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?
LightBurn absolutely uses the character counting, fast streaming protocol, because that gives the best possible performance when doing raster engraving. Servo retraction isnât a standard feature in GRBL as far as Iâm aware. Itâs possible thereâs something that can be tuned, or changed to allow it to work, like a retraction delay, but youâd have to figure out what it requires.
I have an EleksDraw device here that uses an old version of GRBL, and has servo support, and it works correctly. Where did the version of GRBL youâre using come from?
In essence there are some very simple variations to the standard 1.1f version;
Introduction of âSPINDLE_IS_SERVOâ #define into âconfig.hâ
Some further #definitions âSPINDLE_PWM_MAX_VALUEâ and "SPINDLE_PWM_MIN_VALUE in âcpu_map.hâ
Some limited additional code driven by âSPINDLE_IS_SERVOâ #define in âspindle_control.câ
These all look fairly straight-forward and wouldnât seem to cause the kind of issue I am experiencing . . . although a prescaler on the 8bit timer has to be adjusted to 1024 to generate 61Hz (as close as one can get from the normal 50Hz for an RC Servo).
I did experiment with introducing âG4 P0.1â delays (dwell time) into the G-Code following the M3/M5 that I âbulk pastedâ into Tera Term . . . and that did indeed fix the problem . . . however, I donât see where I could introduce/configure this behaviour in LightBurn?
Other programs typically have post-processors that can be created/configured for required variation in G-Code generated.
Thereâs no way at present to do what youâre asking with the GCode system. LightBurnâs GCode emitter does a lot of internal state tracking to produce very compact GCode, so itâs not trivial to make a configurable post processor.
Do you have GRBL set to âlaser modeâ? If so, that might be the issue, because it wonât pause for spindle speed changes like it normally does.
I hate to punt, but ultimately youâre trying to use LightBurn to do something it isnât currently designed to do. I intend to add features to support vinyl cutting / plotting in the future, but they arenât there yet.
Modified G-Code THAT WORKS when âbulk pastedâ into Serial Terminal Program and transmitted to EleksDraw (simply introducing âG4P0.1â âdwellâ after M3/M5 G-Code fixed the problem).
Thanks for the quick and helpful response . . . I did try various combinations of GRBL/GRBL-M3 together with $32/Laser mode on/off, but non of these fixed the problem. GRBL-M3 gave the best result and $32/laser mode made no difference (to GRBL-M3).
The servo output (on D11) is the same output that drives the PWM for the laser . . . so, using GRBL with $32=1 results in a servo that bobbles up and downâ as it approaches corners and other areas where the travel slows down and the laser strength is modulated by GRBL (not optimal behaviour for a pen or vinyl cutter )
I have to say, I am very impressed with LightBurn . . . the tools/features/functions are great . . . and the seamless integration of CAD/CAM with CNC direct interface is slick, efficient and makes using it very easy.
I need to further play with import/export, as my first brief attempts to exchange designs/files with Vectric and Inkscape didnât quite work as expected (but that may be me).
I think the laser functionality/integration is excellent . . . I like this so much that I wanted to also use it for pen/cutter designs too
Exporting to AI or SVG should work fine for Vectric. (I usually use AI there). InkScape doesnât like the AIs I produce because the format is ancient, and InkScape is looking for PDF/AI, which is the newer (dramatically more complicated) version, but SVGs work there.
Is there any way that a âdeviceâ setting could be introduced alongside X & Y size specification that would allow switching on/off addition of a 'âG4P0.1â delay as part of the M3/M5 G-Code insertion?
This would seem achievable at a low cost/effort without having to significantly modify or refactor the GCode emitter . . . and would fix the issue (and any other associated requirement for timing adjustments following PWM/spindle speed changes).
No, I did spot that . . . and great news that I await the release of with some anticipation (on the back of an already great product.)
The only thing I have found that comes close to the integration you have achieved is the Vectric offering . . . but itâs handling and support for direct CNC integration is poor (and even more poorly documented).
Having identified that the underlying problem appears to be a timing issue in the modified (servo support) version of GRBL 1.1f, I looked for alternative solutions . . .
To use this, download the latest version of grbl (1.1g) from github and replace âspindle_control.câ with the version provided in the above link. You will also need to select/modify SPINDLE_TCCRB_INIT_MASK in âcpu_map.hâ to select the appropriate (61Hz) servo frequency rate and, of course, select/modify VARIABLE_SPINDLE in âconfig.hâ . . . all other required #define(s) are contained with the modified âspindle_control.câ. All lines of code that have been added to âspindle_control.câ are marked with a comment in column 100 of their respective lines. Apart from these 31 new lines of code (and an additional SPINDLE_TCCRB_INIT_MASK in âcpu_map.hâ), the rest of the grbl 1.1g source is unchanged.
The #define RC_SERVO_SHORT (15) and RC_SERVO_LONG (31), in the modified âspindle_control.câ, set the PWM duty cycle for the RC Servo to 2.05ms and 1.03ms respectively (these are recommended values for standard RC Servos). There is also a #define that allows the servo to be inverted if movement of the arm is in the wrong direction.
Note: the added RC Servo functionality will only operate in ânon laserâ ($32=0) mode and will be ignored if you have $32 set to 1 (however, the frequency SPINDLE_TCCRB_INIT_MASK set âcpu_map.hâ will still be 61Hz rather than the default 0.98kHz used by most diode laser PWM/TTL inputs). To use this functionality use G-Code M3 to turn on the RC Servo and G-Code M5 to turn off the servo. The amount the RC Servo moves is controlled with G-Code S commands in the range 0-255.
M3 S255 (turn servo full on)
M5 (turn servo off)
M3 S125 (turn servo half way)
M3 S0 (turn servo on full off - similar to M5)
)
