Thanks. I have some high-level comments:

1. I'm leery of naming the code and support after the company "markforged". I think we should come up with a name that better describes the actual kinematics (maybe something like "hybrid-corexy").
2. It shouldn't be necessary to add a kin_markforged.c file. Instead, the python code can select one of the existing cartesian_stepper_alloc(), corexy_stepper_alloc(), or corexz_stepper_alloc() as needed.
3. There's a lot of functionality added here to review. It would be preferable to split this up into a few commits - I'd suggest: add support for basic kinematics, then add support for basic dual_carriage on top of that, and then finally add support for "mirror mode" (and similar) on top of that. I think splitting up into multiple commits will make it easier to review.
4. I haven't completed a full review, but I did notice things like rail.kin_infos = .... The Klipper convention is to never "peek" into member variables of classes defined in other code files. This is important to keep the code maintainable over time (it's mentioned briefly in docs/Code_Overview.md).

-Kevin

Thanks for the comments.

1. I am concerned with that too. Since Marlin, RepRapFirmware and many sources uses that name for kinematics I thought it would be ok. "hybrid-corexy" sounds good to me, I will modify it. Can I just refer to Markforged somewhere?
2. for waiting and positive movements it works but not for negative (hybrid-corexy= y-x; corexy= x-y). If it is ok for you I will keed the kin_markforged.c only for the negatives movements which are un relations with mirror mode.
3. ok
4. those variables are for keeping in mind which stepper_alloc is currently used and the position if waiting. The carriage in a wait is still updating the rail's position since it follows Y moves. Should I add those features to stepper.py or manage them into the hybrid-corexy kinematics?

For duplication and mirror modes extruder steppers and heaters have to be synchronised. For testing purposes I figured out to declare dummies values for the pins in the extruder section and use an extruder_stepper section with the SYNC_STEPPER_TO_EXTRUDER g-code command. For heaters, the easiest way at the moment is to edit the gcode file and duplicate M104, M109 commands in adding the T1 parameter . It works but it is not the correct way to do it. Do you have any suggestions?

Tircown

Can I just refer to Markforged somewhere?

I think it's fine in comments and example configs. I think it would be preferable to avoid the name in filenames and class names.

for waiting and positive movements it works but not for negative (hybrid-corexy= y-x; corexy= x-y)

Wouldn't y-x be the same as -(x-y) which would be the same as x-y with the stepper direction pin inverted (eg, !PA1)? Or am I missing something?

those variables are for keeping in mind which stepper_alloc is currently used and the position if waiting. The carriage in a wait is still updating the rail's position since it follows Y moves. Should I add those features to stepper.py or manage them into the hybrid-corexy kinematics?

I guess I don't fully understand the above. But, it sounds like it should be tracked in the "hybrid-corexy" kinematics code.

Do you have any suggestions?

FWIW, I'm struggling to understand the code (and questions) because I'm not that familiar with either the new kinematics or the "mirror mode" stuff. Is there something the "mirror mode" (and similar) is doing that is fundamental to "markforged" kinematics? That is, is there some mode it implements that can't fundamentally be implemented on a cartesian dual_carriage printer?

-Kevin

The firmware have to invert the direction dynamically: carriage 1 have to be able to run in both directions by being synchronised with carriage 0 depending on the mode.

Mirror and duplication simply reproduce on carriage 1 all what carriage 0 is doing. This allows to print two identical or mirrored pieces at the same time. Both hotends extrudes exactly the same amount of plastic at the same time. Basically, you slice only one piece on the edge of the first half of the X. The firmware have to do the magic trick.

Effectively, my plan is to port duplication and mirror modes in cartesian too in a near future. It should works exactly the same as in hybrid-corexy. The new limits are calculed from the positions of each carriage when mode change. This should be usable as it is for the cartesian dual_carriages. So, half of the job is already done.

Okay, I think I understand. FWIW, my initial reaction is that "mode" support is likely better placed in its own "extras" module, and not in the "kinematics" code. If I understand correctly, the goal is to be able to control the second toolhead simultaneously with the primary toolhead. This sounds like a fine feature, but it seems that it isn't specific to the kinematics of the toolhead. It seems to be about controlling multiple toolheads with standard kinematics, than about a "mode" of the particular kinematics.

Cheers,
-Kevin

Any further updates on this?

-Kevin

I could release PR soon for the basic hybrid-corexy and the dual-carriage version immediatly after. The "extra" module is more complicated for me.

I understand. If you want to submit the basic "hybrid-corexy" code I think we should be able to merge that without much work.

-Kevin

Hej

Just found this on my way to compile Marlin for my new printer. I use exactly this kinematic and thought it's not supported by klipper. So I'm happy to see this!

Any plans when this will be merged?

And another question.
Is it possible to implement a belt driven extruder like the x axis belt? Basically a remote extruder direct drive system.
In principle this would be a belt for the extruder that looks exactly like the x axis belt but compensates the x and y movement.

Any news?
It seems that this modification just needs to be merged!?

What's the status of this PR? I'm guess it's stale now that PR #4229 has been merged.

-Kevin

Yes I close this PR as #4296 can host all the discussion now.
Thank you.