Overscan for Line Mode?

When I’m engraving a design using line mode I keep getting darker spots at the beginning and ends of lines. Is there a way to turn on overscanning for line mode?

I know this has been asked before but the ‘fix’ was to use settings that are no longer in the menus as well as a modification that only works with GRBL.

If you’re able to get dynamic inline mode working that is meant to directly address this phenomenon. However, getting Marlin working in general has been a recurring them on this forum.

If I was skilled enough to be able to get dynamic inline mode working correctly in Marlin, I would probably just write something better than LightBurn in an afternoon.

One of the big selling points of LightBurn is that it works with all sorts of laser cutters, but it kinda feels like cheating if it only works correctly with a setting that doesn’t work. For all we know it doesn’t even work if that setting is enabled because there is the initial problem of having the setting enabled.

Seems like it should be a simple enough thing to add a given distance for deceleration with laser off. Should make vector graphics really pop.

For the most part, if the firmware is properly equipped, LightBurn will allow for inline. Usually it’s that the firmware is not equipped with the proper configuration/compilation. LB can’t be faulted for that. The reality is that Marlin itself poses quite a challenge do to the number of variants in application and the lack of conformity to any real standard.

Sounds like you’re advocating for LightBurn to take on controller functionality. I suspect that’s not the route that the devs would want to take although there are other software implemented features that feel a lot like something that should be handled in firmware…

Do you have the option of running a GRBL based firmware instead of Marlin? You’ll likely have a better time.

The thing is that there is no functional firmware solution at the moment. The most basic settings for this cut laser power to the point it doesn’t leave a mark in most places. The more advanced settings are so untested that they don’t even compile. None of them do anything like what I’m requesting even if they did work.

Lightburn already does overscan for images. This is the same thing for lines. I don’t see how that should be a controller thing. I’m not looking for lower power towards the end of a line, no trapezoidal power curve…I just want the power I set until the end of the line. If that means the laser needs to do a bunch of G0 moves to get from lead out to lead in, I’m happy to make that sacrifice for quality. Not actually sure how that would work being on the controller side; generating a bunch of moves that are not in the G-Code file.

My controller board does not support GRBL; it’s an Octopus. Actually not sure GRBL supports my physical hardware either…it has 4 Z motors for auto bed leveling.

To me the process of it is fairly different. For fill or images there’s an assumption of an entire line being burned and then proceeding to the next line. Overscan in this case just overshoots the beginning and end of each line. This isn’t a big change in motion as the expectation is that laser needs to stop, move down a line, and then proceed in the opposite direction.

For lines an overscan on something simple like a square would require overshooting past the corner, reorienting the laser to align for the next shot, then overshooting again for each corner. This is in contrast to a continuous movement. This wouldn’t be necessarily so hard to program for but then the question is what would be the expected behavior for curved lines?

The proper answer and how it’s managed in other solutions is to reduce power to the laser during deceleration/acceleration as the laser head negotiates corners/curves which I think agree should be in the domain of the controller.

This seems like the real problem to solve. I wonder if this can be tuned in some way. Does this only happen at really slow speeds? If I’m remembering correctly the variable power algorithm in GRBL is quite simple-minded. It reduces power linearly and in direct proportion to change in speed. I would have thought this would require some sort of logarithmic power curve or something but that’s not what I saw from what I recall.

Standard GRBL definitely would not. There are variants that support mult-stepper Y axes so I see it in the realm of possibility that there may be a variant that supports multi-Z steppers. I’m not aware of any GRBL configuration that cares about bed-leveling as tiny variations are not nearly as sensitive in lasering as compared to 3d printers but that’s likely just me not being exposed to those.

I think there’s a higher chance that there’s a build that will work on the Octopus than that supports your hardware situation but I’m just speculating.

The problem actually isn’t bad with curves; it’s sudden motions that cause the laser to momentarily stop. I engraved a ruler and the ends of the lines were circles.

In RDWorks there’s a setting for minimum power and maximum power and it ALMOST eliminates this issue. Hairpin turns still overburn a bit. Not sure if this is firmware or software doing the heavy lifting. I see min power in the settings for images (grayed out) but not in the settings for lines at all. Pretty sure I’d be happy enough just with that, although I’d have to test of course.

In my mind the ‘perfect’ routine would have a maximum and minimum power as well as a maximum acceleration. Anything where the power needs to go below the minimum to avoid going over the maximum acceleration would get lead in/out lines but with the power set to 0. If that means you need to do four G0 moves to make a rectangle, so be it…it’s going to be a really nice rectangle without overburned corners.

The laser stops? As in comes to a standstill? That’s troubling.

How are you burning from RDWorks?

For g-code lasers only grayscale has a valid minimum power setting.

Normally these things would all be defined in firmware. For example, LightBurn has no concept of acceleration or specifies for it in g-code. It only understands g0 rapids and g1 feed rates.

At the end of a line the laser stops, moves to the right by 1mm, and starts again. If 200mm/sec is 60% power and the laser turns off entirely at 19% power, there’s no way to use a trapezoidal curve to cut to the end of a line correctly…it will be over or under burned. Firmware can get close, the RDWorks min power setting can get close, but neither does it perfectly.

This machine had a RUIDA controller for a couple of years until it broke. I would have replaced it with the same but at that point I had 3 arduinos adding functionality that I now just have built into Marlin (and 3 arduinos that are adding features to that…my friends are starting to think I’m some kind of mad scientist)

Thanks for pointing out how to get at least one minimum power setting. Now if I could get that on lines I might be done-ish with my laser build.

Things that might work but are not currently available in LightBurn:
1.) Min/Max power settings for lines…not ideal but at least matching RDWorks at that point.
2.) My complex routine with the acceleration detection…I get it…not easy.
3.) A simple routine to just add zero-power lead in/out lines to every line, regardless of the time it adds.
I think option 3 would probably be the best option because it would allow LightBurn to have better engraving quality than competition, even beating out Ruida machines using only G-Code.

Yeah… this is an interesting problem.

These are arduinos configured to add functionality to your laser? That’s really cool.

You’ve gone kind of a long way moving from a Ruida controller to Marlin, though. Did Ruida support your 4-stepper auto-bed leveling? Crazy idea, could you leave the Octopus to manage the bed and get a GRBL controller to manage the laser and X,Y axes?

I wish I was more experienced with lasering in Marlin but it seems a frustrating experience. I’m looking to move away from Marlin entirely even on 3D printing so may never get the opportunity.

To be clear, LightBurn does have this on DSP controller… just not g-code.

I wonder if you could somewhat hack a version of this by disjointing all your lines

My Ruida DSP didn’t have much functionality beyond the bare basics of laser cutting.

I had a Teensy LC based board controlling the 4 z motors and end stops.
I had another one handling the cooling functions except for the flow meter…
And then one just for the flow meter because I suck at coding and my code was wasteful.
Eventually I combined these all into a single Teensy LC. Oh and there was a rotary attachement that I would switch to using one button to change the Y steppers in use. I was pretty proud of that…job done, laser cutter perfect! Then the Ruida board started having issues.

Now I have a RasPiPico running a keypad connected to a serial port on the octopus board.
I have another RasPiPico converting the analog readings of the end stops to digital readings for Marlin…since that isn’t a feature available in Marlin (?YET?).
And then I have a Teensy LC Converting an Active-Low 3.3V signal into an Active-High 5.0V Signal so the high voltage power supply is happy…because the octopus board doesn’t have any 5.0V PWM outputs. I haven’t messed with the rotary axis yet because all the time I had it, I never used it for anything but testing itself.

This machine has been a journey. I feel like a trade school should give me some credits for the things I’ve done on it. I have been trying to document it but I am not sure how well the write-up/video will turn out.

Overall I am actually pretty happy with Marlin. I have a Marlin mill, 3 Marlin 3D Printers, and this Marlin laser cutter of course. The available features and configurability are downright amazing. I mean…the two basic config files add up to over 7,000 lines of code yet most of it is easy to understand because of all the comments and you can configure something as complex as a Voron 2.4 from scratch in a matter of a few hours. It’s more work to get going in that way but GRBL is a whole lot more work if you have to write the code for your z motors yourself.

What would it take for LightBurn to have a min/max power lines feature in G-Code? If it’s about the price difference, I don’t mind buying the expensive version.

I am not sure what you mean by disjointing lines. I uploaded the test objects I used. The spacing came out correct but each end of every line is a burned circle because the laser slows down to a near stop but the laser stays on.

475mm_ruler.dxf (903.4 KB)
600mm_ruler.dxf (1.1 MB)

Just checking in because my laser cutter is still no good for line engraving. I don’t believe this is a job for the firmware; trapezoidal power would be an improvement but not a fix. I’ve never encountered a DSP that will do this either; they are just very well tuned trapezoidal power curves.

A real fix will require extra G0 or G1 codes. This is not the job of the firmware, I hope one day it is the job of LightBurn.

If not for this and the marlin connection issue, I think I’d like this software a lot. As it is, it’s hard justifying paying for something that feels like a beta.

This is entirely firmware - the Ruida has dual power settings we send it (one for min, one for max) and it interpolates between them when accelerating from a stop to your requested speed.

GRBL does this too, when using variable power mode (M4), but it doesn’t have a setting, it just uses 0 as the min value.

I do not know if there is a variable power mode in Marlin firmware. In general, it is abysmally suited for laser use, because it lacks features like this, and most people use the fan outputs for PWM control, which only update at 10hz, meaning it’s unusable for image engraving or even basic scanning of vector shapes.

Newer versions of Marlin do address most of these issues, but you still have to get a version for whatever machine you have compiled with the appropriate settings enabled.

Doing something like overscan on the vector shapes is not impossible, but would come with a bunch of its own issues.

1 Like

Thanks for the clarification. Did not know the DSP handled that.

GRBL M4 sounds pretty bad; when I was on a DSP I wanted min and max power settings. The feature I recommend would really help people with GRBL lasers it seems…more than with Marlin or Ruida in fact.

In Marlin there are a lot of settings for what they call trapezoidial power control. It’s in the file called configuration_adv.h. Search for “#define LASER_POWER_INLINE”. The problem is that even if I get the settings as close to perfect as possible (and I mean better than a Ruida), they still are not perfect. Heck, Ruida isn’t perfect here either so this isn’t just a Marlin thing…basically every laser remotely within the hobbyist range has this issue, Also the PWM fan thing is a non issue now; they updated it. Plus you could always use a different pin…I found 23khz works well and I think I’m using the pin meant to detect power failures.

RDWorks isn’t much more than a printer driver, but if you are doing your design in something else that doesn’t matter. As for that something else, it’s probably not LightBurn because LightBurn just isn’t as good at design as the free alternatives. It’s a bit of a problem…if RDWorks is a free printer driver and LightBurn is a $120 printer driver, LightBurn seems pointless…

…But if LightBurn could actually claim better quality output for just $120 then suddenly it’s a bargain.

I thought you said that you weren’t able to get inline working. Are you currently configured to use Inline as your Laser Control in Device Settings?

Not sure how you got that impression. The feature works very well and seamlessly under most circumstances. Most GRBL solutions drive diode lasers which generally don’t have a problem addressing power levels all the way down to 0 unlike CO2 lasers. This could potentially be an issue at low power scales on a CO2 laser with large changes in speed.

#define LASER_POWER_INLINE works, it doesn’t work perfectly and it is nothing compared to what is in a good DSP but it works.

#define #define LASER_POWER_INLINE_TRAPEZOID and LASER_POWER_INLINE_TRAPEZOID_CONT does basically the opposite of what it is meant to do…it ONLY burns the sharp corners and nothing in between.

From your description, the M4 on GRBL sounded pretty bad but I guess if I was just using a diode laser it might be different. Problem is that a diode laser that size is incredibly expensive…and it’s got lots of mass so I’d have to completely redesign the machine to handle the acceleration of engraving with it. Plus now I would have to use chilled water to cool a moving electronic part…CO2 just makes more sense in spite of the silly arrangement of bouncing mirrors.

And you’re using “Inline” in Device Settings?

Do you have a photo of the artifacts you’re getting? I’m curious about the severity of the problem.

I am using inline. The worst offender is this ruler design…shut down the machine before it finished when it was obviously bad.

That seems extreme. And no better than I’ve seen on systems not using inline but those are on diode lasers. I don’t think I’ve seen anyone using Marlin on a CO2 system.

I’m wondering if there’s not something else you could tune. Perhaps increasing acceleration if possible.

I’d love to increase acceleration but basic physics are against me; an 800mm long gantry is massive even when made of aluminum, X acceleration is better and the vertical version of this ruler looks better, but still not great even at about 3X the Y acceleration.

Marlin may be an odd choice from the stance of commonality, but if you look at features and price it’s a clear winner,assuming this problem can be solved.