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

Ah, the symlinks will be missing cos I copied it across from the old PC via a thumb drive. How can I create them again?
I hate them!

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 

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
 

We keep just missing.

The button is all I'm interested in.
The button behavior is what I'm coding.
I understand how the estop chain works in principle.

This is how i think AXIS's button works.
when estopped the button appears pressed in.
When the user presses the button one of two things happen.

1) if estop chain is good - the button appears un pressed and linuxcnc comes out of estop.

0r

2) if the estop chain is not good the button appears still pressed in and linuxcnc stays in estop.

What I'm really not sure about is if you have pressed the button to release estop and the estop chain is not ready, if it becomes ready (say in a few seconds) does linuxcnc come out of estop or does it require another button press?

Chris

Based on a bit of work I did last night with a safety relay, I think the state changed as you release the GUI button. If an external estop was enabled at that time, the GUI button did not unpress.
I don't think anything with estop is going to wait around for a few seconds. Its pretty much instantaneous. Get it ready before you take it out of estop or nothing will happen.

I kind of ran out of time last night. I got the safety relay engaging on a GUI estop press but I can't yet see a way to turn the machine off from the GUI. I suspect when I look at my press brake control behaviour, this is pretty normal. On It, I either have to turn off the physical power switch or press the estop to turn off the hydraulic pump (which is in the estop circuit). I'm still thinking about that!