This page describes FluidNC support for clustered S values in linear GCode moves.
Clustered GCode allows a sender to place multiple colon-delimited spindle or laser power samples on one motion line instead of emitting one short move per sample.
Clustered GCode is mainly used for raster-style laser engraving, where power changes much more often than motion direction. Instead of sending one G1 command per pixel or per tiny segment, the sender can encode several evenly spaced power samples on a single linear move.
Example:
G1 X0.961 S256:260:268:262:262:262:266:260:264:256:256:264:268:268:264:266
In that format, the move endpoint is still defined normally. The clustered S list supplies evenly spaced power samples across the distance of the move.
The main purpose of clustered GCode is to reduce streaming overhead during high-resolution engraving.
Without clustering, a sender may need to transmit many very short moves with frequent S updates. That increases serial traffic, parser load, and planner pressure. With clustering, the sender can transmit fewer motion lines while still varying power across the move.
This is most useful for:
FluidNC keeps the feature narrow and compatible with normal motion semantics.
S syntax is accepted on linear moves.S scaling is preserved through the existing spindle pipeline.$I reports [CLUSTER:16] so compatible senders can discover support automatically.This approach avoids introducing a separate raster mode or a new transport protocol.
For senders, the important points are:
$I as [CLUSTER:16].S samples FluidNC reports to senders.1..16.Clustered GCode appears to have evolved as a practical interoperability feature rather than as part of a formal GCode specification.
Public discussion around grblHAL and LightBurn describes the format as colon-delimited S values on a single linear move, added to improve raster throughput on slower controllers. Jason Dorie of LightBurn later described the feature as a practical workaround that originally targeted Smoothieware limitations.
Confirmed public references indicate support in the following ecosystems:
LightBurn initially looked for [CLUSTER:8] during early rollout, but later support expanded to up to 16 clustered samples per move. For current interoperability, [CLUSTER:16] is the correct capability value to advertise.