<h2>G-Code Is RS-274/NGC</h2>
<p>There is no need to attempt to standardize G-Code, the G-code itself <strong>already is</strong> standardized: it is the <a href="https://www.nist.gov/publications/nist-rs274ngc-interpreter-version-3?pub_id=823374" rel="nofollow noreferrer">NIST RS274/NGC</a>, or often short AIN RS-274 and was not designed for just FDM printers but any moving tool. Power lathes, CNC and laser cutters all can run on RS-274! G0 and G1 always move, G28 is always the homing procedure and so on. To show how the RS-274 standard evolved over time, check out an older variant of the document, the <a href="https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir5970.pdf" rel="nofollow noreferrer">NISTIR 597 Canonical Machining Commands</a>.</p>
<h3>Implementation is not standardized!</h3>
<p>However, due to the design of a given machine, the exact procedure for these commands has to be different for different designs. For example in a carthesian, prusa style printer Homing is usually moving negatively in X, Y and Z, in that order, one after another. But in a Delta Printer, that would most likely get your printhead to an illegal position: the printhead would first be moved out of the print volume and then never hit any endstop as those are mounted at the top of the printer. Instead, all axis on a delta are moving up simultaneous on homing, stopping each axis as they hit their endstop at the top, then the whole setup moves down to the printbed in unison. On a mill, lathe or router, the G28 operation usually starts by backing the tool away from the work volume, then moving to the 0 and only then moving the tool back into the work area to avoid fixtures.</p>
<h3>G &amp; M-command gaps</h3>
<p>Another caveat is, that the standardization via the NIST document only encompasses codes G0 to G99 and M0 to M49 - with gaps. Which brings us to the code block M - Miscellaneous. It is not fully defined in the document. <a href="https://en.wikipedia.org/wiki/G-code#List_of_M-codes_commonly_found_on_FANUC_and_similarly_designed_controls_for_milling_and_turning" rel="nofollow noreferrer">FANUC</a> setup uses a few more common M-commands but might contain more. The <a href="https://www.cnccookbook.com/g-code-m-code-reference-list-cnc-mills/" rel="nofollow noreferrer">CNCcookbook</a> has only 16 common M-commands, none of them a reporting one. <a href="https://www.autodesk.com/products/fusion-360/blog/cnc-programming-fundamentals-g-code/" rel="nofollow noreferrer">Autodesk</a> declares even only 11 M-block commands most common: M0 to M9 and M30. Of these the coolant related ones are usually irrelevant for FDM.</p>
<h2>M115</h2>
<p>M115 and M503 are <em>reporting</em> functions outside of the areas that were pretty much defined by the norming agency and thus have cropped up as development needed them until they formed undefined de-facto industry standards. This means that the standard itself does not contain them, but everybody and bob know that these commands are meant to report firmware and report settings respectively because some popular machines started with it.</p>
<p>These two commands are to inform a programmer what is the brains of the machine and settings, and as such, they are also subject to the style guide of the programming institution - the norm document does <em>not</em> contain a style guide, leaving it free for any implementation to chose style. A working example is <a href="https://marlinfw.org/docs/gcode/M115.html" rel="nofollow noreferrer">Marlin's M115</a>.</p>
<p>However, there are reasons why a programmer might disable M115 but keep M503: Industrial machines, especially such with maintenance contracts, usually don't allow users to access the firmware in some ways to on one hand keep them out from messing with the machine too much and on the other make sure that only a licensed technician can access some reporting functions by using proprietary commands. M503 on the other hand reports on the current status of settings that might be changed by the user or their service technician to account for different print requirements.</p>

CC BY-SA 4.0
2020-06-08T13:16:57.567Z
Thanks for putting so much effort in your answer. It's really good and I appreciate it. But my point was exactly about some common standards about commands that are not specified by NIST RS274/NGC. The problem, as I see it, is that firmware for hobby/low-end printers are community-driven and everybody is implementing protocol in a bit different way. It's very natural - we had the same in the beginning of WEB era. But my point is if we should bring everybody and initiate discussion about some common protocol and/or format?
Denys P.
CC BY-SA 4.0
2020-06-08T13:31:54.540Z
The De-Facto standard for G-code is mainly coined by Marlin, which very much works with almost the complete FANUC set (safe for very few afaik) and more commands afaict. If you want to ask someone, you'd have to ask NIST about including 3D printers into the RS274/NGC standard, who then might take what is the de-facto standard.
Trish
CC BY-SA 4.0
2020-06-08T13:34:33.927Z
I can agree with that. Except there Prusa is also very influential on this sector of the market. Rep-Rap wiki page is a great coordination point but it would be nicer to go further. :)
Denys P.
CC BY-SA 4.0
2020-06-08T13:38:22.803Z
To my knowledge, what we use as G-code is the FANUC base upon which Prusa Research, Ultimaker (via Cura) and the Marlin crews, which are somewhat intermingled, pretty much worked out what they needed more based on that and defined a common set of new commands, but I can not find out what they specifically added.
Trish
CC BY-SA 4.0
2020-06-06T10:49:23.317Z
2020-06-08T13:26:19.917Z
2020-06-18T08:29:41.667Z
Trish
<p>Rep-Rap project <a href="https://reprap.org/wiki/G-code" rel="nofollow noreferrer">wiki</a> contains information about different G-Code dialects for FFF/FDM 3D printers.</p>

<p>I googled but couldn't find if there were any attempts in DIY community to standardize existing dialects more or less?</p>

<p>For example, <a href="https://reprap.org/wiki/G-code#M115:_Get_Firmware_Version_and_Capabilities" rel="nofollow noreferrer">M115</a> command should return meta-information about firmware version and capabilities. But almost each popular firmware doing it in a slightly different way: sometimes they are just using different separators, sometimes constants are structurally different as well.</p>

<p>The result (as I see it) is some standard subset of G-Code commands that can be extended with dialects from different firmware providers. Probably something similar (but better) to what's is SQL world.</p>

<p>Are there any major cons for doing this?</p>

<g-code>
Are there attempts to standardize G-code for FFF/FDM printers?
Denys P.
# Are there attempts to standardize G-code for FFF/FDM printers?

(Asked by: username_0 on 2020-06-06)

Rep-Rap project [wiki](https://reprap.org/wiki/G-code) contains information about different G-Code dialects for FFF/FDM 3D printers.

I googled but couldn't find if there were any attempts in DIY community to standardize existing dialects more or less?

For example, [M115](https://reprap.org/wiki/G-code#M115:_Get_Firmware_Version_and_Capabilities) command should return meta-information about firmware version and capabilities. But almost each popular firmware doing it in a slightly different way: sometimes they are just using different separators, sometimes constants are structurally different as well.

The result (as I see it) is some standard subset of G-Code commands that can be extended with dialects from different firmware providers. Probably something similar (but better) to what's is SQL world.

Are there any major cons for doing this?

**Tags:** g-code

---

## 1 answers

### Answer by username_1 on 2020-06-06. Score: 7

## G-Code Is RS-274/NGC

There is no need to attempt to standardize G-Code, the G-code itself **already is** standardized: it is the [NIST RS274/NGC](https://www.nist.gov/publications/nist-rs274ngc-interpreter-version-3?pub_id=823374), or often short AIN RS-274 and was not designed for just FDM printers but any moving tool. Power lathes, CNC and laser cutters all can run on RS-274! G0 and G1 always move, G28 is always the homing procedure and so on. To show how the RS-274 standard evolved over time, check out an older variant of the document, the [NISTIR 597 Canonical Machining Commands](https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir5970.pdf).

### Implementation is not standardized!

However, due to the design of a given machine, the exact procedure for these commands has to be different for different designs. For example in a carthesian, prusa style printer Homing is usually moving negatively in X, Y and Z, in that order, one after another. But in a Delta Printer, that would most likely get your printhead to an illegal position: the printhead would first be moved out of the print volume and then never hit any endstop as those are mounted at the top of the printer. Instead, all axis on a delta are moving up simultaneous on homing, stopping each axis as they hit their endstop at the top, then the whole setup moves down to the printbed in unison. On a mill, lathe or router, the G28 operation usually starts by backing the tool away from the work volume, then moving to the 0 and only then moving the tool back into the work area to avoid fixtures.

### G & M-command gaps

Another caveat is, that the standardization via the NIST document only encompasses codes G0 to G99 and M0 to M49 - with gaps. Which brings us to the code block M - Miscellaneous. It is not fully defined in the document. [FANUC](https://en.wikipedia.org/wiki/G-code#List_of_M-codes_commonly_found_on_FANUC_and_similarly_designed_controls_for_milling_and_turning) setup uses a few more common M-commands but might contain more. The [CNCcookbook](https://www.cnccookbook.com/g-code-m-code-reference-list-cnc-mills/) has only 16 common M-commands, none of them a reporting one. [Autodesk](https://www.autodesk.com/products/fusion-360/blog/cnc-programming-fundamentals-g-code/) declares even only 11 M-block commands most common: M0 to M9 and M30. Of these the coolant related ones are usually irrelevant for FDM.

## M115

M115 and M503 are *reporting* functions outside of the areas that were pretty much defined by the norming agency and thus have cropped up as development needed them until they formed undefined de-facto industry standards. This means that the standard itself does not contain them, but everybody and bob know that these commands are meant to report firmware and report settings respectively because some popular machines started with it.

These two commands are to inform a programmer what is the brains of the machine and settings, and as such, they are also subject to the style guide of the programming institution - the norm document does *not* contain a style guide, leaving it free for any implementation to chose style. A working example is [Marlin's M115](https://marlinfw.org/docs/gcode/M115.html).

However, there are reasons why a programmer might disable M115 but keep M503: Industrial machines, especially such with maintenance contracts, usually don't allow users to access the firmware in some ways to on one hand keep them out from messing with the machine too much and on the other make sure that only a licensed technician can access some reporting functions by using proprietary commands. M503 on the other hand reports on the current status of settings that might be changed by the user or their service technician to account for different print requirements.

> **Comments:**
> **username_0**: Thanks for putting so much effort in your answer. It's really good and I appreciate it. But my point was exactly about some common standards about commands that are not specified by NIST RS274/NGC. The problem, as I see it, is that firmware for hobby/low-end printers are community-driven and everybody is implementing protocol in a bit different way. It's very natural - we had the same in the beginning of WEB era. But my point is if we should bring everybody and initiate discussion about some common protocol and/or format?  
> **username_1**: The De-Facto standard for G-code is mainly coined by Marlin, which very much works with almost the complete FANUC set (safe for very few afaik) and more commands afaict. If you want to ask someone, you'd have to ask NIST about including 3D printers into the RS274/NGC standard, who then might take what is the de-facto standard.  
> **username_0**: I can agree with that. Except there Prusa is also very influential on this sector of the market. Rep-Rap wiki page is a great coordination point but it would be nicer to go further. :)  
> **username_1**: To my knowledge, what we use as G-code is the FANUC base upon which Prusa Research, Ultimaker (via Cura) and the Marlin crews, which are somewhat intermingled, pretty much worked out what they needed more based on that and defined a common set of new commands, but I can not find out what they specifically added.  

---

