Trajectory Planner using Ruckig Lib

Interesting you have ended up with a runner for each dof. Since the UI update i had been looking into the single ruckig in relation to multiple axis and considering a real world example (my plasma table) and how it could deal with the different limitations that exist.

I had come to the conclusion that a single ruckig instance could not adequately cope with the realities of, in this example, my machine. I need to have different jerk and acceleration values honoured by axis. This due to the differences in motor strengths on Z, different construction strengths between X and Y and thus different points where excessive flex and harmonics appear.

Intuitively I think having the multiple ruckig runners is where we need to be.

I will, when get time after rebuilding my table, dig into the recent approach.  It could well be leveraging the existing TP with ruckig runners informing/adjusting the accelerations and velocities might be the way.  

great work.

cheers - J. 

Hi Joco,

Good luck with your machine.

Indeed the xyz ruckig back-end runners ensure at least a valid motor output with no velocity jumps.

I still believe in our own trajectory planner, I think we have to add blending to it first.
Then we could use the G64 P0.01.

So i started writing a blending function, 3d blending wich works now for line-line blending. Arc-line blending still todo.

Hi,

I added fillets for arc's and line's. But still work todo. It's not easy.

One problem is when you have a arc and a line in different planes. I don't know how to create a 3d fillet then.

So far the fillets look amazing.
 

How does a fillet work when like segments are 0.001" long?
Some programs like fusion already have fillets built in to path generation, but they go bonkers on micro segments.

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?

In globally, this is not a problem of the trajectory planner. It's about the settings of the postprocessor + machine program + the trajectory generation algorithm in the program. Most likely, you need to tick the boxes so that circular and spiral interpolations are not generated into small segments but execute a full frame. Perhaps this also needs to be specified in the postprocessor if you don't have the proper instructions for generating circular and spiral splines.

scurve branch has now been synchronised with Grotius's latest works and proven to compile/run using the build_make and build_cmake script sequence from the cmake directory.

This means no need to setup for OCC compile dependencies.

Cheers - J.

Currently, it's only for art models - there is no circles and other similar forms. Such g-code could be only parted with small lines.But thanks.

Modern cad spits out micro segments. A modern machine needs to keep up. Linuxcnc actually does mostly keep up, but without jerk control it can be a rattling experience. G64 mode does smooth over 90% of the moves automatically. The last 10% is what I am hoping will eventually get worked out here.

ihavenofish wrote:

Modern cad spits out micro segments. A modern machine needs to keep up.

True. The CAM I use for 3d contours is all linear output and constrained within "in-tolerance" & "out-tolerance". Can easily put up a beefy half-a-million blocks for a 5-10min machining operation (eg. mold surfacing). I wouldn't expect this to run on Lcnc without an ultra-fast smoothing algo the like of CYCLE832 (Sinumerik).

This project/thread seems the way to go.