[85vmh]

A GUI cannot tell from stat whether the move in progress is a thread, nor its pitch: a G33 or G76 pass reports EMC_MOTION_TYPE_FEED like any G1, and the live backplot draws it as a plain feed. Showing the threads as threads in the backplot, or the pitch being cut while a program runs, needs the spindle synch of each move, which the planner already has in the TC in progress.

threading.webm

stat gets three fields:

• spindle_sync_mode: how the move in progress follows the spindle, SPINDLE_SYNC_NONE, SPINDLE_SYNC_VELOCITY (G95 feed per revolution) or SPINDLE_SYNC_POSITION (G33, G33.1, G76).
• spindle_sync_pitch: machine units the move advances per spindle revolution, 0 when it is not synchronized.
• spindle_sync_index_pulse_angle_offset: the angle in degrees past the spindle index pulse the synch started at, the D word of G33 or G76, 0 when there is none.

The planner fills them from the TC in progress in
tpUpdateMovementStatus() and clears them when there is none; task copies them into EMC_TRAJ_STAT. TC_SYNC_* now take their values from the new EMC_SPINDLE_SYNC_* in motion_types.h, so the mode is reported as is, and the linuxcnc module exports the three constants.

linuxcnc.positionlogger takes a keyword-only sync=True, for the live backplot. Such a logger keeps a 12 byte logger_sync (mode, pitch, index_pulse_angle_offset) beside each point, returned by the new sync_points() with the same indices as points(), and starts a new point whenever the synch changes, so a synched move is not merged into a colinear move before it. Without sync=True, which is what every existing GUI does, it logs exactly as before and sync_points() returns None. The extra buffer costs 12 bytes a point, 1.2 MB at the 100000 point limit.

The fields and sync_points() are documented in python-interface.adoc.

Test: tests/motion/spindle-sync-status runs one move of each synch kind (G94 G1, G95 G1, G33 with D, G76 with D and both tapers), checks stat while it runs, and checks two loggers made with and without sync=True.