Hello, I have a home built 40w co2 laser cutter running on a ramps 1.4 with marlin 2.1.2.1.
I am having issues with the Dynamic Inline Mode.
Im not sure if this is a marlin issue or the way the gcode is created from lightburn.
If i add “m3 I” ( Continuous Inline Mode) the laser runs as expected and turn on and off and pwm is working good.
If i run “M4 I” ( Dynamic Inline Mode Laser/Spindle Configuration (2.0.9.x) | Marlin Firmware)
The laser stays on and burns during every move.
The only change is the start “M3 I” vs “M4 I”
You can see in the picture the same gcode and the 2 very different results.
Is there some thing i am missing to use “M4 I” on my setup?
doing more reading in config adv and seems maybe im mistaken for how m4 i works.
"
‘M4 I’ sets dynamic mode which uses the current feedrate to calculate a laser power OCR value.
*
Any move in dynamic mode will use the current feedrate to calculate the laser power.
Feed rates are set by the F parameter of a move command e.g. G1 X0 Y10 F6000
Laser power would be calculated by bit shifting off 8 LSB’s. In binary this is div 256.
The calculation gives us ocr values from 0 to 255, values over F65535 will be set as 255 .
More refined power control such as compesation for accell/decell will be addressed in future releases.
"
Is “LASER_POWER_TRAP” more what i am looking for? Laser power to be adjusted for speed so i get less burnt corners and under burned straight sections?
"
/**
* Scale the laser’s power in proportion to the movement rate.
*
* - Sets the entry power proportional to the entry speed over the nominal speed.
* - Ramps the power up every N steps to approximate the speed trapezoid.
* - Due to the limited power resolution this is only approximate.
*/
//#define LASER_POWER_TRAP
"
I’ve always understood dynamic inline mode to do this very thing. Essentially, to dynamically adjust power based on accel/decel. However, the comments that you’ve listed seems to contradict that so now I’m questioning that.
This is from Marlin documentation but is based on 2.0.9. I’m wondering if the config comments are simply outdated?
Dynamic Inline Mode
Since Dynamic Inline Mode is new to Marlin (Oct 2021) it should still be considered under development and experimental. Dynamic Inline Mode scales laser power to the stepper feedrate so that a consistent amount of laser energy is applied to the workpiece throughout moves, even as they accelerate and decelerate. (It is similar to GRBL 1.1f in M4 dynamic mode.) Stay tuned.
In any case, if you’re getting burns on traversal moves this is likely a configuration issue.
Can you confirm the following:
You are able to use M4 without inline?
You have PWM control of power levels using M4.
You should make sure both of those work before attempting inline.
As an aside, is there a reason you’re using Marlin for the laser? Even now Marlin is a relatively poor driver for laser function. If you can convert to GRBL your life is likely to be a bit easier.
i have only ever used marlin for all my printers and machines so its what i know
If grbl can support dual x motor and dual x axis end stops i could switch to it.
Are you doing independent control of the 2 X-axis motors? Also, is your laser oriented 90 degrees rotated from typical? Meaning the gantry is moving left-right vs up-down.
Legacy GRBL has limited support for independent Y-axis with specific boards for gantry squaring if I’m remembering correctly. But dual Y-axis is typically accomplished by a less complex dual motor single driver model. I don’t know if this can be remapped to work for X-axis. Or rather, I’m not sure how much work it would take to accomplish it.
Do you mean for left and right extremes? If so, yes, that’s possible.
yes its a bit weird as i have dual x vs y.
Yes i am moving left right.
and no i am using dual x min end stops and drivers to square up.
I know you can do 1 driver 2 motors but in my experience it increases the chances of lost steps.
added picture of my laser in the OP
so i am a bit more confused with marlin.
Seems the LASER_POWER_TRAP is not doing what i thought it would.
From the description
* Scale the laser’s power in proportion to the movement rate.
*
* - Sets the entry power proportional to the entry speed over the nominal speed.
* - Ramps the power up every N steps to approximate the speed trapezoid.
* - Due to the limited power resolution this is only approximate.
I would think it would only alter the laser power but seems to also alter the speed to. my machine slows down when doing greyscale and even doing a box with rounded corners im still getting overburnt corners.
Can’t help you with LASER_POWER_TRAP. The wording sounds very much like what Dynamic Inline should be. I’m wondering if this is in fact the implementation used for Dynamic Inline. In any case, “trap” is the operative word here.
I don’t think I can answer what the best would be. The ones I’m aware of:
They would need to be based on 1.1h I believe for support to be included. If they are not then that would indeed cause a problem. Don’t suppose you’re up for a backport?
The MEGA 5X repo has a number of mentions of dual axis, however. So it does appear to have some level of support for it.
I’m not very familiar with that board but it does seem to be supported by grblHAL so I think worth a shot, especially since this leaves a working controller available.
Hello i have been looking at this issue a bit and reaching out to people to understand more.
Is there a reason why light burn is doing G1 XY S0 moves vs using G0 S0?
If im not cutting but moving why is always using G1 moves and not G0?
LightBurn will use both G1 and G0. From what I’ve seen G0 is used between layers and G1 is used within layers.
GRBL “Laser mode” allows for G1 S power changes to occur immediately instead of pausing for spindle to reach speed. This allows for rapid G1 S changes even to S0 within a job. Imagine a scenario like for grayscale images.
Note that G0 is considered a rapid move and does not conform to Cut setting speed but rather max speed set for axes. So wouldn’t be a great fit to use for non cutting moves within the job.
Hmm so if I am reading this right I will need to parse the out gcode from lightburn to change any line that has both g1 and s0 and replace the g1 with g0.
Kinda klunky but hopefully that will get m4i running as expected.
I thought you were referring to the GRBL implementation. But why would you need to do anything special? The output as is should work correctly. Is there something specific that’s a problem?
I believe Marlin will use speed of “Fast whitespace scan” in Edit->Device Settings for traversal move speeds.
so after talking to the devs of marlin who work on the laser code it seems to support m4i dynamic mode the laser will always fire on non G0 moves.
seems to creator of the m4i mode uses LaserGRBL
LaserGRBL has the option to turn on and off G0 fast skip
By defaults fast skip is enabled thus the use of G0 in its output.
Is this an option that can be added or is this a hard limitation of this software?
Even with S0? That would break the entire intent of a laser mode if true. Keep in mind that there are other people using LightBurn today with M4 inline. Surely there must be some misunderstanding.
This seems entirely backwards to me. Something like this would be more useful if no laser mode existed, thus relying on G0 moves.
I can’t speak for LightBurn but in this case, I’m questioning the very premise for the need.
Basic question, how are grayscale images supposed to be handled in this G0 scheme where full white is expected?
if the laser is off any moves becomes a G0.
So if the laser is off IE white then move via G0
Are they running m4I on marlin boards?
Comment from the devs
isPowered flag set on any parsed G1, G2, G3, or G5 move; cleared on any others. need G0 to move without power.
[9:57 PM]
Dynamic needs G0 because it’s based on the rate of the stepper pulses otherwise its too much calculation for the low end 8 bit boards. The code was meant to be backward compatible. Given that, there is no reason one couldn’t say G1 S0 sets ispowered to false and > S0 sets it to true. However that would deviate from the GRBL format.
the exact reasons for this go beyond me. I just am trying to understand how the code works.
But it seems other laser software support the option for G0 white moves but lightburn cannot.
Some may take issue with G0 but a properly setup machine for max acceleration and travel speeds should not have any issues. This should also work a bit to speed up the cycles times if an image has alot of white space there is no need to crawl over it at cutting speed if no work is being done.
I can see that in some configurations this acceleration and deaccelerations may make quality worse for some machines that have the limits set very close to the max the frame can handle.
But a solution to edit the gcode exists with post processing so its not impossible.
