[BUG] More endstops refactoring (#25758) breaks homing (G28)

[rondlh]

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

After #25758 (More endstops refactoring) homing doesn't work anymore. When sending G28 no axis move and the printer reports "Homing failed". I use SPI_ENDSTOPS for X, Y and Y2 based on TMC5160, and Z-homing based on a BLtouch. Disabling SPI_ENDSTOPS.solves this issue. Also disabling the Y2 driver (// #define Y2_DRIVER_TYPE TMC5160). solves the issue. So there seems to be a conflict between SPI_ENDSTOPS and using 2 motors on an axis.

Bug Timeline

#25758 August 2nd 2023

Expected behavior

Homing works as before

Actual behavior

No movement at all after an G28, just reports homing failed after a few seconds. "G28 X" works fine. But no movement for "G28 Y", just a "Homing failed" message after a few seconds. I believe this is related to SPI_ENDSTOPS, because when I disable it (and add some jumpers) then G28 works fine. I have 2 Y-motors, perhaps that is the cause of the problem.

Steps to Reproduce

1. On a setup with SPI_ENDSTOPS on X, Y and Y.
2. Send a G28

Version of Marlin Firmware

bugfix August 4th 2023

Printer model

Custom

Electronics

MKS Monster8 V1.0

Add-ons

BTT TFT35 V3.0

Bed Leveling

ABL Bilinear mesh

Your Slicer

Cura

Host Software

None

Don't forget to include

• [X] A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

To confirm the issue I downloaded Marlin August 2nd 2023, added my Configuration, PlatformIO, pins files, ExtUI files. Configuration.zip

[thisiskeithb]

https://github.com/MarlinFirmware/Marlin/pull/25758

That PR also broke sensorless probing on deltas, so I'll mark this as confirmed. https://github.com/MarlinFirmware/Marlin/pull/25758#issuecomment-1661456614

I'm curious, why do you use SPI_ENDSTOPS instead of SENSORLESS_HOMING on the Monster8?

[thisiskeithb]

#25758 also broke DEBUG_LEVELING_FEATURE:

Marlin/src/gcode/calibrate/G28.cpp: In lambda function:
Marlin/src/gcode/calibrate/G28.cpp:266:38: error: 'DEBUG_ECHOF' was not declared in this scope; did you mean 'DEBUG_ECHO'?
  266 |           if (DEBUGGING(LEVELING)) { DEBUG_ECHOF(s); DEBUG_ECHOLNPGM(" current: ", a, " -> ", b); }
      |                                      ^~~~~~~~~~~
      |                                      DEBUG_ECHO

[rondlh]

I'm curious, why do you use SPI_ENDSTOPS instead of SENSORLESS_HOMING on the Monster8?

I use both basically (SPI_ENDSTOPS and SENSORLESS_HOMING), the TMC driver detects the endstop (SENSORLESS_HOMING), but instead of reading the signal from the driver via an endstop connecotr, I use SPI_ENDSTOPS to read the endstop status via SPI. So now I have 2 endstop connectors available (X- and Y-) for other purposes, and I don't depend on the correct setting of the jumpers.

Using the endstop connectors (instead of SPI_ENDSTOPS) with ENDSTOP_INTERRUPTS_FEATURE would probably be more accurate. Any other concerns/recommendations?

[thisiskeithb]

I use both basically (SPI_ENDSTOPS and SENSORLESS_HOMING)

Oh, I missed the "n" in #ifndef:

  #ifndef IRON_IDEX // IDEX doesn't use sensorless homing, too inaccurate!
    #define SENSORLESS_HOMING // StallGuard capable drivers only // IRON, enabled for X and Y axis
  #endif

What is the source of your fork/config files? They are not stock Marlin. For example:

#define EXTUI_IRON_BTT_TFT  // IRON, for TFT, used in UI_IRON.cpp

We don't have an "IRON UI"/UI_IRON.cpp

I get a bunch of errors trying to compile with your configs.

[rondlh]

IRON is the code word I use for my custom changes. IRON UI is my custom UI for the BTT TFT35 V3.0 touch screen. The config supports 4 printers, so it's a bit complex, and there are some customizations.

I attached Marlin bugfix of August 2nd with my config. This build shows the homing problems. Marlin_230802-IRON.zip

UPDATE: "G28 X" works fine! "G28 Y" doesn't work, the Y-motors never move and "Homing failed" is reported after a few seconds. Note, there are 2 Y-motors. What's quite odd about this is that not even the homing bump move is executed. I confirmed that the Y-axis is activated, but no Y-movement at all. If I disable SPI_ENDSTOPS (and set some jumpers) then "G28 Y" also works fine.

UPDATE 2 I tested if homing works when I disable Y2 (// #define Y2_DRIVER_TYPE TMC5160). THAT WORKS FINE!

So the issue seems to be related to SPI_ENDSTOPS in combination with 2 drivers on an axis.

MY CONFIGURATION: Cartesian XY layout Sensorless homing for X, Y1 and Y2 SPI_ENDSTOPS Z-homing with BLTouch

[rondlh]

I found the cause of the problem I am having (no movement when homing Y with Y_DUAL_ENDSTOPS in combination with SPI_ENDSTOPS). In Conditionals_post.h

Old line: #define _USE_STOP(A,N,M,C) ((A##_HOME_TO_##M || (C+0)) && PIN_EXISTS(A##N##_##M))

New line: #define _USE_STOP(A,N,M,C) ((ANY(A##_HOME_TO_##M, A##N##_SAFETY_STOP) || (C+0)) && PIN_EXISTS(A##N##_##M) && !A##_SPI_SENSORLESS)

Note the addition of "&& !A##_SPI_SENSORLESS" at the end. If you delete that addition, then things work for me.

#define _USE_STOP(A,N,M,C) ((ANY(A##_HOME_TO_##M, A##N##_SAFETY_STOP) || (C+0)) && PIN_EXISTS(A##N##_##M))

[Sonicboom247]

would this have to do with the entire ENDSTOP section missing? on my Hornet I normally define the below, however that section is no longer in the latest bugfix //#define USE_XMIN_PLUG #define USE_YMIN_PLUG #define USE_ZMIN_PLUG #define USE_XMAX_PLUG //#define USE_YMAX_PLUG //#define USE_ZMAX_PLUG ahh, looks like that was replaced with Inverting Stepper Pins section?

[thisiskeithb]

ahh, looks like that was replaced with Inverting Stepper Pins section?

No, they’re automatically defined based on homing direction now.

[Sonicboom247]

hmm, ok let me keep testing then, I am using the same directions as always and steppers are going opposite. Don't want to hijack thread if it doesn't pertain.

[The-EG]

Another unintended consequence of the refactoring is that using USE_PROBE_FOR_Z_HOMING without Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN (ie. a probe plugged into a dedicated probe port that is used for homing) causes USE_Z_MIN to still be defined. This causes Z_MIN endstop to be enabled in addition to the probe. It's not used for anything, in my tests I don't even have anything connected to the z-min port and homing still uses the probe and works properly.

Disabling the Z_MIN endstop now requires hacking conditionals_post.h. USE_Z_MIN should not be set when using USE_PROBE_FOR_Z_HOMING and not Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN, but HAS_Z_MIN_STATE does still need to be set.

[Sonicboom247]

I did finally figure it out, ended up being a mix of the "new to me" wording of Endstop Hit state High Low, vs True False as well as what The-EG mentioned where I had to also disable Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN and ensure both USE_PROBE_FOR_Z_HOMING as well as Z_MIN_PROBE_PIN PC2 are enabled with a pin defined. only then did everything function as intended. I see where this could function if I decided to user the now open Z_MIN_ENDSTOP for a filament runout sensor I could.

[ptran099]

How am I supposed to home X and Y now that USE_XMIN_PLUG doesn't work, they both crash into the gantry when homing.