The RepRap Standards Consortium

[thinkyhead]

Does there need to be a Consortium for developing shared standards between open source firmware, host software, and 3d-printing middleware across the RepRap ecosystem?

[boelle]

hmm... i would say no, but it would be a great advantage (i think). At least keep it an open inventation to say repetier etc.

one place where i for my own purposes could see an advantage in a common protocol as an example is that i like the idea of the repetier informer app on the phone and the repetier server app and then repetier host as they all can exhange info and status....

the big downside is that so far i have not been able to run repetier firmware as smooth as marlin...

with a common protocol i could mix between the 2 sides of the fence and it would still work.

[foosel]

IMHO there doesn't need to be something formal like a consortium, but there does need to be communication. The current everything-goes approach is not going to scale anymore.

Also there IMHO doesn't need to be a standard for host interfaces, e.g. their REST APIs or something (what @boelle is implying) - those are after all usually only facing the user or already properly documented. The firmware interface however (so, the serial communication that the host is using to talk to the printer) is something that in desperate need of being standardized because it's not very well suited for direct user consumption (stop thinking in terms of the Maker community so far and start thinking in terms of children, teachers, your dog trying to operate a printer) - and the situation there has gotten to a point where I get nightmares every time a new firmware or even just a new fork of Marlin shows up because I know I will sooner or later have users opening new tickets in OctoPrint's tracker complaining that there are problems with the temperature curve of OctoPrint when they connected it to their printer running Awkward Penguin Firmware 3.4.

[boelle]

i was thinking of the serial communitcation.... just me bad at picking the right wording

[foosel]

Ok, I got mislead because you were talking about Repetier Informer, which is clearly using an API provided by a host, not the serial comm.

[boelle]

i only mentioned repetier as they have a nice chain of stuff... the downside is getting support for my hardware.... thou i was given some instructions that might make everything work

Hope i will not get the big "Verräter" stamp on my back for trying out repetier :-D

But it never hurts to check if the grass is more green on the other side of the fence

[gege2b]

Hi there

I agree for a standardized protocol for the serial comms
And I think that the gcode itself needs to be harmonized across all the firmwares too

Actually, based on the Gcode wiki on reprap.org, some (especially "M") codes are interpreted differently

Example : M206 is interpreted as "set home offset" for Marlin, Sprinter and Smoothie
Repetier interpret this as "Set EEPROM value"

Another example : M117, interpreted as a "get zero position" by FiveD and "display message" by the others

This is not really a problem for host software, but I think it's a pain in the ass for the slicers to support all this flavors

[foosel]

That in fact is a huge problem for host software that tries to do more than just stream files to the printer and maybe move the axes.

edit Just because I want to be crystal clear on this, those differences between command syntax and effects across the firmwares are THE biggest reason for a lot of new grey hairs on my head since I started working on OctoPrint ;)

Also: Please don't call that GCODE, GCODE is an actual standard and in fact a file format, not a communication protocol.

[nophead]

The original RepRap 5D firmware is fundamentally different in the way it handles feed rates compared to modern firmwares. It treats F as another dimension and interpolates it between G1 endpoints, whereas normal CNC machines generate their own trapezoids. I don't know if any firmwares still do what the second example in the G1 notes describes.

[thinkyhead]

Serial messages for the present just need to be coordinated with the main forks of the finite number of hosts (and firmwares) that currently exist. Among these are Repetier, Cura, Printrun/Pronterface, and a few others.

At the moment, there is an "ok" extension (to include the current line number) being considered, but the syntax differs between Repetier and other hosts.

@daid suggests for serial messages to use a set of standard strings for status (e.g., "TEMP_ERROR" or "HALT") rather than status/error numbers, followed by message text, which can be fully translatable.

[foosel]

Remember that Marlin is not the only firmware. So it's not just Marlin coordinating with the hosts, but the other firmwares too which would actually be necessary. To make this a bit less of a horrible hassle, a standard (but not necessarily a consortium, sounds like something that would become way too unwieldy instead of getting stuff done) makes sense.

[JustAnother1]

How about calling it "round table" then. That implies that everybody is of equal importance, that everybody can join and walk away anytime and also stands for people coming together to solve a common issue. Then again it is just a name. The bigger issue is to somehow get such a thing organized, right? To get anywhere with this we have to move it somewhere else. A marlin Issue is not the place to discuss this, especially not if we want to also include other firmwares and other hosts into the discussion.

It would be good to have a forum for all parties involved in best case that would be on neutral grounds,..

suggestions?

[thinkyhead]

So, perhaps there should be a separate Github project, specifically for posting the standards for "g-code", handshaking, serial messages, etc. Perhaps in time it could be developed into a standard set of libraries for firmware and hosts.

[wijnen]

I think it would be extremely valuable to have an organization which has a mission of standardizing communication protocols in the 3-D printer world. I have ideas about this which may differ quite a bit from most others. In particular, I consider the serial interface an implementation detail that doesn't require documentation except inside projects. However, given the current situation where every host software tries to communicate with every firmware, it makes sense to standardize it. I'm just saying that if someone writes software that includes a host and firmware that talk some custom protocol with each other, that's fine with me. (In fact, I wrote such software.)

What I'm more interested in is a protocol which allows end user applications like OpenSCAD, Blender and Firefox to implement a Print button that sends the file to the printer driver and prints it, without the user opening any "host program".

But regardless of what is going to be defined, we're not getting anywhere without a good place to discuss it. A repository here on github sounds like a good idea; that would provide a wiki, version control, and a semi-forum in the form of issues like this one.

[thinkyhead]

host and firmware that talk some custom protocol with each other

@wijnen Absolutely. And they should open up the protocol to the community if it solves a problem.

a Print button

Well, of course that will differ by platform, and there are a lot of steps between a 3D model and the GCode. Microsoft is adding a 3D print option to their OS, so we'll probably end up adopting their standards, which they are beginning to introduce.

A repository here on github sounds like a good idea

For current standards I'm posting the documentation at marlinfirmware.org and once that's more complete it can be used as a historical reference document going forward.

[daid]

@thinkyhead Microsoft isn't doing anything new or revolutionary. They all use already existing tech and pretty much bring nothing new to the table (3FM is essentially a fuck you against AMF)

[thinkyhead]

@daid Agreed. If people use a Windows OS that "3D Print" button is going to be a Microsoft product, and it's not really going to be possible for third parties to override that in Adobe software, for example. Each system is going to have its own hooks for drivers and control panels, if people want to integrate with the system itself. I went through this making TabletMagic to support old Wacom tablets: every system has a totally different way to deal with control panels, daemons, etc. Thankfully, for the moment, they must still speak the "RepRap language" as a final output. The community still has leverage on this side of the equation….

[wijnen]

@thinkyhead In my case, my software is open source and the protocol is available, but I'm not even trying to keep it constant between versions. When you update, you need to flash new firmware to your printer (which is a single button operation from my host software). Everyone is free to look at the protocol and learn from it, but it isn't intended to be a standard by any definition of the word.

As for the print button: I think it should be modeled after 2-D printer drivers. I'm only familiar with the way it is done on Unix-based systems. On those, there is a standard interface to the driver framework (CUPS), which allows programs to query settings (so they can present a "printer preferences" dialog) and to send a print job. For applications, every printer is expected to understand Postscript. The framework converts this into whatever protocol the printer really needs.

I haven't written any programs with a print button, but my guess is that for the entire process, there are libraries that create the preferences dialog and handle all the communication. As an application developer, all you should need to do is add the button and write a function to create the Postscript. Regardless of how it does work exactly for 2-D printers, I think we should define those things:

• A language to use for sending the data. STL is too limited IMO, because it lacks support for non-straight segments and multiple materials. AMF seems better, but I heard it was not an open standard?
• A method for connecting to the driver framework. Most likely, this is simply a network port.
• A protocol to use on the connection to the driver framework.
• As part of that protocol, a method to register a printer to the driver framework.
• A standard language to use for well behaving printers. In the 2-D world, almost every printer has its own proprietary protocol (though expensive printers actually use Postscript). The framework should be able to handle that, but it would be nice to tell people "if you want to have your printer supported without writing a driver for it, you should understand this protocol". I think that protocol should probably be G-Code, which then should be better defined than it is now. This is not about what to send over the serial port; that's an implementation detail in this story. It's about what the framework sends to the printer host program (which may or may not have a GUI, but must have a network interface).

It is probably a good idea to allow host software to be started by the driver framework, so that the printer driver is only running when there is an active print job. For software written as a server, the program that is started by the framework is a simple proxy that passes all data to and from a network connection.

Anyway, I was hoping to write proposals like these in the new group which is meant for community-wide discussions. I can register a project for this myself, but I feel it would be better if a better-known person would do this.

[daid]

AMF is indeed not really open (yet). And contains a few flaws IMHO.
Microsoft came with 3MF: http://www.3mf.io/

The microsoft 3D printer driver stuff isn't that complex. And they have "example" drivers that do "3D model -> gcode", as well as the "gcode -> USB-Serial stream" stuff. Their slicer is quite basic as far as I understood. I have contact details at Microsoft for the 3D printing stuff, if you want to dive into that area.

[wijnen]

Hmm, and we need a name of course, before we can register anything. Shall we just follow the title of this issue, "RepRap Standards Consortium"?

[daid]

I think something like "Open 3D printing Standard Consortium" might be better. Outside of the RepRap scene (which is only a part of 3D printing) the name RepRap isn't that well known and does not mean much for those people. "open" on the other hand, is something that people understand a bit better.

[wijnen]

@daid I think it's important that this is cross platform, so driver writers don't need to write a separate driver for every OS like they do now for 2-D printers. Is Microsoft's way of doing things portable to other systems, so that would be an option? If so, then it may be a good idea to do that. However, my experience with Microsoft is that they usually try their best to break things on other platforms, and break things from others on theirs. I don't feel comfortable using anything they made, because of the risk of them screwing us over.

Looking at the 3MF format, it is very similar to AMF from what I saw. In fact, it seems they simply renamed the XML tags... It also doesn't support non-straight edges, which are an important feature IMO. So I wouldn't want to use this format.

However, I'm not aware of any open format that does support them, and I don't think creating yet another format is a good idea. Perhaps we can insert them into 3MF or AMF through their extension systems.

As for the slicing, I think it is important to have options there. There are many things you can want from a slicer, so it doesn't make sense to have one slicer for all users. Also, it may be good to have different slicers for different formats. For example, I would like to have a Print button in KiCAD as well, which generates Gerber files that can be converted into G-Code and then milled on a RepRap. So I think the framework should provide a method for registering and choosing different slicers as well. If Microsoft doesn't support that, I think we should ignore their system and write our own. Because of their malicious history, I would feel more comfortable with that anyway.

I'd happily do much of that writing. However, before I do that, I think we should set up a group where we can make collective decisions. Not to force people to do things, but to know that the community wants this, and so the work that is put into it is not wasted. So again, can someone please set up such a group?

[wijnen]

@daid That's probably true. On the other hand, the consortium may grow to do more things than its original scope (for example, we may want to support PCB milling as well). So it may be better to use a name that doesn't describe much of what we're doing. "RepRap Consortium" would be even better from that point of view. Then again, having "Open" in it is also good, because as you say it describes our identity, which isn't going to change. Open RepRap makes no sense; that suggest that there is also a Closed RepRap. "Open 3-D Consortium" perhaps?

[daid]

No, you don't want milling. A 3D printer is not a mill. Don't pretend it's one. Mills already have a pretty good set of semi-standard GCode. Don't clutter a standard because you have some crazy workflow that 0.1% of the actual users might consider using. The whole idea of making a standard is making the default workflow easy for users, and trouble free.

A 3D printer is a 3D printer. It produces 3D dimensional objects. Stick with that.

2D milling/lasercutting/whatever should not be mixed into that. 3D milling, maybe.

[wijnen]

I wasn't saying that it must be part of the same standard; I was saying that the consortium might also do other things than just 3-D printing, or just standards. So I would like to keep those elements out of its name.

It's not disastrous to have an incorrect name: IBM (International Business Machines) sells to consumers, too, and Microsoft also sells hardware. Both of them don't seem to suffer from their incorrect name. But that doesn't mean we should choose a name that we can see coming is going to be incorrect in the near future.

[thinkyhead]

Open 3D printing Standard Consortium

👍

[thinkyhead]

writers don't need to write a separate driver for every OS like they do now

This will not be changing anytime soon. You can make a lot of the code shared between systems, but the glue code and the UI code will be totally unique to each system. This is where user-space applications have the advantage. They can be written in Python and use Qt, or be written in Java, and be packaged up to run anywhere. Not so with integrated system components.

[wijnen]

@thinkyhead I disagree with you, and I would like to explain why, but not here:

In order to get anywhere, I think we should really set up this new group. If things go well, it will probably get its own website with more custom tools, but for now, to get things started, let's just open a repository here in github, put the standard(s) as files under version control and open issues for discussions. As I wrote, I would prefer if someone else creates the project, but I might just do it myself. I know I don't give people much time, but I do want to have these discussions (there are several combined in this issue) and I don't think it's productive to have them here. Also, it really doesn't make a difference who creates the project.

As I wrote, I have an opinion about the name, but on the other hand I don't care much. Let's get this thing started.

[fmalpartida]

Hi,
do count me in. Though I have little spare time: day job (that pays for the bill), family (kid take most of it and it will get worse when they are on vacation). It leaves little time for anything else.

I do like very much the idea of having a common interface defined between firmware/host.

As a matter of fact I wouldn't like to be on the host/slicer developer's side on an environment where interfaces are constantly changing, working against different interpretations of a particular feature or command. I think that we have reached a point in which running open-loop is by no means a way forward and is heavily impacting our limited contribution time.
I do think that the 3D arena is changing very fast and could change even faster if efforts were dedicated to set alignment. Time could then be dedicated to adding features, refactoring or even bug fixing as opposed to implementing or re-inventing the wheel (hope we don't end up with many wheels though) with different interpretations or variants.

We have to recognise that no 3D printer will work if any of it components are not in synch (well any system really). We do have limited time, and it is time that most of us give generously to improve and/or share. It is great to see that efforts are going in this direction.

How and where? I don't think a "bug tracking" system is the right place. A wiki? perhaps, the goal is to have a place for team collaboration so why not. If there is something that has been initiated that can be used to start with lets use that, if at a later stage it feels that it is not working, it can be changed.

This brings back some echoes from the past reviving RFCs! These were finalised by email, back at the time so...

Very supportive of the initiative.

[foosel]

@wijnen You should have gotten an email from reprapcode.haz.wiki (if not, check your spam folder and if it's not there drop me a mail at osd@foosel.net).

I moved the current reprapcode spec to its own namespace (called spec since that's where I put the subpages already, sorry for that, can't change that now or the pages will lose their existing disqus threads which I'd like to avoid for obvious reasons), feel free to open up new namespaces for further specs.

The wiki also allows rights management per namespace, so we can add independent subgroups of users if need be. You need admin rights for that though which I can't hand out - the wiki is provided by a good friend of mine and he trusts me to limit that kind of access. So just tell me if you need anything. I can look into Github/G+ logins though.

Sorry that took so long, still fighting off a nasty cold.

[fmalpartida]

@foosel my email: fmalpartida@gmail.com

Take care of that cold!

[thinkyhead]

It might help to know about some of the codes being proposed for the next version-tagged Marlin through their inclusion in the Development branch…

M0 - Include an LCD message text in Wait
M33 - Get the longname path of an SD file or folder #2108
M34 - Set SD card sorting options (requires SDCARD_SORT_ALPHA)
M48 - Z Probe repeatability test
M111 - Set the debug level (already in the standard, but new in Marlin, and doesn't do much yet.)
M120 - Enable endstops
M121 - Disable endstops
M145 - Set the heatup values for a material in the LCD menu (added for EEPROM parity)
M380 - Enable solenoid on the active extruder
M381 - Disable all solenoids
M410 - Quickstop, Abort all planned moves
M420 - Enable/Disable Mesh Bed Leveling (added for EEPROM parity)
M421 - Set a single Mesh Bed-Leveling XYZ coordinate (added for EEPROM parity)
M428 - Set home_offset based on the distance between current_position and the nearest "reference point." (exposes an action that already exists in the LCD menu)

Items added "for EEPROM parity" are codes that correspond to values stored in the EEPROM, so that now the contents of EEPROM can be expressed / reproduced as a snippet of G-Code.

[alranel]

If you start this, count me in.
But I'm not supporting this initiative because I don't think it would work. A standardization consortium is usually started by multiple competing companies or organizations agreeing on making their products compatible instead of building walled gardens. Since we're basically talking about the firmware protocol (aka G-code), a consortium makes sense if multiple competing firmware projects partecipate in it. Other stakeholders, like G-code generators, host software or individual users are useful but they're not the core of the agreement. So a consortium won't make sense if Marlin is the only involved firmware project (and by the way, is Marlin adhering officially as a project?).

For now I propose a 3D printing firmware manifesto with just three points. If everyone agreed on that, we'd at least avoided bad changes like what happened to M204.

[Jnesselr]

If anything, hosts should be heavily involved. Personally, I think the host/SD card holds the interface as opposed to the firmware. Looking at the firmwares currently, I wouldn't trust that they could present an agreeable set of gcode to communicate with anything. This definitely wouldn't bring up things like automatically giving the temperature or even the format the temperature comes back as. I'd like to standardize things like that. Things like that only really affect the host side. There are other things like machine auto detection and baud rate auto configuration that would be useful to put with something like this.

I'm just saying, it's very important to consider the host's perspective.

[wijnen]

@alexrj I'm not sure how "count me in" and "I'm not supporting this" go together... Do you reserve your support for things that you are sure to work?

Anyway, you seem to be misled by the name "consortium". I don't really have a better name, but what you describe is not what I want to set up. I want a place for everyone involved in 3-D printer development to discuss things and organize things that nobody can do on their own. The most obvious one is writing standards, but as far as I'm concerned we can do other things when the need arises. And yes, I certainly want more than only Marlin to join. A good start is that I myself have no relation at all with Marlin; I'm not even a user. ;-)

As I wrote in #2090, I like to keep the standards on reprapcode.haz.wiki, at least for now, because it'd be a waste of time to move them. However, if we want some rules for how to decide on accepting or changing a standard, we will probably want something which isn't as easy to change for that. So unless somebody objects, I'll set up a github project for the administrative side of this.

[Jnesselr]

I object! Mostly because @foosel and I are already setting up a Github group. Give us a couple of days to set some stuff up.

[alranel]

@wijnen, a place to discuss is not enough for making standards. We can discuss and agree on changing G1 to FOOBAR1, and even writing a nice spec on a nice wiki, but if no firmware or just a single firmware implements it, then it's not a standard...

[Jnesselr]

@alexrj Agreed, but we have to start somewhere.

[daid]

@alexrj You control a major slicer. I do so as well. We control a major firmware here. I have no idea what the state of Sprinter is. @foosel has a major part with OctoPrint.
I think we're combined quite capable of making changes. But initially we don't have to make changes, initially we just have to agree on what actually is the current mess and call that the "legacy standard" or something.

[alranel]

Usually, the starting point for making a standard is when multiple established organizations or projects agree on sharing the protocol design process. So, first step is making a list of what firmware projects are willing to share a common protocol. If there are at least two, and they have a good userbase share, then the process will have chances to succeed. Otherwise it will just be another unimplemented proposal.

@daid, protocol adoption is generally controlled by the receiving part. In this case, firmware. In case of HTTP, HTTP servers (not browsers). In case of HTML, browsers (not web design tools)... etc.

[wijnen]

@Jnesselr Ok, that's great. I didn't know you were doing that; I'll just wait for you then.

@alexrj You keep implying that I'm going to write a standard and then tell you that you must use it. That is not how this works. We (that includes you) write this standard, and then we (including hopefully all available firmwares and hosts) will like to have a standard, and will use it.

So yes, multiple organizations must share the protocol design process. Why do you think we continue telling everyone that we want their input? What we're currently doing is meant to be a joint effort by multiple organizations, and by the looks of it we do indeed get input from several important players in the community. So instead of explaining how things are supposed to work, look at what's happening and join the fun. ;-)

[jminardi]

At the moment, there is an "ok" extension (to include the current line number) being considered, but the syntax differs between Repetier and other hosts.

I think this small change would go a long way in fixing many of the problems I have as a host software developer. Any updates on this proposal? Where can I read more?

[Jnesselr]

@jminardi http://reprapcode.haz.wiki/spec/communication_basics#comment-2018912627 is where we started discussing it.

[thinkyhead]

it's very important to consider the host's perspective.

Feature requests for the sake of hosts are most welcome! I've been thinking a lot about how to make the host UX a bit better lately. #2108 for example…

[thinkyhead]

We can discuss and agree on [g-code changes] but if no… or just a single firmware implements it…

Not to mention, if no slicers support it, or if few do. For example, G2 and G3 are very sad and lonely codes, but of course it's not a trivial problem for slicers to calculate these curves. And not all slicers (@daid Has Cura got it yet?) support firmware retraction, even though it's been around a while.

The approach taken in Marlin (recent historically) has been to add new codes that fit loosely with the number scheme of the other codes, and if they take arguments, to follow standard procedure for argument lettering. Reading through the M204 thread it seems the author made a natural extension to the code, but broke backward-compatibility in the process. After some discussion, compatibility was restored. A similar issue occurred with G28 in which a seemingly natural extension was added as a proposal, but due to G-Code conventions that the author was naive about, this also broke backward-compatibility. After discovering unexpected behavior and some enlightening discussion about G-Code arguments, it was determined that G28 needed to remain as it is.

We recently had the addition of G29 E where a single letter is added as a flag. But the reason that the "G28 set current position" extension had to be reverted is that hosts send G28 X0 Y0 all the time, regardless of where end-stops are, and (I may be confused but) I believe that there is a rule in some "official G-Code specification" that all letter arguments must include a numeric value, even if they're just a flag. And yet, there's no technical requirement to follow such a rule, so if all stakeholders agree, then such guidelines can be dropped or altered.

The new codes in Marlin which I mentioned above are mostly ad-hoc, codes chosen to fit into the general number scheme, and yes, without regard (AFAIK) for whether Repetier host and other firmware uses them for some other purpose. The informality of Marlin's "inclusion policy" has facilitated new features and some experimentation in the Development branch, and this has helped to disseminate work in progress to the widest possible base, garnering a higher volume of testing and feedback in the last few months than Marlin has had historically. This has led to increased dynamism in the project, which I hope will continue.

So, firmwares can and should be free to experiment in this way and gather feedback. But, before finally publishing these changes in releases, projects should ensure (by some communication) that any new codes or changes to existing codes are copacetic with hosts and other firmwares. If hosts or other firmwares have better ideas, those can be adopted.

So, while I cheekily titled this subject with "Consortium" I think all that's ultimately needed is good dialog.

[wijnen]

On Thu, May 21, 2015 at 04:02:23PM -0700, Scott Lahteine wrote:

there's no technical requirement to follow such a rule

There is a technical argument. It makes it easier to parse G-Code if
everything looks more or less the same. For that same reason, original G-Code
does not support putting strings (such as filenames) in a command. And also
for the same reason, we are now discussing how we should change string
arguments in a way that makes them easier to detect. Please come and join the
discussion. :-)

The goal here is to get as much load off the plate of the microcontroller. If
something can be done on the host, it should.

For this same reason, I do not think that the firmware should be concerned with
retraction, for example. The Slicer may use such codes, but then the Host (or
in my proposal, the Driver Framework) should convert them into G1 commands.

So, firmwares can and should be free to experiment in this way and gather
feedback.

I disagree on a minor point. I think they shouldn't be free, but allowed. The
difference being that they should use special experimental codes that are not
supposed to be used in production. When the feature is ready and useful, it
can then be renamed into a standard G-Code.

[thinkyhead]

There is a technical argument. It makes it easier to parse G-Code if everything looks more or less the same.

Well, just to take the case of G29 E, checking for the existence of E is quick, and it doesn't run any code looking for a number. The same is now true for G28 XYZ – the code no longer cares if there are numbers, and it is thus smaller and faster. You can send G28 X0 Y0 Z0 instead of G28 XYZ (or G28) but all that does is make the serial transfer and string-scanning take longer.

I just recently committed some comprehensive changes to optimize G-Code parsing, mainly by reducing the amount of string-scanning required. Slicers and hosts can further reduce the CPU usage of firmware by removing trailing zeros after the decimal point in numeric values. (Assuming 3.12 and 3.12000 result in the same internal representation.)

[thinkyhead]

I do not think that the firmware should be concerned with retraction, for example.

I tend to agree, and yet I do like having the option to set retraction in the firmware and then use the same G-Code on multiple machines with different extruder characteristics. Also, without formal firmware retraction, the firmware doesn't have any concept of retraction, and can't do anything special in response to it, such as choose not to retract, or to retract a different amount under some circumstances.

But I wonder why firmware retraction was introduced in the first place…? Here's the original commit

[wijnen]

@thinkyhead Yes, there is also a technical argument for omitting the number indeed. I tend to go with doing things the way G-Code expects them, but I'm not saying that this is the only correct thing to do (if only because G-Code is such a broken format that it can't really get any worse). My reason is that if you care about your transfer rate, you shouldn't be using G-Code in the first place. (Which is one of the reasons I wrote my own firmware, which doesn't use G-Code.)

I do like [...] to [...] use [...] G-Code

If my framework proposal gets traction (please comment on the wiki!), nobody will be using G-Code anymore; it'll be a format internal to the system, similar to Postscript or Windows MetaFile (both of which can, and are sometimes, used by humans, but are much more regularly used in communication that doesn't directly involve them).

[thinkyhead]

G-Code is such a broken format that it can't really get any worse

Even so, parsing it is a cinch. I see no problem with extending it to fix some of those shortcomings – like adding proper quoted string support, for example.

please comment on the wiki!

I will check it out after getting some proper food… Felafel is calling me.

[foosel]

To get back on the github group thingy, took us a while due to a lot of other stuff going on, but it's now up at https://github.com/RepRapCode and the start of a spec for the comm protocol from the wiki was just moved over to https://github.com/RepRapCode/RepRapCode too, including backlinks to discussion on disqus. shiny new issues for the continued discussion from here on in the issue tracker, full fledged git commit logs and the possibility to do pull requests against the current version of the spec.

I hope that makes everyone happy who was objecting to the selected tools previously :)

[jbrazio]

Thank you for your interest making Marlin better and reporting this issue but this topic has been open for a long period of time without any further development. Marlin has been under heavy development for the past couple of months and moving to it's last mile to finish the RC cycle and release Marlin v1.1.0. We suggest you to try out the latest RCBugfix branch and reopening this issue if required.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.