Trajectory Planner using Ruckig Lib

Yes XYZAC, XYZBC need different kinematics. For the math and calculating the tool direction in opencascade i just
thought use the letters A & B. At this stage the kinematics are not solved. Only the tool tcp & tool direction is then solved.
Do you think this is ok?

If you want to handle the specific kinematics separately then maybe it would be more generic to calculate smoothed tool orientation as a unit vector (ie length = 1) with origin at (x,y,z)=(0,0,0).
1. Calculate the vector pointing from smooth TCP knot to smooth TA/TO knot
2. Translate this vector to (x,y,z)= (0,0,0,) (ie subtract smooth TCP knot coordinates from start and end points)
3. Normalize the vector to get a length of 1. 

To get the specific tool orientation angles we could parse the ini file to find out which rotary joints are available and calculate the appropriate angles (ie A,B or C ) from this orientation vector using 'atan2' function. I have done some work that calculates spindle rotary orientations from a given tool orientation vector, although that was in python. There will likely be some issues with rotation directions and joint limits that I had to deal with but if  your algo spits out the orientation as a vector then this could all be handled separately.

@Hi,

I just made a test for 5 axis. xyz abc.
Where a rotates around x, b rotates around y. The c axis is the cone symetric axis, like spindle orientation.

The tool direction line is 15mm of lenght.

nice!
I like the added preview of the tool orientation.

Where a rotates around x, b rotates around y. The c axis is the cone symetric axis, like spindle orientation.

Which reminds me that to calculate the tool orientation vector correctly we already need to know the kinematic for which the GCode was created. In your example the C axis value does not have any effect on the orientation tool path at all because it is applied last. If, however, the C axis was applied first (ie it would be the primary rotary axis) the path would look much different.

Hence we will need a way to encode the general type of kinematic in the ini file. We need to know whether the rotary axis is moving the tool or the work and if the rotations are on the same side (tool / work) the we need to know which is the primary and which is the secondary.

I assume there are economic software functions available to apply rotations to a given vector in any sequence?

Actually, since we are calculating the tool orientation vector and later the rotary axis position for a given kinematic it seems we could just (or also) use generic 5axis gcode in vector format to start with. Not sure how widespread vector format output is in cam options though.

[edit]
www.fanucamerica.com/CMSMedia/DnP/Vector...e%20Machining_11.pdf

@Arciera,

From the document i found interesting line :
G1 X0 Y0 Z0 I-0.5 J0.5
K0.7071. For a properly defined vector

They use I,J,K for vector. But for G2, G3 that is not a valid gcode input. Preferr to use AB for the vector and use
C for the spindle orientation.

--
Basicly when using external rotary table, we could use this as axis u,v,w.
Where u=rotation around x, v=rotation around y, and w=rotary table clamp symetric axis.

Then we have a xyz, abc, uvw machine, 6 axis for tool, 3 axis for extern rotary table.

But this then is a single machine config that has valid kinematics for a few configurations like : xyz router,
xyz router + abc head. xyz router + abc head and a uvw rotary table.

So all other configurations, like xyzab, xyzac, xyza, etc need a different software approach.
And i think not all of these variants can use tooldirection optimalisation. Like xyza, where a is secondaire z axis.

So if i add selectors to the program config section :
1. xyzab
2. xyabc
3. xyz
4. xyza
5 xyzabc
6 xyzabcuvw

Then it should use correspondenting c++ function to translate gcode into the proper tcp, and other axis.
Like choosing kinematics.

What you think?