# M669 Custom kinematics configuration

• Hi all,

For the past couple of months I've been working on a printer concept which is similar to the CoreXYZ, but with a cross-gantry layout to avoid over-constraining the XY-gantry.
I'm considering Duet2 for the electronics and I'm trying to wrap my brain around the M669 command, as the documentation is quite sparing: https://duet3d.dozuki.com/Wiki/Gcode#Section_M669_Set_kinematics_type_and_kinematics_parameters

The kinematic equations for my system are:

``````Forward kinematics = Effector movements:
ΔX=1/4(ΔA+ΔB-ΔC-ΔD)
ΔY=1/4(ΔA-ΔB-ΔC+ΔD)
ΔZ=1/4(-ΔA-ΔB-ΔC-ΔD)

Inverse kinematics = Motor movements:
ΔA=ΔX+ΔY-ΔZ
ΔB=ΔX-ΔY-ΔZ
ΔC=-ΔX-ΔY-ΔZ
ΔD=-ΔX+ΔY-ΔZ
``````

Now this is where I'd like to get some input; as I understand the documentation, my M669 would have to read something along the order of:

``````M669 X1:1:-1:-1 Y:1:-1:-1:1 Z-1:-1:-1:-1
``````

However, reading through other kinematic implementations such as: https://forum.duet3d.com/topic/12814/markforged-kinematics-troubleshooting
Only muddy the waters more, so some constructive feedback and guidance as to how to setup the M669 command based on a specific kinematic would be very much appreciated.

Thank you

• I think you actually need:

``````M669 X1:1:-1 Y1:-1:-1 Z-1:-1:-1 U-1:1:-1
``````

That is, the XYZU parameters in M669 are the movements needed by the ABCD motors.

• I think you actually need:

``````M669 X1:1:-1 Y1:-1:-1 Z-1:-1:-1 U-1:1:-1
``````

That is, the XYZU parameters in M669 are the movements needed by the ABCD motors.

Thank you @dc42, that's a very precise way to put it.
It makes a lot more sense computational that M669 requires the inverse kinematic equations for each motor (ABCD) rather than the forward kinematics for the coordinates (XYZ).

In that sense, the nomenclature of naming each motor (XYZU) is a bit unfortunate, especially if the motors aren't directly related to the axis of the same names. I feel like the Wiki might need a wording-update to reflect that.

• It makes a lot more sense computational that M669 requires the inverse kinematic equations for each motor (ABCD) rather than the forward kinematics for the coordinates (XYZ).

In fact the firmware needs both forward and inverse kinematics, but it calculates one from the other by inverting the matrix.

I agree, for non-Cartesian architectures it would be helpful to have labels for the motors that are completely different from the axis names. However, RRF allows ABCD to be axis names too.

• I agree, for non-Cartesian architectures it would be helpful to have labels for the motors that are completely different from the axis names. However, RRF allows ABCD to be axis names too.

So what you're saying is as long as you're consequent in naming, you could use ABCD in place of XYZU in the other gcode commands where the drives are referenced? Set current, set axis steps, etc.

• I agree, for non-Cartesian architectures it would be helpful to have labels for the motors that are completely different from the axis names. However, RRF allows ABCD to be axis names too.

So what you're saying is as long as you're consequent in naming, you could use ABCD in place of XYZU in the other gcode commands where the drives are referenced? Set current, set axis steps, etc.

Possibly, but it would complicate the configuration. So stick to calling the motors XYZU.