You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Warn users that spindle is too fast in G33 / G95 #167
Here are the steps I follow to reproduce the issue:
Have a machine with a slow K axis (ex. max velocity = 60ipm)
Run the following G code snippet
M3 S1000
G0 X0 Z1
G33 Z0 K0.1
M5
M2
This is what I expected to happen:
Some form of warning that the machine can't reach the required feed rate. To execute that motion properly, the Z axis needs to move at 1000 rpm * 0.1 in / rev = 100 ipm (greater than my example limit of 60 ipm).
This is what happened instead:
The cut proceeds without complaint, and cuts the wrong thread pitch.
It worked properly before this:
Probably never, but this seems to have been an issue with 2.6.x as well.
Information about my hardware and software:
Use a simulation config with a slow Z axis (the stock axis simulator will work).
Pop up an operator error dialog if the spindle speed is too fast for the axis limits
Attempt to reduce the spindle speed to a safe speed by issuing a new speed command before the sync motion starts. Obviously this does nothing if the spindle is manually controlled or fixed speed.
It's not ideal because the warning only appears right before the cut starts, but at least the user will have some feedback this way.
@robEllenberg, I took your new branch for a little spin (no pun intended). The warning message looks great.
My branch has been rebased onto yours with some updates. The unit test is cleaned up and uses your modified sim_spindle_encoder.hal. The preview-time check discussed on emc-developers has been implemented. It is similar to the "Program exceeds machine maximum on X" warning in that it uses the same warning dialog, it can only be used in python GUIs, and is only implemented in Axis.
Between your branch and mine, the checks are implemented as described in that discussion, except no warning is raised when the spindle never reaches speed, which isn't important to me. Thanks for the great work, Rob!
Actually, I think the warning "Reducing spindle speed from XXXX to YYYY for synched motion" Rob added is even better than my proposal to raise a warning when the target spindle speed is never reached, since it's enough information for users with fixed-speed spindle to figure out the reason for the hang, and it's more straightforward. Nice work!
I came across this problem today (current Master branch) when using G76.
I was getting inconsistent thread pitches on a lathe I just retrofitted. Eventually slowed my spindle speed right down and the thread worked. I then deduced that my commanded RPM x thread pitch (the required axis movement speed) was greater than my axis maximum velocity (which I had set somewhat low for initial testing).
I would have expected a warning.
This situation is likely to be encountered when constant surface speed (G96) is in effect, as the RPMs are set based on work diameter.
A warning would have saved quite a bit of time! Fortunately I was just doing test parts.
@SebKuzminsky I sure don't see a PR anywhere. This might've been back when PRs were new (at least to me) for LCNC coming from glo, and the work is still only in personal github repos.
Unless someone else wants to put together a PR first, it'll probably be a while before I can really sit down with this (and state tags), but it'll definitely go onto the list.
A PR against 2.7 is in #479. I didn't repeat any review as @robEllenberg and I did in 2017-03, but the patch still merges cleanly, and the regression test still passes on Travis CI.
Activity
robEllenberg commentedon Oct 2, 2016
I have a fix in progress here:
https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/nominal-vel-during-sync
It does two things:
It's not ideal because the warning only appears right before the cut starts, but at least the user will have some feedback this way.
zultron commentedon Jan 21, 2017
Extra documentation on this issue here and here on the EMC-developers list.
zultron commentedon Jan 21, 2017
Nice, the above-linked branch passes my regression test by scaling spindle speed. See the top commit in this branch.
robEllenberg commentedon Jan 27, 2017
Updated branch here with some fixes:
zultron commentedon Feb 9, 2017
@robEllenberg, I took your new branch for a little spin (no pun intended). The warning message looks great.
My branch has been rebased onto yours with some updates. The unit test is cleaned up and uses your modified
sim_spindle_encoder.hal. The preview-time check discussed on emc-developers has been implemented. It is similar to the "Program exceeds machine maximum on X" warning in that it uses the same warning dialog, it can only be used in python GUIs, and is only implemented in Axis.Between your branch and mine, the checks are implemented as described in that discussion, except no warning is raised when the spindle never reaches speed, which isn't important to me. Thanks for the great work, Rob!
zultron commentedon Feb 9, 2017
Actually, I think the warning "Reducing spindle speed from XXXX to YYYY for synched motion" Rob added is even better than my proposal to raise a warning when the target spindle speed is never reached, since it's enough information for users with fixed-speed spindle to figure out the reason for the hang, and it's more straightforward. Nice work!
zultron commentedon Mar 2, 2017
It looks like the fix in #180 clashes with 985bb4e. I'll take a look when I get some time.
Unit test for maxvel violations in spindle-synched moves
andypugh commentedon Aug 8, 2017
Is this merged? Can it be closed?
zultron commentedon Aug 8, 2017
This hasn't been merged, and is in limbo until someone decides whether to merge the change or not.
pippin88 commentedon Oct 20, 2017
I came across this problem today (current Master branch) when using G76.
I was getting inconsistent thread pitches on a lathe I just retrofitted. Eventually slowed my spindle speed right down and the thread worked. I then deduced that my commanded RPM x thread pitch (the required axis movement speed) was greater than my axis maximum velocity (which I had set somewhat low for initial testing).
I would have expected a warning.
This situation is likely to be encountered when constant surface speed (G96) is in effect, as the RPMs are set based on work diameter.
A warning would have saved quite a bit of time! Fortunately I was just doing test parts.
rene-dev commentedon Jul 31, 2018
any reason this is not merged?
SebKuzminsky commentedon Jul 31, 2018
Is there a PR that combines @robEllenberg's fix with @zultron's test?
zultron commentedon Jul 31, 2018
@SebKuzminsky I sure don't see a PR anywhere. This might've been back when PRs were new (at least to me) for LCNC coming from glo, and the work is still only in personal github repos.
Unless someone else wants to put together a PR first, it'll probably be a while before I can really sit down with this (and state tags), but it'll definitely go onto the list.
zultron commentedon Aug 2, 2018
A PR against 2.7 is in #479. I didn't repeat any review as @robEllenberg and I did in 2017-03, but the patch still merges cleanly, and the regression test still passes on Travis CI.
Before run, warn if spindle-synched move violates axis limits
interp: reject a thread pitch the axes cannot follow
BsAtHome commentedon Sep 13, 2026
Fixed with #4441.