More endstops rework, SPI sensorless, etc.

[thinkyhead]

• Add working CI tests for SPI_ENDSTOPS.
• Apply more granular SPI Sensorless conditionals.
• Account for SPI endstops in endstops sanity check.
• Fix _CAN_HOME to allow for undefined endstop pins.
• Tweak ES macros to remove DEFER.
• Show SPI sensorless endstops on Endstop Test screen.
• Fix support for SPI Sensorless with multi-stepper axes.
• Add support for SPI Sensorless with Dual X Carriage.
• Fix homing current for multi-stepper axes.
• Add new options X_SAFETY_STOP, Y_SAFETY_STOP, etc., that permit a second endstop with its own state.
  This will allow an SPI endstop or the selfsame DIAG pin to be used, not just a distinct endstop pin as with USE_*_PLUG.

[thinkyhead]

Thanks for the assist, @lujios! I'm just getting around to revisiting this PR so it can finally get merged for wider testing.

While your solution is workable and has some elegance and consistency, I want to be careful about referencing EndstopEnum states that may not be defined, and for DELTA it should ideally be the case that there is no such thing as EndstopEnum::X_MIN/Y_MIN/Z_MIN but only the XYZ MAX elements. But maybe I can be convinced to think in a different direction about the meaning of these flags when it comes to sensorless homing and its ugly stepsister sensorless probing.

Anyway, one thing about your solution has me confused. You describe a way to force the endstops code to always check the MAX endstop pin and to only set the MAX endstop flags. But then you suggest changing the probe check to:

endstops.trigger_state() & (_BV(X_MIN) | _BV(Y_MIN) | _BV(Z_MIN))

…which would be looking at MIN flag bits that never got set (and should not even exist). How does it make sense that we force setting the MAX flag bits, but then later we check the MIN flag bits?

[lujios]

Thanks for the assist, @lujios! I'm just getting around to revisiting this PR so it can finally get merged for wider testing.

While your solution is workable and has some elegance and consistency, I want to be careful about referencing EndstopEnum states that may not be defined, and for DELTA it should ideally be the case that there is no such thing as EndstopEnum::X_MIN/Y_MIN/Z_MIN but only the XYZ MAX elements. But maybe I can be convinced to think in a different direction about the meaning of these flags when it comes to sensorless homing and its ugly stepsister sensorless probing.

Anyway, one thing about your solution has me confused. You describe a way to force the endstops code to always check the MAX endstop pin and to only set the MAX endstop flags. But then you suggest changing the probe check to:

endstops.trigger_state() & (_BV(X_MIN) | _BV(Y_MIN) | _BV(Z_MIN))

…which would be looking at MIN flag bits that never got set (and should not even exist). How does it make sense that we force setting the MAX flag bits, but then later we check the MIN flag bits?

Hi @thinkyhead.

I think my arguments have been confused.
My proposal is to use the _MIN endstop in the parts of the code that affect the dynamics of movements in a DELTA during the ugly use of sensorless probing. 😁
I never liked how the _MAX flags for delta were forced to be set, and I prefer the code as it is now in this PR. But necessarily you have to correct the parts where _MAX was evaluated and not _MIN as I propose, because otherwise the probes fail.
For your peace of mind in the use of undefined EndstopEnum states, I assure you that the only way to make sensorless probing work in DELTA was to enable MIN stops (although they seem unnecessary in delta). I have always seen them as virtual limit switches, because their position always depends on where the nozzle touches the bed, they change at each probing point and any one or even several can be activated at the same time, this is impossible for a limit switch physical. But its activation is completely valid during bed leveling tests.

[thinkyhead]

The logic in endstops.cpp for checking MIN or MAX endstops is based on code originally conceived for Cartesian. And the logic in probes.cpp was originally conceived for a simple switch-based probe. So there are many different ways we might adapt these more specifically for deltabots.

The first thing to consider is that G28 homing for delta is specifically to the "MAX" (only) endstops and there is no concept of "MIN" endstops – which is sensible since all three carriages need to hit endstops for proper homing. So I'd like to preserve that assumption.

The next thing to consider is that the probe (of whatever type) is specifically checked within endstops.cpp when the probe is enabled and the nozzle is moving towards the bed (or bed moving towards nozzle). So that is where we should extend the sensorless endstops on delta to provide the Z probe state, and it would make the most sense to do this without treating them as "endstops" but just as hardware states. And then we should set the "Z_PROBE" flag, and then the logic for sensorless probing in probe.cpp can just look at that state.

I'd rather do that extra work with more special cases for DELTA in endstops.cpp rather than leverage the existing endstops code that applies to cartesian. So that's the approach I'll aim for, and this way the "sensorless probe" on all types of machines can be more consistent when queried from other places. I'll let you know when there's something ready to test.

[VanessaE]

I'm afraid that this PR completely breaks homing for my printer.

A simple G28 with no parameters does an initial Z move (see below), then it just stops moving, reports "Home XY First" without actually moving X or Y, and then sits there waiting for my next command. If I try to home just X or Y (or both) without Z, I just get the initial Z move, and no error message at all.

My best guess as to why, is that the machine has a BLTouch (clone), which it uses for Z homing rather than a Z min endstop (which it doesn't even have), while I want to use a Z *max* endstop as the limit for the other end of the build volume. This arrangement seems perfectly logical to me, but maybe that didn't carry over into this new code?

Background:

Normally in the homing procedure, Marlin raises Z (i.e. raises the toolhead or lowers the bed), homes X and Y, positions the toolhead over the bed according to the safe Z home setting (if present), then finally homes Z.

However, that initial Z raise exposes a potential problem: If the toolhead or bed is near the Z max limit of the print volume, it can crash into the frame or other physical stops, particularly if this is the first home since the machine was last power cycled or reset.

I'm going to go out on a limb here and assume that most bedflingers won't really run into that (because who ever raises the X gantry all the way up?), but pretty much all printers that move the bed along Z will park the bed at the bottom of the print volume when the machine finishes a print or is otherwise idle, exposing it to that crash possibility.

In previous versions of Marlin, adding and enabling a Z max endstop stops that crash, but that feature was eventually removed from Marlin, then re-introduced with this PR, which of course is why I came here.

Configs as used *without* this PR: Marlin-configs-20230726-bugfix-2.1.x.zip

Only one change is needed to use those configs with this PR: put #define Z_SAFETY_STOP somewhere in Configuration.h.

[thinkyhead]

Updates to address sensorless probing on Delta will follow in another PR.

[rondlh]

It could just be me, but my homing doesn't work anymore, no movement on any axis after a G28, I use SPI_ENDSTOPS for the TMC5160 and a BLTouch for Z-homing and bed leveling.
UPDATE: I did a clean build and can confirm, this update breaks homing quite badly.

[rondlh]

A simple G28 with no parameters does an initial Z move (see below), then it just stops moving, reports "Home XY First" without actually moving X or Y, and then sits there waiting for my next command. If I try to home just X or Y (or both) without Z, I just get the initial Z move, and no error message at all.

@VanessaE Do you have 2 Y-motors? (Y and Y2)? For me G28 X works, but G28 Y doesn't. I have 1 X-motor, but 2 Y-motors.

[VanessaE]

@VanessaE Do you have 2 Y-motors? (Y and Y2)? For me G28 X works, but G28 Y doesn't. I have 1 X-motor, but 2 Y-motors.

The related bug in the PR has already been fixed, but the machine in question is CoreXY, so technically it doesn't have even one X or Y motor, let alone two. 😉

[rondlh]

The related bug in the PR has already been fixed, but the machine in question is CoreXY, so technically it doesn't have even one X or Y motor, let alone two. 😉

OK, thanks for you replay. I found the problem after a detailed compare of the changes. Things are working again for me :D (See below)

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