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

More
23 Jan 2019 23:25 #124693 by jwatte
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?

Please Log in or Create an account to join the conversation.

More
24 Jan 2019 09:26 #124720 by pl7i92
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

Please Log in or Create an account to join the conversation.

More
24 Jan 2019 13:49 #124739 by andypugh

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?

Please Log in or Create an account to join the conversation.

More
25 Jan 2019 17:55 - 25 Jan 2019 18:04 #124832 by jwatte
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.
Last edit: 25 Jan 2019 18:04 by jwatte.

Please Log in or Create an account to join the conversation.

More
25 Jan 2019 18:09 #124838 by andypugh
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?)
The following user(s) said Thank You: jwatte

Please Log in or Create an account to join the conversation.

More
26 Jan 2019 06:52 #124880 by rodw
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
The following user(s) said Thank You: jwatte

Please Log in or Create an account to join the conversation.

More
26 Jan 2019 20:09 - 26 Jan 2019 20:10 #124926 by jwatte
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
Last edit: 26 Jan 2019 20:10 by jwatte.

Please Log in or Create an account to join the conversation.

More
26 Jan 2019 21:10 #124930 by andypugh
No.

Updating Pathpilot won't change your HAL files, those are your config and should be left alone by updates to LinuxCNC.

The and2 logic will go in the HAL file, it isn't a change to the software itself, just a re-routing of the signals from G-code to the IO board.

Please Log in or Create an account to join the conversation.

More
26 Jan 2019 21:25 #124933 by PCW
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...

Please Log in or Create an account to join the conversation.

More
26 Jan 2019 21:53 - 26 Jan 2019 21:53 #124935 by smgvbest
In the Pathpilot postgui hal file the USBIO pins are defined as
# USBIO
net usbio-enabled tormach.usbio-enabled => usbio.enabled
net dig-out-0 tormach.usbio-output-0
net dig-out-1 tormach.usbio-output-1
net dig-out-2 tormach.usbio-output-2
net dig-out-3 tormach.usbio-output-3
net dig-out-4 tormach.usbio-output-4
net dig-out-5 tormach.usbio-output-5
net dig-out-6 tormach.usbio-output-6
net dig-out-7 tormach.usbio-output-7
net dig-out-8 tormach.usbio-output-8
net dig-out-9 tormach.usbio-output-9
net dig-out-10 tormach.usbio-output-10
net dig-out-11 tormach.usbio-output-11
net dig-out-12 tormach.usbio-output-12
net dig-out-13 tormach.usbio-output-13
net dig-out-14 tormach.usbio-output-14
net dig-out-15 tormach.usbio-output-15

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.
Last edit: 26 Jan 2019 21:53 by smgvbest.

Please Log in or Create an account to join the conversation.

Moderators: cncbasher
Time to create page: 0.089 seconds
Powered by Kunena Forum