Cans another person or 2 give this a test before I submit a bug report?
if you home all the axes at the same time, the z axis just moves once. the distance moved is whatever z_hop is set to in safe_z_home.
if you home the axes one at a time, aka X , then Y, and finally Z, you get 3 z_hop(s). Once for X, once for Y, and once of course for Z. Once Z is homed it won’t z_hop anymore, no matter how many times you home X or Y after homing Z.
If Z isn’t homed, you will get a z_hop every single time you home X or Y. Home X 10 times, and the Z will move 10 * z_hop.
#2 & #3 are a bug imo, because if you are close to your machines limit, you can easilly crash it.
I found this out the hard way the other night, when I had the bed close to max Z. I was adjusting my X & Y limit switches, so I homed them a few times, and didn’t notice the bed was only going down (the bed moves on my machine). after a few homings the bed yokes crashed into the Plum Couplers on the z screws.
off the top of my head, I can only think of 2 ways of fixing this.
add a flag to the safe_z_home section so users can indicate the z_hop should be reversed after an axis is homed. (this is something I’m familiar with from RRF).
add an option to the safe z home section that lets the user specify a reverse/recovery amount.
I think the behavior you’re describing is the intended behavior. If Z isn’t homed, the firmware has no way of knowing where the toolhead is, including whether the nozzle is at or below the level of the bed. So with safe Z home enabled, it raises the Z before performing a homing move to make sure the nozzle doesn’t hit or scrape the bed.
If your toolhead is likely to end up at max Z travel, you could consider installing a max limit switch so Klipper will know that the toolhead (or in your case, the bed) is at max Z travel and will not continue to move it. You could also change the behavior of the command by overriding the homing gcode as suggested in the link above.
if you use set_position_z = 0 so that you can move the z axis before/after homing X & Y, then Z acts like its homed already (not good). The best way to correct this would be to add M84 Z. However, Duet 2 boards (what i have) all use the same pin to disable/enable the steppers. Thus M84 Z will just disable all the steppers, making the homing that just finished pointless.
The other way of doing it would be to set enable_force_move=True, and then just use FORCE_MOVE. This however is an issue with any machine using multiple steppers on an axis (railcores have 3 on the Z), as FORCE_MOVE only works on individual steppers. Thus, you basically need to run a loop, so you can run small FORCE_MOVE on each stepper, till you get the the desired offset you want.
non compare the two options above to what i used on rrf.
@koconnor shouldn’t this be fairly simple to do by registering a new command that takes a few inputs and then just calls manual_move like safe_z_home does?