Hi,
that is not my understanding of how Mach4 and motion controller work.
Machs tajectory planner issues position/time data in, commonly, 1ms slices. So an x axis move, where the x axis is the ONLY axis
to move would create a string of data something like this:
Time X Y Z A
nnn 1234 2345 3456 4567
nnn+1 1240 2345 3456 4567
nnn+2 1248 2345 3456 4567
nnn+3 1258 2345 3456 4567
etc
where Y=2345 is the current Y axis position, likewise Z=3456 is the current Z axis position and A=4567 is the current A axis
position in machine counts. The X axis positon at each time slice is calculated by Mach to accelerate the X axis then maintain
a constant speed (increment between slices) and then decelerate until the move is complete.
So while the Y, Z, A axes are not moving they are still explicitly part of each time slice, its just that when they are not required to
move there is no increment/decrement between time slices.
Note that once a time slice is committed to the motion controller you can't get it back. In fact if you have called an X axis
move like G0 X10 then a whole block of time slices are planned and dispatched to the motion controller buffer and once they
are committed they cannot, short of an emergency stop, be cancelled.
What you want to do is have the X axis make a move and while that move is executing perform coordinated moves
with the remaining axes Y,Z,A.
That would mean that there are two streams of position/time data, one that allows the motion controller to generate the
pulse streams to move the X axis per the above table. The other position/time data stream would have the Y, Z and
A axes incrementing/decrementing to match the Gcode move of the Y, Z,A axes with the X axis.......constant?, blank?,
what?
Clearly having two position/time data streams is not possible or sensible. The machine cannot be in two positions at once.
While the X axis is coordinated with Y, Z, and A what you propose cannot be done.
My understanding (my understanding may of course be faulty, I am hoping Smurph, Daz, Steve, Rich et al may read this and
confirm/deny my understanding) is that an out-of-band (OB) axis can behave in the manner that you want.
What I propose is that prior to Mach issuing the preparatory X axis move that the X axis be programmatically decoupled
(un-coordinated) with the remaining Y,Z,A axes and issued a jog move, in the manner of an OB axis. The motion controller
can receive the move data for an OB axis AND execute moves independently of the coordinated moves as described
by the position/time table. Once the tool change is complete the OB axis would be tested to determine whether the move is
complete and if so programmatically reconnected to the coordinated X axis and its current position be updated.
This proposal relies on the behavior of the controller regards OB axes. I believe the ESS operates in the manner I have described
but I'm not 100% certain. I take as evidence that it does behave in this manner the operation of a Step/Dir spindle. The spindle
is a special case of an OB axis and the controller can quite happily send Step/Dir pulses to the spindle independently of the
coordinated axes.
If indeed this is possible it would require some tricky an involved programming. This is all to reduce cycle time by having the
X axis move independently and concurrently with the Y, Z, A axes involved in the tool change? Is it worth it?
Craig