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

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.

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

If I understand these proposals correctly, I need to change or update the PathPilot implementation to detect these changes and update the output relay state.

I'm hoping for a solution that doesn't require me to re-apply it after each update to the PathPilot software.

It sounds like the least-bad solution for me would be to start a new process that polls the existing HAL pins, and applies the appropriate M codes to send the commands to the relays, when it detect changes in the HAL pins. This, then, leads me to my next question, in another topic in this thread, about how PathPilot decides what processes to start, and how I can make it start some new file that I "drop into" the installation. (It's still something I need to remember to do, but at least it doesn't modify files in place at that point. I could even have a shell startup job that auto-installed it if not present.)

forum.linuxcnc.org/pathpilot/35890-how-d...ython-files-to-start

Maybe a better solution is in hardware (only supply power to the USB output relays if out of ESTOP), then even a complete PC crash would turn off the outputs...

In the Pathpilot postgui hal file the USBIO pins are defined as
I'm not the best with hal command but couldn't you take the ESTOP and use a AND to cause one of the dig-out-# lines to includes the estop

There is also what might be a point in the UI where M30 is checked for to rewind the gcode window. you may be able to inserts a MDI command to do what you want with a relay there. may not be ideal but as mentioned M30 is not a remapped code.