-
-
Notifications
You must be signed in to change notification settings - Fork 19.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Marlin 1.1.9 - BLTouch always returns TRIGGERED #12657
Comments
#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? |
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:
|
set to true here. works 100%. connected to Zmin, Ground and signal. Pullup active. |
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. |
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. |
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. |
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. |
So, both true and false 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. #ifdef BLTOUCH
#define SERVO0_PIN 19
but I found it more safe to use it to define my Here's the 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! |
@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. |
Oh, and also, the results of a
And then with "Z_MIN_ENDSTOP_INVERTING" set to true:
I think I've detected the problem, |
Z_MIN_ENDSTOP_INVERTING gets set (or redefined) in:
|
@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.
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
|
I am wrong about the end stop assignments. The MKS boards use the same ones as in pins_RAMPS.h |
@Bob-the-Kuhn I just tried the M43 E1 and then the M280 P0 S60, It just said this:
(assuming first Edit: typo |
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. |
@InsanityAutomation I have just tried everything I tried before with the black and white wires flipped on the board and nothing have changed |
Fair enough, I didn't see that mentioned above so figured better make sure :) |
@InsanityAutomation I never tried to switch this one so that was a nice try! |
Good news: it works! On my previous message I forgot about the pins redefinition part by @Bob-the-Kuhn, well I just did this:
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? |
@Adzetko problem fixed? |
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 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
(withPINS_DEBUGGING
on) returns:Originally posted by @Adzetko in #11698 (comment) (but edited it a bit)
The text was updated successfully, but these errors were encountered: