It has actually been enabled for the next release (1.2.02) already, and Ortur has added support to it for their firmware, and so has Tim Rothman.
Cluster on G code devices has also been set up to allow up to 16 brightness values per cluster, and it looks for [CLUSTER:xx] as a response to the $I command. If it sees that response, it pulls the number out of the argument there, and uses that as the cluster size, clamped to be a value between 1 and 16.
Oz (Lead Dev/Owner) actually replied to that thread on LaserGRBL’s github - however left the chat once it devolved into implementing full image processing on the controllers
Hahaha… This is a circular reference. Oz is the creator of Cluster. He enabled it in Lightburn for Smoothie about 2yrs ago and frankly it’s brilliant due to it being a simple and elegant solution acknowledging that dots are dropped at constant spacing with rastering. Now it’s ready for grbl which unlike smoothie frankly only needed the boost for the compressed dot size lasers to enable higher DPI without impact to speed.
Cheers!
I can see it in the patch update now, but it wasn’t there 2 hours ago (or im blind)
Added support for ‘Clustered’ GCode to GRBL devices (Ortur and Tim Rothman firmware updates will be supporting this)
I will test it at friday.
Ok and i can see it in menu as well if i set up device as GRBL but it isnt in GRBL-LPC.
I was having some troubles with LB communication with GrblHAL (needed to unplug device many times to connect) and setting it up as GRBL-LPC solved it.
So im using device as GRBL-LPC and because of this i found out that it is faster in rastering (on ESP32-WROOM MCU) then normal GRBL device settings - dont ask me why.
Maybe it should be allowed for all kind of GRBL controllers
You’re not blind, the post was updated Clustering is open and able to be added to firmware freely - developers are welcome to get in touch with us to enable it in their firmware.