Thanks for taking the time to look at this. It was a good suggestion to set the rotation diameter for the C axis in g94 mode. Unfortunately, that didn't change anything when running in g94 mode.

After a few more experiments, I conclude that g93 (inverse time mode) is not intrinsically the issue. Here's why -- consider the following code:

g20 (units are inches)

g90 (absolute distance mode)

g93 g1 x0.31761 z0.16371 c0.00 f60.00

g94 g1 x0.35899 z0.07267 c-0.00 f2.00 (this is purposely set slow)

g93 g1 x0.35905 z0.07255 c-0.55 f650.00

g93 g1 x0.35925 z0.07215 c-1.11 f650.00

g93 g1 x0.35955 z0.07145 c-1.66 f650.00

g93 g1 x0.36000 z0.07050 c-2.22 f650.00

g93 g1 x0.36050 z0.06930 c-2.77 f650.00 (works just fine for about 340 lines)

etc.

This first example works just fine for a while. The Queue depth goes up to 31 (LookAhead is set at 50) during the slow movement on line #4. There is nice smooth motion for a while, and the queue depth slowly erodes down to zero after about 340 lines of g-code. At this point I get the jerky (start/stop) movement.

Consider the 2nd example:

g20 (units are inches)

g90 (absolute distance mode)

g93 g1 x0.31761 z0.16371 c0.00 f60.00

g94 g1 x0.35899 z0.07267 c-0.00 f2.00 (this is purposely set slow)

g93 g1 x0.35905 z0.07255 c-0.55 f2000.00 (same points as above, but about 3X faster)

g93 g1 x0.35925 z0.07215 c-1.11 f2000.00

g93 g1 x0.35955 z0.07145 c-1.66 f2000.00

g93 g1 x0.36000 z0.07050 c-2.22 f2000.00

g93 g1 x0.36050 z0.06930 c-2.77 f2000.00

etc.

The first 4 lines are the same, then the speed is about 3X faster for subsequent point. As before, the queue depth goes up to 31 during the slow movement on line #4. Then it quickly drops to zero after about 50 lines of code (and jerky start/stop motion).

So I thought that the faster feed rate might be the problem, but not so. Consider the 3rd example:

g20 (units are inches)

g90 (absolute distance mode)

g93 g1 x0.31761 z0.16371 c0.00 f62.97

g94 g1 x0.35899 z0.07267 c-0.00 f2.00 (this is purposely set slow)

g93 g1 x0.35900 z0.07265 c-0.06 f6500.00 (the points are 10X finer resolution, with 1/10th the time)

g93 g1 x0.35900 z0.07265 c-0.11 f6500.00 (which should result in the same over-all speed as the first example)

g93 g1 x0.35900 z0.07265 c-0.17 f6500.00

g93 g1 x0.35900 z0.07265 c-0.22 f6500.00

g93 g1 x0.35900 z0.07265 c-0.28 f6500.00

etc.

Again, the first 4 lines are the same. Then I give it points with 10X finer resolution (at 1/10th the feed rate -- inverse time remember). So the over-all speed should be just the same as the first example, but with finer resolution. As before, the queue depth goes up to 31 during the slow movement on line #4. Then it quickly drops to zero after about 30 lines of code (and jerky start/stop motion).

I conclude from this that issue is that Mach3 can't keep up with the lookahead calculations that are required to plan the acceleration/deceleration for smooth operation and coordinated motion.

Any other things that I can try? It brings me back to my earlier question about the possibility of giving the LookAhead calculations a bigger chunk of the processor or run it in a different thread? Is there some way to shut down other non-critical real-time activities?