You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yesterday, the cable connecting my Y endstop came loose, leading to the endstop being "TRIGGERED" all the time. During homing, Marlin didn't notice it and just assumed that the Y axis was already at 0 - leading to the Y axis hitting the mechanical borders of movement and stuff.
I think this problem could be recognized when using bumping: After the carriage has been moved away by Y_HOME_BUMP_MM, the endstop should register "Open". This could be detected by Marlin, maybe as a part of VALIDATE_HOMING_ENDSTOPS.
Feature Workflow
Pseudo-code of homing:
Move in X/Y/Z direction until the corresponding endstop gets triggered.
Move HOME_BUMP_MM back.
Check that the endstop is no longer triggered. If it is, stop the print. (This is the new step.)
Move in X/Y/Z direction again until the endstop is triggered.
Additional Information
This check can only be done safely if HOME_BUMP_MM is used.
You could have set HOME_BUMP_MM to a very small value that doesn't release the endstop. This would trigger an error. But then again, a) the user has to have VALIDATE_HOMING_ENDSTOPS enabled so those errors should be more or less expected anyways and b) your bumping would be completely useless and having your printer alert you to this might noe be the worst idea, either.
The text was updated successfully, but these errors were encountered:
I had a similar issue with a semi broken endstop cable, which triggered the es right before it shoul. Resulting in several crashes on axis until i figured out what was wrong. I set up this (for me) working code draft. It stops the machine if no change in endstop state is detected. Help is much appreciated!
Description
Yesterday, the cable connecting my Y endstop came loose, leading to the endstop being "TRIGGERED" all the time. During homing, Marlin didn't notice it and just assumed that the Y axis was already at 0 - leading to the Y axis hitting the mechanical borders of movement and stuff.
I think this problem could be recognized when using bumping: After the carriage has been moved away by Y_HOME_BUMP_MM, the endstop should register "Open". This could be detected by Marlin, maybe as a part of VALIDATE_HOMING_ENDSTOPS.
Feature Workflow
Pseudo-code of homing:
Additional Information
The text was updated successfully, but these errors were encountered: