JoergS5's CoreXY 5 axis (robot kinematics)
-
@JoergS5 said in JoergS5's CoreXY 5 axis (robot kinematics):
A0 can be used to have a hotend which follows the print path.
That would be handy for air-assisted laser or baird-air print cooling:
You could aim the air, where it is most effective.place the Z axis to the hotend like a gantry CNC does it
Then you need a very stable joint between the real XY-gantry and the z-axis. It would be best to have two XY-rails and two z-rails building a #.
-
@JoergS5 have you looked at the zeroing solution the BrendonBuilds implemented for the Voronoi build:
https://github.com/FreddieHong19/Open5x/tree/main/3D_Model/Voron_0/DuetConfig/macros
This is interesting because it relies entirely on Meta Gcode to set the 0,0,0,0,0 position of the 5axis machine.
Currently it simply iterates through to the 0 crossing point one axis at a time, this may be sped up using a different method to iteratively determine the 0 point. It relies on a nozzle touch probe which on the Voronoi is implemented with electrical contact.
-
@T3P3Tony thank you for the link. I'm thinking a lot about how to home and calibrate fast, e.g. with the help of the LDC1612.
-
@o_lampe I currently plan to use two linear rails for the X axis (one in front, one on top) to stabilize the Z axis vertically. This will be especially important for a long Z.
-
@JoergS5 yes, we have also discussed this. Using the LDC1612 to detect the nozzle.
-
3rd edition? You'd think they would have got it right the first time.
-
-
@Phaedrux also that tape measure looks wrong...
-
This post is deleted! -
I've change the kinematics from screw theory to geometric algebra. It works much better now, especially with the Z direction, I had some errors.
Screw theory says that directions of axes must be reversed, depending on whether the axis is attached to the hotend or the table. I'm unsure whether it's the same with geometric algebra. This matters for Voron, whose Z axis is attached to the hotend part. If it matters, I'll have to add a paramter to specifify whether X, Y, Z axes are attached to hotend or bed.
I expected that geometric algebra is slower than screw theory, but to my surprise it is faster: 15 microseconds (for both forward and inverse) compared to 30 of screw theory for each segment calculation. M669 R gives a statistic. (M669 R currently unhomes all axes, I don't know why).
=> Edit: I know why it unhomed, it was the seen variable in Config. I've added a D parameter (see documentation on the main page) to decide not to unhome if wished, if configuration is changed.
I currently build bins and will upload to github together with the sources. Duet 2 still compiles without error.
BC mode should work also, but I have no BC prototype and cannot test it.
I saw an article to build a machine with two rotary axes with arbitrary angles, this I will investigate. It uses Paden-Kahan 2 to translate AC/BC angles into the machine angles. This will cost processing time however.
-
Short update about my activities:
I am aware that RRF is restricted by memory and performance. It has only a few KB or available RAM and every ms is important. So I thought about how to optimize the usage for robot kinematics and will try the following procedure:
- best performance is when the axes are perpendicular and AC/BC axes are in A/B/C directions. The calculation is easiest then and performance best
- the algorithms allow skew axes and arbitrary axes also, so I want to support them also
- so I'll establish a decision tree to use the simple, fast calculations when configuration uses the first case and full calculation for the other
- at every move, first is a call to LimitPosition, so I can check configuration changes there and cache values if possible
- one performance measure I didn't use yet is to cache AC/BC values for moves where AC/BC don't change. I'll implement this now
For memory usage of the bin file, I'll remove every code which is not used. I have a lot of code to calculate between transformation matrix, quaternions, Euler angles, CGA and skrew theory. I don't want to loose it, but storing it into RRF uses much memory. So I'll make a separate github project to store it there. The redundant solutions allow cross check of the calcuations.
For visualisation, the DWC is a bit problematic for me, as I don't want to migrate between C++ and TrueScript. I'll use C++ with OpenCV until I have a better solution (or someone can tell be a solution). So I can use one C++ code base.
An open topic with 5 axis is that rotations are not velocity constant. I'm thinking about how segmentation could be changed, but this is code outside kinematics, it is part of the core RRF. An intersting article to introduce into the topic and how it could be solved with a modified slerp is "Yan/Jeng/Chieng Five-Axis Slerp for Tool-Orientation Planning in a Five-Axis CNC Machine".
-
@JoergS5 I am very interested in your progress so far. I am about to build a mini mill and will at some stage get a 4th and 5th axis so if you need help testing let me know. I will most definitely be 3-4 months off getting it done as funds don’t allow it at the moment so the project is being drip fed
-
@samlogan87 my next step is to CNC including milling, so my activities will help your project. I have e.g. a boring head (german: Ausdrehkopf) which I want to integrate.
-
@JoergS5 said in JoergS5's CoreXY 5 axis (robot kinematics):
Voron, whose Z axis is attached to the hotend part
Just a note. this is only the case for Voron 2.x, V0 and Trident move the bed.
-
@T3P3Tony thank you Tony for the comment. It's important to be aware where the axes are attached (hotend or bed), because this reverses the calculation.
I'll make a decision matrix in the documentation with sample config settings to make it clear. Especially with CNC and milling there are several variants, e.g. the A axis being at the drill side.
