Trajectory Planner using Ruckig Lib

But what accelerations are you running? That’s where the challenges start to appear.

An algo that converts linear moves into velocity continuous splines (i.e. compressor) would sort it. Ain't a programmer's job though (methink), more or less for another world's Master/Adv. Mathematician Job Advert rather! Seeing line-line blending being tested by Grotius is mind-blowing already though...

You guys rock. Hands down. And, Thank you. 

@Grotius - did another test and all 4 joints generate follow errors as soon as push the "run" button.  Homing works fine.
Attached is the config file in use.
 

I have run the same ngc using a standard setup of axis with no issues.  See attached
 

Thanks - J.

Hi Joco,

Maybe try to edit line 816 from tp_runners.c to set lower values.
I used this fixed values to set the runners faster then the tp.

#include "stdio.h"
inline void update_ruckig_followers(TP_STRUCT * const tp){

        // printf("update ruckig followers. \n");

        rxyz.maxacc=tp->aMax*1.2;
        rxyz.maxjerk=tp->max_jerk*10;
        rxyz.maxvel = tp->vLimit*1.2;


I hope it will run on real hardware, offline it seemed to work out of the box. Good luck.
 

@Ihavenofish,

How does a fillet work when like segments are 0.001" long?

I can't say at the moment, fillet code is still not finished.

@Aleksamc,

May I ask one small question in your topic?
I had one problem with A axis (or any other, that not belong to XYZ).
I generated G-codes in ArtCam (it generates a lot of small pieces with length of movement 0.1mm). When I did such code for A-axis (rotary) I received very slow movement. Solution of that was to rename A to X, as example.
Does your trajectory planner could solve this problem?

This solution is not in the trajecory planner, but i get your point. We are still not ready with coding the trajectory planner.
Later on, we can look at external axis and how to process them outside the xyz tp movement.