Something goes horribly wrong in mach 3 mill when I run this code:    At the bold line, it tries to make the Z move instantaneously.  you can hear the stepper motor stall and watch the z value change instantly (even when setting the feed override to 10%) on the readout.    I suspect something is wrong with the code that is confusing mach, but I also consider it a safety issue if mach can suddenly decide to ignore the motor tuning settings due to some quirk of gcode.

the mach version is: 3.039.  If it has been fixed in a later version, then it will be worth the trouble to upgrade.  Any ideas folks?

G01 Z.02
G03 X-9.8916 Y-.835 I-9.9155 J-.8588
X-9.8917 Y-.8349 Z-.06 I-9.9394 J-.8826
G01 X-9.9019 Y-.8265 Z-.0625
X-9.9136 Y-.8203 Z-.065
X-9.9262 Y-.8164 Z-.0675
X-9.9394 Y-.8151 Z-.07
G03 I-9.9394 J-.8826
G01 X-9.9494 Y-.8158
X-9.9591 Y-.818
G03 X-9.9395 Y-.8827 I-9.9493 J-.8504
G01 X-9.9394
G00 Y-.8826 Z.25
Z.5


thanks
Greg

I seem to remember  an issue a while back with something similar to the move you are doing. It was Ray (HimyKabibble)that found it and it only happened if your Z axis was significantly slower than your other axis.
 If I recall the acceleration of the Z was ignored and Mach attempted to move the axis with the rates of the faster X and Y.
Is that the case with your Z?
Hood

I think it's related to G64. Try it in Exact Stop mode.

my axes feed rates are the same (max of 13ipm).  Unfortunately, exact stop mode is useless to me for what/how I cut.  if I have to run in exact stop mode then I will have to switch to different software or stop using the helical interpolation routines (latter probably the better option).

I'd seen this before on a much older version of mach, and it went away when I upgraded to 3.039, but this is the first time I'd seen it here.  it is not picking one of the other axes feedrates, it is quite literally instantaneously jumping (or trying to) between the start and end Z.  it is trying to move the Z faster than mach can even pulse at (25khz, 32k steps per inch).

Is that a full circle, or an an arc that's .0001" long? If it's a really short arc, that's probably what's causing the problem.

it should be half of a helix. 

that being said, the plot thickens.. (here is what appears to be confusing old mach, I think it may be worth the upgrade hassle).  I installed the newest mach version on my non-machine attached computer.  plugged in that Gcode, and actually get an error when I plug in that copied section of code:

Radius to end of arc differs from radius to startLine 1

now if I open the whole code file, it does not give that error, even though the gcode through that particular section is identical.  something weird is going on.

You need another line of code before that one.

apparently.    I cut out one too many lines o marked code. 

G00 G17 G20 G40 G49 G80 G90
G00 Z.25
Z.5
X-9.9394 Y-.8826
Z.1
G01 Z.02
G03 X-9.8916 Y-.835 I-9.9155 J-.8588
X-9.8917 Y-.8349 Z-.06 I-9.9394 J-.8826
G01 X-9.9019 Y-.8265 Z-.0625
X-9.9136 Y-.8203 Z-.065
X-9.9262 Y-.8164 Z-.0675
X-9.9394 Y-.8151 Z-.07
G03 I-9.9394 J-.8826
G01 X-9.9494 Y-.8158
X-9.9591 Y-.818
G03 X-9.9395 Y-.8827 I-9.9493 J-.8504
G01 X-9.9394
G00 Y-.8826 Z.25
Z.5
M05
G90
M30

would you mind loading that up in mach set to absolute coordinates for circles (I am hoping that someone else can replicate the error).   in my preview it now shows a vertical line connecting two arcs, not a helix as it should be.  and if you run it and watch Z, you can see it jump.  It really does look like the gcode is really bad, but I would like to find a way to find out before a part gets screwed up.   

It's treating that arc as a .0001 arc, which makes it plunge straight down

interesting.  plunge down it does, at an infinite feed rate.  even if it slowed down and did that move with a normal feed rate it would work ok without screwing up the zero.   At least I knda know what to look for, too bad it won't error out on me when it tries to move faster than it theoretically can.