I know about this and have dealt with it quite a bit. In my case I needed to direct-drive a stepper as a lathe axis for very light stock and wanted to move around while keeping the A-axis moving constantly. And call the A-unit a "rotation".

One, the format of G-code will have some problems with the concept.

Two, Mach3's brain will trash itself because of a numerical integrity bug in the acceleration rules. It will corrupt its numbers and create software-originated stalls. At least, I ran into it and dissected the problem to no end.

Allow me to explain.

Say you do tune one rotation= 2000 pulses on a 10-microstep G540.

The G-code problems:

Say you want to rotate at 800 RPM for 1 sec. You can simply type **G1 A[800] F800**, but that's not interesting, it goes nowhere.

OK so I want to move to X=1 at 5 ipm. BTW, Motor Tuning has X-jog limited to 50ipm.

**G1 X1 A800 F800**

Oh wait. How many rotations did I really want? How far did I go? The line doesn't say. Let's say I just *know* that I started at X=0. So the travel should take 1/5th a min and 1/5th of 800 rotations in a minute is 160. Uhhh... ok, so **G1 X1 A160 F800**?

But the Feedrate is not exactly correct. In fact how does Feedrate work? How would I get 5ipm? Well, I know it limits XYZ on the basis on sqrt(X^2+Y^2+Z^2). But rotational axis is something totally different. As best I can tell it squares and sums it as well, even though this is a meaningless folly in reality. That's not a Mach3 thing it's a G-code shortcoming. So you'd have to calculate out a feedrate=sqrt(5^2+800^2)=**F800.0156** wait, that basically means the X-axis speed can't be controlled with Feedrate because it has no effect. RIGHT, the idea doesn't work for combining numerically small XYZ feedrates with numerically high rotational rates. You want to say **G1 X1 A160 F800** and adjust the number of spindle rotations it takes to get from point A to point B. This becomes less accurate if high linear travel rates come into play and you may have to write in the Feedrate= sqrt(x-movement^2+y-movement^2+z-movement^2+800^2) equation AND adjust the number of revolutions it takes to get there.

The number of revolutions will build without limit. Say the first move is:

**G0 X0 Y0**

**G1 X1 A160 F800** and the second move is

**G1 Y1 A160 F800**

This is wrong because the A is absolute, not incremental (unless you put the whole darn thing in inc mode, the structure of G-code does not allow you to make only one axis incremental). So next 1in move is A320, next is A480, etc.

You can periodically reset it with G92 A0. BUT, G92 takes all axes to a full stop and like a 1 sec pause due to a Mach3 implementation limitation. So you can't use it between successive instructions. The finish would be bad and it will take forever.

The Mach3 problem:

I found that when G-code gives lines with a very high ratio of delta-A to XYZ motion, there is about a 2% chance of an super-stall on any given line in Constant Velocity mode, even if the RPM is supposed to be constant and there is not even a big change in speed and direction on the XYZ axes. It will not only stall the A-axis but potentially can stall any of the XYZ axes at the same time, despite being at low speed. And it doesn't happen because A grew really really large. I had it happen when A was near 0. The problem likely originates from the obscenely high Feedrate needed to set the RPM creating an error in its internal velocity number and it somehow passes along an erroneous change in XYZA velocities that completely ignores the Motor Tuning acceleration. Exactly where it happens in the code is completely random but will always happen at the same point in the code unless you change something. It really surprised me though that the corruption did not always involve only the A-axis but sometimes the X-axis which was barely even moving before or after, and had a modest acceleration limit.

This is a bear to workaround. But there IS a workaround. The A-numbers in all the G-code lines have to be made numerically smaller. Basically you gotta make the number of pulses per A-unit 10x or 100x larger in the Motor Tuning, and change max speed and acceleration as well. Then you use numbers in the A-field 10x or 100x smaller. Funny because this asks for the exact same movement in the end, but it puts delta-A on the same order of magnitude as delta-XYZ fields more sensible and the stalls will stop. Downside here is that when the magnitude of A travel approaches the magnitude of XYZ travel then "the Feedrate (F-field)=rpm alone, and set the XYZ feedrate by changing the number of A-rots in that line" may not cut it.

Yeah, as you can see, I've "been there".