The Snapmaker is running as fast as it can. In fact, it’s running faster (in technical terms, not really noticeably) than it’s natively supposed to. It chokes on itself from how Snapmaker set up the firmware.
This will not help, the controller in the Snapmaker series is running Marlin. However, it’s slightly modified and will run GRBL motion code, which is a lot cleaner, thus my earlier statement about it ‘technically’ running faster than native. Cleaner code is usually faster.
From what I understand, Marlin handles the command buffer differently.
GRBL will send an ok command back after it’s given a command and successfully parses it. However, if you know the buffer size (which Lightburn checks on connect) it can preload the buffer and then it knows every time it gets an ok from the controller, there’s an empty slot and can fill it so the controller never has to wait on commands to parse.
Marlin handles the buffer as follows. It replies ok when given a command, and puts it in the buffer of unparsed commands. Which then gets pulled when the machine gives the controller the ok to parse another command. If the machine is still processing a long command, then the buffer will backlog and then marlin will send a wait command, telling the host it can’t accept any more commands to the buffer.
Essentially Marlin takes this buffer step and controls it on its own, keeping its own buffer full. So in either scenario, Lightburn is still sending code as fast as it can and the machine is parsing it as fast as it can.
Now, for the actual Snapmaker 2.0… In my testing, the receive buffer can only accept 127 bytes. (but will only parse commands up to 96 bytes) This is another reason for using the GRBL profile. As the built-in Snapmaker profile generates a thumbnail, which, when sent over USB is over said 127 bytes and will cause the controller to refuse it and stop. This is not just a Snapmaker problem, it’s just the serial buffer limitation. It matches my XTool D1 Pro. Those findings can be found here;
As far as the command buffer itself, according to the controller source code it’s been limited tooooo… 4. However, if you run code via the control screen (HMI), either by uploading to, USB stick, or my drag/drop (or similar) run methods, the command buffer is increased to 8.
// The ASCII buffer for serial input
#define MAX_CMD_SIZE 96
#define BUFSIZE 4
#define HMI_BUFSIZE 8
#define INVALID_CMD_LINE 0xFFFFFFFFU
This was pulled from the source code found here. Given you get double the buffer size using the touchscreen, that will be the fastest way to run code.
EDIT: It can only hold 16 commands in the parsed motion buffer. So the controller can hold 20 commands via USB and 24 via HMI at any given time.
// The number of linear motions that can be in the plan at any give time.
// THE BLOCK_BUFFER_SIZE NEEDS TO BE A POWER OF 2 (e.g. 8, 16, 32) because shifts and ors are used to do the ring-buffering.
#if ENABLED(SDSUPPORT)
#define BLOCK_BUFFER_SIZE 16 // SD,LCD,Buttons take more memory, block buffer needs to be smaller
#else
#define BLOCK_BUFFER_SIZE 16 // maximize block buffer
#endif