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. INKSCAPE GCODE FOR ELEKSMAKER SERIALUsing 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. INKSCAPE GCODE FOR ELEKSMAKER SOFTWAREI 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 |