Creating standard G-code aliases for appropriate extended g-code commands? (reprap wiki)

[JohnEdwa]

So, I noticed that someone has started adding Klipper to the reprap wiki G-code page, but obviously from their point of view Klipper has a pretty minuscule feature set as none of the extended gcode commands can be added.

While I understand and have to agree that the extended commands are much more human-readable and easier to use, and some of them truly don't work like their standard G-code equivalents would, I don't see what benefit there is to not also adding as much support to the standard G-code wherever possible.
A lot of them would be as simple as translating from G29 to BED_MESH_CALIBRATE or M420 to BED_MESH_OUTPUT and could fairly easily be done with either macros or aliases.

If made, would a list like this be merged to Klipper?

---

Could you also implement templates to this issue tracker like Cura has for example, so the bot doesn't get excited about ever posted feature request that doesn't have a log attached? klippy.log

[KevinOConnor]

I'm not sure what's being proposed here, so it's hard for me to comment.

If the goal is is to start a general conversations on high-level direction, the mailing list may be a better venue ( https://www.klipper3d.org/Contact.html ).

Could you also implement templates to this issue tracker

I don't think github issues are a good place to report feature requests. (In my experience, most feature requests just sit open forever and clutter the open issues.) The mailing list could be used for feature requests - though admittedly, the mailing list isn't currently used much.

-Kevin

[JohnEdwa]

The first proposition is making Klipper more standard "compliant" by implementing the standard Gcode commands that Klipper already supports but is just using different names, using the functionality already present such as macros and aliases.

G30 is not supported, but PROBE does the same thing. M48 -> PROBE_ACCURACY, BED_MESH_OUTPUT outputs the same thing as G29 T and so on, there are a lot of others where the only difference is the name of the command.

I'm asking this right now because I'd rather wait to see what is and isn't implemented before going to plaster "Not supported" on everything on the reprap wiki that Klipper actually technically supports, but doesn't simply answer to the standard Gcode command for it because the name is different.

And I know perfectly well you have the mention of

Klipper's goal is to support the G-Code commands produced by common 3rd party software (eg, OctoPrint, Printrun, Slic3r, Cura, etc.) in their standard configurations. It is not a goal to support every possible G-Code command.

...but that's currently not even true, as all ABL equipped printers already do use G29 out of the box.

Now certainly some of them are too different to actually implement, and I don't think trying to add G29 with all the bazillion (mostly Marlin specific) parameters as an alias for all the ABL stuff would make sense at all, but if the user sends a plain G29, they mean BED_MESH_CALIBRATE, if they send G29 T they mean BED_MESH_OUTPUT and so on.
At the very least instead of just the completely useless "command G29 not recognized" error message for everything G29 related, if people tried to use the more advanced parameters it could instead print "Please use the extended gcode command BED_MESH_CALIBRATE for more advanced G29 functions" or something like this.

The "standard" on Reprap wiki just says "G29 -> probe the bed, G29 with any parameters -> firmware specific, see below", so only even a simple G29 -> BED_MESH_CALIBRATE would allow Klipper to tick "Yes" for that command.

---

The second... are you seriously suggesting people would ever start using a mailing list for discussions in 2019?
In any case, while this issue tracker certainly isn't the best place for them it has the benefit that we are already here, and adding the templates allows it to be more easily curated because they can be auto-tagged as feature requests - that is why the enhancement label exists in the first place.

[BlackStump]

Gcode Macro user can add what ever alias they want imho and while I am at it Klipper is Klipper and Marlin is Marlin why is it necessary for Klipper to be a Marlin wannabe.
I for one want Klipper to follow Klippers Direction not be dictated by Marlins history or direction.
Just my 2 cents worth

[KevinOConnor]

FWIW, I don't feel I have anything to add to this ticket. I'm not interested in spending time on g-code compatibility (implementing, maintaining, nor supporting). I certainly see value in Klipper working with OctoPrint, Cura, Slic3r, etc., but I don't see any value in supporting "general g-code".

If someone else wishes to implement, document, and support "general g-code" then that is their choice. If they wish to do that and submit it, then I'll review it to the best of my ability at that time. FWIW, I would advise anyone interested in doing that to proceed with caution - as I suspect it could become a large time-sink with no value. In particular, I fear users that are unable/unwilling to overcome the minor differences of Klipper will almost certainly be unable/unwilling to overcome the major fundamental differences of Klipper. Thus, the fear of a time-sink that is ultimately of no value.

Best,
-Kevin

[JohnEdwa]

Well, sounds reasonable enough.

Should think of adding the G29 alias though or in a year or so you might as well replace G28 with "HOME_AXIS" because it's going to be just as common on start G-codes.

[KevinOConnor]

FWIW, one possible solution would be to create a config/sample-gcode-macros.cfg with example Klipper macros for the less common g-code commands. Then a user could potentially add something like [include ~/klipper/config/sample-gcode-macros.cfg] to their config (and/or copy-and-paste desired macros to their config). I think the Jinja2 command templates should make it possible to implement most g-code commands.

If someone wishes to do this, feel free to open a PR with the results.

-Kevin