Hi,
I think the depth of the motion queue does not delay command and control messages
Motion commands are issued by the trajectory planner in the form of PVT data which is queued. Even if Mach was instantly
updated by Ethernet about the position of the servo it would still have to issue trajectory commands and ergo the buffering
delay.
Closed loop control bandwidth is highly dependent on the 'around the loop' communication delay. If you have a buffering
delay of 100ms, given the Nyquist sampling theorem, the best possible closed loop bandwidth would be 5 Hz. Any control
engineer will tell you that the discrimination of a control loop running at the Nyquist frequency is rubbish, you will get
only fair discrimination at 1/10
th the Nyquist rate, in our example 0.5Hz.
Half a Hz bandwidth might be adequate for a temperature control loop with a temperature time constant of 5 seconds but
it will fail miserably trying to control a servo.
Adequate servo control for CNC axis purposes requires an absolute minimum position bandwidth of 100Hz, 250 to 500Hz is
the common norm for entry level servos and 1000 to 5000Hz for the latest and greatest servos.
Mach4 is not a realtime control system, and that is because the operating system on which it runs (Windows) is not realtime
capable.
Linux distros with R(eal) T(ime) E(xentsions) is realtime with a quite respectable jitter of 2us-4us on common PC hardware.
Windows can't manage that.
Craig