I have been testing/evaluating LightBurn prior to purchasing . . . I am very impressed with the functionality and ease of use of the software and want to use it for both pen plotting/vinyl cutting and laser engraving/cutting on my CNC machine.
I believe I have identified an issue with how LightBurn interfaces and streams G-Code to the Arduino GRBL controller. I am running an Arduino Nano with GRBL 1.1f on an EleksMaker EleksDraw machine which has a simple RC Servo to raise/lower the pen/cuttter.
The issue I am experiencing is a failure of the Z-Axis RC Servo (pen holder) to reliably retract (using M3/M5 G-Code), when connected directly to and driven by LightBurn . . . however, if I save the G-Code file produced by LightBurn and send it to my EleksMaker with alternative G-Code sender(s), it works perfectly . . . accordingly, I concluded the problem is most likely not with the G-Code generated and/or how it is interpreted by the Arduino/GRBL 1.1f firmware.
I confirmed this assertion by manually sending each line to the EleksMaker CNC using a serial terminal program (Tera Term), which produced the expected and perfect behaviour . . . however, if I copy the 30 or so lines of my simple G-Code from the saved file and paste them (en-mass/all at once) into the serial terminal program, the Z-Axis RC Servo (pen holder) also fails to retract reliably.
The problem is repeatable and appears to be a timing issue related the sending of G-Code to the Arduino Nano/GRBL controller.
According to the documentation on GitHub ([https://github.com/gnea/grbl/wiki/Grbl-v1.1-Interface) GRBL requires one of two inferface strategies . . . either a) Simple Send-Response Streaming Protocol or b) Character-Counting Streaming Protocol.
Using a serial protocol analyser I was able to monitor the interaction between LightBurn and the Arduino Nano/GRBL controller . . . and, from looking at the data stream, I was able to confirm that LightBurn is not using the Simple Send-Response Protocol. What I observed was that LightBurn is transferring multiple lines of G-Code to which multiple ‘OK’ responses arrive back some time later . . . I believe this may be the underlying issue that is causing the unreliable Z-Axis RC Servo retraction issue.
I suspect this synchronisation issue has arisen because of the use of the Z-Axis RC Servo to drive the pen/cutter holder in this use case and the inherent ‘slow’ response to this device (compared to a laser). The problem may if fact be present in all LightBurn/GRBL interface scenarios, but simply not an observable problem/issue as the CNC machine manages to ‘keep pace’ with the transfer of G-Code.
I have two questions;
- Has anybody else experienced this problem?
- Is anybody able to confirm whether LightBurn has implemented the Character-Counting Streaming Protocol required by GRBL when the Simple Send-Response Streaming Protocol is not used?