LinuxCNC S-Curve Accelerations

first of testing was 3dchips.ngc and second the 1001.ngc When I removed the base thread ... most of spiking was gone but last spiking ( less then 300us peaks - core duo, less then 200us peaks - i5 C6930-0060, 80us peaks - i7 ) are present during the in the clouds ... but it is more then perfect and extremly usable for everybodyit amazing job for sure !!!

rodw wrote:

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 disagree. Compilers can do great things, but writing code with performance in mind can make a HUGE difference. I haven't looked at this code to know if there's low-hanging fruit here or not. As an illustrative example, I recently got the PeanutGB emulator running on an nRF54L microcontroller. Various low-hanging-fruit optimizations (pulling branches out of loops, handling 16-bit numbers natively instead of as 2x 8 bit integers, etc.) brought that from running at not even full speed to running at 130~150% speed.

There's certainly an argument for writing readable code over the most optimized- the above changes varied from neutral in readability to highly detrimental to readability.

Any loops are a good place to start looking at optimization- pulling out any branches, unrolling them, and/or reducing calculations that are done in the loop. Basically Amdahl's Law- look at optimizing the parts of the code that take the most execution time.

Gentelmen, I am not an expert of C hard code for this big performance irons... I have coding just embedded stuff (day of 8bits stuff) and from this I am little bit bended to optimsing everything over readable coding ... because of lack everything 

therefore it was just my opinion ... I am open to learn new stuff and let my habits behind 

Luca do you think about the look ahead position control? PositionCommand(t+1) as I said before please? For run the ethernet and ethercat servo packs in CSP control? This will change the lagging and cycle ferror during movement...

I have coded my own component which is solving it by it is not accurate during the accellerations change ... 

Hi everyone, I'm 杨阳. I'm currently studying the lookahead optimization code in the motion planner, and we're also exploring some approaches to improve its computational efficiency. If everything goes well, I hope to contribute further optimizations in the future. 

We use CSP control with Ethercat, I can't really envision benefit of sending next next position, instead of just next position.

What do you actually observe on real finished parts? Any actual quality issues? Or is this a theoretical concern based on watching HAL ferror signals?

No there is no error observations at parts because regulator in servo doing its job .. its just cosmetic issue of lcnc which I can see when I am comparing lcnc with fo example NC application from TC3...

It just my hint.. many of user are facing this ferror a its difficult to understand for them that this error is not the bug but the feature... 

I am just highlighting situation and when you are already in gentlemen.. how much difficult is to create pin position-command-bus or something else which will forever solve this observation please? 

Thank you. Your jobs are amazing ! 

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!