Repository navigation
motion: a kinematics switch reads the joints where the planner put them - #4810
Open
grandixximo wants to merge 1 commit into
Open
grandixximo wants to merge 1 commit into
grandixximo wants to merge 1 commit into
Conversation
A kinematics switch re-reads the pose from the joints, and it read them at pos_cmd, the cubic interpolation behind the planner. Task issues the switch once motion reports the moves before it done, which is when the planner is done; pos_cmd is a few servo cycles behind it then. With task on a 1 ms cycle the switch reaches motion inside that window, the pose is read off the joints short of the end of the move, the planner is put there, and the joints stay there. On the kins-switch sim with task on 1 ms, a G12.1 right after a G0 W0 left W short of 0: by 0.000025 mm with the sim's former limits, in 18 runs of 20, and by 0.0083 mm with the faster ones of LinuxCNC#4807, in every run. With task on its usual 10 ms cycle the window has passed before the switch arrives. The switch now reads coarse_pos, where the planner has put the joints, as the re-read after a tool offset change already does. The interpolation then finishes the move under the new kinematics. In free mode coarse_pos is pos_cmd, so a switch there is unchanged. tests/kins-switch runs task on a 1 ms cycle and checks that W is back on 0 after the program's G0 W0 and the switch after it: 3 failures in 3 runs before, passing after, also with six copies beside four busy loops and pinned to one CPU.
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.
A kinematics switch re-reads the pose from the joints, and it read them at
pos_cmd, the cubic interpolation behind the planner. Task issues the switch once motion reports the moves before it done, which is when the planner is done;pos_cmdis still a few servo cycles behind it then. With task on a 1 ms cycle the switch reaches motion inside that window: the pose is read off joints short of the end of the move, the planner is put there, and the joints stay there.Found while speeding up the tests in #4807: on the kins-switch sim with
[TASK] CYCLE_TIME = 0.001, aG12.1right after aG0 W0left W short of 0, by 0.000025 mm with the sim's former limits in 18 runs out of 20, and by 0.0083 mm with the faster limits #4807 gave it, in every run. (On #4807 I wrote about 25 um for the first; it was 25 nm.) With task on its usual 10 ms cycle the window has passed by the time the switch arrives, which is why it did not show before.The switch now reads
coarse_pos, where the planner has put the joints, as the re-read after a tool offset change (emcmotToolOffsetChanged) already does. The interpolation then finishes the move under the new kinematics. In free modecoarse_posispos_cmd, so a switch there is unchanged.tests/kins-switch now runs task on a 1 ms cycle and checks that W is back on 0 after the program's
G0 W0and the switch that follows: it fails 3 runs out of 3 without the fix and passes with it, also with six copies running beside four busy loops, and pinned to one CPU.