Hello, I’m working on gantry adjust script for bedslinger type printers. In short it would run tip-top force_move like movements on each stepper until each stepper triggers it’s corresponding endstop. I want to make it as much user friendly and fool-proof as possible. Due to the nature of force_move movement the kinematics would be invalidated after gantry adjustment. So to prevent any scenario where user forgets to level the Z axis again and could crash the gantry onto the bed I’d need to invalidate homing for it and force user to rehome again.
The problem is that I can’t really see how Klipper on Python side tracks the state of of homing. I see Homing object as well as well as motors_off method (that invalidates homing on Mainsail side) in toolhead but really can’t see where it’s taking place. I see set_axes method in Homing but I’m not sure if that’s it?
Tracking the homed axis is actually internal to the kinematics module in use, so it’s nontrival to modify it outside of homing requests. Clearing homing in response to an M84 is accomplished by the kinematics module subscribing to stepper_enable:motor_off, which is not selective.
The set_axis in Homing is what axis you are asking the printer to home, not what is actually tracked.
Without modifying all of the kinematics classes (or writing handlers for all of them), you can’t un-home a single axis. (or at least as much makes sense).
However, since you are specifically targeting bedslingers, you could downscope that to cartesian and corexz, and it might be feasible. However, there is a good chance other things subscribe to stepper_enable:motor_off, so they may not keep in sync.
Ouch, wasn’t aware that it’s so embedded into the source. Thanks for reply though!
I guess I’ll leave homing to user then. I’ve came up with something like this for now. Seems to be working fine, but I guess I need to add some raises and checks whether user configured this thing properly.