adds GET_INPUT_SHAPER gcode command

[jasonhamilton]

Module: Input Shaper

This PR adds a gcode command GET_INPUT_SHAPER that allows user to query input shaper currently in use by the printer. Sample output attached as an image below (same output when setting the shaper).

The reason I added this is because I was having difficulty debugging and determining what input shaper was enabled. I know this sounds obvious that you can just look at the config but hear me out... On my Creality K1 an input shaper is automatically selected and enabled by the initial printer setup by default. My printer is rooted and I wanted to customize the input shaper in order to run comparison tests. The issue I ran into was that I couldn't determine what input shaper was being loaded - was it the one I put in my printer.cfg or was this being overridden by Reality's shaper. Maybe there's an easier way to get this value but the only way I could figure it out - outside of adding this code - was by dumping all of the variables with a custom GCODE script.

Adding this PR in case it might be useful to others - I would imagine others with the same machine would benefit from being able to easily debug and determine the input shaper being loaded properly and not overridden. If it's too much of a corner case I totally understand but for me it seemed logical since other commands have the ability to get the config params, i.e. GET_RETRACTION, and with it added the Input Shaper module will have a total of only two commands.

Signed-off-by: Jason Hamilton jasonscotthamilton@gmail.com

[darkjacky]

Have you tried typing SET_INPUT_SHAPER into the console and seeing what happens?

[jasonhamilton]

Have you tried typing SET_INPUT_SHAPER into the console and seeing what happens?

Just tried it. I've used Klipper for years and to me it's not obvious from the documentation you would be able to run that command without params and get the results. Given the name of the command I didn't try it because I assumed it would SET something and potentially change the state of the input shaper.

After looking under the hood it's obvious but I don't think most people are looking through the code. It might be helpful to put that in the documentation. Happy to write it if you think others would benefit. Otherwise not trying to die on this hill.

[ProfDrYoMan]

You can use this macro to query all parameters and configs. https://ellis3dp.com/Print-Tuning-Guide/articles/useful_macros/get_variable.html Doesn't this work?

[jasonhamilton]

You can use this macro to query all parameters and configs.

https://ellis3dp.com/Print-Tuning-Guide/articles/useful_macros/get_variable.html

Doesn't this work?

Yes that was what I used to dump all variables and imported configs. Just a lot of text to sort through.

[ProfDrYoMan]

Since Kevin mentioned many times that he will not accept pull request for many things that can be achieved by macros you can wait a long time for this to merge.

My guess.

A dockable probe PR sits there waiting because of this argument for a long time.

[github-actions[bot]]

Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html

There are some steps that you can take now:

1. Perform a self-review of your Pull Request by following the steps at: https://www.klipper3d.org/CONTRIBUTING.html#what-to-expect-in-a-review If you have completed a self-review, be sure to state the results of that self-review explicitly in the Pull Request comments. A reviewer is more likely to participate if the bulk of a review has already been completed.
2. Consider opening a topic on the Klipper Discourse server to discuss this work. The Discourse server is a good place to discuss development ideas and to engage users interested in testing. Reviewers are more likely to prioritize Pull Requests with an active community of users.
3. Consider helping out reviewers by reviewing other Klipper Pull Requests. Taking the time to perform a careful and detailed review of others work is appreciated. Regular contributors are more likely to prioritize the contributions of other regular contributors.

Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards, ~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.