For the Snapmaker 2 A350, Lightburn Core 2.1.03, Device Settings, GRBL-M3(1.1e or earlier) profile, the Target Buffer Setting is set to 64. Can or should this be changed for better performance?
P.S. Running via USB cable
Better performance in what way? If your controller is a DLC32 type, it is already way faster than the machine.
Do you know what the target buffer is?
Yes, better performance, It never seems to run at the speed specified in cuts/layers.
Thought maybe the buffer size adjustment might be an issue.
I have no idea what the controller buffer is capable of handling via USB.
This is because every direction change requires some degree of stopping and restarting, or at least slowing down and speeding up. It is not physically possible for the laser module to travel at the programed speed continously.
The correct statement is that it is unknown how fast the controller can empty the buffer. What is well known is that the controller can accept data and process it at a much higher rate than the motors can move the module around.
Of course, I do not have your machine, so it may not be behaving like what I have experienced. Your controller might be 8-bit instead of 32-bit like many machines are now. Double the Target Buffer size and see if it improves your situation. If not, change it back.
To see if you might have a controller parameter out of whack, clear the Console window (right click), enter $$ and then copy and paste the entire result in a Reply.
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
Thanks for jumping in with this detail. From what is posted, I has assumed it was a typical GRBL board.
I do not know the Marlin board, so thanks again for jumping in to help.
Sure thing. 
Though one correction, the Snapmaker Ray actually runs an ESP32 GRBL 1.1f board. The 2.0 and Artisan series run Marlin.
And then there is the A 350, not in your list… 
The A150/A250/A350/A250T/A350T are all part of the 2.0 series. The 150/250/350 dictate the size of the machine, but at the core, are all the same machine. The Artisan only has one size, but is the 3rd and currently final iteration of the Snapmaker 3in1 line.
EDIT: The Ray is a Laser only machine for clarification.