Repository navigation
Show the estop reset after a reset and machine on between two status polls - #4778
Open
grandixximo wants to merge 2 commits into
Open
grandixximo wants to merge 2 commits into
grandixximo wants to merge 2 commits 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.
The status handlers set the estop and machine on buttons, whose toggled handlers then sent that state again. Once GStat reports the estop reset that comes with an ESTOP => ON change, gmoccapy sent an ESTOP_RESET to a machine already on, which aborts its motion. Block the toggled handler while showing the state; on machine on, also update the widgets as the toggled handler did.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.The first commit emits
state-estop-resetwhenever the state leaves ESTOP.That alone made gmoccapy worse. Its status handlers set the estop and machine-on buttons, and the buttons' toggled handlers then send that state again. With the estop reset now reported after the machine is on, gmoccapy sent an ESTOP_RESET to a machine already on, which aborts its motion (in the test, a homing in progress). The second commit blocks the toggled handler while a status handler shows the state, as gmoccapy already does for its fullscreen buttons; on machine on it also updates the widgets the toggled handler used to.
Checked with the ui-smoke tests: after a back-to-back reset and machine on, qtdragon and gmoccapy show the estop reset, and gmoccapy no longer sends ESTOP_RESET or ON from its status handlers (I logged every command it sent over three runs, before and after). The ui-smoke directory passes as is.