[BUG] Hotend overruns soft endstops regardless of NO_MOTION_BEFORE_HOMING

[FlyingSamson]

Bug Description

My printer is configured to disallow movement before homing (NO_MOTION_BEFORE_HOMING enabled) and to use min and max software endstops:

#define MIN_SOFTWARE_ENDSTOPS
#if ENABLED(MIN_SOFTWARE_ENDSTOPS)
  #define MIN_SOFTWARE_ENDSTOP_X
  #define MIN_SOFTWARE_ENDSTOP_Y
  #define MIN_SOFTWARE_ENDSTOP_Z
#endif

// Max software endstops constrain movement within maximum coordinate bounds
#define MAX_SOFTWARE_ENDSTOPS
#if ENABLED(MAX_SOFTWARE_ENDSTOPS)
  #define MAX_SOFTWARE_ENDSTOP_X
  #define MAX_SOFTWARE_ENDSTOP_Y
  #define MAX_SOFTWARE_ENDSTOP_Z
#endif

which from my point of view seems a common configuration to prevent the printer from driving into the walls.
Now after the changes made in commit 81b9c7c it is now possible under some circumstances to do exactly that, that is drive the hotend into the walls. (See steps below)

My Configurations

Configurations.zip

Steps to Reproduce

1. Home one or two axis. For instance

G28 X

2. Now since the code in G0_G1.cpp (lines 54-59) says

#if ENABLED(NO_MOTION_BEFORE_HOMING)
      && !axis_unhomed_error(
          (parser.seen('X') ? _BV(X_AXIS) : 0)
        | (parser.seen('Y') ? _BV(Y_AXIS) : 0)
        | (parser.seen('Z') ? _BV(Z_AXIS) : 0) )
    #endif

and axis_unhomed_error() is false iff no bit corresponding to an unhomed axis is set, I can therewith move the x direction, since only the x bit will be set and the corresponding axis is already homed due to Step 1.
3. In the same time I have activated the MIN-/MAX_SOFTWARE_ENDSTOPS which until commit 81b9c7c prevented me from driving the x direction too far.
4. The code in motion.cpp (line 595, inside apply_motion_limits()) now says

if (!soft_endstops_enabled || !all_axes_homed()) return;

The first condition is false since my endstops are enabled. So the if only depends on the !all_axes_homed() part. Meaning that unless ALL axes are homed, which is not the case since only x was homed, this routine will directly return without clamping the motion to the soft limits of the x axis. And thus allows to overdrive in this direction.

Expected behavior:
As mentioned before I think it is a common use case, that the user wants to be prevented from accidentally driving any motor to far, by enabling both NO_MOVEMENT_BEFORE_HOMING and the MIN-/MAX_SOFTWARE_ENDSTOPS.

Actual behavior:
The user is not prevented from doing so.

Additional Information

I guess there would be many ways to 'fix' this, but reading the discussion on the Issue #15027 which led to commit 81b9c7c it was desired to be able to move arround the toolhead before homing. So I presume the easiest way to satisfy both needs would be to change the contidion in motion.cpp from requesting that not all axes are homed (!all_axes_homed()) to something like 'if no axes are homed return'. Which would imply that it is still possible to drive the head before homing as requested in #15027 (of course only with NO_MOVEMENT_BEFORE_HOMING disabled) and on the other side would apply the limits, when any axis already has been homed. This way homed axis can still be moved, but only in the limits, whereas unhomed axis can't be moved due to NO_MOVEMENT_BEFORE_HOMING.

[drphil3d]

Yep having this same problem SKR 1.3 with TMC2130 SPI. I noticed this started happening after enabling SPI mode.

[boelle]

@FlyingSamson still an issue?

[FlyingSamson]

Yes I just tried it again with the same Configurations and the current commit 669fe74. It still show the same behaviour as described above.

[github-actions]

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.