LinuxCNC S-Curve Accelerations

I think there is no simple answer now.. but from testing last few days its waaay good to control any hardware and smoothness is uncomparable...

I will share testing gcode in comming days .. but basically I go through all examples in nc_file folder and then my code.. my code will be avaible here

I am now searching the best solution of testing and validation ...there is not space for one lady said..

To prove all main stuff but idea is basicaly simole.. step by step test all avaible G code which I have from real machine but there is some limition of my time 

Btw 杨阳 is mika-net at forum? If am I wrong?
 

Yes, I think he is

Edit:
Don't really have any tricks up my sleeves or anything, YangYang or Mika-net here on the forum coded the S-curve, I did most of the testing, we have not till now found anything better, performance and accuracy wise, it's possible some Algo is out there that is better we just have not come across it.
About the spikes, no idea we run 1ms servo and have not noticed realtime errors, I wasn't looking at servo thread in the scope during testing, I'd like your test codes to compare the spikes, possibly try some optimization, but the current code in the PR is best we got today.

Optimalization of RT code is fundamental but I am not expert of them .. golder standard of industrial grade cycle is 250us(which i am facing from my experiences) therefore from before posted scurve planners I have noticed some lagging even at 2ms which is many times bigger...

I saw that many division like "temp/2" in the code, which divider is constant can be replaced by multiply of 0.5 if it is possible ..same but faster?

I am now optimizing the postprocessor and generating the gcode but I am moving to new house and its little bit tricky now .. i have just one working hardware benchtop example with 2ms scan time which is at limit of the RT.. but i have noticed that lagging at starting/stopping of movement is away .. 

Every native cycle as driling turning I need to check too ...

I don't think it makes sense to manually optimise for execution speed in this day and age. Instead use GCC compiler options -03 or -0fast and possibly native optimisations march=native and possibly mtune=native. This may increase code size and possibly memory usage but I don't see that current hardware has constraints in this area. Gone are the days of massaging code to save every byte to fit in a 64k terminal! I did find using the C ternary operator was more efficient than if-else during that exercise.

I had a brief look at the code and it seemed to be well written and efficient.

In some benchmarking I did some time ago on an i5 with bookworm, the 1ms (1000 ns) servo thread executed in about 200 ns and slept for 800 ns so I don't think you will have issues if the s curve code increases execution time.

Of course it goes without saying the PREMPT_RT kernel needs tuning and that's been hard to articulate even after hours of study. My best effort covered in my recent video which has got jitter down to 6 ns according to one viewer. 


@endian, there is a recent PR from grandixximo on the Ethercat hal driver to sync the servo thread to the Ethercat loop which may help you if committed.  github.com/linuxcnc-ethercat/linuxcnc-ethercat/pull/465
 
 

Thank you Rod.. I think it will help everybody with low latency and ethercat jitter...

What i can tell from my observation... If anybody using CSP driver over ethercat.. position is sending but there is everytime single cycle lag because of no feed forward observer FF1 like during compensation in the PID overc command velocity ...
There will be best if the planner will have allready positionCommand(t) and positionCommand(t+1) for direct position control setup .. this will directly avoid lagging just for this purpose .. do you think about it?

I looked at some optimization routes today, nothing sticks, as rodw said modern compiler do already an excellent job. /2 or *.5 does not matter, the compiler does not actually call the division in assembly, /2 stays for code readability. please first give me a code that I can run, that spikes with our scurve, and does not spike with trapez acc. And then we could seriously look at what operations that we introduced might be spiking the servo-thread, and see if optimization is viable/necessary.