Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: poppabear on August 06, 2014, 01:01:09 PM
-
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. ;D
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. :D
Tweakie.
-
Since your Mcode are 10microseconds to fast, put a 10 ms sleep before the output call.
So change your macros to this (and adjust the Microsleep as needed if 10ms if off:
--m770 macro turns "ON" OUTPUT0
function m770()
wx,wxMicroSleep(10);--10ms delay
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()
wx,wxMicroSleep(10);--10ms delay
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
-
Hi Scott,
That seems to do the trick ;)
The wxMicroSleep units are uS (not mS) and it took a delay of 50000uS to resolve the issue completely :)
Tweakie.
-
opps........
the: wxMilliSleep(); is milliseconds.... sorry...
scott
-
Thanks Scott - I am learning as I go ;)
Tweakie.
-
Hello!
Can you please explain, what's the concept of "inlining" (compared to the usual MCode scripting)?
Thank you,
Paul
-
it is not TRUE inlining (like in C) in where the compiler puts the function code where it is written so no call to it is made.
what was done here, was cut out some if statements and a function call. so, in theory less calls to functions and less if statements to process along the way should = more speed (in theory).
look up "inline" and C or C++ as a key word on google or some such.
-
So it means you can inline wxLua code into your G code script?
Something like that?
G1 X10 Y3.5
wx.wxMicroSleep(10);--10ms delay
mc.mcSignalSetState(mc.mcSignalGetHandle(0, mc.OSIG_OUTPUT0), 0);
-
So it means you can inline wxLua code into your G code script?
Hi FocusPaul,
No, you can't do that.
In Macro's, if they are written with the fewest number of statements (careful programming) it will reduce the number of function calls and speed up their execution time.
(In practice, as we have discovered, the Mcode call, assuming it is on a separate line, in the Gcode program is actually executed some 50 milliseconds before the CNC machine has completed the preceding line of Gcode - this has been found too early for lasers (although suitable execution time delay can be added) but for many Mcodes and indeed spindle speed changes (Scode) operating early reduces overall machine run time and makes Mach4 faster).
Tweakie.
-
Yes, they are quick! The issue is because Mach4 doesn't know exactly when the last movement was done on the motion controller. Mach4 holds up the M code until the last way point is sent to the motion controller. But there is going to be some latency involved between the time the data was sent and movement actually is done. So the physical motion always lags the as compared to the position in the G code file. This latency is PC/motion controller specific and will be different on just about every system.
The good news is that you can slow up the M codes with a wx.wxMilliSleep(ms) call. If you are consistently 10ms fast, do wx.wxMilliSleep(10) in the first line of the M code.
That is something to try, but it is not the best solution. Eventually, we will have a facility to turn on output in coordination with motion. We may use the LinuxCNC M62 and M63 type of thing. It seems that there is no standard at all to follow. Maybe if we do it like LinuxCNC does, it will "create" a standard. Only LinuxCNC's current form doesn't go far enough, IMHO. They only provide for turning output on or off at the beginning of a move. It would be nice to be able to do the same at the end of a move. Then there is CV to consider! It all gets a bit complicated.
http://linuxcnc.org/docs/html/gcode/m-code.html#sec:M62-M65 (http://linuxcnc.org/docs/html/gcode/m-code.html#sec:M62-M65)
M62 P1 (Turn output 1 on at the beginning of next move)
M63 P2 (Turn output 2 off at the beginning of next move)
G01 X1 Y1 (The movement. Outputs 1 and 2 will be coordinated with the start of this motion.)
Steve
-
Hi Steve,
The LinuxCNC M62P1 / M63P1 appear to operate in exactly the same way as the Mach3 M11P1 / M10P1 commands. Certainly for laser use it would be nice to have this command set within Mach4 :)
Tweakie.
-
Yeah, the only problem is that M10 and M11 are for turning a pallet or axis clamp on and off on Fanucs. Sometimes they are used to turn vacuum on a table on and off. So I really don't want to use those. And I really don't want to use M codes at all because M codes currently break the CV chain and we would have to add an exception. But we may have to. I would rather join up with LinuxCNC and try to create a standard than try to create something from scratch or use some code that already has uses.
Mach 4 mill (and lathe is almost done) is what we currently have. Lathe is a whole separate interpreter! We plan on having a separate G code interpreters for laser, plasma, water jets, and tangential knifes. These will come at at later date. One interpreter doesn't have to do it all in Mach 4. Until then, try the sleep trick and see if you can get it better. I'm pretty amazed at what you are doing with the laser and the mill interpreter!
Steve
-
Hi Steve,
The sleep trick certainly does work, although to a certain extent it spoils the smoothness of the motion particularly when engraving small text which has many short line segments. It will be interesting to hear how Art gets on with his laser and gating the laser switch to axis step pulses. Keep up the good work my friend. ;)
Tweakie.