Ignore G21 (set units to millimeters).

[jothan]

Emitted by Slic3r and others. Triggers an "unknown command" error
otherwise. It is pretty much a no-op on Marlin.

In some cases, it might trigger a "Wait for user" prompt on the display.

[nophead]

I think there will be many of these because the previous behaviour was to silently ignore unknown codes. Certainly Skeinforge outputs a lot of old codes such as M113, M108, M101 and M102.

[Wackerbarth]

I would contend that the proper action is to "set units scaling factor = 1.0" (Which is likely a "nop" unless we also implement G20). But the proper action is to recognize the code and "execute" the appropriate action. If we don't handle G20, then we should still recognize that code and return the "not implemented" response.

[thinkyhead]

silently ignore unknown codes

True. Except for codes starting with something other than G, M, or T.

It should be relatively harmless for these replies to occur for unknown codes, and it might even be useful to receive a reply that the firmware doesn't implement a given code. But, I put the question to the community… Is there any need for the firmware to reply when it encounters unknown codes? Should it silently ignore all of them? Or, should there be some "not implemented" message too?

[nophead]

Just like why should the protocol change arbitrarily, why should the semantic behaviour of Marlin change arbitrarily? Sudden change from ignoring unknown codes for years to giving errors. No discussion, just a sudden change which then brings in bug reports.

[thinkyhead]

No discussion, just a sudden change which then brings in bug reports.

A lot of PRs sit around for a while with no feedback, apparently no problems encountered. Perhaps they are barely ever tested. So, unfortunately sometimes the only way that a bug is discovered is to wait until after a PR is merged into the Development branch, and then of course everyone comes out of the woodwork to complain about the bug. It's about the only "trick" that works to get things tested and move things forward sometimes.

So, recent optimization to the gcode parser has introduced a new behavior which apparently is undesirable. It's quite easy to fix. Would everyone like me to fix it?

[thinkyhead]

#2193

[ntoff]

Just like why should the protocol change arbitrarily, why should the semantic behaviour of Marlin change arbitrarily?

I had no idea until now that setting the units to millimeters had no effect. I think giving the user feedback that a feature is unsupported is an excellent step forward. Just because "that's the way it's always been" doesn't mean it's the best way.

I think a Marlin V2.0 would be a good place to bring in a lot of new features like a standardized communications protocol that's been in discussion and also better feedback for unsupported commands and commands that are supported but are disabled during compile.

[jothan]

Thanks for fixing this !

[thinkyhead]

I think the next Marlin version tag will be 1.1.0 because there have been updates in the configuration files, and enough added features to warrant a bigger bump.

If we make a straight-up comparison of Marlin 1.0.0-1.0.2 to Marlin 1.1.0, I don't want there to be any changes in behavior that affect hosts or otherwise change the serial interfaces in inconsistent ways. In patching up process_next_command it seems that the intent of the unknown command message should apply to unrecognized codes also, but I agree it should not be the default behavior if it's liable to harm host communication. I don't know what hosts do with "unknown command" messages because up to now they have only been useful to trap mangled code. But I think ideally there should be an option or another message for unrecognized codes, so hosts can know that a code didn't get through.

That would be the role of M111 which allows you to set debug flags. It's a part of the "standard" as listed on the RepRap wiki page for G-code, but up until recently Marlin didn't have any support for it. By sending M111 S68 (or something like it) a host or user could request that Marlin reply "unknown command" when it doesn't recognize a command. Anyway, it's a thought – other firmware wouldn't necessarily need to adopt the same flags as Marlin, but each firmware should document their usage of M111.

[nophead]

I don't think hosts care too much about the gcode. It comes from the slicer and in general the host just sends it to the printer with a few exceptions for special cases.

Since my files come from skeinforge I would not want to hack it and re-slice them all to use a later version of Marlin. Even if the host ignores it, a wall of unknown command messages would not be good.

[ntoff]

@nophead A bit off topic but how do you find skeinforge? I use it primarily but find some small surfaces don't get filled, I'll end up with 2 shells touching, blank space in between and another 2 shells touching on say a 1.5mm wide object. I don't have the same issue with slic3r.

[nophead]

Yes multiple shells don't work very well on small objects so I always use a single shell, but the way Skeinforge connects the infill that is equivalent to two shells on sparse layers and extra shells on solid layers have no benefit. As I design my objects with OpenScad I can specify the filament width and avoid having any artefacts that cant be filled. I.e. between 2 and 3 filaments widths.

The other major defect is it that it only has one bridge direction for each layer, rather than each island. Again I can design around it. The plus side is it never changes so there are no new bugs.

[ntoff]

It's ok if I'm making the thing, but when downloading stuff, it's a bit harder. So that's just the way it is then? Pity, I really love the supports it makes. They're brilliant.

[nophead]

Yes I don't have much luck with downloaded STLs. It is easier to adapt the design to the print parameters than it is to adapt the print parameters to the design.

[thinkyhead]

Who wants to revisit the topic? See #10554…