Hi,
I'm not sure you can, at least as you have written your code.
You are using mcCntlGcodeExecuteWait(), thus Mach will execute the instruction (or instructions) and wait UNTIL
they have been executed BEFORE progressing to a new instruction. That is by definition 'Exact Stop' mode and is discontinuous.
In earlier versions of Mach it was not possible to have GcodeExecuteWait() statements one after another. It was required
that you concatenate a number of moves together and then send the whole bunch to the Gcode interpreter and motion controller.
To illustrate I will take a fictitious example. Say you want to execute this series of moves:
g0 x50 y50
g1 x100 y100 z-1 f250
g1 x150
g1 y50
g1 x50
g0 x0 y0.
You could use successive mcCntrlGcodeExecuteWait statements:
mc.mcCntrlGcodeExecuteWait(inst,"g0 x50 y50")
mc.mcCntrlGcodeExecuteWait(inst,"g1 x100 y100 z-1 f250")
mc.mcCntrlGcodeExecuteWait(inst,(inst,"g1 x150.......
and so on. This would result in a brief pause between successive moves.
As I said earlier in previous times such a technique would have resulted in an error. It was necessary to concatenate the moves:
mc.mcCntrlGcodeExecuteWait(inst,"g0 x50 y50 \n
g1 x100 y100 z-1 f250 \n
g1 x150 \n
g1 y50 \n...............................\n")
and so on. This results in one bunch of code being dispatched to the Gcode interpreter as a text string with embedded line
feed characters. In this circumstance Mach behaves normally (if in CV mode, ie normal operation condition) and blends one
move into the next.
Thus to improve the fluidity of movement you will have to rewrite your code to use very much fewer mcCntlGcodeExexcuteWait()
statements.
There is another API that may be of some help....mcCntlGocdeExecute(). As you will observe it does not wait. Thus a move will
be committed to the motion controller but the function will return to the calling program before the move has finished.
Mach can then be in the process of planning the subsequent move. It might sound like that is the answer to your prayers
but it is not.
Lets say Mach does indeed plan a second move and it dispatches it to the motion controller. It cannot blend the preceeding
move into the current one as the PREVIOUS MOVE IS ALREADY COMMITTED and CANNOT BE CHANGED. Therefore despite
the apparent ability of Mach to plan a move before the last one has executed it cannot use its normal CV blending routines.
For all that it may be worth experimenting with mcCntlGcodeExecute() because it would allow Mach to be executing a physical
move at the same time that another instruction is being processed. If that instruction is another move no advantage will be
obtained. If however the instruction DOES NOT require a physical move then the separate instruction may execute more
smoothly one after another rather than waiting as in mc.CntlGcodeExecuteWait().
Craig