LinuxCNC S-Curve Accelerations

Jerk limiting should in no way affect the path. Ever.

g64 smoothing should ideally be decoupled from jerk limiting - it functionally has a built in jerk limiting as it is.

Acceptable choices are:

1: NOT use jerk limiting on smoothed line to line transitions - only jerk limit the start and end and any breaks in smoothing (acute angles etc), and then all exact stop moves. This will make motion smooth in almost all critical cases.

2: Create a new constant velocity planner with jerk limited smoothing strategies.

Option 2 is where jerk limiting goes to die in linuxcnc. I would focus on option one and making it 100% fully stable - you seem to have a good proof of concept started, but still have a ways to go. I would not get side tracked by trying to reinvent what already works quite well.

I think he is right, I tend for option 1 as well, actually already have it work pretty well in my testing.
Option 2 which is what the big boys use, Siemens Fanuc etc. as far as we understand, requires a complete TP rewrite

Slow down at curvature changes: reduce Vel so the centripetal acceleration change is manageable. (this defeats high-speed machining)

This is what I mean is feasible, not ideal, but what we are working with that moment.

YangYang I think tends toward Béziers and smooth High Speed, but this changes toolpath, I'd rather slow down when necessary to make things smooth, and stay on path, which is generally more important than High Speed in our line of work.
I think slowing down on arcs is simpler to implement, Béziers complicate things, and I think, we will still need to slow down or at least calculate the proper speed to execute and stitch in the blend smooth Béziers at, which could prove to be a headache in my opinion, even though the path is smooth doesn't mean you can run tangential speed jerk control and get rid of jerk spikes, I don't think it works like that, but I'd be glad to be proven wrong, but still you would not be following a programmed arc and I don't like that...

You cannot maintain velocity, follow the exact programmed path, AND have smooth jerk.

This is physically impossible. What I am saying is I would sacrifice velocity rather than programmed path on G2/G3 programmed arcs. At the moment if you run something with tangent arcs even with G61 the velocity is kept, this messes with jerk. G61 with jerk will have to slow down more.
For many line segments G64 Pxx it also slow down more, the more tight the tolerance, the smaller blending arcs the slower you have to move.
Béziers will give you better speed, because you can run them faster, but they are NOT arcs, meaning when you program a square for example, just 4 lines, you set G64 to 0.5 let's say, what kind of path error would you accept? A 0.5mm perfect radius which I have to slow down more to make smooth, or a squashed up Béziers which I can run faster?

Hello,

Just for fun i also created a Polygon program where you can change direction (G2/G3), position, number of point/rounds and the corner radius.

For what option is chosen, doesn't the user choose with P-parameter of G64, how much the controller can deviate from the programmed points? Also by option 1, and acute angles should there be a user option to tell what is acute.

(long time reader, trying to do something back to the community, keep up the good work!)

I'm not expert too, I've just been experimenting with AI and looking at the halscope, trying to wrap my head around things in general, it helps to just chat about these things, even just to make sure I'm not persuing a weird irrational tangent, and I'm actually making sense not just to myself lol. YangYang has the math down, he is the main arbitror, nothing goes to master without his stamp of approval, and he checks on what the AI comes up with, and so far nothing really sticks, only what he write himself works best. I've found something with the arcs, I want him to take a look, and I think we maybe possibly be able to do similar tricks with Béziers, but I don't want to keep your hopes up, I think it is possible that, the fact that Béziers change curvature, may not fit with the current tp lokahead/blending architecture, but maybe... maybe I am wrong.

I thought jerk limiting was purely about acceleration. To extend it to varying the path seems to me is really scope creep. Get it working without changing the path and include path optimisations at a future time and write better gcode for now.

jerk limiting may permit higher maximum acceleration. Currently MAX_ACELERATION is set from a combination of motor dynamics and physics by the machine builder Eg the inertia in a heavy moving table may require a lower acceleration than what the motors are capable of so they are not overcome by inertia on deceleration and cause following errors. Its probably valid on a jerk limited machine to increase acceleration. In this context, some violations may be valid.