homing: stop the correct joints when aborting a homing sequence - #4574
Open
grandixximo wants to merge 1 commit into
Open
grandixximo wants to merge 1 commit into
grandixximo wants to merge 1 commit into
Conversation
HOME_ABORT loops over all joints to stop their free planners, but it indexed through the local 'joint' pointer, which already points at joints[joint_num]. An abort raised from joint N stopped joints N..N+ all_joints-1 instead of 0..all_joints-1: lower-numbered homing joints kept running with their homing state already cleared, and with more than EMCMOT_MAX_JOINTS/2 joints the write runs off the end of the joints array entirely. On a gantry this shows up when the higher-numbered joint of the pair aborts (stuck home switch, switch bounce, limit hit): the partner joint's planner is never stopped, and it faults with a following error naming the partner, not the joint that caused the abort. Refs LinuxCNC#4572
Contributor
|
Thank you for the quick response. |
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
2 participants
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.
While investigating #4572 I found that
HOME_ABORTstops the wrong joints: the loop indexes through the localjointpointer, which already points atjoints[joint_num]. An abort raised from joint N stops joints N..N+all_joints-1 instead of 0..all_joints-1, so lower-numbered homing joints keep moving with their homing state already cleared, and with more than 8 joints the write runs off the end of thejoints[]array.On a gantry this triggers when the higher-numbered joint of the pair aborts the sequence (stuck home switch, switch bounce, limit hit during backoff): the partner joint's planner is never stopped, which matches the #4572 error output naming joint 0.
The bug came in with e0c3b39 (#3481).
@Sigma1912 could you test whether this fixes the alternating gantry homing failure from #4572? I could not reproduce the following error itself in a sim config (feedback follows the command there, so gantry racking never happens), but this bug sits right in that failure path.