Trajectory Planner using Ruckig Lib

@Joco,

Are you factoring the fact the fact that the arc at this line is in fact a circle or is something happening under the hood which is causing this to happen as a result of what is being produced by the ruckig library?

This zero lenght arc is produced by a cam program using cavaliercontours. Normally this would be filtered out by a function, but for no reason it's still there. It has nothing to do with our code and or ruckig lib.

 

Tested these latest adjustments: #884ce9

No apparent errors but motion on the physical machine is not happen as epected.  It seems to rapid to that "zero arc" point which is supposed to be a hole and just stops.



 

 

I have created a new test file from the same dxf file. This one uses the lcnc plasmac PP from sheetcam. Then delete the plasmac specific bits.

This IS WORKING. I am recoding a run with supporting log as I post this. The difference seems to be that circles are done as two arcs. Where as the previous file had circles as a single arc. This was correctky dealt with by the standard tp but was not being handled by the scurve.

Sorry Grotius but I am still not convinced by the zero arc argument. It does not gell with what I am seeing in the gcode or in the way it is interpreted both by linuxcnc gcode plot or other gcode viewers.

Cheers - J.

@Joco,

Sorry Grotius but I am still not convinced by the zero arc argument.
If there is a arc or line with lenght=0. Previously the function returned a "nan", after a source code edit it now returns a "0".
Then as a result no program freezing anymore. It just passes this zero lenght segment.

The cavaliercontours version that cam uses indeed put's out 2 arc segments to create a full circle.
That should not be a problem for the scurve.

Note : If you see a gcode mismatch, please provide the gcode line and or a picture. Then i can figur it out.

@Joco,

You suggest a full circle is the problem for scurve?

Indeed. Stupid..

This is ok, outputs ~157mm.
struct sc_pnt start={0,0,0};
struct sc_pnt way={50,50,0};
struct sc_pnt end={100,0,0};
double l= arc_lenght_c(start,way,end);
printf("arc lenght : %f \n",l);

Then this is fault : It outputs nan, but is a circle.
struct sc_pnt start={0,0,0};
struct sc_pnt way={100,0,0};
struct sc_pnt end={0,0,0};
double l= arc_lenght_c(start,way,end);
printf("arc lenght : %f \n",l);

Ok will fix this.
 

Okay this test run ran for circa 7mins before stopping early.  Attached is video of the run.  It shows the interesting mix of motion. Sharp corners can still ber quite hard while the transitions between arcs can have a relatively long pause.

The program stalls before completion. See log details on

Log file trapped for this run.
 
 
 

New test file based off the sheetcam plasmac PP.  This has circles made of two arcs. Where as the previous test file would have single arc circles.  This was still handled by the standard tp
 

Cheers - J
 

I  don't have the visibility you do of the internals so I am operating from external observation.

The line which was causing the issue is a circle defined by a single arc with the same start and end. Which would seem to be the definition of a circle if represented by a single arc.

This second file I ran used two arcs to define a circle each being 180degs are turn.  This caused the planner no issues.  However the previous definition of a circle did cause it an issue. It could not hanlde that definition.  Yet the standard planner does.

As I said, all based on obersvation of what is feed in and the apprarent behaviour based on those inputs.

Cheers - J.

Note : If you see a gcode mismatch, please provide the gcode line and or a picture. Then i can figur it out.

That was why I gave the link to the gcode viewer for stepping through the gcode file and being able to see the shape rendered and the movemments.  But not problem to provide the pics.  I am pretty sure I quoted the gcode line in question in an earlier post. But no matter.  Happy to add whatever info makes things easier.

Cheers - J.

@Joco,

Now it can cut a circle... Hahaha.
Quite stupid mistake from my side. But ok, we can repair it.

The downsides of this in a nutshell.
If a circle has a centerpoint and the start & end point are the same, the circle is 2d defined, not 3d defined.
The scurve planner uses 3d defined arc's and 3d defined lines for future gcode generation.
So now using a 2d circle is kind of a gcode language paradox problemf for me.

Circle test ok, did just one test and added a circle testfile :

Git is now updated. Will be back monday.

 

Hello.  Have been running some tests as was particulary interested in the "pause" behaviour being observed in certain situations.  I wanted to zero in on that while also doing proof runs.

The pauses seem to be on hard direction changes suach at the edge of a square with a hard 90 degree corner.  There are a few examples of this in the sample gcode file being used for testing.  Isolated down here is the oncentric "squares".
 

However when you look closely at this (loading in either lcnc or in an external gcoder viewer you can see the inner and outter sqaures have "fillets" blending the corners where as the middle square has hard 90 degree corners.  These cause the pauses.

@Grotius - I am guessing that the TP is not doing any kind of blending on these corners and using G64 to generate any intermediate points to soften the change in direction.  The ruckig lib does not seem to do that blending for us.  We ask for postion x,y,z and it gives us the jerk constrained set of points and accerl/vel to get there. If we want some smoothing to happen I presume the TP needs to do that before feeding target states to ruckig.  A bit of a laymans description but hopefully makes some sense.

For anyone interested here is there vido recording the test file being run on real h/w with the plot and halscope up together.  So you can see what is being processed and the halscope values for acceleration and velocoty from the TP. I would suggest sound off and you might end up skipping through bits.  The key is to see the motion/accleration/velocity behaviour on the different shapes.


This is the log file linked to this video run.  Currently I can not run the file more than once.  Tryimg again gets tinker error messages in Axis. I have to stop and restart Axis to get another run to work.
 

Cheers - J.