LinuxCNC S-Curve Accelerations

@grandixximo

when I initiate the jerk, you should stick to that.
Does interpolation refer to the movement of the axes or the speed of the calculation?
If the movement of the axes is meant, I can specify a higher jerk.

If I have a stiff machine, I can apply a high jerk and the axles will move smoothly (no overshooting or anything like that). With a soft machine, I have to set a small jerk, otherwise the axles will move erratically (overshooting or anything like that).
Acceleration also plays a role, of course.

If the jerk is maintained, I can adjust the axles properly.
For example, a small jerk and high acceleration.
If the jerk is not maintained, I have to specify a lower acceleration so that the axles run smoothly.

Both need to be taken into consideration, calculation speed and joints movements, will try to cap to max

I still get acceleration violations but the magnitude seems less


 

ini values:

 

I can not upload the file because it exceeds 1.6mb ... I need to upload it over external source www.uschovna.cz/sk/zasilka/UA4I4N3SK2XGF2W6-TNV/

I checked the @ruediger123 codes and there are another spikes in the ramps... 

I've checked all the reported spikes, and the issue is not the new s-curve in itself, but the trajectory planner architecture, we will have to do a much more involved refactoring, will look at Tormach work, maybe talk with Rob if that happens, and take it from there.
The current scurve is best that can be done within the limitations of the current tp architecture.

Can you elaborate on what are these architectural issues?

spiking is present maily during movement at same vector .. when vector of speed is different, spikes are gone

The curent scurve is architecturally limited to works on segments, and the transitions between segments don't respect scurve limits.
We will see if we can improve blending and look ahead to solve this issue.

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.