LinuxCNC S-Curve Accelerations

Interesting. you could probably use it in pncconfs axis test to see it actually work.
Pncconf uses simple_tp.comp for axis tests.

Hi,

Thanks for the tip!.
I just finished and tested a standard implementation of the trajectory component. I feel like a type goat now.

It uses a  trajectory.hal file for input parameters for DoFs axis 0 up to 5.
Then with halcmd i do a : $ setp trajectory_request 1
Then it perform's the traject until it's finished.
User can set all destiny position's before doing the actual trajectory request with
$ setp target_position_0 10.0
$ setp target_position_1 5.0
etc.

Has anyone a better idea how to pass the arguments?

The github is updated.

If you have amd64, you could grab the compiled files from the repository and copy them to the /linuxcnc/rtlib
trajectory.so (linuxcnc component c style)
libtrajectory_6DoFs.so (c to cplusplus style wrapper, compiled as shared library)
libtrajectory_6DoFs.so.1
libtrajectory_6DoFs.so.1.0
libtrajectory_6DoFs.so.1.0.0
libruckig.so (trajectory s-curve c++ library)
If this will not work without header files, then copy the ruckig include headers into the /linuxcnc/include dir.

i'm wondering, any chance that Ruckig OTG can make it into the linuxcnc trajectory planner? in 3-axis trivkins for a start? as i understand currently blending is done with circular arcs and should be reworked?

circular blending and jerk limiting are two similar but different concepts.

circular blending modifies the requested profile to adjust slowdowns/stops at corners. - ie The planner can modify the profile (within defined parameters) to get closer to the requested feedrate, usually on corners. This uses look ahead.
(That's very simple explanation - look for youtube videos in makinekit for better explanation)

jerk limiting allows higher utilization of the speed/power of the motors by having the trajectory planner not ask for impossible moves, suck as instant acceleration.
In general, without jerk limiting you must lower the max acceleration because the TP asks it to change instantly. It would be the same idea if we didn;t have an acceration setting in the TP - we would have to lower the max speed or the machine would tear it's self apart pretty quickly.

of course one could complement the other.

IIRC the guys here are testing jerk limiting on jogging profile which is a different process then profile planning.
Jogging only plans one joint.

This of course is a great idea in it's self and could lead to changes in the trajectory planner for multi axes.

but it's a pretty big jump. There has actually been a couple jerk limiting TP in development for linuxcnc - none of them make it far enough to include.
once you add such things as spindle sync and feed override etc it gets much harder it seems.

The only reason linuxcnc got the circular blending TP is because Tormach paid for it and they helped us get the code to work for us.
I hear they have circular blending with angular axes too now - we don't have that.

There are some smart motivated people here - I'm routing for them!

(I hope I didn't miss-represent anything/anybody here -not a TP expert)

Chris

As i speak for my situation. My interest is most of time the hal related stuff like components.

I hope in the future linuxcnc will be reduced back to a more modular form, for example a component style
gcode reader, motion planner, etc. I simply miss the linuxcnc building block style at the moment. In other words, a ini file
is not needed. Hal files can do it all.

Today i started coding a multi axis motion planner in component style that can read the gcode, can perform the motion etc.
I hope this will bring some luck.

actually they are modular.
The motion component is a hal module - you load it in the HAL file.
The interpreter is modular - there is a sim (axis/canterp) that uses a canonical interpreter rather then gcode interpreter.
the interpreter is set in the INI file, it just defaults to gcode.

Chris