Assign axes to kinematic, multiple kinematics

[JoergS5]

I wish to assign axes to a specific kinematic and use more than one kinematic at the same time.

The idea is to combine different kinematics into one printer, e.g. the bed shall make 3 movements and 3 rotations, and the hotend shall make Delta. So I need to be able to assign XYZ to Delta and UVWABC to a Cartesian+Rotations kinematic.

Is this possible and what changes to the firmware are necessary?
The synchronized movement would be possible today if the slicer supports it, but the interpretation of ABC as rotations is not possible today imho.

I would prefer a general "modular" approach, in the sense that different kinematics can be combined in the config setup. Something like "setup kinematic K1 with axes XYZE1, and kinematic K2 with UVWABC". It would be good if the same kinematic can be used more than one time, e.g. using two hotends with Cartesian kinematic at the same time, like for a printer with two cranes (Bad example, this would be possible today, take two 5-axis-robots as cranes).

[dc42]

The main changes to the firmware I envisage would be:

1. Support multiple kinematics, by having an array of Kinematics pointers in the Move class instead of just one.

2. Add an additional parameter in M584 to say which kinematics# the axes mentioned in the command belong to. Perhaps like this:

M584 K0 X0 Y1 Z2
M584 K1 U3 V4 W5

The second M584 line in this example would automatically create a second Kinematics. A map of axes to kinematics# would also be created.

3. Extend M669, M665 and M666 so you can say which kinematics the command refers to. M667 can be left as always referring to kinematics 0.

4. Change the DDA class to handle multiple kinematics, using the map of axes to kinematics. There may be some complications here.

5. Change the homing mechanism so that when a homing switch is triggered, it uses the correct kinematics for that axis to call OnHomingSwitchTriggered on.

I would be reluctant to do this in RRF for Duet 2 because of memory limitations, but there would be room in RRF for Duet 3.

There are probably other firmware changes needed that I haven't thought of.

[JoergS5]

@dc42 Thank you for your thoughts. I will try starting with a flexible bed and a simple kinetic as hotend.

I had some additional thoughts at the meantime: if a G-Code line is executed with multiple kinematics, they need to end at the same time, because the speed will be not 0 at the end but takes into account the next G-Code line. So to avoid that one kinematic has to wait, the distance/speed must be same, so a kinematic-specific F (or a speed factor) would be useful.

But I will start "simple" first. Thanks for your input!

[dc42]

I think it would be automatic that the move ends at the same time for all kinematics.

[JoergS5]

@dc42 this would be good. I have to calculate the slicer to avoid collisions, so I need to know when the kinematics are where at which timestamp.