New generic_cartesian kinematics (incl. CoreXYU/CoreXYUV, generic IDEX and AWD)

@koconnor @dmbutyugin FYI.

test kinematics: generic_cartesian by Dmitry Butyugin

Core XYU - dual carriage + IDEX mode

Kinematics configuration

#--------------------  Motor X ----------------------------------#-
[carriage x] 
....
[stepper x]
kinematics: x+y
....
[tmc2208 stepper x]  
....

#--------------------  Motor Y ----------------------------------#-
[carriage y]
....
[stepper y]
kinematics: x-y
....
[tmc2208 stepper y]   
....

#--------------------  Motor U ----------------------------------#-
[dual_carriage u] 
primary_carriage: x
safe_distance: 35
....
[stepper u]
kinematics: u+y
....
[tmc2208 stepper u]   
....

Mechanical design of XYU belts

I think the generic_cartesian kinematic saw some sufficient testing so far, and the results look very promising. So, @koconnor, I’d appreciate if you took a look a the latest proposal (summarized in the first message, which I edited accordingly) when you have time and see if disagree with any of the points we debated over previously. If we can reach an agreement, I could start working on the documentation and the PR.

Also, @miklschmidt and @HelgeKeck, I’d appreciate if you actually gave it a test on RatRig v4 (normal and IDEX), as this is the feature required to support these printers with mainline unmodified Klipper.

Sorry i’ve been so quiet on this, i’ve been absolutely swamped. I’m not sure i can make the time to test this properly for at least a month or two, there’s just too much going on. It looks good to me though, appreciate the effort you’ve put in here. I’ll see if i can get an implementation out to the beta team once i get over the initial influx of new users.

@HelgeKeck is it possible you could give this a whirl in the mean time?

Test Core XY + Core UV - dual carriage + IDEX mode

#-------------------  Motor X -------------------------------#

[carriage x] 
....
[stepper x]
kinematics: x+y
....

[tmc2208 stepper x]  

#-------------------  Motor Y -------------------------------#

[carriage y]
....
[stepper y]
kinematics: x-y
....
[tmc2208 stepper y]   

#-------------------  Motor U -------------------------------#

[dual_carriage u] 
primary_carriage: x
safe_distance: 35
....
[stepper u]
kinematics: u+y
....
[tmc2208 stepper u]   

#-------------------  Motor V -------------------------------#

[stepper v]
kinematics: u-y  
....
[tmc2208 stepper v]   
1 Like

Thanks for working on this. I took a quick look at your latest config proposal, but I haven’t had time to look at the implementation. In general, your proposal looks like it would add useful functionality.

One minor comment I’d have is on the naming of the stepper kinematics parameter. If I’m understanding the proposal correctly, it effectively takes a list of carriage names. Might be better to make that more explicit in the option name. (For example, carriage_control: u+y, but I’m not really sure what a good option name would be.)

FWIW, might be better to hold off on supporting that until there is a concrete use-case. The ā€œgeneric_cartesianā€ support is already going to be a challenge to document and support.

Cheers,
-Kevin

@koconnor @dmbutyugin FYI.

Test Dual Gantry X with dual carriage (Core XY + Core UV ) + IDEX mode

# -----------------  Motor X -----------------------------

[carriage x] 
...

[stepper x]
kinematics: x+y
... 

[tmc2208 stepper x]  

# -----------------  Motor Y -----------------------------

[carriage y]
...

[stepper y]
kinematics: x-y
...

[tmc2208 stepper y]   

# -----------------  Motor U -----------------------------

[dual_carriage u] 
primary_carriage: x 
safe_distance: 0
...

[stepper u]
kinematics: u+v
...

[tmc2208 stepper u]   

# -----------------  Motor V -----------------------------

[dual_carriage v]
primary_carriage: y 
safe_distance: 35
...

[stepper v]
kinematics: u-v
...

[tmc2208 stepper v]

2 Likes

Can I just say that I love the work you’re doing - really interesting and I’m seeing what can be done with Klipper.

1 Like

@koconnor , @dmbutyugin FYI

Hi,
Maybe it’s just my feeling but consider using the syntax:

[carriage_x]
[dual_carriage_u]
[stepper_x]

At least for me, it’s more natural to use including ā€œ_ā€.

-Petr

The space separates the module name from the instance name. Carriage is the module, and X is the instance name, as such the space makes sense both semantically and syntactically. The way klipper configuration currently works, you’d need a module for every single carriage, dual_carriage and stepper section if you used _ instead, and it would be different from all other sections in your config, eg [mcu host], [adxl345 toolboard], [generic_fan chamber_fan] and so on.

@miklschmidt

Hi
Well, it seemed more logical to me just from ā€œ_ā€.
Because currently [stepper_x], [stepper_a], [stepper_left], [stepper_bed] etc. are also used for different kinematics.

But it’s just a matter of getting used to it.
I’m just a user not a programmer.

Hi @koconnor and @dmbutyugin

When could this feature be added to Klipper?

-Petr

I’m working on the documentation and thinking about some suggestions on the naming. Right now, I took the first stab at the documentation, so everyone is welcome to check it out and share their feedback.

1 Like

For those following the progress here: I opened a PR for this feature.

5 Likes

Hello, I made an account here just to come and personally thank you for this amazing work!
I’ve recently built an IDEX Corexyuv printer and I thought I was SOL when it came to firmware support for it, but I’ve already been able to get some prints done with your fork from a few months ago. I’d love to help you where I could - I can code but the maths certainly go over my head, however if you need help with testing something or documentation I’d be glad to help!

1 Like