CoreXYAC / 5-axis Voron / M669 kinematics configuration
-
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.
-
@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 (-;
-
@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.
-
@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°.
-
@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.
-
@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.
-
@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 -
@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.
-
@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. -
@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_robotDuet 2 had compilation problems, I hope the memory is sufficient. => I can try to reduce the cache memory a bit more next week.
