Any chance LASER_POWER_INLINE in the latest marlin branch will be implemented? Can I sign up to test? 
I have no idea what you just asked, or who you asked. 
I asked about a Marlin feature in 2.0 addressed to whomever at LightBurn works with Marlin.
OMG IT WORKS, sec on writeup
Export your gcode for Marlin to desktop. Open it in Notepad++ then:
- replace all M03 with āIā
- replace
^(I.+)[\n](G1.+)$with $2 $1
Send that Gcode to marlin laser with that setting enabled, and you get this:
https://photos.app.goo.gl/8F6HGPBXPwUpjQXu8
Stock Gcode for comparison:
https://photos.app.goo.gl/h4FrQVuWiuY75Ey3A
If you could get this to the dev for the Marlin stuff Iād like to request a switch to enable this for if itās on in the firmware if possible. I already did the work like as requested.
So, if Iām reading your regex pattern correctly, replace:
M03 S200
G1 X50
with
G1 X50 I200
?
Does it still need an M03 to turn on the laser?
Yes. Itās using a look ahead to pull the next line up in front of the previous. No M03 for the laser turn on from what I can see.
I ran it on a Greyscale because what possibly harder could you run it on? Itās showing some of my machine weak points which I expected but itās also working. Itās running at 60mm/s but I can see some slow down but not significant. Also on 3mm MDF and second time even trying greyscale so Iām not expecting great results. Still pretty impressed and like giddy excited. The fill on that pineapple in the video was hauling mass!
M3 / M5 still work for standard on/off, correct? Those are needed for āfireā mode.
From what I can tell yes. The output of the normal code was working fine and this is still turning the laser off before/after movements.
The same firmware is running both of these with just the two replace codes run. So it should work exactly like ānormalā without the inline replacements done, if that makes sense.
To help add:
In the Marlin source the code is actually this:
`
#if ENABLED(LASER_POWER_INLINE)
if (parser.seen('I') == DISABLED(LASER_POWER_INLINE_INVERT)) {
`
So only if it sees the āIā on the line will it do anything special. Otherwise itās the default M3/M4 behavior. M5 is not affected by the change so far as I can tell though there is a config option to:
Turn off the laser on G0 moves with no power parameter.
The fact that itās so heavily configurable is what makes Marlin such a P.I.T.A to support. GRBL, for example, has āLaser Modeā. You set one flag in the firmware and all of this stuff just happens because thatās how it should work. G0 is rapid, G1 is feed / cut.
How would you select a different tool - append P1 or another index on the end of the G1 command?
Iām not really sure. I just went looking to see why it was pausing on power delay and then saw that config value and chased that route down. 
I like GRBL to an extent, itās almost too simple. I have a little Woodpecker PCB CNC that was used to make the breakout for the K40ās ribbon cable. Adding hardware endstops and a Z probe without compile was awesome. Trying to mill a double sided PCB, not so much. After brain transplanting a few deltas Marlin config isnāt that bad anymore. I still couldnāt tell you how to make a fan spin all the time with no extruders as theyāre intrinsically linked. I have to add an extruder to add a fan to set the fan to always spin for the lights to be dimmable? Nah. I just ran them to vmot on the empty stepper slots instead. I can use an inline dimmer if I really want.
Realtime engrave with the two replacements done:
(disregard any missed steps as the machine has only been alive two days)
https://photos.app.goo.gl/rrdtvEvFdbZULdr19
thank you . I will test it tomorrow.
1 Like
Two fixes to it requested but looks really promising.
Good . your motherboard ?
Iām running a āTrigorillaā from a delta printer(Anycubic). Itās a generic Ramps 1.4 though. Mega2560 but a faster controller might be suggested. I tried out a 32 bit board but gave up on getting PWM to work before I got to change the board code in Platform.io.
One more thing I noticed. Looks like over-scanning is doing something goofy. Iām not sure if thatās related to our change or not though. It looks like itās setting the power to last setting when it does the reverse perhaps? Same options here but one has a 20% overscan (16mm)
An update, itās working pretty well with just the āStartā button. Iām trying to track down some points itās not turning the laser off and it appears it may relate to rapid movement but Iām not far enough along the testing path to know. It could be Marlin or my machine so trying to narrow it down to the smallest repeatable fill before I ask too much.
Hereās one without the fill shapes separately on. Thereās some certain condition when it jumps from one shape to the next it wonāt turn off, but for all jumps after that itās on. Falling asleep last night I started to suspect it may have something to do with an X AND Y movement in the G1 with S0 but I need to validate):
And here it is with. It took longer to engrave but not THAT much longer, especially compared to ānormal.ā You can see the pineapple bits themselves didnāt over-burn anywhere in this mode. The GCode for rapid travel in this export is different somewhat still but please donāt change it just yet. Itās using M106 S0 instead of M5. I played around with trying to take the rapid code from one and move it into the other but it didnāt have the effect I was hoping for:
Iām inclined to think my machine is poor and my setup is wrong, but the consistency here makes me think itās something more. Iām managing to have a little effect on it, but not something I can describe yet either. (disregard the greyscale engrave, I had to try ā Looks like it would be pretty good without the missed steps):
I do greatly appreciate the feedback and work Oz! I spent half of yesterday like a kid on Christmas Eve trying to go to sleep.