Replication Mode? Requires changing kins somewhat on the fly

I’m looking at implementing replication mode in Klipper, IE you have two X carriages on one linear guide and either send the same commands to both of their motors, or send inverted commands to either print two identical parts, or mirror copies of the same part.

I’m attempting to do the non-mirror version first by:

  • Adding a macro to home both X carriages then position T1 in the middle of the travel
  • Adding a custom command to switch the X rail out for a new custom rail which addresses both steppers
  • Using the same command with a different MODE parameter to switch back to the original rail afterward.

IE I’m trying to copy the dual_carriage implementation. I’m running into problems with shared pins between the original X axis, the dc_axis, and the new ‘both’ axis, but I think I might be able to solve those with share_type? I’m gonna try it and see if bad things happen.

Is this a sane approach in general though? IE, can I create conflicting stepper instances on the mcu and have things go well as long as I never address them at the same time?

Relatedly, how on earth should I go about inverting my T1 dir pin for mirror mode?

Thanks,
-Nick

1 Like

Interesting.

FYI, there’s been some recent discussions on this at kinematics: Add dual_carriage to hybrid-corexyz by Tircown · Pull Request #4296 · Klipper3d/klipper · GitHub and kinematics: Add Marforged kinematics by Tircown · Pull Request #3609 · Klipper3d/klipper · GitHub .

I haven’t looked at this in detail, but I would think one could use the same micro-controller stepper object and just hook it up to the “trapq” motion queue with different kinematics rules (stepper_kinematics). Again, though, I haven’t looked at it in detail.

I’m running into problems with shared pins between the original X axis, the dc_axis, and the new ‘both’ axis, but I think I might be able to solve those with share_type?

I’m not sure what would happen if you defined the stepper object twice in the micro-controller. It’d probably “mostly work”, but it’s hard to say what would happen in the “corner cases”. Probably better to define just one mcu object and do the arbitration in the host.

Cheers,
-Kevin

Hi there, I just put some time to convert BCN3D Sigmax to klipper, but how sad I am now, findind, the duplication and mirror mode is not implemented. The intended behavior is described in #2323 and #1131
Is there any progress?

I can imagine gcode_marco M605 Sx that will drive X1 to half or mirror position and then activate hardware relay, to detach X1 step pin from mcu and attaches it to x0 step pin (same for extruders) or another relay with negation to invert X1 dir pin for mirror mode.
M605 S5 duplication mode
M605 S6 mirror mode
M605 S0 normal mode - independent X

Are these relays and negation difficult to implement in firmware?

I would love to run klipper on Sigmax with all its abbilities
Thank
Ludek

Hey @lutomi - just looping back in to point you towards the idex_modes.py file now merged in mainline Klipper. I’ve been using it successfully for a few months on a branch based on one of Tircown’s earlier WIPs, but looks like it’s fully merged now so you ought to be able to get your printer running.

Hi @nick-parker. Thank you for this information. Can you help me apply it on my printer? I have no idea how make it. Is there a sample configration or macro?

Sorry @lutomi I spoke too soon. The idex_modes module has been merged but the improvements to it which support duplication/mirror are still waiting in this pull request

If you grab Tircown’s code from that PR you should be able to get your machine working.