Repository navigation
Show the estop reset after a reset and machine on between two status polls - #4778
grandixximo wants to merge 1 commit into
Conversation
GStat emitted state-estop-reset only for ESTOP => ESTOP_RESET. A client that resets the estop and turns the machine on between two polls goes from ESTOP straight to ON, and qtdragon and gmoccapy kept showing the estop set on a machine that was on.
|
I do not like to implement this in gmoccapy. The behavior of gmoccapy wath correct until now, wasn't it? Norbert |
|
Thanks for looking, Norbert. I agree the cause is in gstat, and the first commit fixes it there: gstat now emits I don't think gstat alone can fix it for gmoccapy, though. gmoccapy's status handlers set its E-stop and On buttons, and the toggled handlers of those buttons then send that state to the machine. In this case the signal that the E-stop is reset arrives after the machine is already on, so gmoccapy answers it with an ESTOP_RESET, which aborts what the machine is doing. The current behaviour isn't right in this case either. I ran current master without this PR on the gmoccapy lathe sim, sent the E-stop reset and machine on back to back from a script, and logged the state commands task received (
With this PR the machine stays on, and the first click on the E-stop button sends ESTOP. To be fair, this is not something a user is likely to experience. It takes a script that sends the reset and the machine on within one status poll, as ours does, and I could not reproduce it from halui pins. I hit it in the ui-smoke tests. I also tried the usual boot sequence, halui's E-stop reset and then machine on through a The gmoccapy part is small: while a status handler shows a state on the E-stop or On button, it blocks that button's toggled handler, as gmoccapy already does for its fullscreen buttons. Would that be acceptable to you, or do you see a way to keep it all in gstat that I am missing? |
0c09570 to
760aee8
Compare
|
Following Sunday's meeting I took the gmoccapy commit out, so this PR is gstat only now. Finding out why it was needed turned up two other problems, now in their own PRs:
gmoccapy still sends an ESTOP_RESET and an ON back when it shows the state; with #4801 they do no harm. |
emcTaskSetState() ran the whole E-stop reset for ESTOP_RESET in any state: it aborted motion and the interpreter, stopped the spindles, turned the flood off and aborted iocontrol. Sent to a machine that is on, the machine stayed on and lost whatever it was doing, a running program or a homing. The docs only describe the reset as leaving E-stop, and halui.abort is the way to abort. gmoccapy sends such a reset: when it shows a state change on its E-stop button, the button's handler sends that state again. With gstat reporting the reset after a reset and machine on that fall between two status polls (LinuxCNC#4778), the reset arrives at a machine that is already on, and aborted a homing the ui-smoke driver had just started. Skip ESTOP_RESET when the machine is on. Every other state runs it as before, including configs that tie iocontrol.0.emc-enable-in high, where task never reports E-stop. No in-tree sender relies on the abort while on: AXIS, gscreen, tklinuxcnc and the qtvcp action button check for E-stop first, and the tests reset only from E-stop or at startup.
GStat emits
state-estop-resetonly for an ESTOP => ESTOP_RESET change. A client that resets the estop and turns the machine on between two status polls goes from ESTOP straight to ON, so qtdragon and gmoccapy kept showing the estop set on a machine that was on. I hit it with a ui-smoke driver that sends the reset and the machine on back to back.GStat now emits
state-estop-resetwhenever the state leaves ESTOP, asgstat.adocalready describes it: "Sent when LinuxCNC comes out of estop."Checked on the gmoccapy lathe sim with the reset and machine on sent back to back from a script: on master, gmoccapy switches the machine off again 0.08 s later and its first E-stop click sends ESTOP_RESET; with this change the machine stays on and the first click sends ESTOP.
gmoccapy sends the state it is shown back as commands, so with this change it sends an ESTOP_RESET to a machine that is already on, and task then aborts whatever the machine is doing. #4801 makes task leave a machine that is on alone, and #4802 stops the JOG_STOP gmoccapy sends at startup, which aborted a homing begun right after the machine came on. With all three, gmoccapy ui-smoke ran without a homing retry in every run I made, also beside 8 busy loops, and all ui-smoke tests pass.