LinuxCNC S-Curve Accelerations

By "control the error better" I mean that it can be deterministic about it: it can plan beforehand how much error to allow and how much jerk to allow, by compromising between the two and by varying feedrate. This way it can plan a tool path that is actually physically possible to follow exactly. But it needs to be informed somehow about how to make the choices it has to make. I think an important part of the development of a jerk limited TP is to decide how to make these choices.

arvidb wrote:

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.

Maybe I need to elaborate on this a bit:

Transitioning directly from a line to an arc at any speed > 0 requires inifinite jerk. Other than coming to a complete stop, slowing down doesn't help. So at any speed > 0, some tolerance on arc radius is needed to get anything other than infinite jerk.

Why is this? We are going from a linear move at constant speed, where acceleration is zero, to a circular move at the same speed, where centripetal acceleration is a constant > 0. Transitioning between these two at any speed requires an immediate jump in acceleration; that is, infinite jerk.

It seems to me that driving a car on the road, it's possible to follow the road while accelerating and jerking. I means you must spend time accelerating and jerking.
We trade time for acceleration and jerk not position.

The idea of jerk control planning it to actually calculate a definitive jerk rather then ignoring it. AIUI this allows increase in acceleration which offsets the loss of slowing down for jerk control.

Your observation that gcode doesn't describe jerk is also true for acceleration.
The feedrate set in gcode is often not followed do to this.
In linuxcnc now there is also a tolerance for position vrs speed.

The car analogy is a good one. If you had a road with an immediate transition from straight to a circular arc (as the g code describes), it would be impossible for you to stay exactly in the middle of the road without coming to a complete stop at the transition and then turn the wheels before accelerating again. To pass the transition at any speed > 0 and keep exactly in the middle of the road, your wheels would have to instantly jump from pointing straight forward to pointing at an angle suitable to follow the curve. That would be infinite jerk. So the only way to drive through such a transition at speed > 0 would be to deviate a bit from the middle of the road.

It's true that we must spend time accelerating. The problem with radial jerk is that the time spent doing that is time spent on a tool path that is neither linear nor circular, and since g code can only describe linear and circular movement, any time spent applying radial jerk will move us off the nominal tool path. The more time we spend "jerking" (the lower our jerk limit), the more we get off course. It is unavoidable.

To calculate a definitive jerk rather than ignoring it, we must take this into account. Not taking this into account is equivalent to ignoring jerk.

I wrote earlier "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." - and it seems I was right.

Please take a look at my post with the image from Wikipedia again. It is a good illustration of the problem.

That problem is not really any different than any TP deals with (at every g1 waypoint )
blending to tolerance by lowering the speed is the standard way to do this, its basically
the same with jerk factored in (though considerably more complicated)
With bounded jerk many profiles will actually be faster at a given following error budget.

Ok, so the algorithm should make the jerk limit an absolute priority then, and sacrifice feed rate to reach it. Got it.

arvidb wrote:

Ok, so the algorithm should make the jerk limit an absolute priority then, and sacrifice feed rate to reach it. Got it.

No, in fact lowered (controlled) jerk often allows faster feed rates at a given error budget
(because of lowered excitation of machine resonances)

I mean from the perspective of the algorithm that an actual computer program would have to use. The only variable left to touch if both path deviation and jerk are treated as hard limits is the feedrate.

I didn't mean to say that the user would have to sacrifice feedrate compared to some other TP (I have no experience comparing jerk limited vs unlimited TPs), but from the algorithm's point of view, feedrate is the only thing left to be adjusted to keep the other limits within their bounds, i.e. the thing that's "sacrificed". In the same way that feedrate is "sacrificed" to stay within acceleration limits, as you said before.

I'm trying to understand how a jerk limited TP would work; I'm not comparing it to some other TP.