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.

[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.

[soofle616]

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.

So is it your intention then to run your 3d printer like a paper printer in the sense that you hit "print", the file is transferred to the printer's internal memory before it starts to print, and you can then close your printer software and/or shut down your computer? If so, then i think that's a decent reason to push forward on this (though "because I can" is also reason enough for me). In terms of simplifying the electronics and firmware in the printer i can definitely see the benefit to your idea.

[DavidS]

So is it your intention then to run your 3d printer like a paper printer in the sense that you hit "print", the file is transferred to the printer's internal memory before it starts to print, and you can then close your printer software and/or shut down your computer? If so, then i think that's a decent reason to push forward on this (though "because I can" is also reason enough for me). In terms of simplifying the electronics and firmware in the printer i can definitely see the benefit to your idea.

Well thank you.

Yes it would be nice to be able to send an entire model to be printed to the printer, disconnect from the host system, and have the print finish up with out any reliance on the host system. And that is part of the goal. Doing so with only the RAM in the MCU in 99% of cases.

Then keeping the HW simple as possible reduces the build cost (and part of my goal is to make something that is affordable [less than $150] to copy).

Simplifying software, should be a goal of all programmers. For every 100 lines of code there is on average 6 bugs (in any project now days), so reducing code size reduces the number of likely bugs, and improves the ability to debug. I have been careful about coding to avoid bugs at all cost for a long time, and they still sneak up on me often.

I believe strongly in KISS when it comes to both HW design and programming. If you can do the exact same thing in half the code with the same user experience, do it. I know this is the opposite of modern programmers, who tend to do things in ten times more code with no added function or user experience.

And above all:
I like the challenge of doing something just a little better than standard. If I can shave one wasted clock cycle, I will, if I can shave one byte with out loosing anything I will, if I can save a few lines of code to do the same thing I will. I enjoy programming (not code banging like a lot of modern "Programers" do).

[soofle616]

Simplifying software, should be a goal of all programmers. For every 100 lines of code there is on average 6 bugs (in any project now days), so reducing code size reduces the number of likely bugs, and improves the ability to debug. I have been careful about coding to avoid bugs at all cost for a long time, and they still sneak up on me often.

I believe strongly in KISS when it comes to both HW design and programming. If you can do the exact same thing in half the code with the same user experience, do it. I know this is the opposite of modern programmers, who tend to do things in ten times more code with no added function or user experience.

Technically you're adding lines of code, not removing them, at least for now, since you're plan is to convert from gcode to your language. I realize that the end goal is to directly produce files in your language from the slicer but until you get the slicer built, you're making things MORE complicated. Just having a little fun with you btw

[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]

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.