Trajectory Planner using Ruckig Lib

Grotius wrote:

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.

Attachment not found

Hi Grotius.  I got this compiled on my plasma table and gave it a whirl using the same config in use for previous tests. Just with new runner module active.  Things home ok but as soon as I try and run a test ngc joints 0,1,2 all get follow errors.  NB this is a 4 joint setup being a gantry machine. 

I will have another crack later in the day and if still having issues will attach the config in case you spot a silly mistake.

cheers - J. 

I've been surprised. I recently did a vac form mold in aluminium and it happily moved along at 200+ipm. The limit seems to be the machine, not the software at least in this zone. My program was like 14mb for under 30 mins of cutting.

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.

Hi.  Took those increases out so no multiplier in place.  Still exactly same problem.  Might need to spend some time tracing through where the ferror testing is happening and therefore why it is triggering.  Not tonight and not until tomorrow afternoon as will be in the office for most of the day.

Cheers - J.

Joco wrote:

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


 

0.3g acceleration.