G-Code alternative.

Printable View

04-07-2015, 06:09 AM
DavidS

G-Code alternative.

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:

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:

Code:

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.
04-07-2015, 08:23 AM
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.
04-07-2015, 08:27 AM
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
04-07-2015, 09:03 AM
DavidS

Quote:

Originally Posted by 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.

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.
04-07-2015, 09:04 AM
DavidS

Quote:

Originally Posted by 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

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.
04-07-2015, 09:17 AM
adamfilip

well good luck with it.. new ideas bring innovation. Thanks for your effort
04-07-2015, 10:34 AM
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.
04-07-2015, 12:30 PM
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/
04-08-2015, 03:11 AM
DavidS

Quote:

Originally Posted by 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.

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.
04-08-2015, 03:24 AM
DavidS

Quote:

Originally Posted by 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/

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??
04-08-2015, 03:28 AM
Mjolinor

There are good reasons to make Gcode human readable and standard. All CNC machines use it. The makerbots use X3G which is already the binary form you are talking about and personally I hate the thing, you cannot debug the print file easily. Starting another version of the same thing using different instructions will only confuse people even more, there are already enough people that do not understand what is happening.

Small files has already been shown to be of little consequence in computing in general. Personally I am perfectly happy with the command line and using "control k" commands for print editing and formatting but that is not what made computers ubiquitous, it is the ability to see what you want rather than knowing what numbers do that has made the general public accept computers.

The Internet would real rock if everyone was happy with the information in any form, we could all have dial up and get pages instantly but it is not what people want so the Internet is full of bloat to make things easier for people to use. The same is true for Gcode and it is an excellent format for the job it does.

Maybe you can make it faster and smaller and more efficient but I and many other people read Gcode and use Gcode not only for 3d printing, I actually make simple machines for things like coil winding and linear movement for the most ridiculous one off jobs and drive them with Gcode because I know it and can write it manually like writing a letter.

By all means forge ahead and do it but it will never be accepted accepted by people in general and oyu are setting off down a road that I do not think you understand the complexity of yet.
04-08-2015, 04:03 AM
DavidS

Quote:

Originally Posted by Mjolinor

There are good reasons to make Gcode human readable and standard. All CNC machines use it. The makerbots use X3G which is already the binary form you are talking about and personally I hate the thing, you cannot debug the print file easily. Starting another version of the same thing using different instructions will only confuse people even more, there are already enough people that do not understand what is happening.

Small files has already been shown to be of little consequence in computing in general. Personally I am perfectly happy with the command line and using "control k" commands for print editing and formatting but that is not what made computers ubiquitous, it is the ability to see what you want rather than knowing what numbers do that has made the general public accept computers.

The Internet would real rock if everyone was happy with the information in any form, we could all have dial up and get pages instantly but it is not what people want so the Internet is full of bloat to make things easier for people to use. The same is true for Gcode and it is an excellent format for the job it does.

Maybe you can make it faster and smaller and more efficient but I and many other people read Gcode and use Gcode not only for 3d printing, I actually make simple machines for things like coil winding and linear movement for the most ridiculous one off jobs and drive them with Gcode because I know it and can write it manually like writing a letter.

By all means forge ahead and do it but it will never be accepted accepted by people in general and oyu are setting off down a road that I do not think you understand the complexity of yet.

I do see your points. MCU's do have limited memory, that is my problem with G-Code, that and it uses floating point where Integer would make more sense.

I am not attempting to replace G-Code by any means. Just attempting to make a simpler system for use as the native format on controllers of a limited set of devices similar to 3D printers and mainly focused on 3D printers.

The first implementation of this is actually in a 3D printer that is sent G-Code, and the G-Code is converted to this native command language in one core, the control program running in another core interprets this more efficient binary code. Though a host side program for doing the conversion would be even more efficient. I am using it to save memory in the microcontroller on-board in the 3D printer. It is an alternative for the final stage, NOT for the initial stage or debug level.

Though how hard would it be to write a program that converts between a human readable form and the binary form?

And for controlling mechanical devices how often do you need Floating Point values??? That is in the form of number of steps to move, etc? Integer values just make more sense for the application of 3D printers.
04-08-2015, 10:31 AM
Mjolinor

I have just spent for ever implementing the G7 gcode for my laser cutter, that will be a real dog with binary, it was hard enough in Gcode.
04-08-2015, 01:05 PM
DavidS

Quote:

Originally Posted by Mjolinor

I have just spent for ever implementing the G7 gcode for my laser cutter, that will be a real dog with binary, it was hard enough in Gcode.

Then I would think you an exception to the rule.

To use a line of G-Code you have to parse the text to get the useful information, convert portions of the string to binary floating point numbers you can use, then convert it to a form that makes sense for the type of device being controlled.

Compare that to simply looking at a byte, using it to branch to the correct section of control code, using the 0 one or 2 bytes as an integer value directly in a form that makes sense for the device already.

There are a lot more steps in interpreting G-Code, and a lot more room for error (and a lot more code needed).
04-08-2015, 02:22 PM
soofle616

Quote:

Originally Posted by DavidS

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.
04-08-2015, 07:12 PM
DavidS

Quote:

Originally Posted by soofle616

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).
04-09-2015, 07:17 AM
soofle616

Quote:

Originally Posted by DavidS

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 :p
04-12-2015, 10:29 PM
Aztecphoenix

what has happened to this world? since when has mankind ever said "what we have right now works good enough, why change it"?

DavidS you keep going, it would be nice if someone would come out with a STANDARD file for 3D printing, and if it's less work for the MCU then that means less printer crashes, fewer failed prints, and in the future faster print times.

we as a society have become obsessed with over complicating things, just look at how many different formats we have for just a basic text document, we need to standardize and simplify, how many times have you downloaded a file only to find out you don't have the right program to open it? or how many times you have downloaded a video file only to find you don't have the right codec, don't you think it would be nice to do a search on your computer and just get the files for your 3D printer without them being mixed in with files for laser cutters and CNC mills and so on?

besides, with 3D printers being sold in Staples and so on, how many new average users are going to have any idea how to debug a Gcode file in the first place? unless you want to try and tell me that my grandma can go out, buy a new computer and be able to debug her system everytime Windows crashes
04-13-2015, 09:30 AM
soofle616

I agree, everyone should be forced to use the same thing regardless of their application. There is no room in this world for innovation or experimentation ESPECIALLY in a field like 3d printing. :rolleyes:
04-13-2015, 11:12 PM
Aztecphoenix

Quote:

Originally Posted by soofle616

I agree, everyone should be forced to use the same thing regardless of their application. There is no room in this world for innovation or experimentation ESPECIALLY in a field like 3d printing. :rolleyes:

That's not what I mean, do you really think we need 50 different formats just to view a text document, do think it's really fair that because I can't fork out a few hundred dollars for solid works that I can't view a solid works file with the software I have, all these different formats serve only one purpose, and that is to prevent colaberation between the rich and the poor, because why would any one want to be on a level playing field (sarcasm).
04-14-2015, 02:00 AM
LambdaFF

While I understand the intellectual attractiveness of designing something new and more efficient, I really agree with Mjolinor.

A system that human people can read and understand by only memorizing a <100 commands language will always have appeal. I really wish your system works (I hate efforts going to waste). But practically, for the technicians doing the initial setup, debugging, maintenance and repairs on machines : their job is so much easier if they don't have to speak binary. If you don't mind catering to a limited selection of tech afficionados, forge ahead.
04-14-2015, 07:50 AM
soofle616

Quote:

Originally Posted by Aztecphoenix

That's not what I mean, do you really think we need 50 different formats just to view a text document, do think it's really fair that because I can't fork out a few hundred dollars for solid works that I can't view a solid works file with the software I have, all these different formats serve only one purpose, and that is to prevent colaberation between the rich and the poor, because why would any one want to be on a level playing field (sarcasm).

Well, just because you called it out specifically, you CAN view a solidworks file for free. Download edrawings.

As for what we need for file formats, need is defined by each individual person. I only NEED a small number of file formats for my job and hobbies so if we're talking needs I could argue that anything else is unnecessary and everyone else should just learn to do things using the formats i like. Every format exists for a reason. Maybe that reason is an attempt to force people into proprietary software or maybe it's because that format allows for different feature sets than other formats. Without discussing every possible format individually and in detail there's no way to make that distinction. In the case of the OP's new format project, the clear benefit is file size. Now maybe that benefit is not something you or others are concerned with. If not, ignore it and go on using g-code or whatever you like. But for those like the OP that ARE concerned with file size, it's a significant change from the current "standard" that allows him and those like him to do something that is currently not possible, namely, caching an entire print on his machine without having to add additional storage space to it.