Z-Axis Crash during homing after tall prints
Not a bug but just something that happens on tall prints that almost fill the build volume.
For example when I print something with a Z-Height of 290mm on my VC 300, the print ends with the bed, or rather the arms, around 10 mm above the Z-couplers. The motors are then disabled.
Next time the printer homes, the bed moves down 15 mm as part of the homing procedure, crashing into the couplers of the leadscrews for the last "5 mm".
The crash sounded very unhealthy. My fix now is to set center kinematic position and manually move the bed up before I home it again.
- Any Ideas on how this could be fixed or improved?
- Maybe implementing something similar to sensoreless homing on the Z-Axis as a failsafe?
- has anyone experienced this and / or done something about it?
14 Replies
Yes this happens to me as well. Perhaps this is more of a Klipper issue? We need a firmware to prevent Z axis moves beyond max Z. Or is there a command we can place in printer.cfg ?
It already does, problem is all state is lost when the motors are turned off. So when you home again, the bed could be at -5mm or it could be at 300mm, there's no way to know.
Any Ideas on how this could be fixed or improved?None. There is no sure fire way other than limiting your max_z and/or lowering your homing z_hop.
Maybe implementing something similar to sensoreless homing on the Z-Axis as a failsafe?No such feature in klipper if you want to home with a probe. It's either or and sensorless homing is not how you want to probe Z. Also the z_hop move happens before klipper starts monitoring endstop interrupts so it wouldn't do anything anyway.
has anyone experienced this and / or done something about it?Yes, and no. Besides limiting your max_z and/or lowering z_hop, there's nothing you can do. I'm open to any ideas though, but filling up Z is kind of a hard limit on motion. Btw, although it sounds bad, it shouldn't actually be able to cause any damage, the z-motors should skip long before anything exceeds any load rating, it's all metal on metal 🙂 Personally i prefer skipping motors in kind of rare edge cases when homing at or below
position_max - z_hop with no other consequences, as opposed to risking flex plate / toolhead damage on every single G28 😄What about adding a physical z axis endstop for max Z?
Same problem, you can either have an endstop or you can have a probe.
It's a klipper limitation
Seems like that is a limitation that can be removed should the Klipper developers wish to.
It's quite complicated and requires major architectural changes
mostly because all the kinematics classes have to change, and they don't like that.
Interesting because Z max and Z min are two seperate things
yes and they have nothing to do with endstops 😄
But logically if you had an endstop at Z max and was triggered that's a physical signal that "Hey stop increasing Z now stupid printer" lol
Yes, logically (without klipper brain), it totally makes sense and seems obvious
But alas.. ain't that easy given the current software constraints.
😦
There's one thing we could do
Interesting, I will have to just remember after printing a tall print to use center kinematic position and lower Z enough to avoid the horrible noise
We could save the last known z_position in [save_variables] and check that before z-hopping.. It's not foolproof as the user could manually move Z since the last END_PRINT was called, but it's something we could let people enable as option.
Nice idea
Will add to my todo list for 2.1.. Prolly won't be in at release, but it'll make it in 2.1.1 at least.