[BUG] (bugfix-2.0.x) Auto Bed Leveling does not compensate for angled bed.

[OC-Rookier]

Bug Description

Marlin bugfix-2.0.x does not compensate for angled beds during print.

My Configurations

Config files.zip

Steps to Reproduce

1. Install an SKR Mini E3 V2 into an Ender 3.
2. Download Marlin bugfix-2.0.x and the configuration files for the SKR Mini E3 V2 from GitHub.
3. Open VS Code and install Platform.IO.
4. Copy the Mini E3 V2 files from the configuration folder into the Marlin folder of the firmware.
5. Use this guide to configure the firmware correctly. Also follow instructions for setting up the BL Touch.
6. Build the firmware, copy the firmware.bin file to a Micro SD card, put the card into the printer, and power on the printer.
7. After the firmware is done flashing, manually level the bed and set up the Z offset.
8. Start a print, and watch as one corner is thinner than the rest of the print.

Expected behavior: [What you expect to happen]

I expected that the BL Touch would raise/lower slightly depending on how level each corner of the bed was, thus resulting in an overall uniform first layer.

Actual behavior: [What actually happens]

The printer seems to ignore the mesh that was generated during the G29 command in my starting gcode, and the print is not uniform.

Additional Information

• Using Octoprint, I can see that the printer is generating a mesh when G29 is ran. This also is shown in the Bed visualizerplugin.

• ABL was working when I was using the Creality 1.1.5 board and Marlin 1.1.x.

• I know there are other issues that complain about ABL not compensating, but they seem to close due to inactivity with no obvious solution.

• A friend of mine has the SKR 1.4 Turbo and Marlin bugfix-2.0.x and is also having issues with no compensation after mesh generation.

• I am new to Github (as in just made an account to make this post), so please be patient with me.

[CircuitSetup]

Then you likely have a hardware issue. I've found ABL + BLTouch to be completely unforgiving which is also why it works so well when there are no mechanical issues. So that I can offer some kind of help, can I also ask whether you are running dual z?

I highly doubt it's a hardware issue at this point. I just replaced the stock carriages on my printer (Ender 3), with linear rails, and the problem still persists. I also tried some of the above to no avail.

No, I don't have dual Z.

From what I can tell from my latest tests is that any points that are high are over compensated and the nozzle is too high off the bed by about 0.1mm. For example, this is my current mesh:

Bilinear Leveling Grid: 0 1 2 0 -0.035 -0.050 +0.239 1 -0.033 -0.119 +0.212 2 +0.117 +0.024 +0.223

On the right side the nozzle appears to be at +0.3.

[OC-Rookier]

Again, I want to reiterate that with aside from a switch from the Creality 1.1.5 Silent board to the SKR Mini E3 V2, there has been no hardware changes to the printer. I did not have this issue with Marlin until a few months ago when I changed boards, and thus had to update from 1.1.x to 2.0.6.

[minosg]

Again, I want to reiterate that with aside from a switch from the Creality 1.1.5 Silent board to the SKR Mini E3 V2, there has been no hardware changes to the printer. I did not have this issue with Marlin until a few months ago when I changed boards, and thus had to update from 1.1.x to 2.0.6.

I can also confirm that something is off. I did test for this especially with skr mini e3 1.2 because it works with Marlin 1.5.0.4. Perfectly calibrated machine with same settings prints the gheko properly in 1.5 but not in 6.0. X and bug fix. I have tried a git bisect to figure out which commit could have introduced it, but to no avail.

Yes some users may attribute other issues to this bug, but that does not mean something is not there.

[Blacksource001]

Just to add fule to the fire i also have this problem. Latests bugfix. SKR mini E3 v2.0 BLTouche 3.1 Ender 3

Have tried everything up til now. Hope this gets fixed

[hamster65]

I switched from bilinear to linear bed leveling because with bilinear, the nozzle is too close to the bed in some areas and too far away in others. My bed is well adjusted and there is little Z movement with linear leveling and the first layer looks ok.

With bilinear, there is much more Z movement. The first line that gets printed varies clearly visible in width.There are gaps between the lines of the first layer while other areas don't have gaps but are very uneven.

OT: I described this issue in some bug reports but they were all closed with "we prefer not to handle user support here" or "your mechanics is off". Please don't close too fast, it discourages people from filing bug reports.

[OC-Rookier]

I'll try the latest bugfix this week and rerun my tests from before and report back with my findings. I have not made any hardware changes or tweaks to the printer since the last run outside of leveling the bed manually, so that eliminates those variables.

[Blacksource001]

I played around with this leveling problem for over 3 weeks. Trying all kinds of solutions and firmwares. What ended up fixing my problem was klipper. I am not against marlin but if anyone else is frustrated with this problem and just wants to print again i recommend trying klipper until this problem is fixed.

[sjasonsmith]

@OC-Rookier, you said this a while ago:

Though I do want to bring up a point I discovered in the logs, which is that ABL is working, but the mesh it is using is not the one generated before each print. Instead, it uses the a mesh that was stored in the EEPROM, and discards the new mesh.

Could you provide more information about how you reached this conclusions? if it is in your log files, could you point me to the location of that information?

[OC-Rookier]

I came to this conclusion after running Tests 11, 12, and 13 in my test runs. The download for all the logs and the pictures of the prints are in this comment. Test 11 was the same configuration from the previous test, and the print was satisfactory. However, when I purposely changed the bed level for Test 12, the layers stopped sticking together, as though I didn’t have ABL. Test 13 kept the same bed level from Test 12, but all I did was run M502 and M500. Wouldn’t you know it, I got much better results.

I have a bunch of logs and pictures in that folder, but the most important in my opinion are runs 11, 12, and 13. Log 7 is also pretty big because that’s where I think I narrowed down the issue for the first time.

[minosg]

Couldn't we also verify it using a controlled experiment?

• start an auto levelling routine and use a ruler on one of the sides to skew 3 points of the 9 point grid off. Then save the mesh.
• Remove the ruler and try to print. If the first layer is placed on air in the area where the ruler was then you know the saved grid was used instead of the one read in the current run of the auto bed levelling routine.

[OC-Rookier]

Off topic, but I think an update broke my VS Code install, and now says execvp(3) failed.: No such file or directory immediately when attempting to build the new bugfix firmware for testing. Tried building the printer's current version and it also failed with the same message. I'll have to hold off on updating my printer to new firmware until I get this sorted out.

I can go ahead and try minosg's testing idea with my older firmware.

[OC-Rookier]

Update: The M111 S247 command no longer gives me a verbose output for some reason. Instead of getting something like:

cv:   current_position= X142.50 Y127.50 Z8.62 : Probe::set_deployed

Recv: deploy: 1

Recv: >>> Probe::run_z_probe \x90\x16 X142.50 Y127.50 Z8.62

Recv: >>> Probe::probe_down_to_z \x90\x16 X142.50 Y127.50 Z8.62

Recv: BLTouch DEPLOY requested

Recv: BLTouch Command :10

Recv: bltouch.deploy_proc() end

Recv: >>> do_blocking_move_to \x90\x16 X142.50 Y127.50 Z8.62

Recv: >  X142.50 Y127.50 Z1.67

Recv: echo:busy: processing

Recv:  T:210.59 /210.00 B:65.01 /65.00 @:21 B@:34

Recv: echo:busy: processing

Recv:  T:210.39 /210.00 B:65.02 /65.00 @:24 B@:33

Recv: <<< do_blocking_move_to \x90\x16 X142.50 Y127.50 Z1.67

Recv: BLTouch STOW requested

Recv: BLTouch Command :90

Recv: bltouch.stow_proc() end

I just get Recv: echo:busy: processing. I'll just have to provide logs without as detailed of an output.

[OC-Rookier]

Well this baffles me. I ran more tests, and now it looks like ABL works perfectly fine now. I'm really not sure what to say, other than maybe the firmware is just buggy in the first month after flashing or something, but this makes absolutely no sense whatsoever. It's also a possibility that I just happened to get a good result after M502 / M500 in the previous round of testing, but that also seems unlikely. I ask that others also run these or similar tests and post the results here.

I guess GitHub allows for larger file sizes now? This shows as 25MB.

[jidderz]

I struggled with the same problem for hours. I configured and flashed from the bugifix to 2.0.5 to 2.0.7. It seems G29 works fine but the mesh coordinates does not seem to get saved and recalled upon printing even if the line RESTORE_LEVELING_AFTER_G28 is enabled in firmware. I ended up getting it to work using these GCODE:

G28 M420 S1

-OR-

G28 G29 M500 M501 M420 S1

I made a quick video of how the test went.

https://youtu.be/R8csOM9jCsM

[pabds]

Yes, I posted in July that "G28 home followed by M501 (Load all settings from EPROM) and then M420 S1" worked for me. I put that part in the Cura profle. You should not need to do bed levelling before each print. I do it manually from the control panel and save to EPROM immediately after. Works fine and I only need to level the bed every other month or so.

[sjasonsmith]

I just spent several hours trying to encounter any issues with this, and everything seems to work as expected. Given that several people posting to this issue (including the OP) seem to have fixed the issue with either mechanical repairs or by updating firmware, I think it makes sense to close this issue.

If you are still encountering incorrect behavior, please report a new issue with the details of your issue. It is important to focus on one failure in any given bug report, so that attention can focus on one bug and the it can actually be closed.

I did the following testing with an SKR E3 Mini V2.0 and a BLTouch on an Ender 3.

1. Modified the OP's configuration to work with bugfix-2.0.x and my Ender 3. It is mechanically mostly stock, but has a BMG extruder. Configs.zip
2. Intentionally skewed my bed to have > 10mm variation between corners. This was the grid reported by G29. It looks like just less than 10mm, but my probe cannot reach the right 48mm of the bed.

   Bilinear Leveling Grid:
     0      1      2
   0 -5.070 -3.170 -1.052
   1 -2.400 -0.490 +1.730
   2 +0.448 +2.428 +4.695

3. Print a test pattern across the entire bed. This looks a little ugly, but it still demonstrates that leveling is working. In this test start gcode has M420 S in it, but not G29. Reasons for this being less than perfect:
   • Filament has been exposed for ~6 months. This especially impact the bottom-left square, which sounded very wet.
   • Printer has a large 1mm nozzle, which makes oozing and re-starting after traveling imperfect.
   • This is correcting > 10mm variation!
   • Right-most column of squares is entirely in extrapolated region. Probe cannot reach these.
4. Mechanically level the bed. This was only done by eye, to get to a reasonably level state. The purpose was to ensure that it would be very obvious if the old mesh were used.
5. Start a new print, this time with G29 and not M420 S.
   • New mesh (~0.6mm variation)

     Bilinear Leveling Grid:
       0      1      2
     0 -0.120 -0.115 +0.130
     1 -0.165 -0.075 +0.265
     2 +0.050 +0.195 +0.493

   • Print is very even. Z-offset wasn't quite correct, but the same nozzle pattern is seen in all printed squares.

[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.