CoreXYAC / 5-axis Voron / M669 kinematics configuration
-
@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?
-
@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.
-
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.
-
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.
