G-Code Ambiguity

I've been writing embedded firmware for years, but I recently got into writing 3D printer firmware. For the most part G-Code seems pretty straight forward, but there are some ambiguities that I can't seem to resolve from the limited GCode documentation I could find. For example, do the commands "G0" and "G00" mean the same thing? Is "G00" even a valid command? Is there a limit on the number of digits that can be part of a G-Code Command. Are G commands restricted to positive integers or can they be negative/rational numbers as well? What types of whitespace characters are permitted to separate G-Code Commands? Can commands be separated by any number of whitespace characters, or just one? What do the responses to G-Codes look like? How do you determine when you have reached the end of a G-Code command, is it just when you reach the end of a line or can commands span more than one line with some kind of termination/continuation character?

If anyone knows the answer to these questions or knows where I can find some documentation that details this, I would appreciate it.

See section 3 in [www.nist.gov].

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

In the Reprap arena, only a subset of the gcodes (and the custom M codes specific to Reprap) are used.

The Wiki page is definitive: [reprap.org]

In answering your questions I will state "I believe" if I don't know:
---

For example, do the commands "G0" and "G00" mean the same thing?
According to the Wikipedia definition the G00 matches G0 used in Reprap, and according to our Wiki they are treated the same, but use G1.

Is "G00" even a valid command? Possibly not for some Reprap firmware, undocumented for Reprap so do not use - use G1.

Is there a limit on the number of digits that can be part of a G-Code Command. Firmware dependent. Firmware ignores comments, but if the comment is too long then bad things can happen. In my opinion - more than 3 decimal places for mm coordinates or extruder position is pretty meaningless, but 5 decimal places are often used.

Are G commands restricted to positive integers or can they be negative/rational numbers as well? If you are talking about coordinate values and extruder positions, etc., it's not restricted.

What types of whitespace characters are permitted to separate G-Code Commands? Use spaces - unless you care to check with each firmware developer...

Can commands be separated by any number of whitespace characters, or just one? I believe several can be used, definitely many can be used between a command and a comment. As always, firmware dependent for parser implementation

What do the responses to G-Codes look like? Firmware dependent

How do you determine when you have reached the end of a G-Code command is it just when you reach the end of a line or can commands span more than one line with some kind of termination/continuation character? There should be one command per line, lines are terminated by carriage return or line feed or both. A command can also end when a comment is reached via a semicolon.

I am open to corrections.

---

My printer: Raptosaur - Large Format Delta - [www.paulwanamaker.wordpress.com]
Can you answer questions about Calibration, Printing issues, Mechanics? Write it up and improve the Wiki!

thanks for the link dc42, but the GCode expressions defined in their BNF table does does not seem to match with GCode from sample files. Without knowing what is a valid subset for reprap and what is not, I can't decipher anything from it.

Edited 1 time(s). Last edit at 01/20/2016 06:47PM by SE.

Thanks Paul Wanamaker, that clears up a lot. Im not actually generating G-Code though, I'm writing firrnware to process commands sent to my code, and I'm trying to make it compatible with as many slicers and printer hosts as possible. So it looks like I'll need to support multiple representations of the same command ie. (G1, G01, g001, etc)
The last remaining issue is what I need to return after processing a command. I've seen in some forums where people who write printer hosts say that they expect "OK\n" or something to that affect so that the host knows to send the next command, but I have not found anything definitive on the matter. I know that certain M commands return values to the host as well, is there any kind of standard for values returned?

I found the remaining piece of information in the reprap wiki article that Paul Wanamaker linked. In a small section that I somehow missed before entitled:Replies from the RepRap machine to the host computer. That should be all I need to know to get this working. Thanks again everyone.

You're welcome.
Out of curiosity, are you writing some reparap firmware from scratch?
Have you looked at the 32-bit open source firmware that is available, smoothieware.org etc?

I am writing some new firmware from scratch, I'm very particular about coding style and I struggle with using other people's code because I often don't understand it, or it would take me just as long to figure it out as it would to write my own. When I write my own I get more fine grain control over all aspects of the device, I'm not even using the version of libc or libm that comes with the GCC compiler, i prefer to start blank with nothing but a datasheet. Sometimes I even write my own assembler so I can have better control of the build process.

oh your one of those people (I know two people like that, brilliant bastards that prefer assembler as C doesn’t give enough control)

Please develop for a 32 bit processor, and not the practically dead horribly unfashionable atmega based systems.

Also have you seen teacup firmware might be more to your liking

what do you see as being the major advantage to using a 32 bit processor? It seems like it would be overkill for such a simple system. Not that it would be any more difficult or anything. I was thinking about trying out the parallax propeller since I have some unused project boards lying around. I also have atmega boards sitting around too though. The main factor will be if the propeller has enough gpios to drive all 32 NPN power transistors that drive the motor, and 2 to drive the heaters, and 2 analog pin to read the thermal resistors and another 3 gpios to read the end stops. not to mention 4 to bit bang serial with flow control and extras in case I want to add a bed leveler in the future.

I just checked the propeller documentation and it only has 32 gpios and no attached ADCs I could still use it, but It would require additional hardware.

I started with an 8 bit controller for my delta printer - big mistake. Too many FP square roots for the kinematics, terrible performance.

Users will want things like fast communications while the controller is stepping, graphic displays, etc.
Something like a cortex m4/m0 (with built in FP unit) would be pretty future proof. I got a couple chips to play with last year, should be easy to source.
That is what I hear the Smoothieboard 2 is going to use. Their pro version will have FPGA as well - although don't think it needs it.

Hope your project goes well. Are you planning open or closed source?

Edited 1 time(s). Last edit at 01/21/2016 10:04PM by Paul Wanamaker.

---

My printer: Raptosaur - Large Format Delta - [www.paulwanamaker.wordpress.com]
Can you answer questions about Calibration, Printing issues, Mechanics? Write it up and improve the Wiki!

I wouldn't mind releasing the source if i thought someone was interested in it. Im actually making it because the 3d printer kit that i got from 3d stuffmaker locked up, ignored the z end stop and drove the motor so far into the plate that it tore off one of the support rods before the firmware became forever unresponsive. Their implementation was terrible. Anyways I could look at another processor, but you shouldn't need so much precision that you require floating point, you could probably get away with 8 byte fixed point. The propeller would be good for communicating with the user while stepping since it is an 8 core 32 bit processor, but what would be the advantage of that anyways?

Edited 1 time(s). Last edit at 01/21/2016 10:17PM by SE.

Quote
SE
I'm writing firrnware to process commands sent to my code, and I'm trying to make it compatible with as many slicers and printer hosts as possible. So it looks like I'll need to support multiple representations of the same command ie. (G1, G01, g001, etc)

Such a wheel was invented long time ago already. At 30 to 50 CPU clocks per character, Teacup's parser is blazingly fast. Faster than characters coming in over a 115200 baud serial line even on a 16 MHz ATmega. It parses each character immediately, so no processing phase when a line is completed. And it handles G1, G01, g001 just fine.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug
Such a wheel was invented long time ago already. At 30 to 50 CPU clocks per character, Teacup's parser is blazingly fast. Faster than characters coming in over a 115200 baud serial line even on a 16 MHz ATmega. It parses each character immediately, so no processing phase when a line is completed. And it handles G1, G01, g001 just fine.

Implementing the parser isn't really challenging, I was never worried about how I was going to do it, I just needed to know what some of the requirements of the language in order to do it. As I said earlier I really don't like using other people's code if I don't have to.

Edited 1 time(s). Last edit at 01/22/2016 12:27PM by SE.