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

[GMagician]

Bed leveling is not activated by default..not sure but maybe M420 S1 is what you need

[OC-Rookier]

After editing my starting Gcode to look like this:

G28
G29
M420 S1

It still does not work. The Z axis is now too high and does not stick to the bed.

[thinkyhead]

Whenever there are homing or leveling issues, we now ask everyone to follow a standard procedure to gather more information so that we're not just taking stabs in the dark. Here is the boilerplate:

• Download Marlin bugfix-2.0.x to test with the latest code.
• Enable DEBUG_LEVELING_FEATURE and M114_DETAIL and re-flash the firmware.
• Connect to your printer from host software such as Cura, Printrun or Repetier Host.
• Send M502 and M500 to ensure your Configurations are applied.
• Issue the command M111 S247 to enable maximum logging.
• Perform a G28 to do your standard homing procedure.
• Do a G29 to probe the bed. This will also enable bed leveling.
• Do some of the moves that revealed problems before. Take notes.
• Copy the log output into a .TXT file and attach it to your next reply.

Repeat this procedure, if needed, to demonstrate inconsistencies. From these logs we should hopefully get a better idea of what's going on with your machine.

[pabds]

After editing my starting Gcode to look like this:

G28
G29
M420 S1

It still does not work. The Z axis is now too high and does not stick to the bed.

The Z axis being too high is a separate issue. Bed levelling defines the topographical profile of your print surface. It does not define how far the nozzle is off the bed. The easiest way to address this is to start a print and then select 'Babysteps'. As it starts printing, spin the knob anticlockwise (lowering the nozzle) until the ABS starts to adhere to the print bed. Note the negative number that you have dialled up in 'Babysteps'. Abort the print and enter that number in Configuration, 'Z-offset'. Don't forget to hit 'Save'. Print again and it should be correct. If not tweak again.

[OC-Rookier]

I know about setting the Z offset, as I used that feature back in 1.1.x. I think I may have just adjusted the bed and forgot to tune my offset afterwards.

Anyway, I am currently working on getting logs that show that ABL isn't working as well, or at least as easily as it did back in 1.1.x. Results are kind of a mixed bag right now, but I'll keep testing and hopefully report back with my findings in another day or two.

[pabds]

This probably isn't much help, but I have it working well on my Ender 3 pro (BLTOUCH 3.1, SKR mini E3 V2.0, TFT35 E3V3, current version of Marlin Bugfix 2.0.x). There seem to be numerous subtle differences in how people attempt to set this combination up. I decided to use the dedicated probe port. Method described here, second last post. https://www.reddit.com/r/ender5/comments/g3peqn/finally_got_my_ender_5_pro_to_work_with_the_skr/
The only issue I had was that I initially didn't realise that Auto Home turned off ABL. As above, I edited my Cura profile so that it now does a G28 home followed by M501 (Load all settings from EPROM) and then M420 S1 before it prints. I also forgot, on occasion, to save the mesh to EPROM after running ABL. I heat the nozzle to 170 (below ABS melt point) and the bed to 60 prior to running ABL to prevent thermal effects on the distance between the nozzle and the bed. With all that and the z-offset tuned, it definitely works well for me.

[GMagician]

@pabds this is from manual on web and may clarify something to you

G28 disables bed leveling. Follow with M420 S1 to turn leveling on, or use RESTORE_LEVELING_AFTER_G28 to automatically keep leveling on after G28.
To save time and machine wear, save your mesh to EEPROM with M500 and in your slicer’s “Starting G-Code” replace G29 with M420 S1 to enable your last-saved mesh.

as you can see M501 seems not needed

[OC-Rookier]

Alright. I have the logs for quite a few tests, and inside those logs are also notes I took while observing the printer and/or the finished print. I also have pictures of each print. It should be noted that all the prints used the exact same gcode, which is also in the .zip file. Unfortunately, this file is too big to attach directly to Github (27.6MB > 10MB), so here is a Google Drive link.

https://drive.google.com/file/d/1VopCmff3qSkRDjp-pQuWLrxkMjbZFGNK/view?usp=sharing

[sjasonsmith]

When you are printing can you see the Z screw turning as the print moves across the bed? This verifies that some correction is at least being attempted.

How old is the bugfix code that you are using? I made a change about two weeks ago which improved an issue which could cause inaccurate BLTouch probing. That might not be related to your problems, but it would be worth testing with the just-released 2.0.6 if you weren't already using very recent bugfix-2.0.x.

[OC-Rookier]

I was able to see the Z screw turning when I started a print. My version of bugfix-2.0.x is only about three or four days old.

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.

I do make notes inside each of the log files, as indicated by two forward slashes (//). These notes describe the print or any variables that I have changed.

[minosg]

I can confirm something is off.

I just updated the 2.0.6 release and my gecko model which I have printed hundreds of times doesn't stick because ABL does not compensate or incorrectly compensates.

This is a small bed with a thick borosilicate glass, and yet I'm seeing over 0.9mm difference in a 2cm distance on the model.

I will try go back in earlier branches to when this was introduced

[minosg]

Just a quick update. I used previous tags and tried the 5.0.3 and 5.0.4 and the bug fix branch at commit 378b5685b which is updating the tcmstepper library

503, and 504 are applying corrections appropriately but the bug fix did not.

[sjasonsmith]

@minosg are you saying that problems appeared with that specific commit?

[minosg]

No I am still trying to pinpoint the commit but there are literally hundreds. I just happen to have several branches in different points in bug fix, so I can easily triage changes and this is what I tested so far.

Somewhere between April and July a commit made this issue appear. I do not know why it was not caught earlier so it could be a configuration or bed shape which triggers it.

Since we are dealing with positive and negative float point math here, there are a million ways to go wrong.

[LongDogGuy]

@minosg can you recommend a specific build we can fall back to use until this gets sorted out? I (and I'm sure others), are completely blocked until this gets resolved. Not everyone needs the latest features, just something that is reliable.

[minosg]

@LongDogGuy as i mentioned above and as I have confirmed with testing over the weekend the older releases are fine.

2.0.5.3 and 2.0.5.4 properly calibrate for auto bed leveling. Github tracking and 2.0.6 do not.

[minosg]

@OC-Rookier out of curiosity what slicer do you use?

[OC-Rookier]

I use Cura 4.6.1. It's an .appimage on Linux, if that matters. Worked perfectly fine for the 1.1.5 board and Marlin 1.1.x.

[minosg]

Thanks, then it's definately not a slicer issue. During my testing I bumped onto a prusaslicer issue which messes with extrusion widths.

Have you tried with 2.5.0.4 release?

[OC-Rookier]

I assume you mean 2.0.5.4?

[minosg]

Yes sorry.

[OC-Rookier]

I don't know if I can. My board (SKR Mini E3 V2) does not appear in boards.h, so there might not be any support for it.

[minosg]

Oh right I I'm sorry. I was testing in an 1.2 which worked. Unfortunately you may be stuck until we figure this out

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 days.

[schleir]

Any update here. I am having the same issue. I can help with any logs that are needed.

[salacpavel]

The problem here is that this issue, despite existing and confirmed, is closed because dumb-ass automated closure process - nobody is/will be working on it.

[thisiskeithb]

Stale bot has instructions to keep it open:

Remove stale label / comment or this will be closed in 5 days.

[OC-Rookier]

My bad. Forgot about this issue and just had to be very careful not to bump the bed leveling knobs. I have since updated to 2.0.6.1, and have not tested this issue in this release.

[schleir]

I can confirm that this issue is present in 2.0.6.1

[thisiskeithb]

For everyone reporting that they have this issue, please follow the steps exactly as described in this comment: https://github.com/MarlinFirmware/Marlin/issues/18769#issuecomment-663785318

[schleir]

@thisiskeithb

I followed the steps mentioned and printed a simple level test, below is the gcode that I used. I find that the mesh is generated fine, but the print is not uniform and something is off with ABL. My printer uses skr mini e3 v2.0

• first_layer.gcode.txt

Here is the terminal logs from my printer - serial.log

Here is the configs used for the firmware:

• Configuration_adv.h.txt
• Configuration.h.txt

It uses latest 2.0-bugfix commit that I could find today "82e602c847e248bebc3357405f068fff27fe4537"

Please let me know if you need more logs to fix the issue.

[DistortedDesigns]

I can confirm that ABL is not working. I just installed the latest version of marlin bug fix on my 1.4 turbo and I have a TFT35 V3. I enabled ABL with M420 S1, ran a 5x5 bi-linear, M500 to save. My cura has the code added to recall a saved mesh. I ran the 5 square adhesion test print and there were definite issues. My bed is no more than 0.1 off but no adjustments happening. I do have restore after G28 on in firmware as well.

[muvox]

I have this issue on my SWX1 (MKS Gen L v1) with ABL bilinear aswell. I tried bugfix 3~ weeks ago and one 5~ days ago. My probes standard deviation was 0.04. I checked all my axis, belts and wheels multiple times. I tried 3 by 3 and 5 by 5 grid. I re-measured my probes x and y offset and set them accordingly. I've tried altering manual x and y home position. I've tried altering probing speeds. I've tried disabling BLTOUCH_HS_MODE 5V mode. I've tried with and without adaptive step smoothing. Overall I've tried around 15 different configuration combinations yet the issue is always the same. Topleft corner seems a tad too close to nozzle. Bottom left corner is pretty much perfect and all the rest of the points are too far away from the nozzle to stick properly.
Unfortunately I've turned to MBL cannot post logs atm. Posting any info i could just in case it helps at all. Will see if i get the time to flash latest bugfix with all the debugging stuff enabled in the coming weeks. Start gcode is G28, followed by G29.

[schleir]

I do see some z-compensation as I can see small turns in z coupler during first layer.

It's just that the compensation is not correct or precise enough to produce consistent first layer.

Can this https://github.com/MarlinFirmware/Marlin/issues/18369

be causing the issue?
(MIN_STEP_PER_SEGMENT set too high to 6)

[LarrxX]

Just to confirm that I'm also having this problem with 2.0.6 and 2.0.7 releases. Bed leveling is not compensating properly and I'm getting non uniform first layer on Ender 3 Pro.

Leveling with :

M140 S60 ;set bed temperature to 60
M105 ;report temperatures
M190 S60 ;wait for bed to reach temperature
G28 ;home all axes
G29 ;bed leveling
M140 S0 ;set bed temperature to 0
M500 ;store leveling in EEPROM

And then printing with:

G28 ; Home all axes
M420 S1 ; Load bed leveling topography

Produces total rubbish. And if I print with:

G28 ; Home all axes
G29 ; Bed leveling

I get better results, but still not tcorrect.

Happy to provide logs if needed.

[schleir]

LarrxX,

Interesting, do you have success with
G28
G29
as start g code?

I tried using both start g code and still have inconsistent first layer.

Option 1

Level separately with G29 and save with M500

G28
M420 S1

Option 2

G28
G29

The troubleshooting steps mentioned above recommends to use Option 2 and I have attached logs using Option 2, i.e. g28 G29 before each print.

[LarrxX]

I have inconsistent first layer in both cases, but they are not the same. It's really weird, because there is some Z axis compensation going on, just not as it should be.

I tried flashing 2.0.5.4, same problem persists.

[schleir]

Got it. Sounds like the same issue I am facing.

Can you also please post logs after following steps listed here:

https://github.com/MarlinFirmware/Marlin/issues/18769#issuecomment-663785318

[LarrxX]

Edit: My results below are wrong. I had a faulty Z lead screw coupler which led to a drift in Z when leveling the bed.

---

Ok here are my logs with the latest 2.0.X-bugfix.

Here are my config files:
Configuration.h.txt
Configuration_adv.h.txt

Following the procedure in https://github.com/MarlinFirmware/Marlin/issues/18769#issuecomment-663785318 I have the following log: leveling.log

Then tried printing this one layer file: Calibrator.gcode.txt

Case 1: Here is the log if I do G28then G29 during the print: G28_G29.log

Case 2: Here is the log if I do my leveling first, store it with M500then print using M420: G28_M420.log

And here is what my bed topology looks like:

In both cases there is some Z-axis movement.

I don't get the same results on the print:
Case 1: The print is OK in the back and squished in the front, same as the topology of the bed (as if there was no compensation at all).
Case 2: The print is OK in the front, and not sticking at all in the back (as if the highest level compensation was applied everywhere).

EDIT: Reuploaded both print logs with verbose mode correctly set.

[minosg]

For anyone wanting to test for this bug, I have found out that the Gecko model I have been using to debug other patches is an excellent test print.

https://www.thingiverse.com/thing:3663547

While printing a test cube or any simple shape based print may work, forcing the first layer to do complicated moves is guaranteed to trigger it.

I thought the 6.0.1 release had fixed the leveling issue, but I was printing benchies and test cubes. When tried this model, the tail was always printed on the air.

Has anyone else noticed random layer shifting when printing in Marlin 6.0.0+? While everything works as expected in 5.X.XX versions, the same Gecko model gcodes is sometimes y-shifted in newer versions, and I was wondering if that bug causes compensation applied at the wrong layer, or weather the matrix gets corrupted ( Even though that would result in Moire patterns )

[schleir]

@thinkyhead @thisiskeithb - There are 4-5 sets of logs from the troubleshooting steps (https://github.com/MarlinFirmware/Marlin/issues/18769#issuecomment-663785318) provided in this issue by different people.

Are there any other required information?

[boelle]

Are there any other required information?

no but a barrel full of patience will not hurt, after all marlin is free and all work on it at their free time

[schleir]

Yes, definitely agree :)

[LarrxX]

I opened a new issue #19937. It could explain the behavior seen in this issue. Could the other people having this problem test and confirm?

[LarrxX]

I had a loose Z lead screw coupler which caused a drift in the Z axis when leveling the bed. By resolving it in issue #19937 it solved my problem for this issue.

Hope this helps.

[thestephenmarshall]

After struggling with this for many months, I too noticed a drifting z lead screw which was characterized my the z occasionally becoming out of sync. That was not all however. You see I also had a twist in my X axis that was only occurring at certain positions the the X/Y matrix. The z lead screw was only barely able to move independently with a little force and the X twist.. well you couldn't easily measure that given we are talking about fractions of a millimeter.. I had to go with my suspicions and the feedback I found here I this repository. The machine was a POS MP Maker-select v2.1 frame which are cheap garbage. I printed an entire solution for the X axis which removed all wiggle room except for the normal amount needed for the lead screws the tightened those down like my life depended on it. BLTouch working like day 1. Did I mention the frame is crap? Ok good luck.

[CircuitSetup]

I'm also experiencing this issue since updating to v2.0.6 on an SKR v1.3 I've updated to the latest bugfix release and am still seeing the same results. It seems to be worse when the bed is extra slanted. I can confirm that some correction is occurring since the z motor is moving when printing.

[boelle]

since updating to v2.0.6

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.

[CircuitSetup]

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.

Right, I'm currently using the latest bugfix files (as of 2 days ago), and am still seeing the problem. If I manually level the bed, then run ABL, the problem isn't as severe.

[thestephenmarshall]

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.

Right, I'm currently using the latest bugfix files (as of 2 days ago), and am still seeing the problem. If I manually level the bed, then run ABL, the problem isn't as severe.

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? If so, one other thing I noticed when ABL wasn't working right for me was that no way in hell could I get a true reading from G34 Z Stepper Auto-align. Sure, the output claimed to be within 0.01mm which ultimately was the target... but using the simple tried and true method of placing an object under each side of the X axis yielded un-level results every time. After fixing the mechanical issues on my machine ABL G29 and G34 are working perfectly with the latest bugfix via bilinear.

One last edit: the nail in the coffin here might be finding out that after say 24 hours of printing your manually leveled bed mesh is somehow now incorrect (left side too low or high, etc.). This made it clear to me that something was shifting or inconsistent with the machine. The difference was too small to perceive with the naked eye.

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