Trajectory Planner using Ruckig Lib

No idea how hard any of those are to implement so i might be shooting from the hip here, but i would leave gcode as is.

Hi Tommy,

For the planner this arc is a motion to be fullfilled. image missing /media/kunena/emoticons/laughing.png

The arc has it's own scurve motion from arc start to vm to arc end.
Then the toolpath must follow the arc. This is done by creating a arc segment, like creating a g1,g2,g0 etc.
Then the segment is interpolated how far the scurve motion is.

We can leave the original gcode as is. No problem for that.

In extreme conditions, like G64P25 this should result in big fillets. This can cause the cavaliercontour to skip gcode content,
because they are simply teared away by the cavalier algo.

So i have to come up with a solution.... image missing /media/kunena/emoticons/whistling.png
In the mean time i am listening music trough just cloned youtube-dl. Modified the makefile, it uses python zero there. image missing /media/kunena/emoticons/ermm.png






 

Well, you could add a gcode filter that modified the gcode to insert an arc when the file is opened
Plasma configs Qtplasmac and more notably Monokrom both use filters. Monokrom arguably has  a more sophisticated filter that replaces holes with some "high def" hole cutting features. It does this by replacing any circles in the gcode with its own code with several segments to alter velocity

@Hi Rod,
Yes we can add gcode. We leave the gcode structure intact as is. But add extra info to it.

Will add a Head & Tail to each gcode segment. This are half segments that are tangent to each other.
The Head will get info about it's next gcode segment. Some may be filtered out by the cavalier algo.
This then will solve missing gcode lines when users decide to use G64P100

The cavalier algo is made fertig for 3d operations. image missing /media/kunena/emoticons/cool.png
Testing 2 lines in a 3d position :

    cavline l0;
    l0.p0={0,0,0};
    l0.p1={50,50,50};
    l0.bulge=0;

    cavline l1;
    l1.p0={50,50,50};
    l1.p1={100,0,0};
    l1.bulge=0;

Then we create a plane from the given line points. We translate & rotate the line content to topview xy zero.
Then we do the cavaliercontour algo.
Then we translate & rotate the results back to original plane. This far better then any other fillet algo.

 

Looks awesome Grotius

I'm also following this closely

I have a 22 ton 5axis machine I would love to see this working on

It has rapids of 40m per min so very fast and heavy. Would be a good torture test of your scurve code

It's not enough for an arc to be tangent to a line or to another arc. They have to be curvature continuous. When a line meets an arc on its tangent, the curvature goes from zero to 1/r immediately, where r is the radius of the arc. The radial acceleration goes from zero on the line, to v^2/r instantly where they meet. That means infinite jerk or at least very high jerk in real life. The same is true for arcs with differing radii that are tangent.

The only way to limit jerk is either to slow down to zero velocity where they meet, or join them with a type of curve with a curvature that smoothly varies between the two.

The problem is basically this: en.wikipedia.org/wiki/Track_transition_curve