Clarify on some requirements for adaptive meshing

[kyleisah]

Just wanted to clarify that adaptive meshing relies on objects being defined by the exclude_object module, as well as some other small changes for better readability. I'm open to any other changes recommended to better fit the formatting of the rest of the documentation. Thank you!

[Sineos]

According to your KAMPS GH repository, setting

[file_manager]
enable_object_processing: True

is also a prerequisite. Is this still true for the new implementation?

[kyleisah]

According to your KAMPS GH repository, setting

[file_manager]
enable_object_processing: True

is also a prerequisite. Is this still true for the new implementation?

Yes and no, as some slicers have the ability to do it without moonraker needing to process the gcode file. It’s also a setting in moonraker and not klipper, so I wasn’t really sure of the best way to mention all of that. I left it in the realm of “make sure objects are being defined before the command is called” but I guess a new user might get hung up on that.

[Sineos]

Moonraker today is the de facto way to use Klipper. Likely, the numbers of Octoprint users are dwindling more and more, if not already insignificant. If this feature needs an interaction with Moonraker, even if only in some cases, I would vote for mentioning it. Also, in particular, since this Moonraker setting defaults to false. A regular user will not find out, why his setup is not working otherwise.

[kyleisah]

@Sineos Oh wow, so I just double checked the exclude object modules readme here and there’s no mention of defining [file_manager] in moonraker or anything like that.

I agree that these things should be mentioned and laid out, but I want them to be in places that make sense. I can make some updates to the .md for exclude_object to include setting it up in moonraker, or have it point to moonraker’s documentation for it. What do you think is best?

[kyleisah]

Perhaps I could also expand on the adaptive meshing section a bit further with a small table of prerequisites, similar to the documentation for KAMP

[Sineos]

I'm not the expert, but if enable_object_processing: True is a general prerequisite for successfully using [exclude_object], then I would mention it in both places, i.e.:

• https://github.com/Klipper3d/klipper/blob/master/docs/Exclude_Object.md?plain=1
• https://github.com/Klipper3d/klipper/blob/9f41f53c5e364694b9b41279b3b3aee34250b93a/docs/Bed_Mesh.md?plain=1#L373

Something like:

Using Moonraker requires enable_object_processing: True in the [file_manager] section of the moonraker.conf file.

[jernejp21]

I really appreciate you are documenting everything. I just found out today for adaptive mesh functionality and wanted to test it out, but reading documentation I had no success. I tried to put [exclude_object] in printer.cfg, but still whole bed is probed.

I would appreciate more details what is expected in config files or slicer to correctly set up g-code for parsing. I know this is brand new feature and it's early. I just wanted to express that some info is still missing.

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

[KevinOConnor]

Thanks for working on this. What is the current status of this PR? Is there a consensus on a documentation change?

-Kevin

[github-actions[bot]]

It looks like this GitHub Pull Request has become inactive. If there are any further updates, you can add a comment here or open a new ticket.

Best regards, ~ Your friendly GitIssueBot

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