Laser_power_inline

Any chance LASER_POWER_INLINE in the latest marlin branch will be implemented? Can I sign up to test? :smiley:

I have no idea what you just asked, or who you asked. :slight_smile:

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. :slight_smile: 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. :frowning:

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. :slight_smile:

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. :slight_smile:

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.