Trajectory Planner using Ruckig Lib

Hi Arciera,

I'm still a little confused how to solve this 5 axis geometry. Especially caluclating the inbetween TA knots.

If knot Tcp.0 to Tcp.1 = 100mm.
if knot Ta.0 to Ta.1 = 150mm.
Then tcp 50% = 50mm, then ta=75mm? This should be the interpolation.

Should it be like above?

For only "a" axis, i think just interpolate this. And make it a master move when "a" axis need more time then xyz.

For halcore the progress is running a program with scurve now.
It can start from line, motion fwd, motion reverse. It has a scope for the trajectory planner.

Hi Arciera,

I understand now.

Then my interpolation proposal seems correct :

G1 X1 Y2 Z3 A10 C20
G1 X11 Y2 Z3 A20 C40

Here the xyz moves 10 mm = Line lenght xyz.
Lets assume the spline or fillet lenght from "Q0 to Q1" -> "A10 C20 to A20 C40" = 40mm

Then the interpolation for xyz at 5mm = t0.5 (for interpolation i use time 0 to 1 for a segment)
For Q0 to Q1 is t0.5*40mm = 20mm on the spline or fillet path.

Then we can calculate new vector for A & C. This vector then has a A and a C value for radians.


This whole circus can be done offline in opencascade cad.
So just like you proposed, we do the

1. Run the clothoid fillets algo based on G64 P & Q input values. In one gcode file different fillet sizes can be given.
2. Run a tool orientation algo for a & b axis. I think using A & B is simplest. This then solves smoothing for A & B axis toolpath.
3. Run a check if A & C orientation's can be made in the xyz move time, otherwise xyz velocity must be lowered down.

Did we miss something? Or is it ready to be coded?
 

@Hi,

Tonight i went to the production machine with a hard-drive for testing hal-core.
After figuring out how to setup hal parport and run posix realtime etc for a few hours,
i managed to run the machine on hal-core.

Most of you know halcore uses no python and is very compact coded.
It run's posix realtime, so i am happy for today.



github up to date

Hi Arciera,

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?

I'm still a bit confused seeing that tool motion still decelerates to a full stop after each segment.
In the video i speak about a first test without any motion logic for hal-core. Stopping motion at each gcode line.
Next step now is to add g64 fillets to the gcode. Then eventually the look ahead add's end velocity where it can.