Trajectory Planner using Ruckig Lib

yes, it is a spiral in the corresponding plane (g17 for Z)

Linuxcnc is also able to draw multiturn spirals
G2 or G3 <X- Y- Z- I- J- P-> where P is the number of turns

Full circle or spiral programming is possible without axis words 
G2 Z- I- J- P-

@Hmnijp,

Thanks for confirming.

Hi,

The helix, or spirals are working now for 3 planes. G17 xy-plane, G18 xz-plane, G19 yz-plane.
They use G2 or G3 for helix direction.

I started using opencascade to create a cilinder surface, and then combine it with a line on that surface,
there was a example, it all turned out to nothing as i need to start at a given point, need to end at a given point,
add extra turns if requested etc.

So ended up starting to write functions plane by plane, as i find the yz-plane the most difficult to code.
And i also seperated G2 and G3 functions to keep it simple.

And as Hmnijp mentioned in his post, it can use the P word for nr of turns.
This nr of turns is tested in the lcnc 3d example ngc file:
 
 

And then the gcode file of robh, the helix is also color red:
 

Ok, this looks ok for now.

Helix source file creating a spiral, helix : creating a G2 helix
My conclusion is : Helix start, endpoints are impossible to use for a 2d tri-clothoid fillet to get G2 continuity.
The only way to get the G2 continuity fillet for a helix is to modify the helix spring curvature into a tri-clothoid curvature.

So the spring of the helix will have the model of a tri-clothoid. Is this usefull?

 

Hi,

Now i added a helix G2 continuity test function.

Instead of drawing a helix in a plane, we add something special.
It's a G2 helix (clockwise arc), 2 gcode lines are attached. You can see what happens in both situations.

So it starts the helix with zero curvature (k value) in the spring axis, in this case top view xy plane G17.
Then along the path it uses a cos function to increase the curvature along the path.
Then at the end it comes down to zero curvature.

So now this spiral, or helix has G2 continuity and can be used to create fillets with a tri-clothoid.

 

I think for spiral we can use the gcode L word to enable G2 continuity mode like :

G2 P2 I0.5 J0.5 Z1 L1

P= turns
L= enable G2 continuity for spirals

Kudos Grotius!
Maybe the L1 can be made as a G64 parameter and the default value set at startup like the G64 P and Q parameters. 

Another option would be to set it up as an ini parameter. 

Will the clothoid interpolation work for 9 axis G1 moves?

Regards
automata

​

@Automata,

Yes, G64 P.. Q.. L..

Will the clothoid interpolation work for 9 axis G1 moves?
It is going to work, but we need someone who makes a tiny document how the rules are to achieve this.

I mean, i will code it following the document guide lines, coding steps.

So the document needs a few steps, what are the rules for interpolation on 9 axis. Wich axis first, when what
to do and so on.

Maybe you can make the document and think about it extensively.

Here are the results of a helix not doing a G2 continuity, G2 ... L0
Clearly you see sharp transition corner in yellow, this is bad for machine :
 

And a helix doing G2 continuity in the testfile of Robh,   G2 ... L1:
Yellow is transition from helix to helix. Red and purple, no transition corners visible.
Path is better for machine.

 

We Are about to do a big aluminium 4axis carving and the current trajectory generator swaps to no look ahead when it combines 4axis motion with 3axis motion I think. Which is a problem


I think tormach has fixed that.

Does anyone know what the current limit is and can it be fixed easy?


Just been looking at the wonderful work Grotius is doing and wondering if this is possible to fix atb the same time..
Regards

Andrew

Hi Becksvill,

I know someone else who hass the same problem with a huge 3d printer in Italy. He was asking me the same thing.

So in the current tp from Rob Ellenberg we have to change logic to enable this 4 axis look ahead?
 

Will have a look at that next week in the original trajectory planner.

Yesterday i did some work at the gui interface.

Today i made a MILLTASK component for halcore that i named "state_machine.so"
This component will do the program logic like start, stop, pause etc.  and also handles the jogging & trajectory stuff.

The state_machine.so component is using shared memory to load the gcode data from userspace.
All is done in  c++ code.
So for uploading gcode to the hal side, no hal pins are required. It just's sends the data_structure containing the gcode
information to the kernel module. It's using a mutex.

This is showing the cnc app, after loading the gcode drawing, it sends the gcode_data to hal side.
Then in the component itself it prints the ammount of gcode lines as a test : testing if component has gcode lines recieved.

Ok now this framework works and is quite compact.

At the left it prints the ammount of recieved gcode lines. This print is done by the hal component : state_machine.so