Seeing Double - Lightburn "Scanning Offset Adjustment" woes

After upgrading the 2.5W laser diode on my primo to one of those new Neje 40W modules, I have been “seeing doubles” on my fills. After some research and careful observation, I realized the cause was the Neje laser consistently turning on too early. Using bi-directional scan in lightburn, the result is doubled images along the scanning direction. This makes lightburn just about useless for etching.

Here is an example of a cube that should with a doubled “100” on the top:

So after some reading up, I ran a scan offset test on the rig, which shows the laser turning on too early using the default “offsets disabled” in lightburn (bottom most like is drawn from left to right, alternating as it goes upward on each area):

Here is some background info on how this tuning procedure works:
https://lightburnsoftware.github.io/NewDocs/ScanningOffsetAdjustment.html

Note the numbers above are feedrate in XXXXmm/min, and the Lightburn “Scanning Offset” used for that speed (at 60% power on the 40W module for those interested). These scan offset settings are found under Lightburn “Device” configs. Lower accelerations can result in the gantry not moving at the correct speed at the moment of on/off trigger. To eliminate this issue, the “overscan” settings is maxed out to 50% on lightburn. This gives the gantry time to get to the listed speed before it operates the laser. At 6000mm/min observing motion it was hard to tell if the gantry was 100% up to speed when the laser went on/off. The other data points I could tell were definitely up to speed based on audible observation.

After some measurements and test iterations, I was able to come up with a list of feedrates/offsets to produce this seemingly OK test (a careful eye can spot some variance in the start/stop points, which I can’t explain other than mechanical flex?.. however the relevant alternating patterns are pretty much invisible now):

For completeness, here are those values from lightburn:

Now, after completing this “scan offset tuning” mission, I was excited to start producing some neat stuff. Unfortunately there are still “doubled up” artifacts on my etches, despite lines/cuts appearing perfectly.

As can be seen in the second image, it seems lightburn by default is assuming some value of latency, as the laser seems to be turning on the same time (too early) before it should; higher speeds have more offset, lower speeds less, and the relationship appears linear. However, my final values based on testing are not linear. Whatever it is lightburn is “injecting by default” seems to be borking the operation of the Neje laser.

To make matters worse, I think this method of “predicting” the motion does not work at all with our CNC machines. The reason is the cnc control itself is modifying it’s planner to stay within firmware limits. So even when we send the same gcode to 2 different machines, they won’t necessarily do that at exactly the same time/space profile, depending on acceleration limits etc. So when lightburn assumes it has to change the laser earlier or later, it has to make assumptions about what happens in the planner, and those decisions are literally disconnected from what is actually happeing in the controller as the cnc moves.

So we pretty much are fudging on that scan offset test, by using overscan to ensure accurate speed at the test point. The problem with that, is during a real etch, there always will be some accel in the middle of the scanline, especially at higher resolutions and feedrates, where the MCU has trouble keeping it’s buffer filled. The planner (both grbl and marlin) will reduce feedrate to ensure the buffer doesn’t have to pause for a refill. Since the gcode lightburn created has assumed we would be moving 2000mm/min the whole line, in this example that gcode has a 0.35mm offset built in to the start/stop points along that line. So when marlin/grbl hit buffer limits and slow down, now those offsets are too high, which results in doubling artifacts.

Now after all this work and thought on getting my Neje to etch nicely… I’m wondering how the heck I was able to just plug-n-play with my 2.5W laser without having to deal with this. Does anyone know if there was some assumptions made about latency based on older diodes in lightburn? Has anyone else run into this with their Neje? Conversely, if anyone has had great success etching dithered or greyscale images with their Neje, could you share some details?

I figured I’d run this across you guys before stinking up the lightburn forums and getting a canned response lol.

[edit: I realized I never mentioned my relevant firmware parameters… I’m using GRBLesp32 on a 6-pack, with laser mode enabled, accelerations limited to 127, xy speed limit at 7500, and z speed at 2000. I also have my motors set to never idle.]

2 Likes

OK, I really need some help now… my laser seems to be predicting the future!!!

I checked out the gcodes in ncviewer, and they all look fine! I don’t understand how it’s possible for my fluidnc controller to cause this (no laser delays added etc). Here’s a sample greyscale wheel that doubles up on me:

greyscaleWheel.gcode (61.9 KB)

You can check it out… it doesn’t have scanning offsets included. So it should print fine… but the Neje seems to be turning on too early… or the x position is arriving too late!!! I couldn’t imagine it being the latter, as that would imply missed steps, and if I put cuts before and after, they line up perfectly.

Hay kev, i unfortunately cant offer any help, but i can comiserate. I am having the same issue with my neje 10+W laser. I agree with all your observations and conclusions. If you find any new information, please share.

@Atom , would you happen to be using fluidnc? I ask because in my case the issue was came up after fluidnc defaults changed the stepper engine from i2s_static to i2s_stream. Using stream resulted in some issues with timing of the laser and steppers. Switching back to static fixed it for me. Then I was able to remove all the offsets I played with in lightburn and get perfect etches (well, positionally perfect :wink: ).

Sorry I didn’t add this info to this thread earlier… I was all over the place when I was trying to troubleshoot it, and lost track of all my posts.

1 Like