Trajectory Planner using Ruckig Lib

Hi Joco,

Thanks for your detailled error report.
The gcode file is from cam repository : github.com/grotius-cnc/cam/blob/main/gcode.ngc

I added your modified gcode_test_jw.ngc to the source. And opened the file in axis. Then press run after home,
and error reproduced indeed.

tpAddCircle.
vector size: 6
lengt of this segment: -nan
traject lenght now: -nan
arc startpoint x: 192.000000, y: 162.000000, z: -1.500000
arc endpoint x: 192.000000, y: 162.000000, z: -1.500000
arc center x: 164.000200, y: 162.000000, z: -1.500000

It's obvious, the arc has the same start- & endpoint, wich results in a isnan output for arc lenght in this case.
So i can do 2 things here.

1. Change it into a line when start & end are the same.
2. Filter out this segment, trow it away

So line 21 is:   G03 X192.0000 Y162.0000 I-27.9998 J0.0000 F#<xy_feed>

This essentially a circle.  Use ncviewer.com/ to step through the code file.  Really useful to visualise what is happening where.

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?

Cheers - J

The isnan is fixed by changing isnan to 0 output. So segment's are just there, segment lenght is set to zero.
To inform you where in the source this is done :

github.com/grotius-cnc/linuxcnc/blob/884.../tp/tp_lines.cpp#L89
github.com/grotius-cnc/linuxcnc/blob/884.../tp/tp_arcs.cpp#L233

Github is updated.

Joco, it seems the rapids are below the workpiece. But the file run's oke now.
You may edit the file yourself on github.
 
 

Thanks - yeah its a hack as I can't set WCS to be able to have positive upward Z moves.

Normally Z would be removed on my plasma as that is all under plasmac control.  Once WCS can be set then will change.  OR is it ok to kill off Z moves entirley?  For the purposes of this test file.

J.

@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.