Klipper3d / klipper

Klipper is a 3d-printer firmware
GNU General Public License v3.0
9.41k stars 5.3k forks source link

Bed Mesh not loading, Bed_Mesh_Map attempts to generate new mesh #2594

Closed mordhau5 closed 4 years ago

mordhau5 commented 4 years ago

klippy.log

I recently installed an EZABL probe on my printer and went through the process of tuning it, z-offset, and bed mesh. I've been through this on another printer so I am quite certain I set it up properly, but not the bed mesh. Now the Z-offset has excellent repeatability, I can calibrate and re-calibrate it to within a .1mm. The bed mesh though, appears to be doing literally nothing for my prints and there are sections where the nozzle flying a mm high on the first layer! And I can say almost for certain that I do not see the bed moving during a print invoving squares at the corners and a skirt around the whole thing.

Thought I might try to get a visual on my mesh to better understand the issue so I installed a visualizer plugin for octoprint and configured it to gather it's data from BED_MESH_MAP, as indicated in the doc here. These were the results from the terminal:

Recv: // Klipper state: Ready [...] Send: BED_MESH_OUTPUT PGP=1 Recv: // Mesh Leveling Probed Z positions: Recv: // -0.300000 -0.650000 -0.900000 Recv: // 0.100000 0.000000 -0.450000 Recv: // 0.600000 0.300000 0.000000 Recv: Mesh X,Y: 7,7 Recv: Search Height: 5 Recv: Mesh Average: -0.12 Recv: Mesh Range: min=-0.9000 max=0.6000 Recv: Interpolation Algorithm: lagrange Recv: Measured points: Recv: 0.600000 0.500000 0.400000 0.300000 0.200000 0.100000 0.000000 Recv: 0.422222 0.383951 0.322840 0.238889 0.132099 0.002469 -0.150000 Recv: 0.255556 0.252469 0.213580 0.138889 0.028395 -0.117901 -0.300000 Recv: 0.100000 0.105556 0.072222 0.000000 -0.111111 -0.261111 -0.450000 Recv: -0.044444 -0.056790 -0.101235 -0.177778 -0.286420 -0.427160 -0.600000 Recv: -0.177778 -0.234568 -0.306790 -0.394444 -0.497531 -0.616049 -0.750000 Recv: -0.300000 -0.427778 -0.544444 -0.650000 -0.744444 -0.827778 -0.900000 Recv: Recv: ok [...] Send: BED_MESH_MAP PGP=1 Recv: !! Must home axis first: 0.000 0.000 5.000 [0.000] Recv: ok [...] Send: BED_MESH_MAP Recv: !! Must home axis first: 0.000 0.000 5.000 [0.000] Recv: ok

And if I home the axis and try again, it just starts the BED_MESH_CALIBRATE routine instead of dumping the mesh like it should, which is a no-go since my probe is offset too far to be useful in this regard and I have to go manual.

Really the first issue is the real one, with the second issue being a weird quirk I'd be interested in understanding the behavior better. I've read and re-read through the example-extras.cfg and Extended GCode command section on Bed Meshes, and really quite stumped!

Arksine commented 4 years ago

A few things: 1) You need to update your version of Klipper, as the documentation applies to the latest version.

2) Make sure your visualizer supports BED_MESH_MAP. Most have not bothered to implement it, they just use the output generated by BED_MESH_OUTPUT.

3) In the latest version of Klipper, when PGP=1 is set BED_MESH_OUTPUT prints generated probe points. This data isn't useful for a visualizer, it wants the mesh data.

Also, make sure you read the Config_Changes.md before you update. You will find that min_point and max_point are deprecated, as in the new version bed_mesh expects points relative to the probe location. Since you are manually probing the mesh, you probably don't need to change the values, just the names of the options (min_point is now mesh_min, max_point is now mesh_max). You will need to re-probe your default mesh.

If you want to stick with the version you have for now, I would advise using a visualizer that accepts BED_MESH_OUTPUT. The older version of BED_MESH_MAP does a calibration then outputs the results to the terminal in json format. The new version does not do a calibration, it just uses the existing mesh data to output the results to the terminal (in json format).

mordhau5 commented 4 years ago

Ahah! I believe not being up to date caused confusion with another issue of mine before. And I see you were involved in the commit for the bed mesh changes. I do not see a new release though. I've only ever used my MCU maker's procedure for updating which involves putting the whole octopi/klipper instance on a new image and flashing a corresponding firmware to the board.

mordhau5 commented 4 years ago

An update on this: I updated klipper and my bed_mesh parameters. However, I'm still seeing really inconsistent prints, needing to bump the the z height up or down by as much as .6 mm on some prints. Before klipper I was used to having to babystep the Z to really hone in the perfect layer, but never more than .1 mm.

Arksine commented 4 years ago

Are you having to make this adjustment throughout the first layer, or just initially? If its just initially then your z-offset is off. If its throughout the entire first layer then its possible that the x/y offsets are off, or there is some kind of accuracy issue while probing the bed. Its also possible that there is some kind of accuracy issue that is affecting homing if the adjustment is initially, but changes wildly for each print

mordhau5 commented 4 years ago

Are you having to make this adjustment throughout the first layer, or just initially? If its just initially then your z-offset is off. If its throughout the entire first layer then its possible that the x/y offsets are off, or there is some kind of accuracy issue while probing the bed. Its also possible that there is some kind of accuracy issue that is affecting homing if the adjustment is initially, but changes wildly for each print

It was all throughout the first layer. I took a closer look at the z-heights fed back from the bed mesh calibration and found they were far less precise than the Probe-Accuracy test values. Readjusted the mounted height of the probe and found my standard deviations dropped significantly and now getting a mostly nice looking first layer :)

I did have a related question though that I don't know where else to ask and then I'll close: because the probe is offset from the nozzle by some amount, it obviously can't touch down on every spot on the build plate. How does the bed mesh mechanism handle the areas outside of the probed area? Does it just treat them as if they're at the offset at the nearest point of the mesh, is a slope determined and extrapolated, or are they just not adjusted at all?

KevinOConnor commented 4 years ago

As I understand it, the areas outside of the probed bed mesh region are clamped to the values determined at the edge of the bed mesh region.

-Kevin

mordhau5 commented 4 years ago

As I understand it, the areas outside of the probed bed mesh region are clamped to the values determined at the edge of the bed mesh region.

-Kevin

That explains it. Thank you, Kevin. And also thank you for your answer in IRC last night, I was able to create my toggle macros thanks to you explanation of the .value attribute on an output_pin!