I’ve got a problem I’ve been fiddling with trying to solve with one of the toolheads on my printer. Fundamentally, I need to do one of two things – I need extruder homing, or I need to hide a [manual_stepper] behind G0/G1, switching out the E moves for moves on the stepper. Using one of the various forks that support >3 axis or extruder homing isn’t a particularly good option, so I’m hoping to figure out a hack to make it work via macros. I’d DIY a module, but same deal – I don’t want to deal with keeping a fork in sync.
Given extruder homing is a no-go, my first thought was to skip the extruder entirely, define an A axis (before realizing that Klipper doesn’t support more than three Axis like most firmwares). I’d parse out the E parameter and switch it for an A parameter in the underlying G0/G1 and be done with it.
Without A/B/C axis support, though, that obviously won’t work. My next thought was to use a manual_stepper, and basically call the underlying G1 while simultaneously calling MANUAL_STEPPER, giving it the appropriate distance and feed speed, but they won’t run concurrently. Running MANUAL_STEPPER with SYNC=0 before the move seemed like maybe it’d be an option, but I don’t know how predictable the latency between the two is. The manual says “however if a manual stepper move uses SYNC=0 then future G-Code movement commands may run in parallel with the stepper movement”, which doesn’t make it sound like its likely to be deterministic.
Does anyone have any other clever ideas? I’ve found a lot of discussions about extruder homing and multi-axis support, and there’s a bunch of forks of varying levels of sophistication, but I haven’t seen any discussion of work-arounds using “pure” Klipper.
My current solution is to home the extruder by reducing the stepper current and retracting it the max possible range it could be against a physical endstop, which is hacky and not particularly good for the stepper and bearings but does work.