Marlin: [BUG] ABL/UBL not working - SKR v1.3, TH3D EZABL Pro

[W3DP]

Printer Configuration

Ender 3 Pro
SKR v1.3
TMC2208s
E3D V6 with direct drive
Fixed machined cast aluminium plate with Keenovo AC heater with SSR
Bed, X gantry, hot end carriage and extruder motor all grounded to frame
Bed is level with gantry: max height difference between corners is 0.18mm

Bug Description

Expected behavior: Mesh bed leveling changes nozzle height to compensate for bed imperfections and/or slight slant

Actual behavior: Incorrect mesh bed leveling compensation (or no compensation?)

I installed 2.0.5.3. Looks like printer carries out probing normally but, when printing, nozzle is lower on one side of the bed than the other, clearly not compensating correctly. I tried latest bugfix and 2.0.6. Same issue. I asked TH3D which Marlin release they used for their Unified Firmware (2.0.0), created a minimal configuration and carried out test print. Outcome was a perfect first layer. Then tested 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5 with the same configuration. All these releases have the same issue so it seems the bug was introduced in 2.0.1.

My Configurations

Configuration.h and Configuration_adv.h: minimal configuration for 2.0.6
Configuration-2.0.0.h and Configuration_adv-2.0.0.h: minimal configuration working with 2.0.0
G28-G29.txt: verbose of G28 and G29 commands on 2.0.6
Bed test print.txt: verbose of 1st layer test print on 2.0.6
G29 comp.txt: Bilinear grids for releases 2.0.0 to 2.0.5 (Not sure if it's useful for you but can't hurt!)
ABL_Bug_Report.zip

Will use 2.0.0 for now. Hope the information provided will help you guys fix this bug.

Thanks for your hard work on this firmware.

Regards,

Chris

[ellensp]

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.

[W3DP]

This is my start gcode:

M117 Print Starting...
M75 ; Start Print Timer and Engage Fil Sensor if USB Printing
M84 E ; Disable E Motor for probe accuracy on direct drive systems
M117 Antiblob retract...
G92 E0 ; Reset Extruder distance to 0
G1 E-2 ; Retracts filament to prevent blobs during probing
G92 E0 ; Reset Extruder distance to 0
M117 Homing All...
G28 ; home all axes
M117 Homing Z Probe...
G28 Z ; home z again
M117 Generating mesh...
G29; auto bed leveling
M117 Heaters Recovering...
G4 S10; wait for heaters to recover
M420 Z0; Z fade
M900 K0; LA

M117 Purging extruder...
G92 E0 ; Reset Extruder
G1 Z2.0 F3000 ; Move Z Axis up little to prevent scratching of Heat Bed
G1 X0.1 Y20 Z0.3 F5000.0 ; Move to start position
G1 X0.1 Y200.0 Z0.3 F1500.0 E15 ; Draw the first line
G1 X0.4 Y200.0 Z0.3 F5000.0 ; Move to side a little
G1 X0.4 Y20 Z0.3 F1500.0 E30 ; Draw the second line
G92 E0 ; Reset Extruder
G1 Z2.0 F3000 ; Move Z Axis up little to prevent scratching of Heat Bed
G1 X5 Y20 Z0.3 F5000.0 ; Move over to prevent blob squish

Works on 2.0.0, not on any subsequent releases

[W3DP]

I added the S1 argument to my M420 command in my start gcode and tested with 2.0.6. No change, the issue is still there.

[thestephenmarshall]

All these releases have the same issue so it seems the bug was introduced in 2.0.1

We've all been struggling with this for some time now.

Here is the comparison of 2.0.1 to 2.0.0 https://github.com/MarlinFirmware/Marlin/compare/ac7ee4b94a200590a566fd6979f4738976de12b6...ee170519334d4e2c2aed28437dd94ca298923a18

[boelle]

@W3DP did you remember to save EEprom after bed level?

[boelle]

Here is the comparison of 2.0.1 to 2.0.0 ac7ee4b...ee17051

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.

[thestephenmarshall]

Here is the comparison of 2.0.1 to 2.0.0 ac7ee4b...ee17051

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.

Tested it on both of my printers. Issue still exists. 2.0.0 is working as expected which correlates to the version I was running upon originally installing my BLTouch in Feb. After that, I updated to 2.0.3 and that is when I started noticing something was wrong. Before moving back to 2.0.0 from bugfix branch, I tried 2.0.1 which still did not compensate correctly.

Understanding the above, I can agree with this statement based on the commit/release history:

All these releases have the same issue so it seems the bug was introduced in 2.0.1

I am simply trying to help shed light on what may be an area for bisection.

[W3DP]

I added the S1 argument to my M420 command in my start gcode and tested with 2.0.6. No change, the issue is still there.

@W3DP did you remember to save EEprom after bed level?

I saved to EEPROM after flashing firmware and saved mesh to EEPROM after probing bed for UBL. Did not save to EEPROM after probing for ABL (don't think you need to though?). Currently running ABL on 2.0.0 without issues.

I was on bugfix branch when doing most of the testing. Only switched to 2.0.6 when I could not get it to work properly with bugfix.

[boelle]

(don't think you need to though?)

if not its lost and M420 would not do anything

[W3DP]

I'm thoroughly confused now. My start gcode (see above) is provided by TH3D Studio for their EZABL probe and works faultlessly in 2.0.0 so the mesh is clearly saved.

Based on what I have read in the Marlin documentation, you only need to save the mesh to EEPROM for UBL. When using ABL, the mesh is saved in SRAM.

Has there been a change in Marlin releases post 2.0.0 that requires saving the mesh to EEPROM when using ABL?

[DanKeeling]

I've been having similar troubles and came across the thread, when restoring to 2.0.0 and using example configuration for CR10S, I did notice that the following has changed in later versions:

In 2.0.0 configuration

define MANUAL_X_HOME_POS 4

define MANUAL_Y_HOME_POS 2

In 2.0.6 for instance:

//#define MANUAL_X_HOME_POS 0
//#define MANUAL_Y_HOME_POS 0

I have not yet confirmed if 2.0.6 or bugfix branch works with the configuration changes above, but I can confirm a similar issue with consistent (at whatever my offset was set to and not adjusted based on bed mesh) z-heights after running a G29 just prior to printing using the same Cura profile and gcode file. With ABL bilinear, no adjustment appears to be made upon printing. Will confirm when test prints finish.

With 2.0.0 and the above configuration changes I am getting clean first layer prints where I was not prior.

[Crunch69]

@DanKeeling you are see a difference in bed leveling when changing were the probe homes too? In other words homing in the left corner makes a difference from homing in the center?

[DanKeeling]

I use safe homing in the center of the bed, but as the author described, I was having an issue of ABL not adjusting the heights until I changed back to 2.0.0 branch and configuration. I have now tested with the latest brach bugfix and same 2.0.0 configuration that ABL is working as expected. It was not adjusting the z height before. What I need to do to finish it testing the issue is adjust MULTIPLE_PROBING and EXTRA_PROBING as I left them commented out, so maybe the subdivision or the averaging isn't working after 2.0.0. I'm curious if the MANUAL X or Y HOME defined above being commented out is causing an issue with the "automatic" settings as described in the comments. Basically, process of elimination on whether or not the configuration portion is causing the issue opposed to code updates. I'll need to double check what else changed in the example configuration from 2.0.0 that is now working vs what I had before for completeness.

[testack18]

I'm experiencing the same issue with SKR 1.4 turbo and bltouch. As far as I know 2.0.0 didn't support this board (or at least I missed some configuration as I got error compiling the firmware using skr 1.4 turbo). Also there was other bltouch issues with earlier releases so I'm waiting for a solution.

I'm relative new to 3d printing with limited experiences but I'm happy to help in any testing with my config if somebody could give me instruction what and how to test on SKR 1.4.

Edit: I have tried 2.0.5.4, 2.0.6, and the latest available bugfix last night.

[ellensp]

@testack18 Please don't hijack others issues.
Different controller, different probe.
SKR v1.4 turbo was not added to marlin until 2.0.2

And you clearly looking for support not reporting a bug...
Please use one of these resources.

This Issue Queue is for Marlin bug reports and development-related issues, and we prefer not to handle user-support questions here. (As noted on this page.) For best results getting help with configuration and troubleshooting, please use the following resources:

• MarlinFW.org Marlin Documentation
• RepRap.org Marlin Forum
• Tom's 3D Forums
• Facebook Group "Marlin Firmware"
• Facebook Group "Marlin Firmware for 3D Printers"
• Marlin Configuration on YouTube
• Marlin Discord server. Join link: https://discord.gg/n5NJ59y

After seeking help from the community, if the consensus points to a bug in Marlin, then you should post a bug report.

[testack18]

I just wanted to help. Not hijacking anything, even if I didn't know exactly which version started to support 1.4 turbo...

I see tons of bug reports regarding bltouch bad compensation problem with various board types so I don't think I need support. I think this is a bug in the firmware.
I also see a lot of bug reports regarding this issue is cloesd referring as duplicates. So I wanted to keep clear and do not open a new thread for the same type of problem.
Edit: I also thought that SKR 1.3 and 1.4 are close enough to each other to not discussing them as totally different board.

Anyway, thanks for your kind hints. I'll leave. I don't want to spam.

[boelle]

Not hijacking anything,

yes you are

[Crunch69]

It appears if you configure ABL probing 3x3 you can sometimes get a first layer down 5x5 or 7x7 is a complete fail. UBL fails completely and requires manual correction for all probe points. TH3D firmware ABL works perfectly. SKR v1.3
TMC2209s E3D V6 with BMG direct drive

[W3DP]

Just a quick update. Tried the latest bugfix on Saturday. Problem still persists. Bed was leveled manually prior to the test and first layer was perfect without using ABL. With ABL, left side of the print seemed correct whilst right side was too low. You can visually see the nozzle drop down when it reaches the right end side of the bed.

[thestephenmarshall]

I am removing the BLTouch from my MPMS this weekend and replacing with an Autonics CR18-8DN, so I will be able to see if there is any improvement between the two devices. Interestingly enough, my Ender 5 with the same capacitive probe initially exhibited the same issues as listed here (just not an EZABL). What I did was dial in the nozzle to probe offset really well. Once dialed in, I was finally getting a 95% accurate mesh using billinear ABL on the latest bugfix. That being said, there is still something going on between the left and right side of the mesh that is being generated which makes no sense when you compare results from using MESH_BED_LEVELING which is manual probing. The Ender 5 is 100% dialed in square (I spent a few hours doing this to perfection).

[github-actions[bot]]

This issue has had no activity in the last 30 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 7 days.