Marlin: [BUG] Z homing with BLTouch and Z-endstop switch

[bojanpotocnik]

I know this is the same title as #12726, however I rather started a new issue for clarity as I made quite a few tests. It is also hard to decide if this is a [BUG] or [FR] for Marlin, however it is certainly [BUG] for me.

I have Ender 3 with SKR Mini E3 v1.2 board, which has separate connectors for Z-endstop switch and BLTouch probe. For the whole day I am trying to configure Marlin bugfix-2.0.x to achieve seemingly very simple things:

• Always monitor endstop switches when moving. This is a no-brainer for every CNC owner which finds it logical for Endstop and E-Stop switches being de-facto limits which unconditionaly stop _any_ CNC movement (unless disabled with M121). However, this is not so straightforward to achieve with Marlin - there is ENDSTOPS_ALWAYS_ON_DEFAULT in Configuration_adv.h, however look at the following line.
• By always I also mean when homing. This gramatically and logically indeed falls under previous line, but look at Option 7.
• If BLTouch is present and enabled, use it for homing.

That's it. Below is the description of all combinations of configurations, tested on the Ender 3 using SKR Mini E3 v1.2 with Z-endstop switch connected to the Z-STOP connector (PC2) and BLTouch connected to the SERVOS and PROBE connector (PC14).

Setup

Thanks to #7470, #define ENDSTOPS_ALWAYS_ON_DEFAULT is always uncommented (enabled). In every step/combination, all other relevant configuration defines are shown for clarity. All 4 files are also in the attached Base config (Z-endstop only, no BLTouch, homing at X=0, Y=0).zip file, the configuration in them matches the config in Option 1.

Steps to Reproduce

Option 1

/* pins_BTT_SKR_MINI_E3_V1_2.h */
#define Z_STOP_PIN         PC2
#define Z_MIN_PROBE_PIN    PC14
/* Configuration.h */
//#define BLTOUCH
//#define Z_SAFE_HOMING
//#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
/* Conditionals_LCD.h */
  #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)

Default configuration, using only Z-endstop switch as Z-endstop. Printer homes X and Y, then Z at the same spot (X = 0, Y = 0).

1. :heavy_check_mark: Z-endstop switch is monitored while homing Z.
2. :heavy_check_mark: BLTouch is ignored (not deployed nor monitored) while homing Z.
3. :heavy_check_mark: No BLTouch LCD menu.
4. :heavy_check_mark: Z-endstop switch is monitored when moving Z axis down via LCD menu or G0.

From this point onwards, the following is also uncommented:

// Configuration.h
#define ENDSTOPPULLUP_ZMIN_PROBE
// Configuration_adv.h
#define BABYSTEP_ZPROBE_OFFSET          // Combine M851 Z and Babystepping
#define BABYSTEP_ZPROBE_GFX_OVERLAY   // Enable graphical overlay on Z-offset editor

In every of the following options, after homing X and Y, printer goes to the center of the bed and performs Z-homing (Z_SAFE_HOMING) :heavy_check_mark:.

Option 2

/* pins_BTT_SKR_MINI_E3_V1_2.h */
#define Z_STOP_PIN         PC2
#define Z_MIN_PROBE_PIN    PC14
/* Configuration.h */
#define BLTOUCH
#define Z_SAFE_HOMING
//#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
/* Conditionals_LCD.h */
  #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)

1. :heavy_check_mark: Z-endstop switch is monitored while homing Z.
2. :heavy_multiplication_x: BLTouch is not deployed nor monitored. This could be intentional as indeed the BLTouch is attached, but we didn't explicitly specify that it must be used as a Z probe. But what else to uncomment, then? :interrobang:
3. :heavy_check_mark: BLTouch LCD menu is present, Stow and Deploy are working properly.
4. :heavy_check_mark: Z-endstop switch is monitored when moving Z axis down via LCD menu or G0.

Option 3

/* pins_BTT_SKR_MINI_E3_V1_2.h */
#define Z_STOP_PIN         PC2
#define Z_MIN_PROBE_PIN    PC14
/* Configuration.h */
#define BLTOUCH
#define Z_SAFE_HOMING
#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
/* Conditionals_LCD.h */
  #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)

1. :heavy_check_mark: Z-endstop switch is monitored while homing Z.
2. :heavy_check_mark: BLTouch is deployed while homing Z.
3. :heavy_check_mark: BLTouch is not monitored while homing Z. This is indeed :heavy_exclamation_mark:, however with Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN we specified that the BLTouch is connected to the Z-endstop switch pin, therefore it is :heavy_check_mark: that Marlin only monitors Z-endstop switch because it thinks it is actually the BLTouch.
4. :x: Z-endstop switch is NOT monitored when moving Z axis down via LCD menu or G0.

Option 4

/* pins_BTT_SKR_MINI_E3_V1_2.h */
#define Z_STOP_PIN         PC14 // PC2
//#define Z_MIN_PROBE_PIN    PC14
/* Configuration.h */
#define BLTOUCH
#define Z_SAFE_HOMING
#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
/* Conditionals_LCD.h */
  #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)

1. :heavy_check_mark: Z-endstop switch is NOT monitored while homing Z. This is indeed :heavy_exclamation_mark:, however from the FW standpoint the Z-endstop switch hardware connection does not even exist.
2. :heavy_check_mark: BLTouch is deployed while homing Z.
3. :heavy_check_mark: BLTouch is monitored while homing Z.
4. :heavy_check_mark: Z-endstop switch is NOT monitored when moving Z axis down via LCD menu or G0. This is indeed :x: from a mechanical standpoint, however as said in point 1, the Z-endpoint switch does not even exist from the FW standpoint.

:x: overall despite all :heavy_check_mark:, because we lost the Z-endstop switch.

Option 5

/* pins_BTT_SKR_MINI_E3_V1_2.h */
#define Z_STOP_PIN         PC2
#define Z_MIN_PROBE_PIN    PC14
/* Configuration.h */
#define BLTOUCH
#define Z_SAFE_HOMING
#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
/* Conditionals_LCD.h */
  #define HAS_CUSTOM_PROBE_PIN  true // DISABLED(Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN)
  #define HOMING_Z_WITH_PROBE   (Z_HOME_DIR < 0 && !HAS_CUSTOM_PROBE_PIN)

This was accidentally tested as I forgot to comment #define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN.

1. :x: Z-endstop switch is NOT monitored while homing Z.
2. :x: BLTouch is NOT deployed while homing Z.
3. :heavy_check_mark: BLTouch is not monitored while homing Z. This is not :x: because of the reason described in Option 3 point 3.
4. :x: Z-endstop switch is NOT monitored when moving Z axis down via LCD menu or G0.

Effectively printer is unstoppable when homing Z and will smash to the bed.

Option 6

/* pins_BTT_SKR_MINI_E3_V1_2.h */
#define Z_STOP_PIN         PC2
#define Z_MIN_PROBE_PIN    PC14
/* Configuration.h */
#define BLTOUCH
#define Z_SAFE_HOMING
//#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
/* Conditionals_LCD.h */
  #define HAS_CUSTOM_PROBE_PIN  true // DISABLED(Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN)
  #define HOMING_Z_WITH_PROBE   (Z_HOME_DIR < 0 && !HAS_CUSTOM_PROBE_PIN)

1. :heavy_check_mark: Z-endstop switch is monitored while homing Z.
2. :x: BLTouch is NOT deployed while homing Z.
3. :x: BLTouch is NOT monitored while homing Z.
4. :heavy_check_mark: Z-endstop switch is monitored when moving Z axis down via LCD menu or G0.

Option 7

/* pins_BTT_SKR_MINI_E3_V1_2.h */
#define Z_STOP_PIN         PC2
#define Z_MIN_PROBE_PIN    PC14
/* Configuration.h */
#define BLTOUCH
#define Z_SAFE_HOMING
//#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
/* Conditionals_LCD.h */
  #define HAS_CUSTOM_PROBE_PIN  true // DISABLED(Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN)
  #define HOMING_Z_WITH_PROBE   (Z_HOME_DIR < 0)

1. :x: Z-endstop switch is NOT monitored while homing Z.
2. :heavy_check_mark: BLTouch is deployed while homing Z.
3. :heavy_check_mark: BLTouch is monitored while homing Z.
4. :heavy_check_mark: Z-endstop switch is monitored when moving Z axis down via LCD menu or G0.

Option ?

I have run out of ideas. Maybe the solution would be:

/* Conditionals_LCD.h */
  #define HAS_CUSTOM_PROBE_PIN  (defined(Z_STOP_PIN) && defined(Z_MIN_PROBE_PIN) && (Z_STOP_PIN != Z_MIN_PROBE_PIN))
  #define HOMING_Z_WITH_PROBE   (Z_HOME_DIR < 0)

and some fix for Option 7 point 1.

[boelle]

@bojanpotocnik is this a bug or ???

[bojanpotocnik]

Well, it is a bug and a question/feature request - maybe I'm just missing something.

The bug part:

Description

Z-endstop is ignored while homing if using BLTouch probe despite the ENDSTOPS_ALWAYS_ON_DEFAULT is enabled.

Steps to Reproduce

1. Configure the FW as in the Option 7 above.
2. Start Z homing.
3. Simulate the BLTouch malfunction or just mount the BLTouch probe too high - so the Z endstop switch will be triggered before the BLTouch probe (or just trigger it by hand before the BLTouch is triggered).

Expected behavior: Z homing is stopped as soon as (BLTouch or) Z-endstop switch is triggered.

Actual behavior: Z-endstop switch is ignored, Z homing stops only when the BLTouch probe is triggered.

And now for the feature request / question part:

Should it be by default or at least possible for the the user to use Z-endstop switch and BLTouch probe simultaneously without editing the Conditionals_LCD.h file as described in the Option 7 above? Or is there any other combination of configurations (or Option in my initial post) to achieve this functionality?

[boelle]

can we split it up 2? ie one bug and one fr ?

[bojanpotocnik]

Hmm, is the other thing more of a bug

BLTouch is not used if using separate pin (that is if Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN is disabled)"

because of the HOMING_Z_WITH_PROBE logic in Conditionals_LCD.h,or a feature request

Cofiguration option to use Z-endstop switch and BLTouch probe simultaneously

?
Reading this again I do not understand the HOMING_Z_WITH_PROBE logic - shouldn't the normal operation of the Z-endstop switch be retained (unless configured otherwise, e.g. with Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN or commenting #define Z_STOP_PIN) and BLTouch probe just used in conjunction if the BLTOUCH is defined?

[dinamitemic]

+1 for this logical behaviour. I was think the exact same thing. I've an skr mini v1.1 so same mcu.
Right now I'm in option 2 and looking for a solution in order to get option 7 working.

[boelle]

@bojanpotocnik please split this up in a bug and then a feature request so the 2 things are not mixed

[boelle]

will temp close this one until its split up in a bug and one feature request

[Releece]

I have the same issue with my both brand new SKR1.4 & BL-Touch, installed on my Creality Ender 4. My BLT was functioning correctly: controllable with G-Code commands, M119 gave triggered & open responses when deploying BLT probing pin and pushing it up by hand. However when homing Z the BLT probe signal was ignored every time & only the Z endpoint switch would conclude the homing. I tried an enormous amount of settings on/off, trying to use as little changes as possible to firmware, but growing in changes because I had simply tried every possible combination. Disabling Z endpoint would just result in the bed crashing/grinding against my nozzle after my BLT measured and indicated a STOP signal in time, until reset/power off.

Until I found this issue! With the settings in option #7 from @bojanpotocnik it all suddenly worked. Note that I tried tens of firmware settings except editing Conditionals_LCD.h. This has been the key to fix my issue, except it is not straightforward or well documented at all. I hope others with similar issues can find a solution here. My case would most certainly on it's own be a BUG if using BLT homing does not work until using HOMING_Z_WITH_PROBE from a very unknown file such as Conditionals_LCD.h

I want to point out that using BLT in conjunction with a Z endstop switch is so simple in essence and important, a more complex & fragile Z-probe protecting important parts like nozzle, bed, belts should have a fail-safe. Making this fully functional and easily selectable is a wise idea. @bojanpotocnik did excellent work in documenting and analyzing this problem. Wich part is a BUG or FEATURE REQUEST is just simply a matter of perspective and even argumenting this binary descision get's endlessly complex, stopping @bojanpotocnik, me or someone else to continue this issue. That shouldn't be a reason for this to just become forgotten. Is there no way to get attention from someone with enough expertise who can make this nessecary distinction?

PS: probably irrelevant, but I use 4x TMC2209 with DIAG pin cut off on XYZ

[emaayan]

@bojanpotocnik please split this up in a bug and then a feature request so the 2 things are not mixed

it's a bug. period, the real issue is that marlin does not allow the usage of a custom pin as a BL-TOUCH probe connector as the new SKR boards are made for. everything else is not relevant, z-min should be not effected by this, and triggering it should stop the printer as it did in the past, and if it doesn't , then it's another bug.
the expected behavior when you connect a bl-touch to anything else other then z-min is that triggering the bl-touch should stop the printer as though it was connected to z-min.
i would have opened another bug on it, but as you can see, someone already did, and with growing popularity of SKR board you'll probably have more bugs like this.

[stantond]

@boelle there are two bugs here, I can't see an FR.

One I already raised, #16839. This deals with not being able to Z home with a probe when using a dedicated probe pin.

The other bug (I suggest reopening and renaming this issue) would be "[BUG] Z endstop is ignored when homing with separate Z probe despite defining ENDSTOPS_ALWAYS_ON_DEFAULT"

[AnHardt]

A probe is not an endstop. An endstop is not a probe. A probe can be used as a z-min-home-switch, not as a z-min-security-endstop.
A probe needs to be deployed, or at least switched on.
ENDSTOPS_ALWAYS_ON_DEFAULT reacts on endstops, not probes by purpose. Else you could not print at low altitudes (with probes like inductive, capacitiv, ...)

When this was invented about no board had dedicated pins for a probe. The simplest way was to use a unused endstop-pin. Most of us just simply replaced the z-min-endstop with a probe. PROBE_USES_Z_MIN_ENDSTOP implied there is no z-min-endstop - use the probe for homing z to min. Defining a dedicated probe-pin implied there is a z-min-endstop and to use that for homing.

Now - since more boards do have a dedicated probe-pin we could rethink that.

[emaayan]

A probe is not an endstop. An endstop is not a probe.
A probe needs to be deployed, or at least switched on.
ENDSTOPS_ALWAYS_ON_DEFAULT reacts on endstops, not probes by purpose. Else you could not print at low altitudes (with probes like inductive, capacitiv, ...)

When this was invented about no board had dedicated pins for a probe. The simplest way was to use a unused endstop-pin. Most of us just simply replaced the z-min-endstop with a probe. PROBE_USES_Z_MIN_ENDSTOP implied there is no z-min-endstop - use the probe for homing z to min. Defining a dedicated probe-pin implied there is a z-min-endstop and to use that for homing.

Now - since more boards do have a dedicated probe-pin we could rethink that.

yep, but in the mean time you could probably add some more documentation , probably near the Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN field clarifying the use of the dedicated probe connector

[InsanityAutomation]

Option 1 : Good
Option 2 : Needs method to intentionally force off the endstop pin (use_zmin_plug disabled, home dir <1 probe pin set and probe enabled) - Bug
Option 3 : Expected as the bltouch normally only triggers as a pulse and otherwise a constant trigger is considered a fault. Also many capacitive or IR probes will view the part you are printing as a trigger. Not feasible here.
Option 4 : most common setup and really identical functionally to 3
Option 5 : Forcing calculated value led to unintended but expected results. It was trying to use an endstop on the same pin because of the flag.
Option 6 : expected, probe is only used for mesh generation in that config
Option 7 : Same configuration option needed from Option 2

As far as I can see there is only 1 actionable item here. #16839 encompasses that item.

[stantond]

@InsanityAutomation I _think_ there's an additional piece here - when both Z Probe and Z endstop are connected, provide an option to listen to both probe _and_ endstop for homing, stopping when either one of them triggers.

On a good setup, this isn't really required, but when getting to that point, it seems crashing into the bed isn't as uncommon as it should be, and a probe can fail even after working for some time. It's certainly no physical hardship to have both probe and endstop installed - I suspect many users have the endstop from the factory and add a probe later - so this would provide a safety feature which becomes more applicable as more boards introduce a dedicated Z Probe pin, and takes advantage of hardware that many Marlin users will already have.

[AnimeEd]

I'm new to bltouch and found this thread while planning to put in my probe. I'm surprised this hasn't been figured out and intergrated as it seems like basic functionality. Having now told you my inexperience, please allow me to ask a potentially stupid question. Can option 7 be accomplished by connecting the probe of the bltouch and the z endstop in parallel? Assuming they are sending the same signal, to the board, the end switch would represent a lower bound for the probe. It would be a dirty hack though.

[emtrax-ltd]

I fully agree with: "A probe is not an endstop. An endstop is not a probe"
if Z_MIN_PROBE_PIN is configured with additional probe functionality, then there are the two following use cases for the Z_STOP_PIN

1) Triggering Z_STOP_PIN interrupts homing and leveling completely - failsafe when probe is failing
2) Triggering Z_STOP_PIN is combinded with probe signal - "first come, first served"

In "failsafe" mode the trigger of Z_STOP_PIN should be mounted 0.5-1.0 mm under the trigger point of the probe. So it prevents the head from crashing into the bed and breaking thinner glasses or making some nice holes into the surface. The "combined" mode is more a "soft failsafe", if probe has failed or is missing (for unknown reason). It then behaves like classic homing with manually leveled bed (traditional way).

[BoothyBoothy]

I have been struggling for a week with a new BL Touch and a SKR V1.4 Turbo (TMC2209s with sensorless homing on the X only) with Marlin 020004 on a Hypercupe Evo Core XY Build. As soon as I used the option 7 suggestion in Conditionals_LCD.h as per Releece`s comments above everything worked perfectly straight away. Best Boothy.

[AnimeEd]

Just to be clear, when you guys say option 7 works, the end switch is still not being monitoring during homing, correct?

[BoothyBoothy]

Hi, I changed my firmware settings in conditionals_lcd.h as per the attached screen grab from the default and the 5 test prints I have undertaken since have worked well with the BLTouch with no problems. Prior to changing these settings I was getting repeat lack of homing on Z and home failures with a request to reset. I am techy but no coder so you have to bear with my results only comments\response. When you say not being monitored do you mean the Z end switch is disabled ? In my case changing these settings made the Z end stop work in conjunction with the probe when homing .Before these changes it did not work at all even though I had the //#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN disabled\uncommented in configuration.h due to the SKR V1.4 board having a specific set of BLTouch connectors. Apologies again for my lack of experience. Best Boothy

[emtrax-ltd]

Option 7 only works when you enforce "HOMING_Z_WITH_PROBE" by commenting out the check of "!HAS_CUSTOM_PROBE_PIN" in 'inc/Conditionals_LCD.h'.

marlin 4.0.5

In the code you can see, that the author disabled homing with a probe explicitly if a custom probe pin was configured.

The original z-min-pin is not monitored during homing or printing with this configuration!

[github-actions[bot]]

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.