Scanning Offset measurement from self-reading grid

NicholasL · July 11, 2026, 2:41pm

I’ve just been playing around with this calibration image which, when output (using bidirectional engraving, ‘Threshold’ mode, and 0.1mm line interval), should immediately reveal the correct “Line Shift” value for any speed you run it at:

This project shows how it can be used : scanning_offset_grid_v1.lbrn2 (328.5 KB)
It is currently set with power values to suit an 80W CO2 machine so adjust the power % to suit your machine:

How to use/example output:

Disable any existing Scanning Offset Adjust and run the “scanning_offset_grid_v1.lbrn2” test file, circle the sharpest most readable figures, these are your ‘Line Shift’ readings:

Where there are several in-focus, just bracket the sharpest group and select the middle one.

Enter those figures into your Scanning Offset Adjust and toggle on ‘Enable Scanning Ofset Adjustment’ :

Run the test again.

You should now see the edges of the rectangles are no longer fuzzy and all the other figures in the grid should be fuzzy except for the first few in the 0.00 row.

Notes

-The large numbers are filled with a vector outline intentionally to confirm the fill is in alignment with vectors (‘Initial Offset’=0).

-I used 200, 400 and 600 because I mostly engrave at around 400mm/s, and I’m happy that any other speeds will be covered by interpolation, for example, in this case:
300 will be 0.21
500 will be 0.32

-Don’t scale the image since the pixels are arranged to line up with a 0.1mm line interval. (It might be possible if you were careful to do the same with the line interval, haven’t tried it).

-Polarity: The calibration image includes a positive and negative sign at the start of each row, if you only see a (-) at the start of the row, then your machine is different, let me know and I’ll post a different image (or use the figure in the leftmost column). And if you enter the value but the results are twice as bad, then change the polarity (-/+) of the Line Shift entry in LightBurn.

ednisley · July 11, 2026, 4:18pm

Definitely the case with a KT332N controller with a 500 mm/s speed limit:

The measured values I’ve been using seem fairly small:

NicholasL · July 11, 2026, 5:08pm

Try this one, but ignore the polarity when you enter the figures:

scanning_offset_grid_v2_dual_500.lbrn2 (195.9 KB)

bernd.dk · July 12, 2026, 11:35am

Thanks for the nice test. However, I have more difficulty finding the appropriate number than comparing the ends of the lines.
With a good magnifying lens and a little patience it works.
And for the final fine tuning, patience is always needed.

ednisley · July 12, 2026, 12:25pm

Looks better:

The best matches over on the right agree closely with my original values.

The sign, as you suggest, is wrong, but the KT332N has other peculiarities.

Being me, I want more granularity in the speed, maybe steps of 100 mm/s from 100 to, say, 700 mm/s for the speed demons out there, but that’d make a daunting layout.

Aye, but … those tools seem in rare supply.

bernd.dk · July 12, 2026, 1:51pm

Because I don’t know how precise LB interpolation works with my machine, I’ve done tests with 50mm/s interval.
Although I also end up at 500mm/s, on my machine (same as @ednisley ) it is unrealistic or better said, not advantageous. Between 250 and 300 mm/s for not too big shapes, is the breaking point where higher speed means higher total times.

MikeyH · July 12, 2026, 3:59pm

Those users trying to run at Warp 8 need to read this thread.

bernd.dk · July 12, 2026, 5:24pm

I might have to make a little video about it sometime, it usually works best on people’s (our) understanding of how things are connected.

MikeyH · July 12, 2026, 8:45pm

Please do! I have a C:\Lightburn\Projects\User Helpers\ folder that is chock full of video URL’s, Doc’s, and Images I have built to call upon. The way you guys serve up information and solutions, I am guessing you have the same.

NicholasL · July 13, 2026, 12:38pm

Here is an updated version of this tool. I discovered a mistake with the last one, I realized that it wasn’t actually being sent to the machine at the resolution I was expecting (the line interval was affecting/capping the horizontal resolution).

This one works at a higher resolution, so is more accurate. I’ve added in extra bands, at 100mm/s intervals, but not to 700mm/s - anybody can modify this project and duplicate the 500 image to use with faster speeds if needed (all the images are exactly the same and have just been duplicated and cropped for the lower speeds to save time).

scanning_offset_grid_v3_dual_500.lbrn2 (248.5 KB)

Test result:

Line Shift Entry:

Note: I set 500 to slightly more than 0.31 just to keep the interpolation working correctly for the higher figures.

Final result with Scanning Offset Adjustments enabled:

You should see crisp edges on rectangles and the first row of each block.

bernd.dk · July 13, 2026, 2:26pm

That gives me a bit of a problem..

jkwilborn · July 13, 2026, 2:33pm

That’s nice, a lot of work, thanks for posting it and the .lbrn2 file.

I have to make a certain point that seems to go unnoticed, in that the failure or variations depend on the whole line of components operating together.

If you get a car that the engine and rear end will run 100 mph, but the transmission is only good for 50mph, how fast can you go? Over 50mph you’re transmission isn’t going to function optimally.

Same with these. Controller → lps → tube. There’s not an issue with the Ruida as it works at very high speeds. The Chinese build lots of stuff, but, usually they do the minimum they have to do to make it work. The lps passes inspection if it responds to 90% placard voltage in <= 1ms. An RF machine has a response time in the nano seconds, not milliseconds, like a glass tube.

If you use worst case values of 1ms, then at 1000mm/s, the best you could expect is the ability to turn the tube on/off is only once per mm. So the best you can possibly expect is 25.4dpi.

500mm/s you’re resolution doubles to 50.8dpi.

Although my machine has been greatly lightened, mass wise and I run a very high acceleration value of about 45,000mm/s^2, I have run it at 1650mm/s, which was purely academic. However you start to notice a slight degradation to the results once you exceed ~500mm/s. As I believe I’m reaching the lps speed limit, but figuring out the actual response time of the lps/tube combination is not so easy. I limit any kind of scanning graphic at about 300mm/s to ensure it’s all working properly. I did a video of a test using the companies suggested 35 inches/s (889mm/s) here. It’s rather long and I think, I got poor results.

This was the graphic, unfortunately I lost the results (photo) of the test… I believe it’s on one of my pair of disks that got corrupted.

I think this is pretty clear from the test results, as the scanning offset makes up for the lps → tube response time.

Haven’t tried but I don’t think you need to have the tube on the whole time, just at the begging and end of the whole line. Might be worth trying to make a pulse type pattern, dot/dash, to try and figure out how fast it’s responding. Although your text might be showing it. All you really care about is on time/off time for the tube to start up, doesn’t really give you the kind of information you need, at least not directly. If you do solid lines, then the once the tube turns on it runs at that power until the line is turn off.

Your work is greatly appreciated… I’ll try to dig into it a bit more when I get the chance.

ednisley · July 13, 2026, 3:56pm

Ran without complaint here with “the same” KT332N as your machine.

Apart from flipped signs (which may be an intractable issue), the results again agree with my previous measurements:

I dial the power back to 10% under 300 mm/s, but the tight line spacing hits the cardboard hard and the 200 mm/s image is overcooked.

bernd.dk · July 13, 2026, 5:10pm

I’m on the latest Beta version of LB, but I get what I sent, it’s strange.
The modified test, with a line spacing that makes more sense, I get this result. I also had to adjust the power setting a little.
But, I don’t get any usable example with these settings and without offset compensation.
On the left is the same engraving with my correct offset compensation values, on the right without.
I will try later on white cardboard, but the error message/warning I don’t know why it’s only here with me.

NicholasL · July 15, 2026, 11:10am

Ignore that message and don’t change the line interval, otherwise it won’t work. The line interval is ridiculously small to make sure the bitmap is processed at a higher resolution. I does result in a lot of activity which is a pain, but still works if you reduce the power.

Alternatively, try running this image with “Pass-Through” enabled, it will use the high resolution of the file to resolve the small horizontal shifts, and with the help of Claude I “thinned” the image by 75% to prevent the small line interval that was hurting the last version. There is a thin “timing” band on the left hand side (don’t crop it out, or change the size of this image), intended to keep the return scan at a regular interval so the polarity feature stays intact.

bernd.dk · July 15, 2026, 12:03pm

ok, I’ll try it as soon as possible, thanks

bernd.dk · July 15, 2026, 2:05pm

Hi Nicholas, I have repeated the test as recommended and can clearly see the difference, even though it is on MDF, which is not particularly suitable for this type of tasks.

There are a small error in your version 3, 100mm/s has become 200mm/s…, but I could easily fix that

On the right material you can quickly and easily find the clearest values, then just choose the middle one.
It should be included in the LB official test series.

Thanks

NicholasL · July 15, 2026, 2:56pm

Thanks, good spotting, I’ve updated that, and added an example on the right side using the newer (faster) grid.

scanning_offset_grid_v3_dual_500.lbrn2 (307.2 KB)