|
From: Luca T. <no...@gi...> - 2026-09-18 07:18:37
|
Branch: refs/heads/master Home: https://github.com/LinuxCNC/linuxcnc Commit: db60dc6becf498482e2ccf78c1eb3b5a7f43c3ce https://github.com/LinuxCNC/linuxcnc/commit/db60dc6becf498482e2ccf78c1eb3b5a7f43c3ce Author: Luca Toniolo <107...@us...> Date: 2026-09-18 (Fri, 18 Sep 2026) Changed paths: M src/emc/task/emctaskmain.cc M tests/kins-switch/test-ui.py M tests/kins-switch/test.ngc Log Message: ----------- task: a kinematics selection is seen on the next line, and the test reads it there (#4563) * task: do not sleep a cycle after a kinematics switch or a cleared wait 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. * tests: kins-switch reads the kinematics on the line after the selection 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 (#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 #4560. To unsubscribe from these emails, change your notification settings at https://github.com/LinuxCNC/linuxcnc/settings/notifications |