HAL component for DC motor runaway protection

With DC motor servo setups, there is a known risk of runaway conditions if the feedback encoder cable gets disconnected or the encoder malfunctions. If the machine is stationary when this happens, the feedback malfunction can show 1-2 encoder ticks of position error to LinuxCNC, which is too small to trigger following error. The PID integrator will try to compensate the error, causing the axis to slowly accelerate towards one end until it crashes.

I had a near-miss with this when messing with the cabling with machine powered on (I know, stupid..). Fortunately quick e-stop press avoided a crash this time. To protect against any future cabling or encoder faults, I made this little HAL component.

Parameters:

• control_threshold: Movement is expected to occur if absolute value of control exceeds this threshold.
• feedback_threshold: Encoder is considered to work correctly if the changes in feedback exceed this threshold.
• time_threshold: Time delay to account for motor inertia.

Pins:

• input control:  The output from PID controller
• input feedback: The feedback input to PID controller
• output out: Goes high if runaway is detected

The basic idea is that once the PID output is high enough, the motor should start moving. If the component doesn't see movement in encoder feedback within given time, it can be used to trigger emergency stop. Small movements that are below feedback_threshold are expected to occur within time_threshold seconds, after which PID output will return below the threshold. Larger movements will reset the timer every time a feedback_threshold worth of movement is detected since the last reset.

There is example of using this component in a full configuration here:
github.com/HacklabJKL/sergei_cnc2/commit...636d14fa01c15c82e95c

Hi,

Yeah, it could be nice to have this part of the main distribution.
Though it might make sense to let this "bake" bit first, I'm still building my CNC machine so haven't done very much practical testing yet.

Today when testing I did notice a small bug with negative movements , fixed in the attached version.

I have done a test without limit switches
and a failed linear scale resulted in a crash.
Ferror was 3/20mm but this didn't worked.
Ferror protects when encoder does not work
or works unreliable ?
Machine was a mill with analog speed servos
without encoders and position feedback send to linuxcnc by linear scales.
Can use this component to protect from this type runaway ?

During motion you would get a following error if the encoder stops counting
since at some point the commanded position would differ enough from the
feedback position to cause a following error.

If stopped, a bad encoder can cause a runaway. One way to address this
failure mode is to

1. Have some integral term so a small error will eventually saturate the system

2. check either pid.N.saturated (a bit) or pid.N.saturated-s (a float) to
check if the PID loop is saturated. A possible refinement here is to set
the PID maxoutput to a function of the commanded velocity.

2A. The previous check does require the error build up to full output before
the error is detected so a faster response would be to check pid.n.errorI
(by comparing it to a limit) Normally you would not expect the integral error to
build up to a large value if encoder feedback is working (note you need to
have "debug=1" on the PID loadrt line ti make the errorI parameters appear)