

After substituting another computer that had a 2 microsecond variance, the machine went from being able to move the heavy Z-axis at 185 IPM to 245 IPM, graphic evidence of the amount of impact this sort of thing can have.

That machine exhibited an interrupt variation (variance from desired timing) of 14 microseconds.

Using DRIVERTEST.EXE, they measured performance of a 2.2 GHz Dell Optiplex 330. They use the Mach3-provided utility DRIVERTEST.EXE ( comes with Mach3) to determine how stable a particular PC configuration is for driving a CNC machine. Tormach has quantified the magnitude of these problems pretty nicely in one of their many excellent engineering articles. This is tremendously wasteful of the motor’s torque, is far from ideal as a way to drive a cutter through material, and generally gums up the works. When it shows up again, the axis must accelerate. Whenever a step pulse is delayed, you get a big deceleration. Think about the delays in the pulse train as introducing large arbitrary amounts of deceleration and acceleration into the motion of the axis. Giving the motor drivers a pulse stream full of stops and starts is like driving a car with a clogged fuel filter that bucks and balks when you try to get crisp acceleration. What happens we don’t give the stepper or servo driver a clean stream of pulses? Those signals get interrupted by a variety of distractions the machine may have ranging from other software running on the machine besides the CNC controller to energy saving software that kicks in to slow the processor to a variety of other issues. Simply put, if the task of sending motion control signals (step + direction pulses) to the motor driver hardware is interrupted, we have problems. Our first article in this series discussed how using Windows to solve all of the CNC Controller problem suffers because Windows is not a real time operating system.
