What is the performance?
For the 3dpBurner (like most laser engraving CNCs), the performance is the maximum real speed we can archieve for a work. The mechanics of a small 3dpBurner can reach about 17000mm /min without problems. That is, for example, we can send a Gcode sentence for engraving a straight line at 80% of the laser power at 17000mm/min of speed with success...But what would happen if instead a 80% power black line we want to engrave a black to white degraded line?
In that case we need to send a Gcode sentence for each line point with the appropriate coordinate and power (decreasing power), so the number of processing commands that GRBL needs to compute will increase exponentially.
The Arduino CPU is capable of processing a large number of instructions per second but has limits, if due to the amount of sentences by a time we exceed that limit, the effect will be translated into the GRBL buffer, that will be blank for some instants due the CPU is busy processig the previous commands. This will produce "micro pauses" in the machine motion and a jitter engraving speed, and constant speed is essential for laser engravings, it is not the same to keep the laser on a point 1s than 2s.
During all the 3dpBurner living project i have tested several GRBL versions and variants, including the newer GRBL v1.1, I have always obtained the best performance (top working speeds) with the actual 3dpBurner one, which is one of the GRBL 0.9 variants made by Alpharesearch some time ago for improving laser machines.
What GRBL version is better for 3dpBurner?
If you usually do not use the raster mode (point-to-point grayscale engraving) and your jobs are mainly vectorial ones (lines, curves and uniform fills) you can use GRBL 1.1 and you'll get jobs equal or better than with the current 3dpBurner 0.9 based fimware.If your main use is the raster mode you can get some higher speeds (micro pauses free) with the current 3dpBurner firmware and this is very appreciated.
Any plan for moving to GRBL 1.1?
On the same side there are also users who work with a third-party software for the 3dpBurner control and they reported me that some of these applications doesn't work with versions prior to 1.1.
Paralleling with the new 3dpBurner Sender revision I am also working in a GRBL v1.1+ adapted version and doing performance and stability tests to take all the advantages of the new GRBL features.
Probably, after releasing this revision the logical step is go for the new GRBL v1.1+ way.
I will publish news ASAP.
Some performance related notes:
The sender:
3dpBurner Sender it is not only a line by line sender application but also makes a Gcode optimization before sending the file, it parses lines to uppercase, remove comments, unnecessary spaces and bytes... this reduces the data stream and the GRBL computing tasks contributing with a better performance.It also makes an efficient use of the GRBL buffer by using the character counting method, a must for high speed works. That is why you can notice better results than using a generic CNC sender.
The 3dpBurner Sender interface is simple for the same reason. If you use any other software, i reccomend to disable the the drawing visualization and the Gcode live view log during your raster jobs, as this consumes resources. The simple fact of seeing the Gcode lines as they are executed or moving the form window with the mouse during the program execution is noticed.
The connection latency:
The performance is also seriously linked to the PC connection (USB quality cable) and to the communication channel latency, for example, Bluetooth connection has a lot of latency and is not recommended for raster jobs due a lot of micro pauses in motion (it is valid for vectorial mode).How can I check the performance?
-Send it to the 3dpBurner engraver (by USB cable connection) using the 3dpBurner Sender (it is a motion test so you can disconnect the laser wires).
-During execution, check the GRBL buffer on the 3dpBurner Sender status bar, it will be the mostly times full, this is at 17 for GRBL v0.9 and at 0 for GRBL v1.1, also notice the constant motor sounds denoting a constant speed.
-Now, cancel the job and use Notepad for editing the file. Look at the first lines and replace the F2000 line by F4000 (we have changed the feedrate from 2000mm/min to 4000mm/min), save the file.
-Send the modified file again and check the buffer. It's now unstable and the motors sound denotes a jitter motion. We have over passed the top speed limit.
We have to search that speed limits and always working below it in raster mode (unlike in vectorial mode), the max speed reachable will be linked directly to the raster resolution (0.1mm in this case), for lower resolutions, for example 0.2mm the working speed can be higher and vice versa. So we need to search that limit for each resolution we use.
