task: a kinematics selection is seen on the next line, and the test reads it there - #4563
Merged
Merged
Conversation
WAITING_FOR_KINS_SWITCH went to DONE without setting emcTaskEager, so the command after a G12.1 waited for the next cycle; every other wait state sets it. And readahead_reading, on finding a queue buster's wait over, cleared it and read nothing until the next cycle, which costs every queue buster a cycle before the line after it is read. Two selections on consecutive lines: the first kinematics stayed in force 20 ms before, one servo period after.
The test sampled motion.kins-type from a 20 ms Python loop and required the values it caught to be 0 1 0 1. The program's last two selections are on consecutive lines, so the kinematics between them is in force for a task cycle or two, and the arm CI runner missed it (LinuxCNC#4560). What the test means to check is that a selection is a queue buster: the line after it runs in the selected kinematics. So that line now reads the pin itself, #<_hal[motion.kins-type]> next to #<_kins_type>, and the test checks the four messages against 0 1 0 1. Nothing is sampled, nothing can be missed, and with G12.1 made not to wait the check reports the pin one selection behind. Fixes LinuxCNC#4560.
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.
The test read
motion.kins-typefrom a 20 ms Python loop and required the values it caught to be 0 1 0 1. The program's last two selections are on consecutive lines, so the kinematics between them is in force for a task cycle or two; the arm runner missed it, as #4560 shows, while the interpreter's own messages were right.Two commits:
WAITING_FOR_KINS_SWITCHwent to DONE withoutemcTaskEager, andreadahead_readingcleared a queue buster's wait without reading the next line in the same cycle (that one costs every queue buster a cycle). Two selections on consecutive lines: the first kinematics stayed in force 20 ms before, one servo period after. 125 tests around task green (abort, halui, mdi-queue, mdi-while-queuebuster-waitflag, remap, toolchanger, interp, statbuffer, kins-switch).#<_hal[motion.kins-type]>next to#<_kins_type>, and the test checks the four messages against 0 1 0 1 instead of sampling. That is the guarantee the test is for, a selection is a queue buster and the next line runs in it; with G12.1'sINTERP_EXECUTE_FINISHdisabled the check reports the pin one selection behind and fails. The joint sampling during the W move stays, that state lasts the move.Fixes #4560.