The goal is allow both accuracy and speed. However there is a tradeoff between those two just as there is now.
During any move all vel, acc, jerk values must be coordinated to follow a given path. For a coordinated move any limiting constraints will limit the other related joints to prevent violations. To perform multiple move through a sequence of lines the motion planner has to blend moves and cut corners. The blend is also shaped to avoid violating any limits but go as fast as possible. The distance the corner can be cut by will be user specified. G64 just like now. Ultimatly the gcode program combined with your machine and its capabilities are still going to limit the upper feed rates that can be accomplished. With jerk limiting the max acceleration values for any given machine will be able to be increased while still having less following error. This should lead to decreased cycle times for any given g-code program. On Sun, Aug 22, 2021, 8:15 PM John Dammeyer <jo...@autoartisans.com> wrote: > This jerk control raises some questions for me. They probably have simple > answers rather than as complex as jerk control but perhaps it's related. > > Each axis has a MAX_ACCELERATION value. Simple math says that if X and Y > are moving at an identical velocity then the path of the tool is 45 > degrees. > > I suspect that the MAX_ACCELERATION is exactly that: maximum. If we want > that 45 degree line to remain straight then both axis have to accelerate at > the same rate and end up at the same velocity at the same time so the > acceleration that’s used is the lowest of the MAX_ACCELERATION value? > > From a feed rate perspective we want to get up to the target feed as > quickly as possible since chip load, tool rubbing etc. can have adverse > effects if the speed is too slow? > > By the same token the speed along that 45 degree path is the F parameter > so each axis speed isn't the F value but the amount required to create the > speed on that path? > > Finally if the combination of acceleration and distance is such that the F > parameter isn't reached before it's time to decelerate then the tool > reaches 0 before ever hitting the requested speed? > > This is all for a simple move that starts and stops. And clearly would > cause a jerk like motion but it's precise from point A to point B. As I > understand the jerk side of things the requirement is to look ahead at the > next move and only accelerate or decelerate as required to reach the new > velocity for each axis and change the rate of acceleration within that > envelope. > > But now the two axis are no longer following the target path right? > There is one that has to slow down to half the speed while the other > accelerates up to twice the speed (for example). The path followed now is > more complex? And which acceleration is used and is it changed as the path > is followed? > > What's the goal? To traverse the path as accurately as possible or to > reduce the shaking from sudden speed changes (the jerk)? > > Mostly just confused. > John > > > > > > > -----Original Message----- > > From: Curtis Dutton [mailto:curtd...@gmail.com] > > Sent: August-22-21 11:48 AM > > To: Enhanced Machine Controller (EMC) > > Subject: Re: [Emc-users] jerk control > > > > I have a desire to implement this. > > > > My business is in need of another cnc router and I will be building as > > high speed of a machine as I can afford. It is going to be a dual table > but > > a horizontal spindle. 1m x 1m working envelope. I plan on using linear > > motors. > > > > It will require jerk limiting to really get the value out of the machine. > > > > I have been working on bits and pieces in my spare time but I have very > > little time right now. > > > > > > My main approach so far is.... > > > > > > The realtime motion component will be enhanced so as to interpolate > nurbs > > curves. Those curves need be in a specific form of parameterization. > (coord > > length parameterized) > > > > > > The other part is in user space and it is the hard part. To perform > > blending of line segments it converts segments to nurbs curves, and > blends > > them together by fitting a segment of a clothoid (euler spirals) in > between > > them. It must do all of this while fitting within all of the velocity, > > accel, jerk and limit constraints. Then it reparameterizes these curves > for > > consumption by the motion component. > > > > This is essentially plotting a reasonable driving path on an N > dimensional > > race track. > > > > From some of the papers that I have read it looks like it will involve > > numerical integration and/or linear programming. Adding jerk equations > into > > standard physics makes it very much harder to solve. Closed form > equations > > don't really seem to exist. (If you have experience with this I could > > sorely use pointers, links, papers) > > > > > > Ultimately this is a very difficult task. Building a stripped down > version > > of a jerk controlled motion planner is what many people have done to > earn a > > PHD. > > > > > > I would be happy to join up with anyone else that is interested in > working > > on this. Even ideas, papers, demos is very helpful. Timeline for this... > > sadly a few years at best before completion. > > > > > > Thanks, > > Curt > > > > On Tue, Aug 17, 2021, 10:10 PM andrew beck <andrewbeck0...@gmail.com> > wrote: > > > > > Here is the text from your link sam > > > > > > > > > Ramped velocity in this case just means constant acceleration over the > > > whole segment. This is less optimal than a trapezoidal velocity > profile, > > > since the acceleration is not maximized. However, if the segment is > short > > > enough, there isn�t enough time to accelerate much before we hit the > next > > > segment. Recall the short line segments from the previous example. > Since > > > they�re lines, there�s no cornering acceleration, so we�re free to > > > accelerate up to the requested speed. However, if this line is between > two > > > arcs, then it will have to quickly decelerate again to be within the > > > maximum speed of the next segment. This means that we have a spike of > > > acceleration, then a spike of deceleration, causing a large jerk, for > very > > > little performance gain. This setting is a way to eliminate this jerk > for > > > short segments. > > > > > > Basically, if a segment will complete in less time than 1 / > > > ARC_BLEND_RAMP_FREQ, we don�t bother with a trapezoidal velocity > profile on > > > that segment, and use constant acceleration. (Setting > ARC_BLEND_RAMP_FREQ = > > > 1000 is equivalent to always using trapezoidal acceleration, if the > servo > > > loop is 1kHz). > > > > > > You can characterize the worst-case loss of performance by comparing > the > > > velocity that a trapezoidal profile reaches vs. the ramp: > > > > > > # v_ripple = a_max / (4.0 * f) # where: # v_ripple = average velocity > > > "loss" due to ramping # a_max = max axis acceleration # f = cutoff > > > frequency from INI > > > > > > For the aforementioned machine, the ripple for a 20Hz cutoff frequency > is > > > 100 / (4 * 20) = 1.25 IPS. This seems high, but keep in mind that it is > > > only a worst-case estimate. In reality , the trapezoidal motion > profile is > > > limited by other factors, such as normal acceleration or requested > > > velocity, and so the actual performance loss should be much smaller. > > > Increasing the cutoff frequency can squeeze out more performance, but > make > > > the motion rougher due to acceleration discontinuities. A value in the > > > range 20Hz to 200Hz should be reasonable to start. > > > > > > Finally, no amount of tweaking will speed up a toolpath with lots of > small, > > > tight corners, since you�re limited by cornering acceleration. > > > > > > On Wed, Aug 18, 2021, 2:06 PM John Dammeyer <jo...@autoartisans.com> > > > wrote: > > > > > > > This is what we're talking about right? > > > > Ramping acceleration? > > > > https://www.mmsonline.com/articles/understanding-jerk-control > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > From: Feral Engineer [mailto:theferalengin...@gmail.com] > > > > > Sent: August-17-21 6:46 PM > > > > > To: Enhanced Machine Controller (EMC) > > > > > Subject: Re: [Emc-users] jerk control > > > > > > > > > > I'm curious what the current level of block lookahead is on lcnc > > > compared > > > > > to commercial controls. Anyone know the amount of data buffering > that > > > it > > > > > can handle? > > > > > > > > > > Phil T. > > > > > The Feral Engineer > > > > > > > > > > Check out my LinuxCNC tutorials, machine builds and other antics at > > > > > www.youtube.com/c/theferalengineer > > > > > > > > > > Help support my channel efforts and coffee addiction: > > > > > www.patreon.com/theferalengineer > > > > > > > > > > On Tue, Aug 17, 2021, 9:36 PM Sam Sokolik <samco...@gmail.com> > wrote: > > > > > > > > > > > It would be the same setup... Just using servo amps.. > Velocity out > > > > of > > > > > > the pid - position back from the encoders. > > > > > > > > > > > > On Tue, Aug 17, 2021, 8:14 PM andrew beck < > andrewbeck0...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > Not sure Sam. > > > > > > > > > > > > > > I have a 7i77 on this mill though also. So analog control > > > > > > > > > > > > > > On Wed, Aug 18, 2021, 12:51 PM Sam Sokolik <samco...@gmail.com > > > > > > wrote: > > > > > > > > > > > > > > > I am going to ask a stuid question.. If you have a velocity > run > > > > step > > > > > > gen > > > > > > > > with pid. Couldn't you hook a limit3 between the pid and > > > steghen. > > > > > > > > Because the input is velocity instead of position - wouldn't > the > > > > > > > > acceleration limit in the limit3 be jerk instead of > acceleration? > > > > I > > > > > > am > > > > > > > > sure it doesn't work that way.. I was just thinking you have > > > moved > > > > the > > > > > > > > derivatives up one.. > > > > > > > > > > > > > > > > (I can tell you it doesn't seem to work in practice - > probably > > > > because > > > > > > > the > > > > > > > > pid will always try to correct the error. Like maybe you > would > > > > need to > > > > > > > > negate the limit3 amount on the feedback side..) > > > > > > > > > > > > > > > > On Tue, Aug 17, 2021 at 1:28 PM Scott Harwell via Emc-users < > > > > > > > > emc-users@lists.sourceforge.net> wrote: > > > > > > > > > > > > > > > > > I haven't tried it yet, but this looks promising. > > > > > > > > > LinuxCNC S-Curve Accelerations > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Scott H > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tuesday, August 17, 2021, 12:57:06 PM CDT, Ralph > > > Stirling > > > > < > > > > > > > > > ralph.stirl...@wallawalla.edu> wrote: > > > > > > > > > > > > > > > > > > I've also been hoping to see this appear in a Linuxcnc > update, > > > > > > > > > as it has been worked on by a number of people for years. > > > > > > > > > Here are the most recent threads about jerk-limited > trajectory > > > > > > > planning: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://forum.linuxcnc.org/24-hal-components/40152-jerk-limited-trajectory-planner-hal-component > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://forum.linuxcnc.org/38-general-linuxcnc-questions/34666-c2-smooth-velocity-profile?start=0 > > > > > > > > > > > > > > > > > > -- Ralph > > > > > > > > > ________________________________________ > > > > > > > > > From: David Berndt [ber...@uberwin.com] > > > > > > > > > Sent: Tuesday, August 17, 2021 9:01 AM > > > > > > > > > To: Enhanced Machine Controller (EMC); andrew beck > > > > > > > > > Subject: Re: [Emc-users] jerk control > > > > > > > > > > > > > > > > > > CAUTION: This email originated from outside the Walla Walla > > > > > > University > > > > > > > > > email system. > > > > > > > > > > > > > > > > > > > > > > > > > > > I don't have a great need for it with my machines, or the > > > > time/brains > > > > > > > to > > > > > > > > > implement it. It just seems like a feature we really should > > > have. > > > > > > > > > > > > > > > > > > I'd be willing to participate monetarily in some sort of > > > > system to > > > > > > > > > incentivize the inclusion of jerk control. Perhaps an > > > open-source > > > > > > > feature > > > > > > > > > bounty? Does the community want to consider that sort of > thing? > > > > > > > > > > > > > > > > > > -Dave > > > > > > > > > > > > > > > > > > On Mon, 16 Aug 2021 23:06:05 -0400, andrew beck < > > > > > > > > andrewbeck0...@gmail.com> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > hey guys > > > > > > > > > > > > > > > > > > > > I am sitting here watching my cnc mill atm its shaking > quite > > > a > > > > bit > > > > > > > > > > acceleration is 600mm/sec2 which is not that high i > think. > > > > > > compared > > > > > > > > to > > > > > > > > > > every other cnc mill i have used with a commercial > > > controller. > > > > > > they > > > > > > > > have > > > > > > > > > > jerk control and work much better. so looking forward to > > > when > > > > we > > > > > > get > > > > > > > > > > jerk > > > > > > > > > > control here on linuxcnc! > > > > > > > > > > > > > > > > > > > > but in the mean time i need a poor mans jerk control and > > > > thinking > > > > > > of > > > > > > > a > > > > > > > > > > limit on the pid output to chop down the initial > acceleration > > > > for > > > > > > the > > > > > > > > > > first > > > > > > > > > > moment in time just so little moves don't shake it to > death > > > > > > > > > > > > > > > > > > > > andy mentioned that I could maybe use a limit component > to > > > > limit > > > > > > the > > > > > > > > > > initial acceleration for the first tiny moment in time > to cut > > > > down > > > > > > on > > > > > > > > the > > > > > > > > > > vibrations. > > > > > > > > > > > > > > > > > > > > how do you guys think that could work? > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Emc-users mailing list > > > > > > > > > > Emc-users@lists.sourceforge.net > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc- > > > > > users&data=04%7C01%7Cralph.stirling%40wallawalla.edu > > > > %7C7457b9607a2d4747a1e508d961a1b508%7Cd958f048e43142779c8de > > > > > > > > > > > > > > > bfb75e7aa64%7C0%7C0%7C637648169423748846%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB > > > > > > > > > > > > > TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ue%2BwIaVhfay08NBevlCAvyOoNp0qVz9ojUuigRuCOOs%3D&reserved=0 > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Emc-users mailing list > > > > > > > > > Emc-users@lists.sourceforge.net > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc- > > > > > users&data=04%7C01%7Cralph.stirling%40wallawalla.edu > > > > %7C7457b9607a2d4747a1e508d961a1b508%7Cd958f048e43142779c8de > > > > > > > > > > > > > > > bfb75e7aa64%7C0%7C0%7C637648169423748846%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB > > > > > > > > > > > > > TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ue%2BwIaVhfay08NBevlCAvyOoNp0qVz9ojUuigRuCOOs%3D&reserved=0 > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Emc-users mailing list > > > > > > > > > Emc-users@lists.sourceforge.net > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Emc-users mailing list > > > > > > > > > Emc-users@lists.sourceforge.net > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Emc-users mailing list > > > > > > > > Emc-users@lists.sourceforge.net > > > > > > > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Emc-users mailing list > > > > > > > Emc-users@lists.sourceforge.net > > > > > > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Emc-users mailing list > > > > > > Emc-users@lists.sourceforge.net > > > > > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Emc-users mailing list > > > > > Emc-users@lists.sourceforge.net > > > > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > > > > > > > > > _______________________________________________ > > > > Emc-users mailing list > > > > Emc-users@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > > > _______________________________________________ > > > Emc-users mailing list > > > Emc-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > _______________________________________________ > > Emc-users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
