If your macros are slow (like on lasers), try "In-lining" them to save on func calls.

--M770 macro turns "ON" OUTPUT0
function M770()   
    mc.mcSignalSetState(mc.mcSignalGetHandle(0, mc.OSIG_OUTPUT0), 1);     
end
M770();
--[[
if (mc.mcInEditor() == 1) then--leave uncommented unless in the editor
    M770();
end
--]]

***********  This next macro goes into a separate macro for the off func. **********

--M771 macro turns "OFF" OUTPUT0
function M771()   
    mc.mcSignalSetState(mc.mcSignalGetHandle(0, mc.OSIG_OUTPUT0), 0);     
end
M771();
--[[
if (mc.mcInEditor() == 1) then--leave uncommented unless in the editor
    M771();
end
--]]

Scott

Something's not quite right - they will not turn Output 0  on/off here. 

Tweakie.

Hey Twdakie,

   I am opening them in the mcLua editor, and then I hit "run" and Output 1 turns on for m770, and off for m771 what are you doing to get it not to work in yours? Do you have other things writing to that output?

scott

Hi Scott,

Agreed, running M770 / M771 in the mcLua editor works but entering M770 or M771 in the MDI or within GCode does not work here.
Obviously I am doing something wrong but so far it has alluded me. 

Tweakie.

now THAT is odd....

I cannot get them to run in my MDI or G-code either!  
Never had that happen before,
I even tried:

 * UN-commenting the "is in editor stuff", no change.
 * Restoring it to "UN-inlined" (standard way of doing a macro), no change
 * putting in and taking out the function call M770() and M771(), no change
 * After each change, closing and re-opening M4, no change
 * I see it blow past the M770/M771 while watching the OUTPUT1 LED on the Diag-page, nothing

 * if I put the native code into the PLC script which via code turns on and off output1, IT WORKS!
 * BUT.... If I put mclua code to call the MDI command or Gcode command and call it via macro name
    it does NOT work....

***  I am wondering if something broke in the mclua? Or, perhaps I have done something stupid,
***  which is always a possibility, Perhaps Steve can look it over and see where the Break or the Opps is.

Here is the M770/M771 gcode I am using to test with:

F60.000000
G0 X0.000000 Y0.000000 Z0.200000
M3 (start Spindle)
S60.000000
g1 x1 f20
M770
G4 P2
M771
x0
M5
G0 X0.000000 Y0.200000 Z0.000000
M99  

It really doesn't make any sense, and I have a "Lic." copy of M4 as well running on the "Sim".

Scott

OK, it was an attack of STUPID!!!

you have to name the macro with a LOWER case m....

in the macro code m770, and m771 then it works!!

just never paid attention to that

scott

so here are the working In-Line (mdi and gcode) m770 and m771:
(Tweaky, tell me if it speeds up your laser output or not, I don't have one)

--m770 macro turns "ON" OUTPUT0
function m770()   
   mc.mcSignalSetState(mc.mcSignalGetHandle(0, mc.OSIG_OUTPUT0), 1);
end
--m770()--testing;
--[[
if (mc.mcInEditor() == 1) then--leave uncommented unless in the editor
    m770();
end
--[[

-----------**********************************---------------------------------

--M771 macro turns "OFF" OUTPUT0
function m771()   
   mc.mcSignalSetState(mc.mcSignalGetHandle(0, mc.OSIG_OUTPUT0), 0);
end
--m771();--testing
--[[
if (mc.mcInEditor() == 1) then--leave uncommented unless in the editor
    m771();
end
--[[

Scott

Thanks Scott it works just fine now  

I don't think Mcodes will ever be fast enough for laser use but now they are working I will give the 'in-liners' a try and report back.

Tweakie.

Hi Scott,

Sorry to say this but there is no noticeable increase in speed over the 'multi-liners' (sent to me by Craig last week).

Even slowing the feed-rate down by 1/4 to 1000mm/min this is the result - the gaps represent the 'turn-on' delay and the tails the 'turn-off' delay.

If the Mcodes were gated to an (any) axis movement (as Art did with the M10/M11 set in Mach3) then the situation may be different but I think this needs to be done within the core rather than as an external Mcode.

Damn lasers, you just got to love them really.  

Tweakie.

EDIT;  Please disregard this post - Now I have had more time to look at this picture, something is not quite right so I may have jumped to the wrong conclusion. I need to re-run the test in order to get more information regarding the 'gaps' and 'tails' in relation to the toolpath.

Having slept on this puzzling issue for a couple of hours I was keen to carry out more tests this morning and these are my findings…

1) After regenerating the tool-path (just to be sure) the result was identical to the previous test sample.
2) From another ‘comparative test’ the results from a ‘multi-line’ generated Mcode were identical to the results from an ‘in-line’ generated Mcode – there appears to be no measurable difference in the Mcode execution speed.
3) The ‘gaps’ and ‘tails’ (see previous photo) are not what they seem (and certainly not what I had first thought, in fact quite the opposite) - the ‘gaps’ have been caused by the laser turning ‘off’ too early and the ‘tails’ have been caused by the laser turning ‘on’ too early.
4) Although my Gcode consists basically of…
          Axis movement
          Mcode
          Axis movement
the Mcode has been executed some 10mS ahead of the first axis movement being completed.
5) I take back what I said about Mcodes never being fast enough for laser use and ‘humble pie’ comes to mind.  

This situation may change with later revisions of Mach4 and Darwin but currently these Mcodes are too darn quick.  

Tweakie.