CoreXYAC / 5-axis Voron / M669 kinematics configuration

PXP11

Hi guys.

Short Intro:
I built a 5-axis Voron 2.4. Mechanically it works but I'm having trouble with the M669 kinematics configuration. (Duet2 Wifi + DueX5)

Long Intro:
So, I'm currently in the final phases of my study to become a mechanical engineer. As part of my bachelor thesis, I got the task to develop a 3d printing system which can be used to functionalize already existing plastic parts e.g. printing geometries on injection moulded parts. This was the perfect task for me because on the one side I know my way around 3d printers and as a CNC-Machinist by trade I have already worked with 5-axis CNC machines.
So after a short research phase I settled on converting a 350mm Voron 2.4 to 5-axis using duet boards and RPF, mostly because I'm already familiar with the firmware and it's the only one capable of handling the 5-aixs stuff.
I mainly developed three key components: AC-axis trunnion, custom printhead because of the necessary clearances and a 3D-touchprobe-tool to locate the parts in space.

Current status:
Mechanically and electrically, everything works. For the setup process I put it in the standard coreXY mode M669 K1. Homing for all the axis works perfectly (A- and C-axis do also have homing switches). A is constrained +/- 90°, C is free to rotate indefinitely.

Problem:
In my research concerning the feasibility of the project I stumble upon all the duet documentation regarding the "robot" stuff: Robot Docs. I found my way to the 5-axis CNC page (5-axis Docs) and discovered a already existing configuration for CoreXYAC. So the command M669 K13 B"robotType=CoreXYAC" should solve all my problems.
Turns out I was a bit too optimistic there. When implementing M669 within the config.g file I get the following message:
Am I correct in the assumption that those types are not implemented in RPF 3.4.5 or are other previous configurations needed before the M669 command?
So even if I must configure the kinematics matrix myself, it's hard for me to find the correct information, as it's obviously quite a niche application and the information is fragmented across different pages. For example: The M669 command is featured much more in depth on the robot config page than on the gcode repository for M669.
If someone already has any help, insight or information regarding this topic, your support would be much appreciated.

Thanks in advance
Dan

PS: I looked a lot at the OpenX5 repository from Freddie Hong but all the kinematics stuff is handled in the grasshopper/ rhino setup and not on the Duet. Due to the fact that we are planning to use commercial 5-axis slicing software this is not really a option. This printer needs to receive XYZAC lines and to move according to the kinematics model.

dc42

@PXP11 said in CoreXYAC / 5-axis Voron / M669 kinematics configuration:

Am I correct in the assumption that those types are not implemented in RPF 3.4.5 or are other previous configurations needed before the M669 command?
So even if I must configure the kinematics matrix myself, it's hard for me to find the correct information, as it's obviously quite a niche application and the information is fragmented across different pages.

We're waiting for @JoergS5 to announce a stable version of the robot code before we integrate it into our standard Duet 3 builds of RRF. Meanwhile you might like to seek advice in this thread https://forum.duet3d.com/topic/17421/robotic-kinematics.

We won't be including robot kinematics in Duet 2 builds because of lack of flash memory space. So even when we do include it as standard in our Duet 3 builds, you will need to build the firmware for Duet 2 yourself, adjusting the Pins_DuetNG.h file to enable robot kinematics and to disable enough other features to free up sufficient flash memory space.

PXP11

@dc42
Thank you for the clarification.
So this basically this means no onboard kinematics until a robot code version is released and I created a custom fork for the Duet2 with every unused pin und unnecessary feature disabled? Or just upgrading to a Duet3 6HC+3HC?

But the Duet2 should be able to handle 5-axis simultaneous movement when the kinematics model is calculated externally and just fed in as XYZAC coordinates? Or do I already need to disable features now/ is there a way to monitor the flash memory used?

JoergS5

@PXP11 @dc42 I'll make a build for Duet 2 to test whether memory is sufficient, then David can decide whether it can be integrated for Duet 2 also.

I make a version with cached values or without. Without caching, it will be slower, but needs less memory, so there are chances for Duet 2. This is handled by a #if switch, needing recompilation (or setting it to cache for Duet 3 and without for Duet 2 as default). I have Duet 2 and 3 and can compare and report the results. Another possibility is a limited cache for Duet 2, so not all subkinematics like 6 axis robot can be used, but those who need less memory.
Edit: I will currently not use the if option to avoid too much code change. The data+cache needs about 2000 bytes currently to support all subkinematics, this can be diminished for Duet2 if needed.

I concentrate on CoreXY 5 axis, this will be the first released part. Release of the test version between tomorrow or a short time later, depending whether I find bugs. I build a binary for Duet 3 Mini, Duet 3 6HC and Duet 2, but publish the sources addtionally to github for own compilation of course.

JoergS5

Testing yesterday, I found several bugs and a few ambiguities in the specification of the configuration options. I don't want to bother (or annoy) anybody with them, just correct them before delivery. A reminder for me that unit and integration testing are essential (at least for me).

Additionally, I build a CoreXY 5 axis prototype today to verify code. The forward/inverse code as such works ok. I'll post the prototype in the My Duet controlled machine section, as it may be interesting as low cost version to try 5 axis.

I'm changing configuration as well, to lower memory usage and for some special cases. The usual M208 homing procedure will be supported vor CoreXY, because XYZ are linear.

JoergS5

I have some results from today about CoreXY:

for every inverse kinematics there are two solutions for AC: A 180 degrees different and C negated. Example A=30, C = 50 => another solution with same position and orientation with A=-150, C=-50. My proposal would be to set a preference variable abSign to 0 positive or 1 negative and try to remain in this area. Or are there other proposals?

It may make sense to change the AC at some time, because XYZ position changes considerably, so space requirements can require the change. Changing while a move happens is a disaster (infinite velocity). The change could be made with a specific G-Code command.

performance looks good, on the laptop 1.4 microseconds for inverse kinematics and low memory usage. Duet 2 should be possible with a flag to limit the cache.

oliof

@JoergS5 you are allowed to be opinionated in your implementation and just pick one of the two kinematics solutions. It moght be interesting to do a "shortest path" kind of heuristic later (-;

JoergS5

@oliof you may be right, it is a problem to be solved in a later release.

In robot industrial, there are 8 inverse solutions, in all AC/BC related 2 inverse, in 5 bar parallel scara with 5 axes 4 forward (the workmodes), resulting in 4 * 2 inverse solutions, so I'll store the current preference and use it for forward/inverse, until something better is developed. The algorithms always give back all solutions.

PXP11

@JoergS5
So I actually thought about the preference angles when constructing the 5 axis Voron. The printhead was designed accordingly to accommodate an A-angle of up to 90°+ (A90) while having the nozzle as close to the build plate as possible. As of now I have set the max angle at 90° but it can accommodate at least up to 110°. Also for visibility purposes it's much more preferrable than the negative A-angles. And in general on commercial 5 axis machines and CAM Software or rather post processors, the next positive C-angle is always preferred for the possible solutions. If the C-axis is freely rotating that is, some cheap trunnions for example have to turn back to 0 after 720°.

JoergS5

@PXP11 I've tested the results of the A angles between -180 and +180 ok, but precision of the linear axes calculation is diminished when the angle is near +-90 or +-180 degrees *) (precision is about 0.3 mm then in worst case. The normal precision is in the region 1e-4 mm). I'll add double precision when being there probably or try a different algorithm. When near +-90, little rotation changes have a big influence on the xyz positions (RTCP correction) which are corrected by xyz movements.

*) near means it is approaching about +-0.3 degrees, so between 89.7 and 90.3 degress the xyz results begin to be less precise (the difference between forward and inverse kinematics result).

I add a requirement to store the absolute degree of the C axis, so a limit to +-720 can be set. I'm not sure whether the slicer or firmware shall rotate back the C axis when this limit is reached.

PXP11

@JoergS5
I think in "normal" simultaneous and dynamic operation it's actually not that likely to be near that +-90° window. Especially if you think about the printing of convex or concave shapes. The 90° angle is more likely with a stationary A-axis (radial rotary printing) or AC-axis stationary when printing "normally" on the side of a cube for example. This obviously depends on the use case. I don't know how this affects the accuracy when one or both of the rotaries are stationary.

@JoergS5 said in CoreXYAC / 5-axis Voron / M669 kinematics configuration:

I add a requirement to store the absolute degree of the C axis, so a limit to +-720 can be set. I'm not sure whether the slicer or firmware shall rotate back the C axis when this limit is reached.

Well this could either be handled in the slicer but more likely in the post processor. When the angle goes over +-720 you subtract the int-multiple and set back the position with a G92 accordingly next to 0. This would be my first and dirty solution. No idea if there would be a more refined method.

T3P3Tony

@PXP11 said in CoreXYAC / 5-axis Voron / M669 kinematics configuration:

But the Duet2 should be able to handle 5-axis simultaneous movement when the kinematics model is calculated externally and just fed in as XYZAC coordinates

yes this definitely works ok because that is how @Freddiester is controlling the original #Open5X printer:
https://forum.duet3d.com/topic/27648/5-axis-3d-printer-on-prusa-i3?_=1686302247551

JoergS5

@PXP11 I'll make a build for CoreXY 5 axis tomorrow, check in and make a Duet 2 binary, which is memory reduced, so it should work for you.

I'll make some updates to the robot 5 axis dedicated page about homing and how to specify the config.

PXP11

@JoergS5
Perfect, I'm looking forward to tiring out the build. If everything goes to plan, I should have time to test on the printer towards the end of next week.
Thank you very much for the extra effort.

JoergS5

@PXP11 I've made the build now, but my prototype is not ready, so I cannot test it. I posted you the binary, but I would prefer if I can test it next week before you damage something. I'll be out of office until Tuesday, then I can proceed.
The files are checked in in https://github.com/JoergS5/RepRapFirmware_robot

Duet 2 had compilation problems, I hope the memory is sufficient. => I can try to reduce the cache memory a bit more next week.