LinuxCNC S-Curve Accelerations

Probably need to talk to Rob the programmer of the read ahead. The problem is the code familiarity required, to same nothing of knowing how to program S code.

It would be so nice though.

I've thought adding s curve to jogging would be a nice step too.

Jerk-limited motion is interesting, and I've played around a bit with generating such paths. (Lots missing before they could be called "tool paths", rather just experimental stuff to understand how jerk-limited motion behaves.) Here's an example of a short move, starting in the lower left accelerating right, turning upwards using a constant jerk vector aimed at 10.30 o'clock, then turning left using two clothoid segments before decelerating:



The original poster mentioned a slight following error:

grandixximo wrote:

Is it possible with LinuxCNC to set an S-Curve acceleration that does not effect motion blending?

S-Curve type acceleration has a much smother movement, way less jerky, but i've noticed a slight following error in some situations if it's set on the axis drives, so i was wondering if there is a way to set it directly from LinuxCNC, and if it would be any more precise, if there is not currently, are there plans for future versions?

The thing is, as far as I can see it is physically impossible to describe jerk-limited arcs exactly using g-code. The resulting arcs will always have a smaller radius than nominal, because transitioning from an un-accelerated line to a circular arc (with its inherent constant centripetal acceleration) cannot be done instantly - limiting that jerk is of course the whole idea. This transition takes time, and non-circular motion (away from the direction of the line). So when circular motion is reached, we cannot have both the center of motion and the radius we wanted.

I think accepting this, and figuring out an acceptable way of handling it, is a big part of the difficulty in creating a jerk-limited trajectory planner.

One way I can see is specifying a tolerance on the radius and then letting the planner reduce feedrate into the arc, if necessary, so that it can be met without violating the jerk limit. What do you think?

The old trajectory planner with it's parabolic blending was almost jerk limiting. Perhaps if someone could figure out how to apply its methods of blending to the jerk limiting problem.

Todd, was that a reply to my post? If so, you should know that regardless of algorithm, any jerk limiting (anything less that infinite jerk) means that all radiuses will be somewhat smaller than programmed. You cannot change radius of curvature with less than infinite jerk without also moving the center of curvature.

Look at the (exaggerated) figure in the Wikipedia article on clothoids, under Formulation :

The circle is offset from the line (not tangent to the line). In contrast, all arcs programmed in g code are tangent to the previous/next straight line. You will get this discrepancy with any kind of jerk limiting.

Maybe a good order of priority would be as follows:

1) Keep within the arc radius tolerance given (tolerance = 0.0 would mean no jerk limit).
2) Keep up feedrate while honoring max acceleration value through arc (limited by centripetal acceleration).
3) Minimize jerk as much as possible given the two earlier conditions (down to some configurable goal jerk magnitude). This pretty much means aiming for maximum deviation from nominal arc radius (within the tolerance in 1).

Wouldn't a jerk limit aware TP simply slow down enough to limit the error to the
preset tolerance (as it does now for "infinite" jerk motion)

Remember you always have this error to some degree since its not physically
possible to have infinite jerk.

That is the question. Slowing down is certainly one way to handle it. Another is to prioritize feed rate and allow higher jerk where necessary.

There are three goals here that cannot be satisfied simultaneously: shape, feedrate and jerk limit. (And of course acceleration limits feedrate through arcs as well.)

If the user selects a jerk-limited TP, that means (s)he wants to trade some positional accuracy for "less than infinite" jerk. (As you say, some of this tradeoff is forced anyway due to the reality of physics.) I'm suggesting the choice should be made explicit by having an "arc tolerance" setting.

That takes care of the shape-vs-jerk issue. Then we have feedrate vs jerk: to keep within the specified arc tolerance we could limit feedrate and/or be flexible on the amount of jerk allowed. How to make that choice?

I'm suggesting a "jerk minimizing" strategy that prioritizes feedrate over a hard jerk limit: keep feedrate up and use the specified arc tolerance to minimize jerk as much as possible, but without a limit. If the curvature and feedrate are low enough to allow lower jerk than the configured "goal" value, then use the configured "goal" value and be a bit more accurate on shape, instead.

Tangential jerk (when accelerating along the toolpath) would always use the configured jerk value. The "no hard limit" would only apply for radial jerk. For line-to-line blending we already have the G64 setting, but I don't think users would accept that much error on programmed arc radiuses?

Of course, I'm not sure how feasible this is to implement. I'm just mulling over the user experience side of things: what's the optimal way to handle this within the laws of physics?

If the user selects a jerk-limited TP, that means (s)he wants to trade some positional accuracy for "less than infinite" jerk. (As you say, some of this tradeoff is forced anyway due to the reality of physics.) I'm suggesting the choice should be made explicit by having an "arc tolerance" setting.

Not necessarily, it may mean they want to allow the TP to vary the feedrate to keep from exceeding
physical machine limits and tolerances. A infinite jerk TP _always_ exceeds physical limits,
which causes following errors. In fact, a jerk limited TP can allow higher acceleration within
a fixed following error budget.

Ok, agreed, but the user needs to be aware that the jerk limited TP comes with limitations on what it can do.

In theory, the only way to have non-infinite jerk while exactly keeping the shape of the toolpath is to come to a complete halt before and after each arc. Anything else is physically impossible. Any jerk limited TP needs to handle this fact somehow. That's what I'm trying to convey here.

Yes, in real life infinite jerk is impossible, so in real life the machine won't move with infinite jerk even though it's told to, which as you say gives following errors. A jerk limited TP cannot precisely follow the optimal/programmed path either, but it can control the error better. The question is: how should it prioritize between shape, feedrate and jerk?