After much troubleshooting I have boiled my problem down to the following:  When attempting to execute a rapid involving 2 or more axis, IF one of the axes is making a very small move (<.020" say) while the other axis is making a larger move, the axis making the larger move will stall. Every time. I extracted the following code from a troublesome program to test the problem:

G1 X0.3382 Y1.8169 F20
G0 Z0.125
G0 X0.3359 Y0.522
G1 X0.3382 Y1.8169
G0 Z0.125...

rinse repeat.  That move from X0.3382 to X0.3359 is causing the problem. Change that to a larger X move and the problem vanishes completely. It is the act of making a very small move on one axis while making a larger move on the other axis that gives me trouble. Changing the length of the longer move has no affect.  

I have written programs to exercise the mill in all axis motion. Rapids of varying lengths; can literally run all day without missing a single step at max speed.  As soon as I try and rapid with a move that has a high aspect ratio between any two axis I get a motor stall.  I dont seem to be lacking for power supply power or stepper torque, as I can rapid all of the motors at once without issue and I can mill at a respectable rate under load without issue.

I have disabled networking, disabled sound card, disabled all system sounds... I'm really just running mach3 at this point.

I have replaced my parallel breakout board. I have replaced my parallel cable with a shorter cable (suspecting some kind of EMF related issues). No joy.

Cranking down my rapid speeds to a crawl does NOT alleviate the problem. Changing my backlash %ofmax number does not alleviate the problem. I have had limited success with changing my acceleration rate, but its very much hit or miss. If I change my acceleration rate to something very low (say 5 IPM/M) it will periodically succeed at executing the test code. Again, note that rapids testing cannot reproduce this problem with ANY acceleration rate so long as the moves are not of high aspect ratio.  I normally rapid at 90 IPM and accelerate at about 30 IPM/M and this has historically caused me no problems.  

I am running keling 4030 stepper drivers at 36 volts feeding some NEMA23 steppers on an X2 mill.  I have switched to a C35 breakout board using sheilding twisted pair network cables to talk to the stepper drivers (again, in suspicion of EMF noise of some sort).  Did not change the problem.

I do not have a way to intercept and monitor the pulse stream coming out of the PC or out of the breakout board so I dont know if the stream is somehow corrupted.

I tried this on a different PC and got the same result, so it doesn't SEEM to be linked directly to the PC parallel interface.

Anyone ever seen anything like this? Any ideas?  Maybe some sort of cross talk in the hardware? Software bug?

Thanks for considering

have you tried it with a lower rapid speed like 50 ipm

Yes, as I mentioned I can crank my rapids down to a crawl (less than 10ipm) and still get a problem.  :\

it doesn't seem to be related to inertia or motor power type issues

sorry i must have missed that bit.

no worries, I've done a lot of troubleshooting and my presentation may not be the most coherent story!

Also, please note that while I have my nominal rapid rate set to 90 ipm, the machine is actually capable of significantly more (>120 ipm) I just have it de-tuned for conservatism sake.

what are the microsteps set at, and do you have the steppers driving the ballscrew direct. Is it a ballscrew or a leadscrew.

Ballscrews
16000 steps/inch
Toothed belt connection
pulleys turn freely by hand when not connected to steppers, have not been able to detect any manner of mechanical binding in my examining the motor installs/belt tension etc.

I forget the microstepping I have the drivers set to as it has been several years since I first set it up, but yes they are microstepping

Also, the pulleys are such that the motors are geared down, ie slower movement of the screw as compared to the motor; again I forget the exact ratio but iirc its on the order of 2:1

I've experienced a similar (same) issue, but thought it was my controls.  Try changing the G0s to G1s to see if the problems goes away.  I've not had another recurrence since eliminating G0s in my code.

I first experienced this issue when I switched to the later versions of M3 (.058+ ?) so I could use M10/M11 commands with my laser diode machine.

I do believe it is a Mach3 bug.

John Champlain

I just tried it again by replacing all G0's directly with G1's (ie keeping the previous feedrate). Works fine, no stalls.

I went a step further and replaced the g0's with G1 F90 moves... stalls

so with a g1 at the same rate as a g0 it will still stall