Problem
G33 and G33.1 derive the axis feed from the K word (pitch) times the spindle speed. Nothing checks that the resulting feed stays within machine limits. If pitch x RPM asks for more than the axis can deliver, the program is not rejected and no message is issued; the trajectory planner simply clamps velocity, the axis lags the spindle, and the thread is ruined (or a following error trips).
The interpreter checks only that the spindle is turning (src/emc/rs274ngc/interp_convert.cc, convert_straight_move, G_33 / G_33_1 cases). There is no velocity feasibility check anywhere on that path.
Why this is not a one-line fix
The interpreter has no access to trajectory or axis velocity limits, so the check cannot live next to the existing "spindle not turning" errors. Options:
- Task/canon-side check: when
START_SPEED_FEED_SYNCH is queued, compare |K| x current spindle RPM / 60 against traj max velocity and abort with a clear error. Needs the active spindle's commanded speed at that point, which task has.
- Motion-side runtime response: instead of silently clamping, raise a distinct fault ("spindle-synchronized move exceeds axis limits") so the user learns why the thread failed, rather than a generic following error.
Either way the check involves runtime spindle state, so exact-time-of-check semantics need a decision (S word at interp time vs. actual spindle speed at motion start, especially with spindle-at-speed logic).
Note
Current behavior is now documented in the G33/G33.1 sections of the G-code manual (see #4349). This issue tracks whether a code-side check or fault is wanted on top of that.
Problem
G33 and G33.1 derive the axis feed from the K word (pitch) times the spindle speed. Nothing checks that the resulting feed stays within machine limits. If pitch x RPM asks for more than the axis can deliver, the program is not rejected and no message is issued; the trajectory planner simply clamps velocity, the axis lags the spindle, and the thread is ruined (or a following error trips).
The interpreter checks only that the spindle is turning (src/emc/rs274ngc/interp_convert.cc,
convert_straight_move, G_33 / G_33_1 cases). There is no velocity feasibility check anywhere on that path.Why this is not a one-line fix
The interpreter has no access to trajectory or axis velocity limits, so the check cannot live next to the existing "spindle not turning" errors. Options:
START_SPEED_FEED_SYNCHis queued, compare|K| x current spindle RPM / 60against traj max velocity and abort with a clear error. Needs the active spindle's commanded speed at that point, which task has.Either way the check involves runtime spindle state, so exact-time-of-check semantics need a decision (S word at interp time vs. actual spindle speed at motion start, especially with spindle-at-speed logic).
Note
Current behavior is now documented in the G33/G33.1 sections of the G-code manual (see #4349). This issue tracks whether a code-side check or fault is wanted on top of that.