Skip to content

task: program_units follows the executing G20/G21, like gcodes (#3627) - #4686

Open
tzuohann wants to merge 1 commit into
LinuxCNC:masterfrom
tzuohann:fix-program-units-3627
Open

tzuohann wants to merge 1 commit into
LinuxCNC:masterfrom
tzuohann:fix-program-units-3627

Conversation

@tzuohann

@tzuohann tzuohann commented Oct 15, 2026 •

Copy link
Copy Markdown
Contributor

Fixes #3627.

While a program runs, stat.program_units should match gcodes. Instead it follows the interpreter's read-ahead:

G21
G1 X25 F300   (while this runs: gcodes says G21, program_units says inches)
G20           (the interpreter has already read this line)
M2

Why: gcodes comes from the executing move; program_units was set only when the interpreter read the G20.

Fix: emcTaskUpdate (src/emc/task/emctask.cc) sets programUnits from the active G20/G21, as suggested on the issue. This keeps all C readers (linuxcncrsh, emcsh, shcom) consistent. Canon's write stays for canterp. Idle behaviour is unchanged.

Test: tests/program-units fails without the fix (every sample wrong: 670/670, 774/774, 853/853) and passes with it.

Related: #3657.

…CNC#3627)

program_units was only written by canon USE_LENGTH_UNITS, when the
interpreter read a G20/G21 -- often far ahead of motion -- while gcodes
reports the executing move. emcTaskUpdate now sets programUnits from the
active G20/G21 it has just computed. Canon's write stays for interpreters
that report no G20/G21 (canterp).

tests/program-units runs a 5 s G21 move followed by G20 on simulated
motion and fails if program_units disagrees with gcodes during the move.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Python Module program_units returns wrong code

1 participant