QTPlasmac and estop-latch broken (no iocontrol.0.user-request-enable)

seems like I got it now after running the conversion script on a gmocappy config and it fixed the estop and I was actually able to cut something!
Sorting out Gmocappy's dependencies was another journey you don't need to know about.

Thanks for your help.

So now the final challenge is to get sheetcam operational on Linux.
But Les is helping there.  www.forum.sheetcam.com/viewtopic.php?f=2...1&view=unread#unread

rodw wrote:

This took a bit of sorting out but I eventually found the bug.

When you use estop latch, it requires a reset signal to take it out of estop.
According to the documents, and posts by Bevins and BigJohnT, this reset signal should be connected to 

Code:

iocontrol.0.user-request-enable If you fire up an axis sim or even an early QTplasmac sim (pre estop modes) and monitor this signal in halscope, you will observe a pulse on this signal when the GUI estop is pressed. This is what resets the latch. When I monitor this signal in QTPlasmac, there is no pulse so the latch is never reset. Myself, Bevins and BigJohnT are some I know who use estop-latch. In my case I use it to create a chain for 3 estop buttons which has worked flawlessly until I tried to use QTplasamc. Surely, it not prudent for a GUI to not fully support estop functionality. Can this be fixed please?  I know it could be worked around with some hal logic, but really the features of estop latch are there for a reason so I don't really want to do something half arsed with estop.

 

So I looked into this some more with Qt. The basic problem is linuxcnc requires a weird 3rd state for toggle buttons.

here is how i think it works with AXIS with an external estop loop.

1)
button checked (looks pressed in),
linuxcnc estopped,
external estop logic false

2)
user presses button,
linuxcnc request estop release
external logic checks it's requirements
button _stays_ checked

3a)
external estop passes requirements - goes true
linuxcnc releases estop
button unchecks

3b)
external estop logic requirements don't pass - stays false
button stays unchecked
you must click the button again to try again?


4)
press estop button or external logic goes false
linuxcnc estops
button is set checked
must click the button again to request estop release.

Does this sound what you are expecting?
I currently have a test button in qtvcp that will do this.
The only thing I'm not sure of is if you press the button to release the estop and the external logic is not true (ie not all good),
should it automatically come out of estop when the logic does pass or should you have to press again to try to request the estop to release?
Ie it will only release estop if the external logic is _already_ true (all good)

Chris

Chris, I think it needs a diagram, See attached with 3 estop buttons each with an estop latchHere is my take on how it works
1. Starts with Linuxcnc in a software estop state, the last estop-latch.n.fault-out is true so drives disconnect relays are enabled and warning lights turned on.
2. User enables software estop button.
3. iocontrol.0.user-request-enable goes true and;
4. it is connected to the first latch in the chain  (say estop-latch.0.ok-in) and;
5. iocontrol.0.request.enable sends a pulse which is read by all estop_latch-reset components
6. each estop latch checks its does not have an error condition. If all is good, estop-latch.n.ok-out goes true and is passed along to the next latch in the chain.
7. if all estop-latches are error free, the last estop.n.ok-out in the chain goes goes true
8. the last ok-out (estop-latch.2.ok-out) is connected to iocontrol.0.enable-in so the machine comes out of estop, screen button unpresses.
9. If any estop is pressed (including the GUI one), the chain is broken, estop-latch.n.ok-out goes false, the chain is broken and Linuxcnc goes into an estop  condition again.
10 Start again at point 2 after estop condition is resolved and relevant fault-in input is cleared (goes false)
 

Page 2 of this thread is what it all looks like in hal.
forum.linuxcnc.org/10-advanced-configura...and-latches?start=20

Estop-latch is  not well documented. Itr really needs a worked example.
I had no idea about the pulse on  iocpotrol.0.user-enable-out until I fired up halscope a day or so ago. 
I think this could be useful to trigger a safety relay. I'll save that for another experiment

thanks for looking into this.

My interest is the button behavior.
I need to know what happens when you request estop reset but the external logic isn't ready.

Do you need to press again or do you just wait for the external logic to eventually be ready and then estop releases.

My bet is that you need to press the button again.

Chris

I've been using a multiple estop latch setup for 5 years with that setup and I've never seen a problem.
If you press the GUI button and an external estop is enabled, it refuses to go out of estop and an error message is displayed.

I've been playing with a safety relay today and that a whole new learning curve and I have not even got to the hal file!
I have to order a different estop switch as it requires a  dual terminal normally closed switch!

Looks like the user-request-enable signal is 100 ms long. I don't think it would wait