I believe there is some weirdness with bugfix-2.0 and some definitions in Conditionals_LCD.h
Here:
#define HOMING_Z_WITH_PROBE (Z_HOME_DIR < 0 && !HAS_CUSTOM_PROBE_PIN)
HOMING_Z_WITH_PROBE will be 0 if you have a custom probe pin. If HOMING_Z_WITH_PROBE is false, BLTouch probes won't deploy based on this in motion.c:
```
#if HOMING_Z_WITH_PROBE && ENABLED(BLTOUCH)
if (axis == Z_AXIS && bltouch.deploy()) return; // The initial DEPLOY
#endif
```
I've gone through to try and see if I have another setting that is overriding somehow (SKR1.4), but I can fix this simply by removing the !HAS_CUSTOM_PROBE_PIN.
In Conditionals_LCD.h
Change the corresponding lines to
#define HAS_CUSTOM_PROBE_PIN true
#define HOMING_Z_WITH_PROBE (Z_HOME_DIR < 0 )
This works for me. Im also using a SKR 1.4 (Turbo)
I might have the same problem. On my MKS_SGEN_L board, Z_MIN connects to the DIAG0 of the z driver to detect stalls when something goes wrong. BLTouch is connected to the Z_MAX pin, so I enabled Z_MAX and Z_MIN as endstopsand set it Z_MAX as custom pin for the probe. BLtouch does not deploy.
I believe there is some weirdness with bugfix-2.0 and some definitions in Conditionals_LCD.h
@paukstelis — If you use a pin other than the Z_MIN_PIN for your probe you must disable Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN, and then you can't home with the probe. You will instead home with the endstop attached to Z_MIN_PIN.
Please fill out the complete template and supply configs when posting reports, because it may be a mis-configuration or it may require a special combination of options to reproduce your issue.
On my MKS_SGEN_L board, Z_MIN connects to the DIAG0 of the z driver to detect stalls when something goes wrong.
To deal with boards that have fixed assignments for their DIAG pins, we've done this sort of thing to allow the free endstop pins to still be usable. (BTT SKR 1.3 as example):
/**
* Trinamic Stallguard pins
*/
#define X_DIAG_PIN P1_29 // X-
#define Y_DIAG_PIN P1_27 // Y-
#define Z_DIAG_PIN P1_25 // Z-
#define E0_DIAG_PIN P1_28 // X+
#define E1_DIAG_PIN P1_26 // Y+
/**
* Limit Switches
*/
#if X_STALL_SENSITIVITY
#define X_STOP_PIN X_DIAG_PIN
#if X_HOME_DIR < 0
#define X_MAX_PIN P1_28 // X+
#else
#define X_MIN_PIN P1_28 // X+
#endif
#else
#define X_MIN_PIN P1_29 // X-
#define X_MAX_PIN P1_28 // X+
#endif
#if Y_STALL_SENSITIVITY
#define Y_STOP_PIN Y_DIAG_PIN
#if Y_HOME_DIR < 0
#define Y_MAX_PIN P1_26 // Y+
#else
#define Y_MIN_PIN P1_26 // Y+
#endif
#else
#define Y_MIN_PIN P1_27 // Y-
#define Y_MAX_PIN P1_26 // Y+
#endif
#if Z_STALL_SENSITIVITY
#define Z_STOP_PIN Z_DIAG_PIN
#if Z_HOME_DIR < 0
#define Z_MAX_PIN P1_24 // Z+
#else
#define Z_MIN_PIN P1_24 // Z+
#endif
#else
#define Z_MIN_PIN P1_25 // Z-
#define Z_MAX_PIN P1_24 // Z+
#endif
So this just needs to be applied to the SGEN-L pins file also.
I believe there is some weirdness with bugfix-2.0 and some definitions in Conditionals_LCD.h
@paukstelis — If you use a pin other than the
Z_MIN_PINfor your probe you must disableZ_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN, and then you can't home with the probe. You will instead home with the endstop attached toZ_MIN_PIN.Please fill out the complete template and supply configs when posting reports, because it may be a mis-configuration or it may require a special combination of options to reproduce your issue.
OK. I can see this leading to confusion (as it already has) with SKR1.4 boards since it has a dedicated probe pin for use with the BLTouch. I guess I don't understand why disabling Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN should mean you can't home with the probe. Maybe SKR1.4 Turbo pins should have a conditional that redefines Z_MIN_PIN to the probe pin if BLTOUCH is defined. That doesn't seem like a very good general solution, however.
Disabling Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN tells Marlin that you (may) be using a min Z endstop. If you're not using a Z endstop, it used to be guaranteed you could use that pin for the probe. But now we have overlapping functions as DIAG pins are signaling these too, and they can't be reassigned to other pins. So the solution left to us now is the pins change outlined above.
That doesn't seem like a very good general solution, however.
Each board finds its own solution. Where can the probe (not just BLTouch) be attached? Does the use of other functions prevent the preferred choice? What is the common use case for the board, and what machines is the board meant to accompany? If the board has DIAG pins that "must pertain to endstops," what pins do they block and how can we least disruptively free those pins for other uses?
They stumble along and arrive at "good enough" eventually.
Damn DIAG pins! Yeah, that makes more sense. I guess just using Z_MIN_PIN with BLTouch is easiest solution. I wonder if you could do something as simple as have an option like HOME_WITH_PROBE that the user can set to signify that the user wants to home with the probe. Presumably that wouldn't preclude triggering from an endstop or DIAG in the event of a probe failure. Maybe I'll take a swing at it and see what breaks.
The above pins actually map perfectly to the MKS SGEN-L, and I see that the DIAG pins are marked on the board and thus I assume hardwired, so I'll commit that change. 633b716a3a Whether or not it helps you and Hamster is to be seen…
What do I have to set in the config for this to work?
//#define Z_MIN_PROBE_PIN P1_24
-> BLTouch deploys and stows several times -> Emergency stop.
//#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
-> BLTouch does not deploy.
There is another issue about that:
https://github.com/MarlinFirmware/Marlin/issues/16886
So, I was having issues getting the probe to deploy on a SKR 1.4 Turbo using the servo connection and dedicated probe pins during a G28.
I made the following changes and now it is working as expected.
conditionals_LCD.h
Change this
#define HAS_PROBE_XY_OFFSET DISABLED(NOZZLE_AS_PROBE)
#define HAS_CUSTOM_PROBE_PIN DISABLED(Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN)
#define HOMING_Z_WITH_PROBE (Z_HOME_DIR < 0 && !HAS_CUSTOM_PROBE_PIN)
To the following
#define HAS_PROBE_XY_OFFSET true
#define HAS_CUSTOM_PROBE_PIN true
#define HOMING_Z_WITH_PROBE Z_HOME_DIR < 0
In Configuration.h:
//#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
in Marlin/src/pins/pins_BTT_SKR_V1_4.h:
And now G28 deploys the probe just before making the Z-Axis down movement to probe the center of the bed.
In Conditionals_LCD.h
Change the corresponding lines to#define HAS_CUSTOM_PROBE_PIN true #define HOMING_Z_WITH_PROBE (Z_HOME_DIR < 0 )This works for me. Im also using a SKR 1.4 (Turbo)
Adding these two lines worked for me on build 2.0.5.1 using SKR 1.4 Turbo and BLTouch 3 using the specific Zprobe pin (defined as P0_10 in pins)
Thanks!
Same issue here: 2.0.5.1 / SKR 1.4 Turbo BL Touch 3.1
i'm new to marlin but it seems like there is opposing logic in the code part of which i'm not 100% on
from Configuration.h
/**
* Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
*
* Enable this option for a probe connected to the Z Min endstop pin.
*/
#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
suggests that on the SKR 1.4 board that it should be commented out since it doesn't use the Z_MIN_ENDSTOP_PIN ... but the logic in Conditionals_LCD.h conflicts with this when defining HOMING_Z_WITH_PROBE
#if HAS_BED_PROBE
#if DISABLED(NOZZLE_AS_PROBE)
#define HAS_PROBE_XY_OFFSET 1
#endif
#if DISABLED(Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN)
#define HAS_CUSTOM_PROBE_PIN 1
#endif
#if Z_HOME_DIR < 0 && !HAS_CUSTOM_PROBE_PIN //*** issue?
#define HOMING_Z_WITH_PROBE 1
#endif
#ifndef Z_PROBE_LOW_POINT
#define Z_PROBE_LOW_POINT -5
#endif
#if ENABLED(Z_PROBE_ALLEN_KEY)
#define PROBE_TRIGGERED_WHEN_STOWED_TEST 1 // Extra test for Allen Key Probe
#endif
#if MULTIPLE_PROBING > 1
#if EXTRA_PROBING
#define TOTAL_PROBING (MULTIPLE_PROBING + EXTRA_PROBING)
#else
#define TOTAL_PROBING MULTIPLE_PROBING
#endif
#endif
#else
when you comment out Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN ... it sets HAS_CUSTOM_PROBE_PIN 1 and prevents #if Z_HOME_DIR < 0 && !HAS_CUSTOM_PROBE_PIN from evaluating as true.
My question is .. when configuring the BLTOUCH on the SKR 1.4 or any board for that matter, should
#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
be commented out ? or not?
@paukstelis is the issue gone?
Lack of Activity
This issue is being closed due to lack of activity. If you have solved the
issue, please let us know how you solved it. If you haven't, please tell us
what else you've tried in the meantime, and possibly this issue will be
reopened.
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.