[BUG] SKR 1.4 and bltouch issues

[mtfisher]

Hello,

Having issue getting the bltouch to home on the z index as shown in following video https://www.youtube.com/watch?v=B13D0v-6sFg

As seen in the video the probe is triggered but the Z axis continues to move down

Just wonder if anyone else is reporting any issues with BLTouch homing not working.

My printer is a Ender 3 with a SKR 1.4 turbo, BlTouch 3.1 and the drivers are TMC 2209s and my config files are

https://www.dropbox.com/s/kfq0uf8b6m971ly/Configuration_adv.h?dl=0
https://www.dropbox.com/s/p3cxn2iygcu5evi/Configuration.h?dl=0

I have pluged my bltouch in to the z min end switch port and when powered on M119 reports the z min end switch is open.

The branch I am using is bugfix-2.0.x with the last commit hash being 2ef6b86ccdc3fdd3fde332f36181f4b2009e15b6 on Thu Jan 23 04:52:16 2020 +0100

[rrichX]

I'm not sure if I should start a new issue here, but in the last couple of days switched from an SKR 1.3 to a 1.4 Turbo but I use DC42's IR Probe and also having issues with my Z probe (But being shown as TRIGGERED). If I set Z_MAX_ENDSTOP_INVERTING to true, it shows as open.

If I change the default_envs and MOTHERBOARD settings for the SKR 1.3 (Z_MAX_ENDSTOP_INVERTING set to false), the firmware complies and the Z probe works with everything plugged into the same marked plugs.

I've tried bugfix-2.0.x from yesterday and today (but not tried today's on the 1.3).

Marlin_Config_and_adv.zip

[JudgeZ]

Seems like you need to set the #define Z_MIN_PROBE_ENDSTOP_INVERTING to true and also adjust your settings for BLTouch v3.1 in configuration_adv as listed in configuration_adv

/**

• Settings for BLTouch Smart 3.0 and 3.1
• Summary:
• • Voltage modes: 5V and OD (open drain - "logic voltage free") output modes
• • High-Speed mode
• • Disable LCD voltage options
    */

It also needs to be plugged into Z_MIN_ENDSTOP_PIN since you have #define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN

[tatusah]

Good job @mtfisher using proper testing method with enough room to test the functionality initially with finger. SKR 1.3 board schematics show the actual endstop signal detection using 3.3 volts connected to a pull-up resistor. SKR 1.4 boards don't have the schematics published yet only the pin diagram. So the BLTOUCH_SET_5V_MODE is unnecessary although the signal input pins seem to be 5v tolerant. Anyway the BLTouch would work also in the default open drain mode which is working with both 3.3 and 5 volt signal level system. If using the 5v mode then the signal probably needs to be inverted just lke @JudgeZ said. If the 5v mode is disabled then the inversion most probably isn't needed at least not on my setup.

@rrichX probably better not mix in different type of probe which might need different type of settings for proper functionality. Also if the thing is about configuration problems then it would be better to look help from Marlin Discord channel of different 3d printing related Facebook groups. But in any case it's worth re-check your connections and related configurations as you are talking about Z_MAX and SKR 1.4 doesn't have Z_MAX pins.

[mtfisher]

made some changes and forced my bl touch in to OD mode along with trying inversion enabled and disabled.

I commented out the #define BLTOUCH_SET_5V_MODE and enabled #define BLTOUCH_LCD_VOLTAGE_MENU just so i can confirm my probe is in open drain mode. Still getting the same issue as shown in the video

[tatusah]

Actually noticed ENDSTOPPULLDOWN_ZMIN_PROBE defined in your configs for some reason. And the way pull-ups are set I believe this would mean that both are enabled at the same time. So I would disable the pull-down setting by commenting it out. If that doesn't solve it then it's best to start debugging the issue from basics, Like installing physical endstop switch in place of the probe and check if it works correctly and shows both states for the endstop with M119 when you have the switch pressed and released. If normal endstop switch show open when released and triggered when pressed then connecting the BLTouch back instead of the switch should work.

[NickClark]

Following this report intently as I'm seeing the exact same behavior on my SKR 1.4 Turbo.

I'm also plugged into the Z endstop. Before this I was using the designated BLTouch ports and had it rigged to use sensorless homing on Z. Which worked fine, except I'm not happy with sensorless homing on Z (I really wish I could use sensorless Z homing as a backup endstop for emergencies).

I moved the BLTouch to using the endstop port so I could use it for more accurate homing, but I have run into this issue.

[ManuelMcLure]

For grins, try adding

#define ONBOARD_ENDSTOPPULLUPS

in pins_BTT_SKR_V1_4.h and disabling the Z end stop pull-up in Configuration.h. The SKR boards have hardwired pull-ups so turning the chip ones on as well could overwhelm the BLTouch.

[NickClark]

Didn't seem to work for me....

[JudgeZ]

Did you cut the diag pin on the 2209s? This is a necessary step for the 2209s without sensorless homing. https://github.com/bigtreetech/BIGTREETECH-SKR-V1.3/blob/master/BTT%20SKR%20V1.4/Hardware/BTT%20SKR%20V1.4%20Instruction%20Manual.pdf
I had to cut mine for it to work with the exact same setup.

[thisiskeithb]

The diag lines are permanently connected on the SKR 1.4 and BTT002, so you have to cut the diag pin on the driver for any axis you want to use traditional endstops or ABL probes on.

[NickClark]

Hmm... that's too bad. That's not something that can be ignored in firmware?

Before I go and disfigure my Z 2209... is an alternative to just to re-map the BLProbe port (P0_10) on the SKR 1.4 to be the Y end stop? Or does that not take care of the conflict?

And as an aside: I wish one could use the dedicated BL ports for probe and primary z-endstop, and still use stallguard for backup. My understanding is this is not possible

[NickClark]

Ok... all seems well if I just put the BLTouch back to the SKR 1.4's Probe pin and change Marlin\src\pins\lpc1768\pins_BTT_SKR_V1_4.h to

// #define Z_STOP_PIN         P1_27
#define Z_STOP_PIN         P0_10

I wish I didn't have to change this in Marlins src. Seems likely to be a common need, since I wouldn't be suprised if most people owning a 1.4 board with 2209's will be using sensorless homing for X and Y and a probe for Z. This avoids having to mangle your Z driver.

[mtfisher]

@NickClark any chance you can publish your config somewhere for reference. Going to try some more of the suggestions later tonight

[mtfisher]

Just to mention I did cut the sensorless homing pins on 2209s

[mtfisher]

Made the ENDSTOPPULLDOWN_ZMIN_PROBE definition and I am still getting the same issue. Also just to mention all the sensorless homing pins have been cut on all my drivers.

my configs are now:

https://www.dropbox.com/s/6ib0lvy64l662j3/Configuration_adv.h?dl=0
https://www.dropbox.com/s/0eiv0y2lh68ek1g/Configuration.h?dl=0

Also just to confirm I have no objections to useing the z min endstop port on the board

[NickClark]

@mtfisher Sure, I'll try to do that after work today. Interesting... you say you did cut the pins and it didn't work? Maybe our problems are different after all. Although I never did trim the pins, just switched to using P0_10 instead. So far all the research I've done on this problem concludes with one of the following as the issues:

1. The BLTouch was connected to the mainboard backwards.
2. The BLTouch was bad
3. They didn't clip the pin

[mtfisher]

@NickClark turns out The BLTouch was connected to the mainboard backwards was the issue. As I am using the old wiring loom from my melzi board while I wait for a new cable. I can confirm that I am am able to home after flipping pins as the pin layout is different from the melzi board.

Sorry for taking up everyones time. But its worth referencing this post in case someone in future comes along

[mtfisher]

closing

[NickClark]

@mtfisher Hey! Not bother here for sure! It got me going the right direction and will most definitely help someone else in the near future. I'm just super pleased that switching the endstop pin to P0_10 fixed it. It would be nice if this was configurable from 'Configuration_adv.h' though.

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