diff options
| author | John Thornton <jthornton@gnipsel.com> | 2014-06-12 08:28:03 -0500 |
|---|---|---|
| committer | John Thornton <jthornton@gnipsel.com> | 2014-06-12 08:28:03 -0500 |
| commit | 28bcc7fc2ded325568bfb590ae24c2349f758bf0 (patch) | |
| tree | d125da5ff89eb7d3a666497725872b0c48d519f5 | |
| parent | 5c968882f9378b698532af31eefc3a53be1490b1 (diff) | |
| download | linuxcnc-28bcc7fc2ded325568bfb590ae24c2349f758bf0.tar.gz linuxcnc-28bcc7fc2ded325568bfb590ae24c2349f758bf0.zip | |
Docs: add info on trajectory planner ini options
Signed-off-by: John Thornton <jthornton@gnipsel.com>
| -rw-r--r-- | docs/src/common/User_Concepts.txt | 12 | ||||
| -rw-r--r-- | docs/src/config/ini_config.txt | 114 |
2 files changed, 126 insertions, 0 deletions
diff --git a/docs/src/common/User_Concepts.txt b/docs/src/common/User_Concepts.txt index 80ece27ca..0ea5ff619 100644 --- a/docs/src/common/User_Concepts.txt +++ b/docs/src/common/User_Concepts.txt @@ -11,6 +11,18 @@ before attempting to run a CNC machine with g code. === Trajectory Planning +[WARNING] +The new Trajectory Planner (TP) is on by default. + +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 + +For more information on the Trajectory Panner ini options see the Integrators +Manual. + Trajectory planning, in general, is the means by which LinuxCNC follows the path specified by your G Code program, while still operating within the limits of your machinery. diff --git a/docs/src/config/ini_config.txt b/docs/src/config/ini_config.txt index 3039bc752..44bce8833 100644 --- a/docs/src/config/ini_config.txt +++ b/docs/src/config/ini_config.txt @@ -528,9 +528,123 @@ Section. [[sub:TRAJ-section]] === [TRAJ] Section(((TRAJ (inifile section)))) +[WARNING] +The new Trajectory Planner (TP) is on by default. + +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 + The [TRAJ] section contains general parameters for the trajectory planning module in 'motion'. +* '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' - Look ahead 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 +look ahead 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). ++ +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. + * 'COORDINATES = X Y Z' - The names of the axes being controlled. Only X, Y, Z, A, B, C, U, V, W are valid. Only axes named in 'COORDINATES' are accepted in g-code. This has no effect on the mapping from G-code |