Skip to content
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

[QUESTION] BLTouch/Endstop always TRIGGERED #16552

Closed
Anilo1990 opened this issue Jan 12, 2020 · 46 comments
Closed

[QUESTION] BLTouch/Endstop always TRIGGERED #16552

Anilo1990 opened this issue Jan 12, 2020 · 46 comments
Labels
A: STM32 F: BLTouch T: Question Questions, generally redirected to other groups.

Comments

@Anilo1990
Copy link

Anilo1990 commented Jan 12, 2020

Hi guys.

Hope you guys can help me a little because my printer is broken right now.

My Configurations

So I own a Ender 3 Pro with a Cheetah 1.2a silent board. For ABL I'm using a genuine BLTouch V3.1 with Marling Bugfix 2.0.x. Since I've this printer it worked fine for me. No big issues at all for months.

Configuration.h and Configuration_adv.h file below in the zip file.
Configuration.zip

What Happened / Bug Description

I was designing a case for the motherboard so I can store it on the backside of the printer. Because there is limited amount of space I cut off the protruding PINs for the display cable on the back of the motherboard. After that I realized that my printer isn't autohoming anymore.

https://youtu.be/LqzZSbMJdMM (with BLTouch)
https://youtu.be/A5y0Ab0J8RQ (with mech. Endstop)

### Actual behavior: [What actually happens]

[...]
Send: M119
[...]
Recv: Reporting endstop status
Recv: x_min: open
Recv: y_min: open
Recv: z_min: **TRIGGERED** -> _fyi: red light + pin is retracted; it doesn't matter if something is pluged into the Z-Min port_
Recv: ok
[...]

Send: M43 S1
Recv: Servo probe test
Recv: . using index: 0, deploy angle: 10, stow angle: 90
Recv: . Probe Z_MIN_PIN: 15
Recv: . Z_MIN_ENDSTOP_INVERTING: false
Recv: . Check for BLTOUCH
Recv: . Deploy & stow 4 times
Recv: WARNING: INVERTING setting probably backwards.
Recv: ** Please trigger probe within 30 sec ** -> _fyi: slightly touching the pin; color turns from blue to red_
Recv: FAIL: No trigger detected
Recv: ok
[...]

I checked every wire twice and thrice. Did a continuity test with my multimeter for the BLTouch wires and the multimeter is beeping. Before autohoming I can move the Z-axis up and down via LCD commands. I don't know what happened to this board which was functioning properly before cutting of the protruding pins. Btw the protruding pins which you see on the picture below are for the LCD and they have nothing to do with the Z-axis or BLTouch. Also I didn't put any stress on this board which might be a result of cold joints.

81996961_10218989159938924_4696010240926154752_o

I also tried the stock Fysetc Marlin software from https://github.com/MarlinFirmware/Marlin/issues/new/choose without any success.

### Expected behavior: [What you expect to happen]
The expected behavior would be that I can autohome my printer and the Z-axis is not always triggered. I can see that when I manually trigger the mechanical endstops for X and Y. The state changes from open to triggered but not for Z.

### Additional Information
I'm reading through the whole internet since yesterday night.
Also in Github there are a few topics related to this issue but unfortunately nothing works for me

#11877
#12657
#7024

@AmiSMB
Copy link

AmiSMB commented Jan 13, 2020

I would try with nothing connected to the Z endstop connection and see what happens. If your x and y end stops are working the I would test one of these connected to the z stop connector to see what happens. I think that you may have damaged the board if it was working before.

@Anilo1990
Copy link
Author

If your x and y end stops are working the I would test one of these connected to the z stop connector to see what happens.

I tried that already. It always says "triggered". But I don't understand what cutting off the protruding pins has to do with the Z-min issue :-(
I ordered another board from Aliexpress. I'll compare them both when the new one arrives. In the meantime if someone has an idea feel free to tell me please.

@GMagician
Copy link
Contributor

I tried that already. It always says "triggered". But I don't understand what cutting off the protruding pins has to do with the Z-min issue :-(

Hoping you have done it without power, it can be that electrostatic discharge has destroyed processor input

@Anilo1990
Copy link
Author

I tried that already. It always says "triggered". But I don't understand what cutting off the protruding pins has to do with the Z-min issue :-(

Hoping you have done it without power, it can be that electrostatic discharge has destroyed processor input

of course I did it without power. Plugged off the AC cable from the printer as well. Who is going to solder with power turned on if someone does that he deserves to fry his board :-D

I can trigger and open the mechanical endstops for X and Y so I don't know why Z is not working. I plugged the Y endstop to Z but it's always saying triggered. Never mind, I'll check again when the new mainboard arrives.

@CRCinAU
Copy link
Contributor

CRCinAU commented Jan 19, 2020

I'm not sure what the problem is here:

Send: M119
Recv: Reporting endstop status
Recv: x_min: open
Recv: y_min: open
Recv: z_min: TRIGGERED
Recv: filament: TRIGGERED
Recv: ok P31 B31
[...]
Send: M280 P0 S10
Recv: ok P31 B31
[...]
Send: M119
Recv: Reporting endstop status
Recv: x_min: open
Recv: y_min: open
Recv: z_min: open
Recv: filament: TRIGGERED
Recv: ok P31 B31
[...]
Send: M280 P0 S90
Recv: ok P31 B31
[...]
Send: M119
Recv: Reporting endstop status
Recv: x_min: open
Recv: y_min: open
Recv: z_min: TRIGGERED
Recv: filament: TRIGGERED
Recv: ok P31 B31
[...]
Send: M280 P0 S160
Recv: ok P31 B31
[...]
Send: M119
Recv: Reporting endstop status
Recv: x_min: open
Recv: y_min: open
Recv: z_min: TRIGGERED
Recv: filament: TRIGGERED
Recv: ok P31 B31

Pin down = open, Pin up = TRIGGERED.

@Anilo1990
Copy link
Author

I'm not sure what the problem is here:
Pin down = open, Pin up = TRIGGERED.

Is this a question from your issue or what are you trying to tell us?

You should read what M119 command is doing
http://marlinfw.org/docs/gcode/M119.html
"The BLTOUCH probe only sends a brief pulse, so “TRIGGERED” indicates the probe is in error state."

You need to use M43 S1 and touch your BLTouch barely to see if the state changes from open to triggered and vice versa. From what I can say is either your mainboard or the BLTouch has a malfunction.

@CRCinAU
Copy link
Contributor

CRCinAU commented Jan 19, 2020

It's always been like this from day #1 - and it works fine. In fact, it was one of the test units for working on the BLTOUCH_HS_MODE functionality in Marlin.

It's a genuine BLTouch v3.0 and tested on both an SKR e3 mini v1.2 and the stock Ender 3 mainboard.

Further, you can see me sending the RESET ALARM (M280 P0 S160) and the probe is still TRIGGERED.

@Anilo1990
Copy link
Author

@CRCinAU the thing is then why my ender 3 is not working?
Like I sad I tried the stock BLTouch firmware from fysetc and also I tried to plug in the other mechanical endstops into Z_min but it never worked after I cut of the protruding PINs.

My BLTouch is also a original one not one of this knockoffs for 10 bucks.

@CRCinAU
Copy link
Contributor

CRCinAU commented Jan 19, 2020

Go back to basics. If you deploy the probe, does it change to OPEN? If you stow the probe again, does it go back to TRIGGERED?

At this stage, I'd ignore what the documentation says - as a lot of boards don't support interrupts on the probe ports - meaning it all has to be done via polling - so a pulse can be very bad - especially if missed...

@Anilo1990
Copy link
Author

@CRCinAU i did everything i know but so far it doesn’t change. Do you have a recommended way to test? I can then try that later when I’m home again.

@GMagician
Copy link
Contributor

GMagician commented Jan 19, 2020

@CRCinAU please note this:

also I tried to plug in the other mechanical endstops into Z_min but it never worked

this is not a bltouch issue...

Edit:
If mechanical endstop doesn't work and input associated to z_min is correct, answer is not too much different then "damaged input"

@CRCinAU
Copy link
Contributor

CRCinAU commented Jan 19, 2020

this is not a bltouch issue...

Certainly. I wonder though, I never could get it working on the PROBE port on the SKR E3 Mini v1.2 - I had to use the Z-STOP port. While that's an off topic discussion, I wonder if its to do with the input setup - which would be board specific...

@GMagician
Copy link
Contributor

That may be an hardware issues maybe because of some sort of PNP NPN? Don't know how skr works.
But mechanical endstops (AFAIK) have a pull-up and close to GND then testing input with these device, without pullup in configuration, should work (but board may have its own pull down.. any schematic available?)

@CRCinAU
Copy link
Contributor

CRCinAU commented Jan 19, 2020

As this might be useful to OP, as it may well be a similar board issue, schematics for the SKR E3 mini v1.2 are here:
https://github.com/bigtreetech/BIGTREETECH-SKR-mini-E3/tree/master/hardware/BTT%20SKR%20MINI%20E3%20V1.2

@GMagician
Copy link
Contributor

GMagician commented Jan 19, 2020

Stop and probe are, on H/W side, identical.
They have a board pull-up so closing to gnd is ok, no pull up required in configuration.

Edit: Only difference I see is PROBE that is connected to a multifunction pin (PC14-OSC32-IN) maybe it needs a special processor setup to be correctly used. I don't know how stm32 works, maybe some other developpers know it

@ebraiman
Copy link

I'm experiencing this issue across several HW platforms and would be willing to show the problem on each HW platform on camera. These are the HW platforms; RAMPS 1.4/1.6, MKS Gen L 1.0/1.4, SKR V1.3/1.4 SKR Pro and more. I want to proven incorrect. Let me know.

@thinkyhead
Copy link
Member

Marlin trusts what the pin tells it. Perhaps pullups / pulldowns need to be set on these pins…?

@thinkyhead thinkyhead added T: Question Questions, generally redirected to other groups. F: BLTouch labels Jan 21, 2020
@ebraiman
Copy link

Give me the marlin setting you want and I'll compile and load for each board.

@thinkyhead
Copy link
Member

Is it your BLTouch that is failing to work, as with the OP?

@thinkyhead
Copy link
Member

Without pullups/pulldowns pins may float, but as GMagician points out, the pins are apparently pull-up. Still, it cannot hurt to try enabling the pull-ups for NC switches or pull-downs for NO switches.

@ebraiman
Copy link

ebraiman commented Jan 21, 2020

Yes, the BLtouch is failing and shows triggered. I have two flavors of BLtouch V2.0 and 3.1.

@ebraiman
Copy link

Hardware:
SKR 1.4 (LPC1768)
BLTouch v3.1
Wired per documentation https://github.com/bigtreetech/BIGTREETECH-SKR-V1.3/tree/master/BTT%20SKR%20V1.4

Downloaded Marlin-bugfix-2.0.x
Extracted on Windows 10
Opened In VScode

Configuration.h changes:
changed #define MOTHERBOARD BOARD_BIGTREE_SKR_V1_4
changed #define SERIAL_PORT -1
removed comment for #define BLTOUCH
removed comment and change number of servos for #define NUM_SERVOS 1
commented out //#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
platformio.ini changes:
default_envs = LPC1768
uploaded via arrow button in VScode
Power cycled SKR 1.4 via remove of USB connection after firmware.bin placed on TF drive.

Opened PronterFace.exe
Connected to SKR 1.4
Entered, M119

Output:SENDING:M119
Reporting endstop status
x_min: TRIGGERED
y_min: TRIGGERED
z_min: TRIGGERED
z_probe: TRIGGERED

@ebraiman
Copy link

Repeated with SKR 1.4 Turbo (LPC1769)
configuration.h:
Changed #define MOTHERBOARD BOARD_BIGTREE_SKR_V1_4_TURBO
platformIO.ini:
default_envs = LPC1769
rebuilt in VScode
PO/PO SKR 1.4 Turbo with removal of USE after firmware.bin loaded.
Opened Pronterface and connected
Entered M119

Results:
SENDING:M119
Reporting endstop status
x_min: TRIGGERED
y_min: TRIGGERED
z_min: TRIGGERED
z_probe: TRIGGERED

@ebraiman
Copy link

RAMPS 1.4
Physical connection for RAMPS 1.4:
Servo signal pin row is Pin 11
Z-min for white wire and black on ground
Jumper is connected to servo rail for VCC and 5V
Bltouch 3.1

PlatformIO.ini
changed default_envs = megaatmega2560
Configuration.h:
Changed #define MOTHERBOARD BOARD_RAMPS_14_EFB
removed comment for #define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
changed #define SERIAL_PORT 0

Recompiled and uploaded

Opened Pronterface:
Connected
Entered M119
SENDING:M119
Results:
Reporting endstop status
x_min: TRIGGERED
y_min: TRIGGERED
z_min: TRIGGERED

@ebraiman
Copy link

Which board would you like me to try next? Or did I miss a step?

@ebraiman
Copy link

Swapped in BLtouch 2.0 with same results on RAMPS 1.4.

@ebraiman
Copy link

3dTouch on RAMPS 1.4 has same issue.

@ebraiman
Copy link

Set #define ENDSTOPPULLUP_ZMIN
built and loaded on RAMPS 1.4 with no change on BLtouch v2.0 and 3d Touch.

Set //#define ENDSTOPPULLUP_ZMIN
Set #define ENDSTOPPULLDOWN_ZMIN will not build.

@ebraiman
Copy link

Not sure if all my HW is broken, but seems like a low probability.

@lantren
Copy link

lantren commented Jan 21, 2020

Not sure if all my HW is broken, but seems like a low probability.

Wow. Now if you could only identify an older version of the firmware that actually works correctly on all your improbably broken HW . That might be useful to someone.

@ebraiman
Copy link

Example 1
https://youtu.be/5cSzFCv7K4Q
Example 2
https://youtu.be/roiquQpfFHU
Example 3
https://youtu.be/HR-zn4dv1fY
Example 4
https://youtu.be/d0akA_5mm-8

Would you like more examples?

@GMagician
Copy link
Contributor

GMagician commented Jan 21, 2020

@ebraiman please note that original post by @Anilo1990 was about problem with bltocuh but also mechanical endstop. Now one question about your test. Have you ever tryed with an endstop on the same input? Maybe something wrong with pin assignment for your board?

Edit: what if you close input to gnd/3.3V (pay attention to this may be dangerous)?
Edit2: are you using interrupts on endstops?

@ebraiman
Copy link

Tested just now on RAMPS 1.4 with Mechanical two wire switch and worked correctly.

echo:Marlin bugfix-2.0.x
echo: Last Updated: 2020-01-21 | Author: (none, default config)
echo:Compiled: Jan 20 2020
echo: Free Memory: 5625 PlannerBufferBytes: 1136
echo:Hardcoded Default Settings Loaded
echo: G21 ; Units in mm (mm)
echo:Filament settings: Disabled
echo: M200 D3.00
echo: M200 D0
echo:Steps per unit:
echo: M92 X80.00 Y80.00 Z4000.00 E500.00
echo:Maximum feedrates (units/s):
echo: M203 X300.00 Y300.00 Z5.00 E25.00
echo:Maximum Acceleration (units/s2):
echo: M201 X3000.00 Y3000.00 Z100.00 E10000.00
echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
echo: M204 P3000.00 R3000.00 T3000.00
echo:Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> J<junc_dev>
echo: M205 B20000.00 S0.00 T0.00 J0.01
echo:Home offset:
echo: M206 X0.00 Y0.00 Z0.00
echo:PID settings:
echo: M301 P22.20 I1.08 D114.00
echo:Z-Probe Offset (mm):
echo: M851 X10.00 Y10.00 Z0.00

M119
SENDING:M119
Reporting endstop status
x_min: TRIGGERED
y_min: TRIGGERED
z_min: open
M119
SENDING:M119
Reporting endstop status
x_min: TRIGGERED
y_min: TRIGGERED
z_min: TRIGGERED

@ebraiman
Copy link

Just some thoughts. If BLtouch does not work for multiple chipsets of Marlin for 1768/1769/MEGA2560, then could this be an implementation issue?

@tatusah
Copy link

tatusah commented Jan 21, 2020

Do you mean @ebraiman that you have suddenly multiple boards that show BLTouch triggered regardless whether the probe is stowed or deployed and thus you can't use the probe?

@ebraiman
Copy link

I'm using a fixed mounted configuration. Should we set fixed mount? Did this change recently? This has been occurring sine last summer 2019.

@tatusah
Copy link

tatusah commented Jan 21, 2020

I mean that is the state reported by M119 still triggered after you deploy the probe pin down with M280 P0 S10 or through the BLTouch menu via LCD.

@Anilo1990
Copy link
Author

@ebraiman don't try M119. Try sending M43 S1 and then see what happens.
I can't imagine that all your boards are broken and also I don't understand your issue ... your just posting the output of M119 commands on different boards :-D

@GMagician
Copy link
Contributor

If BLtouch does not work for multiple chipsets of Marlin for 1768/1769/MEGA2560

I have a mega2560 + ramps 1.4 + bltouch clone and it works, so not too clear what happens to you
For sure if you have 'triggered' something is not correct. On bltouch such conditions lasts for 10ms (or something like that). If endstop, connected to same input is workings this tells us that input is working, not a board issue, but maybe board is too busy to read 10ms signal. Are you using interrrupt on endstops?

@boelle
Copy link
Contributor

boelle commented Jan 21, 2020

@Anilo1990 is your org issue still there?
@ebraiman only post here if your issue is 100% the same and you have precise same hardware as @Anilo1990, if you have a different issue or different hardware please create your on issue post and remember to read the issue template and the 2 pinned posts

@Anilo1990
Copy link
Author

@boelle yes still waiting for the replacement board from china. it's on his way. estimated arrival time is mid february.

@GMagician
Copy link
Contributor

@Anilo1990 since your board may be dead and nothing can be worse, you may try to short-circuit gnd and input signal (on board connector with nothing connected) and check what M119 says. Then repeat with 3.3V (I think your board is also 5V tolerant) and signal.

@boelle
Copy link
Contributor

boelle commented Jan 30, 2020

@Anilo1990 have you checked what your dead board said when sending M119 ?

@boelle boelle added the A: STM32 label Feb 3, 2020
@boelle boelle changed the title [BUG] BLTouch/Endstop always TRIGGERED [QUESTION] BLTouch/Endstop always TRIGGERED Feb 4, 2020
@Anilo1990
Copy link
Author

So I got my new Cheeta 1.2a board today. Swaped it and my printer works again like before.
I really don't know what caused the issue.

[...]
Send: M119
Recv: Reporting endstop status
Recv: x_min: open
Recv: y_min: open
Recv: z_min: TRIGGERED
Recv: ok
[...]

[...]
Send: M43 S1
Recv: Servo probe test
Recv: . using index: 0, deploy angle: 10, stow angle: 90
Recv: . Probe Z_MIN_PIN: 15
Recv: . Z_MIN_ENDSTOP_INVERTING: false
Recv: . Check for BLTOUCH
Recv: = BLTouch Classic 1.2, 1.3, Smart 1.0, 2.0, 2.2, 3.0, 3.1 detected.
Recv: ** Please trigger probe within 30 sec **
Recv: . Pulse width: 30ms or more
Recv: = BLTouch V3.1 detected.
Recv: ok
[...]

I tried M43 S1 before and like I wrote 23 days ago when I touched my BLTouch with the old board it didn't detect triggering. The new board detects the manual triggering.

@boelle
Copy link
Contributor

boelle commented Feb 8, 2020

@Anilo1990 so this one is solved? if so please click the close button below

@github-actions
Copy link

github-actions bot commented Jul 3, 2020

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.

@github-actions github-actions bot locked and limited conversation to collaborators Jul 3, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A: STM32 F: BLTouch T: Question Questions, generally redirected to other groups.
Projects
None yet
Development

No branches or pull requests

9 participants