6-axis compatible

Hi. I expanded the klipper’s control axes from 3(XYZ) to 6(XYZABC) with the addition of roll, pitch and yaw. I have checked the operation with my own printer. I would like to submit a pull request to expand to 6 axes. The aim is to support robot arms and non-flat printing.

1 Like

Is the topic I wrote different?

Do you have any pictures of your printer?

I’d be interested in seeing what you’ve come up with.


I think that various mechanisms can be implemented, but this is just an example.

I am running it with klipper. A G-code is something like “G1X0Y0Z0A15B30”. B is the tilt angle and A is the tilt rotation angle. (I think kinematics is still in the development stage and I would like to keep it private.)

There was also another thread with similar content:

However, no one else seems to have implemented it yet.

very cool! can you link your fork or make a pr?

It will be this link. Now we are modifying the internal core to move the 3-axis kinematics with the 6-axis state. Please cooperate with the development.

1 Like

Thanks for the link! So -

G1 X0  Y0  Z0  A0  B0  C0
G1 X10 Y10 Z10 A10 B10 C10

-would go smoothly and synchronously go from 0 to 10 on all axis? Will you do a PR?

I think each axis is moving synchronously. I made a pull request, but it is necessary to clear many setting files in the inspection process, and as a result, an error occurs in a file that does not support the 6-axis specification. I am modifying the core area of ​​klippy. As a result, the ripple effect was large, and it was found that there were many changes in modules that had not been confirmed, and it was not possible to deal with them easily.

Nice work!
I would like to give it a try but I don’t have delta printer (yet).

There doesn’t seem to be a complete integration in the motion planner code. Only the planar components of the move set the pace of motion. So there is no guaranties that the rotations movements will be bounded by the configured limits. But then angular feeds and accelerations would have to be defined separately.

I don’t think that the interpretation of the rotation axes as cartesian axes is valid. For example, in the formulas:

move_d = math.sqrt(sum([d*d for d in axes_d[:6]]))


junction_cos_theta = -(axes_r[0] * prev_axes_r[0]
                       + axes_r[1] * prev_axes_r[1]
                       + axes_r[2] * prev_axes_r[2]
                       + axes_r[3] * prev_axes_r[3]
                       + axes_r[4] * prev_axes_r[4]
                       + axes_r[5] * prev_axes_r[5])

However, for the shake of genericity, maybe this is a close enough approximation?

1 Like

You are correct. Perhaps, but the calculation method needs to be changed depending on the kinematics (using a configuration file).

I believe that the current process of processing all 6 axes the same is more suited for trunnions like machining centers. Please read this paper.

I do believe that if the object to be formed is fixed, such as my HEXA or robot arm, it should be calculated in only three axes (XYZ). But I haven’t gotten there yet because I don’t know the optimal shape.