Hi,
as far as the comms delay that Mike (mcardoso) refers to I have not noticed it in practice.
Like any MPG, if you spin the pulse generator wheel quickly and have a high or significant step increment set in
Mach4 it is entirely probable that you will exceed the axis speed and therefore end up with motion commands in the
buffer which will in turn result in after-run even once you stop spinning the wheel.
This used to happen to me when I had a 1mm movement increment per step set in Mach4. It was very easy for me to
end up with 20-50mm of movment stored up in the buffer......and no amount of panic on my part was going to change
that. I found the problem less pronounced when I set the maximum increment per step to 0.5mm per step, but my normal
setting is now 0.1mm per step. I can cause after-run if i really really try to spin the wheel as fast as I can but under normal
operating circumstances I don't end up with any after-run and can yet still jog plenty fast enough.
It has made me realise that after-run is not a fault, its what Mach is supposed to do....it did something stupid because that is
exactly what I asked it to do. Now that I have a realistic increment set the 'problem' has evaporated, I can jog as quickly
as I want or need and yet have the resolution for all but the most demanding of positioning ops.
As Mike pointed out the USB comms impose a delay between the pendant and Mach.
Follow this sequence of events:
1)The trajectory planner is otherwise unoccupied. The planner has been issuing a long string of zero movement PVT
(position velocity over time) commands to the motion controller in one millisecond intervals.
2)The motion controller has a buffer (180ms is the default buffer length in the ESS) full of zero movement commands
and so the machine is stationary.
3)The trajectory planner receives a step command from the VistaCNC plugin to execute a single increment step
on the selected axis.
4)The trajectory planner issues a string of PVT data slices to enact that movement, lets say 5 slices so that the move
takes 5ms.
5)180ms later (the buffering delay) the motion controller recieves the non-zero PVT data and the motion controller issues
the pulse streams for the axis motor to move as required.
Consider step 3) a little more closely. When the pendant MPG wheel is advanced one click the circuity within the pendant
assembles a frame of data to send to its plugin (here I am assuming a VistaCNC type plugin), then the frame of data is
communicated to the plugin, and thence to Mach. I would assume the plugin-to-Mach communication to be in the usec
range, likewise I would assume the hardware can compose the data frames in usecs, therefore the only (significant) delay
is the USB frame rate....around 8-12ms.
The total delay from the MPG pulse to the pulse be enacted by the motor is 190ms being the sum of the buffering delay
and the USB frame delay. Were it possible to eliminate the USB delay, the total delay from MPG to motor is 180ms.
Clearly the total delay is to all intents and purposes determined by the buffer delay NOT the USB delay.
Consider now the situation that you have a hardwired MPG to you BoB/ESS combination. When the MPG is rotated one click
the BoB/ESS hardware being essentially instantaneous composes a data frame to send to the ESS plugin which
in turn communicates to Mach. Machs trajectory planner then issues the same 5 non-zero PVT data slices, which is communicated
to the ESS via the same 180ms buffer.
The default controller rate for the ESS is 40Hz. Thus it will communicate frames of data back to it s plugin ( and thereby Mach)
with up to a 25ms delay.
The total delay from MPG pulse to motor pulse is 205ms, assuming the worst case timing of the MPG pulse realtive to
the ESS data frame timing, to 180ms, assuming the best case timing.
The total delay is still largely determined by the buffer delay.
Thus I disagree with Mikes contention that communication delays imposed by a USB (or other serial communication protocol)
place pendants at a disadvantage relative to hard wired MPG's, the total delay is determined nearly exclusively by the
buffering delay of the motion controller and is the same in both circumstances.
Craig