Emulating >3 axis without new kinematics

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.

It would help to know what you’re trying to accomplish.

I mean, I thought I was clear on that. I need a 4th axis with endstops. I can’t really use E as the 4th axis because it doesn’t support endstops. I can use a manual_stepper, but it isn’t guaranteed to sync moves with G0/G1 even if its run asynchronously.

The manual is wishy-washy about how the move scheduling happens, thus asking what people knew about it. If a manual_stepper with sync=0 followed by a G0/G1 definitely schedule concurrently, it might work.

I just suspected that wasn’t the case, because there are so many forks to fix the problem of not supporting endstops on E and not supporting an A/B/C/W/etc axis, and there’s been very little interest shown in merging any of them.

My question was about your use case. 3D printers don’t require homing of the E axis, which makes me think you’re trying to operate something other than a 3D printer. What are you trying to do?

I think the point of the manual_stepper with SYNC=0 is that the movement isn’t synced/scheduled at all with respect to any other movements. Klipper just fires that move and processes the next command, and the manual_stepper moves independently of the motion planner. If the very next command is a G1 command the two movements will probably be executed at roughly the same time but the firmware makes no attempt to synchronize them.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.