LinuxCNC S-Curve Accelerations

db1981 wrote:

How and where is the feed override applied at the moment? In front of the look ahead?

in this file github.com/LinuxCNC/linuxcnc/blob/master/src/emc/tp/tp.c look for calls to "tpGetFeedScale()"

arvidb wrote:

Thank you for the analysis. Maybe tangential-only jerk limiting is more useful than I imagined. Interesting!

Regarding kinematics: I don't even want to think about jerk limiting, say, a robotic arm. Cartesian machines first?

When it comes to feed override and a full jerk limiting TP, I'm thinking that one solution could be to plan the trajectory for pre-set max feed rate and following tolerance, producing also data on max velocity at each point on the path. And then limit velocity further at each point, where applicable depending on current feed rate setting. Yes, it makes the tool path less precise than absolutely necessary, but on the other hand, do we want the tool path shape to change depending on feed override setting? Maybe there has been a lot of discussion about this already so that there is some consensus?

This video discusses the trajectory planner as it is now.

Maybe it is possible to replace the circular arc blends with some kind of bezier curve, a 7th order bezier has 8 parameters and could be parametrized to given start and end position/velocity/acceleration and jerk (with respect to curve-parameter). I don't know how hard it is to transform a bezier into something that is parametrized by length, i suppose that will get ugly very quickly. But that should be a well-studied problem with known recipes for approximation.

Thanks, a very interesting lecture. Thanks to Robert Ellenberg too for talking!

It was kinda cool to see: the jerk-limited counterpart to parabolic blending is kindof what I called "constant jerk vector" here (i.e. switch as fast as possible from one direction to another). The jerk-limited counterpart to arc blending would then be the clothoid, which, just like the arc, keeps constant velocity.

Clothoids are parameterized by length, too. But they only give constant jerk for something like a train or car, which turns with the curve. For something like a tool in a machine, that keeps a constant heading, there's also jerk needed to rotate the acceleration vector around it, and acceleration to rotate the velocity vector. That can be seen from the jerk and acceleration limit violations in my plot on that same page.

For anybody interested in the topic, maybe this could be informative. It provides a general over view on path blending and proposes a method using clothoids.

dro.deakin.edu.au/eserv/DU:30118119/shah...thsmoothing-2019.pdf

[edit]

Just realized that this looks like the usual spam post. It's not I swear.

There are 2 aspects to this problem.

One thing is the generation of the speed profile. The other one is blending toolpaths under constraints like allowed deviation, allowed acceleration, allowed jerk.

I just resurrected my branch (that only changes the speed profile) and it seems to merge cleanly on master. If you want to play around with it, you need to #define BEZIER for the "smooth" planner or compile with -DBEZIER.

Also, as a memento, if I remember correctly, the MachineKit ppl refactored the trajectory planner into it's own module so you can plug it in at run time. Maybe it's worth taking a look at that.

And thanks for the link to the dissertation, this will make an interesting read.

Aciera wrote:

Just realized that this looks like the usual spam post. It's not I swear.

Don't stress, we know who the good guys are and won't shoot on sight

reading this topic with interest to expand what little I know and what I thought about tradjectory planners and why stuff is programmed the way it is plus the evasive S-curve that regularly crops up over the years on various forums and requests for integration.

does it really change the finished part in the hand at the end of the job?

robertspark wrote:

does it really change the finished part in the hand at the end of the job?

Yes I believe so. Imagine a plasma cutter cutting at 10.24 m/min with 5 m/sec/sec acceleration (0.5G). It will get to speed in 30 milliseconds.... the inertia results in a massive jerk when it stops and starts and also when it gets to speed and stops accelerating. Oscillations in the cut are inevitable.

For a milling machine at a more leisurely pace, its probably not so much an issue but I have heard of users doing retrofits complaining about jerk on big heavy machining centres...