-
-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Creating standard G-code aliases for appropriate extended g-code commands? (reprap wiki) #2142
Comments
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 ).
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 |
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.
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
...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 The "standard" on Reprap wiki just says " The second... are you seriously suggesting people would ever start using a mailing list for discussions in 2019? |
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. |
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, |
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. |
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 If someone wishes to do this, feel free to open a PR with the results. -Kevin |
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
toBED_MESH_CALIBRATE
orM420
toBED_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
The text was updated successfully, but these errors were encountered: