BLTouch levelling broken since 2.0.7.2 Ender 3 Pro SKR Mini E3 V2

[jbbandos]

Bug Description

BLTouch leveling isn't working on 2.0.7.2 (also confirmed on bugfix-2.0.x, see comment below), and it shifts the Z to 5 at the end of the leveling (from the normal 10 - z-offset shown by g28)

Configuration Files

Required: Include a ZIP file containing Configuration.h and Configuration_adv.h.

Marlin-configuration.zip

Steps to Reproduce

1. G29 J1
2. M420 S0 Z0 3, G35 to tram the bed the best possible, repeat until it indicates 0 minute turns only
3. G28
4. G29

Expected behavior:

A leveling grid with differences for the corners falling under 0., z left at 11.73 as set by G28

Actual behavior:

A leveling grid with the back line wrongly raised, all points above 0.160, and Z set at 5. Any attempt to tram the bed based on this grid fails, and the results become worse at every pass. The issue is happening with AUTO_BED_LEVELING_BILINEAR and AUTO_BED_LEVELING_UBL at least.

Additional Information

I did the recommended M502, M500, and M111 S247 before the sequence of G28 and G29. The unfiltered log is done with the "copy all" in octoprint, with all temperature and SD messages, the filtered with a select + copy of the octoprint terminal, with SD and temperature messages fltered out. Unfiltered log.txt filtered log.txt

This is the bed leveling plugin image on marlin 2.0.6.1:

And this on 2.0.7.2, without any moves of the printer, any changes at all except the firmware:

On 2.0.6.1 I was already affected by issue #15450

edit: for some reason I had enabled "Z_AFTER_PROBING 5", please ignore references to z position after probing.

[boelle]

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.

[jbbandos]

I've built it now on a newly checked out bugfix-2.0.x branch. I just copied the config*.h over the existing ones, after checking that the only differences were configuration ones. The result is the same, unfortunately.

Filtered log 2.0.x.txt

[jbbandos]

I did again a G28/G29 after flashing with 2.0.6.1, and got the expected results: Filtered log 2.0.6.1.txt

[takumi-84]

In fact, in Marlin 2.0.7.2 the AUTO_BED_LEVELING_BILINEAR is not working nor the MESH_BED_LEVELING in my case it is a corexy with arduino mega 2560 I do not get the option to calibrate the bed when I choose "AUTO_BED_LEVELING_BILINEAR" in the case of MESH_BED_LEVELING the legend appears only home, it doesn't work for me on the creality cr10s either. resolve

[jernejp21]

In my case, I see that left side of the bed is ok, while right side of the bed is too close. I have tried lowering the bed with the screws to see if this could be the problem - the result is always the same.

[MEGAMENE]

In my case, I see that left side of the bed is ok, while right side of the bed is too close. I have tried lowering the bed with the screws to see if this could be the problem - the result is always the same.

I'm also having this same exact problem, the left and center is good but the right side is too close. And this is with a basically perfect level bed in Bed Visualizer, every corner with less than 0.1 of offset. I've been taking apart my Ender 3 thinking that something is wrong with it, but now I'm not sure.

[jbbandos]

@jernejp21, @MEGAMENE Can you two check if G35 (assisted tramming) still gives reasonable output? I also took apart my ender 3, checked all the cabling to see if it was snagging somewhere or was a bad contact on the bltouch cables, until I decided to go back to the older firmware and then everything worked. But G35 tramming works well for me, and i can get the bet perfectly trammed, it is just G29 / ABL that is badly broken.

[sjasonsmith]

@jbbandos your pictures comparing 2.0.6.1 to 2.0.7 are interesting. Would you be able to help narrow down a date when it started failing, by trying the bugfix branch at some points between those?

[jbbandos]

@sjasonsmith Sure, I just no longer have the exact configurations I used to build 2.0.6.1 (used rsync in the wrong direction while doing a "backup"). But if you want me to test specific versions I can do that. I can start setting up clean clones of 2.0.7.1, etc. down to 2.0.6.1, or do you have specific commits in mind?

[boubounokefalos]

So atm, last working BL Touch release is the 2.0.6.1? (I have the exact same setup and was wondering why my BL Touch is not consistent in leveling)

[sjasonsmith]

@jbbandos no specific commits. It makes sense to do a binary search across the entire commit list to determine when it broke.

Git has a BISECT capability for this, although I’m not sure exactly what workflow people use with that as far as your configurations files go.

When I do this I tend to look at the dates, starting by identifying which month the problem appeared in.

[takumi-84]

in fact the one that works well is the version of Marlin-2.0.6.1. I had to go back to the stable version of Marlin-2.0.6.1!

El lun., 16 nov. 2020 a las 17:10, Jason Smith (notifications@github.com) escribió:

@jbbandos https://github.com/jbbandos no specific commits. It makes sense to do a binary search across the entire commit list to determine when it broke.

Git has a BISECT capability for this, although I’m not sure exactly what workflow people use with that as far as your configurations files go.

When I do this I tend to look at the dates, starting by identifying which month the problem appeared in.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/20105#issuecomment-728296972, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARYQ3XKZSQQXQWRKO7XY5ATSQGBLXANCNFSM4TSII4QQ .

[jbbandos]

@takumi-84 was right, I had the same issues with 2.0.7.0: //action:notification Ender 3 Pro Ready. echo:busy: processing Bilinear Leveling Grid: 0 1 2 3 4 0 +0.205 +0.198 +0.206 +0.214 +0.203 1 +0.242 +0.231 +0.224 +0.217 +0.194 2 +0.347 +0.340 +0.344 +0.356 +0.359 3 +0.510 +0.454 +0.383 +0.402 +0.363 4 +0.519 +0.522 +0.533 +0.557 +0.543

echo:busy: processing X:227.00 Y:195.00 Z:5.00 E:0.00 Count X:18187 Y:15662 Z:2216 ok P31 B31

[sjasonsmith]

I plan to work on this next week. If anybody can help identify dates between those two versions which still work properly that would be a great help. The best scenario would be a single commit ID where the behavior changed.

Leveling issues are often hard to debug, because it is hard to separate mechanical issues from software issues in reports. If we have an exact configuration that works on one commit and not on the next, then we will be in a really good position to resolve the issue.

[jbbandos]

Ok, I'll do my best to keep testing the commits between 2.0.6.1 and 2.0.7.0. At least on my ender 3 pro / skr mini e3 v2 it is reproducible. On the CR10V3 I don't have this issue, so it is also probably hardware related.

[bvrielink]

Got the same problem on an Ender 5 Pro also with a SKR Mini E3 2.0 board. Don't know exactly when it started but at least firmware version 2.0.7.0 and 2.0.7.2 has this problem for me. Can do some tests next week if needed. Printer is getting some upgrades so is not working atm.

[sjasonsmith]

@bvrielink please post your configuration files if you are seeing this precise problem. Having configs from a few affected uses may help identify common themes.

[anesuccio]

I am affected as well with this problem. I see the same "tilting effect". Not sure if it works fine flashing 2.0.6.1, I couldn't do it now.

Hardware & Firmware

Ender 3 SKR mini E3 v2.0 BLTouch v3.1 Marlin 2.0-bugfix downloaded 8th November 2020. Unified bed leveling enabled.

Configuration files

Configuration.zip

Steps to reproduce (including EEPROM reset)

M502 M500 M190 S50

G28 G29 P1 G29 P3

G29 S0 G29 F 20.0 G29 A M500

(Mesh validation results in optimal first layer.)

G29 L0 G29 J2 -- Here the mesh breaks

Mesh topographies (G29 T)

Before breaking

Bed Topography Report:
    ( 20,215)                                                              (215,215)
        0       1       2       3       4       5       6       7       8       9
 9 | +0.222  +0.183  +0.187  +0.163  +0.153  +0.108  +0.130  +0.130  +0.110  +0.110
   |
 8 | +0.113  +0.102  +0.097  +0.100  +0.082  +0.070  +0.087  +0.090  +0.113  +0.135
   |
 7 | +0.113  +0.095  +0.082  +0.077  +0.070  +0.058  +0.067  +0.075  +0.080  +0.085
   |
 6 | +0.165  +0.120  +0.092  +0.075  +0.062  +0.025  +0.043  +0.048  +0.045  +0.045
   |
 5 | +0.158  +0.077  +0.050  +0.040  +0.030  -0.007  +0.015  +0.033  +0.035  +0.037
   |
 4 | +0.125  +0.065  +0.045  +0.053 [+0.035] +0.028  +0.023  +0.048  +0.062  +0.077
   |
 3 | +0.173  +0.118  +0.072  +0.062  +0.023  +0.005  +0.030  +0.048  +0.043  +0.043
   |
 2 | +0.160  +0.100  +0.072  +0.065  +0.030  +0.010  +0.033  +0.035  +0.033  +0.033
   |
 1 | +0.082  +0.075  +0.050  +0.043  +0.043  +0.040  +0.060  +0.080  +0.097  +0.115
   |
 0 | +0.143  +0.095  +0.067  +0.053  +0.040  +0.055  +0.075  +0.085  +0.087  +0.090
        0       1       2       3       4       5       6       7       8       9
    ( 20, 20)                                                              (215, 20)

After breaking

Bed Topography Report:
    ( 20,215)                                                              (215,215)
        0       1       2       3       4       5       6       7       8       9
 9 | -2.047  -1.828  -1.563  -1.329  -1.079  -0.865  -0.582  -0.323  -0.083  +0.176
   |
 8 | -2.161  -1.912  -1.657  -1.395  -1.153  -0.906  -0.629  -0.367  -0.084  +0.198
   |
 7 | -2.165  -1.923  -1.676  -1.421  -1.169  -0.922  -0.652  -0.385  -0.121  +0.144
   |
 6 | -2.116  -1.901  -1.669  -1.427  -1.180  -0.958  -0.681  -0.416  -0.159  +0.100
   |
 5 | -2.127  -1.948  -1.715  -1.466  -1.216  -0.994  -0.712  -0.435  -0.173  +0.089
   |
 4 | -2.163  -1.964  -1.724  -1.457  -1.215  -0.963  -0.708  -0.424  -0.149  +0.125
   |
 3 | -2.119  -1.915  -1.700  -1.451  -1.231  -0.989  -0.705  -0.427  -0.173  +0.087
   |
 2 | -2.136  -1.936  -1.704  -1.452  -1.227  -0.988  -0.706  -0.444  -0.187  +0.073
   |
 1 | -2.217  -1.965  -1.730  -1.478  -1.219  -0.961  -0.682  -0.402  -0.125  +0.152
   |
 0 | -2.161  -1.948  -1.716  -1.472  -1.225  -0.950  -0.671  -0.401 [-0.139] +0.123
        0       1       2       3       4       5       6       7       8       9
    ( 20, 20)                                                              (215, 20)

Additional info

Repeating G29 J2 adds the same constant increment to each point in the mesh, different from point to point.

I have set the probe offset (-1.43mm) correctly before leveling. I use the probe as the Z-endstop.

[sjasonsmith]

@anesuccio which versions and/or commits were those "breaking" and "non-breaking" versions using?

[anesuccio]

The same 2.0.7.2 version. String distribution date 2020-07-09. Version.h.zip

Breaking and non-breaking are referred to the steps to reproduce.

[sjasonsmith]

@anesuccio does it break if you use G29 J (without the 2)? This is just a thought, since an ideal plane can be formed from 3 points (the default), but requires approximation for the 3 points I would expect J2 to probe.

I realize I am asking a lot of questions. I'm just trying to get the best understanding I can of where people are encountering these issues. I am hoping to replicate the test platform exactly so that I can debug with the exact configuration files people are posting here.

[Vertabreak]

My only question is why is G29 J being used at all this is the tilt feature that would only come in to play if you have bed knobs and someone decided to play with them after creating a mesh to compensate rather then rerunning G29 P1.

[beepee123]

This seems related to an issue I am experiencing. Using a Nov 13 pull of bugfix-2.0.x on a SKR mini E3 2.0.

Using a servo+microswitch ABL, it seems I cannot get bilinear ABL to function correctly. I went back to my Creality Melzi board and things work fine. Completely re-aligned gantry, cleaned and realigned z-screw, realigned bed with spirit level and calipers, taped up bed adjustment screws to prevent movement, checked all eccentric wheel adjustments, re-checked belts... I even re-printed my ABL microswitch arm in case it had gotten bent, all to no avail. Then this happened:

1. Rebuilt and reflashed above bugfix-2.0.x with dialed in z-probe offset and working settings from 1.1.9.1+bugfix build on melzi board.
2. Booted up, ran M502, M500, warmed up bed and performed G29 bilinear (3 slow probes with EXTRA_PROBING)
3. Saved with M500, ran M420 S1 Z3, and printed a 1-layer leveling test
4. Leveling test would only adhere to rear of bed, used Z-babysteps to correct until I got good adhesion
5. Completed print, cleaned bed, corrected Z-probe offset with z-babystepping settings, cleared babystepping
6. Ran G28 XYZ using LCD, then manually moved nozzle to X,Y of Z-homing location
7. Manually moved Z to 0.0 and found that I could easily slide paper under nozzle without even touching it!
8. Went to LCD configuration, reduced Z-probe offset, saved, then went back to step 6

No matter how many times or how far down I dialed the z-probe offset (repeating steps 6-8), the nozzle Z0.0 location never moved. I even verified that the Z-probe offset was being saved correctly in the serial console using M503. No amount of change made a difference, I even dialed it 1mm just to check.

Hope this info helps somehow - rolling back to 2.0.6.1 for now.

[bvrielink]

@sjasonsmith Here are my config files: config.zip

[anesuccio]

@anesuccio does it break if you use G29 J (without the 2)? This is just a thought, since an ideal plane can be formed from 3 points (the default), but requires approximation for the 3 points I would expect J2 to probe.

I realize I am asking a lot of questions. I'm just trying to get the best understanding I can of where people are encountering these issues. I am hoping to replicate the test platform exactly so that I can debug with the exact configuration files people are posting here.

Yes, it does break after G29 J without setting the number of points. Here is the mesh after that command. I'm observing a similar unexpected "tilt" (printer was not touched and i can see way too high increments).

Bed Topography Report:
    ( 20,215)                                                              (215,215)
        0       1       2       3       4       5       6       7       8       9
 9 | -0.929  -0.704  -0.434  -0.194 [+0.061] +0.281  +0.569  +0.834  +1.079  +1.344
   |
 8 | -1.174  -0.919  -0.659  -0.391  -0.144  +0.109  +0.392  +0.659  +0.947  +1.234
   |
 7 | -1.309  -1.061  -0.809  -0.548  -0.291  -0.038  +0.237  +0.509  +0.779  +1.050
   |
 6 | -1.391  -1.171  -0.933  -0.686  -0.433  -0.206  +0.077  +0.347  +0.610  +0.875
   |
 5 | -1.533  -1.348  -1.111  -0.856  -0.601  -0.373  -0.085  +0.197  +0.465  +0.732
   |
 4 | -1.701  -1.496  -1.251  -0.978  -0.730  -0.473  -0.213  +0.077  +0.357  +0.638
   |
 3 | -1.788  -1.578  -1.358  -1.103  -0.878  -0.630  -0.340  -0.058  +0.203  +0.468
   |
 2 | -1.936  -1.730  -1.493  -1.235  -1.005  -0.760  -0.472  -0.205  +0.058  +0.323
   |
 1 | -2.148  -1.890  -1.650  -1.393  -1.127  -0.865  -0.580  -0.295  -0.012  +0.270
   |
 0 | -2.223  -2.005  -1.768  -1.517  -1.265  -0.985  -0.700  -0.425  -0.157  +0.111
        0       1       2       3       4       5       6       7       8       9
    ( 20, 20)                                                              (215, 20)

My only question is why is G29 J being used at all this is the tilt feature that would only come in to play if you have bed knobs and someone decided to play with them after creating a mesh to compensate rather then rerunning G29 P1.

I use this because I print very fine layers (0.06mm) and using the same glass bed (not something magnetic I can take off for detaching printed objects). So I tilt the bed slightly every time I remove printed objects from the bed.

[jbbandos]

My apologies to everyone, I made a huge mistake - I didn't recompile 2.0.6.1 with my current configurations, but instead was comparing to a version I had compiled and lost the configurations. And what I found is that when I compile 2.0.6.1 with my current configurations, I get the same issue (fake lift and distortion of the back of the bed) as with the versions after that one. I used a copy of the old configuration files that was likely to be close to the one I used to compile 2.0.6.1 once, and checked the differences to try to find the issue - and while I have yet to identify the main culprit, I found that disabling CLASSIC_JERK doubles the error range from 0.5 to 1.x This is on 2.0.6.1 with my configs as attached to comment 1, only adjusted for the differences between 2.0.7.2 and 2.0.6.1: Bilinear Leveling Grid: 0 1 2 3 4 0 +0.062 +0.054 +0.067 +0.084 +0.068 1 +0.355 +0.219 +0.212 +0.190 +0.059 2 +0.347 +0.350 +0.366 +0.450 +0.500 3 +0.821 +0.759 +0.679 +0.636 +0.518 4 +0.906 +0.976 +1.005 +1.041 +1.095

Now, just with CLASSIC_JERK enabled: Bilinear Leveling Grid: 0 1 2 3 4 0 +0.185 +0.180 +0.187 +0.200 +0.173 1 +0.285 +0.206 +0.206 +0.201 +0.161 2 +0.324 +0.318 +0.326 +0.338 +0.330 3 +0.424 +0.360 +0.359 +0.373 +0.328 4 +0.481 +0.490 +0.502 +0.525 +0.499

I am still investigating what is configuration point that triggers the issue, but all the others here, can you please check if you had different configurations in 2.0.6.1?

[jbbandos]

After about half a dozen of tests and builds, I identified HOMING_FEEDRATE_Z as the configuration that breaks ABL for me. If I leave it at the default (460), ABL works. Changed to (660) as I had, and ABL gives the strange values. My apologies to the developers, I should have rebuilt 2.0.6.1 to start with.

[hamster65]

I have got #define HOMING_FEEDRATE_Z (4*60) which is Marlin's default, I believe. Maybe something is off with the timing during leveling so that higher speeds cause these issues. Linear levelling seems to work, but bilinear gives an uneven and slightly tilted bed.

[jbbandos]

I've done a few more builds, and the only consistent trigger for the ABL errors I was seeing is changing HOMING_FEEDRATE, at least from 2.0.6.1 to 2.0.7.2. Disabling CLASSIC_JERK exacerbates the issues for me at least in 2.0.6.1, I didn't compare with it on or off. My configurations for 2.0.7.2 are here, and I am now trying to use the exact same settings adjusted to the difference for versions in bugfix-2.0.x. Can any of you compare your configurations with mine and see if there is a specific change that triggers the ABL errors in your case? Marlin configs.zip

I am still seeing issue 15450, and I wonder if that is what you are getting now.

[anesuccio]

I've got also the default HOMING_FEEDRATE_Z (4*60), with UBL activated.

I tried also to change with G1 X Y the initial probing position for G29 J2. The mesh always breaks.

I have also two requests:

• Can I use the same configuration.h and configuration_adv.h files for older version of Marlin to find the breaking-version?
• What configuration parameters affect the calculations of the bed tilt done by G29 J or G29J#?

I'll repost my slightly changed configuration files. Configuration Anesuccio.zip

[jbbandos]

I have also two requests:

• Can I use the same configuration.h and configuration_adv.h files for older version of Marlin to find the breaking-version?

What I do is usually check out the branch I want with visual studio code, then copy the configuration.h and conguration_adv.h to the folder. The I use the open changes option (right click menu on file in the git tab) to check the changes one by one and only accept those that are configuration enabling, disabling, values, etc.

[jbbandos]

bugfix-2.0.x branch and I have ABL BILINEAR apparently working. Logs and configs included: Marlin bugfix-20.0x configs.zip Filtered log bugfix-2.0.x.txt With debug: Bilinear Leveling Grid: 0 1 2 3 4 0 +0.037 +0.055 +0.055 +0.070 +0.073 1 +0.045 +0.046 +0.061 +0.062 +0.060 2 +0.035 +0.029 +0.047 +0.059 +0.056 3 +0.051 +0.042 +0.047 +0.065 +0.060 4 +0.023 +0.044 +0.061 +0.087 +0.093

G29 uncorrected Z:11.73 corrected Z:11.65 current_position= X227.00 Y195.00 Z11.65 : sync_plan_position

Without debug: Bilinear Leveling Grid: 0 1 2 3 4 0 +0.051 +0.049 +0.059 +0.076 +0.070 1 +0.051 +0.053 +0.065 +0.071 +0.066 2 +0.030 +0.030 +0.043 +0.060 +0.066 3 +0.036 +0.049 +0.061 +0.089 +0.070 4 +0.029 +0.043 +0.068 +0.095 +0.087

X:227.00 Y:195.00 Z:11.65 E:0.00 Count X:18187 Y:15662 Z:4735 @anesuccio - can you test building with my configs and see if it works for you?

[anesuccio]

@jbbandos Sure. I have to adapt them because I'm using an Ender 3, not Pro. I think to test tomorrow morning.

[anesuccio]

Still not working for me.

[sassahoc]

I have a ender 3 v1 that i got in march of 2019. I just upgraded to skr mini v2 and a bl touch 3.1 and i updated the firmware to the fimware-bltouch.bin with marlin 2.0.7.2 and my bltouch keeps disconnecting randomly. sometimes i can get half way through a bedd level but most of the times when i turn the printer on it says, unable to enable bed leveling. I have the bl touch plugged in properly and i have tried re downloading and reflashing the software. I do not know how to modify config files. is there a older version of marlin with bltouch that i can download somewhere that will work for the skr mini v2?

Thanks

[tomich]

I can reproduce @jbbandos issue. Using BIQU B1, that comes with an SKR 1.4 board.

I didn't report previously because I'm using a BLTouch clone so I was assuming the issue was there, but can confirm it works with older versions. Is there any test or info I can help with?

[anesuccio]

I do not know if the bug is related to the usage of BLTouch (eventually clones) or to the specific dimension settings of the print area.

For example I have uneven margins due to binder clips on my bed.

There follow my configuration changes which I think may have an impact on UBL tilt calculation:

Configuration.h

• USE_PROBE_FOR_Z_HOMING -- default: Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
• X_MAX_POS X_BED_SIZE + 10 -- default: X_MAX_POS X_BED_SIZE
• RESTORE_LEVELING_AFTER_G28 -- default: commented
• MESH_INSET 20 -- default: MESH_INSET 1
• Z_SAFE_HOMING -- default: commented (but BLTouch needs that)

Configuration_adv.h

• PROBING_MARGIN_FRONT 20 -- default: commented PROBING_MARGIN_FRONT PROBING_MARGIN
• PROBING_MARGIN_BACK 20 -- default: commented PROBING_MARGIN_BACK PROBING_MARGIN

[tarsonis123]

Same here. Creality 4.2.7. This marlin UBL makes me want to throw this printer out of the window. Spend 8 hours since yesterday and not possible to get a level. "insert a lot of bad words here" New to the release from yesterday. Mesh edit keeps the Z at default height 5 and doesn't lower the nozzle anymore after confirming to edit the point..... But this another bug. Nightmare. Should have never changed the one firmware that I forgot which worked....

[tarsonis123]

I have also two requests:

• Can I use the same configuration.h and configuration_adv.h files for older version of Marlin to find the breaking-version?

What I do is usually check out the branch I want with visual studio code, then copy the configuration.h and conguration_adv.h to the folder. The I use the open changes option (right click menu on file in the git tab) to check the changes one by one and only accept those that are configuration enabling, disabling, values, etc.

Could you elaborate this more? Which folder do you copy them? Open changes option in VS is missing when I right click a file. I was doing it like this before. Rename old config to "_alt", copy them into the marlin folder, select for compare and then compare with selected. If there is an easier way I'm happy to hear that

[sjasonsmith]

@jbbandos I have spent many hours yesterday trying to reproduce problems with AUTO_BED_LEVELING_BILINEAR on various boards. This has included both an SKR Mini E3 V2 as well as a Creality 4.2.7 board. I am using current bugfix-2.0.x as of the time of this comment.

I am not seeing any issues like this at all. All of my BLTouch probing has worked flawlessly, and I have been able to print well using the generated meshes.

You commented a few days ago:

have ABL BILINEAR apparently working

Does this problem seem resolved for you?

[jbbandos]

@sjasonsmith I stopped seeing the issue when I removed the change to HOMING_FEEDRATE_Z (which I had copied from my CR-10 configuration). The only issue I have now appears to be #15450. I will do a new build of bugfix-2.0.x to test again after I finish the current print (13 hours to go still).

[tarsonis123]

@jbbandos I have spent many hours yesterday trying to reproduce problems with AUTO_BED_LEVELING_BILINEAR on various boards. This has included both an SKR Mini E3 V2 as well as a Creality 4.2.7 board. I am using current bugfix-2.0.x as of the time of this comment.

Yes sure works like intended I guess?

Oh and I spent weeks to rule out any mechanic problems as I thought the UBL must be fine but every release a new issue and one is running in circles. The Z height goes haywire after every G29, ABL not used if one not uses dozens of commands in the Gcode to force it, correction mesh is inverted for some, correction differs one layer height after G29 next to another, Probe commands get renamed every week... In my opinion this hole ABL should be build up new from the ground with 1 manual mesh leveling and 1 auto bed leveling. This no wonder nobody has a clue anymore with 5 different ABL essentially doing the same but none of it right. It a bugfix version so ok, but if the stable version is a mess like that then there is reason to complain. I won't add any more proof as there plenty of them mostly in closed issues.

[sjasonsmith]

@tarsonis123 one of the problems with leveling issues is that as soon as one is reported, people tend to pile many other issues into the same report. What starts as one manageable issue becomes confused with every leveling system on every board with every mechanical defect. It is for this reason that leveling issues so often go ignored.

I am not claiming everything is perfect. I guarantee you it is not. I can also guarantee you that I have given my best effort to reproduce these reported issues, including rebuilding my hardware to match the reporter's machines, so that I can use their exact configurations.

I can't pursue every claim in every comment. If the OP's issue is resolved or seems to be a mechanical issue, then anything else should be reported in a new issue. If you can come up with a way to reliably reproduce problems such that the failures will occur on another machine running the same hardware with the same configuration, then great! We will pursue it then and address it.

[sjasonsmith]

I stopped seeing the issue when I removed the change to HOMING_FEEDRATE_Z (which I had copied from my CR-10 configuration).

I will do a new build of bugfix-2.0.x to test again after I finish the current print (13 hours to go still).

@jbbandos it is reasonable that increasing the homing speed decreases probing accuracy. It is strange that it would appear as a consistent pattern, unless there is an acceleration issue causing steps to be skipped during the process.

The only issue I have now appears to be #15450.

I also spent several hours trying to reproduce the issue from that report, without success. It has now been closed and locked, as it was one of those issues which sat too long and ended up with a huge variety of issues within the comments. Please read my last post on that issue, and re-test with bugfix-2.0.x. If you still have issues please open a new issue with the very specific behavior you are seeing and steps to reproduce. We will then make every effort to keep the issue focused on that one issue and not allow it to diverge from that again.

Please let me know how your testing goes.

[sjasonsmith]

@jbbandos have you had a chance to come back and try the latest bugfix code to see if you are still having issues.

[jbbandos]

@sjasonsmith , I am using bugfix and have not seen this issue as long as I don't change HOMING_FEEDRATE_Z.

I am still trying to find the exact conditions that trigger what I thought was issue #15450, where my z-offset seems to be "interpreted differently" at times. What I am seeing with that is not the leveling grid changing, but instead the nozzle distance to the bed being different in different prints even if it is the same in the settings. I am still trying to identify how and when that happens, but appears to be power cycle related.

[holocronology]

I would be happy to join in on this topic. I recently added BLTouch v3.1 to my Ender 3 Pro and SKR Mini E3 v2.0 board. Through the course of process, that I ended up using the bigfix-2.0-x firmware. I am running the BLTouch through the z-probe port on the SKR board and have disconnected the stock Z-Endstop.

Using BiLinear ABL. Probing and mesh generation seems to work A-OK. The issue that I'm seeing is most noticeable when printing a skirt around a print, where part of the skirt is clearly being printed too close to the bed and the rest is seemingly ok.

The only other alternative that I can think of is that I did turn on feature to use the z-probe to level the corners. This functions by going to each order and then will tell me to raise/lower until it's within tolerances.

Happy to provide any other data that I can.

[sjasonsmith]

@holocronology, please be sure you have EXTRAPOLATE_BEYOND_GRID enabled.

[holocronology]

@sjasonsmith Yes EXTRAPOLATE_BEYOND_GRID is enabled. Currently on Bugfix-2.0.X that I downloaded on 6-December 7:40am CST.

Here is my config.h and config_adv.h for reference.

[tarsonis123]

I would be happy to join in on this topic. I recently added BLTouch v3.1 to my Ender 3 Pro and SKR Mini E3 v2.0 board. Through the course of process, that I ended up using the bigfix-2.0-x firmware. I am running the BLTouch through the z-probe port on the SKR board and have disconnected the stock Z-Endstop.

Using BiLinear ABL. Probing and mesh generation seems to work A-OK. The issue that I'm seeing is most noticeable when printing a skirt around a print, where part of the skirt is clearly being printed too close to the bed and the rest is seemingly ok.

The only other alternative that I can think of is that I did turn on feature to use the z-probe to level the corners. This functions by going to each order and then will tell me to raise/lower until it's within tolerances.

Happy to provide any other data that I can.

Exactly the same issue I see here on my device with nearly exactly the same equipment (just BLTouch clone - deviation 0.003). I ordered an original BL yesterday which should arrive tomorrow. This should get the clone/original argument out of the equation. I try to report.

On this issue another miracle happened to me yesterday. I did a enormous amount of probing and protocolling yesterday. Ended up probing the heat surface and making it nearly flat (dip in the center) with a piece of aluminum foil. Glass bed over it and probing. I ended up with result that had a deviation from center to outer corner by 0.08. It was better with the glass bed as it was cold. Probe offset was a mild friction with a 0.1 paper. Anyway I started a project print with a fade height of 0.6. Right after the start the skirt was too squished so I ended up adding 0.1 through babystepping (not probe z babysteps) which already made me suspicious. I canceled the print after 5 layers since I had to add offset to every of the 5 layers and not seeing the babysteps I already done nowhere in the interface (why the hell does it reset to 0 after confirm in a running print?? )

So I thought it would be nice to update the made babysteps to the probe offset which I've done by 0.1. Did homing and verified it with the paper. Restarted the same gcode file. What's happing. The nozzle is to high and big constant gaps between the lines. I needed to revert the 0.1 offset with the babysteps! Photo below. Mathematically this is nonsense. So I canceled the print and revert to the old offset and did babysteps again for the final one. What else I did see was that changing the offset for layer one to ideal condition seemed to be destroyed by the bed Leveling on the next layer. I modelled a knob for the Z rod with an cross on it so its easy to see when the bed leveling kicks in.

Same offset value. Left thought probe offset - Right through Babysteps. In between those two results was one G28 in the start code