Ignore following errors while homing

A friend and I are converting a VMC to LinuxCNC.

The limit switches are also the homing switches and are wired into the servo drive and fed into LinuxCNC. When the negative limit switch is hit the servo drive enables a braking resistor and only allows right movement. This stops the servo extremely fast and leads to a following error if our maximum following error isn't set rather large.

It seems like the safest way to handle this is to expect the following error and to ignore them on homing commands. Is there a way to do that?

best way is to re-wire and fit a second switch for homing
just slightly inboard of the limits ,

it could also be done by re-wiring or re-routing the limits via , i presume a Mesa card etc
it's difficult to explain more without knowing more , but it's quite easy to do

cncbasher wrote:

best way is to re-wire and fit a second switch for homing
just slightly inboard of the limits ,

it could also be done by re-wiring or re-routing the limits via , i presume a Mesa card etc
it's difficult to explain more without knowing more , but it's quite easy to do

I've thought about adding homing switches, but that is a complicated project to do correctly on this machine (it's a large VMC, not a small benchtop mill). The best homing switch implementation would be expanding the current limit switches to have a third switch in them and machining new ramps that contact the homing switch earlier. The limit switches on the machine cost about $200ea, so that would be a nearly $1000 project.

It would be trivial to rewire to have the servos ignore the limit switches, but they provide a lot of safety to the system (for instance if we had a runaway it is good knowing that eventually the servo will kill the motor when it reaches it's limit). The machine has been running with it's current physical configuration for over 20 years and it seems unnecessary to change that vs a software change that says a following error is okay if a limit switch is hit.

I thought there might be a way to configure the allowable following error into two different hal parameters, and flip to the larger one when the limit switch hits.

When the negative limit switch is hit the servo drive enables a braking resistor and only allows right movement. This stops the servo extremely fast and leads to a following error if our maximum following error isn't set rather large.

What speed are you homing at? Does this improve if you set HOME_SEARCH / LATCH _VEL to slow speeds?

Generally having a hardware reaction to a switch, independent of the logic reaction in the software, must be undesirable I should think.
I would not imagine that the following error can be discounted easily, because it is an integral part of the positioning feedback of the axis.

One solution that occurs is to simply have 2 way switches to set the use of the end of movement switches between homing (with no signal feed to the drive) and limits (with the servo drive brake enabled).

It would require some logic changes and a slightly altered homing procedure, but I know others have gone down that road before for other reasons.

regards

We are homing at 2000mm/min. We have to slow down to under 500mm/min to keep a reasonable following error using the existing wiring. X travel is about 800mm, so that would be painful (machine rapids are 24000mm/min to give some reference).

Most hardware is configured to handle E-Stop regardless of what the software does, this is the same thing on this machine for the limits. It's interesting to think about turning them off during homing sequence, but that makes me less comfortable then disabling following errors during the homing sequence. The following error doesn't even need to be disabled for the entire homing, only if the limit switch is also contacted.

If following error is available as a HAL pin (I'll have to check later on) then I can see how to implement this all in HAL logic. Looking at the LinuxCNC-sim install that I have at home it looks like it is only an OUT parameter and can't be changed.

What sort of driver are you using on the mill? perhaps there is a way to delay the event that trips the break when the limit is hit?
Then linuxcnc might be able to get a lower following error and not fault out when the break applies.
Maybe the drives have a function to apply the break X encoder counts after the switch is tripped?
Then you will have the saftey while keeping the wiring as is.

I suspect that the source to motion would need to be modified to do what you want

Perhaps the most flexible would be for ferror and min_ferror to be exposed as
normal hal pins rather than .ini file constants. Then a mux component
could switch between wide ferror limits before homing is complete
to normal ferror limits once homing was completed

EDIT: easier than I thought...

dgarr on IRC just educated me about ini constants and I was able to change the ferror limits on a running system:

pcw@pcw-G41M-Combo:~/linuxcnc-dev$ halcmd show pin ini.0.\*ferror
Component Pins:
Owner Type Dir Value Name
33 float IN 0.0002 ini.0.ferror
33 float IN 0.0001 ini.0.min_ferror

halcmd setp ini.0.ferror 5
halcmd setp ini.0.min_ferror 2

pcw@pcw-G41M-Combo:~/linuxcnc-dev$ halcmd show pin ini.0.\*ferror
Component Pins:
Owner Type Dir Value Name
33 float IN 5 ini.0.ferror
33 float IN 2 ini.0.min_ferror

These changes are "live" (I was able to generate a ferror on a running system by setting both limits to 0)

Swapper wrote:

What sort of driver are you using on the mill? perhaps there is a way to delay the event that trips the break when the limit is hit?
Then linuxcnc might be able to get a lower following error and not fault out when the break applies.
Maybe the drives have a function to apply the break X encoder counts after the switch is tripped?
Then you will have the saftey while keeping the wiring as is.

The first idea is possible and a good one. The control (Yaskawa CACR series) allows for the following options when the limit is hit:

Yaskawa wrote:

(a) Coasting to a stop (Cn-01, bit 6= 1)
When overtravel occurs, the motor coasts to a stop.
(b) DB stop (Cn-01, bit 6=0)
When overtravel occurs, the motor is stopped by the dynamic brake. Whether the brake
is released after the motor stops or not is decided by bit 7 of user constant Cn-01.
(c) Stop at the torque specified by user constant Cn-01, bit 8 = 1
When overtravel occurs, regardless of speed reference, the internal circuit forcibly changes
speed reference to zero and immediately stops the motor. After the motor stops, it is
released free. Stop torque is decided by Cn-06, emergency stop torque.
(d) Zero-clamp after stopping at the torque specified by user constant Cn-01, bit 8 = 1
After the motor stops as (c) above, it is held in zero-clamp mode.

I think the drive is currently in mode (b). I should be able to switch to mode (c) and control the torque to get something that closely matches our acceleration curve. Thanks for the idea!

I do like the idea of having the motion tuning parameters available as pins, but can also see the challenge in having these change in realtime. Following error is probably a lot safer to change in realtime than acceleration.

I do like the idea of having the motion tuning parameters available as pins, but can also see the challenge in having these change in realtime. Following error is probably a lot safer to change in realtime than acceleration.

Changes to ini hal pins are seen promptly in hal but milltask, the userspace task controller for LinuxCNC, samples the ini hal pins when it is _not_ running a program (or mdi command).

for related info, see the thread:
www.linuxcnc.org/lucid/index.php/english...ation?start=10#51720

As I explained above, the ferror ini parameters _can_ be changed in real time

another option suggested by cradek on irc is to use homing to index
(jog to mark perhaps near middle of travel) and then home to index