[BUG] UBL and Bilinear Leveling not working, Z Axis not moves with enabled Bed Level

[silentpain711]

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

Bilinear Bed Level and also UBL Bed Level doesn't work for me.

i have Build the Marlin 2.1.2 and the bugfix-2.1.x Version In both, i can create the Mesh Level and show it with M420 V. But in print progress are not working to compensate the Mesh Level with the Z Axis both Stepper standing still. I feel both Z Axis from Z Steppers with my finger no reaction from steppers in first Layer.

So I have on Left Side too low and on the Right Side a too high Bed Level.

Original BLTouch is used as z probe.

My EPROM is working i can save Mesh Level Data and after Power off is the Mesh Level Data always existing.

I have testet the Start GCode with M420 S1 and G29.

M420 S1 Version:

M104 S[first_layer_temperature] ; set hotend temp M140 S[first_layer_bed_temperature] ; set bed temp G28 ; home all axes M420 S1; enable mesh level M109 S[first_layer_temperature] ; wait for hotend temp M190 S[first_layer_bed_temperature] ; wait for bed temp G1 X5 Z0.6 Y5 F1000.0 ; go left front print area for intro line G92 E0.0 G1 X65.0 E9.0 F1000.0 ; intro line G92 E0.0

G29 Version:

M104 S[first_layer_temperature] ; set hotend temp M140 S[first_layer_bed_temperature] ; set bed temp G28 ; home all axes G29; create mesh level M109 S[first_layer_temperature] ; wait for hotend temp M190 S[first_layer_bed_temperature] ; wait for bed temp G1 X5 Z0.6 Y5 F1000.0 ; go left front print area for intro line G92 E0.0 G1 X65.0 E9.0 F1000.0 ; intro line G92 E0.0

Bug Timeline

No response

Expected behavior

I have Expected that the Z Axis Compensate the Mesh Level with drive down by negative Values in Mesh Level data and up by positive Mesh Level Data. To Compensate the uneven Bed.

Actual behavior

Z Axis doesn't move by print a layer with enabled Mesh Level.

Steps to Reproduce

No response

Version of Marlin Firmware

2.1.2

Printer model

Anycubic I3 Mega S

Electronics

Bigtreetech SKR 3 EZ

Add-ons

No response

Bed Leveling

ABL Bilinear mesh

Your Slicer

Prusa Slicer

Host Software

None

[silentpain711]

Here is my both Config Files in a Zip File:

Config Files.zip

[RV-from-be]

@silentpain711 This is unfortunately not a Marlin issue, but a hardware issue. Please, check your printer, mounting, axis squareness, axis parallelism, POMs wheel,...

[stef-ladefense]

read this : https://github.com/MarlinFirmware/Marlin/issues/25274

[plampix]

The G29 version not working is probably caused by a typo in the start gcode. You're using M29 instead of G29 over there.

[Zizzinator]

Having the same issue but I've check to make sure no typo is in the start code unlike OP

G92 E0 ;Reset Extruder G28;Home axis and disable mesh bed level M420 S1 ;Autolevel recall from saved G1 Z2.0 F3000 ;Move Z Axis up G1 X9.1 Y20 Z0.28 F5000.0 ;Move to start position G1 X9.1 Y200.0 Z0.28 F1500.0 E15 ;Draw the first line G1 X9.4 Y200.0 Z0.28 F5000.0 ;Move to side a little G1 X9.4 Y20 Z0.28 F1500.0 E30 ;Draw the second line G92 E0 ;Reset Extruder G1 Z2.0 F3000 ;Move Z Axis up

ex: of pronterface output: Bilinear Leveling Grid: 0 1 2 3 4 5 0 -0.100 -0.078 -0.040 -0.013 -0.023 -0.035 1 -0.078 -0.058 -0.073 -0.053 -0.073 -0.065 2 -0.018 -0.067 -0.060 -0.058 -0.108 -0.113 3 -0.120 -0.130 -0.108 -0.100 -0.103 -0.120 4 -0.048 -0.168 -0.205 -0.143 -0.127 -0.108 5 -0.183 -0.200 -0.138 -0.138 -0.105 -0.103 echo:busy: paused for user echo:busy: paused for user echo:busy: paused for user

m500 SENDING:M500 echo:Settings Stored (726 bytes; crc 48110)

G29 on it's own and when spliced into the start code works just fine, and am able to get a readout that matches what I would expect for in Pronterface. Creality has a rather crap UI so I don't know what it's actually seeing and using from the Marlin config in the printer. which stinks since it's slicer is fairly easy to use compared to Repetier or Pronterface which are not good with .3mf files... M500 registers as memory stored confirmed both by Pronterface direct control and the LCD on the printer. When M20 S1 or G29 or any recall of the mesh bed level is used though the z axis does not compensate for the bed mesh saved. There is no binding of the carriage, the X axis is not sticking nor is there an issue with the nozzle. I can literally put my finger on the z axis and what should be very minute movements I'm feeling nothing.

Am using Creality slicer and Ender 3 board 4.2.7, got a BL touch sensor and have set the z offset from the sensor within .003mm using feeler gauges at the z home touch spot. obviously with the bed warp it's a bit off at the corners.

feels like I'm going crazy but the only responses I've gotten to trouble shoot are 'include M420 S1, or G29' aka nothing useful

thoughts?

[silentpain711]

M29 was a typo in the post in my real GCode stand G29. I can‘t fix my Problem the Printer stands still and wait for a solution.

[Fossdal]

using marlin 2.1.2 and BLtouch, and Skr mini e3 v1.2

I have the same problem.

my bed is a little low on the right side when i print a test pattern of 9 squars spred over the bed to do a first layer test. i can clearly see that the nozzle is further away on the ones in the right side. and using bed visualizer in octoprint i can also see that it is lower on the right side. this is the start of the gcode ;FLAVOR:Marlin ;TIME:610 ;Filament used: 0.421474m ;Layer height: 0.2 ;MINX:27.74 ;MINY:27.74 ;MINZ:0.2 ;MAXX:207.26 ;MAXY:207.26 ;MAXZ:0.2 ;Generated with Cura_SteamEngine 5.3.0 M140 S60 M105 M190 S60 M104 S212 M105 M109 S212 M82 ;absolute extrusion mode ; Ender 3 Custom Start G-code G92 E0 ; Reset Extruder G28 ; Home all axes G29 ; Auto bed-level (BL-Touch) 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 G92 E0 G92 E0 G1 F2700 E-5 ;LAYER_COUNT:1 ;LAYER:0 M107 ;MESH:1 Leyar 9 squars.3mf G0 F6000 X107.678 Y108.22 Z0.2 ;TYPE:WALL-INNER G1 F2700 E0

[AkashicSeer]

I have had this problem for months on my ender 3 max with version 4.2.2 board, with a CR touch. Nothing I do makes this feature work. I have spent months trying to get it working. I have done all the mesh creation and validation. I save it to eeprom etc. I activate UBL in the menu. I add M420 S0 to the gcode to make it use the mesh. It simply does not apply the mesh.

I have run the validation tool until it looks perfect. Getting it to even look decent takes tons of time adjusting. And the adjusting makes no sense. Mesh edit is nonsense. I edit the points that the auto generator miss and each time I change one it tries to recalculate others that were perfect and the next time I check one that was perfect after adjusting one anywhere, it is either too high or eats into the bed. WTF is that how it is supposed to work??

I have taken the printer apart 3 times and checked everything is aligned. I added a second Z stepper thinking that would help. I have changed the nozzle 6 times. I adjusted all POM wheels and replaced some.

All of it seems to be Marlin UBL not working properly. I now even compile my own firmware. I have adjusted and changed and tried everything I can find in both configuration profiles all the way up to marlin 2.12 now and nothing fixes this.

I have also done everything anyone and everyone has suggested. To get a good print I have to stand there while the first layer is going down and manually change the z height by using the Tune -> baby z step option adjusting it up and down as it prints.

I have run out of ideas. I am ready to just spend $30 and get a new Mainboard from Amazon, one with wifi. I just can't imagine what could possibly be the problem?

[AkashicSeer]

for me it was Prusa doing something that turns off the UBL, even if I had restore or enable after homing uncommented in the configurations file. I even tried adding M420 S1to the gcode and it still would not use the mesh. I switched over to Cura and BOOM problem solved. At least that problem anyways.

[EvilGremlin]

It's starting gcode and RESTORE_LEVELING_AFTER_G28, you can easily solve this in PrusaSlicer too.

[AleKrabbe]

Any news on this?

I have the same problem.

Running Marlin 2.1.2.1 with bug fixes on a Ender 3 with BTT SKR E3 V3 and CR Touch.

I use M420 S1 after G28 on the printer settings (using Cura 5.3.1 slicer) and the Z motor does not spin to compensate for the uneven bed, this can't be related to hardware or wiring because everything else works, homing, moving axis, printing, etc...

It just ignores the bed mesh stored on the EEPROM, I validated that there is a bed mesh stored with the M420 V1 command, this is the output:

Send: M420 V1 Recv: Bilinear Leveling Grid: Recv: 0 1 2 3 4 Recv: 0 +0.092 +0.080 +0.057 +0.067 +0.100 Recv: 1 -0.050 -0.028 -0.013 +0.085 +0.172 Recv: 2 -0.075 -0.070 -0.043 +0.057 +0.127 Recv: 3 +0.055 +0.015 +0.015 +0.077 +0.110 Recv: 4 +0.077 +0.012 -0.003 +0.052 +0.047 Recv: Recv: echo:Bed Leveling ON Recv: echo:Fade Height OFF

I event did that mid print to check if ABL was ON, and it was; regardless of that, the Z rod was still no moving, proven by the fact that the print itself had areas where the nozzle almost scratched the bed and other areas where the print was not sticking to the build plate.

The bed was trammed and Z-OFFSET was defined corectly as to when z = 0 the nozzle barely scratches a piece of papper.

I also tried to compile my own version of Marlin, here are the configuration files: marlin_configs.zip

Please let me know if there is anything else I can provide in order for this problem to be solved, lets get to the bottom of it.

Thank you.

[Fossdal]

i put a piece of tape sticking long out on top of the z-rod so it was easier to see it spinning, and i could see that it compensated on the first layer. but it was not compensating enough to make any difference, the nozzle was still good on the left side and far off the bed on the right side

i have since updated to latest 2.1.2.1 and re-leveled the bed as good as i can. and so the bl-touch is practically not needed. i have not made any test with the new 2.1.2.1. to see if it solved the problem

[AleKrabbe]

That kinda defeats the purpose of having the z probe and ABL, would be nice to figure out whats wrong on the firmware.

[joao-a-cardoso]

This is also happening to me.

I an using ABL Bilinear, with grid size 10x10, built with a PINDA V2 probe with the nozzle at 250º and bed at 100º. Leveling Fade Height is disabled.

I have the bed fairly level, less than 0.5 mm differences between higher and lower points, which I confirmed by observing with the Octoprint Bed visualizer and Marlin's own Mesh Editor. Also I have bed leveling activated at start up.

I test by moving over the X axis using g1 x300. The Z axis motors should move to compensate, and they just don't move.

It has already worked in the past.

I am using version 2.1.2.1, on A BTT BlueR Plus, using a MKR Robin Nano V3.1. Attached my config files Configuration.zip.

Is there anything wrong with my setup? Anything I can do to make this work?

[ellensp]

With ENABLE_LEVELING_FADE_HEIGHT enabled several of you have #define DEFAULT_LEVELING_FADE_HEIGHT 0.0 (also settable with M420 Z or for UBL G29 F) So you also need to check your eeprom settings

if Z is higher than DEFAULT_LEVELING_FADE_HEIGHT, all compensation is disabled.

Ie you have disabled all bed leveling compensation by setting this to 0

Also when testing Z is compensating or not, you Z must be under the DEFAULT_LEVELING_FADE_HEIGHT The closer to the bed the more pronounced the compensation . It also pays to have some sort of flags on your lead screws, so any move is obvious, as the movements are small

[joao-a-cardoso]

several of you have #define DEFAULT_LEVELING_FADE_HEIGHT 0.0 (also settable with M420 Z or for UBL G29 F) So you also need to check your eeprom settings

if Z is higher than DEFAULT_LEVELING_FADE_HEIGHT, all compensation is disabled.

Ie you have disabled all bed leveling compensation by setting this to 0

Also when testing Z is compensating or not, you Z must be under the DEFAULT_LEVELING_FADE_HEIGHT The closer to the bed the more pronounced the compensation . It also pays to have some sort of flags on your lead screws, so any move is obvious, as the movements are small

I have it commented out... Though that would disabled the fade... Will try that. Thanks

[ellensp]

Disabling #define ENABLE_LEVELING_FADE_HEIGHT disables the fade feature, so compensation occurs the full Z height Disabling #define DEFAULT_LEVELING_FADE_HEIGHT {number} marlin uses the default value of 0, ie it is disabled.

[ellensp]

@joao-a-cardoso reduce your mesh size to 5x5, there looks like there may be a bug with Bilinear where if mesh size is > 7x7 ish (there are other factors) it will corrupt eeprom, so there is no valid mesh to enable without re probing.

[joao-a-cardoso]

Disabling #define ENABLE_LEVELING_FADE_HEIGHT disables the fade feature, so compensation occurs the full Z height Disabling #define DEFAULT_LEVELING_FADE_HEIGHT {number} marlin uses the default value of 0, ie it is disabled.

Thanks for your response, just checked my config:

Indeed enable, is commented.

[joao-a-cardoso]

@joao-a-cardoso reduce your mesh size to 5x5, there looks like there may be a bug with Bilinear where if mesh size is > 7x7 ish (there are other factors) it will corrupt eeprom, so there is no valid mesh to enable without re probing.

Thank you again :-)

Just to confirm, if eeprom gets corrupted I would not be able to reload the mesh, right?.

Yet, that dos not seem to be the case, because it is possible to load the mesh (or so it seems)

Or, am I thinking it wrong?

[joao-a-cardoso]

Todar, turned th eprinter on and repeated the tests. Now, moving the X axis cuases the X axis to move for compensating. Without changing anything, weird....

[github-actions[bot]]

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

[AkashicSeer]

i put a piece of tape sticking long out on top of the z-rod so it was easier to see it spinning, and i could see that it compensated on the first layer. but it was not compensating enough to make any difference, the nozzle was still good on the left side and far off the bed on the right side

i have since updated to latest 2.1.2.1 and re-leveled the bed as good as i can. and so the bl-touch is practically not needed. i have not made any test with the new 2.1.2.1. to see if it solved the problem

I thought I was the only one. I've been losing my mind with Marlin. I need to try klipper soon. I put marlin on a new BTT E3 V3 board and I can see the z rods turning but as you say it is not working properly. Parts of the first layer are too high and don't stick, others are too low and smashed to hell. It is really noticeable with a large flat print. It really is a pain in the ass. Even with my new board, getting a mesh validation to print properly is a roll of the dice. I can literally do one right after the other, no changes and they are not the same.

I have to find a way to run clipper, my old laptops are too old.

[AkashicSeer]

With ENABLE_LEVELING_FADE_HEIGHT enabled several of you have #define DEFAULT_LEVELING_FADE_HEIGHT 0.0 (also settable with M420 Z or for UBL G29 F) So you also need to check your eeprom settings

if Z is higher than DEFAULT_LEVELING_FADE_HEIGHT, all compensation is disabled.

Ie you have disabled all bed leveling compensation by setting this to 0

Also when testing Z is compensating or not, you Z must be under the DEFAULT_LEVELING_FADE_HEIGHT The closer to the bed the more pronounced the compensation . It also pays to have some sort of flags on your lead screws, so any move is obvious, as the movements are small

It sure would be nice if this sort of info was in the docs. I despise the docs in their current state.

[AkashicSeer]

@joao-a-cardoso reduce your mesh size to 5x5, there looks like there may be a bug with Bilinear where if mesh size is > 7x7 ish (there are other factors) it will corrupt eeprom, so there is no valid mesh to enable without re probing.

Is this really what is happening? I've been trying to get my printer working properly for almost a year now. I think I've been using more than 5 x 5. It sure would be nice if this sort of info was in the docs.

[AkashicSeer]

So you guys close an issue that is still an issue without any solution. Why do I keep trying to get marlin working FFS.

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