bad z heigh after z tilt and bed mesh

[NedalLive]

Hello,

I encounter a problem with the Mesh, the nozzle is still too high on the left side and still too much crushed on the right side of the bed. at first I made a Z_tilt 10, -30 10, 220 320,75 then I make a 5x5 mesh and save it with the name BED100, load the mesh and print the print the left side is always too high I try different area probe Z0 completely front left, front center, and in the middle of the bed, it does not seem to affect the left side is still too high ... i also try to subtract the value of z_adjust provided during Z_Tilt to my Z_offset but the result is the same the left side is still too high.

I voluntarily placed the inclined bed (left side raised 3mm from the right side) then I made a mesh (without Ztilt not to force the mechanism) to launch the print on the left side was still too high d at least 0.1mm

Thanks for your help. klippy.log

[BlackStump]

You might want to delete of comment out bed_tilt if you are using bed_mesh because you can use one or the other but not both. as per here if you have a read. https://github.com/KevinOConnor/klipper/blob/master/config/example-extras.cfg#L102

[NedalLive]

where do you see Bed_tilt ?? I use Z_Tilt and Bed_Mesh, are they incompatible?

[BlackStump]

oops misread the log file.

[lenne0815]

Im having a similar issue without using tilt compensation aswell.

I probed with various grids: 6x6, 9x9 ( 2x2 actually crashes klipper )

And couldnt really pin the issue down, switching over to bicubic interpolation at .5 tension made it a bit better but its still not 100%

At one point i believed that the mesh is actually mirrored along y for some reason but im not to sure about that either, its really weird ( I need to mirror it alon y to get the correct representation with bed visualizer )

Are you using positive endstops @NedalLive ?

[NedalLive]

@lenne0815 only on Y (-30) X is at (0)

[lenne0815]

Hmm ok, i actually meant the other way around, mine are at x450 y470.

Is it possible for you to test if y0 makers a difference ? I cannot switch it over on my machine that easily.

[NedalLive]

unfortunately I can not easily switch my end stop in position max ...

[manoukianv]

Hello,

i have take a look on bed_mesh codes, and i don't understand somethink... A little picture to explain my issue :

If the probe offsets start from Probe in direction of Nozzle on the axis, so i think the bed_mesh compute the mesh position in the wrong direction (+/-) here : https://github.com/KevinOConnor/klipper/blob/ef4f84e3aecc469486e6560db27e94d9ab37f123/klippy/extras/bed_mesh.py#L464

@KevinOConnor , did i understand the algorithm in reverse?

[Krasnall]

I have a similar issue. I have a dual Z stepper configuration without Z endstops. BLtouch acts as a virtual endstop and homing works fine. I then sync both Z steppers manually and perform mesh calibration. The result is reasonable and Z moves up and down accordingly when I move the carriage around X and Y.

Now I manually lift one side of my X axis by a few mm so that the Z steppers are not in "sync" anymore. I perform Z_TILT_ADJUST (2x2) and the terminal output seems reasonable (a few mm difference between left and right Z stepper). However, the Z steppers are not synced at the end of the process as I would expect - one side is still higher the way I manually set it before Z_TILT_ADJUST. When I issue lateral movement commands, Z steppers on left and right side are not compensating for the tilt.

[KevinOConnor]

@manoukianv - all the coordinates in the config file should be relative to the nozzle. So, from your picture it appears the probe is 40mm in a positive direction from the nozzle and thus should be configured with y_offset=+40.

@Krasnall - If you're having an issue with z_tilt, you should open a new issue and attach the klipper log file from the event - see: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

@lenne0815 , @NedalLive - If I understand you correctly, the mesh is being applied but not to your satisfaction? Perhaps @Arksine can help, but I'm not sure I'd be able to assist with something like that in the short-term.

-Kevin

[Arksine]

@manoukianv Looking at your picture, it seems to me that the probe is offset in the positive Y direction relative to the nozzle, not the negative as you have set in your printer.cfg. So your y_offset should be 40, not -40 if that is indeed how your probe is oriented. The calculation of the mesh min and max values are correct, by adding the probe's offset the result should be the coordinate on the bed where your probe actually was during the probing procedure. Edit: I should have read Kevin's response first, he is correct.

@lenne0815 I don't think there is any way possible that the mesh could be mirrored. BED_MESH_OUTPUT however does send data in the reverse direction along the y-axis, looking at the output is analog to standing in front of your printer and looking down on the bed, with the origin at the front left corner of the bed.

@NedalLive I would recommend against loading a mesh after making changes using z_tilt or manual adjustments. Make those adjustments first, then probe with BED_MESH_CALIBRATE and attempt a print. Also double check your probe offsets to make sure that they are correct.

[NedalLive]

@KevinOConnor & @Arksine thank you for your response in effect the mesh works but does not seem to be corrected enough ... the problem is systematically between the side uche and the side rights tu bed ... no offset difference between the front and the back of the bed left front Middle Left and Rear left looks the same as the front Right middle right and right back are identical

I deliberately twisted my bed it is visible on the picture that I join.

to illustrate I only realize a bed_Mesh + saved

Here is the result : Left front (X0Y-30 side)

Middle front

Right front

can see that the mesh is in good condition because I have a delta of about 4mm however despite the correction the left side is higher (better result on the picture) than the right side is too crushed

[Arksine]

@NedalLive How close to the front of the bed is this? Looking at your configuration, it looks like the first 50mm of Y will be outside of the mesh. Values outside of the mesh are clamped to the last known value (ie the calculated offset at X25 Y25 will be clamped to the last known value in the mesh at X25 Y50).

So if these prints are indeed outside of the mesh, a significant amount of bed variance can't be accounted for and you would get poor results.

[NedalLive]

@Arksine my probe falls exactly on the printed square. the results that I observe are identical on the middle and back position (Y-30 at Y220...) of each row the squares having the same coordinate X are identical to each other regardless of the coordinate Y

[lenne0815]

@arksine thank you for replying !

I think i dont really understand you unfortunately.

I did not use bed_mesh_output, is that done automatically after creating a new bed mesh ? ( Im unsure where bed visualizer gets its mesh from, i only know that it refreshes after i create a new bed mesh and shows the current one with a inverted y axis )

Are you really forcibly inverting the mesh for visualizers ? It took me close to a day including breaking my probe holder ( i introduced an "error" so i could check whats going on in one corner, the probe got stuck on it jada jada ;) ) to realize y is inverted in the visualisation, i dont understand why ? No matter how you rotate a cubic printer f.e. even when you flip it upside down x0 y0 is x0 y0 and x300 y300 vice versa.

But anyhow, it would be great if there would be an indication somewhere that the mesh gets flipped in y when it writes the output to the format octo plugins can read.

So you say the actual mesh isnt flipped which is certainly the more likely case imo aswell ( i just couldnt pin it down really due to the uniform warp of my bed ) this means my error is very similar to nedals, the mesh works but its slightly undercompensating aswell without using tilt compensation though.

Somehow it looks like the splines created for the mesh arent fully intersecting the probe points but just come very close to it, depending on tension from nearby probe points.

Is there some kind of inhibition from the z max speed / acceleration going on maybe ? I always wondered how thats handled by the bed mesh. My z accelerates rather slowly, but x/y can travel quite fast, mayve theres a correlation ?

Beside all that, thank you very much for your time arksine, even in its current state the bed mesh is a huge help for my printer.

[Arksine]

@NedalLive So the right side is getting too much adjustment? Things that I think could cause this: 1) Bed or printer geometry has changed since probing the mesh 2) Probe variance

The only potential adjustment to the probed z points is while the mesh is fading out. An extremely large gcode offset could cause fade to kick in early, however in your case it would raise the right side, not lower it. Outside of fade, the adjustment depends entirely on the probed points and supplied probe offsets. There is nothing inherent in bed_mesh that would add adjustment to one side of the bed on top of the mesh.

@lenne0815 Most likely your visualizer already knows about the BED_MESH_OUTPUT command and executes it for you. As to why the mesh output is inverted along Y, as I said, it seems to be the standard for reporting topology and I didn't think it would be wise to deviate.

Increasing the bicubic tension increases the overshoot when generating splines in the mesh (ie. interpolating curvature from slope). If increasing it helps you then your bed has relatively rapid changes in geometry. The only possible way I know of for the splines to not intersect the probed points is if your x and y offsets in the [probe] config are incorrect. Those offsets are used to map the points to the correct location along each axis, then the splines are generated from them. Z speed/acceleration shouldn't affect bed_mesh. Since you have an extremely warped bed, you may wish to try probing more points.

I will investigate the code to see if I can find a potential bug causing these inconsistencies, however I doubt that is the case. The core bed_mesh code was tested extensively prior to merging with expected results. I will note that it can't compensate entirely for extremely warped beds.

If I don't find anything in the code, the good news is that in the future I plan to add functionality that will give you the option to manually add offsets to individual regions of the bed. This will help those with extremely warped beds that the mesh doesn't pick up.

[KevinOConnor]

I'm going to close this as I think the original questions were answered. Let me know if I need to reopen.

-Kevin