The new TP behavior is on by default in master. If you have no TP settings in your [TRAJ] section - linuxcnc defaults to.....
ARC_BLEND_ENABLE = 1 ARC_BLEND_FALLBACK_ENABLE = 0 ARC_BLEND_OPTIMIZATION_DEPTH = 50 ARC_BLEND_GAP_CYCLES = 4 ARC_BLEND_RAMP_FREQ = 100 I have cut and pasted some info from Robs post on the forum - helps explain each setting -ARC_BLEND_ENABLE = 1 Turn on new TP. If set to 0 TP uses parabolic blending (1 segment look ahead.) Default value 1. -ARC_BLEND_FALLBACK_ENABLE = 0 Optionally fall back to parabolic blends if the estimated speed is faster. However, this estimate is rough, and it seems that just disabling it gives better performance. Default value 0. -ARC_BLEND_OPTIMIZATION_DEPTH = 50 Lookahead depth in number of segments. To expand on this a bit, you can choose this value somewhat arbitrarily. Here's a formula to estimate how much "depth" you need for a particular config: # n = v_max / (2.0 * a_max * t_c) # where: # n = optimization depth # v_max = max axis velocity (UU / sec) # a_max = max axis acceleration (UU / sec) # t_c = servo period (seconds) So, a machine with a maximum axis velocity of 10 IPS, a max acceleration of 100 IPS^2, and a servo period of 0.001 sec would need: 10 / (2.0 * 100 * 0.001) = 50 segments to always reach maximum velocity along the fastest axis. In practice, this number isn't that important to tune, since the lookahead rarely needs the full depth unless you have lots of very short segments. If during testing, you notice strange slowdowns and can't figure out where they come from, first try increasing this depth using the formula above. If you still see strange slowdowns, it may be because you have short segments in the program. If this is the case, try adding a small tolerance for Naive CAM detection. A good rule of thumb is this: # min_length ~= v_req * t_c # where: # v_req = desired velocity in UU / sec # t_c = servo period (seconds) If you want to travel along a path at 1 IPS = 60 IPM, and your servo period is 0.001 sec, then any segments shorter than min_length will slow the path down. If you set Naive CAM tolerance to around this min length, overly short segments will be combined together to eliminate this bottleneck. Of course, setting the tolerance too high means big path deviations, so you have to play with it a bit to find a good value. I'd start at 1/2 of the min_length, then work up as needed. -ARC_BLEND_GAP_CYCLES = 4 How short the previous segment must be before the trajectory planner "consumes" it Often, a circular arc blend will leave short line segments in between the blends. Since the geometry has to be circular, we can't blend over all of a line if the next one is a little shorter. Since the trajectory planner has to touch each segment at least once, it means that very tiny segments will slow things down significantly. My fix to this way to "consume" the short segment by making it a part of the blend arc. Since the line+blend is one segment, we don't have to slow down to hit the very short segment. Likely, you won't need to touch this setting. -ARC_BLEND_RAMP_FREQ = 20 This is a "cutoff" frequency for using ramped velocity "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). I had considered making the RAMP_FREQ into a time instead, but it seems like the idea of a cutoff frequency is more intuitive, at least to a controls engineer. expanding further 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. Still, if you see a slowdown that you think shouldn't be there, post the example here. There's always the chance that there's a bottleneck that we missed. On 6/11/2014 10:44 PM, Todd Zuercher wrote: > Great to hear that it's in. Looking forward to using it. > > Just a couple of questions, have the necessary config changes to use it been > added to the documentation? > If someone doesn't make the ini changes will the old strategies still used > then? > > > ----- Original Message ----- > From: "Sebastian Kuzminsky" <s...@highlab.com> > To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net> > Sent: Wednesday, June 11, 2014 9:29:27 PM > Subject: [Emc-users] New trajectory planner merged into LinuxCNC's > development branch > > I'm pleased to announce that Robert Ellenberg's new trajectory planner > has been merged into LinuxCNC. It is in the master branch, aka 2.7~pre, > what will become 2.7 later when it's released. It will be part of build > v2.7.0-pre0-550-gd699a06 and later. The new TP is not in 2.5 or 2.6, > those will keep working the same way they always have. > > Robert's new trajectory planner improves LinuxCNC's ability to keep > machining speed up, while not violating the programmed feed rate or > machine velocity or acceleration constraints from the ini configuration. > > Your G-code programs should still make the same parts as before, but > they should now adhere to the programmed feed rate more closely, and > thus cut better and run to completion more rapidly. The old trajectory > planner would sometimes slow down more than it needed to, the new one > does a better job. > > > Many thanks to Robert Ellenberg for all the coding and debugging, and to > Sam Sokolik and others for relentless testing. > > > Brave users of the master branch! Please keep an eye on your machines > and let us know if they misbehave in any way. (And let us know if your > machines run better than before!) > > ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
