search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.17k stars 19.21k forks source link

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

Closed ghost closed 2 years ago

ghost commented 2 years ago

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

Yes, and the problem still exists.

Bug Description

I will first document the setup:

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:

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 commented 2 years ago

Sounds similar to these issues #23835

Arakon commented 2 years ago

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 commented 2 years ago

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

ghost commented 2 years ago

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 commented 2 years ago

Also similar to #22322

descipher commented 2 years ago

No config posted .. make sure BABYSTEP_ZPROBE_OFFSET is enabled.

ghost commented 2 years ago

No config posted .. make sure BABYSTEP_ZPROBE_OFFSET is enabled.

It is. See attached.

Configuration.zip

descipher commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

Testing now with the suggested changes.

ghost commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

github-actions[bot] commented 2 years ago

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[bot] commented 2 years ago

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.