LinuxCNC S-Curve Accelerations

If filtering is what you call s-curve, that will not take long to implement, but that is practically the same as setting s-curve on your servos, but you have a nice parameter in the gcode which you can tweak. But  mind that jerk filtering WILL change your path, this is as far as I understand just a lazy afterthought patch fix.

Mine and YangYang's approach: "We will deviate from the commanded path by at most P, using this specific mathematical curve."
Tormach's approach: "We will filter the output and try to keep deviation reasonable, probably, mostly."
For you to object to Beziers on path-purity grounds while advocating for Tormach's method is... inconsistent, to put it politely.

grandixximo wrote:

If filtering is what you call s-curve, that will not take long to implement, but that is practically the same as setting s-curve on your servos, but you have a nice parameter in the gcode which you can tweak. But  mind that jerk filtering WILL change your path, this is as far as I understand just a lazy afterthought patch fix.

Mine and YangYang's approach: "We will deviate from the commanded path by at most P, using this specific mathematical curve."
Tormach's approach: "We will filter the output and try to keep deviation reasonable, probably, mostly."
For you to object to Beziers on path-purity grounds while advocating for Tormach's method is... inconsistent, to put it politely.

Sigh.

There should be no deviation. ever. period. If the word deviation comes up, we are not talking about jerk control anymore. 

Option 1, then option 2. Option 2 is mostly useless without Option 1. Filtering doesn't work for me as it is not controlled motion. As you say, we can just soften the servo response for that and we all know that is NOT a good plan.

So it does sound like we need a ground up new TP to actually get anywhere with this. A bit disappointed as this means tormach's implementation was kinda misrepresented to me (not by rob, I never talked to him directly).

That's said, I still feel like this would be great to get implemented anyway, as it might make a bit of a stop gap incremental improvement even if its not the end goal. it would not meet any of the requirements for the lemontart bounty though.

Sleepy time.



 

@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.

grandixximo wrote:

@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 am not mixing up anything. This is literally what I've been saying the whole time. You literally just repeated what I said several posts ago.

S curve DOES NOT HAVE TO WORK IN ALL MODES. This is the point of my "option1" for exact stop as I described earlier (and lead ins and outs of g64 moves). This is the most important jerk control needed in linuxcnc. Option 2 is making it work fully with g64 and is FAR FAR less important. Option 1 is critical, option 2 is... optional. This is why every single jerk control project fails. People jump at option 2 and give up.








 

This is the most important jerk control needed in linuxcnc. Option 2 is making it work fully with g64 and is FAR FAR less important.

I think that this might actually be the point were many would beg to disagree.

Aciera wrote:

This is the most important jerk control needed in linuxcnc. Option 2 is making it work fully with g64 and is FAR FAR less important.


I think that this might actually be point were many would beg to disagree.

And this is a problem.