LinuxCNC S-Curve Accelerations

More
6 years 4 months ago - 6 years 4 months ago #171450 by PCW
Replied by PCW on topic LinuxCNC S-Curve Accelerations
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.
Last edit: 6 years 4 months ago by PCW.

Please Log in or Create an account to join the conversation.

More
6 years 4 months ago - 6 years 4 months ago #171558 by arvidb
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?
Last edit: 6 years 4 months ago by arvidb.

Please Log in or Create an account to join the conversation.

More
6 years 4 months ago - 6 years 4 months ago #171561 by PCW
Replied by PCW on topic LinuxCNC S-Curve Accelerations

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.
Last edit: 6 years 4 months ago by PCW.

Please Log in or Create an account to join the conversation.

More
6 years 4 months ago - 6 years 4 months ago #171567 by arvidb
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?
Last edit: 6 years 4 months ago by arvidb.

Please Log in or Create an account to join the conversation.

More
6 years 4 months ago #171575 by arvidb
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.

Please Log in or Create an account to join the conversation.

More
6 years 4 months ago - 6 years 4 months ago #171584 by arvidb

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.
Last edit: 6 years 4 months ago by arvidb.

Please Log in or Create an account to join the conversation.

Time to create page: 0.106 seconds
Powered by Kunena Forum