I have a 3 axis router contrlled through a Galil DMC2108 controller. The work surface is 97" x 49" with 6" of Z travel. Until recently this was used for small projects with travel if less than 24" and worked well. Recently I have G code to cut panels from full 4 x 8 sheets and during long travels the controller looses sync and the stepper motors makes that noise that it should not do and stops turning (the steps are out of sync).
I have tried to see what is causing this by using the Galil smart term and all I can see is that the count increases as the axis advances and suddenly the counter  jumps at the time the stepper starts to skip. This occurs at a count of around 327,000 and the total travel on the 97" axis is around 390,000.
1) Could this be due to lost communication via the ethernet connection
2) could this be due to low priority of the ethernet controller in the computer
3) could it be that Mach 3 has a max step limit.

This is not due to a mechanical blockage since I have disconnected the motor from the ball screw and the same thing happens. I thought that the Galil controller would manage the command to travel the complete distance and only report the distance but it seems like Mach3 is still sending the steps throughout the move. Is this how Galil controller operates?

Have you tried increasing the Queue Buffer Level? Information on this is on page 9 of the Galil Plugin pdf.   Kit

Thanks for the input, i did try the suggesteion to adjust the Queue Buffer Level but this had no effect.

I did find the problem however after looking in several different areas. What was causing the problem was that I used the screw mapping feature in Mach3 and for some reason there was a correction point which was way off at this equivalent X axis setting.

I was able to use a 1 meter calliper to verrify the screw mapping by setting some fixed points on the router. This allowed me to cover the complete 2.5M of travel. It looks like when I entered one of the point which was at approx at 2.1m or the 327,000 pulse count Mach3picked up a very large correction factor and the controller was trying to compensate for it. Not sure how Mach3 treates this but i assume that it is trying to keep a constant velocity so it needs to apply the correction in real time. Must be that if there is a large correction then the controlller can not react.