Trajectory Planner using Ruckig Lib

Quick question, why has Open Cascade become a build dependency?

I have created an "scurve" branch at the point before all the UI additions so we can keep some separation of focus.

I have been tinkering with graphviz to map out some of the call hierarchy that happens around the trajectory planner.   This might be of use to someone.
Here is the image as it stands:
 

Here is the graphviz dot code for the image:
 

Cheers - James.
 

Hi Joco,

Nice work! Soon going on with scurve.

@Joco

Consider using much higher max_jerk if you haven't gone much past 6000. It's in mm/s^3 - Datron Cube for instance uses (iirc) 60000 for finishing and 300000 (!) for roughing. Of course my machine isn't quite that rigid, but as I showed in my post earlier ( forum.linuxcnc.org/38-general-linuxcnc-q...-lib?start=30#283537 ) I settled on using 22000 mm/s^3 on the machine (with 8000 mm/s^2 accels). I imagine your plasma machine can achieve much higher jerk/accel than my heavy router with steppers!

@Ratchet

Kind of an aside, but you can look into Octave if you want to generate some code from your math modeling - it is more/less an open-source equivalent of Matlab and is very easy to port code between the two programs as they have similar syntax - Octave does handle functions slightly differently.

I added a bunch of TODO items to the repo for myself and will follow up on these - November/December is the busiest time of year with work for me unfortunately, but I can make some progress nonetheless.

Consider using much higher max_jerk if you haven't gone much past 6000. It's in mm/s^3 - Datron Cube for instance uses (iirc) 60000 for finishing and 300000 (!) for roughing. Of course my machine isn't quite that rigid, but as I showed in my post earlier ( forum.linuxcnc.org/38-general-linuxcnc-q...-lib?start=30#283537 ) I settled on using 22000 mm/s^3 on the machine (with 8000 mm/s^2 accels). I imagine your plasma machine can achieve much higher jerk/accel than my heavy router with steppers!

Thanks - that's some good guidance.    I'm in the process of dismantaling my gantry to add another linear rail to give a significant upgrade in the stiffnes of the X carraige mounting.   On hard accelerations through Y I was getting very bad torch wobble.  Parallel rails will solve that.   Once done I will be able to return to 3000mm/s/s accels and look at max speeds circa 30,000mm/min.  I might be able to run accelerations up into the 6000mm/s/s but its creating a lot of stresses and unless I am cutting a lot of sub 1mm steel at 60A I just don't need that level of performance.

Cheers - James.
 

Hi,

Today i started working on scurve again.

To inform you about current status.

I used the tp_scurve_skynet version and added 3 extra ruckig xyz runners on top of the tp runner.
Now in total there are 4 ruckig runners.

The runners are single dofs, one for tp, one for x, one for y, one for z.

The xyz runners must follow the xyz toolposition, performing a scurve motion profile. Notice,
the maxvel for the runners is the maxvel for tp, so no tp race is going on.

Then we can calculate the following error for xyz at runtime and display it with halscope :


Now this seems to work, in fact, here we eliminated the infinite jerk in one smart coding move.
Now to display this following error in axis, we could use the new axis c++ gui. Just an idea.
This new axis c++ gui can show us 2 tool cones. One cone for tp and one cone for following error.

Ok github is updated.

Hi,

Ok now i say the tp has to output the value of our runners.
Only path rules are colinair segments and rapids.

Look at the stunning result.

 
 
 
 

Hi,

Here are some test values from repeatedly test the same linuxcnc startup screen gcode.

During runtime i can set the xyz runners input values like, maxacc, maxjerk & maxvel to by multiplied by a scale factor [x].
If scale factor >1,  they can keep up with the tp runner more easely.

Here are test outputs when using different scale factor[x] values for jerk_max, vel_max & acc_max.
The error value is the off path extrema in mm.

 

I found out :
The off path extrema is high at the end of a rapid.
When tp is doing g1,g2,g3, the runners do a good job and accuracy is quite good.

Next thing to test is a gcode with sharp corners and a gcode with fillet corners.

Hi Guys,

I did another test today, wich seems to work out of the pandora box :


It is in fact the original lcnc trajectory planner written by Rob Ellenberg with another engine
under the hood. This engine are 3 ruckig runners hacked into his code.