Clustering was a thing I came up with to reduce the overhead required for planning a raster engraving job, originally for Smoothieware, but it’s been included in a couple of GRBL systems now too.
GCode based systems use a motion planner - this is the thing responsible for keeping the system within the limits of speed and acceleration set in the settings. If you tell it to draw a rectangle, it’s the thing that decides when it’s time to slow down before getting to a corner, and how long to take to speed back up again.
Any system that uses streamed GCode has a “plan buffer” that sits between the software and the firmware, holding moves that are coming but haven’t been executed yet. Each time a new GCode instruction is received, it gets added to the plan buffer and the planner looks through what’s there already and makes decisions about how fast each move can be allowed to go, just in case the NEXT move (that hasn’t been received yet) tells it to stop. You always have to be able to “see” far enough ahead to come to a stop within your desired acceleration setting.
Imagine driving a car around a blind corner at night on a road you’ve never taken - you probably slow down, just in case the part of the road you can’t see yet has a red light.
Smoothieware has a short buffer (32 moves) and each new move added to the buffer triggers a re-evaluation of everything before it, and it’s kind of slow. If each move is a single pixel in a grayscale image, and the pixels are 0.1mm, that means you can only see 3.2mm ahead. If you ask the thing to run at 100mm/sec, and the acceleration isn’t too fast, it can easily take more than 3.2mm to get up to (or slow down from) that speed, so you’ll never actually reach your desired speed.
Clustering changes this - Since all the pixels are going along the same line anyway, it uses one bigger move that’s 10 pixels long, and just plops the 10 power values on it all at once, instead of using 10 different G1 moves. Longer moves with multiple power values means the planner can see farther ahead, and it takes less effort to re-plan, and it takes less bandwidth to send it over the USB too.
“10” in this case is sort of arbitrary. We started with 8, because that’s what would fit in the limited RAM Smoothieware had available, but LightBurn supports clusters of up to 16 brightness values. A single cluster is also not required to use all of them, and normal GCode (with a single power value) is supported transparently.
TL;DR: Less computation, and can see farther ahead, meaning the machine will run faster and smoother, and take less bandwidth to do so, all in a way that still allows things like engraving along a diagonal, and support for grayscale. It’s also super simple for firmware coders to add.