MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.3k stars 19.25k forks source link

[BUG] Quad Z Quad Endstop Homing Issue #23227

Open TheSWilde opened 2 years ago

TheSWilde commented 2 years ago

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

Yes, and the problem still exists.

Bug Description

Build a 3D-printer with quad Z stepper and quad Z stop. Each stepper has its own driver (TMC2209 UART) on a BTT Octopus 1.1. Whenever i home the Z-axis the gantry drives down until touch each Z-stop. Than it drives up and slowly back down to the Z-Stops. Than errormessage "ERROR:Pinter haltet. kill() called!" appear and i have to reset the printer.

If i configure Marlin to just use one oft the 4 endstops, everything works fine.

Bug Timeline

Old issue (#17785?) without solution

Expected behavior

Z-gantry drives down to Z-Stops, a bit up, than slowly down and tadaa: Z is at 0 and printer ready.

Actual behavior

Z homing touch up endstops twice and printer gets stopped with errormessage "ERROR:Pinter haltet. kill() called!"

Steps to Reproduce

The error appears as soon as i homing Z. Everytime.

Version of Marlin Firmware

2.0.9.2

Printer model

DIY

Electronics

BTT Octopus V1.1 + 7x TMC2209 UART-Mode

Add-ons

No response

Bed Leveling

No Bed Leveling

Your Slicer

Cura

Host Software

Pronterface

Additional information & file uploads

Errorlog.txt configs.zip

ellensp commented 2 years ago

if you disable VALIDATE_HOMING_ENDSTOPS it doesn't ERROR Still looking into why

ellensp commented 2 years ago

also fails on 3 Z steppers.

ellensp commented 2 years ago

hit_state is definitely going to 0 on 3rd Z stepper home, this triggers the error. but I cant find out where/what is going on before that.

TheSWilde commented 2 years ago

I also tried disable VALIDATE_HOMING_ENDSTOPS for testing. I was confused, because: X and Y drives straight to their stops and are zeroed without a second run (as expected). Z drives down until every stop is triggered, drives a bit up and does a second run until Z-stops are triggered again (without any error) Shouldn't the second run be disabled?

thinkyhead commented 2 years ago

Does the machine still go to KILL state if you disable USE_WATCHDOG ?

TheSWilde commented 2 years ago

The error occurs even with Watchdog disabled

tu77 commented 10 months ago

same Problem here!

I upgraded from 2 to 3 Z axis and got the same issue! in the end I downgraded to 2 Axis again.. a bit annoying!

latest marlin BTT Octopus 1.1 Core XY

Ted-Printable commented 2 months ago

https://github.com/MarlinFirmware/Marlin/issues/26717 has a lot information.

To summarize:

Running Marlin2.1.2.4 (bugfix version late August had same results) on a BTT Octopus V1.1 (STM32F446ZE) with TMC2209 drivers. The machine has FOUR - Z-steppers, Z, Z2, Z3 and Z4 with four Z endstops.

Homing while using only one endstop ends normally with normal results, accept of course no stepper alignment. Homing with multiple endstops without "validation" , meaning disabling VALIDATE_HOMING_ENDSTOPS, terminate normal and correct. All four steppers are aligned and homed, with ONE bump only.

However, using the Validation feature (which is a great feature) results in "HALT CALLED" after the second, or validating bump. It appears that at least part of the issue is the 4 endstop activations occurring at almost the same moment. Marlin calls KILL because one or more endstops were "not seen to be activated". It seems that four endstops occurring the same moment cannot be correctly detected by Marlin interrupts, which is probably a physical limitation.

A possible solution would be to have Marlin accept that the "validation bump" is good as long as it received at least one endstop signal. This would work as the first bump still works normal to align the four axes perfectly and the validation is only to get a good zero point with a slower bump. A possible work around would be to enable users to specify individual axis to validate. That way at least X and Y can be validated properly. All this was deduced from results after disabling the kill call in "endstops.ccp". 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. By disabling this, the homing ends normal, but with no error checking on any axis, X,Y and Z, which is not good at all.

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 on the second bump only. (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 Marlin.)

Someone with better programming skills could implement that or hopefully a better solution. There is still the mystery of multiple homing calls that was first noticed by "ellensp" (https://github.com/ellensp) EllenSP is right by saying more debugging is needed as the bug is still not isolated completely.

All help and assistance is greatly appreciated. Thanks you.