Repository navigation
G33/G33.1: no check that pitch x spindle speed stays within machine limits #4391
Description
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_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. - 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.
Activity
Sigma1912 commentedon Aug 17, 2026
See also #167
BsAtHome commentedon Aug 17, 2026
While you are at it,... Maybe we can fix #164 too? The Zaccel jitter in G33 still happens today in master:
grandixximo commentedon Aug 17, 2026
Yeah, I looked at those @Sigma1912 you have a lathe you can test on?
Sigma1912 commentedon Aug 17, 2026
Well, it's not a lathe but it's real hardware with feedback on all axes. So, using halscope, it should be good enough to test:
andypugh commentedon Aug 17, 2026
Note that #581 claims to include a fix for this.
BsAtHome commentedon Aug 17, 2026
Yes,but which of the 283 files of that PR does include the fix? It mentions that Rene would be willing to try sort it out (4 years ago). My guess is that we could probably find a fix faster by looking at the problem than looking at that PR :-)
pcw-mesa commentedon Aug 22, 2026
Is any of this related to the bug that the target thread position is mis-caculated so that it
has a spindle speed dependent Z offset?
grandixximo commentedon Aug 22, 2026
Not directly, no. This work changes the velocity command law inside the position sync tracking loop, which is what caused the servo-rate acceleration jitter, and adds limit checking on the pitch and spindle speed combination. It does not touch how the sync start point is computed against the index pulse.
A speed dependent Z offset at the thread start would come from the lead-in instead: the axis starts from rest at the index and needs roughly v squared over 2a of distance to reach the synchronized velocity, so it lags during that ramp, and the length of the lag scales with the spindle speed. That is a separate mechanism from the one fixed here.
One caveat on that answer: the old correction law over-corrected and limit cycled at the servo rate, so its mean tracking error was not the same as the new law's. If the offset you mean is a steady state offset rather than a start offset, the new law could well move it. I have not measured for one, so I am not claiming either way.
If you have an issue number or a test case for it, point me at it and I will look separately.
Edit:
Found #3455
interp: reject a thread pitch the axes cannot follow
motion: fault when the spindle outruns a synchronized move
robEllenberg commentedon Aug 24, 2026
grandixximo commentedon Aug 24, 2026
Thank you for the input, I think some refinement is in place once the fixes land, does this have to be blessed by @andypugh ?
grandixximo commentedon Aug 24, 2026
On the exact-stop spike: #4441 sidesteps that by not testing position error at all. The overrun fault measures spindle revolutions over a 0.25 s window times the pitch, and only arms once the axis is already pinned at 99% of its max velocity. At the end of an exact-stop G33 the axis is decelerating, so it never arms. Error-based detection was the first thing I tried, and the entry lag alone is many times larger than any sane threshold, which is what pushed me to the demand-based test.