@ihavenofish I think there's some confusion here worth clearing up, you're right that filtering (like Tormach does) gives you unpredictable deviation, the path ends up wherever the filters spits out, that's not what we're after.
But I think you're mixing up two different things, how the machine speeds up and slows down is jerk control, whether we cut corners is G61 vs G64, these are separate knobs, if you want perfect path following, use G61, the machine will stop at every corner, follow the exact line, no deviation, with proper S-curve planning it'll do that smoothly instead of jerking around, you get accuracy, you give up speed, fair trade.
G64 P is for when you say "I'm okay with cutting corners by up to this much, just keep moving." That's already how LinuxCNC works today, S-curve doesn't change that, it just makes the motion smoother while respecting whatever tolerance you set.
Why Beziers instead of arcs for blending?
Arcs are a 2D thing. Works fine for XYZ, but what's an "arc" when you've got 9 axes moving at once? It doesn't really make sense.
Beziers are just smooth curves that work in any number of dimensions.Also arcs have constant curvature, so when you enter and exit a blend there's a sudden curvature change, the TP deals with this by speeding up and slowing down, which is why you see velocity bobbing up and down through corners, Beziers can match curvature at the transitions, so you get steadier speed through the blend, And on top of that, arcs need sin/cos every servo cycle while Beziers are just a handful of multiplies and adds, In a tight loop running 1kHz+, that matters. Same tolerance as before, just a better curve to fill it with.
This isn't like the clothoid thing, we're not trying to get fancy with exotic geometry, just trying to get smooth motion that respects whatever path constraints you set, does that make more sense?
Just to be clear, the only reason I'm talking about deviation is because S-curve has to work in all modes, including G64 P where the user has asked for corner blending, s-curve isn't only for G61 exact stop, and there will always be a fallback to trapezoidal via HAL pins, some operations like threading, tapping, and probing need the tighter timing that trapezoidal gives you. You can hook planner_type to an M-code and switch modes in your G-code when needed.
I think that user should take in mind and just select active motion strategy by type of job ... tapping and threading is great to hase at rigid solid trapeziodal thingy ... but probing from my point of view has to be done outside of servo-thread at hardware layer of servo FPGA to get exact position .. no time or cycle lagging present
change in CCS can affect mainly finishing turning paths and there it should be correct by postprocesor itself or user ... during slow finish use trapeziodal or 2. option (solved by hal layer)
filltering as simulations of jerk limiting at servo layer is highway to hell ... during the finishing paths mainly at turning there you will need to increase regulator parameters from the controller to servo driver rather you can forgot at product tolerances
thing must be solved step by step .. phase 1. is really big deal for everybody .. roughing with high speed and low jerk with more laggy tolerance during high mass movement is better ... some jerk during finishing with clear smooth finish at low speed is acceptable for all ... we have regulators for that
I think re-editing the stuff which was coded in oposite of common avaible tp is not a right way ... there we are facing of problem a shiny new stp.c
