[BUG] PRINTER KILL AFTER HOMING 4 Z MOTOR #26717

andrea199 · 2024-01-21T19:11:30Z

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

Yes, and the problem still exists.

Bug Description

Hi everyone,
I'm trying to configure my 3D printer with:
Motors: 2 Y Motors, 4 Z Motors
Endstops: 2 Y Endstops, 4 Z Endstops
I'm encountering an issue during Z-axis homing. The homing sequence starts, touches the endstops, then moves up for a certain ammount of mm (That i dont know how to change), then it come back down and in the instant of the second touch of the endstops, it crashes and triggers the error pictured below.
My Setup:
Marlin 2.1.2.1
Bigtreetech Octopus board with TMC2209 drivers controlled via UART
All motor and endstop pin assignments have been adjusted due to the dual Y and quad Z configuration.
Troubleshooting:
I suspected the pin changes might be causing the problem, but running M119 confirms all endstops are correctly wired and functioning properly.
As a temporary workaround, I comment out //#define Z_MULTI_ENDSTOPS and use only one Z endstop for homing, which avoids the crash and error. However, I'd like to utilize all four endstops for improved accuracy.
How can I configure Marlin to handle 4 Z-axis homing without the crash? Any guidance or insights would be greatly appreciated!
As a possible solution, I also considered modifying the homing procedure to make it happen in a single downward movement, i.e. without the upward and downward movement. I am not sure how to do this, but in Klipper, you can set the value of "homing_retract_dist" to 0 to make it home in a single movement. There is a similar command in marlin ?

Thank you for your time and assistance!

Bug Timeline

No response

Expected behavior

No response

Actual behavior

No response

Steps to Reproduce

No response

Version of Marlin Firmware

2.1

Printer model

No response

Electronics

No response

LCD/Controller

No response

Other add-ons

No response

Bed Leveling

None

Your Slicer

None

Host Software

None

Don't forget to include

A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

CONFIG.zip

The text was updated successfully, but these errors were encountered:

sargonphin · 2024-01-24T15:11:48Z

Could you enable #define DEBUG_LEVELING_FEATURE in Configuration.h, compile & flash the firmware, then run M111 S247 and then G28?

This will output a whole lot more debug information on the terminal and maybe help diagnose any issue with the endstops

andrea199 · 2024-01-24T16:12:45Z

Hi,
I tryed what you asked and thats the result !! the operation goes smooth until when the motor Re-bump all the Z endstop are touched.

11:07:52.757 : echo:DEBUG:ECHO,INFO,ERRORS,COMMUNICATION,DETAIL
11:07:57.480 : N20 G28 Z0107
11:07:57.555 : echo:N20 G28 Z0107
11:07:57.555 : >>> G28 X0.00 Y0.00 Z0.00
11:07:57.555 : Machine Type: Cartesian
11:07:57.555 : Probe: NONE
11:07:57.555 : >>> homeaxis(Z)
11:07:57.555 : Home Fast: -1500.00mm
11:07:57.555 : >>> do_homing_move X0.00 Y0.00 Z0.00
11:07:57.556 : ...(Z, -1500.00, [2.00])
11:08:04.057 : <<< do_homing_move X0.00 Y0.00 Z0.00
11:08:04.057 : Move Away: 10.00mm
11:08:04.057 : >>> do_homing_move X0.00 Y0.00 Z0.00
11:08:04.057 : ...(Z, 10.00, [2.00])
11:08:09.174 : <<< do_homing_move X0.00 Y0.00 Z0.00
11:08:09.174 : Re-bump: -20.00mm
11:08:09.174 : >>> do_homing_move X0.00 Y0.00 Z0.00
11:08:09.174 : ...(Z, -20.00, 0.50)
11:08:21.432 : <<< do_homing_move X0.00 Y0.00 Z0.00
11:08:21.432 : >>> do_homing_move X0.00 Y0.00 Z0.00
11:08:21.432 : ...(Z, 0.00, [2.00])
11:08:21.432 : echo:Home fallito
11:08:21.451 : Error:Printer halted. kill() called!

Ted-Printable · 2024-08-24T07:41:22Z

Hi, having the same issue.
Running Marlin2.1.2.4 (Latest) on a BTT Octopus V1.1 (STM32F446ZE) with TMC2209 drivers.
I have FOUR - Z-steppers, Z, Z2, Z3 and Z4.

Homing works normal when using only one Z-endstop, all four motors work together, all stop at same time.
Then I enable #define Z_MULTI_ENDSTOPS and the result is this:
All four Z steppers work perfect, when one or more stepper hits an endstop, that stepper stops, until all four steppers
are stopped. All four steppers back-off the endstops as per usual.
All four stepper lower slowly to confirm endstops.
When all four endstops are hit, FATAL ERROR, HALT CALLED.

It works perfect as expected till the last moment when it should simply confirm the Z-homepoint and then function is complete. Instead of finishing, it calls halt.

PLEASE HELP, it will be much appreciated.
Thank you!!

Ted-Printable · 2024-08-24T08:24:15Z

I also enabled the #debug_leveling feature as suggested and got the following report;

Recv: X:350.0000 Y:150.0000 Z:20.0000 E:0.0000 Count A:28000B:12000 Z:4000
Recv: T:26.12 /0.00 B:23.23 /0.00 @:0 B@:0
Recv: X:350.0000 Y:150.0000 Z:20.0000 E:0.0000 Count A:28000B:12000 Z:4000
Recv: T:26.06 /0.00 B:23.28 /0.00 @:0 B@:0
Recv: X:350.0000 Y:150.0000 Z:20.0000 E:0.0000 Count A:28000B:12000 Z:4000
Recv: T:26.07 /0.00 B:23.32 /0.00 @:0 B@:0
Recv: X:350.0000 Y:150.0000 Z:20.0000 E:0.0000 Count A:28000B:12000 Z:4000
Recv: T:26.21 /0.00 B:23.29 /0.00 @:0 B@:0
Send: G91
Recv: ok P31 B63
Send: G28 Z0
Recv: X:350.0000 Y:150.0000 Z:20.0000 E:0.0000 Count A:28000B:12000 Z:-2800
Recv: T:26.22 /0.00 B:23.44 /0.00 @:0 B@:0
Recv: X:350.0000 Y:150.0000 Z:20.0000 E:0.0000 Count A:28000B:12000 Z:-2800
Recv: T:26.34 /0.00 B:23.32 /0.00 @:0 B@:0
Recv: echo:Homing Failed
Recv: //action:notification OctoCore Ready.
Recv: //action:notification Homing Failed:
Recv: Error:Printer halted. kill() called!
Changing monitoring state from "Operational" to "Error"

Anyone know what the "P31 B63" received from the printer mean?

I am pretty sure this is a bug, the result of homing not knowing how to respond when it received multiple endstop signals.
Probably we only need to tell it that after backing of it should only monitor the normal Z-endstop and ignore Z2-Z4-endstops.
Problem is I have not got the programming skills to resolve it.
All help will be be greatly appreciated. Thank you!!

ellensp · 2024-08-24T08:32:05Z

Regarding "P31 B63" you have ADVANCED_OK enabled

  /**
   * Send an "ok" message to the host, indicating
   * that a command was successfully processed.
   *
   * If ADVANCED_OK is enabled also include:
   *   N<int>  Line number of the command, if any
   *   P<int>  Planner space remaining
   *   B<int>  Block queue space remaining
   */

This has nothing to do with homing or failing to home.

Ted-Printable · 2024-08-24T08:32:39Z

A more detailed report.
I had to grab the output in two moves, may have missed a few lines.

Recv: echo:G91
Recv: ok P31 B63
Send: G28 Z0
Recv: echo:G28 Z0
Recv: >>> G28 X343.0000 Y343.0000 Z30.0000
Recv: Machine Type: CoreCartesian
Recv: Probe: NONE
Recv: >>> homeaxis(Z)
Recv: Home Fast: -300.0000mm
Recv: >>> do_homing_move X343.0000 Y343.0000 Z30.0000
Recv: ...(Z, -300.0000, [6.0000])

Recv: <<< do_homing_move X343.0000 Y343.0000 Z30.0000
Recv: Move Away: 7.0000mm
Recv: >>> do_homing_move X343.0000 Y343.0000 Z30.0000
Recv: ...(Z, 7.0000, [6.0000])
Recv: <<< do_homing_move X343.0000 Y343.0000 Z30.0000
Recv: Re-bump: -14.0000mm
Recv: >>> do_homing_move X343.0000 Y343.0000 Z30.0000
Recv: ...(Z, -14.0000, 0.75)
Recv: X:343.0000 Y:343.0000 Z:30.0000 E:0.0000 Count A:27440B:27440 Z:-2800
Recv: T:25.65 /0.00 B:23.67 /0.00 @:0 B@:0
Recv: X:343.0000 Y:343.0000 Z:30.0000 E:0.0000 Count A:27440B:27440 Z:-2800
Recv: T:25.60 /0.00 B:23.72 /0.00 @:0 B@:0
Recv: <<< do_homing_move X343.0000 Y343.0000 Z30.0000
Recv: >>> do_homing_move X343.0000 Y343.0000 Z30.0000
Recv: ...(Z, 0.0000, [6.0000])
Recv: echo:Homing Failed
Recv: //action:notification OctoCore Ready.
Recv: //action:notification Homing Failed:
Recv: Error:Printer halted. kill() called!
Changing monitoring state from "Operational" to "Error"

Ted-Printable · 2024-08-24T08:35:55Z

ellensp, thanks, I learned something, much obliged.

Ted-Printable · 2024-08-24T09:14:18Z

New Revelation......
I disabled //#define VALIDATE_HOMING_ENDSTOPS and redid the test.
Results posted below, TOTAL SUCCESS.
So the problem is with Homing Validating with multiple steppers and endstops on the axis.

Send: G28 Z0
Recv: echo:G28 Z0
Recv: >>> G28 X220.0000 Y180.0000 Z30.0000
Recv: Machine Type: CoreCartesian
Recv: Probe: NONE
Recv: >>> homeaxis(Z)
Recv: Home Fast: -300.0000mm
Recv: >>> do_homing_move X220.0000 Y180.0000 Z30.0000
Recv: ...(Z, -300.0000, [6.0000])
[...]
Recv: <<< do_homing_move X220.0000 Y180.0000 Z30.0000
Recv: Move Away: 7.0000mm
Recv: >>> do_homing_move X220.0000 Y180.0000 Z30.0000
Recv: ...(Z, 7.0000, [6.0000])
Recv: <<< do_homing_move X220.0000 Y180.0000 Z30.0000
Recv: Re-bump: -14.0000mm
Recv: >>> do_homing_move X220.0000 Y180.0000 Z30.0000
Recv: ...(Z, -14.0000, 0.67)
Recv: Re-bump: -14.0000mm
Recv: >>> do_homing_move X220.0000 Y180.0000 Z30.0000
Recv: ...(Z, -14.0000, 0.67)
[...]
Recv: <<< do_homing_move X220.0000 Y180.0000 Z30.0000
Recv: >>> do_homing_move X220.0000 Y180.0000 Z30.0000
Recv: ...(Z, 0.0000, [6.0000])
Recv: <<< do_homing_move X220.0000 Y180.0000 Z30.0000
Recv: >>> do_homing_move X220.0000 Y180.0000 Z30.0000
Recv: ...(Z, 0.0000, [6.0000])
Recv: <<< do_homing_move X220.0000 Y180.0000 Z30.0000
Recv: >>> do_homing_move X220.0000 Y180.0000 Z30.0000
Recv: ...(Z, 0.0000, [6.0000])
Recv: <<< do_homing_move X220.0000 Y180.0000 Z30.0000
Recv: Endstop Z hit at Phase:144 Delta:752 Distance:0.1150
Recv: >>> do_homing_move X220.0000 Y180.0000 Z30.0000
Recv: ...(Z, 0.1150, 0.67)
Recv: <<< do_homing_move X220.0000 Y180.0000 Z30.0000
Recv: >>> set_axis_is_at_home(Z)
Recv: Axis Z home_offset = 0.0000 position_shift = 0.0000
Recv: > home_offset[Z] = 0.0000
Recv: current_position= X220.0000 Y180.0000 Z0.0000 :
Recv: <<< set_axis_is_at_home(Z)
Recv: current_position= X220.0000 Y180.0000 Z0.0000 : sync_plan_position
Recv: current_position= X220.0000 Y180.0000 Z0.0000 : > AFTER set_axis_is_at_home
Recv: <<< homeaxis(Z)
Recv: >>> move_z_after_homing X220.0000 Y180.0000 Z7.0000
Recv: do_blocking_move_to_z(10.0000, 6.0000)
Recv: >>> do_blocking_move_to X220.0000 Y180.0000 Z7.0000
Recv: > X220.0000 Y180.0000 Z10.0000
Recv: //action:notification OctoCore Ready.
Recv: <<< do_blocking_move_to X220.0000 Y180.0000 Z10.0000

Ted-Printable · 2024-08-24T10:35:44Z

Found the problem, but not the right solution.

In file \Marlin\src\module\endstops.cpp on lines 453 to 459 is the statement that kills the printer if any endstop is not triggered.

This need to be altered to ignore if any of Z, Z2, Z3, Z4 is not triggered. It should be ok if only one of the four is triggered. (I think the second bump is a problem as it triggers all four endstops almost simultaneously, resulting in one or more triggers being missed.)
By disabling the kill the function works normal, but the safety check is now removed for all endstop checks, even X and Y axis, which is bad.

If someone with better skills could help out with a alternative solution, it will be great.
Thanks for any assist.

thisiskeithb · 2024-08-24T11:13:25Z

Please download bugfix-2.1.x to test with the latest code and let us know if you're still having this issue.

Ted-Printable · 2024-08-24T11:49:34Z

Will, let you know shortly.....

Ted-Printable · 2024-08-24T12:11:32Z

Downloaded the latest bugfix, but same error again. Kill called after validating , the second home bump.
I know this is not something widely used, but I am almost sure the multiple endstops activate so close together that one or more does not register, causing the kill.
I think there should be a command to accept any one of the four triggers ,the second time, as successful validation.
Just dont know how to do the change in the file myself.

Thanks for the suggestion, I hoped it would work, but alas not.

ellensp · 2024-08-24T12:16:44Z

as a test please disable VALIDATE_HOMING_ENDSTOPS and see if that gets past it

Ted-Printable · 2024-08-24T12:28:54Z

I already did that test as reported above, disabling VALIDATE_HOMING_ENDSTOPS, terminate normal and correct.

Seems when the four steppers is perfectly alighned after the first bump that is the issue, in my unwise opinion.

ellensp · 2024-08-24T15:40:05Z

added a bunch of debugging to watch hit_state, and set M111 S32 here is the log

Note this is on the simulator, so im not sure its fully compatible with multiple Z endstops

echo:DEBUG:DETAIL
ok

G28  X

>>> G28  X0.00 Y0.00 Z0.00
Machine Type: Cartesian
Probe: NONE
remember_feedrate_scaling_off: fr=66.67 100%
Raise Z before homing:
do_z_clearance(5.00 [0.00 to 5.00], 0)
do_blocking_move_to_z(5.00, 4.00)
>>> do_blocking_move_to  X0.00 Y0.00 Z0.00
>  X0.00 Y0.00 Z5.00
<<< do_blocking_move_to  X0.00 Y0.00 Z5.00
>>> homeaxis(X)
Home Fast: -300.00mm
>>> do_homing_move  X0.00 Y0.00 Z5.00
...(X, -300.00, [50.00])
validate_homing_move start:
hit_state:1 'X':'MIN'
hit_state = 0
validate_homing_move end:
<<< do_homing_move  X0.00 Y0.00 Z5.00
Move Away: 5.00mm
>>> do_homing_move  X0.00 Y0.00 Z5.00
...(X, 5.00, [50.00])
<<< do_homing_move  X0.00 Y0.00 Z5.00
Re-bump: -10.00mm
>>> do_homing_move  X0.00 Y0.00 Z5.00
...(X, -10.00, 25.00)
validate_homing_move start:
hit_state:1 'X':'MIN'
hit_state = 0
validate_homing_move end:
<<< do_homing_move  X0.00 Y0.00 Z5.00
>>> set_axis_is_at_home(X)
> home_offset[X] = 0.00
  current_position= X0.00 Y0.00 Z5.00 : 
<<< set_axis_is_at_home(X)
  current_position= X0.00 Y0.00 Z5.00 : sync_plan_position
  current_position= X0.00 Y0.00 Z5.00 : > AFTER set_axis_is_at_home
<<< homeaxis(X)
  current_position= X0.00 Y0.00 Z5.00 : sync_plan_position
restore_feedrate_and_scaling: fr=66.67 100%
X:0.00 Y:0.00 Z:5.00 E:0.00 Count X:0 Y:0 Z:2000
<<< G28  X0.00 Y0.00 Z5.00
ok

G28 Y

>>> G28  X0.00 Y0.00 Z5.00
Machine Type: Cartesian
Probe: NONE
remember_feedrate_scaling_off: fr=66.67 100%
Raise Z before homing:
do_z_clearance(10.00 [5.00 to 10.00], 0)
do_blocking_move_to_z(10.00, 4.00)
>>> do_blocking_move_to  X0.00 Y0.00 Z5.00
>  X0.00 Y0.00 Z10.00
<<< do_blocking_move_to  X0.00 Y0.00 Z10.00
>>> homeaxis(Y)
Home Fast: -300.00mm
>>> do_homing_move  X0.00 Y0.00 Z10.00
...(Y, -300.00, [50.00])
validate_homing_move start:
hit_state:2 'Y':'MIN'
hit_state = 0
validate_homing_move end:
<<< do_homing_move  X0.00 Y0.00 Z10.00
Move Away: 5.00mm
>>> do_homing_move  X0.00 Y0.00 Z10.00
...(Y, 5.00, [50.00])
echo:busy: processing
<<< do_homing_move  X0.00 Y0.00 Z10.00
Re-bump: -10.00mm
>>> do_homing_move  X0.00 Y0.00 Z10.00
...(Y, -10.00, 25.00)
validate_homing_move start:
hit_state:2 'Y':'MIN'
hit_state = 0
validate_homing_move end:
<<< do_homing_move  X0.00 Y0.00 Z10.00
>>> set_axis_is_at_home(Y)
> home_offset[Y] = 0.00
  current_position= X0.00 Y0.00 Z10.00 : 
<<< set_axis_is_at_home(Y)
  current_position= X0.00 Y0.00 Z10.00 : sync_plan_position
  current_position= X0.00 Y0.00 Z10.00 : > AFTER set_axis_is_at_home
<<< homeaxis(Y)
  current_position= X0.00 Y0.00 Z10.00 : sync_plan_position
restore_feedrate_and_scaling: fr=66.67 100%
X:0.00 Y:0.00 Z:10.00 E:0.00 Count X:0 Y:0 Z:4000
<<< G28  X0.00 Y0.00 Z10.00
ok

G28 Z

>>> G28  X0.00 Y0.00 Z10.00
Machine Type: Cartesian
Probe: NONE
remember_feedrate_scaling_off: fr=66.67 100%
>>> homeaxis(Z)
Home Fast: -300.00mm
>>> do_homing_move  X0.00 Y0.00 Z10.00
...(Z, -300.00, [4.00])
validate_homing_move start:
hit_state:4 'Z':'MIN'
hit_state = 0
validate_homing_move end:
<<< do_homing_move  X0.00 Y0.00 Z10.00
Move Away: 2.00mm
>>> do_homing_move  X0.00 Y0.00 Z10.00
...(Z, 2.00, [4.00])
<<< do_homing_move  X0.00 Y0.00 Z10.00
Re-bump: -4.00mm
>>> do_homing_move  X0.00 Y0.00 Z10.00
...(Z, -4.00, 1.00)
validate_homing_move start:
hit_state:4 'Z':'MIN'
hit_state = 0
validate_homing_move end:
<<< do_homing_move  X0.00 Y0.00 Z10.00
>>> do_homing_move  X0.00 Y0.00 Z10.00
...(Z, 0.00, [4.00])
validate_homing_move start:
hit_state:0
echo:Homing Failed
Error:Printer halted. kill() called!

It may have raised more questions than answers,

the test machine has x,y,z,z2,z3,z4,e0
It calls validate_homing_move twice on X and Y due to Re-bump
You can see it calling validate_homing_move 3 times on Z and failing the 3rd time

also found that 2 Z's works fine > 2 and it errors

more debugging needed

Ted-Printable · 2024-08-26T09:17:50Z

Hi, I did the same test with the "S32" debug detail.
In this instance I am running what truly reflects my machine, X, Y, Z, Z2, Z3 and Z4 with all four Z-steppers on their own endstop.
NOTE: I have disabled the kill call in "endstops.ccp" as discribed above, which makes everything run 100%, but the error check function is totally disabled, which is not good.

The resulting output......
[...]
Send: M111 S32
Recv: echo:DEBUG:DETAIL
Recv: ok P31 B63
[...]
Recv: //action:notification OctoCore Ready.
[...]
Send: G28 Z0
Recv: >>> G28 X350.0000 Y220.0000 Z30.0000
Recv: Machine Type: CoreCartesian
Recv: Probe: NONE
Recv: >>> homeaxis(Z)
Recv: Home Fast: -300.0000mm
Recv: >>> do_homing_move X350.0000 Y220.0000 Z30.0000
Recv: ...(Z, -300.0000, [6.0000])
[...]
Recv: <<< do_homing_move X350.0000 Y220.0000 Z30.0000
Recv: Move Away: 5.0000mm
Recv: >>> do_homing_move X350.0000 Y220.0000 Z30.0000
Recv: ...(Z, 5.0000, [6.0000])
Recv: <<< do_homing_move X350.0000 Y220.0000 Z30.0000
Recv: Re-bump: -10.0000mm
Recv: >>> do_homing_move X350.0000 Y220.0000 Z30.0000
Recv: ...(Z, -10.0000, 0.60)
[...]
Recv: <<< do_homing_move X350.0000 Y220.0000 Z30.0000
Recv: >>> do_homing_move X350.0000 Y220.0000 Z30.0000
Recv: ...(Z, 0.0000, [6.0000])
Recv: <<< do_homing_move X350.0000 Y220.0000 Z30.0000
Recv: >>> do_homing_move X350.0000 Y220.0000 Z30.0000
Recv: ...(Z, 0.0000, [6.0000])
Recv: <<< do_homing_move X350.0000 Y220.0000 Z30.0000
Recv: >>> do_homing_move X350.0000 Y220.0000 Z30.0000
Recv: ...(Z, 0.0000, [6.0000])
Recv: <<< do_homing_move X350.0000 Y220.0000 Z30.0000
Recv: Endstop Z hit at Phase:112 Delta:784 Distance:0.1200
Recv: >>> do_homing_move X350.0000 Y220.0000 Z30.0000
Recv: ...(Z, 0.1200, 0.60)
Recv: <<< do_homing_move X350.0000 Y220.0000 Z30.0000
Recv: >>> set_axis_is_at_home(Z)
Recv: Axis Z home_offset = 0.0000 position_shift = 0.0000
Recv: > home_offset[Z] = 0.0000
Recv: current_position= X350.0000 Y220.0000 Z0.0000 :
Recv: <<< set_axis_is_at_home(Z)
Recv: current_position= X350.0000 Y220.0000 Z0.0000 : sync_plan_position
Recv: current_position= X350.0000 Y220.0000 Z0.0000 : > AFTER set_axis_is_at_home
Recv: <<< homeaxis(Z)
Recv: >>> move_z_after_homing X350.0000 Y220.0000 Z7.0000
Recv: do_blocking_move_to_z(7.0000, 6.0000)
Recv: >>> do_blocking_move_to X350.0000 Y220.0000 Z7.0000
Recv: > X350.0000 Y220.0000 Z7.0000
Recv: <<< do_blocking_move_to X350.0000 Y220.0000 Z7.0000
Recv: <<< move_z_after_homing X350.0000 Y220.0000 Z7.0000
Recv: current_position= X350.0000 Y220.0000 Z7.0000 : sync_plan_position
[...]
Recv: <<< G28 X350.0000 Y220.0000 Z7.0000
Recv: ok P31 B63

It is obvious that KILL is called because one or more endstops, activation was not received. The endstops function 100%, they can be triggered before the validation bump individually, which stops just that stepper correctly.
My diagnosis is still that after the first bump, the four are so precisely aligned that Marlin is unable to register all four interrupts because they happen almost at the say time.

I believe a workaround would be to : In case of multiple steppers and multiple endstops on an axis, to accept correct validation as long as at least one of the multiple endstops are triggered.

As for the multiple "home" calls, that is a mystery to me, an indication of other "un-noticed bugs/issues" perhaps?
Thanks to any and everyone for help and assistance.

thisiskeithb · 2024-08-26T11:14:31Z

I believe a workaround would be to : In case of multiple steppers and multiple endstops on an axis, to accept correct validation as long as at least one of the multiple endstops are triggered.

That only masks the issue and would defeat the purpose of Z_MULTI_ENDSTOPS.

thisiskeithb · 2024-09-05T23:34:29Z

Duplicate of #23227

Ted-Printable · 2024-09-06T02:25:43Z

This bug/issue was not resolved.
It is a duplicate but both are closed, without resolution.??

thisiskeithb · 2024-09-06T04:25:59Z

It is a duplicate but both are closed, without resolution.??

#23227 is not closed:

andrea199 added the Bug: Potential ? label Jan 21, 2024

InsanityAutomation self-assigned this Apr 7, 2024

thisiskeithb added the F: Calibration label Apr 10, 2024

thisiskeithb added Bug: Confirmed ! and removed Bug: Potential ? labels Aug 24, 2024

thisiskeithb marked this as a duplicate of #23227 Sep 5, 2024

thisiskeithb closed this as completed Sep 5, 2024

MarlinFirmware locked and limited conversation to collaborators Sep 6, 2024

MarlinFirmware deleted a comment from Ted-Printable Sep 6, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[BUG] PRINTER KILL AFTER HOMING 4 Z MOTOR #26717

[BUG] PRINTER KILL AFTER HOMING 4 Z MOTOR #26717

andrea199 commented Jan 21, 2024

sargonphin commented Jan 24, 2024

andrea199 commented Jan 24, 2024

Ted-Printable commented Aug 24, 2024

Ted-Printable commented Aug 24, 2024

ellensp commented Aug 24, 2024 •

edited

Loading

Ted-Printable commented Aug 24, 2024

Ted-Printable commented Aug 24, 2024

Ted-Printable commented Aug 24, 2024

Ted-Printable commented Aug 24, 2024

thisiskeithb commented Aug 24, 2024

Ted-Printable commented Aug 24, 2024

Ted-Printable commented Aug 24, 2024

ellensp commented Aug 24, 2024

Ted-Printable commented Aug 24, 2024

ellensp commented Aug 24, 2024 •

edited

Loading

Ted-Printable commented Aug 26, 2024

thisiskeithb commented Aug 26, 2024

thisiskeithb commented Sep 5, 2024

Ted-Printable commented Sep 6, 2024

thisiskeithb commented Sep 6, 2024

[BUG] PRINTER KILL AFTER HOMING 4 Z MOTOR #26717

[BUG] PRINTER KILL AFTER HOMING 4 Z MOTOR #26717

Comments

andrea199 commented Jan 21, 2024

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

Bug Description

Bug Timeline

Expected behavior

Actual behavior

Steps to Reproduce

Version of Marlin Firmware

Printer model

Electronics

LCD/Controller

Other add-ons

Bed Leveling

Your Slicer

Host Software

Don't forget to include

Additional information & file uploads

sargonphin commented Jan 24, 2024

andrea199 commented Jan 24, 2024

Ted-Printable commented Aug 24, 2024

Ted-Printable commented Aug 24, 2024

ellensp commented Aug 24, 2024 • edited Loading

Ted-Printable commented Aug 24, 2024

Ted-Printable commented Aug 24, 2024

Ted-Printable commented Aug 24, 2024

Ted-Printable commented Aug 24, 2024

thisiskeithb commented Aug 24, 2024

Ted-Printable commented Aug 24, 2024

Ted-Printable commented Aug 24, 2024

ellensp commented Aug 24, 2024

Ted-Printable commented Aug 24, 2024

ellensp commented Aug 24, 2024 • edited Loading

Ted-Printable commented Aug 26, 2024

thisiskeithb commented Aug 26, 2024

thisiskeithb commented Sep 5, 2024

Ted-Printable commented Sep 6, 2024

thisiskeithb commented Sep 6, 2024

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

ellensp commented Aug 24, 2024 •

edited

Loading

ellensp commented Aug 24, 2024 •

edited

Loading