[BUG] BLTouch Fails Probing Bed running Marlin 2.0.5 #17242
Comments
|
Config Files attached. |
|
Same problem here after merging lasted changes, SKR 1.3 and branch bugfix-2.0.x from yesterday. |
|
Same Error here. |
|
i have same issue. Probing fails at different probing points. |
|
Any update on this issue? |
|
I have same issue on SKR 1.4 and the printer when hotbed heated crash serial , I think it's due to the same problem |
|
All I've come to notice if my bed leveling knobs are just the slightest bit loose (not snug) then this issue occurred. Whats funny is an earlier version of Marlin did not do this. I have two printers - An Ender 3 running and SKR Mini E3 1.2 and a Tevo Tornado running an MKS Gen L V1.0. At first, it only did this on the Tevo. I ended up resolving that by adjusting the bed leveling knobs and using a Torpedo level to level out the bed the best I could. Now my Ender 3 started doing it. The Ender always failed after probing the second time in the 3rd spot. I noticed my bed level knob was loose and snug it back up. Issue hasn't happened again. Did something change in Marlin in rergards to multiple probing? Is it comparing a variance from the first time it probes to the second and then fails if that $variance > X (where X is some configurable value lower than configured variance)? |
|
Having the same issue. Using 2.0.5.2(release) also have tried latest 2.0.x bugfix (747a4bb) |
|
Hi everyone, I confirm with version 2.0.4.4 the bltouch works and the printing does not stop with the heated bed. I tried to make a comparison between the versions and I reported some fixes for the skr but it is too much code to analyze not having written it myself .... and I don't have the time to patch. |
SERVO0_PIN is P2_00 (dedicated servo pins) |
The same behavior here on an Ender 3 with a SKR Mini E3 1.2 and bilinear ABL. |
|
Does anyone have adpative_step_smoothing enabled? I had very repeatable errors with adaptive step smoothing enabled when I had hybrid threshold disabled and a high z homing feedrate. It caused printer halts all the time. I fixed it by enabling hybrid threshold, but then the probing accuracy was way off and created some pretty crazy meshes. Currently I’m running with adaptive_step_smoothing disabled and no problems at all! |
|
I configured 2.0.5.3 with ADAPTIVE_STEP_SMOOTHING enabled. Because of your comment I disabled it and built the firmware again. But nothing happened. Probing stops at the 3rd spot. |
Ah, worth a try. |
|
In the meantime I have tried several configurations based on 2.0.5.3. But now the probing seems to work again. The only thing I changed in my configuration is the parameter GRID_MAX_POINTS_X from 4 to 3. |
|
I am observing a similar issue. I have an MKS Robin Nano 1.2 and an original BLTouch 3.1. Digging a little bit into the firmware, I see the following behavior: // Feedrate (mm/m) for the "accurate" probe of each point the problem disappears. |
|
I had this from 2.0, but I thought it is because of the noise 5V that the board makes. Ender-3, SKR Mini E3 v1.2, latest bugfix. |
|
Issue is still there. |
Which offset between probe and nozzle do you have? M851 I would like to compare that, with my latest settings. |
After this good news and a successful leveling, the problem appears again. ABL does not work. It is now the case that G28 still works without problems, but with a G29 the errors appear again. After the axes have moved to the first leveling point, the BLTouch (in my case a clone from Geeetech, 3DTouch) deploy, the LED turns off, then it stows and the LED lights up. This happens three times until the process is canceled. I tested the behavior with several stable 2.0.x.x firmwares, as well as with the latest bugfix 2.0.x. Here is my configuration based on the latest Bugfix-2.0.x for my Ender-3, SKR Mini E3 v1.2, Geeetech 3DTouch. Is there any configuration error I made and overlooked? |
|
I have been battling this same issue all night. I have tried every suggestion listed on this page and it still fails randomly at some point in the probing process. It was working, and I was fine tuning when it just suddenly started failing. It's been over a month since the last post, I'm curious if anyone has found a solution? Ender 3, SKR 1.4 Turbo, 2208, BLTouch 3.1, latest bugfix 2.0.x |
|
I have the same problem in robin nano 1.2. Marlin firmware 2.0.5.3. What is funny that on this version one week earlier everythig worked perfect. |
|
Same issues here running 2.0.5.3
|
|
After fixing other items on my printer I planned to work on a workaround to get rid of that issue. Before I started I modified my configuration settings to get an easier start for that fix. After that modification in configuration.h the issue was gone! Currently I am using the following settings: #define HOMING_FEEDRATE_Z (4*60) and I have removed: //#define MULTIPLE_PROBING 2 // for this setting you need an offset > 2 mm between probe and nozzle Maybe someone is able to double-check these settings. At the moment it might be a speed issue or something releated to multiple or extra probing. |
|
@toophast2catch still an issue? |
Yes, I had to go back to 2.0.4.4 and everything works, same hardware / config. |
|
. Please ignore my last response. I thought I was responding to another case. Yes, this is still an issue for many as you can see above. I figured out a work around by leveling my bed with my bed leveling knobs, but this defeats the purpose of ABL. I've found this issue occurs when the bed is so out of level that the BLTOUCH seems to detect a Variance in the probe points and it fails probing. Maybe it's a new safety? But still odd. If I level my bed with my knobs, probing works just fine. But this defeats the purpose of ABL. My bed is so flat now, my z axis doesn't compensate for anything. |
|
I don't have bed levelling knobs on my printer unfortunately. I have to shim it to close and then use UBL on 2.0.4.4 which works fine. |
|
Please test the bugfix-2.0.x branch to see where it stands. |
|
I have a similar problem with slow probe failing. The sanity check in probe.cpp seems to fail if the BL touch is mounted low and offset.z is zero (as I often use initially to find the actual offset): In my case, the trigger position is 2.09mm and offset.z is 0mm with Z_CLEARANCE_MULTI_PROBE default to 5. The result of The author of this bug @toophast2catch had a failure on fast probing: This is most likley due to the similar sanity check for the fast probe This particular sanity check was added by @InsanityAutomation in commit 84b6e11. I have commented out the sanity check locally and my BLTouch works as expected. |
|
@boelle - branch bugfix-2.0.x has the same issue: The code has been changed to use a lambda but the clearance calculation remains the same: if (try_to_probe(PSTR("SLOW"), z_probe_low_point, MMM_TO_MMS(Z_PROBE_SPEED_SLOW),
sanity_check, _MAX(Z_CLEARANCE_MULTI_PROBE, 4) / 2) ) return NAN;Perhaps |
|
@toophast2catch @jpflouret did #18435 fix the issue? |
|
It did for me. |
|
This happened to me out of the blue. The 2 wires on the BL Touch were the Black and White. |
|
@jpflouret oki will close close this one as fixed then we can always reopen if its not the case |
|
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. |
I have a Tevo Tornado running an MKS Gen L 1.0. Probing worked fine in previous releases, but I'm having problems getting it to probe correctly in Marlin 5.0. I enabled Debugging for Probing and I'll provide that output.
What happens is, it will probe start to probe and fail at point 6,7,or 8. Now it is failing at point 1. Its a BLTOUCH v3.1. Below is the debug output and I will also provide a zip of my config files.
Log Output
Any help is appreciated. Looks to me this is firmware bug.
The text was updated successfully, but these errors were encountered: