[BUG] Marlin 2.0 "bugfix" + SKR 1.3 + BLTouch (clone) - nozzle randomly crushes into the bed

[mbabic84]

Hello,

I have an issue with the combination mentioned in the title. There is a problem when nozzle crushes into the bed randomly on G28, G29 or G34. I have no idea how to reproduce this issue, sometime it happens two times in a row, sometime it works flawlessly the whole day. I tried to set "BLTOUCH_DELAY" to a higher value (500ms+) and the issue is less common but maybe it is only my feeling.

Thanks.

[Aurawin]

Do the M48 probe test a few times and compare the results. I had 2 other non-ANTCLABS sensors that provided obscene deviations.

I just purchased and installed my authentic BL Touch from ANTCLABS on Amazon. The deviation when I did a follow-up M48 (repeatability test) it returns deviation values much smaller (the smaller the better) than any previous sensor. I've tried capacitive, inductive, and 2 other touch devices all from Amazon. All but the authentic BL Touch went back (with haste).

Believe me, the differences are day and nite and well worth the extra money.

[mbabic84]

I just run M48 with 30 repeats and it ended up with

Mean: -0.008667 Min: -0.030 Max: 0.010 Range: 0.040 Standard Deviation: 0.010601

I tried it also with star pattern with similar results and also without the crash to the bed. I used this particular sensor on another printer (mks gen l) for a couple of months with no issue, so this probably is no issue with the sensor itself.

[DrNeis]

Maybe your problem has to do with my problem. Do you have FAST_PWM_FAN enabled? There seems to be a problem with PWM on the SRK 1.3 when enabled. Check our discussion here #13861

[mbabic84]

I don't have enabled this function.

[ghost]

There is a problem when nozzle crushes into the bed randomly on G28, G29 or G34

This means that the firmware is sometimes not seeing the trigger pulse, randomly.

This can be because your controller board has an unusually high capacitor on the relevant input pin, or because the probe is faulty (oh, it works on the other printer, so ok...), or because you have not got the ENDSTOPPULLUPS on or maybe even some other issue.

What is your printer, printer controller board, configuration.h etc.?

[mbabic84]

I use a custom made printer with Bigtreetech SKR 1.3 32bit board. ENDSTOPPULLUPS is enabled. I attached a zip file with used configuration files. Maybe someone can find what can cause this behavior. Thx

configuration.zip

[ghost]

Here is a small part of the SKR 1.3 schematics: You can see the 0.1uF capacitor, I feel that one is not too large, it's ok. There is actually a 10K pullup to 3.3V there already, so your ENDSTOPPULLUPS will actually add to that. That's good too. Maybe you could get a little bit more reliability if you yourself add a 1K resistor from 5V to the signal of the probe.

[mbabic84]

My knowledge of electronics is quite limited, but I own a couple of 1k resistors and I know how to use a soldering iron, so, I can definitely give it a try. Thank you FanDjango.

[DrNeis]

I own two different clone BLTouch sensors (V 1.0 and 1.2) and i am using the same Motherboard (BIGTREETECH SKR 1.3). Both sensors are working without the problem you describe. Because of that I think solering the resistor may not help you.

[ghost]

In that case I would also say that.

[mbabic84]

I had also a problem that I was not able to get working bltouch of version 1.0, only version 1.2 was working. So, maybe it is a problem with the motherboard itself. I probably try to order another one :)

[ghost]

See if the occurrences are more seldom if you lower #define HOMING_FEEDRATE_Z (10*60) to half of that.

[mbabic84]

I tried to lower it and it seems better now. I'll also check the wiring from the sensor, there are some connectors on the way, so I'll cut them and solder wires directly just to be sure.

[mbabic84]

I tried to enable "BLTOUCH_FORCE_5V_MODE" and since then I had no problem. Bltouch is acting a kind of wired but so far no crash into bed.

[ghost]

It's a clone, you said. It shouldn't and cannot as far as I know react in any specifiy way to a SET_5V_MODE command. As a matter of fact, there are many who consider giving a clone such unknown command a risk that it will fail. The servo-angle corresponding to SET_5V_MODE is only known to the new BLTOUCH V3, the orginal. The angle is 140°, right in the middle between SELF-TEST and RESET. Who knows what the probe is recognizing?

So it is with great surprise I hear that it now works better.

[InsanityAutomation]

Id wager the extra unknown command just gives it longer to process the previous one and increasing the safe delay would be a safer solution.

[ghost]

I'd lose if I bet against that I think, as he said in the beginning that increasing the DELAY seemed to help a little bit. Maybe he should try BLTOUCH_DELAY 1000?

Theoretically, there are only a few reasons to crash into the bed:

1. Missing the trigger pulse - nuff said about that: Noise, weak pullups, etc. Maybe even a faulty probe.

2. Probe is not in "trigger" mode, i.e. it is not properly deployed at all, in that case why is the pin down (TO: is the pin down when it crashes? Did you ever see in detail?). Maybe it went into alarm for some reason (TO: Did you try to turn in the ferrite core a little bit?, maybe the probe sometimes fails to deploy.) The upcoming new code would tell us more about the sequence of events leading to the problem.

TO: Would you be up to installing a different firmware (newer, test-version for BLTouch type probes, still in evaluation) and having a look-see? It could provide valuable insights and more information.

[mbabic84]

I tried to set a delay to 500ms which was better than a default value but when I try to set it to 750ms then there was no difference. Mostly it was ok, but sometimes it hit the bed. I did not try to increase it more. I had this very same probe on another printer where it worked without any issues for a couple of weeks (there was mks gen l). When it did not trigger the endstop, the probe was always deployed as it should be. I can show you a short video of how it works now, its kind of weird, but it detects endstop every time so far. I mostly use the latest version of Marlin code (branch bugfix-2.0.x) but I can test different branch/version for sure.

[ghost]

When it did not trigger the endstop, the probe was always deployed as it should be. Ok, that is useful info. Show me the weird behaviour if you can in the video, then we can decide

[ghost]

Part of the problem is of course also this:

I own two different clone BLTouch sensors (V 1.0 and 1.2) and i am using the same Motherboard (BIGTREETECH SKR 1.3). Both sensors are working without the problem you describe.

Maybe your clone is a third kind and DOES need the 1k resistor. Not saying anything, but you know how it is. Maybe...

[mbabic84]

Here https://www.dropbox.com/s/aj4zewyovvd021b/2019-05-07%2023.13.32.mp4?dl=0 you should be able to see how it works with "BLTOUCH_FORCE_5V_MODE" enabled now.

[ghost]

Ok seen it. current bugfix-2.0.x, right?

[mbabic84]

Yes, latest, max few commits behind.

[ghost]

If you have enabled 5V mode you have also enabled BLTOUCH_V3, I suppose, otherwise it wouldn't enable. But that will make things even more complicated because that is also setting SW mode in current bugfix-2.0.x. Not a problem, but it accounts for some of the delays one can see in the video. And it's a clone, it can't do the 5V stuff.

Doesn't really look weird if one accounts for that. Do please disable BLTOUCH_V3, disable BLTOUCH_FORCE_5V_MODE. Go back to normal non-V3 BLTouch.

But then we still need to find out where it fails and why. I'll get to you tomorrow on that, it's late here.

[mbabic84]

Ok, then, I'll disable it and I'll try to catch failed probe on video. There is no need to hurry, I have to leave tomorrow and I'll be out of town for a few days. Thank you and have a nice evening (rest of it at least :)).

[InsanityAutomation]

Can also try the pending code here https://github.com/MarlinFirmware/Marlin/pull/13814

[mbabic84]

Ok, so, here is a video with a failed probe: https://www.dropbox.com/s/mcogvp5a72s4sll/2019-05-08%2000.35.11.mp4?dl=0

There were about 15 successful probes before this failed one.

[ghost]

Very good video. Looks very very much like the trigger is not being seen. Two things to do:

1. Try a 1K resistor between the white and the red wire (i.e. a 1K pull-up resistor between 5V and the trigger-output signal of the probe.

No need to "Can also try the pending code here #13814", because @thinkyhead has merged this last night.

2. There's a new bugfix-2.0.x out there as of last night with the BLTouch code merged in. It produces better error messages but you must turn them on in configuration.h:

/**
 * Enable detailed logging of G28, G29, M48, etc.
 * Turn on with the command 'M111 S32'.
 * NOTE: Requires a lot of PROGMEM!
 */
//#define DEBUG_LEVELING_FEATURE

In order to compile that if you have not got a lot of PROGMEM, turn off SDCARD (temporarily) for example. You can revert back again after the test.

We all would like to see the debug output of a fail.

In case the probe works better or well with the 1K resistor, I would still install the new bugfix version, so that in future there is better probe command sequencing.

[mbabic84]

Ok, so, I tried to enable "DEBUG_LEVELING_FEATURE" and here are the results when probing failed:

I hope you will be able to get something from it, I'm not :)

[ghost]

FInally we have all needed information for debugging such cases in one place with this new bugfix code. Yes I can see the successfull last deploy, which performed ok. The controller did not see the trigger during the blocking move. 1K resistor next.

[mbabic84]

I added 1K pull-up resistor and the issue is almost gone. I made about 300 probe tests with M48 and there was only one failed probe. Here is a console log:

I have to make better wiring from bltouch with a resistor included and I'll try it again. It still has few connectors on the way, so, it can cause some issues too. I have to thank you, this looks very promising :)

[InsanityAutomation]

Makes me wonder if they cloned the V3 probe problems and all LOL. good chance that they grabbed one of the pre April probes and duplicated what was on it...

[InsanityAutomation]

If you still have an issue following the connector changes, try going to a 470ohm resistor instead of 1k

[InsanityAutomation]

Fwiw another user on discord with an ender 3 melzi 1.1.4 board also required the resistor. Trying to get an idea of what boards do and don't need them...

[marvelous240]

Hi all. I've been running into issues with a genuine BLTouch V3.0 pre-April that relate to this. Without any additional resistance the probe won't even self test. I've found that if you hold the probe in your hand and place your finger on the connector with your flesh in contact with the little bit of the terminal that's exposed, the probe will go through the self test and function perfectly. It will also work if you're using the cable extension kit and pinch the black and white wire with your fingers where the connectors meet and where the terminals are exposed. I guess our bodies add enough resistance to get it working. I also jammed a 1kohm resistor in the jst connector of the black and white wire and that worked as well. I saw that FanDjango mentioned a red and white wire above. Did you mean the black and white? They go to the z-min endstop's ground and signal. Not voltage. Just want to make sure I tie a resistor in the right place more permanently. I assume that’s what you meant because the SKR V1.3 is a ground trigger. Also should note I’m not running any fast or soft fan fix and using a fresh Marlin 2.0 bugfix from two days ago.

[marvelous240]

Video example showing self test failure mentioned above. Also FYI I'm just referencing the self test not completing as an example, because when it doesn't complete, all axis will still home but bed leveling will fail after a few probes. When the self test does complete and there's enough resistance, the Bltouch will finish the bed leveling sequence and continue to probe accurately using M48.

https://drive.google.com/file/d/1dOPy7MsHDV1_VsNsQMKYkAiYKpTjMFx1/view?usp=sharing

[ghost]

What happens when you power on and the black/white is not connected at all? Self test and then red light continuous? If so, then I would query whether the black/white is connected to the right place. Suggestion: BLACK is Ground, just like BROWN on the three wire cable. Be careful where you put that. If in doubt, leave black dangling for now. The question is where to put the WHITE one, ok?

Typically if your fingers can influence signals, it is because they are floating or close to a threshhold. That doesn't help in this case. Lets be systematic.

Disconnect BLACK/WHITE. Both of them.

Check in the LCD if the SELF TEST, DEPLOY, STOW commands work?

Yes?

So that half is ok.

Then like I said above, the WHITE cable needs to be put somewhere where it works. Let's take it up to that point and then converse again?

[ghost]

using a fresh Marlin 2.0 bugfix from two days ago.

Yup, and BLTOUCH_FORCE_5V_MODE I hope.

Without any additional resistance the probe won't even self test

See the previous post. Commands to the probe are a separate topic to be addressed FIRST. Remove BLACK/WHITE. Let's get the commands to the probe working first, separate issue. BROWN = GND, RED = 5V, ORANGE = Servo Signal must be working first without "fingers", ok?

[marvelous240]

I’ll test what you suggested in a few. Thanks! No I do not have force 5V mode defined. Should it be? I thought that was for the clones?

[marvelous240]

Actually I see the language changed in the firmware. So 5V mode should be ok. These SKR boards are 5V tolerant correct?

[InsanityAutomation]

Most pins are. Not all. Analog mode means 3.3v so we still need to figure out what that does to some things like Filament width sensors.

[ghost]

Thanks! No I do not have force 5V mode defined

Also keep in mind: 1st thing to fix is that the probe must accept commands from the LCD, Menu "Configuration", Submenu "BLTOUCH".

Defining 5V Mode (or not) influences the second half of your problems, it changes the voltage level of the WHITE cable. We haven't even reached that point yet.

5V mode setting becomes important later, so to speak.

[boelle]

Lack of Activity This issue is being closed due to lack of activity. If you have solved the issue, please let us know how you solved it. If you haven't, please tell us what else you've tried in the meantime, and possibly this issue will be reopened.

[Virtualight]

I am also experiencing the exact issue described by the author with my SKR v1.3 board using latest Marlin Bugfix 2.0 where the BLTouch (two different clones) occasionally does not trigger and stops the bed leveling. I have checked the 10ms pulse out of the BLTouch with an oscilloscope and it is square and noise free.

Here are my relevant configuration settings;

define ENDSTOPPULLUPS

define BLTOUCH

define SERVO0_PIN P2_00 //SKR 1.3 board

define USE_ZMIN_PLUG //BLTouch on this endstop

define Z_MIN_ENDSTOP_INVERTING true

define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN

I have tried #define BLTOUCH_FORCE_SW_MODE with no improvement. I have tried #define BLTOUCH_SET_5V_MODE I have also tried the 1k pullup resistor (see picture below) and a decoupling capacitor across the output of the BLTouch.

Here is a video showing it failing; https://youtu.be/27QdFZsk4fM

[Aurawin]

For me, the BLTouch auto level and z-axis alignment have been doing pretty well. I am enjoying the quick feature as well.

I did however just witness a time where the bltouch kept randomly cycling and twitching. It was insane. Down up, Down up, twitch. Where twitch would be lower than a bit up in and lower and a bit up just about 0.5mm. Rapid cycle. I couldn't align dual z, I had to reboot Marlin to get the issue to go away.

[Virtualight]

OK - I figured out what the problem was with my probe. The probe is attached to my Z_MIN_ENDSTOP and I have uncommented #define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN, however, during a G29 any low points on the bed that are below the homing point cause an abort in firmware i.e. the z-axis does not come up far enough to trigger the probe. The solution I found was to change #define Z_MIN_POS from 0 to 2.

[Virtualight]

In retrospect to my post above I should have changed the Z_PROBE_LOW_POINT function. Anyway I was so confused with the plethora of the z-axis functions that decided to make a drawing with help and feedback from the Rigidbot Community as we could not find anything on-line. We would greatly appreciate any feedback/suggestions on the drawing and accompanying text or where to find a better explanation;

To ensure a relatively failsafe implementation of a probe for bed leveling it is recommended to use it in conjunction with a mechanical microswitch. The microswitch acts as a homing endstop and dependable reference point for the probe.

The microswitch is ignored during bed leveling, however, if a probing fails to trigger it is stopped by the Z_PROBE_LOW_POINT function variable and will retry up to four times before aborting the bed leveling.

The Z_PROBE_LOW_POINT variable needs to account for any dips in the bed but not low enough that it crashes into the nozzle. The probe probes down from the nominal bed height at homing to Z_PROBE_LOW_POINT - Z_PROBE_OFFSET_FROM EXTRUDER (both are negative values).

Once the leveling is done the lowest point below the nominal bed height needs to be calculated and accounted for in Z_POS_MIN. Z_POS_MIN is the sum of the distances between z-min set by the microswitch and the nominal bed height during homing plus the height of the lowest dip in your bed matrix.

Addendum; The probe and microswitch have separate roles but are tied together in the background. It would be nice if after a G29 that the figures that make up Z_POS_MIN could be spat out.

[Blisk]

I have exactly the same problem with SKR mini E3 and 3dtouch. Nozzle crashing into heatbed. I found out a solution but it is for marlin 1.1.9 Can anyone point me how to make the same changes in marlin 2.0.5? https://github.com/InsanityAutomation/Marlin/commit/15ce74badfd3a1b6e6ffabf882234ffa77682715

[sjasonsmith]

@Blisk this issue isn't really the place to discuss it, especially since it has been closed for almost a year. Head over to Discord or one of the other support forums and seek help there. As a quick hint, if you are seeing this using firmware from BTT repo, that issue has been fixed in the main Marlin repo many months ago.

[github-actions[bot]]

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.