Skip to content
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

Clarify on some requirements for adaptive meshing #6476

Closed
wants to merge 4 commits into from

Conversation

kyleisah
Copy link

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
Copy link
Collaborator

Sineos commented Jan 29, 2024

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
Copy link
Author

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
Copy link
Collaborator

Sineos commented Jan 29, 2024

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
Copy link
Author

@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
Copy link
Author

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
Copy link
Collaborator

Sineos commented Jan 29, 2024

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

Something like:

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

automatically adjust the mesh parameters based on the area occupied by the defined
print objects.
Adaptive bed meshing is a way to speed up the bed meshing process as well as waste less mesh information by only probing
the area of the bed that will be used for printing. When used, this method will
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When used, this method will [...]

What I find a bit unclear today: What is the criteria, when adaptive meshing is used? Is it just the presence of [exclude_object] along with named objects in the gcode? What if I wanted to not use adaptive meshing? Would I need to turn off naming objects in the slicer or take out [exclude_object]?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you wanted to not use adaptive meshing, you would just call BED_MESH_CALIBRATE without the ADAPTIVE=1 flag on the command

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I wanted to point out:

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Sineos I've just made some updates to the bed_mesh.md for clarification on setup requirements. If this looks okay, I can move forward with making changes to the exclude_object.md about setting up object processing with moonraker.

docs/Bed_Mesh.md Outdated Show resolved Hide resolved
@jernejp21
Copy link

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.

Split up the adaptive meshing section for readability, and add a "how-to" section.
Remove trailing spaces
Copy link
Collaborator

@Sineos Sineos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work 👍

Just two minor nit picks.

- Certain slicers may do this by default, or do not provide an option because it is an "always-on" feature.
- More modern slicers provide a "Firmware-Specific" option for labeling objects. If you enable this, you'll need to verify that your slicer supports the `klipper` gcode flavor, and is generating `EXCLUDE_OBJECT_DEFINE` commands at the beginning of the sliced gcode file.
- If your slicer does not support firmware-specific object labeling, or does not support the `klipper` gcode flavor, you will need to [configure Moonraker's file manager module](https://moonraker.readthedocs.io/en/latest/configuration/#file_manager) to enable object processing.
- Finally, to generate an adaptive bed mesh, you must append the `ADAPTIVE=1` flag to `BED_MESH_CALIBRATE` wherever you normally call for a bed mesh to be generated.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a simple wording like

Call BED_MESH_CALIBRATE ADAPTIVE=1 either from your [START_PRINT](Slicers.md#klipper-gcode_macro) macro or from your slicer's starting Gcode. It is recommended to place this command pretty much at the end of the start-up routine, this means at least after heating up the bed.

would be clearer as these should be the two typical places for a regular user.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, that makes sense. I’ll find a spot to work something like this in as well.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a simple wording like

Call BED_MESH_CALIBRATE ADAPTIVE=1 either from your [START_PRINT](Slicers.md#klipper-gcode_macro) macro or from your slicer's starting Gcode. It is recommended to place this command pretty much at the end of the start-up routine, this means at least after heating up the bed.

would be clearer as these should be the two typical places for a regular user.

There is no guarantee that I user will be using a START_PRINT/PRINT_START macro. They could just be putting all of that in the slicer custom gcode.
It's better to leave it as "... add BED_MESH_CALIBRATE ADAPTIVE=1 to your start GCode".

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, but I do not understand this comment:
grafik

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, but I do not understand this comment: grafik

Oops, sorry! I didn't read the text carefully enough.

- You must enable object labeling in your slicer.
- Certain slicers may do this by default, or do not provide an option because it is an "always-on" feature.
- More modern slicers provide a "Firmware-Specific" option for labeling objects. If you enable this, you'll need to verify that your slicer supports the `klipper` gcode flavor, and is generating `EXCLUDE_OBJECT_DEFINE` commands at the beginning of the sliced gcode file.
- If your slicer does not support firmware-specific object labeling, or does not support the `klipper` gcode flavor, you will need to [configure Moonraker's file manager module](https://moonraker.readthedocs.io/en/latest/configuration/#file_manager) to enable object processing.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...to activate enable_object_processing

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that could use some more clarity. I’ll add that when I get a moment

print objects.
#### Concept:

Adaptive bed meshing is a way to speed up the bed meshing process as well as waste less mesh information by only probing
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does "waste less mesh information" mean? What information is being wasted if adaptive is not being used?

Also, a nit: can you please conform to the document's line length?

Copy link
Author

@kyleisah kyleisah Feb 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does "waste less mesh information" mean? What information is being wasted if adaptive is not being used?

Well, if you're doing a regular full mesh for a small cube on a big bed, you're really only using 1 probed point and some interpolation rather than all of the probed points fitting to the object being printed.

Also, a nit: can you please conform to the document's line length?

I don't know what I'm doing here, I'm just trying to help out.


Adaptive bed meshing is a way to speed up the bed meshing process as well as waste less mesh information by only probing
the area of the bed that will be used for printing. When used, this method will
automatically adjust the mesh parameters based on the area occupied by objects defined by the `EXCLUDE_OBJECT` command. See the [exclude objects guide](Exclude_Object.md) and
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually think that the old version ("area occupied by the defined print objects") was a bit better. Talking about how those objects get defined (the EXCLUDE_OBJECTS command) seem more appropriate for the "How it works" section.

have undesirable results when attempting print moves **outside** of the probed area. If a
full bed mesh has a variance greater than 1 layer height, caution must be taken when using
adaptive bed meshes and attempting print moves outside of the meshed area.
have undesirable results when attempting print moves **outside** of the probed area. If you
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I generally prefer documentation be written in a "neutral" way, without using pronouns. Not sure how to explain it so I'll give an example:

Instead of "If you normally have ...", say "If a printer normally has ...".

must be taken when attempting print moves outside of the adapted mesh area.

If there are no objects defined by the [exclude_object](Exclude_Object.md) module before the adaptive
bed mesh is requested, the default method will be used instead. If you are requesting an adaptive bed mesh and
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"default method" or "default size"?

- Certain slicers may do this by default, or do not provide an option because it is an "always-on" feature.
- More modern slicers provide a "Firmware-Specific" option for labeling objects. If you enable this, you'll need to verify that your slicer supports the `klipper` gcode flavor, and is generating `EXCLUDE_OBJECT_DEFINE` commands at the beginning of the sliced gcode file.
- If your slicer does not support firmware-specific object labeling, or does not support the `klipper` gcode flavor, you will need to [configure Moonraker's file manager module](https://moonraker.readthedocs.io/en/latest/configuration/#file_manager) to enable object processing.
- Finally, to generate an adaptive bed mesh, you must append the `ADAPTIVE=1` flag to `BED_MESH_CALIBRATE` wherever you normally call for a bed mesh to be generated.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a simple wording like

Call BED_MESH_CALIBRATE ADAPTIVE=1 either from your [START_PRINT](Slicers.md#klipper-gcode_macro) macro or from your slicer's starting Gcode. It is recommended to place this command pretty much at the end of the start-up routine, this means at least after heating up the bed.

would be clearer as these should be the two typical places for a regular user.

There is no guarantee that I user will be using a START_PRINT/PRINT_START macro. They could just be putting all of that in the slicer custom gcode.
It's better to leave it as "... add BED_MESH_CALIBRATE ADAPTIVE=1 to your start GCode".

Copy link

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
Copy link
Collaborator

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

-Kevin

@KevinOConnor KevinOConnor added the pending feedback Topic is pending feedback from submitter label Mar 6, 2024
@github-actions github-actions bot added the inactive Not currently being worked on label Mar 27, 2024
Copy link

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.

@github-actions github-actions bot closed this Mar 27, 2024
@mdshw5
Copy link
Contributor

mdshw5 commented Nov 9, 2024

I'd just like to bump this PR since I've gone though the adaptive bed mesh configuration with Klipper and moonraker, as well as helped a few others, and the only reliable place that explains the necessary configuration in detail is on the Klipper Discourse instance (https://klipper.discourse.group/t/native-adaptative-mesh-support/13541/2). I understand that this PR might be difficult since it involves changes to but the Klipper and moonraker documentation, but clarifying the setup process in some way is still necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
inactive Not currently being worked on pending feedback Topic is pending feedback from submitter reviewer needed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants