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
