LinuxCNC S-Curve Accelerations

Unless I'm not understanding some fundamental concept, isn't that how it already works?

You can't cheat the actual physics. Any corner 90 degrees or less will require a nearly full stop to achieve the P tolerance. The more acute the angle, the smaller the blend radius you can have to satisfy the P tolerance, and the closer to a full stop the machine has to come.

Put another way, centripetal acceleration, jerk, snap, crackle, etc depend only on velocity and radius. If you want to follow a constant radius at a constant velocity, the acceleration, jerk, etc will be constant. Only their direction changes, not their magnitude.

The only way to reduce jerk in a corner is to reduce the velocity or increase the radius.

An option, which has been discussed earlier, is an "egg" shaped corner radius where the jerk increases to a maximum at the middle. That might be preferable since at the midpoint the jerk force is shared by both axes. You could accomplish roughly the same thing by decelerating before the radius, accelerating toward the midpoint and decelerating again before the exit.

Another option would be to permit higher centripetal jerk than straight line jerk. This would be similar to input shaping used in 3D printers.

I don't see how much can be gained here. Fancy blending algorithms will be too slow to benefit the fast machines they are intended to benefit.

 
I was wrong, on closer inspection the planner can stay within the jerk limit without falling back to a full stop.

It was a bug in the jerk budget split during Bezier blends. Tangential jerk (Ruckig along the path) and centripetal jerk (curvature change through the blend) were budgeted independently, 50% and 100% of the per-joint limit respectively, assuming they're orthogonal. They are in Cartesian space, but not per joint axis, where they add as scalars. For @ruediger123's octagon: 25k + 50k = 75k on a 50k limit, matching the ~47% overshoot in the HALscope trace.

Fix: subtract the tangential share before allocating centripetal. 25k + 25k = 50k, exactly at the limit, no overshoot, no wasted headroom. Corner velocity drops ~20% vs the buggy code, but it's the true physical maximum.

@PCW was right, the TP should always obey constraints. Fix is in the 9d branch.

Edit:
the artifacts at the end of the page.
I'm also looking at what Automata had reported, I think I can improve merging of small segments, I'll put some effort into that


Edit:
I think the previous build maybe have some issue because I merged master without being careful
New build, still working on speed, not ready yet

delete link, this had issues too

I have been experimenting with planner type 1 for a while now with 3-axis milling machine. Generally it seems to work but I'm having problems with g33.1. What is the current state with tp1, should it work when running g33.1? Right now I get error "ruckig_plan_position: invalid limits (v=0.000000, a=3000.000000, j=120000.000000)" at every spindle revolution. In ini file I have nonzero traj(default_linear_velocity, max_linear_velocity), axis' and joints(max_velocity).

EDIT: did more testing. Slowed down spindle speed, looks like the error appears all the time and not only once in revolution. The z-axis velocity seems to be bouncing between 0 to something when the control tries to keep the axis synced, and the tp1 planning breaks every time the speed goes past zero. The other (bigger) problem is when g33.1 is on the bottom and spindle rotation changes, joint2 following error appears.

I solved this temporarily by adding a hal pin to tp which sets true when spindle synchronized motion is on and used that to live change to tp0. With that rigid tapping works just fine although the same z-axis velocity bouncing is present.
 

I know TP2 does not support G33.1 yet, I thought TP1 did but never tested, might have to do some work there, thanks for reporting, will try to patch it up soon

github.com/LinuxCNC/linuxcnc/actions/runs/24246961815?pr=3807

new build has slight speed improvement, still working on it

Found another bug/missing feature in tp1. Hitting feed hold sometimes breaks planning, I guess the remaining length of current segment is too short to calculate using ruckig?
Ruckig planning failed (first attempt),
Back to tp 0
feed_override: 0.330000
max_vel: 132.000000
cpos: 380.077500, tpos:
380.133525, dx: 0.056025
cvel: 33.000000, tvel: 132.000000
cacc: 3000.000000
maxa: 3000.000000, maxj: 120000.000000