[BUG] Bilinear ABL produce tilted mesh

[NoPinky]

After 3 weeks fiddling around I can finally narrow down what could be wrong with my Ender 3 V2 and 3DTouch (cheapter BLTouch clone, but the issue is definitely not because of the clone).

Firmware: Ender3-V2-BLTouch-20201101.bin (directly from Marlin nightly build, but I have this issue with any Marlin firmware since October)

Steps to reproduce:

1. Freshly flashed firmware, load defaults.
2. Use Octoprint terminal or similar to call M420 S0 to be sure mesh is not active, there should not be any mesh anyway because of the freshly flashed firmware and load defaults. I do this because I noticed that once the mesh is active, it compensates every G0/G1 commands (Fade height set to false/0). I even stick a piece of tape to the Z lead screw and look at it while "driving around" on the bed to unsure there is no compensation going on.
3. Set Z-offset to the value I know is right from the many times before:-2.35via LCD display.
4. With the help of G0/G1 or in case of Octoprint the Control tab buttons to move to each corner and do manual leveling with the knobs and a piece of paper and fine G0/G1 commands so all four corners are well set. (yes, I do it by jumping vertically from corner to corner, multiple rounds)
5. G28, thenG29 V4 and I receive this mesh:

   Send: M420 V
   Recv: Bilinear Leveling Grid:
   Recv:       0      1      2      3      4
   Recv:  0 +0.045 +0.045 +0.080 +0.090 +0.108
   Recv:  1 +0.030 +0.028 +0.023 +0.030 +0.048
   Recv:  2 +0.005 -0.005 -0.015 -0.007 -0.005
   Recv:  3 +0.013 +0.020 +0.038 +0.033 +0.050
   Recv:  4 +0.043 +0.060 +0.085 +0.102 +0.138

   Visualization:

Mesh and visualization looks correct EXCEPT that it is tilted right side up/too high. This can't be because I ensured all corners are on the same level. The output vom G29 V4 is consistent to the resulting mesh

6. M420 S0 again to turn off mesh (G29 activates mesh).

7. Move nozzle just 0.1mm above the bed and go to each corner again to ensure they are still level: they are! Center and center right are the low spots, I can see those with bare eyes in the gap of the nozzle to the bed. All 4 corners have the same gap. There is no way ABL should produce the tilted mesh where right side is always higher.

8. M420 S1 to activate mesh and do the same movement as in step 7. I start with center, then right side and then left side. I can see with bare eyes again that there is compensation happening as the Z lead screw is moving and the nozzle is following the beds relief. However the on the 2 left corners the nozzle scrapes the bed.

9. optional: do a test print with any bed leveling verification pattern and I will see that the left side is too high and the right side is too low.

Judging from my observations, there must be something wrong with how the mesh is created. It's like there is an overlaying mesh that adds the tilt to the mesh from the ABL, but this happens in "real time" during the proping, as the reported Z-height from G29 V4 is consistent als already corrupted with every proped point.

Workaround: I intentionally tilt my bed out of level by raising the right side to match with the wrong mesh, then my first layer are consistent.

I am not sure if this is a duplicate of this issue: #19839 or somewhat related to this: #19937

[boelle]

Configurations, please Please ZIP up your Configuration.h and Configuration_adv.h files (as requested in the Issue template) and drop them into your next reply. We'll check them over and see if anything is amiss.

Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

[NoPinky]

@CRCinAU I used your precompiled firmware, can you please help providing the configuration files to Ender3-V2-BLTouch-20201101.bin? I haven't found any possibility to download those on your site. Thanks.

[thisiskeithb]

@CRCinAU I used your precompiled firmware, can you please help providing the configuration files to Ender3-V2-BLTouch-20201101.bin? I haven't found any possibility to download those on your site. Thanks.

We can't support forks here, so please test with latest bugfix-2.0.x from this repo only.

[CRCinAU]

We can't support forks here, so please test with latest bugfix-2.0.x from this repo only.

This is the nightly checkout of bugfix-2.0.x built just after the date tag is updated to 2020-11-01 - not a fork.

I have heard rumours about this type of bug - but not had the time to check it out for myself... The current theory is that it occurs once you enable the fade height... so, in the interest of debugging, try this:

1) Disable mesh fade height: M420 Z0 2) Re-level the bed 3) Home: G28 4) Probe: G29 5) Enable fade height: M420 Z5 6) Home: G28 7) Probe: G29

Compare the two output grids and see if / what the difference is...

[salacpavel]

Is https://github.com/MarlinFirmware/Marlin/issues/15450 related as well?

[Bloodpack]

Following

[hamster65]

Fade Height 0: Recv: Bilinear Leveling Grid: Recv: 0 1 2 Recv: 0 -0.266 +0.175 +0.579 Recv: 1 -0.412 -0.009 +0.276 Recv: 2 -0.475 -0.223 -0.042

Fade Height 5: Recv: Bilinear Leveling Grid: Recv: 0 1 2 Recv: 0 -0.261 +0.182 +0.563 Recv: 1 -0.393 -0.020 +0.259 Recv: 2 -0.462 -0.222 -0.037

Fade Height 0 again: Recv: Bilinear Leveling Grid: Recv: 0 1 2 Recv: 0 -0.256 +0.161 +0.575 Recv: 1 -0.412 -0.023 +0.262 Recv: 2 -0.470 -0.221 -0.042

Fade Height 10: Recv: Bilinear Leveling Grid: Recv: 0 1 2 Recv: 0 -0.257 +0.171 +0.562 Recv: 1 -0.419 -0.014 +0.259 Recv: 2 -0.485 -0.224 -0.053

Fade Height 0 again: Recv: Bilinear Leveling Grid: Recv: 0 1 2 Recv: 0 -0.259 +0.178 +0.568 Recv: 1 -0.391 -0.006 +0.259 Recv: 2 -0.466 -0.220 -0.053

M48: Recv: Mean: -0.014458 Min: -0.019 Max: -0.009 Range: 0.010 Recv: Standard Deviation: 0.003307

[CRCinAU]

Ok, so the output of the grid looks to be within a margin of error to me, which is good...

Does it make any difference to the output of the print when going between M420 Z0 and other M420 Zx values?

[hamster65]

I don't think it makes a difference and I think I don't have the same issue NoPinky is seeing. I levelled my bed using the paper method and BedVisualizer shows it is flat and green.

With bed levelling turned off, first layers look ok. However, with bed leveling turned on, there are gaps in the first layer on the right side of the bed and when I babystep down to compensate, lines on the left come out very uneven because the nozzle is to close to the bed. Bed levelling is compensating and it is moving to the right direction. Not sure about the timing and amount, though. Something is off. Of course I double checked my probe offsets and the fact that it prints ok with bed levelling turned off should rule out a mechanical problem.

Right now I have no further ideas. I'll keep bed levelling disabled for now or try with UBL or linear bed leveling.

[hamster65]

With linear bed levelling, the first layer looks ok, too. The Z stepper is moving, but I can barely see it. There was a lot more compensation going on with bilinear levelling.

[NoPinky]

Configurations, please Please ZIP up your Configuration.h and Configuration_adv.h files (as requested in the Issue template) and drop them into your next reply. We'll check them over and see if anything is amiss.

Please test the bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

I finally got the time to compile the firmware myself (only used precompiled firmwares before). As requested, I compiled with the latest bugfix-2.0.x branch and with the config files attached: config.zip

The same described problem still persists. I will probably try UBL or manual mesh leveling next

[tomich]

This sound pretty similar to #20105 . I have same issue. Can you try using firmware versions older than 2.0.7.2 and see if the problem persists?

[NoPinky]

This sound pretty similar to #20105 . I have same issue. Can you try using firmware versions older than 2.0.7.2 and see if the problem persists?

I did try it with 2.0.7.2 and I the same problem. I now have the feeling that my issue may be connected to sagging of my gantry as I have single Z-axis configuration. I will update to dual-Z in the coming weeks and have another go with the BLTouch (clone). For now I am using manual mesh bed leveling with 25 points. It takes about 15 mins but works well enough for me.

[tomich]

older than 2.0.7.2

Please try 2.0.7.1 or OLDER. I fixed tilted mesh issues with that.

[sjasonsmith]

@NoPinky I have been trying to reproduce leveling issues all day using today's bugfix-2.0.x, and it has been working fine for me. This includes trying to match an Ender 3 V2 example to the the options CRC configures with his. In all cases the probed mesh seems to accurately portray my bed, and I have been able to print just fine with the produced meshes. I even managed to attach a dial probe to my carriage to let me sanity-check my probed meshes against a mechanical measurement device, and they seem to correlate appropriately.

I would like to point out that when you are manually leveling using the nozzle, you are measuring in a fundamentally different way than when probing. With the probe, you are relying on the assumption that the probe will see the same offset that the nozzle will in the same X/Y position. Since probes have X/Y offsets, any twisting or other misalignment in the mechanism will result in less accurate probes.

I doubt it is necessary to upgrade to dual Z to resolve your issue. You should thoroughly inspect your assembly. Some specific things you can look for include:

• Loose Z coupler
• Z binding (z screw cannot turn freely due to shaft misalignment)
• Loose or overly tight wheels on carriages. This includes all three axis.
• Bed is too loose, and needs springs tightened
• Debris on V-track or wheels.
• Wires or bowden tube tug on the carriage when at the right side of the bed.

Since I am unable to reproduce this and you suspect you may have a mechanical issue, I am going to go ahead and close this issue. This is in no way an attempt to avoid resolving leveling issues. It is quite the opposite. We are working to reduce the backlog of outstanding issues, to ensure that new issues can receive prompt attention. If you are able to gather more information which makes this reproducible on other machines I would be happy to look at it again.

[NoPinky]

@sjasonsmith Thank you for your thorough investigation about the matter and suggestions on the mechanical side for me. I really appreciate you taking time for that in the mass of other issues. Last night I retightened the gantry on my Ender 3 V2 and other parts, but haven't testet it yet. The gantry did sag a bit on the right side, that must have been the problem. I will surely reflash bilinear bed leveling in the coming weeks and reverify it.

[hamster65]

@sjasonsmith Thanks for investigating! Let me add: I see a tilted bed, too, with bilinear levelling, but not with linear levelling (which is what I am using now and it is working fine). This should rule out any hardware issue(?).

[sjasonsmith]

@hamster65 when you are using LINEAR leveling you don't actually see the probed points. The points are used to perform a least-squares fit to a flat plane, which is then stored to EEPROM as three points. Those points are used to re-generate a perfectly flat mesh when it is needed. It is basically the same as 3POINT leveling, except it tries to fit a plane to many probed points, rather than only probing three points.

3POINT and LINEAR are really intended for beds which are very flat to begin with, they just may be tilted. They won't compensate for actual deviations in the bed surface.

The mesh you see reported when using LINEAR is a perfectly flat (but tilted) mesh, and doesn't actually represent your bed geometry.

[hamster65]

thanks for clarifying!

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.