I suspect one of the reasons this is acceptable in Marlin is because G0 and G1 speeds are the same. There is no separate proper rapid moves concept.
I believe this concept only exists for Marlin. But in any case, the working cases have been with Marlin boards.
However, I spent a little time reviewing how Inline in LightBurn is generated. I thought it used M4 specifically but it looks neither M3 or M4 is specified at all. So it’s not clear to me which Marlin will use by default if Inline is requested.
I don’t understand the comment about deviating from GRBL format. It’s because Marlin deviates from GRBL that this is even a potential issue. If the behavior were the same this would be a non-issue.
I think it’s more that LightBurn does not more than it cannot.
As stated earlier, Marlin doesn’t differentiate feed speeds for G0 or G1. They’re all the same. You can override G0 speeds in LightBurn with the Fast Whitespace Scan setting.
If an option was added that’s great. I wasn’t aware. However, I’m struggling with this language:
For Cartesians and Deltas the G0 (rapid linear movement) command is (and must be) a direct alias for G1 (rapid movement). On SCARA machines G0 does a fast non-linear move. Marlin 2.0 introduces an option to maintain a separate default feedrate for G0 . Note: Slicers tend to override firmware feedrates!
Seems to indicate that cartesian machines require that G0 and G1 be the same.
Thanks for that.
So i have done some more testing and i am still a bit frustrated with the m4i.
So the G0 makes the laser no longer fire on travel moves but it seems this mode uses the feed rate for power. Trying to figure it out.
Are you saying for G1 moves? If so, make sure what you’re seeing isn’t the result of variable power adjustment for deceleration/acceleration and actually direct power control via feed rate.
By the way, it’s stuff like this where Marlin just isn’t a great laser platform at this time.
They have trap power for compensation and it works okay ish.
But in my testing im finding the laser lube is not exactly linear in its power curve.
I have the min fire value worked out and a max set to extend tube life.
Thinking i might move over to linuxcnc so i can use the hal file config to make a lincure to adjust for the tubes non linear performance.
I have a laser power meter but its only for up to 5W. so im going to have to try and measure the power of the entire range without burning the sensor. I might have to capture a defocused beam passing a smaller peep hole.
This should allow me to test the entire power range of the tube and even if the values aren’t true power values the only thing that matters is the scale i get. in my burn tests it seems to scale up very fast for a few % then level off then again and about 12% laser scales fast again.
Or i could just burn a clear acrylic plastic at power intervals and measure the depth. This would give a quick visual representation of power to depth but makes for a less accurate scale as my measurements will probably be off a bit.
I can use the 3d printer main board now with linuxcnc via the Remora project. not the 8 bit boards but the 32bit ones with a rpi 4 using SPI control of the 3d printer board is working.
I suspect with linux cnc i will get better control and having the rpi4 doing the real time control i wont have to worry about the limited power of the main board.
I may also be chasing minuscule gains. As it seems most other people with C02 lasers dont even map the power ranges or care about the non linearity.
I’m not familiar with the Remora project and have not worked directly with LinuxCNC. I’ll caution that LinuxCNC Is one of the least commonly referenced controllers on the LightBurn forum. I don’t know what that means for its use in specific applications that would not bring people here, however.
2 things you should be aware of:
LinuxCNC Is offline only in terms of LightBurn. You’ll have to generate gcode and run it externally.
You’re likely to be fairly isolated in terms of access to people with experience doing this, at least on this forum. You seem relatively comfortable forging your own path so may not be too uncomfortable for you but something to be aware of.
Partly I think this has something more to do with the notion that power regulation is something expected to be done in hardware/firmware. Although there are certainly some that have attempted to plot current vs output power more from an empirical perspective to understand behavior, but not to control it.