-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Conversation
According to your KAMPS GH repository, setting
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. |
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. |
@Sineos 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? |
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 |
I'm not the expert, but if
Something like:
|
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 |
There was a problem hiding this comment.
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]
?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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:
- Using
ADAPTIVE=1
is not documented in the Adaptive Mesh Chapter (https://github.com/Klipper3d/klipper/blob/master/docs/Bed_Mesh.md#adaptive-meshes) - It is somewhat "hidden" documented in the next chapter (https://github.com/Klipper3d/klipper/blob/master/docs/Bed_Mesh.md#calibration)
- It is not documented in https://github.com/Klipper3d/klipper/blob/master/docs/G-Codes.md#bed_mesh_calibrate
There was a problem hiding this comment.
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.
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 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
fix typo
There was a problem hiding this 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. |
There was a problem hiding this comment.
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 was a problem hiding this comment.
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.
There was a problem hiding this comment.
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".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- 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 to enable object processing.
...to activate enable_object_processing
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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".
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:
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, PS: I'm just an automated script, not a human being. |
Thanks for working on this. What is the current status of this PR? Is there a consensus on a documentation change? -Kevin |
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, PS: I'm just an automated script, not a human being. |
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. |
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!