Warn users that spindle is too fast in G33 / G95

[robEllenberg]

Here are the steps I follow to reproduce the issue:

1. Have a machine with a slow K axis (ex. max velocity = 60ipm)
2. 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).

[robEllenberg]

I have a fix in progress here:

https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/nominal-vel-during-sync

It does two things:

1. Pop up an operator error dialog if the spindle speed is too fast for the axis limits
2. 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.

[zultron]

Extra documentation on this issue here and here on the EMC-developers list.

[zultron]

Nice, the above-linked branch passes my regression test by scaling spindle speed. See the top commit in this branch.

[robEllenberg]

Updated branch here with some fixes:

• New spindle sync algorithm that seems to have less ripple with high resolution encoders (needs testing to confirm)
• Fixed interaction with blending / position sync motion
• Inform the user via a GUI info message if the spindle speed is being reduced.

[zultron]

@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]

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]

It looks like the fix in #180 clashes with 985bb4e. I'll take a look when I get some time.

[andypugh]

Is this merged? Can it be closed?

[zultron]

This hasn't been merged, and is in limbo until someone decides whether to merge the change or not.

[pippin88]

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]

any reason this is not merged?

[SebKuzminsky]

Is there a PR that combines @robEllenberg's fix with @zultron's test?

[zultron]

@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]

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.