История изменений

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.

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.

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.

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.