A plea to firmware developers to use common GCode standards April 27, 2018 05:53AM |
Registered: 10 years ago Posts: 14,672 |
Re: A plea to firmware developers to use common GCode standards April 27, 2018 06:39AM |
Registered: 8 years ago Posts: 301 |
Re: A plea to firmware developers to use common GCode standards April 27, 2018 06:41AM |
Registered: 10 years ago Posts: 14,672 |
Quote
DADIY
Totally agree. However shouldn't their be some oversight/governance to allocating new G/M codes?
Re: A plea to firmware developers to use common GCode standards April 27, 2018 07:46AM |
Registered: 9 years ago Posts: 1,159 |
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.
Re: A plea to firmware developers to use common GCode standards April 27, 2018 08:37AM |
Registered: 6 years ago Posts: 5 |
Re: A plea to firmware developers to use common GCode standards April 27, 2018 09:18AM |
Registered: 8 years ago Posts: 3,525 |
Re: A plea to firmware developers to use common GCode standards April 27, 2018 10:46AM |
Registered: 5 years ago Posts: 5 |
Re: A plea to firmware developers to use common GCode standards April 27, 2018 11:03AM |
Registered: 11 years ago Posts: 335 |
Re: A plea to firmware developers to use common GCode standards April 27, 2018 12:10PM |
Registered: 10 years ago Posts: 14,672 |
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.
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")
Re: A plea to firmware developers to use common GCode standards April 27, 2018 12:34PM |
Registered: 5 years ago Posts: 5 |
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.
Re: A plea to firmware developers to use common GCode standards April 27, 2018 02:56PM |
Registered: 6 years ago Posts: 3 |
Re: A plea to firmware developers to use common GCode standards April 27, 2018 06:49PM |
Registered: 10 years ago Posts: 14,672 |
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.
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.
Re: A plea to firmware developers to use common GCode standards April 27, 2018 08:26PM |
Registered: 10 years ago Posts: 39 |
Re: A plea to firmware developers to use common GCode standards April 28, 2018 03:00AM |
Registered: 8 years ago Posts: 5,232 |
Re: A plea to firmware developers to use common GCode standards April 28, 2018 03:58AM |
Admin Registered: 16 years ago Posts: 13,888 |
Re: A plea to firmware developers to use common GCode standards April 28, 2018 12:14PM |
Admin Registered: 16 years ago Posts: 13,888 |
Re: A plea to firmware developers to use common GCode standards April 29, 2018 02:12AM |
Registered: 8 years ago Posts: 5,232 |
Re: A plea to firmware developers to use common GCode standards April 29, 2018 02:43AM |
Registered: 10 years ago Posts: 14,672 |
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" ...
Re: A plea to firmware developers to use common GCode standards April 29, 2018 04:24AM |
Registered: 5 years ago Posts: 5 |
Re: A plea to firmware developers to use common GCode standards April 29, 2018 04:50AM |
Admin Registered: 16 years ago Posts: 13,888 |
Re: A plea to firmware developers to use common GCode standards April 29, 2018 09:10AM |
Registered: 10 years ago Posts: 14,672 |
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
Re: A plea to firmware developers to use common GCode standards April 29, 2018 03:57PM |
Registered: 12 years ago Posts: 939 |
Re: A plea to firmware developers to use common GCode standards April 29, 2018 06:06PM |
Registered: 5 years ago Posts: 5 |
Re: A plea to firmware developers to use common GCode standards April 30, 2018 10:38AM |
Registered: 14 years ago Posts: 351 |
Re: A plea to firmware developers to use common GCode standards April 30, 2018 01:39PM |
Admin Registered: 16 years ago Posts: 13,888 |
Re: A plea to firmware developers to use common GCode standards April 30, 2018 02:21PM |
Registered: 14 years ago Posts: 351 |
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 ...
Re: A plea to firmware developers to use common GCode standards April 30, 2018 06:07PM |
Admin Registered: 16 years ago Posts: 13,888 |
Re: A plea to firmware developers to use common GCode standards April 30, 2018 06:10PM |
Registered: 14 years ago Posts: 351 |
Re: A plea to firmware developers to use common GCode standards April 30, 2018 06:17PM |
Registered: 5 years ago Posts: 5 |
Re: A plea to firmware developers to use common GCode standards April 30, 2018 06:56PM |
Admin Registered: 16 years ago Posts: 13,888 |