Best practice for multiple sources of Hal signals (estop, jog, etc.)

More
7 years 9 months ago #124213 by dokwine
Best practice for multiple sources of Hal signals (estop, jog, etc.) was created by dokwine
I am reworking my machine to incorporate a Glade panel. The machine also has a Vista USB pendant on it. My question is how to let either the pendant, or Glade drive common signals like estop or jog since those input pins can only be attached to one output pin? Is the correct approach an "or" function in an rt thread or is there a better preferred approach?

My current setup seems to allow axis and the pendant estop or jog the machine, but I was never able to sort how to add my own jog buttons with pyvcp without conflicting with the pendant.

Thanks

Please Log in to join the conversation.

More
7 years 9 months ago #124220 by cmorley
Replied by cmorley on topic Best practice for multiple sources of Hal signals (estop, jog, etc.)
It depends on what type of buttons/switches you use.
The preferred way is to use momentary switches to toggle events.
In this way any panel can change the state.
You can see the idea in HALUI - there are pins with 'is-on' for status and separate pins for on and off.

Unfortunately things like jog rate and jog increment don't work that way.
Each ui has it's own concept of jograte/increment.

How does your pendant connect to linuxcnc?
If it was me I would try to use GLADEvcp for the 'hub' of all ways to jog.
It would mean you would need to connect your USB pendant with python code to gladevcp.

And that would still leave AXIS independant for jog rate etc - AXIS is not friendly in that way. It can be hacked in using the .axisrc file python and HAL.

Depends on how much time/work you wish to put into it.

Chris M

Please Log in to join the conversation.

More
7 years 9 months ago #124253 by dokwine
Replied by dokwine on topic Best practice for multiple sources of Hal signals (estop, jog, etc.)
Thanks for the reply Chris. A few additional thoughts/?s then..

  • Hah! Never put that together :\ "is-on vs "on" --was always puzzled by the similar names :)
  • The pendant is a bit of a black box; it has a driver and comes with a bunch of preconfigured Hal statements providing access to the signals which, in turn, drive standard HALUI input pins and conflicting with the panel's HAL pin definitions
  • I expect I won't go there right now, but when you refer to connecting the pendant to gladevcp via python, are you referring to bashing the pins directly within python as a way to avoid creating signals for the HAL pins?

    • For the time being I think I'll just work through the estop issue, as I rarely jog from the panel and I rarely run things from the pendant. Once I'm back up with gladevcp I may revisit. I just needed to see if I was missing something obvious.

    Thanks again,
    Ron

    p.s. One more thing... when you refer to momentary switches toggling events you are suggesting multiple momentary switches through an "or" function?

    Please Log in to join the conversation.

    More
    7 years 9 months ago #124264 by rodw
    Replied by rodw on topic Best practice for multiple sources of Hal signals (estop, jog, etc.)
    It is possible to create an estop chain in hal where you have seperate switches that trigger an estop. Its not documented very well anywhere I can find but it looks something like this for 3 estop switches (in my config anyway.). Note at the end, I turn on a warning light and disable my stepper drives.
    Code:
    # --- ESTOP CHAIN STARTS --- net latch-reset iocontrol.0.user-request-enable net latch-ok-in iocontrol.0.user-enable-out net latch-ok-in => estop-latch.0.ok-in net latch0-out <= estop-latch.0.ok-out net latch0-out => estop-latch.1.ok-in net latch1-out <= estop-latch.1.ok-out net latch1-out => estop-latch.2.ok-in net latch-reset => estop-latch.0.reset net latch-reset => estop-latch.1.reset net latch-reset => estop-latch.2.reset net latch-out iocontrol.0.emc-enable-in <= estop-latch.2.ok-out net estop-out estop-latch.2.fault-out # --- EXTERNAL ESTOP SWITCH --- net external-estop <= hm2_7i76e.0.7i76.0.0.input-00 net external-estop => estop-latch.0.fault-in # --- PENDANT ESTOP SWITCH --- net pendant-estop <= hm2_7i76e.0.7i76.0.0.input-26-not net pendant-estop => estop-latch.1.fault-in # --- TORCH BREAKAWAY E-STOP --- net torch-breakaway <= hm2_7i76e.0.7i76.0.0.input-06 net torch-breakaway => estop-latch.2.fault-in # --- E-STOP STEPPER DRIVE DISABLE --- net estop-out hm2_7i76e.0.7i76.0.0.output-05 # --- E-STOP RED WARNING LIGHT --- net estop-out hm2_7i76e.0.7i76.0.0.output-00 # --- ESTOP CHAIN ENDS ---

    Please Log in to join the conversation.

    More
    7 years 9 months ago #124272 by cmorley
    Replied by cmorley on topic Best practice for multiple sources of Hal signals (estop, jog, etc.)

    dokwine wrote: Thanks for the reply Chris. A few additional thoughts/?s then..

  • Hah! Never put that together :\ "is-on vs "on" --was always puzzled by the similar names :)
  • The pendant is a bit of a black box; it has a driver and comes with a bunch of preconfigured Hal statements providing access to the signals which, in turn, drive standard HALUI input pins and conflicting with the panel's HAL pin definitions
  • I expect I won't go there right now, but when you refer to connecting the pendant to gladevcp via python, are you referring to bashing the pins directly within python as a way to avoid creating signals for the HAL pins?

    • For the time being I think I'll just work through the estop issue, as I rarely jog from the panel and I rarely run things from the pendant. Once I'm back up with gladevcp I may revisit. I just needed to see if I was missing something obvious.

    Thanks again,
    Ron

    p.s. One more thing... when you refer to momentary switches toggling events you are suggesting multiple momentary switches through an "or" function?


    So your pendant using only HAL pins actually can work fine.
    You could feed those HAL pins into gladevcp python code and dispatch all commands from there.

    The 'or' component should not be necessary.
    Most states, say flood coolant, is held in linuxcnc's motion controller.
    You change the state by sending messages to the controller and the controller sends you status of the state with messages.

    so if you have two pendants that have flood buttons that are momentary, with an LED for status of that state, then if one button is pressed it passes a message to the controller to toggle it's state.
    After it toggles it's state the controller sends a status message to both pendants to update their LEDs.
    If this way the state of both pendants are always the same and no 'or' component is needed

    If you use a physical toggle switch on one pendant then of course that process can't work the same.
    The physical switch represents the 'status' of that pendant and it can't be changed automatically.
    It also doesn't work if the state (such as jograte) is not held by the motion controller.

    In these cases you can connect the pendants together with HAL pins or code and dispatch commands from one place.

    Chris M

    Please Log in to join the conversation.

    More
    7 years 9 months ago #124279 by dokwine
    Replied by dokwine on topic Best practice for multiple sources of Hal signals (estop, jog, etc.)
    Thanks Chris and Rod. I think I have what I need to get this sorted.

    I really appreciate the input,
    Ron

    Please Log in to join the conversation.

    More
    5 years 9 months ago #193711 by ikkuh
    Replied by ikkuh on topic Best practice for multiple sources of Hal signals (estop, jog, etc.)

    dokwine wrote: Thanks Chris and Rod. I think I have what I need to get this sorted.


    Hi Ron,

    Care to share what you came up with? Might be helpful for others.

    Please Log in to join the conversation.

    More
    5 years 7 months ago #204029 by ikkuh
    Replied by ikkuh on topic Best practice for multiple sources of Hal signals (estop, jog, etc.)

    rodw wrote: It is possible to create an estop chain in hal where you have seperate switches that trigger an estop. Its not documented very well anywhere I can find but it looks something like this for 3 estop switches (in my config anyway.).


    I used your code to setup a latch and it all seems to work, but I can never get the machine out of the external e-stop state. Can somebody tell me what I am doing wrong? I can see in Halshow that signals are generated and respond to the physical switches.

    I have an 7i96, Chinese paralel port bob (both for input/output) connected to the machine.I also have a JoyStick USB card connected that supplies input signals for LinuxCNC. The BOB shows the leds and the usb JoyStick card supplies the inputs for the external stop signals (except for the main e-stop, that is coming from the 7i96).

    (more info about using the JoyStick USB solution can be found at: git.cnckloon.nl/PeterT/CNCMachine/wiki/Joystick-USB with many thanks to Jerry www.youtube.com/channel/UCLOP1A92jZxEmfZf_CJWW7A , he has lots more stuff explained).
    Code:
    # external estop loadrt estop_latch count=3 ############### joystick, usb, bob loadusr -W hal_input -KRAL DragonRise # --- ESTOP CHAIN STARTS --- net latch-reset iocontrol.0.user-request-enable net latch-ok-in iocontrol.0.user-enable-out net latch-ok-in => estop-latch.0.ok-in net latch0-out <= estop-latch.0.ok-out net latch0-out => estop-latch.1.ok-in net latch1-out <= estop-latch.1.ok-out net latch1-out => estop-latch.2.ok-in net latch-reset => estop-latch.0.reset net latch-reset => estop-latch.1.reset net latch-reset => estop-latch.2.reset net latch-out iocontrol.0.emc-enable-in <= estop-latch.2.ok-out net estop-out estop-latch.2.fault-out # --- EXTERNAL ESTOP SWITCH --- net external-estop <= hm2_7i96.0.gpio.010.in_not net external-estop => estop-latch.0.fault-in # --- PENDANT ESTOP SWITCH --- net pendant-estop <= input.0.btn-base4 net pendant-estop => estop-latch.1.fault-in # --- TORCH BREAKAWAY E-STOP --- #net torch-breakaway <= hm2_7i76e.0.7i76.0.0.input-06 #net torch-breakaway => estop-latch.2.fault-in # --- E-STOP STEPPER DRIVE DISABLE --- net estop-out parport.0.pin-03-out # --- E-STOP RED WARNING LIGHT --- net estop-out parport.0.pin-04-out # --- ESTOP CHAIN ENDS --- ## # The next lines are only needed if the pins had been connected before unlinkp iocontrol.0.tool-change unlinkp iocontrol.0.tool-changed unlinkp iocontrol.0.tool-prep-number unlinkp iocontrol.0.tool-prepared net tool-change gmoccapy.toolchange-change <= iocontrol.0.tool-change net tool-changed gmoccapy.toolchange-changed <= iocontrol.0.tool-changed net tool-prep-number gmoccapy.toolchange-number <= iocontrol.0.tool-prep-number # create signals for tool loading loopback net tooloffset-x gmoccapy.tooloffset-x <= motion.tooloffset.x net tooloffset-z gmoccapy.tooloffset-z <= motion.tooloffset.z #net Pgm-run <= halui.program.run <= parport.0.pin-12-in-not #net Pgm-pause <= halui.program.pause <= parport.0.pin-11-in-not #net Pgm-run <= halui.program.run <= input.0.btn-joystick net Pgm-stop <= halui.program.stop <= input.0.btn-thumb # net Pgm-pause <= halui.program.pause <= input.0.btn-thumb2 net Pgm-resume <= halui.program.resume <= input.0.btn-top net Pgm-step <= halui.program.step <= input.0.btn-top2 ############# net Mist-on <= halui.mist.on <= input.0.btn-pinkie # net Mist-off <= halui.mist.off <= input.0.btn-base # net Homing <= gmoccapy.h-button.button-0 <= input.0.btn-base # net HomingStart <= gmoccapy.h-button.button-1 <= input.0.btn-base2 # net Spindle-start <= halui.spindle.0.start <= input.0.btn-base2 # net Spindle-stop <= halui.spindle.0.stop <= input.0.btn-base3 ######################## net Estop-activate <= halui.estop.activate <= input.0.btn-base4 net Jog-Z-Plus <= gmoccapy.jog.axis.jog-z-plus <= input.0.btn-base5 net Jog-Z-Minus <= gmoccapy.jog.axis.jog-z-minus <= input.0.btn-base6 ## Unused ------------------------------------------- MODE [ End Button ] ## Unused ------------------------------------------- TURBO [ End Button ] ## Unused ------------------------------------------- CLEAR [ End Button ] ## Unused ------------------------------------------- AUTO [ End Button ] net Jog-X-Plus <= gmoccapy.jog.axis.jog-x-plus <= input.0.abs-x-is-pos net Jog-X-Minus <= gmoccapy.jog.axis.jog-x-minus <= input.0.abs-x-is-neg net Jog-Y-Plus <= gmoccapy.jog.axis.jog-y-plus <= input.0.abs-y-is-neg net Jog-Y-Minus <= gmoccapy.jog.axis.jog-y-minus <= input.0.abs-y-is-pos #**** Debounce ### https://www.forum.linuxcnc.org/24-hal-components/32319-debounce#87672 loadrt debounce cfg=2 addf debounce.0 servo-thread setp debounce.0.delay 10 #**** /Debounce #***** Toggle loadrt toggle2nist names=toggle.0,toggle.1 addf toggle.0 servo-thread addf toggle.1 servo-thread #***** /Toggle setp hm2_7i96.0.gpio.036.is_output true ## mist # Mist Button ######## net mist_toggle_debounced debounce.0.0.in <= input.0.btn-pinkie net mist-toggle toggle.0.in <= debounce.0.0.out net mist-on toggle.0.on => halui.mist.on net mist-off toggle.0.off => halui.mist.off net mist-control halui.mist.is-on => toggle.0.is-on => parport.0.pin-02-out #$ net Spindle-start_debounced debounce.1.0.in <= input.0.btn-base2 # net Spindle-start_toggle <= debounce.1.0.out ## net halui.spindle.0.start <= input.0.btn-base2

    Please Log in to join the conversation.

    More
    5 years 7 months ago #204039 by ikkuh
    Replied by ikkuh on topic Best practice for multiple sources of Hal signals (estop, jog, etc.)
    Somehow I managed to forget to add the latches to a thread, it works now:
    Code:
    ### external estop loadrt estop_latch count=3 addf estop-latch.0 servo-thread addf estop-latch.1 servo-thread addf estop-latch.2 servo-thread

    Please Log in to join the conversation.

    Time to create page: 0.107 seconds
    Powered by Kunena Forum