and I will be a happy man once some wonderful person works it out:) On Mon, Aug 23, 2021 at 1:49 PM Curtis Dutton <curtd...@gmail.com> wrote:
> 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 > _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
