Peculiar behavior with inverse time mode

Under certain circumstances, inverse-time mode appears to improperly interpret the feed rate parameter. Consider the following example:

g20 (units are inches)
g90 (absolute distance mode)
g93 g1 x0.880000 z0.050000 c0.00 f22.73
g93 g1 x0.880000 z0.025000 c0.00 f800.00
g94 g1 x0.880000 z0.000000 c-0.00 f4.00
g93 g1 x0.880000 z-0.000000 c-0.03 f39000.00
g93 g1 x0.880000 z-0.000000 c-0.06 f39000.00
g93 g1 x0.880000 z-0.000001 c-0.08 f39000.00
g93 g1 x0.880000 z-0.000001 c-0.11 f39000.00
g93 g1 x0.880000 z-0.000002 c-0.14 f39000.00
g93 g1 x0.880000 z-0.000003 c-0.17 f39000.00
g93 g1 x0.880000 z-0.000003 c-0.19 f39000.00
g93 g1 x0.880000 z-0.000005 c-0.22 f39000.00
g93 g1 x0.880000 z-0.000006 c-0.25 f39000.00
g93 g1 x0.880000 z-0.000007 c-0.28 f39000.00
g93 g1 x0.880000 z-0.000009 c-0.30 f39000.00
etc.

The motion is extremely slow (like a half minute per step). By comparison, the following code works at the expected speed:

g20 (units are inches)
g90 (absolute distance mode)
g93 g1 x0.88000 z0.05000 c0.00 f22.73
g93 g1 x0.88000 z0.02500 c0.00 f800.00
g94 g1 x0.88000 z0.00000 c-0.00 f4.00
g93 g1 x0.88000 z0.00000 c-0.03 f39000.00
g93 g1 x0.88000 z0.00000 c-0.06 f39000.00
g93 g1 x0.88000 z0.00000 c-0.08 f39000.00
g93 g1 x0.88000 z0.00000 c-0.11 f39000.00
g93 g1 x0.88000 z0.00000 c-0.14 f39000.00
g93 g1 x0.88000 z0.00000 c-0.17 f39000.00
g93 g1 x0.88000 z0.00000 c-0.19 f39000.00
g93 g1 x0.88000 z0.00000 c-0.22 f39000.00
g93 g1 x0.88000 z0.00000 c-0.25 f39000.00
g93 g1 x0.88000 z0.00000 c-0.28 f39000.00
g93 g1 x0.88000 z0.00000 c-0.30 f39000.00
etc.

The manual states "In inverse time feed rate mode, an F word means the move should be completed in [one divided by the F number] minutes." So both cases should work at the same speed.

My application is a ornamental lathe with XZ stage and a stepping motor driving the spindle of the lathe for precise rotational control (connected to the C-axis). The XZ stages have 1.8 degree steppers with 10TPI lead screw and 10 micro-stepping Gecko G540 drivers. This gives 20,000 micro-steps per inch (1 micro-step = 0.00005"). The C-axis has a 6.5:1 ratio timing belt drive giving 13,000 micro-steps per rotation (1 micro-step = 0.0277 degrees). My reason for using inverse time mode is so that the spindle rotates at a constant speed and so that I can generate g-code that won't interpret the feed rate as degrees/minute in the event that neither the X nor Z stage moves.

It appears that EMC is getting confused when I give it the z-coordinate that is not an exact multiple of one micro-step. Going from z-0.000001 to z-0.000002 does not cause any actual movement because the distance is much less than one micro-step. Yet EMC has slowed down the feed rate in spite of the fact that I'm in inverse time mode.

When I edit the g-code so that all coordinates are exact multiples of my resolution (0.00005"), then everything works OK. However, I hate having to generate g-code that is specific to my hardware implementation. Any ideas what's causing this? More importantly, how to work around the problem?

Would you be able to use G95 for the rotary moves?
linuxcnc.org/docs/html/gcode_main.html#sub:G93,-G94:-Set

Rick G

Yes, I've considered that. I would have to write some software that weeds out those instructions that don't actually cause a move in X or Z with my particular hardware and resolution and covert to G95. It would have been nicer if EMC2 implemented inverse-time mode properly. The whole point of inverse-time mode is to make the movement in the given time no matter what movement (or lack of movement) exists for any of the given axes. (Providing you don't exceed the max limits you've specified in the config file, of course).

Is it possible that you are just running into some limts because of the
high block rate you are imposing (1/39000 minutes = ~1.5 ms per block)

That's a good observation. Later today, I'll increase the time by a factor of 10 (without doing actual cutting) and see what happens.