[BUG] Inconsistent leveling with UBL + BLTouch (SKR MINI E3 V3.0, Ender 3 Pro)

[ghost]

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

Yes, and the problem still exists.

Bug Description

I will first document the setup:

• Ender 3 Pro fitted with SKR MINI E3 V3.0/
• BLTouch using 3+2 PIN configuration, 2 pin for Z ENDSTOP, the rest to the probe pin header.
• No hot end mods and no linear rails, standard factory mechanics.
• Z lead screw is fine.
• Manual leveling produces perfect first layer across all bed corners using a patch STL (can provide the file).
• Sources match git master, with board config applied. Can provide the files.
• Upgraded springs, properly adjusted, no play observed. Wheels are also stable.
• Z probe offsets: #define NOZZLE_TO_PROBE_OFFSET { -41, -10, -2.4225 } (Z offset varies)
• MESH_INSET set to 20.

Probe accuracy test:

>>> M48 P4 V2
SENDING:M48 P4 V2
M48 Z-Probe Repeatability Test
//action:notification M48 Point: 1/4
1 of 4: z: -0.002
//action:notification M48 Point: 2/4
2 of 4: z: -0.004
//action:notification M48 Point: 3/4
3 of 4: z: 0.001
//action:notification M48 Point: 4/4
4 of 4: z: 0.003
Finished!
Mean: -0.000618 Min: -0.004 Max: 0.003 Range: 0.006
Standard Deviation: 0.002577
//action:notification Deviation: 0.002577
ok P31 B25

The problems I have experienced:

1. After leveling the bed manually (tramming), I can get a perfect first layer print. Let's say the Z probe offset was adjusted to -02.101 using the wizard.
2. Creating a mesh with G29 P1 and SmartFill for the right side (the only points it fails to measure) produces a valid mesh.
3. Printing the same patches produces a visibly different result, squish is not good, seems like it corrected the Z higher than it should.
4. Unrelated but worth noting: JSON enabled in the build for G29 T Output, I used the hidden ifdef option... I can't trigger it, so I couldn't produce a plot of the bed. Not using octoprint and not interested in setting it up right now. Seems like some change made that a NO-OP and it is non functional currently. A pity.

Mesh that produced the results:

>>> G29 t
SENDING:G29 T
//action:notification Doing G29
Bed Topography Report:
    ( 20,215)                                      (215,215)
        0       1       2       3       4       5       6
 6 | -0.160  -0.134  -0.124  -0.093  -0.090  -0.078  -0.065
   |
 5 | -0.088  -0.043  -0.063  -0.049  -0.074  -0.083  -0.083
   |
 4 | -0.065  -0.010  -0.321  -0.020  -0.214  -0.052  +0.111
   |
 3 | +0.005  +0.032  +0.015 [-0.055] -0.033  -0.055  -0.055
   |
 2 | +0.008  -0.014  +0.013  +0.012  -0.014  -0.034  -0.034
   |
 1 | +0.021  +0.042  +0.019  +0.007  -0.036  -0.073  -0.073
   |
 0 | +0.006  +0.017  +0.002  -0.019  -0.043  -0.114  -0.115
        0       1       2       3       4       5       6
    ( 20, 20)                                      (215, 20)
//action:notification Ender-3 Pro Ready.
ok P31 B30

The bed doesn't seem warped to any noticeable extent, I actually checked with a calibrated angle and mechanics ruler, and it is within tolerances.

My observations:

• G29 J4 threw the mesh off tolerances.
• I am getting very inconsistent Z probe and Z baseline numbers. It almost seems like my Z moves around. I can't claim there is no mechanical issue but I certainly haven't found any. I'm using the same steps I used successfully before and, when I dialed the manual leveling it was perfect. (can provide photos).

I did not experience these variations when using ABL with a 9x9 grid.

Bug Timeline

No response

Expected behavior

No response

Actual behavior

No response

Steps to Reproduce

No response

Version of Marlin Firmware

git master

Printer model

Ender 3 Pro

Electronics

SKR MINI E3 V3.0

Add-ons

BLTouch

Bed Leveling

UBL Bilinear mesh

Your Slicer

Cura

Host Software

Pronterface

Additional information & file uploads

No response

[FrankHovis]

Sounds similar to these issues #23835

[Arakon]

Do you have ENDSTOP_INTERRUPTS_FEATURE enabled and ADAPTIVE_STEP_SMOOTHING disabled? The CPU used on the board is slower than on previous Mini E3s and runs into severe trouble with a bltouch if too many CPU intense features are active.

See i.e. #23655

[ghost]

ENDSTOP_INTERRUPTS_FEATURE and ADAPTIVE_STEP_SMOOTHING enabled. Tested also software mode for the BLT but that marginally helped.

[ghost]

Seems like we have two angles to this: one is to consider the feature incompatible, the other is to optimize it. I recall ADAPTIVE_STEP_SMOOTHING is mostly useful for high speed configurations, since all it does is attempt to reduce vibrations, right? A mechanically sound and well maintained printer at <60mm/s speeds shouldn't see a difference from it.

Oh, and thank you for the ref, damned BTT and bullsh*t marketing... they downgraded the MCU.

[GJSchaller]

Also similar to #22322

[descipher]

No config posted .. make sure BABYSTEP_ZPROBE_OFFSET is enabled.

[ghost]

No config posted .. make sure BABYSTEP_ZPROBE_OFFSET is enabled.

It is. See attached.

Configuration.zip

[descipher]

Question:
What is the actual z offset value when measured while the probe is deployed?
Are you using the offset wizard?

#define NOZZLE_TO_PROBE_OFFSET { -41, -10, 0 }

[descipher]

This should be 10 to make sure the wizard calculates correctly.
#define Z_HOMING_HEIGHT 4 // (mm) Minimal Z height before homing (G28) for Z clearance above the bed, clamps
This also conflicts with
#define Z_CLEARANCE_DEPLOY_PROBE 5 // Z Clearance for Deploy/Stow

I would recommend you use the default config values and retest it.

[ghost]

Testing now with the suggested changes.

[ghost]

@descipher Apologies for the delay.

These are the current settings, I'm in the process of verifying and cancelling my previous mesh:

>>> M851
SENDING:M851
  M851 X-41.0000 Y-10.0000 Z-2.3963 ; (mm)
ok P31 B31

Attaching revised configuration.
Configuration.zip

Regarding the Z offset, I used the wizard but fine tuned with a calibrated gauge, from 0.4 to 0.1mm. I also used the same process for tramming and I can basically print near 100% perfect first layers across most of the bed without UBL, except for some spots on the right upper side.

Pronterface is having a few burps:
Can't read from printer (disconnected?) (SerialException): device reports readiness to read but returned no data (device disconnected or multiple access on port?)

[descipher]

Pronterface can be temperamental, however that could also be noise related. Grounding is critical, frame & PSU should ground to the AC mains ground return path.

[ghost]

Pronterface can be temperamental, however that could also be noise related. Grounding is critical, frame & PSU should ground to the AC mains ground return path.

Hamradio operator here, grounding should be good and there is a filtered power strip + actual line filter up to 20A installed on the supply line. I will however retest and comment here if I find anything spurious.

[thinkyhead]

If Pronterface is acting up, especially with UBL, it might help to enable the SERIAL_OVERRUN_PROTECTION option.

[github-actions]

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

[github-actions]

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.