How to make the USB I/O turn off relays on M30 or Estop?

I'd like to use the USB I/O module (protocol) to control parts of my mill.
I'd like the relays to turn off when M30 is executed or the Estop is pushed.
How do I hook this into the LinuxCNC bit?

The Halfile controles the pins of your USB modukle
THERE you can conect to whatever you want
INSiDE the POSTGUI_Halfile

BETTER to use your own Mcodes to put your need togeter
USER-Mcodes

The Estop is handles by the HAL you need to get it to HALUI
for use in Postgui

jwatte wrote: I'd like the relays to turn off when M30 is executed or the Estop is pushed.
How do I hook this into the LinuxCNC bit?

How the relays are turned off rather depends on how they are turned on...

Are these relays connected to HAL signals, or controlled independently, with G-code for example?

This forum is about the PathPilot software.
One supported add-on for the PathPilot software is "the USB I/O module."
This is not "any USB I/O module," it's this particular part:
www.tormach.com/store/index.php?app=ecom&ns=prodshow&ref=32616
It is enabled through the "USB I/O Module" checkbox on the Settings page.

The part uses M64 Px and M65 Pn codes to turn on/off relays "n"
Unfortunately, once "on," a relay will not turn "off" even if the program reaches M30, or if the Estop is pressed on the controlled machine.

What's extra dumb about this, btw, is that when Estop is pressed, the relay control button in the GUI stops working -- the relay stays on until I type a manual off command, or bring the machine out of estop and reset the controller.

I'd like to make it so that, when Estop is pressed or the machine reaches M30, the M65 Pn codes are sent to turn the relays off.

In the best of worlds, I can make this change without editing any files that PathPilot will overwrite when it updates, because I do install updates when they are available, and I do not like the idea of forgetting to apply some local change and then the relay-stop not happening.

However, if that can't be done, then a "minimally invasive" method would be better than a "maximally invasive" method. For example, if I could start a new Python module that polls the machine state, and if it finds the machine in Estop or not-running after being running, it issues the appropriate commands.

The closest to what you want is the SHUTDOWN_HAL
linuxcnc.org/docs/2.7/html/config/ini-config.html#_hal_section
But that isn't all that close as it runs on exit, not program end.

M30 is not a remappable code:
linuxcnc.org/docs/2.7/html/remap/remap.h...map:remappable-codes
So that won't work.

Can you make your postprocessor output an M31 instead, then remap that to reset the IO?
Again, not an e-stop solution.

Maybe the answer is to do it in HAL? If the outputs are driven by M63 then they are driven through the pins motion.digital-out-NN in the HAL.
You could and2 those with halui,program-is-running before they are linked to the USB board handler (presumably a userspace HAL component?)

And2 in Hal is the way to go. One of Dewey's plasma configs used the digital pin and when the torach breakaway dropped the torch, flames were still spewing even after an estop and I was sprinting to the other side of a fairly large table to turn of the plasma power supply!

If halui,program-is-running does not turn off on an estop, you might also need to include motion.motion−enabled