Marlin 1.1.9 - BLTouch always returns TRIGGERED

[Adzetko]

I am on Marlin 1.1.9 (it did the same on 1.1.8), I've got a legit BLTouch (from antclabs).

In Configuration.h, the ENDSTOP_INTERRUPTS_FEATURE is off, BLTOUCH is on (and nothing else concerning the Z axis probe of course), and I have Zmin uncommented, not Zmax.

It is reacting to every M280 P0 Sxx commands,
M119 returns "TRIGGERED" for the Z axis in whatever circumstances (deployed or not), and it continues returning "TRIGGERED" even when I disconnect the BLTouch itself.

I've tested the black and white cables (from the BLTouch PCB itself to the male pin on the 3D Printer) separately with a multimeter in the diode mode (beeping when there is current), and everything is reacting as excpected,
M43 S (with PINS_DEBUGGING on) returns:

Servo probe test
.  using index:  0
.  deploy angle: 10
.  stow angle:   90
. probe uses Z_MIN pin: 15
. uses Z_MIN_ENDSTOP_INVERTING (ignores Z_MIN_PROBE_ENDSTOP_INVERTING)
. Z_MIN_ENDSTOP_INVERTING: false
. deploy & stow 4 times
WARNING - INVERTING setting probably backwards
please trigger probe (note: I'm triggering it)
trigger not detected

Originally posted by @Adzetko in #11698 (comment) (but edited it a bit)

[RudyBenner]

#define Z_MIN_PROBE_ENDSTOP_INVERTING true // set to true to invert the logic of the probe.

[Adzetko]

#define Z_MIN_PROBE_ENDSTOP_INVERTING true // set to true to invert the logic of the probe.

@RudyBenner It is actually set to true, and I think BLTouch overwrite this value anyways, should I go on and try setting it to false?

[Bob-the-Kuhn]

I think there's a problem with the M43 code. Z_MIN_ENDSTOP_INVERTING set to false is what you want.

With Z_MIN_ENDSTOP_INVERTING set to false you should see triggered when the cable is removed.

Was this working previously or did you just install the BLTouch?

Speaking from personal experience, most likely you have the BLTouch tied to something besides the Z_MIN input.

If the wiring is correct, try moving the BLTouch to a different endstop and modify the pins_YOUR_BOARD.h file accordingly.

If you still are having problems then please post the following:

• configuration.h
• configuration_adv.h
• pins_YOUR_BOARD.h
• picture(s) of each connection from the BLTouch back to the controller

[RudyBenner]

set to true here. works 100%. connected to Zmin, Ground and signal. Pullup active.

[tifrei]

I have the same Problem. Just tried it the whole last week and even got a replacement ramps caus i thought the ramps might be faulty. When powered on the bltouch is just blinking mostly red . And M119 gives me back that it is triggered. When i put the same ramps back on the arduino mega i sued before the bltouch works fine.

[Bob-the-Kuhn]

Blue is good. That indicates that the servo signal is getting to the BLTouch.

There are two orange/red blinks.

The slower one indicates a problem with the power. It comes on at power up and stays blinking even when the reset command is sent.

The faster one indicates a fault. It I cleared by the reset command.

[Adzetko]

Mine is not blinking, the red LED is acting like intended, and the blue one is always on (don't know if this is what's intended though), I'll test what you ask me to do this weekend, my son is sick atm, so my priorities aren't on 3D printing.

[icamaster]

My problem when slightly different, but you could try. The embedded pull-up was too low, so I had to use an external pull-up (4.7k), after that it worked perfectly. It took me hours to diagnose.

[Adzetko]

So, both true and false Z_MIN_ENDSTOP_INVERTING returns "TRIGGERED" when M119. It already does this with Marlin 1.1.8, but from what I heard, the BLTouch support was bugged, so I thought using 1.1.9 would solve the problem.

Here is how my BLTouch is wired, I verified, I swapped the red and brown cables on the female pins for my 3D printer according to the picture there (as on the BLTouch itself it is brown-red-yellow, and what we want is red-brown-yellow):

And so the zip below contains my files, don't know where it could've been wrong.
Some details: you might see I'm using Thermistor 17 (which is not a standard Marlin thermistor I think), and I have a custom "thermistortable_17.h" to go with (which is not in the zip, as this is not a part of the problem I hope?).
Also, my board is based on the MKS 1.3, so I gave both "pins_MKS_GEN_13.h" and "pins_RAMPS.h" files, though the only changes made to the pins files are to the SERVO0_PIN, I've first tried without this:

#ifdef BLTOUCH
  #define SERVO0_PIN       19

but I found it more safe to use it to define my SERVO0_PIN, as I said it works the same with and without this piece of code, because when the SERVO0_PIN is not the good one, I don't see the blue LED anyways.

Here's the zip:
Discoeasy200 - BLTouch - Marlin1-1-9.zip

@icamaster Sorry but I don't understand what you are reffering to, where should I put some resistors? Is it somewhere inside the BLTouch? Isn't the small adjustable screw at the top intended to adjust what replacing the resistor does? It's a bit confused in my head.

Anyway, I appreciate your help guys, thank you a lot for taking some of your time for my problems. I hope we'll find out what is happening here, have nice holidays!

[icamaster]

@Adzetko My thing may not apply to you as I am using a RAMPS 1.4 board. But the idea of the pull-up resistor is to connect the switch of the BLTouch (white pin) to V+ (the leftmost red pin for example) via a 4.7k ohm resistor. But again, looking at your problem again, I do not think this applies to you.

[Adzetko]

Oh, and also, the results of a M43 S with "Z_MIN_ENDSTOP_INVERTING" set to false:

Servo probe test
.  using index:  0
.  deploy angle: 10
.  stow angle:   90
. probe uses Z_MIN pin: 15
. uses Z_MIN_ENDSTOP_INVERTING (ignores Z_MIN_PROBE_ENDSTOP_INVERTING)
. Z_MIN_ENDSTOP_INVERTING: false
. deploy & stow 4 times
WARNING - INVERTING setting probably backwards
please trigger probe
trigger not detected

And then with "Z_MIN_ENDSTOP_INVERTING" set to true:

Servo probe test
.  using index:  0
.  deploy angle: 10
.  stow angle:   90
. probe uses Z_MIN pin: 15
. uses Z_MIN_ENDSTOP_INVERTING (ignores Z_MIN_PROBE_ENDSTOP_INVERTING)
. Z_MIN_ENDSTOP_INVERTING: false
. deploy & stow 4 times
WARNING - INVERTING setting probably backwards
please trigger probe
trigger not detected

I think I've detected the problem, Z_MIN_ENDSTOP_INVERTING seems to always be set to false, whatever config I feed it. I've searched where could it be redefined but only found some code in "Conditionals_LCD.h" but I don't understand everything going on there.

[Roxy-3D]

Z_MIN_ENDSTOP_INVERTING gets set (or redefined) in:

• Conditionals_LCD.h
• Conditionals_post.h
• Configuration.h
• probe.cpp
• SanityCheck.h

[Bob-the-Kuhn]

@Adzetko - there may be a pin definition problem. The attached MKS BASE 1.1 diagram says Z_MIN is pin 18 but pins_RAMPS.h defines it as pin 15.

Disconnect the BLTouch from Z_MIN and then use M43 I to watch the state of pins 15 & 18 as you alternately ground Z_MIN and leave it open. One should be toggling. Let me know which one it is.

After playing with Z_MIN, remove all the endstops, issue a M43 E1 command and then ground each endstop. Let me know if anything strange happens (like grounding Y_MAX but the screen says X_MIN changed).

Issue a M43 E1 command and then issue a M280 P0 S60 command. The S60 command puts the BLTouch into a test mode where the output is in the triggered state. This should have resulted in one of the endstops changing state. If the attached diagram is correct then X_MAX will have changed state.

---

I suspect that the endstops are defined per the attached. If so then add the follow to the end of pins_MKS_GEN_13.h

//
// MKS base has different pin assignments for MOST end stops
//
#undef  X_MIN_PIN
#undef  X_MAX_PIN
#undef  Y_MAX_PIN
#undef  Z_MIN_PIN
#define X_MIN_PIN           3 //  2 on RAMPS
#define X_MAX_PIN           2 // 18 on RAMPS
#define Y_MAX_PIN          15 //  3 on RAMPS
#define Z_MIN_PIN          18 // 15 on RAMPS

[Bob-the-Kuhn]

I am wrong about the end stop assignments. The MKS boards use the same ones as in pins_RAMPS.h

[Adzetko]

@Bob-the-Kuhn I just tried the M43 E1 and then the M280 P0 S60, It just said this:

endstop monitor enabled
ok
ok

(assuming first ok was for the first command and the second one for the second command)

Edit: typo

[InsanityAutomation]

Remember the black and white wires are not dry contacts. It matters which one is signal and ground. When in doubt, try to flip them.

[Adzetko]

@InsanityAutomation I have just tried everything I tried before with the black and white wires flipped on the board and nothing have changed

[InsanityAutomation]

Fair enough, I didn't see that mentioned above so figured better make sure :)

[Adzetko]

@InsanityAutomation I never tried to switch this one so that was a nice try!

[Adzetko]

Good news: it works! On my previous message I forgot about the pins redefinition part by @Bob-the-Kuhn, well I just did this:

#undef  X_MAX_PIN
#undef  Z_MIN_PIN
#define Z_MIN_PIN          18 // 15 on RAMPS

because my others pins were correctly setup, and now I did my first successful print in a while!

Now new question: what would be a more elegant way to define the pins than in the bottom of pins_MKS_GEN_13.h?

[boelle]

@Adzetko problem fixed?

[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.