Shutdown due to expected probe state to be deployed but is stowed (1)
I just switched on my printer and wanted to start a print, but unfortunately the homing on Z failed and the printer ran into an emergency stop.
What happened:
X and Y homed as expected,
My Euclid probe was taken and the first homing on Z worked.
Print bed moved down as expected and the second probe went into this Emergency shut down.
This issue is always reproducible, I just updated yesterday late evening.
In the first movie you can see the behavior:
https://www.dropbox.com/s/ytcm51mqr8g95bg/VID_20230220_185325.mp4?dl=0
In the second movie, I moved the Z manually after the emergency shut down and you can see that the probe works as expected:
https://www.dropbox.com/s/a0cak8wb6nu2kzq/VID_20230220_185434.mp4?dl=0
Any idea where to look at?
7 Replies
Issue fixed with a complete installation from scratch. I have no idea what happened that this crap happened.
I do, i was messing around with homing yesterday to solve an issue. I think you just missed the last commits: https://github.com/Rat-OS/RatOS-configuration/commits/v2.x
GitHub
Commits · Rat-OS/RatOS-configuration
The RatOS modular klipper configuration. Contribute to Rat-OS/RatOS-configuration development by creating an account on GitHub.
What you're describing was fixed with these commits:
Homing: fix z-hop
Z Probe: clear z during stow no matter what
Stowable: fix missing z speed
Yes, with the newest setup all is working fine again, and I have seen the commit, but too late. 😄
Printer is doing his job now again.
I know that this is still Beta and things can happen...
Yeah i tested it and everything, but alas I goofed 😩
I just updated at the wrong moment, that´s all. Normally I just wait if I have to print something, but in this case I am the idiot and I did it even if I know that it was a bad idea.
Ideally i'd like if you didn't have to worry about it, but yes, definitely good practice.