Hello Guest it is April 13, 2021, 01:05:59 PM

Author Topic: How can I smooth out motion in my LUA script  (Read 411 times)

0 Members and 1 Guest are viewing this topic.

How can I smooth out motion in my LUA script
« on: January 30, 2019, 11:24:52 AM »
I wrote a script for my tool changer and got it working with help from here.

Now I would like to do a little optimization. One of the problems is that during the tool change cycle the motion is pausing during the different operations. I would like to eliminate the pauses if possible.

For example part of the lowering to pick up the sequence is:
Lower over tool holder
Turn on blow off
Lower some more
Turn off blow off
Turn on Drawbar open

There is a stop in motion at each point where I ether turn on or turn off an output. Is there a way to turn on/off the outputs with out stopping the machine motion?

Here is my code for that sequence:

    ------ Lower to blow off start position ------
    local GCode = ""
    GCode = GCode .. "G00 G91 Z-2.0\n"
    mc.mcCntlGcodeExecuteWait(0, GCode)
    ------ Turn on Blow off  ------
    local BlowOff = mc.mcSignalGetHandle(inst, mc.OSIG_OUTPUT0)
    mc.mcSignalSetState(BlowOff, 1)

    ------ Lower to pick up start position shut off blow off, turn on drawbar------
    local GCode = ""
    GCode = GCode .. "G00 G91 Z-.25\n"
    mc.mcCntlGcodeExecuteWait(0, GCode)
    mc.mcSignalSetState(BlowOff, 0)
    local DrawbarOPEN = mc.mcSignalGetHandle(inst, mc.OSIG_OUTPUT1)
    mc.mcSignalSetState(DrawbarOPEN, 1)
Re: How can I smooth out motion in my LUA script
« Reply #1 on: February 01, 2019, 11:02:34 PM »
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()

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().

My wife left with my best friend...
     and I miss him!
Re: How can I smooth out motion in my LUA script
« Reply #2 on: February 02, 2019, 10:54:05 AM »
How about using M64 and M65 to turn the outputs on and off? I don't know if this will help with the 'smoothness' of the motion but it is a bit tidier.

So your code would end up like this..

Code: [Select]
local inst = mc.mcGetInstance()

local GCode = ""
GCode = GCode .. "G00 G91 Z-2.0\n"
GCode = GCode .. "M64 P0\n" --Output 0 on
GCode = GCode .. "G00 G91 Z-.25\n"
GCode = GCode .. "M65 P0\n" --Output 0 off
GCode = GCode .. "M64 P1\n" --Output 1 on

mc.mcCntlGcodeExecuteWait(inst, GCode)