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.
Expected behavior: [What you expect to happen]
BL Touch deploys and works
Actual behavior: [What actually happens]
BL Touch doesn't deploy.
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
/// #define Z_MIN_PROBE_PIN PA2
Configuration.h
// Endstop Settings
#define USE_ZMIN_PLUG
//#define USE_ZMAX_PLUG
// Enable pullup for all endstops to prevent a floating state
// Mechanical endstop with COM to ground and NC to Signal uses "false" here (most common setup).
#define Z_MIN_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_PIN PA2 // Defined in pins
Configuration_adv.h
#define BLTOUCH_DELAY 500
//Take note of the 5V warning preceding this line in the Marlin FW
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).
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.

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,
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.pngThat 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,"

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.
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,"