LinuxCNC S-Curve Accelerations

Hi grandixximo,
Congratulations and big thank you for taking on this long pending task of adding scurve velocity to linuxcnc.
By the mathematics of circular arc blending (used by Rob Ellenberg) in the current linuxcnc planner, there cannot be finite jerk at the transition from a line to a circle or vice-versa. Circular arc blending uses circular arcs to blend the path between two lines or lines and arcs.
To limit jerk at the transition, you need to use a different geometrical primitive than a circular arc.
Grotius has used clothoids and the implementation is available in his clothoid3d library: codeberg.org/skynet/libclothoid3d
Others have used splines. For example opencn uses hermite splines: mecatronyx.gitlab.io/opencnc/opencn/CNC_...tric_Operations.html
Apart from G2/C2 continuity at the junctions, these curves are parameterizable by path length, a property used extensively in the look-ahead optimization.
Once again thank you for taking on this task.
-automata

Thank you for your suggestion automata, we are aware and taking into consideration all known approaches, bi-arc, spline, clothoids, quintic etc...
These are substantial changes which may need a separate branch, or a different planner again planner_type 2 or more.
As of now we are concentrating efforts on fixing the spikes that have been reported, and I've had some success, not ready to share the code yet, probably next week, but I will share a picture of my current results, I've used mainly Rüdiger's code for testing, but also Endian's and Peter's PCW. A special thank you goes to ruediger123 for making the simple rhombus code. I love it because it's very quick to test and shows the blending issues very well. This was the original code what is now in master linuxcnc running the rhombus with G64 p0.25 to accentuate the issue


And this is same code after some blending and cubic improvements, note that YangYang's code sp_scurve itself has not changes a single dot.
 
As I mentioned before the main issues were not in the scurve code itself but in the architecture around it that needed to be tweaked, or possibly be rebuilt ground up, but that's for another time.

As of  now the three big improvements/tweaks are:
1- making a bigger blending arc (still within G64 Pxx tolerance)
2- reduce velocity when blending (inevitable to avoid spikes)
3- limiting how much the cubic interpolation coefficient 'a' can change between segments - the cubic interpolation done after the kinematics was screwing up YangYang's smooth curves

Anyhow next week we are planning on refining and cleaning up the code, YangYang will work on tpOptimizePlannerMotions, I will do testing or real hardware not just scope reads, test latency as well. We may have a PR ready end of next week, but no promises.

I revised the NC program and made the number of corners and the radius parameterizable.

 
 Thats a dodecadon lol
I was planning to make rounded corners actually be radiuses in the gcode G2 G3, probably next week, unless you want to oblige, many thanks again Rüdiger!

NC program.
square with parameterizable size and corner radius.
with G10 L2 R can be rotated around the C axis.
I don't have the knowledge to create an NC program with any number of corners and G2/G3 radiuses

github.com/grandixximo/linuxcnc

For whomever would like to help me test the improvements, download and build, this is not in master yet, still waiting for the halcsope to get merged, I have only tested on the scope so far, will do some testing on real hardware before sending a PR to master.
Would love to have some help testing, thank you all!

still in fixing a few things, don't expect the git history to stay