2
$\begingroup$

Rep-Rap project wiki 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 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?

$\endgroup$
6
$\begingroup$

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

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 setup uses a few more common M-commands but might contain more. The CNCcookbook has only 16 common M-commands, none of them a reporting one. Autodesk 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.

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.

$\endgroup$
4
  • 1
    $\begingroup$ 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? $\endgroup$ – Denys P. Jun 8 '20 at 13:16
  • $\begingroup$ 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. $\endgroup$ – Trish Jun 8 '20 at 13:31
  • $\begingroup$ 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. :) $\endgroup$ – Denys P. Jun 8 '20 at 13:34
  • $\begingroup$ 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. $\endgroup$ – Trish Jun 8 '20 at 13:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.