Closed matthock closed 4 years ago
@matthock, could you expand a bit on the motivation behind this? If you're set up for mesh leveling, what are the factors that motivate you to avoid it for general use?
there allready is? im using BED_MESH_OUTPUT
for octo, works great?
kind regards Tonny
Hi @matthock,
It did not look like there was a Klipper log file attached to this ticket. The log file has been engineered to answer common questions the Klipper developers have about the software and its environment (software version, hardware type, configuration, event timing, and hundreds of other questions).
Unfortunately, too many people have opened tickets without providing the log. That consumes developer time; time that would be better spent enhancing the software. If this ticket references an event that has occurred while running the software then the Klipper log must be attached to this ticket. Otherwise, this ticket will be automatically closed in a few days.
For information on obtaining the Klipper log file see: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md
The log can still be attached to this ticket - just add a comment and attach the log to that comment.
Best regards, ~ Your friendly GitIssueBot
PS: I'm just an automated script, not a human being.
It's admittedly a bit of a niche use case - I do a lot of mods on the printer and it's useful to be able to run a dense mesh to verify that everything's still square. However, this takes a long time, so I prefer to run tilt for day to day printing for faster startup (a 9mm slab of AL stays pretty dang flat as long as the rest of the machine is square). Perhaps I'll look at it myself as it's likely niche enough to not be worth main developer time.
I think what you are requesting would be relatively simple to implement. Something like this should work:
--- a/klippy/extras/bed_mesh.py
+++ b/klippy/extras/bed_mesh.py
@@ -86,7 +86,8 @@ class BedMesh:
self.gcode.register_command(
'BED_MESH_CLEAR', self.cmd_BED_MESH_CLEAR,
desc=self.cmd_BED_MESH_CLEAR_help)
- self.gcode.set_move_transform(self)
+ if not config.getboolean('diagnostic', False):
+ self.gcode.set_move_transform(self)
def handle_ready(self):
self.toolhead = self.printer.lookup_object('toolhead')
self.bmc.handle_ready()
With that patch applied, add diagnostic: True
to the [bed_mesh] section and it should allow you to probe and generate a mesh without transforming moves.
Any further updates on this issue? I'm guessing the original question was answered.
-Kevin
You can close it if you wish. I don't think there's a ton of demand for it, I can always make a new one or ask for it to be reopened if I get around to implementing it.
Okay, lets mark it closed until there is some further progress.
-Kevin
Currently, mesh and tilt leveling settings are mutually exclusive. It would be useful to be able to enable them both at the same time, at least in the context of dumping information to the terminal - essentially, be able to do a "query-only" version of mesh level while tilt level is enabled for actual usage. The goal would be to use tilt for day to day usage, but you could still run the mesh for the Octoprint Bed Visualizer.
Another similar option would be to have a separate query-only mesh command for use by Bed Visualizer. This would also be useful even if you are using mesh leveling day to day, as there are some settings you would want for Bed Visualizer that are less useful for operation and vice versa (for example, a denser mesh without interpolation for the visualizer). This wouldn't even necessarily need a config section - the arguments (such as query area and density) could be passed as extended GCODE arguments to the command as long as a probe is configured.