[BUG] ABL z-offset sporradic compensation.

[nfons]

Bug Description

my setup: Ender 3 Pro w/ Skr mini e3 1.2 BLT 3.1 Bullseye mount @ -48, -10 Bed: PEI flex sheet

6x6 grid with multiple_probes = 2 for weighted accuracy

Config.h config_adv.h

running a bed level test print , the z-offset seems to be sporadic. I have run this with bi linear subdivision on/off and still the same result.

I have looked in to #15206 to make sure I can eliminate X-gantry sag. To verify I did a cold paper corner test (all 0'd). As well as measurement of x-gantry via calipers. To the best of my testing, these are relatively accurate.

I did a M48 to test probe accuracy, which comes out to std dev: 0.00172 (I think rather accurate)

after this I did a heated G29 to factor in thermal expansion. which makes my bed look like this:

I have done few prints with both bilinear subdivision on and off

if my z-offset is inaccurate (either too much/little) then I would expect this to be propagated through the print. yet its not.

As you can see "X" marks spots with bad levels (either under or over)

if it was a gantry, issue, I would expect one side to be an issue, yet you can see here:

perfect at around mid point. too high @ 0,0 too high @ 0,225 close @ 225,255 perfect @ 225,0

Here is another @ a different level:

G for good, U for Under, 0 for over

[thierryzoller]

RELATED TO https://github.com/MarlinFirmware/Marlin/issues/17349 ?

[nfons]

I dont think so.

in any case, here is a few other test i did using EZABL instead of blt. i purposefully put the right side lower.

even with that I am still seeing oddities

[thierryzoller]

Wow, I must say I am impressed by the Bug Reports I am seeing here - I have very rarely come across such detailed and usefull bug reports.

[thierryzoller]

I used G26 to print a test and I can replicate your findings. It is almost as if ABL doesn't compensate at all. Back to manual leveling

[nfons]

@thierryzoller did you see #17399 ? could you try 2.0.4.4 to see if that works?

[thierryzoller]

Currently stuck, will do once I can

[boelle]

@nfons is the issue still there?

[nfons]

@boelle yes. as a work around, I did g29, and then saved mesh to eeprom.

then during print, I manually adjusted the bed via springs (I have the yellow springs + nylock mod) it seems to hold fine for now.

[thierryzoller]

So the original issue still exists?

[boelle]

Please test the bugfix-2.0.x branch to see where it stands.

[nfons]

@boelle Yea, compiling and testing it now. will report back

[txt4nk]

I am having the exact same issue as @nfons, seeing the same crazy mesh on bed visualizer, looks like a mountain range.. I have been battling this for months now, just tried the latest bugfix and it's still there for me. Setup: Ender 5 Pro E3D Hemera BTT SKR E3 Mini V1.2 (I have tried two E3 DIP boards, a V1.1 mini and a TH3D EZboard lite.. all have this issue)

My M48 fluctuates between 0.0018-0.0020 My bed is 100% true, it is a cast aluminum bed that I had sanded down and verified to be flat within 0.05mm.

I did the 4 corner test, still get horrible first layers. But if I turn off ABL all together and re-install my mechanical z stop switch, its the nicest first layer you've ever seen.

[txt4nk]

Any updates on this? I just installed a brand new heat bed, downloaded the latest bugfix and am still having the exact same issue.

I'll do whatever testing you guys need me to.. I just need to get this printer back up and running. Here's a link to the build I created tonight and my printer specs. Ender 5 Pro E3D Hemera SKR E3 Mini V1.2

Marlin-bugfix-2.0.x.zip

[thierryzoller]

Oh, issues will just be closed, if you cannot proof that you have tested with the latest bugfix and it still is a problem. I have never seen any software product where the burdon is put on the reporter as much as this one. No indication or pointer to lines of code changed to fix the bug. If you don't spend your free time, continously, monthtly updating , flashing testing, then the issue is closed. Magic bugfixing :)

[txt4nk]

I figured they would prefer not to open several threads about the exact same issue so I tried to post here to get some traction on this.. but I guess I'll just have to start my own and monitor this one. Just one more out of the SEVERAL threads about the same issue.. but if that's how they prefer it, so be it.

[sjasonsmith]

@thierryzoller and @txt4nk I thought I had replied to this earlier, but must have never quite reached the point of clicking the comment button.

This was clearly never a "stale" issue, and shouldn't have been marked as such. Often issues are reported without enough information to debug, and the reporters vanish. Allowing these to collect obscures important issues, and makes it harder to see what needs attention. I believe that process is still evolving somewhat, but the intent is that a simple reply would automatically keep the issue alive.

I closed the new report from @txt4nk because it was (by admission) a duplicate. Spreading a single issue across multiple reports makes it hard to see progress. In this case it is entirely possible that nobody is yet doing anything, because the right person to help has not yet happened to investigate. (I don't know who the right person is, it might be you!).

[txt4nk]

My printer is sitting here idle, if anyone has ideas but lack a printer with this issue I will do any sort of testing you need. Hell, if you're in west texas you can even take my printer to do your own testing for all I care.

[nfons]

I still see the issue somewhat. but admittedly the bugfix version is MUCH MUCH better than the previous ones.

The simple fix that I was able to do was hit g29, then level the bed manually via knobs.

though this is not a 100% fix, since I cannot re-g29 but for my purposes It "works"?

only draw back is that I cant change beds.

[txt4nk]

Yes that is just a workaround. The bug is still very much there for me. I tried this mornings version of bugfix, as I saw thinkyhead had committed some fixes yesterday afternoon.

[thierryzoller]

hit g29, then level the bed manually via knobs.

I don't think Manual Bed Leveling is the solution to Automatic Bed Leveling not working properly ? :)

[thestephenmarshall]

I've squared everything away and ensured no skewing or bent rods, ect. Still seeing this issue. Certainly doesn't seem hardware related given the number of folks seeing it. Sadly, most of these issues are closed either bc of inactivity (I don't have all day to learn the inner workings of ABL) or whatever "stale" here means. Everyone reporting seems to be experiencing similar issues.

[txt4nk]

I installed a BLtouch on an ender 3 today that has an SKR E3 dip and 2209's. Before the bltouch, the printer has been printing medical supplies for months straight with hardly any problems (im talking like.. 7 or 8 failed prints out of at least 400). What do ya know.. exact same issue as my ender 5 and everyone else's printer experiencing problems.

[boelle]

whatever "stale" here means.

means that if nothing happens in 30 days a robot will mark it stale and after 5 days it will close it

[thierryzoller]

I'll write a script that pings this issue every 29 days.

Wateveritakes

[boelle]

then maybe @thinkyhead who is running the show will just block you

[thierryzoller]

You understand how ridicule the situation is ? A bug is fixed when code is delivered that fixes the issue. You are forcing us to keep updating this report to have the bug not closed. You understand the fallacy in your logic? Do you?

He is free to ban me, In which case I wont spend any further second on Marlin and move everything to reprap/duett.

[sjasonsmith]

@thierryzoller any actions regarding stale issues are intended to deal with issues which are not actionable for various reasons, and nobody is responsive to provide more information. It’s not intended to simple make real actionable issues go away. It is an evolving process and some mistakes were made that caught up some issues inappropriately.

I acknowledge it probably doesn’t feel like this is getting a lot of attention. With a bunch of volunteers looking at whichever issues they want, either nobody has succeeded in reproducing this or has simply not had time to spend on it.

@boelle should not have threatened you with a ban. He has no power to do such a thing, and does not speak for @thinkyhead (nor do I).

I don’t love the auto-ping script you mentioned, but I’m sure we’ll talk about it again if it becomes an issue.

[txt4nk]

@sjasonsmith thank you for bringing professionalism into this thread, it definitely makes a big difference.

[AnHardt]

As long i see the word "sporadic" in the title i will not have a look into the issue. That sounds like random - not reproducible - unclear cause and effect. I'm quite sure - i'm not alone with that.

[txt4nk]

Wow.. just because it says sporadic you completely ignore it? Lol good to know. I guess I need to start a list of words not to say around here.

[thierryzoller]

As long i see the word "sporadic" in the title i will not have a look into the issue. That sounds like random

You should apply to replace theo on linux - a comment aligned to his demeanor. Maybe you could have looked at the 20+ duplicates of this entry, including mine, it's not sporadic neither. We'll give you bonus points for spending your time to reply what is probaby the least helpfull comment on this issue. Guys I am not sure whether I am just done with Marlin, seeing the arrogance of both moderators and contributors I think I'll move to something else. You'll do without me - I spend 5 hours giving full debug traces for this problem, only to be met with what I can only toxicity.

[txt4nk]

@thierryzoller check out #18598, last post.

[thierryzoller]

Thanks @sjasonsmith for your words, but you miss my point.

I don’t love the auto-ping script you mentioned, but I’m sure we’ll talk about it again if it becomes an issue.

I was rather pointing out the ridiculeness of such an auto-closure approach. What's the difference between a bot adding "." comment to keep this from closing and the bug getting closed without a fix? I think the bot is usefull and helpfull.

Allright, you convinced me, no bot. I will do it manually, you'll tell me the difference? none.

[txt4nk]

alright lets get back on topic here.. In #18598 the OP shared some of the modifications he\she made to their firmware and get some better results. I figured it wouldn't hurt to try it on the Ender 3 I just added ABL to, so here is a list of things I changed and ended up with some great results. @thierryzoller In an effort to see if this us a fluke or a real fix, would you mind trying this? I am going to try this on my Ender 5 in a while (the one I've been fighting for months..)

Configuration.h

define AUTO_BED_LEVELINGBILINEAR Already had this_

//#define MESH_BEDLEVELING Already had this_

define RESTORE_LEVELING_AFTERG28 Already had this_

define GRID_MAX_POINTSX 7 You can stick with 3 or 5 or whatever you've got going on.. I did 7 for a higher resolution_

define Z_SAFEHOMING Already had this_

define HOMING_FEEDRATEXY (50*60) This was the only real change in configuration.h on my end_

Configuration_adv.h

define SLOWDOWNDIVISOR 2 Already had this_

//#define ADAPTIVE_STEPSMOOTHING Already had this_

define BABYSTEP_MULTIPLICATORZ 4 Had this at 1_

EDIT Forgot to add something to configuration.h. comment out multiple probing (//#define MULTIPLE_PROBING)

[AnHardt]

Following Marlin issues nearly continuous on a nearly daily base since over 5 years will drive you mad. You'll need at least some self protection. My way is, reading in Thunderbird, stopwords and ignoring the boelle-bot (who is not following the changes in Marlin enough to beg for retrying 'bugfix') and a few other users. There are still a few hundred messages to scann a day.

[nfons]

As long i see the word "sporadic" in the title i will not have a look into the issue. That sounds like random - not reproducible - unclear cause and effect. I'm quite sure - i'm not alone with that.

sorry this is the most idiotic thing i have seen from a OSS.

even cursory level of english would have indicated that the "sporadic" refers to in-print rather than per-print issue.

Hell even if english is not your strong point, reading the bug description, I have put a ton of efforts with detailed pictures showing reproduced issue via the numerous pictures i have posted

[txt4nk]

welp.. Ender 5 is no better than it was before.. was worth a shot I guess.

[sjasonsmith]

Can we all just stop fighting? If you have something to add to advance toward a resolution, then please do so. Continuing to argue does nothing to encourage people to contribute meaningfully to a resolution.

[Dracrius]

@nfons Please try disabling #define ADAPTIVE_STEP_SMOOTHING It was causing dips of over 1mm in bed level test as I note after a lot of trial and error in #18598. While you bed visualizers dont make it as obvious and I am surprised you are not getting Bltouch alarms with Multi Probing as I did from it catching the errors itself I think it may just be a slight difference in setups.

But I can consistently cause basically 1 in 3 bed levels meshes to show wrong results with a 3x3 grid and single probes or cause failures with 2 just by enabling #define ADAPTIVE_STEP_SMOOTHING. If I disable it and rebuild I have sat and run over 10 bed level meshes in a row with consistent results.

[thierryzoller]

For documentation purposes, the issue that I reported (same) but that was closed without a fix can be found here

17872

Others about ABL not working that were closed but not fixed:

https://github.com/MarlinFirmware/Marlin/issues/17399 https://github.com/MarlinFirmware/Marlin/issues/17587 https://github.com/MarlinFirmware/Marlin/issues/16519 https://github.com/MarlinFirmware/Marlin/issues/16397 https://github.com/MarlinFirmware/Marlin/issues/16380

[txt4nk]

I was reading through all of those as I woke up this morning, and this may have absolutely nothing to do with it but its worth just putting out there.. the majority of people with this issue that I've seen posting are on Ender 5's. I even got my Ender 3 running great yesterday with the tweaks from #18598, but my Ender 5 had ZERO change.

The only real difference I can think of between the two would be that the Ender 5 uses hardware endstops at the max position instead of the min position like the Ender 3. This in turn would make the Ender 5 use soft endstops for the min position. While reading those additional bug reports this morning, @thinkyhead mentioned in one of them that there could be some correlation with soft end stops.

Like I said, it probably has nothing to do with the issue but at this point any thought is worth putting out there.

[Zygriid]

@txt4nk, i am using an ender 3 with sensorless homing, and i am experiencing the same issue.

[txt4nk]

Well it was just a theory, consider it busted lol

[sjasonsmith]

@nfons a change was submitted for HAL/STM32F1 boards (such as your SKR E3 Mini) which fixed inconsistent BLTouch behavior. Can you re-test with bugfix-2.0.x to see whether your probing consistency has improved.

Enabling ADAPTIVE_STEP_SMOOTHING caused the problem to occur more often, but was not actually the root cause. With the fix that went in you should see improve reliability both with or without ADAPTIVE_STEP_SMOOTHING.

For anyone following this issues with a board that does NOT use HAL/STM32F1, those likely require separate fixes. For this purposes of this issue, I would like to consider it resolved if it is fixed for the category of board for which it was originally filed. There are several other open issues tracking BLTouch issues for other HALs.

[nfons]

@sjasonsmith Thanks! Let me try with the new bugfix.

I will try with both ON/OFF and see.

[nfons]

@sjasonsmith I am closing this as the latest BF branch seems to have fixed it:

Most zones are pretty consistent, except for 255,0 (front right corner). which imo is still within reasonable bounds and could be due to mechanical issues with the printer itself (doubt it, but i cannot verify)

I have the settings with ADAPTIVE_STEP_SMOOTHING off.

for anyone else that might wonder in here, my bugfix branch can be found here: https://github.com/nfons/Marlin/tree/ezabl-bugfix (note i switched to the ezabl, but should be the same with BLT)

[txt4nk]

Mine seems to be fixed on the ender 3 as well, have yet to try it on the ender 5. Thanks for identifying and fixing this issue gents, its highly appreciated

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