Some limited additional code driven by “SPINDLE_IS_SERVO” #define in “spindle_control.c”.Some further #definitions “SPINDLE_PWM_MAX_VALUE” and "SPINDLE_PWM_MIN_VALUE in “cpu_map.h”.Introduction of “SPINDLE_IS_SERVO” #define into “config.h”.In essence there are some very simple variations to the standard 1.1f version The version of GRBL I am using is “cprezzi /grbl-servo” ( ). 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?.Has anybody else experienced this problem?. 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 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). I believe this may be the underlying issue that is causing the unreliable Z-Axis RC Servo retraction issue. What I observed was that LightBurn is transferring multiple lines of G-Code to which multiple ‘OK’ responses arrive back some time later. and, from looking at the data stream, I was able to confirm that LightBurn is not using the Simple Send-Response Protocol. Using a serial protocol analyser I was able to monitor the interaction between LightBurn and the Arduino Nano/GRBL controller. either a) Simple Send-Response Streaming Protocol or b) Character-Counting Streaming Protocol. The problem is repeatable and appears to be a timing issue related the sending of G-Code to the Arduino Nano/GRBL controller.Īccording to the documentation on GitHub ([ ) GRBL requires one of two inferface strategies. 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. 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. 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. 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. 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. 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. I believe I have identified an issue with how LightBurn interfaces and streams G-Code to the Arduino GRBL controller. 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 have been testing/evaluating LightBurn prior to purchasing.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |