Lightburn is generating Gcode with the following format:
G1Y66.464S200F6000
I need it to generate data in this format for saving to a file:
G1 Y66.464 S200 F6000
I suspect that there is a simple answer, but I can’t find it.
- Edward
LightBurn does not allow user-based changes to the GCode, and there’s currently no option to add whitespace - The GCode spec dictates that it is not required, and it wastes bandwidth, so we don’t emit it. What is it that you need the spaces for?
1 Like
As I am building a DIY CO2 laser, I am also building an alternative to the ‘Ruida’ controller. Why? Versatility, cost and a ‘the journey is the destination’ pastime. The underlying software is OctoPrint on a Raspberry Pi, with 5" touchscreen as the physical interface.
I’m including features like automatic X/Y squaring, water flow monitoring by quantity, fan speed according to material and/or smoke density, etc. Things that a Ruida doesn’t offer.
As far as I can tell, OctoPrint expects spaces between commands, since that is how virtually every slicer out there formats its gcode.
The lack of spaces also breaks various utilities that are used for massaging / displaying gcode.
A choice between formats as Lightburns’ output would be nice.
What do you plan to use this laser for? I can say with absolute certainty that a Ruida controller will run laps around every GCode controller out there, for speed. If you plan to do photo engraving, GCode controllers will limit you greatly.
That out of the way, I’ve been considering adding an option to add spaces to the generated code, and we’re also (slowly) working on a generic GCode editor. Both of those would be applicable here.
Thank you for your reply, it gives me plenty to think about.
I think that I saw you on a YouTube interview, and that you mentioned that once the design is processed into Gcode by Lightburn, Lightburn is essentially done with it, and that the laser controller basically takes over and independently processes the Gcode that Lightburn generated and fed (or feeds) to it. Correct?
Given the advances in controllers in the last few years, with faster processors, more memory, advanced stepper drivers, optimized mature software, I am intrigued by the possibilities of newer hardware. It would seem that we are a point where mechanical hardware limitations would be more significant than software/controller limitations in terms of throughput.
Do you give the Ruida Gcode? Is it not a Gcode controller? Just wondering what the big difference is between a Ruida and other Gcode controllers.
(FWIW, (without sounding too smart-allecky) not including whitespace seems that it would be significant in the days of 9600 baud and parallel port hookups. When the common connection speed these days is 250K over USB2, well…)
That’s the connection speed from the computer to the USB chip on the controller, true, but the communication from that chip to the actual brain on the board is typically still done at a lower baud rate, and parsing text consumes cycles as well. Call it what you like, but LightBurn was written to be as fast as possible across a wide range of devices, not just ones we favor.
Ruida controllers don’t use GCode - they use a binary protocol, and they run extremely specialized firmware on Altera Cyclone FPGA chips. They’re capable of running rings around even the best GRBL implementations out there. 14 bit PWM instead of 10 bit, with a 20KHz PWM cycle instead of 1KHz, plus the ability to specify a minimum power level per cut, as well as a maximum, which gives much better control of a glass-tube CO2.
There are lots of other reasons they’re better, and a few minor ways in which they aren’t (infinite stream length is something they don’t do, for example, but GRBL will).
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.