A plea to firmware developers to use common GCode standards

There are at least six open source 3D printer firmwares in common use, and more if we include open source CNC firmwares. The RepRap movement has been a success in part because of healthy competition between different firmwares, with users able to switch between firmwares according to their needs. Therefore it is vital that all firmwares support a common core GCode, and that a given G- or M-code means the same in all firmwares that support it. We would be doing a grave disservice to the community if we lock users into particular firmwares by making it difficult to switch because of GCode incompatibilities.

Fortunately, we have two standards available that are independent of any firmware development team:

1. The original NIST CNC Gcode standard at [ws680.nist.gov]. This covers basic moton commands as well as a lot of CNC-specific stuff.

2. The GCodes page on the reprap.org wiki at [reprap.org].

It is therefore self-evident to me that any firmware developer wishing to implement a new GCode function should:

1. See whether there is an existing G- or M-Code defined in either of those standards that supports that function or a closely-related one, and if there is, implement that GCode, perhaps with additional parameters;

2. If there is no existing G- or M-Code, allocate a new one that is not already used in either of those standards, and immediately add the provisional specification of that code to the reprap.org wiki so that nobody else allocates it for another purpose. The reprap.org GCode wiki page itself has espoused this principle in its introductory text for many years.

I am therefore disturbed that some firmware developers appear to be ignoring these principles, by allocating new GCodes for their own purposes regardless of the existing use of those codes in either of these two documents. So please can we have a commitment from all open source firmware development teams:

- To follow these principles themselves;
- When processing github pull requests, to reject any pull request that violates them.

I will start the ball rolling by committing the developers of RepRapFirmware to these principles.

---

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

Totally agree. However shouldn't their be some oversight/governance to allocating new G/M codes?

---

DC42 Kossel 330mm x 2meters
My Thingiverse Creations

Quote
DADIY
Totally agree. However shouldn't their be some oversight/governance to allocating new G/M codes?

Who would/should provide that oversight/governance?

Edited 1 time(s). Last edit at 04/27/2018 06:54AM by dc42.

---

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

Quote
dc42
There are at least six open source 3D printer firmwares in common use, and more if we include open source CNC firmwares. The RepRap movement has been a success in part because of healthy competition between different firmwares, with users able to switch between firmwares according to their needs. Therefore it is vital that all firmwares support a common core GCode, and that a given G- or M-code means the same in all firmwares that support it. We would be doing a grave disservice to the community if we lock users into particular firmwares by making it difficult to switch because of GCode incompatibilities.

Fortunately, we have two standards available that are independent of any firmware development team:

1. The original NIST CNC Gcode standard at [ws680.nist.gov]. This covers basic moton commands as well as a lot of CNC-specific stuff.

2. The GCodes page on the reprap.org wiki at [reprap.org].

It is therefore self-evident to me that any firmware developer wishing to implement a new GCode function should:

1. See whether there is an existing G- or M-Code defined in either of those standards that supports that function or a closely-related one, and if there is, implement that GCode, perhaps with additional parameters;

2. If there is no existing G- or M-Code, allocate a new one that is not already used in either of those standards, and immediately add the provisional specification of that code to the reprap.org wiki so that nobody else allocates it for another purpose. The reprap.org GCode wiki page itself has espoused this principle in its introductory text for many years.

I am therefore disturbed that some firmware developers appear to be ignoring these principles, by allocating new GCodes for their own purposes regardless of the existing use of those codes in either of these two documents. So please can we have a commitment from all open source firmware development teams:

- To follow these principles themselves;
- When processing github pull requests, to reject any pull request that violates them.

I will start the ball rolling by committing the developers of RepRapFirmware to these principles.

Totally agree with this sentiment. There is nothing worse then trying to help someone with Gcode/Mcode only to find that there FW does things in a totally different way to what you would expect.

It would be extremely nice if all Devs did take note of the Wiki and keep it upto date with any changes made as well.

I hope that some take this on board and follow your Lead David Well Done!

Doug

As a person who uses "Proprietary" CNC controllers, and "Open" or semi-open CNC and 3D printer controllers on a regular basis, I believe G-Code consistency is a VERY important idea. I endorse this, and volunteer to do anything I can to help.

IMHO, NIST standard should be the strongest driver. Both for the details of specific G-Codes, and perhaps more importantly, for the specification of 'sequence' behavior, such as which commands are modal, how the modes are grouped, how a multi axis move behaves, etc, etc. Things that 'cross' an individual statement or parameter.

By the very nature of Open, there is no one "governance" structure. At the same time, there are many examples of an active community helping guide very disparate development to produce a very coherent result.


This thread is a start toward being that active community.

Perhaps what we need is some sort of marking/logo thinking something like the OSH logo which stands for something. So those choosing to meet the reprap gcode convention can proudly display the logo.

Edited 1 time(s). Last edit at 04/27/2018 09:18AM by DjDemonD.

---

Simon Khoury

Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions

I think that prominent representatives from the existing opensource 3d printer communities should govern this open standard and by defining and documenting new gcodes, their parameters, expected behaviour etc. directly.
That's because they / you have the most insight into the future development and feature set of theese devices, and therefore are uniqely qualified to make extensions to the standard.

In my opinion there should also be a vendor specific region in the gcode registry where gcodes could be freely defined by any vendor, spcific to one or more of their prodicts used for functions only their device needs, and therefore it should not be added to the general gcode base. (For example a wild one, "clean the buildplate / apply adhesion coating by proprietary hardware", "laser pre-heat the previous printed layer for increased adhesion" or "set infrared heater power")

I'm not a huge fan of everyone adding and claiming g-codes. In an ideal world the firmware and slicer developers would agree on an efficient, minimal set of standard commands.

I don't think M codes past 100 or so need to be standardized. Random configuration codes like "M588: Forget WiFi host network" are never going to be called by the slicer; and when you start including that kind of stuff from every firmware the page just becomes a mess.

I've seen hobbyist proposals for fully portable g-code but I don't think that is possible, the format is just too low level. Its like advocating for a universal assembly language. If you want fully portable programs you need to operate one level higher, kind of like how CAM works in motion primitives then posts them into g-code.

Machine tool programming has a similar problem and its looking like the long-term solution would be to abandon g-code (and essentially have the machine verify and postprocess a motion file), not standardize g-code.

Quote
denke
I think that prominent representatives from the existing opensource 3d printer communities should govern this open standard and by defining and documenting new gcodes, their parameters, expected behaviour etc. directly.

That's fine by me, as long as we all agree on where they should be documented. The obvious place to document them IMO is the reprap.org wiki page. G/M code commands that are already defined in that or any other common standard (in particular, NIST) should not be subverted.

Quote
denke
In my opinion there should also be a vendor specific region in the gcode registry where gcodes could be freely defined by any vendor, spcific to one or more of their prodicts used for functions only their device needs, and therefore it should not be added to the general gcode base. (For example a wild one, "clean the buildplate / apply adhesion coating by proprietary hardware", "laser pre-heat the previous printed layer for increased adhesion" or "set infrared heater power")

IMO that's fine for proprietary firmware, however in open source firmware there is the danger that a developer may be lazy and choose to define a feature as proprietary when it has more general applicability.

---

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

Quote
dc42

Quote
denke
I think that prominent representatives from the existing opensource 3d printer communities should govern this open standard and by defining and documenting new gcodes, their parameters, expected behaviour etc. directly.

That's fine by me, as long as we all agree on where they should be documented. The obvious place to document them IMO is the reprap.org wiki page. G/M code commands that are already defined in that or any other common standard (in particular, NIST) should not be subverted.

Quote
denke
In my opinion there should also be a vendor specific region in the gcode registry where gcodes could be freely defined by any vendor, spcific to one or more of their prodicts used for functions only their device needs, and therefore it should not be added to the general gcode base. (For example a wild one, "clean the buildplate / apply adhesion coating by proprietary hardware", "laser pre-heat the previous printed layer for increased adhesion" or "set infrared heater power")

IMO that's fine for proprietary firmware, however in open source firmware there is the danger that a developer may be lazy and choose to define a feature as proprietary when it has more general applicability.

If the programmer is lazy, or trys to cut corners then they could. In this case it should be the code's maintainer's responsibility to reject the pull request -similarly to your originally stated guidelines-

While I like the idea that reprap wiki is the authoritative source for open-source g-code, would it not make sense - with the talk of code maintainers and pull-requests - to set up a "reprap g-code" git repo?

Volunteer maintainers could review changes and pull them into the spec just like other software projects. Every so often they could "release" on to the wiki and it would be "hey y'all if you like being open source support this". It would also be cool to have firmware writers look at the spec in progress and when the wiki gets updated, potentially have the new codes ready to go in a new firmware release soon after.

Quote
691175002
...
I don't think M codes past 100 or so need to be standardized. Random configuration codes like "M588: Forget WiFi host network" are never going to be called by the slicer; and when you start including that kind of stuff from every firmware the page just becomes a mess.

I disagree, for several reasons:

1. Slicers do call M-codes past 100. For example, some versions of slic3r call M204 and M566. Firmware developers shouldn't try to restrict or second-guess what GCode features a slicer developer may want to use.

2. There are plenty of other programs that may or do use M-codes beyond 100, for example Octoprint, Repetier host, and PanelDue.

3. If different firmwares use different GCodes for performing the same functions, that is very confusing to users who are trying out different firmwares.

Quote
691175002
I've seen hobbyist proposals for fully portable g-code but I don't think that is possible, the format is just too low level. Its like advocating for a universal assembly language. If you want fully portable programs you need to operate one level higher, kind of like how CAM works in motion primitives then posts them into g-code.

Machine tool programming has a similar problem and its looking like the long-term solution would be to abandon g-code (and essentially have the machine verify and postprocess a motion file), not standardize g-code.

Maybe that's the ideal long-term solution; but as long as slicers and firmware are separate pieces of software, the GCode that they use to communicate needs to be standardized.

Edited 1 time(s). Last edit at 04/27/2018 06:50PM by dc42.

---

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

Keeping GCode variants as close as possible is admirable so that CAM tools can be saner to implement.

>See whether there is an existing G- or M-Code defined in either of those standards

To make that as easy as possible, why not list any missing NISTIR 6556 codes on the reprap page? Most of them are likely already there.

>The original NIST CNC Gcode standard

Not to quibble here, but NIST didn't issue NISTIR 6556 (A.K.A RS274/NGC v3) as a standard. It was a fine research report though, has an accompanying c++ implementation, and has served as basis of many products.

Isn't it too late already?
Just look at all the different homing/bed leveling/printer calibration gcodes. ( G26-G33 ) It's a mess.
You FW dev's should try to find a common ground there. IMHO, all these Gcodes could be covered by G28 with some additional parameters. G28 would then have a greater meaning, like: "init mechanics " instead of "hominig axis".

I also felt in the past, that new FW-features try to "claim" as many unused M-Codes as possible, although they could have modified existing M-codes by adding a new parameter. Why? Just to make it harder for the "competion"?

Maybe it's time to define a new class of G-code: P-class for FW specific commands. The reprap-wiki would then offer links to the wiki pages of the FW-devs.

Edited 1 time(s). Last edit at 04/28/2018 03:05AM by o_lampe.

... for my company I've too modified one of the older Marlin4Due FW for "specific" use by adding some M-codes to handle I/O-pins in groups (instead of setting or reading them singular) and for a special handshake, what's only usefull with my too "specific modified" Pronterface-variant

As this is only usefull with our "industrial" controller boards, I didn't meant it for including into the common M-code list.

So maybe a separate set of "application-specific" commands, which are only valid in specific conditions and can vary by implementation, could be a way around the issue?

"P"-codes can interfere with the "P"-settings (=pin - e.g. "M42 P30 S255"), so better another, not actually used char like "Q" or "V" ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

... this are my "application specific" M-Codes, only usefull with the too modified Pronterface variant (modified temp-reading methodes, to read more variables from the Marlin4Due firmware):

* M43 - Read pin status via gcode Use M43 Px to read pin x to value - #option for gieCAPS
* M44 - Read all Input pins - D41 to D47 - #option for gieCAPS

* M130 - Single read: Ref-switches and Input-pins -- gieCAPS modification
* M131 - Continuous read: Ref-switches and Input-pins -- gieCAPS modification

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

P stands for proprietary, but any letter would work. ( as long as the FW-gurus find consens about the letter )

Quote
VDX
... for my company I've too modified one of the older Marlin4Due FW for "specific" use by adding some M-codes to handle I/O-pins in groups (instead of setting or reading them singular) and for a special handshake, what's only usefull with my too "specific modified" Pronterface-variant

As this is only usefull with our "industrial" controller boards, I didn't meant it for including into the common M-code list.

So maybe a separate set of "application-specific" commands, which are only valid in specific conditions and can vary by implementation, could be a way around the issue?

"P"-codes can interfere with the "P"-settings (=pin - e.g. "M42 P30 S255"), so better another, not actually used char like "Q" or "V" ...

I suggest we reserve M1000 to M1099 for this purpose. Would you be happy with that?

---

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

You are much more qualified then me to decide this, but I would put it more "out of the way" where it would never interfere with the registering of new "community" codes.

Since M999 is reset, and there are a few others around that already, I would put it to 2000 - 2999 or 9000 - 9999? it would also be sufficent so a large company with many proprietary printers and functions would never run out of space over the years even if they allocate them unresponsibly. They would also "stand out" more from the "community" codes

Edited 1 time(s). Last edit at 04/29/2018 04:31AM by denke.

... for me any "available" range would be OK - I was only searching for some "free" numbers ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Quote
denke
You are much more qualified then me to decide this, but I would put it more "out of the way" where it would never interfere with the registering of new "community" codes.

Since M999 is reset, and there are a few others around that already, I would put it to 2000 - 2999 or 9000 - 9999? it would also be sufficent so a large company with many proprietary printers and functions would never run out of space over the years even if they allocate them unresponsibly. They would also "stand out" more from the "community" codes

I'd be happy with 9000-9999 too.

---

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

I agree that it’s a good idea, but the only way this is going to work is if you establish contact with the existing popular firmware owners, and remain in close communication as new features are added. It’s going to have to be a committee, informal or not. Even then it’s only likely to last until one of the major players strongly disagrees with something.

CNC controller manufacturers can’t even manage to follow the NIST standard consistently, hence every high end CAM package has a suite of post processors to fix there output for specific controllers.

NIST is probably only useful as a guideline, 3d printers already don’t follow it for even basic gcode, G28 was never intended to home a machine to limit switches, but that doesn’t matter since it’s consistently used across firmware for printers.

In general things have been fairly consistent across firmwares, at least the 3 or 4 I’ve used, in a lot of ways the slicers and UIs drive this, since in general people adding a feature that exists in a different firmware will do it in a way it can be used.

---

___________________________________________________________________________

My blog [3dprinterhell.blogspot.com]

If you think back to about 10-15 years ago, during the "Browser Wars" all the major web browser engines interpreted html and css in their own way. This led to much chaos ... larger webpages used conditional stylesheet loading, so a ton of extra work had to be done by the web developers, they had to create different css files for each browser, so the site looks and works about the same in all browsers. It was pure nonsense.

With the passing of time Firefox and Chrome emerged, and gained dominance over the market. However their engine is completely different they follow the same docs as guide to describe how things should work, and this gives them the advantage of stability and compatibility.

I think if most of the big communities get behind this initiative, then the smaller ones will be forced to follow, because the slicer communities will simply force them to. If they break the standard, slicers will not create a workaround just for them, but rather point them to the common specs, and file a bugreport to fix compatibility.

I'm neither a seer, nor a pro in this area - to be frank, I'm just a noob with a big mouth and good intentions - but i think if Marlin, Smoothieware, and Reprap (check) would join it would suffice.

Smoothie was created years ago with as one of it's main goals the support of 3D printing, laser cutting and CNC milling ( and more ).

Because of this we've been very attentive to following the Reprap Gcode standard ( wiki documentation ) for 3D printing, and the NIST stantards for CNC milling ( they are unfortunately incompatible. the early reprap folks didn't really think about how big/important it would all become ).

For lasers what we do works with both systems because we limit the laser rules to only a few simple ones, so users can choose cnc or 3Dp mode for their lasers.

Btw, Smoothie's laser specs ( smoothie was by far the first one to do laser, and hosts work this way too, so I'd expect this to be standard overall ) in short :

G0 means move without turning the laser one, G1 means move with the laser turned on ( this is great because it makes it so that most CNC milling software can be used out of the box for laser cutting ).
Moves turn the laser one proportional to speed ( meaning as speed increases laser power increases ), leading to an equal amount of power being put into the work piece even when accelerating/decelerating.
The S parameter ( 0 to 1 ) defines the desired laser power.
So G0 X10 moves without cutting, G1 X20 S0.1 moves with laser at 10% power.
The S parameter is modal ( is remembered even if not specificed ).

If somebody wants to add a laser section to the reparp wiki spec, this would probably be a good start.

About Mcodes above 1000, I'm fairly certain it's generally considered to be for user-defined Mcodes, and I don't think we should be putting Mcodes there. There is a ton of room bellow 1000.

... the first Software with optional selectable CNC- and Laser-controlling was the original RepRap-Software in the 3rd or 4th iteration (could be around 2008 or -09).

With "pulse-controlled" (not analogue) laser drivers any 3D-printing software can be used for laser-engraving/-cutting without changes in the firmware or G-codes - I'm only setting the "pulses per mm" ratio in the firmware to a usable value and then changing the pulse-length per G-code by setting an analogue port (averaged PWM) to a value of 0-5V, which is interpreted by the laser driver as a pulse-length (e.g.) between 5µs to 500µs ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Quote
VDX
... the first Software with optional selectable CNC- and Laser-controlling was the original RepRap-Software in the 3rd or 4th iteration (could be around 2008 or -09).

With "pulse-controlled" (not analogue) laser drivers any 3D-printing software can be used for laser-engraving/-cutting without changes in the firmware or G-codes - I'm only setting the "pulses per mm" ratio in the firmware to a usable value and then changing the pulse-length per G-code by setting an analogue port (averaged PWM) to a value of 0-5V, which is interpreted by the laser driver as a pulse-length (e.g.) between 5µs to 500µs ...

I created Smoothie because I had a laser cutter and no firmware that would run it. I asked here, grbl, and a few other projects, and nobody pointed me at something usable in Reprap-Software. First time I ever hear of it. And that's after helping litterally thousands of laser cutter users. Not one mention.

About "any firmware can do it", it might have changed recently, but last time I looked none of Marlin, Repetier etc could do ( correctly ) power-proportional-to-acceleration ( I've seen a few users go RRF recently so that might have it ). Trying to implement that into grbl and failing was one of the reasons for porting grbl to LPC1768 originally ( at grbl's author's advice ) ...

... this "power-proportional-to-acceleration"-thing is a common problem (or misunderstanding) even with many comercial laser-engravers

It's a really big problem to get the power of a laser regulated in respect to accelerated speed with an analogue (or PWM) driver -- the laser power is not linear from 0 to max, so you'll need a pretty sophisticated calibration to get an even distribution along a line, so the (accelerated) ends werent' burned stronger than the constant speed in the middle.

My first methode to avoid burned edges was a "speed independant" methode by simply using the X- and Y-step-clock signal to generate an even raster, which is the same, regardless how fast or if accelerated.

With the RepRap-firmwares it's even simpler by simply using the Extruder step-clock signal, as it's exactly synchrone to the XYZ-acceleration (needed and calculated for even distribution of the plastic). Here the effective power can be set by changing the "pulses per mm" value, and/or the pulse lengths (at constant pulses/mm distribution).


And for the CNC-mill- and laser-options - look into the oldest skeinforge infos -- this was one of the programs with optional switches for generating G-code for milling or lasercutting ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Ok, yes, I'm aware of the "extruder axis" hack. And yes, skeinforge did have some CNC milling options. You are *technically* right here. I'm not sure you've got a good connection to what users actually need/want though There are good reasons neither of these ever really saw any use, and users are so happy about the more recent developments around this.

I tried to dig threw the reprap docs and gcode database on the question at hand, and it seems that M452 sets the firmware to laser mode, and laser is on only for G1 moves if E increases, any other movement or EOF sets the laser off.
M571 sets the laser pwm factor for the output. VDX was faster to answer.

I think that theese are exactly the things that need to be standardised. Obviously not every firmware will support for ex. the mentioned laser functionality but if someone decides to implement it, it should be clearly documented what are the commands used and what is their expected behaviour.

An added bonus that with standardisation a natural debate / brainstorming would form about some of the more complex functionality, where each community's representative could make suggestions how to acheive the most robust, longterm end result. This would benefit all parties by providing the best solution, a clear, well tought over way to implement a feature, the community by ensuring interchangeability, and the slicer / toolpath creating software vendors / communities by eliminating the need to support distinct implementations of the same command / task.

I think it's a nice goal...

Edited 2 time(s). Last edit at 04/30/2018 06:21PM by denke.

... here an (incidentally) example of "charred edges" with a comercial PWM controlled laser-engraver, I've done today for a test.

While it's perfect with engraving on aluminium, the tested plastic is much more sensitive to power variations in curves:

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]