Suppress Generated Points Output on Adaptive Mesh Rapid Scan With Command Option

[3DPrintDemon]

When using a bed scanner like Beacon, Cartographer, or BTT Eddy to generate an adaptive mesh & your mesh is 25,25 or 50,50 for example the console is filled with hundreds of lines of probe points. This is less than ideal as you loose all console messages before the meshing action as they quickly drop off the bottom never to be seen again (unless log is viewed of course). Not only that but running & displaying the calculations is not really needed by most users & is a drain on the host’s resources & cpu time.

Plus if you have to hit emergency stop for any reason while the host is running all these points you have to wait for it to finish displaying the entire list before you can restart the system.

Solution: Enable users to add an option to the BED_MESH_CALIBRATE command to totally suppress generated mesh point output to stop the above occurring & huge lists of numbers being created & displayed.

Usage: Use SGPO=1 (Suppress Generated Points Output) to tell the system to omit points output when meshing.

Using SGPO=0 or the omission of SGPO=<0-1> entirely causes the normal & current behaviour of outputting the generated points to the console & log.

Command Example:

BED_MESH_CALIBRATE METHOD=rapid_scan ADAPTIVE=1 ADAPTIVE_MARGIN=10 SGPO=1

Results: This is the current & normal view in the console at the moment.

This would be the results with the proposed changes in place & the use of SGPO=1 option.

With the PR changes I’ve not added the ability to have the system add the calculations to the log but it works as-is for a simple proof of concept with a solution that can be carried forward by the dev team if they deem it viable.

I’m by no means a pro coder so I’m sure this could be greatly be improved in short order but it works on my printer. Thanks for your time to read this, I appreciate all of your efforts & I hope my small contribution here could be possibly of value.

[whyme12]

I really like the idea. BUT I dont like the the parameter name. I would suggest to rename the parameter to SILENT=1 or maybe MUTE=1 instead of some weird acronym. To make it more intuitive.

And please add it to the QUERY commands too. QUERY_PROBE for example is used to detect if klicky probes are docked and spams the console with useless information for the user.

[3DPrintDemon]

Hi thanks. Im glad you like the idea. The name is easily changed to whatever is deemed appropriate. It is at the moment however represented by a similar acronym to the BED_MESH_OUTPUT command currently available in Klipper.

Klicky probe is a good system but it never really overwhelmed the console as this does tbh, it’s only a few lines in comparison.

[Arksine]

Thanks. I had actually done some work with regard to this and I just recently had the time to test, push, and create a PR...see #6828.

Rather than add an option I think we can safely remove the call to print generated points when the mesh configuration changes. The PR also truncates the initial output so the log isn't overwhelmed if an extremely dense mesh is configured. These entries were intended to be informative in case there was an issue, however we can achieve a similar result by having users manually run BED_MESH_OUTPUT PGP=1 if they think there is an issue with the generated mesh. The previous behavior could be restored using a macro if desired.

[happytechca]

I really like the idea. BUT I dont like the the parameter name. I would suggest to rename the parameter to SILENT=1 or maybe MUTE=1 instead of some weird acronym. To make it more intuitive.

And please add it to the QUERY commands too. QUERY_PROBE for example is used to detect if klicky probes are docked and spams the console with useless information for the user.

I like your PR as I also don't find much value in the mesh data being displayed on the console (I'm at 20x20 which is even less extreme) I too, however, would vote for a more intuitive parameter name. SGPO=1 when I look back at my START_PRINT macro in a few months I'll definitively have to google it. SILENT=1 sounds better but I wonder if it might be confused with an attempt of some sort to dampen the sound of the bed mesh (aka make it quieter?) perhaps NO_OUTPUT=1 , SILENT_OUTPUT=1 or CONSOLE_OUTPUT=0 (with a default value of 1)?

[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.