[BUG] PRINTER KILL AFTER HOMING 4 Z MOTOR

[andrea199]

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

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

Additional information & file uploads

CONFIG.zip

[sargonphin]

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]

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]

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]

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]

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]

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]

ellensp, thanks, I learned something, much obliged.

[Ted-Printable]

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]

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]

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]

Will, let you know shortly.....

[Ted-Printable]

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]

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

[Ted-Printable]

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]

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]

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]

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]

Duplicate of https://github.com/MarlinFirmware/Marlin/issues/23227

[Ted-Printable]

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

[thisiskeithb]

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

https://github.com/MarlinFirmware/Marlin/issues/23227 is not closed: