I am working on a custom LinuxCNC UI and trying to understand whether EMC_TASK_PLAN_STEP can be given reliable “step completed” answer using only public LinuxCNC command/status/error channels.
The goal is not to step exactly one authored G-code source line. I understand LinuxCNC native step mode appears to operate on internal interpreter/motion boundaries, and these may not map 1:1 to G-code lines. Multiple G-code lines may combine into one motion item, and some lines such as modal changes or dwell may not produce motion identity changes.
What I am looking for is a public NML/status signal that reliably answers:
“The requested native step has reached its terminal boundary.”
I tested the following using command/status/error NML:
EMC_TASK_PLAN_STEP
EMC_TASK_PLAN_RUN
EMC_TASK_PLAN_PAUSE
EMC_TASK_PLAN_RESUME
EMC_TASK_PLAN_RUN from a specified line
status fields including task mode/state, interpreter state, exec state, task_paused, EMC_STAT.motion.traj.single_stepping, motion_line, current_line, read_line, motion_id, in-position, active file, command echo/serial, and the error channel.
Observed behavior:
EMC_TASK_PLAN_STEP in AUTO submits and echoes reliably.
EMC_TASK_PLAN_STEP in MANUAL also writes/echoes, then reports asynchronously through the error channel: can't do that (EMC_TASK_PLAN_STEP:511) in manual mode.
From idle/AUTO, the first PLAN_STEP appears to arm/pause state but does not expose line or motion advancement.
From paused queued motion, repeated PLAN_STEP can advance motion_line / motion_id, which is useful for motion items.
For dwell/non-motion cases, I did not find a reliable public line/motion/status transition that identifies completion of one native step.
EMC_STAT.motion.traj.single_stepping is public and useful, but it seems to represent persistent stepping mode/gate state. It can remain true after observed motion or non-motion boundaries, so it does not by itself delimit one requested step.
RUN -> PAUSE and RESUME -> PAUSE expose reliable running/paused transitions, but the amount of program read/queued/executed before pause takes effect is not bounded enough to call it a STEP.
RUN(line) -> PAUSE chooses a start line but does not provide a next-boundary terminal condition.
Looking at LinuxCNC task behavior, it seems the more precise native step gate may involve internal state such as steppingWait and steppedLine, but I do not see those exposed through public status.
My questions:
Is there an existing public NML/status field, Python linuxcnc.stat() field, or other supported API that indicates completion of one native EMC_TASK_PLAN_STEP request?
Is EMC_STAT.motion.traj.single_stepping intended only as a persistent stepping-mode flag, or can it be interpreted with other public fields to detect a completed native step?
Are steppingWait, steppedLine, or equivalent native step-boundary state intentionally private, or is there another public way to observe that same information?
For UI purposes, is it correct to expose EMC_TASK_PLAN_STEP only as a raw/native LinuxCNC step command without promising source-line or completion?
Is there a recommended command/status sequence used by AXIS, QtDragon, or other UIs to decide when a single native step has completed?
At this point, my conclusion is that PLAN_STEP can be exposed as a native control, but I should not claim reliable completion unless LinuxCNC exposes a per-request step boundary or stepped identity through public status. I would appreciate confirmation or correction from anyone familiar with the task/interpreter stepping internals.
Also, I wish there were a 'developer' forum where I could ask questions like these