LinuxCNC S-Curve Accelerations

reading this topic with interest to expand what little I know and what I thought about tradjectory planners and why stuff is programmed the way it is plus the evasive S-curve that regularly crops up over the years on various forums and requests for integration.

does it really change the finished part in the hand at the end of the job?

robertspark wrote: does it really change the finished part in the hand at the end of the job?

Yes I believe so. Imagine a plasma cutter cutting at 10.24 m/min with 5 m/sec/sec acceleration (0.5G). It will get to speed in 30 milliseconds.... the inertia results in a massive jerk when it stops and starts and also when it gets to speed and stops accelerating. Oscillations in the cut are inevitable.

For a milling machine at a more leisurely pace, its probably not so much an issue but I have heard of users doing retrofits complaining about jerk on big heavy machining centres...

To bridge the gap until the developers have something. Many good servos already have this function. Example from the Delta manual

It seems to be veri good solution however no sure if this can be sincronized for at least 2 axis.

I was reading this interesting article about bezier curver
www.drdobbs.com/forward-difference-calcu...-of-bezier/184403417

and I think it can be helpfull to solve the maths

I've done some more work on this. I worked through the remaining equations and ended up with something I simply don't know how to solve. I believe it's a cubic equation, but it contains the root of a sum of the squared dependant and other variables:

t2^3 = 1/6*(6*a0^2*j0*t2 - 2*a0^3 + 6*j0^2*s_target - 6*(2*j0^2*t2 - a0*j0)*v0 - 3*(2*j0^2*t2^2 - a0^2 + 2*j0*v0)*sqrt(j0^2*t2^2 - 1/2*a0^2 + j0*v0))/j0^3, where t2 is the variable to solve for.

Anyway, I tired of banging my head against these equations, and decided to try a numerical solution for the remaining cases instead:
Of course a numerical (iterative) solution is not great in a real time system. I benchmarked the code - and got a bit of a shock when it reported ~100 ms for a solution! That's eons of computer time! Then I realised I had a lot of debug printouts. Rmoving them brought it down to ~7 ms. Still way too much. Maybe I should try an optimised build instead of a debug build? That gave another factor 10 improvement - but still too slow. Then I realised that maybe I don't need picometer accuracy *lol*. Changing it to 0.1 µm brought the calculation time down to less than 50 µs on my i5-3470 CPU. Still not great but at least it's in the realm of usability. For comparison, the cases where I have an analytical solution benchmarks at about 2-3 µs.

It should also be possible to optimise the algorithm to converge faster. And I haven't given up hope on an analytical solution, either. Maybe there's help to find at Mathematics Stack Exchange or even the local university, if needs be.

I still have a few test cases unaccounted for, but they should be variants of the ones I already have so should not present any huge difficulties. (One can hope, at least. ) Then it's off to integration with linuxcnc. One positive thing about using a numerical solution is that it doesn't need the cubic solver from the GNU Science Library, which removes the GPLv3 "taint".

Here's the output of the "jlim_complex" test. It's supposed to model jogging with a (course) MPG. It sets the target position to 0.01 m at t = 0.0; 0.02 m at t = 0.1; 0.03 m at t = 0.2, 0.04 m at t = 0.3 and then back to 0.03 m at t = 0.5:

Ohh that one is easy to solve

I more wanted to point at a tool you might want to use.