G-Code alternative.

[DavidS]

G-Code is a very good human readable way of representing commands to a 3D printer. Though it is big, many times larger than it needs to be to do its job. I have taken a very close look at this while I write what is going to be the release version of my 3D printer firmware.

Microcontrollers have limited RAM, this is well known. As such G-Code is a huge pain, as it has to be loaded while being used.

My solution is to create a binary control language. As I comment my code to show what works so far, here is a simple outline of my control language, extracted from the comments in its parser source code:

'Command processor.
'This uses a simple set of byte commands.
{The Commands are one byte folowed by one or two bytes of data.
 The current commands are:
 
 00nnnn = Move X, forward.
 01nnnn = Move Y forward.
 02nnnn = Move Z forward.
 04nnnn = Move X reverse.
 05nnnn = Move Y reverse.
 06nnnn = Move Z reverse.
 08nn   = Set Current X Speed.
 09nn   = Set Current Y Speed.
 0Ann   = Set Current Z Speed.
 0Bnn   = Set Current Extrusion Speed.
 0Fnn   = Set Current Extruder Temperature.

 10 = Zero X.
 11 = Zero Y.
 12 = Zero Z
 14 = Set current X position as Zero.
 15 = Set current Y position as Zero.
 16 = Set current Z position as Zero.
 18nnnn = Set current X position as nnnn.
 19nnnn = Set current Y position as nnnn.
 1Annnn = Set current Z position to nnnn.
 1Cnnnn = Set Maximum X position to nnnn.
 1Dnnnn = Set Maximum Y position to nnnn.
 1Ennnn = Set Maximum Z position to nnnn.

 20nn = Select Extruder.
 21nn = Set Current Feed Rate.
 22nn = Set Heat for current Extruder.

 30 = Set Simulation Mode (does all the X/Y/Z movements, with the extruder turned off).
 31 = UnSet Simulation Mode (back to regular print mode).

 80nnnn = Set repeat counter.
 81nnnn  = Decrease repeat counter by one and go back up to 65535 bytes if repeat counter not zero.
 84nn   = Set small repeat counter.
 85nn   = Decrease Small Repeat Counter and go back up to 255 bytes if small repeat counter is not zero.
  
 F0 = All Stop.
 FF = Print Done (Turn off extruder(s), zero X and Y, move Z to maximum)..

}

Likely this does not show how much is saved. Obviously the more repeated layers the more that is saved.

Here is a commented hex dump of a 57 Byte cube measuring 256 units cubed in this new command language, that works with my 3D printer:

CUBE: HEX DUMP Commented.
21:00:22:72:  ;Setup extruder, wait for heatup.
10:11:12:     ;Zero XYZ.
00:00:10:     ;Set X start pos .
01:00:10:     ;Set y Start Position.


80:00:40:     ;Setup number of repeating layers (64 in this).
;Next draw a solid square:
21:7A:        ;Start extruder.
84:40:        ;Setup small repeat 64 times.
00:01:00:     ;Draw 256 steps X.
01:00:04:     ;4 steps Plus Y.
04:01:00:     ;256 Steps negitive X.
01:00:04:     ;4 steps plus Y.
85:0C:        ;Small Repeat last 12 bytes 64 times.
;Now add a layer.
02:00:08:     ;Raise Z by 8 steps.
84:40:        ;Setup small repeat 64 times.
00:01:00:     ;Draw 256 steps X.
05:00:04:     ;4 steps -Y.
04:01:00:     ;256 Steps -X.
05:00:04:     ;4 steps -Y.
85:0C:        ;Small Repeat last 12 bytes 64 times.
81:00:23      ;Repeat last 35 bytes, 64 times.

FF            ;Print complete.

Pretty good.

Now the calibration cube that some 3D printer companies provide (with the 5 steps diagonally by five teared steps), that is only 861 bytes in size using this binary command language. That is 54 times smaller than the G-Code version.

The idea is to create a program to convert G-Code into this new command language, to get started. Then eventually create slicers that directly produce this command language instead of G-Code. Either way it will not take long to get this into use.


This coding format is open to anyone to use, no warranty of any kind.

[soofle616]

Ok legitimate question, Why bother?

You say that g-code is much larger than needed from a microcontroller's perspective, ok fine, I accept that. But what benefit does shrinking the file actually have? SD cards aren't wanting for space so having multiple files on a card isn't a concern. Printing speed, at least for fdm and sla machines, is limited due to mechanical or material properties so having a lighter weight file that is easier to process isn't going to speed things up at all. I can see the potential for better print quality from a delta machine but only in the case of curves where existing firmwares are calculating a bunch of smaller lines that emulate a curve. Having a file that is quicker to process could allow for more calculations allowing for shorter lines and therefore smoother curves but it is my understanding that this really isn't a huge concern for the most part. So I'm just curious why you're putting in all this work and what you hope to gain from it. If it's an exercise in "because i can" then by all means continue with your work and I hope your results are good.

[adamfilip]

A huge undertaking. I can appreciate the efficiency improvement and reduced memory consumption. but the current system works. and with microcontrollers getting cheaper and more advanced with larger amounts of memory is this really necessary.
it would be quite a battle to get Slicer companies to adopt this. and turn it into a standard.

gcode is used for many industries

[DavidS]

Ok legitimate question, Why bother?

You say that g-code is much larger than needed from a microcontroller's perspective, ok fine, I accept that. But what benefit does shrinking the file actually have? SD cards aren't wanting for space so having multiple files on a card isn't a concern. Printing speed, at least for fdm and sla machines, is limited due to mechanical or material properties so having a lighter weight file that is easier to process isn't going to speed things up at all. I can see the potential for better print quality from a delta machine but only in the case of curves where existing firmwares are calculating a bunch of smaller lines that emulate a curve. Having a file that is quicker to process could allow for more calculations allowing for shorter lines and therefore smoother curves but it is my understanding that this really isn't a huge concern for the most part. So I'm just curious why you're putting in all this work and what you hope to gain from it. If it's an exercise in "because i can" then by all means continue with your work and I hope your results are good.

It is dual purpose. First, because I can.

Second, even with MCU's getting cheaper with more memory, to upload an entire job to the MCU (sometimes multi megabytes of G-Code) and have it run from RAM with out need for the host system, and with out need of a mass storage device separate from the MCU, you need something better than G-Code. Most of the low cost MCU's still have less than 128KB of data RAM (low cost is less than $8.00 for the chip). And the best of the low cost MCU's still have less than 64KB of usable Data RAM for under $8 (P8X32A, AVR, many ARM's), with out using additional cost components.

[DavidS]

A huge undertaking. I can appreciate the efficiency improvement and reduced memory consumption. but the current system works. and with microcontrollers getting cheaper and more advanced with larger amounts of memory is this really necessary.
it would be quite a battle to get Slicer companies to adopt this. and turn it into a standard.

gcode is used for many industries

I have no interest in that battle. If people like it they will use it, if enough people like it it will grow, if not it will be a niche application. Either way it is fun to write.

G-Code is great for human readability, not so much for Machine readability.

[adamfilip]

well good luck with it.. new ideas bring innovation. Thanks for your effort

[jlmccuan]

GCode can be very compact as well. It has logic, loops, if/then, can be run in absolute or relative units, have multiple work offsets, tool changes, etc. Most slicers and low end programming packages simply run in a more verbose format for the simplicity of debugging. Many even change arcs and circles to line segments rather than center point radius and angle functions.

[Mjolinor]

Stratasys use a bespoke binary format called CMB that does properly what you are talking about and it is complex. I did a lot of work reversing it.

Here is a starting point. Enjoy.
https://azttm.wordpress.com/2012/09/...b-file-format/

[DavidS]

GCode can be very compact as well. It has logic, loops, if/then, can be run in absolute or relative units, have multiple work offsets, tool changes, etc. Most slicers and low end programming packages simply run in a more verbose format for the simplicity of debugging. Many even change arcs and circles to line segments rather than center point radius and angle functions.

Even at a command for command equal redo in the code I am using it saves a lot of space, as I am using 16 bit integers with a 8 bit command. G-Code uses ASCII text, with space characters and new line characters between portions of commands, and at least 3 bytes for the command plus at least three bytes per parameter.

I am adding some more looping to mine as I go already, the above form is early development.

[DavidS]

Stratasys use a bespoke binary format called CMB that does properly what you are talking about and it is complex. I did a lot of work reversing it.

Here is a starting point. Enjoy.
https://azttm.wordpress.com/2012/09/...b-file-format/

Very interesting, though very inefecient. Each parameter is a float in most of those instructions. A float is 4 bytes, and has a larger range than any 3D printer I am aware of.

Most 3D printers can represent fine moves through the entire range of print with in 12 bits, some are a bit larger, though the largest I am aware of with the most possible points would not use more than 20 bits (24 bits is 3 bytes), so why waste space by using floats? And why waste conversion time by using floats?

Set up the steps per unit, then use integers per unit (which is where mine is likely to end up), assuming a resolution of 0.1mm (seems fairly standard for most 3D printers), that would be 6.5536 meters each direction, for a print using two byte (16 bit) integers. Now as the resolution improves I could see a resolution as low as 0.05 in the future, though that is still over 3.3 meters each direction. And a 24 bit parameter version of a code similar to what I am doing would exceed the limits of any likely 3D printer, even if your prints are the size of a very large house (greater than 167.7 meters at a resolution of 0.1mm or 83.8 at resolution of 0.05mm).

So why the waste of space in data and in code by using floats??