Advanced Search

tommylight wrote:

NWE wrote:

Most hard stop home systems I've seen, used steppers.
 

Yes, and not reliable at all, and only used on 3D printers.
Definitely not something used on large machines with motors that can do quite some damage.
 

You're right, I certainly wouldn't want to try it with big powerful servos. I should have included more context: These are small dc servo motors driving Z1 and Z2 on the Ursviken press brake I'm retrofitting. That is the independent left and right motion of the two fingers on the backstop. The whole thing is so overbuilt, these little dc motors are going to smoke before they destroy anything.

I have been studying the machine, and have come to the conclusion Ursviken had to have been using hard stop homing on these. All the other, more powerful axis have homing switches, and only the R axis has limit switches. I have not yet found anyone who has watched one of these homing, running the original Ursviken controller.

If the encoder counts, its unlikely the index would be missed as the hardware
index processing uses the same digital filter as the A and B signals.

I included a photo below of the servo drives I already purchased. We have them mounted on the gantry already. here is a link to them. www.omc-stepperonline.com/a6-series-1000...-ip67-a6-rs1000h2a1- 

NWE wrote:

Most hard stop home systems I've seen, used steppers.

Yes, and not reliable at all, and only used on 3D printers.
Definitely not something used on large machines with motors that can do quite some damage.

Well I found somebody to help with this project and we were chugging away making good progress at it. I dident hear from him in a week or two and he messages me saying he was in a bad accident and just got released from the hospital. its been another week or two and I havent heard back from him. Really sucks hopefuly hes okay but we gotta move forward in the project. Is anyone here still interested in helping? im going to post all of the progress we made below its a google sheets aswell as a few pdfs  docs.google.com/spreadsheets/d/10GAzmrCI...184782#gid=730184782  

Interference issues, as seen on your second picture where the high voltage/power stuff is very close to parallel port/BOB, and messy wiring.
First make sure the grounding is OK, then move low voltage stuff as far from high voltage stuff as possible, use short cables, no spaghetti!

Sorry, I forgot to write, these are DC servo motors. Most hard stop home systems I've seen, used steppers.
I think I will write a hal component homeswitch-hardstop that monitors encoder velocity and latches a home-switch-output when the velocity decelerates faster than decel-limit (or servo motor load exceeds max-load?). The latched home switch output clears when the velocity changes direction and moves farther than min-backoff. These encoders do not have index. The most repeatable home position will be with the motor stalled against hard stop. The instant the motor power is switched off, the axis will likely rebound slightly, probably an unrepeatable distance.

I guess I will need to use the homing method of:
1. Home search velocity toward hard stop. Ouch, not at max power!
2. Home switch output latches on hard stop.
3. Back off home switch; home switch unlatches when it detects reversed motion.
4. Home-latch-velocity toward hard stop.
5. Homing complete; move to home-pos at the speed of home-final-vel.

I see I could use this component as shared home + pos limit switch + neg limit switch.

Hey, is anyone doing hard stop homing? I'm not finding any combination of LinuxCNC + hard stop homing. Google is not my friend today. Llm claims to know everything about it but I'm not buying that. If google doesn't know about it then llm has got to be fabricating it.

I am ready to try coding a halcomp if it doesn't already exist. I just don't got time to reinvent the wheel if someone else has already done it.

I consider hard stop homing to be the least accurate version of homing, but in today's project it will be a lot better and cleaner than rigging up some homing switches. If I can attain 5mm repeatability I will be happy, but I am confident I can do better than that.

I caught the index signal with my oscilloscope! It is near the top end of the ram travel, a tiny little pulse. I think I still have the ram jogging up/dn too fast the mesa card isn't latching on it, possibly even to fast for the electronics in the sensor itself. I unbolted the sensor from the Y1 ram and moved it slow with my fingers and caught the ~200uS pulse visible in the second screenshot. The ram is still jogging open loop and way too fast for homing. Looks like I'm on track to close the loop, and try tuning it hydraulic servos and all.

Now that I understand how the index-enable signal is read/write and is latching (I disconnected it from joint.3.index-enable to make sure it's not clearing it before I get to see it.) my latching hal AND2 + OR2 wiring the other day was unnecessary.

Here you go

i put that. it just waits for something.
 

Edit: i got it. Just rename the file from arduino-connector to arduino with loadusr -W arduino and it works.

The real-time threads must be loaded before using any pin.

Put loadusr -W arduino-connector at end main hal file.

All LinuxCNC motion hardware is real time so as I said the only limitation is that the accuracy
of some operations like probing and homing without using index is limited to velocity *
servo thread period (usually 1 ms). This is typically not an issue because the final velocity can be quite low
as the distance covered by the final latch move is small.

On Mesa hardware, the stepgen is a digitally controlled rate generator. At ever servo thread
invocation (typically 1000 times a second),  LinuxCNC reads the current stepgen position
from the hardware and compares it to the actual commanded position and makes corrections in the rate 
to keep the step generation in sync with LinuxCNCs commanded position. This typically
keeps the external step generation within a small fraction of a step of the commanded position.
 

I would probably renumber the sserial channels so the 7I85 sserial channels start at 0 rather than 1

Flashing is safe as long as you have a recent mesaflash that supports the 7I96S

You could also use some threshold (> 200?) on  the fault count pin

You should also find out why you are getting sserial faults, in general these should never happen

I also think it's actually a bug if run is not cleared when all communication is lost and LinuxCNC
gives up