Marlin: [BUG] BL Touch on SKR PRO 1.1 without Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN doesn't work on G28

Created on 17 Dec 2019  Â·  18Comments  Â·  Source: MarlinFirmware/Marlin

Bug Description

BL Touch does not deploy on G28 if Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN is disabled on SKR Pro 1.1.
It works without any issues on Configuration -> BLTouch and M43 Probe test.
It also works when enabling Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN and set Z_MIN_PIN to PA2 which is the same pin like Z_MIN_PROBE_PIN.

Send: M43 S
Recv: Servo probe test
Recv: . using index:  0, deploy angle: 10, stow angle:   90
Recv: . Probe Z_MIN_PROBE_PIN: 37
Recv: . Z_MIN_PROBE_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 (+/- 4ms): 12
Recv: = BLTouch pre V3.1 (or compatible) detected.

My Configurations

config.zip

Steps to Reproduce

  1. Connect BL Touch to the Probe header on SKR Pro 1.1
  2. Ensure Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN is disabled in Configuration.h
  3. Issue G28

Expected behavior: [What you expect to happen]
BL Touch deploys and works

Actual behavior: [What actually happens]
BL Touch doesn't deploy.

Most helpful comment

Originally Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN had additional information. Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN implicit says "There is no other z-min-endstop - we have only a probe - so if you want to home to z-min you have to deploy the probe".
While an active Z_MIN_PROBE_PIN told: " The probe is not connected to z-min-endstop but here. So we have the z-min-endstop pin occupied by a read endstop - we don't need to deploy the probe when we home to z-min,"

All 18 comments

This is the same issue with SKR 1.3. Even though Z_MIN_PROBE_PIN is defined in the pin files, but if you look at these boards, there is no separate Z_MIN_PROBE_PIN - so you are using / have to use Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN.
If you are using VSCode with intelliSense, when you disable Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN, a warning is generated for SET_INPUT_PULLUP on line 248 in endstops.cpp stating that:
Identifier "DIOP1_24_DDR" is undefined

Although this warning doesn't show up when compiling, it seems to be important enough to cause the probe not to operate as it should.

I will investigate further.

I would recommend looking at issue #5705 as well, scroll down to Bob-the-Kuhn commented on Jan 16, 2017.

I struggled with the same issue, and found many similar posts.

I believe I found a simple solution (work around/hack)

Configure the setup to use Zmin and not the Zmin probe.

Hardware change:
Plug the BLTouch sensing wire into the Zmin plug. White in Z- (PG8), Black in GND. As per SKR-PRO-V1.1-Pin.pdf

Marlin configuration (standard BLTouch config plus a change in SKR_PRO_V1_1 pins)

Marlin\src\pins\stm32\pins_BTT_SKR_PRO_V1_1.h
// Z Probe must be this pins

ifndef Z_MIN_PROBE_PIN

/// #define Z_MIN_PROBE_PIN PA2

endif

Configuration.h
// Endstop Settings

define USE_XMIN_PLUG

define USE_YMIN_PLUG

#define USE_ZMIN_PLUG

define USE_XMAX_PLUG

define USE_YMAX_PLUG

//#define USE_ZMAX_PLUG

// Enable pullup for all endstops to prevent a floating state

define ENDSTOPPULLUPS

// Mechanical endstop with COM to ground and NC to Signal uses "false" here (most common setup).

define X_MIN_ENDSTOP_INVERTING false // Set to true to invert the logic of the endstop.

define Y_MIN_ENDSTOP_INVERTING false // Set to true to invert the logic of the endstop.

#define Z_MIN_ENDSTOP_INVERTING false // Set to true to invert the logic of the endstop.

define X_MAX_ENDSTOP_INVERTING false // Set to true to invert the logic of the endstop.

define Y_MAX_ENDSTOP_INVERTING false // Set to true to invert the logic of the endstop.

define Z_MAX_ENDSTOP_INVERTING false // Set to true to invert the logic of the endstop.

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

define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN

//#define Z_MIN_PROBE_PIN PA2 // Defined in pins

define BLTOUCH

Configuration_adv.h
#define BLTOUCH_DELAY 500

//Take note of the 5V warning preceding this line in the Marlin FW

define BLTOUCH_SET_5V_MODE

And that is all.

I think the recommendation is outdated. There is no need to undefine * Z_MIN_PROBE_PIN* and with BLTouch, the logic of the endstop is always automatically set to false:

in Conditionals_LCD.h

// Always disable probe pin inverting for BLTouch
  #undef Z_MIN_PROBE_ENDSTOP_INVERTING
  #define Z_MIN_PROBE_ENDSTOP_INVERTING false
  #if ENABLED(Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN)
    #undef Z_MIN_ENDSTOP_INVERTING
    #define Z_MIN_ENDSTOP_INVERTING false
  #endif

The only things needed are:
BLTOUCH
Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
USE_ZMIN_PLUG

SKR PRO 1.1 Marlin 2.0 or Marlin-bugfix-2.0

BLTouch working fine for me. G28, G29 , Z auto align

Using BLTouch Header

configuration.h

line: 659 #define Z_MIN_PROBE_ENDSTOP_INVERTING true // Set to true to invert the logic of the probe.
line: 829 #define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
line: 879 #define BLTOUCH

pins_BTT_SKR_PRO_V1_1.h

line: 49 #define Z_MIN_PIN PA2 // PG8 BLTouch Header Pin

line: 659 #define Z_MIN_PROBE_ENDSTOP_INVERTING true // Set to true to invert the logic of the probe.

this part is not necessarily since it is always reset to false in Conditionals_LCD.h for the BLTouch - see my comment above.

Ok thanks

@DarkShortie is the issue still the same with all the updates in the last 7 days?

btw, who can confirm there is an issue? use the same configs as OP and the same hardware if possible

I just tried it with the latest code, it's commit 1c9ccce5209cd1727bf80e632f4f781c651e0c35 and the result slightly changed.

At the first test when opening the bug report it didn't deploy but Z started to move down, now it doesn't deploy, but Z doesn't move down and leveling is finished. It looks like the endstop is directly hit.

M43 S results are still the same.
One thing I've just recognized is that M43 S reports Probe Z_MIN_PROBE_PIN: 37 but it should be PA2.

Also the probe is not in the center of the bed, but the nozzle is.

When I just enable Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN and change the pins between Z_MIN_PIN and Z_MIN_PROBE_PIN it works again, also the probe pin is now again in the center of the bed.

With Marlin-2.0.x

I use the default Marlin settings, but with the BLTouch limit sensor connected to Z Min and it works fine. No changes to pins file.

// Mechanical endstop with COM to ground and NC to Signal uses "false" here (most common setup).

define X_MIN_ENDSTOP_INVERTING false // Set to true to invert the logic of the endstop.

define Y_MIN_ENDSTOP_INVERTING false // Set to true to invert the logic of the endstop.

define Z_MIN_ENDSTOP_INVERTING false // Set to true to invert the logic of the endstop.

define X_MAX_ENDSTOP_INVERTING false // Set to true to invert the logic of the endstop.

define Y_MAX_ENDSTOP_INVERTING false // Set to true to invert the logic of the endstop.

define Z_MAX_ENDSTOP_INVERTING false // Set to true to invert the logic of the endstop.

define Z_MIN_PROBE_ENDSTOP_INVERTING false // Set to true to invert the logic of the probe.

This is not a bug. These boards (SKR PRO 1.1 and SKR 1.3) don't physically have a Z_MIN_PROBE_PIN. User must use Z_MIN_PIN and thus must enable Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN. Z_MIN_PROBE_ENDSTOP_INVERTING does not need configuring as it is always automatically set to false for BLTouch.

The confusion arises with the declaration of Z_MIN_PROBE_PIN pin in the pin files.

//
// Z Probe (when not Z_MIN_PIN)
//
#ifndef Z_MIN_PROBE_PIN
  #define Z_MIN_PROBE_PIN  P1_24
#endif

Note the comment (For whatever reason @Msq001 has changed it to // Z Probe must be this pins in pins_BTT_SKR_PRO_V1_1.h which doesn't make it as clear as the original comment.)

These boards (SKR PRO 1.1 and SKR 1.3) don't physically have a Z_MIN_PROBE_PIN.

Actually, the SKR Pro does have a probe pin on a BLTouch header, although I don't think Marlin lets you use it if you are also using the BLTouch for Zmin homing, it expects that Z_MIN_PIN will be used in that case, even when using a probe.

image

That said, I think the easiest solution for everybody is to just plug the BLTouch into the Zmin header anyway. The only difference is that the probe pin would allow using a single 4-pin connector, but BLTouch doesn't come wired that way anyway.

Zmin on dedicated header works fine, you just change PG8 to PA2 in
pins_BTT_SKR_PRO_V1_1.h file,

define Z_MIN_PIN PA2 // PG8 BLTouch Header Pin You

can use PG8 for anything else ( Like Kill Pin)

In configuration.h you need to uncomment ( around line 829 ) #define
Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN

On Thu, Dec 26, 2019 at 4:48 PM Jason Smith notifications@github.com
wrote:

These boards (SKR PRO 1.1 and SKR 1.3) don't physically have a
Z_MIN_PROBE_PIN.

Actually, the SKR Pro does have a probe pin on a BLTouch header, although
I don't think Marlin lets you use it if you are also using the BLTouch for
Zmin homing, it expects that Z_MIN_PIN will be used in that case, even when
using a probe.

[image: image]
https://user-images.githubusercontent.com/20053467/71492755-909b0680-27ee-11ea-9916-11649ae77e1c.png

That said, I think the easiest solution for everybody is to just plug the
BLTouch into the Zmin header anyway. The only difference is that the probe
pin would allow using a single 4-pin connector, but BLTouch doesn't come
wired that way anyway.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/16244?email_source=notifications&email_token=AAXKJNNHCCFM4PWNPWBRV2LQ2UYFXA5CNFSM4J37BWJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHWHQ7Q#issuecomment-569145470,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAXKJNKHNFNHBH4CKOHN5GLQ2UYFXANCNFSM4J37BWJQ
.

Why is this closed now? The issue is still there.

SKR Pro 1.1 has a Probe pin, which is also defined correctly in the pins file (PA2), so I expect that it works when I configure Marlin to use the Z_MIN_PROBE_PIN in the Configuration.h.

Yes, it works if you change Z_MIN_PIN to PA2 and activate Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN but this does render the whole option for Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN useless as you can always argue like this and Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN can be completely removed from the code base.

Originally Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN had additional information. Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN implicit says "There is no other z-min-endstop - we have only a probe - so if you want to home to z-min you have to deploy the probe".
While an active Z_MIN_PROBE_PIN told: " The probe is not connected to z-min-endstop but here. So we have the z-min-endstop pin occupied by a read endstop - we don't need to deploy the probe when we home to z-min,"

Originally Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN had additional information. Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN implicit says "There is no other z-min-endstop - we have only a probe - so if you want to home to z-min you have to deploy the probe".
While an active Z_MIN_PROBE_PIN told: " The probe is not connected to z-min-endstop but here. So we have the z-min-endstop pin occupied by a read endstop - we don't need to deploy the probe when we home to z-min,"

image
not anymore, it seems

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.

Was this page helpful?
0 / 5 - 0 ratings