LinuxCNC S-Curve Accelerations
02 Feb 2023 22:50 #263551
by dgarrett
Replied by dgarrett on topic LinuxCNC S-Curve Accelerations
Below is an example (master branch) demonstrating how to
convert the provided skeleton tpcomp.comp to a custom
trajectory planning module named 'trytp':
convert the provided skeleton tpcomp.comp to a custom
trajectory planning module named 'trytp':
$ # read tpcomp instructions:
$ man tpcomp
$ ...
$
$ # begin example by making and using a temporary directory:
$ mkdir /tmp/try
$
$ # copy the skeleton tpcomp.comp from your git repository
$ # to /tmp/try:
$ cp /home/dgarrett/src/hal/components/tpcomp.comp /tmp/try
$ cd /tmp/try
$
$ # follow best practice instructions to rename to trytp.comp
$ cp tpcomp.comp trytp.comp
$
$ # edit per instructions (use editor of your choice):
$ gvim trytp.comp
$
$ # note edits made for the 1)component name and 2) TOPDIR:
$ diff trytp.comp tpcomp.comp
1c1
< component trytp"Trajectory Planning (tp) module skeleton";
---
> component tpcomp"Trajectory Planning (tp) module skeleton";
49c49
< #define TOPDIR /home/dgarrett/linuxcnc-dev
---
> //#define TOPDIR /home/myname/linuxcnc-dev
$ # for this test TOPDIR points to an unmodified git tree
$ # so it will build a 'trytp' module that uses the exact
$ # code of the default tpmod
$
$ # compile and install:
$ halcompile --install trytp.comp
Compiling realtime trytp.c
Linking trytp.so
cp trytp.so /home/git/linuxcnc-dev/rtlib/
$
$
$ # test existence of trytp module using halrun:
$ halrun
halcmd: loadrt trytp
Note: Using POSIX realtime
@@@trytp.comp:extra_setup: tp_parms=no_tp_parms
@@@trytp.comp: TOPDIR=/home/dgarrett/linuxcnc-dev
...
$
$ # test usage of trytp in a sim config:
$ cd /home/dgarrett/linuxcnc-dev/configs/sim/axis/
$
$ # query linuxcnc script options:
$ linuxcnc -h
linuxcnc: Run LinuxCNC
...
Options:
...
-t "tpmodulename [parameters]"
specify custom trajectory_planning_module
overrides optional INI setting [TRAJ]TPMOD
...
$
$ # try running a sim config using -t option :
$ linuxcnc -t trytp axis.ini
LINUXCNC - 2.10.0~pre0
Machine configuration directory is '/home/dgarrett/configs/sim/axis'
Machine configuration file is 'axis.ini'
Starting LinuxCNC...
...
linuxcnc TPMOD=trytp HOMEMOD=homemod EMCMOT=motmod
^^^^^^^^^^^
^^^^^^^^^^^
Note: Using POSIX realtime
@@@trytp.comp:extra_setup: tp_parms=no_tp_parms
@@@trytp.comp: TOPDIR=/home/dgarrett/linuxcnc-dev
...
... test
$ # After the above test works, one can then replace any of the files
$ # specified by USE_TOPDIR with custom files that implement a custom
$ # trajectory planner being sure to include all trajectory
$ # planning api functions.
Please Log in or Create an account to join the conversation.
04 Feb 2023 11:18 #263661
by andypugh
forum.linuxcnc.org/38-general-linuxcnc-q...time?start=10#263611
Replied by andypugh on topic LinuxCNC S-Curve Accelerations
Just to further muddy the waters, this could change in the future.> The Linuxcnc motion planner does not operate in real time.
This is incorrect and misleading -- likely
conflating the interpreter's processing of gcode
program commands with the trajectory planner's
processing of canonical commands.
forum.linuxcnc.org/38-general-linuxcnc-q...time?start=10#263611
Please Log in or Create an account to join the conversation.
12 Feb 2023 20:13 #264379
by Grotius
Replied by Grotius on topic LinuxCNC S-Curve Accelerations
Hi,
A little update so far.
1. The bottle-neck still is a interupt like a velocity change during runtime.
The science paper i use is calculating the jerk max value for each curve.
This makes the scurve's for a vm change a very difficult job.
So i looked at ruckig motion lib today and made a program.
The ruckig version i use still has a bug for velocity end > 0 values. Maybe i have to look again if this is solved with
a newer version. For calculating waypoints with Ruckig, u have to buy the pro version.
I have never used a cubic-spline algo that can do the vel,acc and pos. So at the moment i don't know how to start with this.
But this can be a solution to investegate.
At the moment i am writing curve functions that uses a fixed jm value. Let's see how far we can get.
A little update so far.
1. The bottle-neck still is a interupt like a velocity change during runtime.
The science paper i use is calculating the jerk max value for each curve.
This makes the scurve's for a vm change a very difficult job.
So i looked at ruckig motion lib today and made a program.
The ruckig version i use still has a bug for velocity end > 0 values. Maybe i have to look again if this is solved with
a newer version. For calculating waypoints with Ruckig, u have to buy the pro version.
I have never used a cubic-spline algo that can do the vel,acc and pos. So at the moment i don't know how to start with this.
But this can be a solution to investegate.
At the moment i am writing curve functions that uses a fixed jm value. Let's see how far we can get.
The following user(s) said Thank You: wellingtoncsouza, Darium
Please Log in or Create an account to join the conversation.
16 Feb 2023 22:19 #264661
by Grotius
Replied by Grotius on topic LinuxCNC S-Curve Accelerations
Hi,
Another update today. Actually i have good news.
I suspsect within a week or 2 the library is ready. Need a few intensive day's coding to finish this.
I made extra scurve formula's from the science paper base formula's. And i was able to master
some of the formula's to stitch different curves together at different times etc.
You can check this "scurve magic" in the "source" link below.
Ok, so far i think this can be a excellent lib when finished.
Then we can look at the examples given by
Mr. Garret and try to integrate this code into a linux cnc axis application.
Some info about the library and the extra formula's :
1. The extra formula's prevent curve mirroring, and make a forward time calculation easy.
2. For every acc- dcc- concave- convex curve a custom formula can be used.
3. The library is using curve periods : t1,t2,t3,t4,t5,t6,t7,
4. It uses a consant "jm" jerk max value. Machine movement can be predicted as contant, stable.
5. It uses linear acc,dcc periods t2, t6. (Ruckig can not do this with a cubic spline algo)
6. Motions may start with a "vo" velocity start, "acs" acceleration start.
7. Motions may end with a "ve" velocity end, "ace" acceleration end.
8. The library can build any curve combination, for example a curve down, then up : t7,t1,t2,t3 etc.
In the science paper these additional formula's are not shown.
Later on when the library is ready, i problably will make a new science paper
with the extra formula's etc to make this work complete.
formula cheet sheet
header
source
Another update today. Actually i have good news.
I suspsect within a week or 2 the library is ready. Need a few intensive day's coding to finish this.
I made extra scurve formula's from the science paper base formula's. And i was able to master
some of the formula's to stitch different curves together at different times etc.
You can check this "scurve magic" in the "source" link below.
Ok, so far i think this can be a excellent lib when finished.
Then we can look at the examples given by
Mr. Garret and try to integrate this code into a linux cnc axis application.
Some info about the library and the extra formula's :
1. The extra formula's prevent curve mirroring, and make a forward time calculation easy.
2. For every acc- dcc- concave- convex curve a custom formula can be used.
3. The library is using curve periods : t1,t2,t3,t4,t5,t6,t7,
4. It uses a consant "jm" jerk max value. Machine movement can be predicted as contant, stable.
5. It uses linear acc,dcc periods t2, t6. (Ruckig can not do this with a cubic spline algo)
6. Motions may start with a "vo" velocity start, "acs" acceleration start.
7. Motions may end with a "ve" velocity end, "ace" acceleration end.
8. The library can build any curve combination, for example a curve down, then up : t7,t1,t2,t3 etc.
In the science paper these additional formula's are not shown.
Later on when the library is ready, i problably will make a new science paper
with the extra formula's etc to make this work complete.
formula cheet sheet
header
source
Please Log in or Create an account to join the conversation.
17 Feb 2023 23:17 - 17 Feb 2023 23:24 #264725
by Grotius
Replied by Grotius on topic LinuxCNC S-Curve Accelerations
Hi again,
Good news again. The basics of the curve lib works. I mean it can be used
to interpolate motion. The curve engine is working.
If you are interested in testing it, just clone the dump dir on github, and run it in qt.
Tomorrow i take one day off.
Then i will polish the code and will make a c interface for it to use with lcnc.
For info :
In some scenario's the lib uses a stitch. A stitch is a tiny bridge defined as t2,t4 or t6 to get a
absolute s output. For example, if ve can not be reached,, a stitch is applied to the curve builder engine.
This exotic motion starts with negative acc, goes to vm, ends at ve with end dcc.
If you have any comments, go ahead.
github.com/grotius-cnc/dump/
github.com/grotius-cnc/dump/blob/main/screen1.jpg
Good news again. The basics of the curve lib works. I mean it can be used
to interpolate motion. The curve engine is working.
If you are interested in testing it, just clone the dump dir on github, and run it in qt.
Tomorrow i take one day off.
Then i will polish the code and will make a c interface for it to use with lcnc.
For info :
In some scenario's the lib uses a stitch. A stitch is a tiny bridge defined as t2,t4 or t6 to get a
absolute s output. For example, if ve can not be reached,, a stitch is applied to the curve builder engine.
This exotic motion starts with negative acc, goes to vm, ends at ve with end dcc.
If you have any comments, go ahead.
github.com/grotius-cnc/dump/
github.com/grotius-cnc/dump/blob/main/screen1.jpg
Last edit: 17 Feb 2023 23:24 by Grotius.
The following user(s) said Thank You: itsme
Please Log in or Create an account to join the conversation.
19 Feb 2023 20:49 #264829
by Grotius
Replied by Grotius on topic LinuxCNC S-Curve Accelerations
Hi,
A little update.
I tested the scurve lib performance in the mean time with the chrono high resulotion clock.
The picture of the scurve i tested : the scurve
The test was based on a 9 axis machine.
The curve is quite a standard curve, but is one of the types to be sampled down for "vm" to fit "s".
So the test is 9 times the scurve calculation. This then should fit into the servo cycle of 1ms, say 0.6 ms is ok to not
overload other lcnc stuff wich is also in the servo cycle.
The output was not so good.
The recorded peak : 4.6 milli seconds.
Ok. What to do?
I could create fast functions as : github.com/grotius-cnc/dump/blob/main/sc.cpp line 37.
To solve the problem, but much work...
I can remember Ruckig goes oke up to 3 dofs synchronized within 1ms.
But we need at least 9 axis to go.
For the rest i repaired a few tiny bug's. And programmed the curve combinations.
So far so good, but we need to do something to improve the performance.
A little update.
I tested the scurve lib performance in the mean time with the chrono high resulotion clock.
The picture of the scurve i tested : the scurve
The test was based on a 9 axis machine.
The curve is quite a standard curve, but is one of the types to be sampled down for "vm" to fit "s".
So the test is 9 times the scurve calculation. This then should fit into the servo cycle of 1ms, say 0.6 ms is ok to not
overload other lcnc stuff wich is also in the servo cycle.
The output was not so good.
The recorded peak : 4.6 milli seconds.
Ok. What to do?
I could create fast functions as : github.com/grotius-cnc/dump/blob/main/sc.cpp line 37.
To solve the problem, but much work...
I can remember Ruckig goes oke up to 3 dofs synchronized within 1ms.
But we need at least 9 axis to go.
For the rest i repaired a few tiny bug's. And programmed the curve combinations.
So far so good, but we need to do something to improve the performance.
The following user(s) said Thank You: tommylight, Darium
Please Log in or Create an account to join the conversation.
19 Feb 2023 22:40 - 19 Feb 2023 22:42 #264835
by Grotius
Replied by Grotius on topic LinuxCNC S-Curve Accelerations
Hi,
After some testing try to improve just one function, it helped a little bit, this are netto times :
step 1, local vars : function time:0.001308 ms
step 2, using inline : function time:0.001219 ms
step 3, removing jm,as calculation : function time:0.001027 ms
step 4, using std::min : function time:0.001704 ms <= only increased the time.
Then the 9 axis test was improved from 4.6 to 2.8 ms. I think this is just only from adding "inline" in
front of functions who are repeatedly used.
Tomorrow i will make some work to split up functions into fast functions to reduce the cycle time.
I have no other option left.
After some testing try to improve just one function, it helped a little bit, this are netto times :
step 1, local vars : function time:0.001308 ms
step 2, using inline : function time:0.001219 ms
step 3, removing jm,as calculation : function time:0.001027 ms
step 4, using std::min : function time:0.001704 ms <= only increased the time.
Then the 9 axis test was improved from 4.6 to 2.8 ms. I think this is just only from adding "inline" in
front of functions who are repeatedly used.
Tomorrow i will make some work to split up functions into fast functions to reduce the cycle time.
I have no other option left.
Last edit: 19 Feb 2023 22:42 by Grotius. Reason: editor meshed up.
The following user(s) said Thank You: Bari
Please Log in or Create an account to join the conversation.
19 Feb 2023 23:40 #264839
by rodw
Replied by rodw on topic LinuxCNC S-Curve Accelerations
If your error reporting is called repeatedly to print messages, replace the text with Error #defines or enums as printing is very resource intensive (eg time consuming).
Linuxcnc has a function called rtapi_print (or similar) which may help. I'm not actually sure how it works.
PREEMPT_RT has some recent patches to allow the linux kernel print statements to be queued and print when possible. I wonder if you could borrow the kernel printk() statement?
Be sure to share your code in git so otheres can review and help.
Linuxcnc has a function called rtapi_print (or similar) which may help. I'm not actually sure how it works.
PREEMPT_RT has some recent patches to allow the linux kernel print statements to be queued and print when possible. I wonder if you could borrow the kernel printk() statement?
Be sure to share your code in git so otheres can review and help.
The following user(s) said Thank You: Grotius
Please Log in or Create an account to join the conversation.
20 Feb 2023 21:06 #264902
by robh
Replied by robh on topic LinuxCNC S-Curve Accelerations
just want to say thank you for taking the time and effort into this topic and i hope you do resolve, jerk limiting for us guys running bigger faster machines would be a night and day change for sure to linuxcnc. will keep watching this space
Please Log in or Create an account to join the conversation.
20 Feb 2023 22:27 #264911
by Grotius
Replied by Grotius on topic LinuxCNC S-Curve Accelerations
Hi,
A little update.
jerk limiting for us guys running bigger faster machines would be a night and day change for sure to linuxcnc.
Yes. For all of us. This is a game changer, when integrated.
I think we where lucky today. I programmed for 10 hours, with some succes.
Not all the functions are optimized now, but i optimized those so i could do a another test.
Now i reached a peak time of : 0.49 ms on a 9 axis scurve thread.
Now i reached a peak time of : 0.73 ms on a 16 axis scurve thread.
This is done with a curve with periods : t1,t2,t3,t5,t6,t7 without "vm" sampling.
I hope the final performance will stay like above.... We will see.
@ Rod,
During the performance test, no print output is done. This will slow down the process a lot.
For hal components we use indeed the rtapi print, no problem for that.
I am now working a little bit on the front end.
User interface is like the ruckig lib. The ruckig update cycle is quite clever, so i use that too, and
i will explain a little what i mean by a clever update cycle :
Not clever way:
1. The program can calculate a scurve for a motion, given vo,vm,ve, etc. Then user will request a time point on the curve
and program will do a interpolation on that given time point. So curve is calculated from begin to end.
Clever, ruckig way :
2. The program calculates a curve from current pos,acc,vel up to the endpoint for every request.
The program then gives a new waypoint for next 1ms. Then the new waypoint is as input again.
A little update.
jerk limiting for us guys running bigger faster machines would be a night and day change for sure to linuxcnc.
Yes. For all of us. This is a game changer, when integrated.
I think we where lucky today. I programmed for 10 hours, with some succes.
Not all the functions are optimized now, but i optimized those so i could do a another test.
Now i reached a peak time of : 0.49 ms on a 9 axis scurve thread.
Now i reached a peak time of : 0.73 ms on a 16 axis scurve thread.
This is done with a curve with periods : t1,t2,t3,t5,t6,t7 without "vm" sampling.
I hope the final performance will stay like above.... We will see.
@ Rod,
During the performance test, no print output is done. This will slow down the process a lot.
For hal components we use indeed the rtapi print, no problem for that.
I am now working a little bit on the front end.
User interface is like the ruckig lib. The ruckig update cycle is quite clever, so i use that too, and
i will explain a little what i mean by a clever update cycle :
Not clever way:
1. The program can calculate a scurve for a motion, given vo,vm,ve, etc. Then user will request a time point on the curve
and program will do a interpolation on that given time point. So curve is calculated from begin to end.
Clever, ruckig way :
2. The program calculates a curve from current pos,acc,vel up to the endpoint for every request.
The program then gives a new waypoint for next 1ms. Then the new waypoint is as input again.
Please Log in or Create an account to join the conversation.
Time to create page: 0.241 seconds