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.
