Laser head stutters during first engraved scan lines

Each engraving, regardless of image modes and/or scan speed, my laser head stutters like my smoothieboard is busy filling up its buffer or whatever. few seconds later all is well and scans are smooth. this does not reflect on the outcome. you cannot see any differences between first few lines where the laser head jitters to the rest of the image being engraved. speed is set to 100mms but seen this at any speed.

Where should i start looking for what can cause this?

Searched google to see if others suffer the same and found this thread which looks to be the same issue that I’m experiencing:

It’s likely just the buffer on the board filling up slowly. When using the new cluster firmware, LightBurn inserts an automatic delay in the GCode at the beginning of the scan to give the board time to buffer up some code.

If you aren’t using the new clustering firmware, 100mm/sec is actually too fast for Smoothieware to keep up if the image is heavily patterned, so that could be it too. Without seeing what you’re trying to engrave, it’s a guess.

Attached hereby is one of my engraving tests.ENGV-TEST.lbrn (66.6 KB)

the better looking butterflies were engraved using grayscale.
I found and downloaded the cluster firmware.bin but first I need to know if it can be used with my SKR 1.3 board.

It’s not officially supported, and the SKR board has a lower clock frequency than official Smoothieboards or C3D boards, as they used the cheaper chip. I haven’t tested it so I can’t say for sure if it will or not.

It looks like you don’t have overscan enabled (that’ll cause burning on the sides, though it might just be the butterfly art). If you lower your power a little, and drop the speed to 80mm/sec (if you’re using 254dpi) that will help get you more consistent speeds.

What made the difference is me lowering DPI from 635 down to 400 @ 100mms
i also added 1% overscan (i used that before for tests but results were not consistent).

Anyway, now no stuttering and the outcome is much nicer.
I like GrayScale much more than any Dither modes - more tuning is needed but the result worth it.

635 DPI on even a standard Smoothieboard is going to have a much lower maximum speed. At 400 DPI, with grayscale, you’ll get about (25.4 / 400) mm dots, or 0.0635mm. 100 mm/sec / 0.0635 is about 1574 gcode instructions per second, or about double what Smoothieware is capable of processing. 254 DPI makes a dot of 0.1mm, which is 1000 dots per second at 100mm/sec, or 800 dots per second at 80mm/sec. That’s why I suggested that speed.

Short version: you’re exceeding the processing limit of your controller by quite a bit. It’ll work, but it might stutter a bunch, depending on the image. If the image has long areas of the same color, it will emit less gcode because one instruction will cover more distance, and that will help it keep up.

1 Like

I hope adding start/end gcodes will overcome this initial buffering stuttering regardless of the flavor of smoothie firmware in use, unless this new cluster firmware is needed to support this preload feature.

I doubt it’s a buffering / preload issue - the DPI you’re using is exceeding the processing speed of a full speed Smoothie controller, and yours runs about 80% of that speed. I can add the delay command to the standard output for Smoothieware, but I would be surprised if it helped in your case.

You can easily test it yourself by doing this:

  • Load your file in LightBurn
  • Click “Save GCode”
  • Save the gcode as a txt file
  • Open the gcode in notepad
  • Add this line right at the top of the file:
    G4 P250
  • Save the file
  • In LightBurn, click ‘Run GCode’ and choose your file

Thank you Oz. Since stuttering is very noticeable only during first few scan lines i hope to see the effect of adding pause. Whether this will teach me something or nothing I will add G4 P250 just to learn a bit more about what goes on under the hood. You taught me quite a bit about how to calculate speeds and bottlenecks which will help me fine tune my current settings and to chose my next controller(s) wisely.
18 usd for upgrading my k40 with skr 1.3 just to be able to use lightburn is perfect combination to start with.



  1. How can i check the cache size on my SKR1.3 controller? is there a command to check that? i would like to load/fill up the buffer before job actually starts. There is this green progress indicator in LB laser control tab but I am not sure i can tell the actual amount free/filled.
  2. Are you going to add to next release a way to load cache before job starts, regardless which firmware I am running? i do no use the Cluster firmware, just the default Smoothieware firmware_cnc flavor of it. I was trying dwell command G4 P250 to no avail.


Smoothie (and other controllers) generally do this on their own. Smoothieware has a 32 entry planning buffer, and it doesn’t take long to send 32 GCode commands - it usually takes longer for the laser head to move to the start position of the job.

Stock Smoothieware will only process about 800 gcode values per second, so if you’re using 0.1mm dots (254 DPI), you can engrave at a maximum of 80mm/sec before you will occasionally stutter. It depends on the image being done - parts that are a perfect on/off 50% dither have the most gcode commands in the shortest space, so that’s where it will go slowest.

There is no command in Smoothie to tell it to buffer - I added the dwell because it seemed to help a little. If it does nothing on your system, nothing I add would be different.

If It takes 1000ms to process 800 commands, this means that on average 32 commands buffer size is like… 25ms long? that’s close to nothing. following this post of mine i search and found out that on LPC 1768 the USB is connected directly to the mcu - no driver, no cache, nothing.
I can only wish for faster STM32 controllers running @ 168Mhz (requires STM32 flavor of smoothie) and/or LPC 43xx mcu’s that runs closer to 200Mhz - that would be few steps up from LPC1768 based controller.

The new cluster support I added to Smoothieware extends the usefulness of the buffer by allowing up to 8 power values to be distributed across a single G1 move, effectively multiplying the available distance you can see ahead by 8x, but without significantly increasing the processing load.

The issue with raster engraving is that each of those tiny G1 moves is treated no differently than any other, but with rastering they all go in the same direction at the same speed, and only vary the power. Cluster mode takes advantage of this, reducing the planning complexity while increasing the look-ahead distance.

And yes, the buffer is insanely short. That’s why LightBurn fills the serial receive buffer on the target device as well as the plan buffer. When a move is pulled from the plan buffer, there is always data waiting immediately to replace it. It’s more complex to manage, but the performance gain is worth it.

I’ve run into much the same thing engraving on GRBL. With too high a speed v. DPI the planning buffer gets drained by movement faster than the gcode parser can fill it. When that happens and the steppers run out of things to do they just stop dead and without proper deceleration they can “skid” as the holding torque is exceeded by the inertia of the head. (A belt-system problem; I’d hate to hear the banging this would produce on a screw drive machine though.)

I’ve got a Due board with a 48mhz clock and native floating point support on the way which I expect will let me run at least 3x faster (clock speed alone) and hopefully 5x faster with FP support, but we’ll see.

Right now the only thing for it if a job skids is drop the DPI, run the head slower or add delays somehow. Laws of physics etc.

The motion planners are authored to not go faster than they can “see” - that’s why the planning buffer is significant. In the case of Smoothieware, for example, with a 32 entry plan buffer, using 0.1mm dots, you can see ahead 3.2mm. If your acceleration is set such that it takes you longer than 3.2mm to slow to a stop, you will never reach full speed - Smoothieware won’t let you, because the next entry to hit the planning buffer might be a 90 degree turn, in which case it would have to make that full stop in time.

If you’re seeing lost steps when pushing too hard, it’s likely that your acceleration is too high, and the inconsistent motion speed caused by not enough planning distance is causing resonance. GRBL only uses C1 continuous motion paths, so it’s not limiting jerk or jounce, so it will be more likely to have resonance issues. Even Smoothieware still gets them, but it’s less likely.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.