parametric blending path

I'm new on these section ... my problem is how to create a custom Gcode or <ocall> that use r1-r2-h1-h2 that the parameter values ​​are employees in a proportional way on the speed ... these because I use lcnc on deltarotary and "S" acceleration curve is not avaiable (using limit3 the result is good but not enought) ... so the other strategy is to change the trajectories in order to dampen the structural vibrations ... In the draw is not indicate the selected plain, is because I need 3d direction...

Is possible these whit Gcode or is better to create custom comp to do these?

Regards
Giorgio

is impossible to use spiline G5 or G5.1 because I work in Z plane .... G5 in XY plane ...
Where are locate the G5 code in linuxcnc files? ... I think I can modify it for custom Gcode for have spiline in Z plane .....

Regards
giorgio

Tanks a lot ..... I see 2 day ago araisrobot solution and cnc-club solution (Jerk in Lcnc forum??) ...

cnc-club is referred to std. Lcnc ... solution-by-cnc-club ... but is good base to work for convert NewLinuxcnc/JA with S curve capacity ...

Not find araisrobot, code I see only the scara retrofit on youtube .... so I think the best approach to solve the problem is for first, study jerk solution for delta kins, study the example than if is a solution rewrite cnc-club modification for axes and joint too in new Lcnc ...

I work around G5 modification for now... insert jerk decc and acc in ja it seems a long thing ...

regards
giorgio

github.com/araisrobo/linuxcnc

But I believe it is based on a much older version of Linuxcnc (before the new trajectory planner)

It is a lot of work to integrate it, and probably why it hasn't been done. But if someone were to make it work, I have a few of machines I'd love to try it out on, but for the work we do the new trajectory planner is more important to reducing run-times.

Todd wrote:

It is a lot of work to integrate it, and probably why it hasn't been done. But if someone were to make it work, I have a few of machines I'd love to try it out on, but for the work we do the new trajectory planner is more important to reducing run-times.

I see araisrobot git repository ... but I thought it contained something newer ...
Sorry not understand: "but for the work we do the new trajectory planner is more important to reducing run-times." ... the new trajectory planning is faster then older one or more slow than older?? (I'm sorry it's because my English is not very good...)

Regards
giorgio

The old planner only had 1 line of look ahead, meaning that it would limit velocity to an amount that the machine could come to a complete stop by the end of the next g-code line.

The new planner looks and plans the velocity to follow the path multiple lines ahead, so that the length of the next line segment(s) are not the limiting factor of the machines velocity.

This can make a huge difference in machining time for complex CAM generated code. I have files that the machining time was reduced to 1/3 the time on our machine with the new vs old planner.

ok I understand these .... thank for info ...

Really I note these in complex moving cicle of my robot and in some particular gcode file on my printer ... sometime is impossible make some gcode trick because Lcnc He had to read and execute the last line before performing the magic code ... so the magic code always worked in half .....

I hope these work in complex and long cam-gcode as with my gcode trick ....for example with the old trajectory planning ( what I'm still using it ) if I put a condition with variables from a hal file is impossible that LCNC execute the trajectory in exactly the same way as would perform if the condition were not there (normally these situation perform with G64 ...) .... I think this depends on the fact that the condition inserts a row that is not a trajectory .... from what you say the new trajectory planning should have passed this thing ....

regards
Giorgio