LinuxCNC S-Curve Accelerations

It is not a simple change, the look ahead is about velocity not position, it is not something we can easily expose via HAL, it does not exist, we do not have that point ahead of time, we need to calculate it, and you just had us look at performance optimization, this will double the calculations, for cosmetic reason, I don't think you'd want that either.

okay, thanks, I understand... just said my observations ... did you check my gcode yet? 

Yes I just finished testing, and our S-Curve acc tp seems to be computationally better, and spiking less the servo thread compared to the original trapez acc tp, as far as I see, thanks to our work you are getting a better and more computationally efficient TP with planner_type = 1 

Now I'm a bit confused about what spikes you want me to fix, the pictures you sent are of the latency-histogram, which I think you cannot even run when you are running linuxcnc, interpreting gcodes, and actually run our code the new s-curve acc tp, planner_type = 1

I think you might have some misunderstanding of where our S-Curve lives within the LinuxCNC architecture, we only changed the TP which stands for the Trajectory Planner. The Trajectory Planner is not calculating anything when you run latency-histogram, whatever spikes you see in latency-histogram have no connection with the Trajectory Planner, does that clear things up? Or is there something I'm missing? Am I misinterpreting you? Or am I missing something else?

Edit:
On our system I see way more spikes when moving windows around, opening glxgears, or even simply having halscope in view rolling the servo-thread, when halscope is minimized I have way less spikes to 20k compared to when I run either g-code you supplied. There is a catch I can only see that I was having less spikes AFTER I restore halscope in view, and then the spikes start again, making me conclude that the act of checking the spikes with halscope introduces more spikes than anything we are doing with the S-curve or trapez TPs, but I repeat in my testing our S-curve is more computationally efficient than normal trapez TP

I have just posted the latency of my system in the case of checking and searching spikes source... 

Oooo it amazing to find that checking a scope is a source of spiking itself... thank you for briliant observation!

Spikes when you run latency-histogram are caused by the CPU doing other stuff, like checking the network status, reading your mouse and keyboard inputs, display graphical elements, going to sleep because its got nothing to do.
This is not in topic of this discussion about s-curve

Edit:
My test methodology was analytical, I ran same g-code, on same machine, same halscope size, changed the least variables as possible, only planner_type 0 vs planner_type 1
Please in future if anyone wants to bring forth issues about our s-curve implementation, they should use similar testing methodology, during our own internal testing of the S-curve calculations, we also often forgot to do this straight fair comparison, and it sent us on wild goose chases. Mind that we are aware that there are blending issues, this is something that we are working on, but these issues persist in both planner_types. Therefore please try to compare planner_type 0 vs planner_type 1 without changing anything else before bringing forward issues.

I think we are not understanding us now ... I just share latency histogram to just prove my RT and latency free setup(eliminate hardware setup source), not to share pictute of spikes of my latency... I defenetly know that latency histogram and scope are two different things but over histogram we are fast and visible proving our setup of RT... 

here is scope of Intel core duo and AI tells me that Intal core duo has not some hardware instructions which can cause overloading from time to time ... here was most visible spiking 

Edit > yes my testing was doing exactly as you are talking ... first test was 3 phase and the 7phase generator .. 

it was just testing after experience with scurve of grotius where spiking what much greater and creating time lagging during cloud of point movement ... this situation is now not present at all I think, it works really well .. motion is excelent 

great job ! I am amazed.