Skip to content

G33/G33.1: no check that pitch x spindle speed stays within machine limits #4391

Description

@grandixximo

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:

  1. 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.
  2. 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.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions