[BUG] Auto Bed Leveling not Working #16380

GurenWolf · 2019-12-29T20:04:00Z

Hello Marlin fans and developers.

I have a Anycubic Kossel Linear Plus, Bigtreetech SKR 1.3 board, TMC2208 drivers in UART mode and the latest marlin bugfix 2.0.x firmware with a fairly standard setup.

Description of the Bug

After running Auto Bed Leveling (Bilinear), the first print is still uneven (higher on the left, lower on the right). Previous mechanical calibration has been done, such as tightening the belts and screws (not too much), securing the build plate firmly and lubricating the rails.

My Configurations

M503 report included.

Marlin.zip

Steps to Reproduce

Reset machine to factory defaults after uploading the firmware and save with M500.
Do autocalibration and save with M500.
Autohome.
Level the bed with Auto leveling.
Save with M500.
Autohome
Make sure ABL is ON.
Do a test print.

(Restoring ABL state is enabled in firmware and is it also stated inside the slicer which is the latest Cura. I also tried it with other Cura versions and the result is the same).

Expected behavior:

Even first layer, no excessively high areas, no excessively low areas.

Actual behavior:

Excessive high and low areas. (Left side is higher, right side is lower).

Thingiverse file used: https://www.thingiverse.com/thing:2563185

Additional Information

I am beginning to think that the plane is flipped since the steppers' rotation using TMC2208 drivers needs to be inverted in order for the printer to work correctly and MAYBE the firmware is not taking that into account. If that's not the case, then I definitely ran out of ideas; it kind of makes me want to grab the printer and through it out of the window after so many days of dealing with this.

I also noticed that when babystepping, the printhead goes nuts, way to high sometimes even though adjustments are subtle.

I would truly appreciate help and guidance on this.

sjasonsmith · 2019-12-29T20:11:50Z

I can't open your attached zip file. Seems corrupt?

You are not modifying the endstop heights after auto-calibration, are you? I think in the other issue you had opened you mentioned zeroing them out again.

GurenWolf · 2019-12-29T20:14:32Z

@sjasonsmith, I will reupload. And no, I did not readjust the endstop heights this time, all values shown are the ones coming from autocalibration and autoleveling.

GurenWolf · 2019-12-29T20:17:15Z

Files reuploaded.

sjasonsmith · 2019-12-29T20:25:33Z

Can you try the test print again with bed leveling completely disabled? I'd like to see whether leveling is actually making things worse.

I don't currently use bed leveling on my Kossel LP, I just use G33 auto-calibration, and I see much better behavior than your picture shows.

GurenWolf · 2019-12-29T20:31:36Z

Can you try the test print again with bed leveling completely disabled? I'd like to see whether leveling is actually making things worse.

I don't currently use bed leveling on my Kossel LP, I just use G33 auto-calibration, and I see much better behavior than your picture shows.

I forgot to mention that I have already done so. The result is pretty much the same. Maybe leveling settings are not getting stored?

I can of course tweak the endstop screws to play with the leveling, but figuring out which axes are responsible for this tilting is kind of complicated... delta printer after all. Autoleveling is supposed to help with this, but it is not. Back with the trigorilla board this issue was kind of fixed after leveling a few times.

The other thing that concerns me is that I managed to do some good quality prints with this 32 bit board, and then after upgrading the firmware a few times, things just messed up with fairly the same configurations.

sjasonsmith · 2019-12-29T21:02:01Z

With no bed leveling enabled, I would expect much better results than that. After a good G33, If you have issues I would expect them to occur as the radius increases from the center, not from one side to the other as you are seeing.

I believe that G33 reports the amount of error after each round on the terminal. I think it can stop either because it reaches good enough accuracy, or it has hit a limit on the number of iterations. If yours is stopping due to an iteration limit, there may be a mechanical issue that it isn't managing to compensate for. I believe you can actually run G33 as many times as you want, and it will use the current values as a starting point, so you could see wither running it multiple times ends up continuing to change values.

Obvious mechanical things to check would be to see whether those endpoint height offsets can be verified physically, and adjust them to be closer to even. I would also double check that there isn't anythink under the bed preventing it from sitting level. I find it easy to accidentally place that bad on the printer slightly askew.

GurenWolf · 2019-12-29T21:53:47Z

@sjasonsmith, I ended up downloading the firmware and setting everything up from scratch and also made sure that autoleveling is disabled on the slicer. After you said that autoleveling may be the culprit, that really caught my attention, so I did as much as possible to make sure that wouldn't bother.

Even though I had tried that option before, this time, after doing everything from scratch and leaving autoleveling disabled, I had better results, or to be more precise, the kind of results I used to have, this felt refreshing, and upsetting as well.

Some lower sides appeared on the print but they were somewhat aligned with the corresponding axes, so I went there and gave a very subtle twist to those endstop screws. It still needs more tweaking, but it's definitely better now.

Results:

So, from what I have seen, many of the marlin options make a lot more trouble and sometimes are pretty much useless, like in this case.

Anyways, thanks a lot. I can sleep calmly tonight. Or at least I believe so, more like hoping something as annoying as this doesn't come up again.

sjasonsmith · 2019-12-29T21:57:33Z

That is encouraging. Since you are now getting reasonably good behavior without bed leveling, it would be good to re-enable it and verify whether the problem returns. It is certainly a problem if bed leveling features make things worse.

GurenWolf · 2019-12-29T23:24:56Z

I did further testing now, this time using bed leveling. The results are about the same as the first picture where you can notice an uneven surface. In this case the whole first layer is covered since I adjusted the endstop screws previously, but the effect is the same, an uneven first layer.

Will keep working with bed leveling turned off and tweaking the endstop screws to see how good it can get (which so far is better than the autoleveling feature).

Thanks a lot @sjasonsmith , I will be posting more print results without the autolevel feature on a different thread soon.

sjasonsmith · 2019-12-29T23:33:48Z

Please leave this issue open for now. I'd like to see if I can reproduce the leveling issue you are seeing. I've done tons of tests to verify that probing works, but only rarely actually print anything.

GurenWolf · 2019-12-29T23:36:29Z

Sure, no problem. Waiting to see what you come up with as well.

AnHardt · 2019-12-30T10:09:03Z

In general Marlins bed leveling algorithms do work fine.
But they do level the probe (if there is one). So all mechanical problems causing a tilt of the Effektor, causing different probe-nozzle-distances over the bed, can't be compensated and/or make things worse.
On a delta the most common problem causing Effektor tilt is, diagonal rods to the same tower having not exactly the same length.

skellatore · 2020-01-02T05:20:12Z

I'm having problems with this on a delta as well. It feels like it's correcting in the wrong direction, or not considering the offset/adjustments from the G33 and only adding to them when its actually printing. On several occasions one side of my print was barely touching the bed and other other side, the nozzle is so close to the build plate the extruder starts skipping.

I'm going to try defaulting and bed leveling only and then defaulting+g33+bed leveling to see what is happening with the measurements and report back.

AnHardt · 2020-01-02T12:21:41Z

On a DELTA G33 and G29 theoretically exclude each other.
If the bed is bumpy G33 can't work at all.
If the bed is tilt only, this is corrected by G33.

skellatore · 2020-01-02T13:55:08Z

If that's the case, why aren't they mutually exclusive?

What's the official response on this?

sjasonsmith · 2020-01-02T14:10:35Z

@AnHardt I believe @Roxy-3D told me that delta was a significant use case for UBL, to compensate for “cupping” defects as the effector gets further from the center.

I’m not sure whether that need is still relevant or obsoleted by G33, it just seemed relevant to the current discussion.

skellatore · 2020-01-02T14:59:10Z

Something appears to be up with the BABYSTEP_ZPROBE_OFFSET. It appears that having this enabled is messing with some things. My probe Z offset is -16.38 and when I try to use the z adjustment via the LCD (with BABYSTEP_ZPROBE_OFFSET enabled) it says -6.83. If no adjustment is made, M503 reports -16.38. If I make an adjustment, M503 reports as -6.xx. It's losing 10mm somewhere!

disabling BABYSTEP_ZPROBE_OFFSET has resolved my problems and I can actually print now and the layer height is pretty consistent without it deciding it wants to bury the nozzle into another brand new PEI sheet and destroy it.

AnHardt · 2020-01-02T16:04:50Z

@sjasonsmith
We all know - there are no perfectly flat beds.
So in practice G33 does it's best to do it's job (assuming a perfectly flat bed).
And bedleveling tries to get rid of the remaining error.

Both fail if there is a varying effektor tilt over the bed-surface (analog to x-sled-rotation)

Before there was G33, G29 had to (try) to eliminate all the error introduced by, for example a wrong delta radius, causing concave/convex-plane errors. That was not new with UBL - has been there with the first delta-bed leveling.

At the begin there was 3-point-leveling just correcting the tilt.
Later multi-point-leveling averaged more probes to geet a better picture of bed. The only 3-points could be in valleys or on top of hills
Seen historically DELTA-leveling was the first kind of mesh-leveling (and had automatic probing).
Then Mesh-bed-leveling brought the meshes to the Cartesians and got it's famous precision by using manual probing with the nozzle (eliminating the bad effects of x-sled rotation and colleges by having no xy-probe-offsets).
UBL brought back automatic probing and, if you like lots of parameters and complexity, some impressing convenience features.

EDIT:
With G26 and some patience you now can eliminate all the probing errors (caused by x-sled-rotation and similar effects.)

InsanityAutomation · 2020-01-02T16:07:55Z

The menu type is defined as signed float 52, so only +/-#.### can be displayed. It can be changed to 43 if desired but you lose precision. This has been changed back and forth multiple times.

tpruvot · 2020-01-02T21:42:18Z

There is a sample config there (its what i currently use): config/examples/Alfawise/U20-bltouch/
ABL, BILINEAR, no babystep

I added an arrow on my Z axis top to be able to see the Z compensation over big moves... which seems kinda inexistant since october... (but not null, i can see tiny movements but not everywhere and a lot less than before)

M420 S1 Z3 in the start gcode

tpruvot · 2020-01-02T21:53:59Z

here is a 150x150 border stl to try https://drive.google.com/file/d/1xAMDX963g0dFcIeDvMgpEqrA9FVsQJBh/view?usp=sharing

GurenWolf · 2020-01-03T03:09:00Z

@AnHardt I believe @Roxy-3D told me that delta was a significant use case for UBL, to compensate for “cupping” defects as the effector gets further from the center.

I’m not sure whether that need is still relevant or obsoleted by G33, it just seemed relevant to the current discussion.

UBL, another little nightmare. I have also tried that option of course and in that case I don't know if it actually works, or if it is me mentally wanting it to work after almost two wasted hours of adjusting every single point on the mesh. To be honest, improvement is barely noticeable compared to the effort one has to make when using this option.

That is really my biggest complaint with UBL, there is no easy way to edit the mesh in a standard LCD. When trying to use the editing mesh option (and many other options in particular), the printhead goes wild ramming into everywhere it can and cannot reach.

By the way, I have done some other prints, and they have come out somewhat ok, but I am still calibrating the printer to get a great result, using a 32 bit board and super silent and precise stepper drivers is like learning how to use it from the beginning. Still, getting better results each time without any autoleveling feature.

tpruvot · 2020-01-03T03:13:23Z

so i finally got UBL working, but just like ABL... no obvious difference... i had to adjust the edges to fit the X/Y

   #define MESH_MIN_X _MAX(MIN_PROBE_EDGE, MESH_INSET)
   #define MESH_MIN_Y _MAX(MIN_PROBE_EDGE, MESH_INSET)
   #define MESH_MAX_X X_BED_SIZE - 35 // NOZZLE_TO_PROBE_OFFSET
   #define MESH_MAX_Y Y_BED_SIZE - _MAX(MESH_INSET, MIN_PROBE_EDGE)

To have Z compensation, all probe points need to be filled (none skipped) and the UBL enabled in the Motion/UBL/Activate menu (not kept against prints)

Z compensation seems not enough... max 5° rotation seen on Z, same as ABL one so, but seems kinda better than ABL... actually

looxonline · 2020-01-03T12:55:01Z

Something appears to be up with the BABYSTEP_ZPROBE_OFFSET. It appears that having this enabled is messing with some things. My probe Z offset is -16.38 and when I try to use the z adjustment via the LCD (with BABYSTEP_ZPROBE_OFFSET enabled) it says -6.83. If no adjustment is made, M503 reports -16.38. If I make an adjustment, M503 reports as -6.xx. It's losing 10mm somewhere!

disabling BABYSTEP_ZPROBE_OFFSET has resolved my problems and I can actually print now and the layer height is pretty consistent without it deciding it wants to bury the nozzle into another brand new PEI sheet and destroy it.

Yes!!! This is exactly what I have been noticing with the latest builds. Completely wrecked one of my PEI sheets!

GurenWolf · 2020-01-03T18:33:05Z

Something appears to be up with the BABYSTEP_ZPROBE_OFFSET. It appears that having this enabled is messing with some things. My probe Z offset is -16.38 and when I try to use the z adjustment via the LCD (with BABYSTEP_ZPROBE_OFFSET enabled) it says -6.83. If no adjustment is made, M503 reports -16.38. If I make an adjustment, M503 reports as -6.xx. It's losing 10mm somewhere!
disabling BABYSTEP_ZPROBE_OFFSET has resolved my problems and I can actually print now and the layer height is pretty consistent without it deciding it wants to bury the nozzle into another brand new PEI sheet and destroy it.

Yes!!! This is exactly what I have been noticing with the latest builds. Completely wrecked one of my PEI sheets!

I just disabled this option as well and it seems to be printing even more accurate. I wouldn't have noticed if it weren't because of those comments. Thanks @skellatore and @looxonline. Will keep printing and fine tuning more without the helping features to see what results I get.

Bluey2444 · 2020-01-05T03:48:25Z

I'm using bilinear levelling and it's applying an inverted compensation. So instead of moving the nozzle up it's moving it down and vice versa. BTT SKR 1.3 and bltouch sensor on a 200x200 bed. Wanhao i3.

boelle · 2020-01-10T16:04:28Z

@GurenWolf is this still an issue when using bugfix 2.0.x ?

GurenWolf · 2020-01-10T19:52:54Z

@boelle, bugfix 2.0.x is exactly what I am using. It doesnt matter how many times I download it and begin from scratch, ABL just doesn't work as intended. For the time being, I am leaving that feature off as well as BABYSTEP_ZPROBE_OFFSET as said by @skellatore .

Something appears to be up with the BABYSTEP_ZPROBE_OFFSET. It appears that having this enabled is messing with some things. My probe Z offset is -16.38 and when I try to use the z adjustment via the LCD (with BABYSTEP_ZPROBE_OFFSET enabled) it says -6.83. If no adjustment is made, M503 reports -16.38. If I make an adjustment, M503 reports as -6.xx. It's losing 10mm somewhere!

disabling BABYSTEP_ZPROBE_OFFSET has resolved my problems and I can actually print now and the layer height is pretty consistent without it deciding it wants to bury the nozzle into another brand new PEI sheet and destroy it.

Leaving these features off and tweaking the endstop screws has proven to be more effective so far.

randellhodges · 2020-01-10T20:21:47Z

When M503 reports wrong, what does M851 with no arguments report?

I looked at the code, and I do see some differences between what values they use when reporting. Also, I wonder if doing a save before M503 changes the results.

I'm not sure the difference between probe_offset_xy and probe_offset and when those values get put in sync.

M503

      SERIAL_ECHOLNPAIR_P(
        #if HAS_PROBE_XY_OFFSET
          PSTR("  M851 X"), LINEAR_UNIT(probe_offset_xy.x),
                  SP_Y_STR, LINEAR_UNIT(probe_offset_xy.y),
                  SP_Z_STR
        #else
          PSTR("  M851 X0 Y0 Z")
        #endif
        , LINEAR_UNIT(probe_offset.z)
      );

M851

	SERIAL_ECHOLNPAIR_P(
      #if HAS_PROBE_XY_OFFSET
        PSTR(MSG_PROBE_OFFSET " X"), probe_offset.x, SP_Y_STR, probe_offset.y, SP_Z_STR
      #else
        PSTR(MSG_PROBE_OFFSET " X0 Y0 Z")
      #endif
      , probe_offset.z
    );

I don't have a delta, but I have run Marlin with an SKR 1.3 and 2208s and SKR 1.4 with 2209s with babystepping and I haven't run into this issue. One difference is that I do not specify the Z offset in the firmware. I leave it set to 0 and only do it with M851 or the UI menu option to specify probe offset.

I usually only do a babystepping menu option while printing and then might save via the UI but I don't go check it with an M503 while printing.

Might be my "workflow" means I haven't seen that particular issue.

InsanityAutomation · 2020-01-10T20:38:48Z

@GurenWolf to be 100% sure, youve tried after #16425 got merged?

looxonline · 2020-01-11T03:36:08Z

@GurenWolf to be 100% sure, youve tried after #16425 got merged?

Mine was fixed after this.

GurenWolf · 2020-01-11T03:48:12Z

I will give it another go from the beginning to see what happens.

boelle · 2020-01-14T19:14:13Z

@GurenWolf how did it go?

GurenWolf · 2020-01-14T23:02:03Z

Sorry I haven't posted anything yet, I have been quite busy during these days. I will post results some time during this week.

GurenWolf · 2020-01-19T04:26:00Z

Just downloaded and tried to test the latest Malrin Bugfix2.0.x, but I got this error after trying to compile:

Marlin\src\HAL\HAL_LPC1768\../../core/../inc/../core/drivers.h:71:51: error: missing binary operator before token "("
 #define AXIS_DRIVER_TYPE(A,T) AXIS_DRIVER_TYPE_##A(T)

I am using vscode and platformio.

Config Files:
Marlin.zip

boelle · 2020-01-23T11:58:29Z

what tool do you use to compile with?

GurenWolf · 2020-01-23T18:32:13Z

This issue is being discussed in #16611. The firmware compiled after applying a workaround mentioned in there. I will begin testing to see what happens.

GurenWolf · 2020-01-23T20:54:32Z

So.... after all this time, these are my final thoughts on what has been done. I did everything from scratch as usual, taking into consideration that #16425 got merged with the latest firmware.

And after all the fixing and redoing from Marlin developers, ABL got better. However, I am still preferring @sjasonsmith apporach of leaving the feature off.

Why?.... Because ABL simply got better, but not as near as good as what I attempted to achieve by leaving the feature off and tweaking the endstop screws.

To wrap it up, there is definitely an improvement on the feature, you can tell it levels the bed a lot better, with a few hiccups on the way (still showing signs of a lower side, but not as pronounced as before). The Z-Probe Ofsset is now showing the correct value and behaving as it should as well.

And these are the pictures after the final attempt, using the same file shown at the beginning:

Thank you all so much for the effort put into this.

Any final comments before closing this thread?

looxonline · 2020-01-24T05:46:33Z

I'm using Cartesian and I can say that ABL has never been better. I've increased my grid size, enabled double probing and enabled the experimental interpolation feature. I now get completely level prints across the bed.

boelle · 2020-01-24T12:44:20Z

same as @looxonline, been using bi-linear or ages and never seen an issue

GurenWolf · 2020-01-24T14:36:34Z

I'm using Cartesian and I can say that ABL has never been better. I've increased my grid size, enabled double probing and enabled the experimental interpolation feature. I now get completely level prints across the bed.

I guess it is an implementation that suits best cartesian printers. For now, my delta is better off with manual leveling.

InsanityAutomation · 2020-01-24T14:42:23Z

@GurenWolf realistically its just the most tested. Very few active developers have Delta machines unfortunately. I get cartesian thrown at me relatively often but nobody has offered to donate a delta. So as development advances regressions can commonly creep in, process deviate, and nobody realizes until quite some time later.

thinkyhead · 2020-01-25T10:48:28Z

Historical note: Marlin's ABL Bilinear was adapted from the Delta bilinear leveling implemented by Johann Rocholl back in Marlin 1.0.0 days.

github-actions · 2020-07-03T10:04:12Z

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.

InsanityAutomation mentioned this issue Jan 2, 2020

Use Z-offset editing precision based on value limits #16425

Merged

GurenWolf closed this as completed Jan 24, 2020

github-actions bot locked and limited conversation to collaborators Jul 3, 2020

[BUG] Auto Bed Leveling not Working #16380

[BUG] Auto Bed Leveling not Working #16380

Comments

GurenWolf commented Dec 29, 2019 • edited Loading

Description of the Bug

My Configurations

Steps to Reproduce

Additional Information

sjasonsmith commented Dec 29, 2019

GurenWolf commented Dec 29, 2019

GurenWolf commented Dec 29, 2019

sjasonsmith commented Dec 29, 2019

GurenWolf commented Dec 29, 2019

sjasonsmith commented Dec 29, 2019

GurenWolf commented Dec 29, 2019 • edited Loading

sjasonsmith commented Dec 29, 2019

GurenWolf commented Dec 29, 2019 • edited Loading

sjasonsmith commented Dec 29, 2019

GurenWolf commented Dec 29, 2019

AnHardt commented Dec 30, 2019

skellatore commented Jan 2, 2020

AnHardt commented Jan 2, 2020

skellatore commented Jan 2, 2020

sjasonsmith commented Jan 2, 2020

skellatore commented Jan 2, 2020

AnHardt commented Jan 2, 2020 • edited Loading

InsanityAutomation commented Jan 2, 2020

tpruvot commented Jan 2, 2020 • edited Loading

tpruvot commented Jan 2, 2020

GurenWolf commented Jan 3, 2020 • edited Loading

tpruvot commented Jan 3, 2020 • edited Loading

looxonline commented Jan 3, 2020

GurenWolf commented Jan 3, 2020

Bluey2444 commented Jan 5, 2020

boelle commented Jan 10, 2020

GurenWolf commented Jan 10, 2020

randellhodges commented Jan 10, 2020

InsanityAutomation commented Jan 10, 2020

looxonline commented Jan 11, 2020

GurenWolf commented Jan 11, 2020

boelle commented Jan 14, 2020

GurenWolf commented Jan 14, 2020

GurenWolf commented Jan 19, 2020

boelle commented Jan 23, 2020

GurenWolf commented Jan 23, 2020

GurenWolf commented Jan 23, 2020

looxonline commented Jan 24, 2020

boelle commented Jan 24, 2020

GurenWolf commented Jan 24, 2020

InsanityAutomation commented Jan 24, 2020

thinkyhead commented Jan 25, 2020

github-actions bot commented Jul 3, 2020

GurenWolf commented Dec 29, 2019 •

edited

Loading

GurenWolf commented Dec 29, 2019 •

edited

Loading

GurenWolf commented Dec 29, 2019 •

edited

Loading

AnHardt commented Jan 2, 2020 •

edited

Loading

tpruvot commented Jan 2, 2020 •

edited

Loading

GurenWolf commented Jan 3, 2020 •

edited

Loading

tpruvot commented Jan 3, 2020 •

edited

Loading