7i76e and selective drive fault detection during drive initialization

Greetings,

Some background, I bought a Mesa 7i76e 4 years ago and am finally getting around to putting it to use. I am reworking the controller for a small mill that started out life well over a decade ago on EMC generating steps via parallel port to Gecko G201s. The primary motivator for the 7i76e was the fact the modern releases of linux and LinuxCNC would not reliably run the base thread at acceptable performance levels and I got tired of iterating with the hardware I had on hand. I just wanted my mill converted and running. The Mesa solution is superior anyway, IMO.

The new drives are KL-5080H (a Leadshine variant I believe) driving closed loop NEMA23 stepper motors.

The power to the drives is separate from the control power. The idea is that this allows cycling drive power without cycling the entire controller (LinuxCNC or the 7i76e) should a drive fault occur. Drive faults must be cleared by power cycling the drive. This allows LinuxCNC and the 7i76e to always be in communication and running.

The main power switch on the controller supplies AC and brings up a 24 VDC power supply. That supplies power to the 7i76e and field power for anything else attached to it. A N.O. relay controls AC to the separate 48 VDC drive power supply. This supply does not turn on until a signal from the 7i76e energizes the relay. This all works.

The KL-5080H can assert a drive fault which is tied to inputs and linked to the HAL e-stop chain. It is currently configured to assert high when triggered. The drive firmware allows this to be configured as high or low. I surfaced LEDs in the GUI so the condition has some visual feedback. This also all works.

Finally, the problem. When LinuxCNC is taken out of e-stop and the power button is hit in the GUI,everything works as expected, until the drives fault during their startup sequence, thus triggering a drive fault, e-stop which turns the drive power back off almost immediately.

Although I had considered this possibility, I had not taken the time to ensure what happens at drive startup with the state of the drive alarm. Note that the drive has no drive-ready signal. As it turns out, the drive firmware twiddles the alarm signal as part of its power up sequence, asserting it briefly, then turning it off, as detected using halscope.

So, it is working exactly as it should given the circumstances. Problem is, its not what the desired behavior. I need either a stable drive-ready signal or to temporarily ignore only during drive power up the pesky test blip from the drive alarm signal.

I think I need something like, when machine-is-on (or some other signal) is enabled, ignore drive alarms (feels risky) for some period of time as determined by experimentation (looks like well under 3 seconds).

Assuming what I am trying to do is not the worst idea ever, what are the preferred options to pull this off without introducing unintended side effects? I imagine someone has run into this before but I did not find it. Of course, I can bypass all of this with a manual switch, but that means I cannot reset the drives from the GUI, which was a design goal.

One thing I can try is to invert the alarm signal in the drive firmware (and correspondingly in HAL) to and see if it behaves differently. I expect it'll twiddle the state in any case and I'll be no further ahead.

Sorry the the lengthy post, trying to provide context.


Thanks,

Barry

After posting that book chapter and pondering the problem, I chose to use debounce. Drive faults will be deferred 25ms. It is a compromise and not ideal, but it does work.

Still open to other suggestions.


Thanks,

Barry

Motion inhibit ?

Motion inhibit (motion.enable I presume) seemed interesting. I sort of looked at that but it seemed to be turning into a bit of a rabbit hole, and I concluded, perhaps incorrectly, it may not suit the purpose.

I hunted for an analog to iocontrol.user-request-enable (except for use with machine.enable, or similar) and came up dry. Browsing the source I found onoff_clicked in an Axis Python module which sets a flag in the linuxcnc module. That won't really help at that level, of course.

If one could intercept the motion.enable request event, a startup flag could be set then cleared by a timer. The startup flag would become part of the drive-fault handler allowing the drive-fault to remain cleared but only if triggered during startup, thereby preserving the integrity of the rest of the e-stop chain and behaving as desired (trigger e-stop) in the normal running state.

This becomes trivial if I use the physical signal from the start/stop switch and relay on the control box, but then I still have to hit that button in the GUI and defeats the goal to replace the front panel start/stop button with the GUI machine on button.

It's been a while since I meddled with linuxcnc behavior. I could be missing some obvious things. Maybe more reading. I searched and did not find a similar situation that was solved without using real world signals.


Barry

You could use a couple of hal components to disable the signal from the drives fault signal for a period of time after the drives are enabled. Use a tristate_bit and a oneshot. Connect the input of the Oneshot to the machine enable signal, and the "output not" of the Oneshot to the enable of the tristate_bit. Then feed the signal from the drive through the Tristate_bit's in and out. Set the time for the Oneshot equal to the amount of time you need to ignore the drive's error signal. But if you are happy with what you already have, it is slightly simpler, just a little less responsive when you truly have an error.

You could use a timer in CL. input, machine is on, start a timer that will energize a relay with the contacts of the relay is series with your pesky drive alarm signal so linuxcnc does not see it during the time set in the timer. . After the time period the relay closes back and the alarm signal will trigger linuxcnc. you could also inhibit motion during that time period just to be safe.


That should work if I understand your problem.