Possible Bug: Ender 5 Pro, E3D Hemera, SKR Mini E3 V1.2, BLtouch 3.1, ABL not correcting enough or in the right spot?

[txt4nk]

To start off, I've built a few ender 3's with ABL and even had this exact printer up and running beautifully until my first SKR mini E3 decided to start giving the TMC connection error on the X axis. I replaced it with an E3 DIP V1.1 and that is where my issues started. I have my BL touch setup to do 9x9 probing (I normally run 3x3 but since this issue started, I wanted more resolution to see if that would fix it, spoiler alert.. it did not). I've tried the BTT firmware, I've tried vanilla marlin (both the official release and the latest bugfix, as of 2 hours ago). I then got my replacement Mini E3 V1,2 in the mail and decided to put that in the printer in case it was something with the DIP board and I've still got this issue. I have changed the heated bed just in case it was severely warped and I am getting the exact same pattern as the old bed. To take that thought even further, I put the same heat bed on an ender 3 without ABL and I got stellar prints off of it. Either I'm missing something here or there's a bug.

First heat bed:

Second heat bed:

uncommented the following:

define BLTOUCH

define NOZZLE_TO_PROBE_OFFSET { -46, -2, -4.0 } (these have been working for over 6 months before the issue started)

define AUTO_BED_LEVELING_BILINEAR

define RESTORE_LEVELING_AFTER_G28

define GRID_MAX_POINTS_X 9

define Z_SAFE_HOMING

[polgaro]

I'm not an expert here, but the -2 sounds fishy (too small)... mine is -40, -12

If the offset is wrong, then the adjustment is being done in the incorrect point, you can imagine that it would break your print :(

Some other ideas just to try: what happens if you do 4x4 instead of 3x3? does it make it better? if so, your bed may be extra extra warped, but it's fine xD

[txt4nk]

My bltouch sits 46mm to the left of my nozzle and 2mm to the front.. a ton of ABL sensors have a super close Y axis offset. Like I said in my original post, those numbers have worked perfectly in the beginning. I have measured them probably 10 times since this started just to verify. I don't know what your setup is but 12mm to the front sounds like a lot. I've done all the way up to 15x15 grids for extra resolution. Even did 15x15 with 5 probes per point. The prints don't look any better than they did at 3x3 single probe points. If I completely disable the bltouch on this printer, the prints are perfect.

[polgaro]

i'm just trying to help here :) this is my bracket: https://www.thingiverse.com/thing:3584158

questions: Are you using BLTOUCH_HS_MODE?

Can you run M48 and check that the probe is actually working correctly? https://marlinfw.org/docs/gcode/M048.html

I'm asking all this because right now I customized my firmware, but until yesterday I was running the basic bltouch with zhoming bin file with excellent results! (I have an Ender 3 Pro... so...)

If you want i can send you my Configuration.h and Configuration_adv.h...

I can tell it works because one of my springs is kinda dead... so either i raise the bed on that side too much or the bed wobbles A LOT, so my bed in the top left corner is like 2mm raised (yes, 2 whole mm :P) and i just burned the new firmware, ran the G28-G29 and everything working great.

I know that this time i changed a lot more than just the basic configuration (I mean, If i'm going with the trouble of compiling it, at least do it nice, right? So i even did #define MULTIPLE_PROBING 2. Why? I don't really know.

Anyways, what i'm trying to say is that the latest firmware version works for me (well, besides the problem with the platformio.ini) just flashed it today. 5 hours ago.

Let me know if you want my files

[txt4nk]

i'm just trying to help here :) this is my bracket: https://www.thingiverse.com/thing:3584158

questions: Are you using BLTOUCH_HS_MODE?

Can you run M48 and check that the probe is actually working correctly? https://marlinfw.org/docs/gcode/M048.html

I'm asking all this because right now I customized my firmware, but until yesterday I was running the basic bltouch with zhoming bin file with excellent results! (I have an Ender 3 Pro... so...)

If you want i can send you my Configuration.h and Configuration_adv.h...

I can tell it works because one of my springs is kinda dead... so either i raise the bed on that side too much or the bed wobbles A LOT, so my bed in the top left corner is like 2mm raised (yes, 2 whole mm :P) and i just burned the new firmware, ran the G28-G29 and everything working great.

I know that this time i changed a lot more than just the basic configuration (I mean, If i'm going with the trouble of compiling it, at least do it nice, right? So i even did #define MULTIPLE_PROBING 2. Why? I don't really know.

Anyways, what i'm trying to say is that the latest firmware version works for me (well, besides the problem with the platformio.ini) just flashed it today. 5 hours ago.

Let me know if you want my files

Negative, no HS mode right now. Before this issue came up I used to run it all the time but until I get this issue resolved I'm going to stick with slow poke mode lol

I have run M48, my standard deviation is 0.01xxx (not at the office right now so I don't have the exact number in front of me).

I am also concerned that all documentation points to using the RC environment on these boards but I've got an RE processor on my board. If you look at the RE btt environment, it points to additional files for the E3 DIP.

I did some looking in the marlin github tonight and there seems to be quite a few people popping up with the exact problem I am having so I'm a little more at ease knowing it's not just me. This has been driving me nuts. BUT knowing yours works tells me that it is likely something in the differences between the ender 3 and ender 5 settings.

[txt4nk]

Also, here are photos of my hotend and bltouch so you can see the offsets.

[grzybasinski]

Home all axes (G28) and move nozzle somewhere in the middle of the bed then run g-code: M48 P10 V4 and tell me what standard deviation (it will be printed after last measurement) is.

Edit: I see that you have did it. SD around 0.01 is too much for me. Tighten the screw on top as much as you can (I have done that and my SD gone from 0.025 to 0.001 :) Then turn on restore leveling after G28 in config files and remember to save to memory after leveling is done.

[grzybasinski]

I probably know what you are doing wrong. Give me a time to check it on my ender 3 if I am 100% right :)

[txt4nk]

My M48 with 10 probes. My bltouch is mounted without the springs, and the screws are nice and tight.

[grzybasinski]

Ok. I don't want you to wait long, so I will write te answer while testing. Sorry for 3rd message in the row and my bad English, I hope you will understand me :D Also my marlin menu is not in English so there can be mistranslations in my explanation.

I am using skr e3 mini v1.2 on my ender 3 pro with 3dtouch (~ nearly the same as bltouch 3.1). And I fully customized and calibrated it myself with marlin 2.xxx

I think that You (don't be angry on me) and many people using bltouch probing do not know how it actually works. But first of all let's go back in history to explain calibration in marlin firmware.

When you power on your printer, the calibration (Z height correction) always stays OFF. I don't want to describe a lot, but it's caused in compatibility in a short way ;)

To turn on your saved calibration, you must:

1. Home your axises,

2. Go to: Movement -> (and here after G28 command will appear an option) Enable leveling, turn it on, near that, there will be something like -> Height Calibration Fade (?) measured in "Z" == mm. The default value is 0 and it means, that marlin will move your z axis to get perfect layer the whole print up. You can specify the value (for example "5") and then save it to eeprom. It will stop the height movement after this value (so there will be less height difference in final print).

3. Now if you Home home your axes (G28) once more, the leveling in move menu should stay "ON" to the next power cycle (And if you will try to print something, the leveling should activate itself if you uncommented #define RESTORE_LEVELING_AFTER_G28) :)

So what does "#define RESTORE_LEVELING_AFTER_G28" do? It is simply restoring the value of "LEVELING: ON / OFF" before the G28. But because of this value is always off during reboot, you must turn it on after every power cycle :)

If I remember... People are putting G29 (?) command in start g-code (3x3 grid to be faster) before every print to make this option turn on itself (as I remember, the bed leveling turns on after G29, but now I am testing it to make sure my message is 100% correct).

You can tell if your z height is correcting during print by looking at screws on Z-Motor "clutch".

Edit: You deviation and montage is correct. I have also bltouch mounted without springs).

Edit 2 I am printing 200x200mm square with leveling turned on after rebooting, the result is proper first layer. Then I will turn it off and post another picture of the same print. I have corrected the z height using baby stepping.

The problem is mentioned here: https://github.com/MarlinFirmware/Marlin/issues/10726

[txt4nk]

Ok. I don't want you to wait long, so I will write te answer while testing. Sorry for 3rd message in the row and my bad English, I hope you will understand me :D Also my marlin menu is not in English so there can be mistranslations in my explanation.

I am using skr e3 mini v1.2 on my ender 3 pro with 3dtouch (~ nearly the same as bltouch 3.1). And I fully customized and calibrated it myself with marlin 2.xxx

I think that You (don't be angry on me) and many people using bltouch probing do not know how it actually works. But first of all let's go back in history to explain calibration in marlin firmware.

When you power on your printer, the calibration (Z height correction) always stays OFF. I don't want to describe a lot, but it's caused in compatibility in a short way ;)

To turn on your saved calibration, you must:

1. Home your axises,
2. Go to: Movement -> (and here after G28 command will appear an option) Enable leveling, turn it on, near that, there will be something like -> Height Calibration Fade (?) measured in "Z" == mm. The default value is 0 and it means, that marlin will move your z axis to get perfect layer the whole print up. You can specify the value (for example "5") and then save it to eeprom. It will stop the height movement after this value (so there will be less height difference in final print).
3. Now if you Home home your axes (G28) once more, the leveling in move menu should stay "ON" to the next power cycle.

So what does "#define RESTORE_LEVELING_AFTER_G28" do? It is simply restoring the value of "LEVELING: ON / OFF" before the G28. But because of this value is always off during reboot, you must turn it on after every power cycle :)

If I remember... People are putting G29 (?) command in start g-code (3x3 grid to be faster) before every print to make this option turn on itself (as I remember, the bed leveling turns on after G29, but now I am testing it to make sure my message is 100% correct).

You can tell if your z height is correcting during print by looking at screws on Z-Motor "clutch".

Thanks for the reply.

I'm pretty versed in Marlin at this point, I am aware of the state of marlin upon power up and the steps required to get the printer to auto level (auto home, bed level is turned on, etc). I always do an auto home upon printer start up, and all of my prints also run a G28 in the starting gcode.

I uncomment restore level after G28 for the times where I do not find it necessary to run G29 (I've got two printers setup in my slicer, one with G28 then G29 and one with just G28) . If I run the G29 version and the print comes out with great first layer quality I will use the non G29 printer for a while, as there's no need to continuously probe the bed.

My z height is correct, this exact setup was working amazingly for about 6 months and just all of a sudden after my first E3 mini died and I went to a DIP board, this issue has been present. My Z offset has not changed, but I've also mentioned that turning ABL off and printing without it yields great prints.. My z offset is set perfectly on those non ABL prints.

[txt4nk]

I have created firmware for a few people on Ender 3's here in the past couple weeks and I was able to confirm that the firmware I compiled for them is working great. There's got to be a bug in the settings that differ between the ender 3 and ender 5, or a setting that I need to change..

In octoprint I use an add on called bed visualizer. I noticed on the ender 3, it works pretty much right out of the box however for the ender 5, I have to tell it to flip the Y axis as the "home" for the ender 5 is the back right corner of the bed. The ender 3's is the front left side.. I'm wondering if ABL is getting that mixed up as well somehow..

[grzybasinski]

Did you manage to turn it on automaticaly after rebooting in ender 3? If yes, how?

[txt4nk]

I assume you're talking about ABL? No, it requires a G28 before it can be enabled as well.

[grzybasinski]

Exactly. Nobody ob youtube mentions it. I must always home -> activate it, so its annoying :D

[txt4nk]

I've just come to accept that its a necessary step lol I've also made my first steps after a firmware update to manually initialize the eprom and do a power cycle just to get rid of any garbage that may be left behind.

[grzybasinski]

Ok I managed to turn it on automatically after power cycle. Just put: M420 S1 Z10 in starting g code after homing :D Z axis is moving without touching the menu before printing.

[polgaro]

Were you able to fix your problem?

Actually, now i'm having a problem myself hahaha. So, after a few prints I had a print that was actually hard to remove from the bed... long story short, after that, the front left part of the printer is slightly under what it used to... The BLTouch should get rid of that problem and it's NOT doing it.

I shouldn't have to change my Z offset again after I made it work...... I wonder if i'm doing something wrong?

I have G28; G29; in my GCode, but nothing seems to change... What am I missing?

Are you saying that i should do: G28 G29 M420 S1 Z10

???

I thought the M420 was just to load the mesh from the EEPROM?

Thanks!

[txt4nk]

I was not.. I even got to the point where I disassembled the whole hot end, replaced the nozzle, sanded my heat bed perfectly flat.. the abl still has the exact same pattern. M420 is to just recall the mesh, personally I just run G28 then G29. Always have, and its worked great until this issue.

[polgaro]

I'm tempted to get the marlin base code and replace the files that need to be replaced... I'm not sure

[polgaro]

BTW I DO have

define RESTORE_LEVELING_AFTER_G28

[txt4nk]

I do too, I just disabled it as a troubleshooting step. Its back on now.

[polgaro]

I'm trying now with M502 + M500... https://github.com/MarlinFirmware/Marlin/issues/15851

Trying now

[polgaro]

Nope. didn't work...

[txt4nk]

Yeah tried that too.. i still think there is a bug somewhere.

[polgaro]

Send: M420 V Recv: Bilinear Leveling Grid: Recv: 0 1 2 Recv: 0 -0.309 -0.405 -0.476 Recv: 1 +0.056 -0.028 -0.052 Recv: 2 +0.556 +0.455 +0.439 Recv: Recv: echo:Bed Leveling OFF Recv: echo:Fade Height OFF

errrrrr......... bed leveling off?

[polgaro]

Send: M420 S1 Z10 Recv: echo:Bed Leveling ON Recv: echo:Fade Height 10.00 Recv: X:0.00 Y:0.00 Z:0.36 E:0.00 Count X:0 Y:0 Z:5 Recv: ok [...] Send: M420 V Recv: Bilinear Leveling Grid: Recv: 0 1 2 Recv: 0 -0.309 -0.405 -0.476 Recv: 1 +0.056 -0.028 -0.052 Recv: 2 +0.556 +0.455 +0.439 Recv: Recv: echo:Bed Leveling ON Recv: echo:Fade Height 10.00 Recv: ok

Let's try now!

[txt4nk]

I really hope that works

[polgaro]

No, it didn't........... I'll level my bed by hand and go to sleep... I wished the developers would help :'(

[polgaro]

Just to clarify, it did EXACTLY the same on the front left corner where it didn't compensate

[txt4nk]

I got my bed level within .03mm on all 4 corners manually.. non ABL prints look freaking fantastic.. enable ABL and it just goes to shit.

[grzybasinski]

BTW I DO have

define RESTORE_LEVELING_AFTER_G28

Restore leveling is restoring the state of leveling: on / off before homing. I think you should use M500 command just after G29 to let M420 S1 V10 load mesh measured by G29 (not previous one), stored in eeprom.

[polgaro]

After spending an hour, I found that that's not actually the problem hahaha It IS compensating. Just not doing it correctly...

I checked and while it's printing it IS moving the Z slightly when going horizontally. It's just not enough in the left side to compensate. I have no idea why it's doing this. I can keep babystepping until i make the left side work but the right side won't........... anyways! I'm switching to UBL and see how it goes. Wish me luck

[txt4nk]

Yeah mine is moving too, but like I said in the title and like you just said yourself, it seems like its not correcting enough or in the right spot.

[txt4nk]

I'm trying the latest bugfix version right now.. It was updated 14 hours ago.

[txt4nk]

its slightly better.. I'm getting way more movement out of the Z axis, but its still not 100%.. my Z fade was set to 10, i'm going to set it to 100 to see if it changes anything

[grzybasinski]

Moving z fade up to 100 will reduce movement. I have leveled bed pretty well, so my z movement with z height 10 Stops in a half way to that value (it has a low value to compensate)

[txt4nk]

Moving z fade up to 100 will reduce movement. I have leveled bed pretty well, so my z movement with z height 10 Stops in a half way to that value (it has a low value to compensate)

Thanks for this info! I'll set it down to 0 or 1 then. Appreciate the help Jakub

[txt4nk]

set at 0 & 1, both prints failed miserably.. Set at 100, and the print was not good by any means, but it got way further than the 0 and 1 prints.

[txt4nk]

yep.. I was a fool to think that it would magically be fixed.. What next? i'm honestly about to just give up on this.

[txt4nk]

confirmed that this is also happening on a th3d ezboard.

[polgaro]

i set a 5x5 grid and super cleaned the bed. it sticks... i guess i'll take it. This is definitely not ABL though hahaha

[txt4nk]

Im still getting the identical pattern I've been getting the whole time.. i even rotated the bed 90° today to see if the pattern would "follow" it and it did not.

[txt4nk]

Went UBL this morning and did about 20 minutes of manual mesh leveling in the spots I was having issues and I have a near perfect 200x200 first layer. With this, I can go back into my mesh and manually change the few problem area's on the 200x200 print to achieve the perfect first layer. Thanks for nothing, bilinear lol

[txt4nk]

Question for you guys that are having ABL issues too.. I noticed when I auto home my bed, and when I print on the center of my bed, the nozzle is always 10mm below the center of the bed.. I am wondering if that and the ABL not working are related?

[grzybasinski]

You must set the home offsets.

Wysłane z iPhone'a

Wiadomość napisana przez txt4nk notifications@github.com w dniu 02.06.2020, o godz. 17:15:

 Question for you guys that are having ABL issues too.. I noticed when I auto home my bed, and when I print on the center of my bed, the nozzle is always 10mm below the center of the bed.. I am wondering if that and the ABL not working are related?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[txt4nk]

I don't see anything in the marlin code for home offsets.. can you show me the #define code for it?

[txt4nk]

Okay so I ran an M503 and found the home offsets, ran M206 to move the Y 10mm and it did not change. I then made a drastic change (M206 Y50 & also tried M206 Y-50) and the nozzle still homed to the exact same location.

[iammenotyou]

This sounds like it is related to a confirmed bug in Marlin. https://github.com/MarlinFirmware/Marlin/issues/15450. But it would be really nice if a developer would look at this as it is making printing near impossible. Ender3 pro, Skr mini e3, bl touch.

[txt4nk]

I'll check it out tomorrow, I gave up on it recently but ill get it powered up tomorrow to test the latest.

[txt4nk]

Same garbage result using a freshly downloaded bugfix from 2 hours ago. I tried posting on the marlin github and all I got was resistance from dbags that weren't even the developers, and the developers never chimed in. Sad part is, this result is happening on multiple boards, different manufacturers too so its not a SKR issue. Guess I'm just sh!t out of luck