Marlin: [BUG] Z-endstop switch ignored while homing when using BLTouch

[bojanpotocnik]

Copied from my comment in #15731.

Description

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

Steps to Reproduce

Have separate pins for Z-endstop switch and BLTouch probe (in my case SKR Mini E3 v1.2):

/* pins_BTT_SKR_MINI_E3_V1_2.h */
#define Z_STOP_PIN         PC2
#define Z_MIN_PROBE_PIN    PC14

Enable ENDSTOPS_ALWAYS_ON_DEFAULT in Configuration_adv.h:

/* Configuration_adv.h */
#define ENDSTOPS_ALWAYS_ON_DEFAULT

Enable BLTouch in Configuration.h:

/* Configuration.h */
#define BLTOUCH
#define Z_SAFE_HOMING
//#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN

Change "logic" in the Conditionals_LCD.h to perform HOMING_Z_WITH_PROBE even if it uses the custom pin (remove && !HAS_CUSTOM_PROBE_PIN)

/* Conditionals_LCD.h */
  #define HAS_CUSTOM_PROBE_PIN  DISABLED(Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_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) // && !HAS_CUSTOM_PROBE_PIN)

1. Home XY, start Z homing.
2. 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 the Z-endstop switch by hand before the BLTouch is triggered).

Expected behavior: Z homing is stopped as soon as BLTouch or Z-endstop switch is triggered, therefore in this case, as soon as Z-endstop switch is triggered.

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

Additional Information

ENDSTOPS_ALWAYS_ON_DEFAULT otherwise works - the movement is stopped when Z axis is moved via LCD menu or via G0 whenever Z-endstop switch is triggered.

Configuration.h, Configuration_adv.h and Conditionals_LCD.h.zip

[psavva]

How does it make sense use both z min endstop and bltouch?
Isn't the BLT supposed to be the z endstop ultimately?

[bojanpotocnik]

We could say so, yes. But we can also look at it as a probe tool (which sometimes fails). Let me explain.

CNC machines always react on the endstops or motor stall detection, the reason is pretty simple: if the CNC machine is moving and the endstop switch is hit or the motor is suddenly stalled - _something went wrong_ or the axis reached its moving limit - in any case, _the movement in that direction just cannot / must not continue_.

Our 3D printers are usually so cheap, motors nearly as powerful and the frame nearly as rigid that we ignore those logical safety measures in exchange for less MCU work (faster loop times). I understand that on AVR MCU we need to spare CPU cycles and disable features we _don't usually need_, that's what the #define ENDSTOPS_ALWAYS_ON_DEFAULT is for, disabled by default.
However on the MCUs powerful enough, ideally we would always check for the endstops and the TMC motor stall detection (Trinamic motor drivers has special _stallGuard Interrupt_ for that), because there is really no debate about continuing movement in that direction if any of those trigger (except for special cases when the user explicitly turns this off using commands).
There are users which report that BLTouch sometimes fail (I know there are solutions for that, but lets ignore it now), they configure it incorrectly,.. maybe there is some hardware obstacle, etc... and the poor printer just continues to force push the axis into that direction.
We could say it is not significant and we don't reall need to care... but there are separate connectors on the controller board to enable us having both of them connected. Why not actually use that benefit?

[boelle]

@bojanpotocnik is this still an issue? a lot of updates are added constantly so it might have been fixed

[Nicolaski3D]

I have exactly the same issue with:

SKR PRO V1.1 board

1/ I think about a bug. I did few test, If I add an limitswitch on Z additionnaly of the BL touch It will work.
The BLtouch not react: stay in his position "triggered"

2/ If I change the program and Write

define Z_MIN_PIN PG8

define Z_MIN_PROBE_PIN Z_MIN_PIN

BL touch sensor will be released but it will be ignored as endstop.

[Nicolaski3D]

I found a solution for me, It's work properly:
on this config:
SKR PRO V1.1 - BLTouch V3.1 - TMC 2209 UART - TFT35

Soon i will write a help to properly configurate, i spent 2 days on this problem...

[boelle]

@Nicolaski3D so this is not an issue but more wrong setup?

[Nicolaski3D]

I have 10 min so I try to write help. i hope it will be clear : For my side, there is something wrong with probe pin on the SKR PRO v1.1

#define Z_MIN_PROBE_PIN PA2

Several people have this problem. I think there is somethings wrong with the soft Marlin v2.0/SKR PRO V1.1, but my skills in C++ are limited.
I do not use limit swicth yet but now all is ok. Maybe soon I will install my limit switch Z_MIN on the Z-MAX connector. And change the board configuration and program.

PS: during Z probe you must send Z axis minimum 10 mm up on Z axis on every probes.

If it's like me you will have to use the method Z probe: Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN :

in configuration.h:

define Z_MIN_ENDSTOP_INVERTING false

define Z_MIN_PROBE_ENDSTOP_INVERTING false

define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN // Requested in antlaps instruction BLTOUCH v3.1

define BLTOUCH

define AUTO_BED_LEVELING_BILINEAR

if EITHER(AUTO_BED_LEVELING_LINEAR, AUTO_BED_LEVELING_BILINEAR)

// Set the number of grid points per dimension.
#define GRID_MAX_POINTS_X 4 // Like you prefer I use 4x4 grid on my autolevel
#define GRID_MAX_POINTS_Y GRID_MAX_POINTS_X

define NUM_SERVOS 1 // Servo index starts with 0 for M280 command

define SERVO_DELAY { 300 }

define X_PROBE_OFFSET_FROM_EXTRUDER 0 //Depend on your BLTouch installation value

define Y_PROBE_OFFSET_FROM_EXTRUDER -22 //Depend on your BLTouch installation value

define Z_PROBE_OFFSET_FROM_EXTRUDER -2.35 //Depend on your BLTouch installation value

//It must be greater than or equal to the higher of the X_PROBE_OFFSET_FROM_EXTRUDER and Y_PROBE_OFFSET_FROM_EXTRUDER.

define MIN_PROBE_EDGE 22

Configuration_adv.h

For information SKR V1.1 PRO sensor are in 3.3Volt so I desactivate the set mode 5V. The bl touch v3.1 is ok with 3.3 or 5V.

if ENABLED(BLTOUCH)

//#define BLTOUCH_DELAY 300
//#define BLTOUCH_FORCE_SW_MODE
//#define BLTOUCH_SET_5V_MODE
//#define BLTOUCH_FORCE_MODE_SET
//#define BLTOUCH_HS_MODE

endif // BLTOUCH

Connection on SKR PRO V1.1: the PIN
On the probe area : Connect the 3 pin +5v Red /Control signal Yellow / GND brown
And for me separetaly : white cable on Z_min - Black on GND

It's look like that the bug between marlin and SKR about the dedicated Probe pin PA2 :
On SKR PRO V1.1:

/ Z Probe must be this pins
//

ifndef Z_MIN_PROBE_PIN

#define Z_MIN_PROBE_PIN PA2

endif

[Vertabreak]

Basically when you Install a bltouch it is your new z endstop and you should remove the old one to prevent false positive triggers.

[bojanpotocnik]

@bojanpotocnik is this still an issue? a lot of updates are added constantly so it might have been fixed

@boelle tested today with the latest bugfix-2.0.x and yes, the behaviour is exactly the same. As I wrote in my _Enable BLTouch and Bilinear Auto Bed Leveling_ commit (<- IMO the cleanest way to see what I change to use BLTouch),

1. Enabling the BLTouch does not enable Z-homing using BLTouch as one would expect (or is it just me?), definition of HOMING_Z_WITH_PROBE must also be edited to achieve this functionality,
2. Z-endstop switch is then ignored when homing Z.

[damvcoool]

Z endtop and bltouch are both working fine for me
Take a look at my configuration here
https://github.com/damvcoool/Marlin-2.0.x-SKR-Mini-E3-v1.2

[boelle]

@bojanpotocnik did you have a look at @damvcoool's config?

[boelle]

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.

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