G93 rotary moves with a very small linear move run too fast.

[andypugh]

Reported on the Forum: https://forum.linuxcnc.org/20-g-code/48607-g93-strange-behavior#267629

This G-code works properly, lines N30 and N40 both run at 14.9 deg/sec

N00 G0
N10 Y0. Z1.3005
N20 G1 F100
N30 G93 A178.639 F5
N40 A357.443 F5
N50 M2

This code does not work properly,

N00 G0
N10 Y0. Z1.3005
N20 G1 F100
N30 G93 A178.639 F5
N40 Z1.3003 A357.443 F5
N50 M2

N30 runs at 14.9 deg/sec but N40 runs at the A axis velocity limit. The difference is the very small Z axis move of 0.0002 units.

This can be easily reproduced in the sim-axis-axis9axis configuration. Reported in 2.9 on Debian 12 and tested on 2.8.4 Buster.

@robEllenberg Have you seen this?

[andypugh]

Is this the same as #1738 ?

[andypugh]

Some pointers from Rob Ellenberg:
"We found / fixed a similar issue in PathPilot. In our case, the problem was that interp, canon, and motion didn't agree on how small the XYZ component of motion had to be before treating it as a pure angular move. If canon treated it as a pure angular move, but motion though it was linear+angular, then the computed feed would be too high. My particular fix takes advantage of some changes we made for 9 axis blending, but I don't think you would need that to fix it in linuxcnc. The PathPilot TP / canon does some of its planning in abstract path distance / velocity units along all axes at once to avoid that ambiguity.

I think it's possible to fix it in linuxcnc by checking that the "tiny" distance cutoff matches in interp, canon, and motion for computing feed rates, it should be something like 1e-7. Another complication is that interp works in progam units, so if interp uses a constant, that threshold is effectively smaller for mm than inches. The "tiny" distance cutoff should ideally be based on user units and then converted to canon / program units for use in canon / interp respectively.
"

[andypugh]

@robEllenberg The fix to this one seems too simple. So I am wondering what I am missing.

Relevant code: https://github.com/LinuxCNC/linuxcnc/blob/2.8/src/emc/rs274ngc/interp_convert.cc#L4442
"In inverse time feed mode, a lower bound of 0.1 is placed on the feed"

Which actually happens here:
https://github.com/LinuxCNC/linuxcnc/blob/2.8/src/emc/rs274ngc/interp_inverse.cc#L65

rate = std::max(0.1, (length * block->f_number));

In this case, with a linear move of 0.002mm and a feed of 5, the rate is calculated as 0.1 instead of .001, and the move runs at 0.006 linear speed (limited by the rotary joint max speed of 90 deg/sec)[1]

So, the fix seems to be a little more intelligent about how we handle a zero-length segment. The good news is that we don't care how wrong the feed rate is on a zero-length segment.

[1]Massively increasing the rotary axis accel and speed was enough to get the programmed linear velocity of 0.1

[andypugh]

Fixed via b244b37