Caveat up front, I don’t have a filament sensor, but I do have a 6-in-1-out setup that uses a splitter and a set of “close enough” hardcoded distance values like you describe. Having true extruder stepper homing like this would be really nice.
However, I think the problem you’re going to have with doing what you’re trying to do with a macro is that you can’t interrupt a running G1 command without issuing an emergency shutdown. So there’s no way to have a macro do something like retract filament until a filament sensor is triggered. What you could do is use delayed_gcode to hack together the equivalent of a while loop that (for example) retracts 1mm of filament and then checks whether the filament sensor has been activated, and repeats doing this until the filament sensor is activated, at which point the loop breaks and the macro continues. This is a very imperfect solution though, and it has some significant downsides:
- This method of “homing” will only be accurate to within one unit of whatever distance value you use (e.g. 1mm in the example above).
- The extruder stepper will come to a complete stop between each successive G1 command, so stringing ten
G1 E1s together will not look the same as aG1 E10. The motion will be jerky and since extruder steppers respect acceleration too, the max extrusion speed likely won’t ever be reached, so the smaller yourEvalue, the slower this will be.
I think the “proper” way to do what you want would be to add some core Klipper code that truly homes the extruder as with other axes. About a year ago someone attempted to do this using a physical endstop switch. It looks like they are still maintaining a Klipper fork with this functionality included. Maybe some parts of that fork could be adapted to use the currently supported filament sensors.