Request for Fast Carriage Return

Using the typewriter analogy, when engraving in 1 direction (bidirectional off) the laser moves at the engraving feedrate during the “carriage return”. This makes the “carriage return” while not engraving painfully slow. Think of a typewriter and the typist having to wait it basically doubles the engraving time. I need this because I cannot fully account for everything with scanning offset adjust as there is sometimes backlash changing the laser height and other things that change over time.

If the carriage return is not a separate feedrate it should at least use the “fast whitespace scan” feedrate.

Thank you!!!

You can set your travel speed. Maybe you have it set at homing speed?

@Bonjour, the travel speed during the carriage return is based on the engraving speed. I wrote a python program that fixes this, but I’d like it as a feature.

When not engraving it makes no sense to go so slow.

Enable Fast Whitespace and set a speed for it:

It does do exactly this on my version - I’ve verified by saving the gcode to a file:

; Scan @ 100 mm/sec, 20% power
G1X7.14F6000S200           ; cutting move at 100mm/sec
G1X-7.14Y0.1F18000S0       ; return move at 300mm/sec
G1X7.14F6000S200           ; cutting move at 100
G1X-7.14Y0.1F18000S0       ; return move at 300

Is that not working for you?

1 Like

Oz, it’s definitely using engraving speeds for the carriage return. I’m engraving at 1200mm/sec with fast whitespace scan at 3000mm/s. The image that I’m using has limited whitespace and you’re seeing the overscan with F3000. The carriage returns are the longer movements.

2 ; GRBL device profile, current position
9 G1Y-2F3000S0
10 G1Y-0.24F1200S54
1817 G1Y-2F3000S0
1818 G1X0.08Y164.39F1200S0
1819 G1Y-2F3000S0
1820 G1Y-0.24F1200S54
3627 G1Y-2F3000S0
3628 G1X0.08Y164.39F1200S0
3629 G1Y-2F3000S0
3630 G1Y-0.24F1200S54
5409 G1Y-2F3000S0
5410 G1X0.08Y164.39F1200S0
5411 G1Y-2F3000S0
5412 G1Y-0.24F1200S54
7203 G1Y-2F3000S0

Which version of LightBurn are you using?

I’m seeing this on and I believe it’s consistent with previous versions.

You said, “the image that I’m using” - are you burning this in Grayscale mode, by chance? The output you’re showing has some moves at the 3000 feed rate, and some at the 1200 rate, so it’s obviously doing something. Are you engraving along Y, or along X? Those moves look like they’re primarily along Y, though that shouldn’t matter.

Oz, you’re seeing 2mm overscan for a short distance at the speed of fast whitespace scan (3000). This is correct.

The issue is you’re also seeing a carriage return of about 165mm at the speed of engraving (1200, not at the speed of fast whitespace scan) and it is sloooooooooooooooooooow.
Thank you.

You can also tell the carriage return because on the same line there is also a 0.08mm stepover which corresponds to the scan interval (0.08mm or 318 dpi).

You skipped right past the important part of that post.

Yes, I’m engraving grayscale. Scan angle is 90deg, so it does G91 (incremental) movements with DeltaY=0.08, then when it reaches the end of the image, it takes extra movements in Y for overscan of 2mm. Then the carriage return includes a long movement in Y, and a stepover of 0.08mm in X.

That’s the issue then. With grayscale, pure white is still valid, as it might be a non-zero min-power setting. If you want areas skipped in grayscale mode, make them transparent, and save the image as a PNG with the transparency intact and that will work.

Oz, it actually has nothing to do with the image or grayscale.
It has to do with 1 directional scanning (bidirectional turned off)

Per your comments Fast Whitespace scan speed should be in all 3 of these conditions:

  1. you hit a blank area on the image (or it has a transparent background), it does this correctly
  2. when you are in the overscan, it does this correctly
  3. After it has engraved all the pixels in a row (or column) and steps over to the next row (or column), when engraving in one direction it will perform the carriage return, this is a very long movement and the length of this movement is image size+2*overscan distance. It does not do this correctly.

The correct Gcode should be for line 1818 above
Instead of G1X0.08Y164.39F1200S0
Remember that you use G91 movements (relative), so the machine moves almost 165mm at engraving speed the the laser off and it doubles the engraving time with bidirectional turned off. If it used the higher speed it would only increase the engraving time by about 40% (1200/3000).


So you have tried this with a different image mode, like dither, and it did not use the fast whitespace scan for the return then either?

FastSkip.txt (8.4 KB)

This is two images, both grayscale. The top one is a solid white background and the bottom is transparent:

They’re about 7mm across, and done with a 0.2mm pixel size, with the gcode posted above, bidirectional scanning off, and you can easily see the 5+mm return moves using the faster speed on lines 14, 31, 45, etc.

So either this is something that has been fixed in the version I have, or you have something funky with your settings. I’ve looked through the code history and found no recent changes, but it’s not impossible that I missed it.

Oz, I have the same issue with the images you posted in grayscale or dither.
I don’t see the issue in the gCode you posted!
It must be the version you are using.
Looking forward to the next revision with this fixed.

Also looks like you debug the same way I do… let me guess… how many 1000 times have you generated gCode for that image?

I have quite a few different images I use for different tests, but yes, that happens a lot. :slight_smile:

Sorry Oz, I found out the dependency. Overscan turned on/off will toggle the result. If Overscan is turned on it will do the carriage return at engraving feedrate instead of at “Fast Whitespace Scan” speed. If overscan is turned off it will do the carriage return at “Fast Whitespace Scan” speed as expected.

thank you.

That was it - this is fixed for the next release.

1 Like