Tempest Planner explanation of Function.. (Boring warning..)
Posted: Fri Jan 15, 2016 7:02 am
OK, those who really want to understand in depth how the Tempest planner in Auggie works, and what the difference is to Mach3's planner may find this interesting.
All others should immediately hit "back" or "close" and never again open this document. Users need not know, but may appreciate knowing how it all works.
TO most, a hammer is just a tool to bang in a nail, and when they go to buy a hammer, they are stunned by the actual range of possible hammers. To them, it seems overkill, but talk to a person who uses a hammer all day,and he'll regale you with stories of his favorite hammer type,the swing, the balance and the heft. Understanding Trajectory Planners is similar. TO the average user, you tell it to run a list of motion commands, and it does. It will suck or be great depending on what that user runs and what his expectations are... some will like it, others will not. Why?
To answer this one needs to understand the complexity of what a planner is asked to do. It must take a list of motions, determine the proper acceleration and feed-rate for each motion while not exceeding any individual axis limit of speed and
accel. To most, it would be useless without Constant Velocity, or CV as we call it.
So we can say the most important part of any planner is the acceleration of the tool path itself , as computed from the desired overall feed-rate and the settings of the individual axis(s) involved in the move.
Mach3 has a Bang-Bang planner. Tempest is a sinusoidal S Curve planner. They differ in approach and each has its strengths
and its weaknesses.
Whenever any planner cycles,( planners run in cycles, usually every 1ms), it looks at its current queue and determines where it will be 1ms from now. It computes that as what is sent to the hardware for positioning.
Planners differ in how they look to where they will be, and how they handle joining any upcoming lines.
First, lets understand Mach3's planner a little bit to illustrate the differences.
Lets say we're at stop in Mach3, and you command a move of 100mms in just the X axis. Mach3 will take your maximum accel
value and apply it, so the speed set to that axis will be (accel * .001)+ previous speed, thus raising X's speed to a new value from zero.
The planner will then take that speed, and see where it would put the axis at that point in time. The axis will continue to accelerate each cycle until M3 calculates that its endpoint can only be arrived at as it stops by applying deceleration, so it then applies maximum accel every cycle until speed is equal to zero. Since the calculations were done correctly , we are now in position. If, during this run, the speed hits the feed-rate, which it may or may not do depending on distance, acceleration is
turned off and we run at the speed we arrived at each cycle until its time to decelerate.
Now consider if Mach3 has two lines added to it, One a move to X100, followed by a move to Y=100. If CV is off, its as above with each line done one after the other. If CV is ON however, we must join the lines together. This is done with co-acceleration. As soon as MAch3 senses its time to decelerate in order to stop the X move at 100, it will begin to accelerate the Y move to 100. This has the effect of creating an ellipsoidal blend with the elliptical properties a ratio of the X accel to
the Y accel values. As the decelerating speed of the X axis is countered by the acceleration of the Y axis, the tool-path remains
near constant. This, in a nutshell, is CV under Mach3.
This is a very robust planning strategy and works for the vast majority of people. It has limitations and can be a bit jerky in
certain types of code, but is a very good design. Its a modified planner from EMC and is very good about joining small segment code as the accel of the next line starting at the start of decel allows motions to join together at speed, though this can in some
cases cause jittery mechanical motion as the trade-off.
Tempest Planner:
Tempest was written the year after I left Mach3. With time to spare and to waste I spent a year investigating various higher order planning strategies, Higher order planning held promise of a smoother motion less damaging to machines and allowing mechanics not as tight to do the job. While high order planning was usually on multi-million dollar machines, I felt that in the case of the hobby world where I often saw machines made of plywood and threaded rod, higher order may be able to allow
such machines to perform without pulling themselves apart.
I released an early version in a special release of Mach3 and had many requests to finish it, as it couldn't stop or pause.. but as a smoothing agent, it did do well, and my older router tables liked it a lot.
So lets compare how they work.
In Tempest, when the single move to X100 is commanded, we calculate from your maximum acceleration and the Jerk Limit you specify , the amount of acceleration it can apply to get the axis either up to speed, or as close as can be, while applying that acceleration in sinusoidal phases. Wait a sec, how does a jerk get limited. WTF IS jerk really..
This is key to understanding Tempest, its limitations and its strengths.Jerk is a math term, it means the change in acceleration divided by the change in time. It is the effect you get when , while cruising at slow speed in a Ferrari, you stomp the pedal to the floor. Traditional planners never move by any other means than to stomp the pedal to the floor to begin motion, and hit the brakes pedal hard to stop. They use the maximum accel and decel in each case, so the brake is no stronger then the gas pedal. The only time the gas isn't on full is when your at speed.
In a good stout machine, this doesn't matter, but in many home brew machines, or heavier machines, this type of thrust isn't good for the machine itself or the motors. To correct for Jerk, planners apply the gas slowly , then back it off slowly when they get up to speed. Now if you do that in a constant speed, that's 4th order correction, if you linearly get faster as you go down
or up, that's 5th, and Tempest goes one extra mile and applies the gas pedal in a set of polynomial equations different on each line and pre-planned so the guy sitting next to you feels no more motion than what you declare in your Jerk-limit setting. In Math terms the jerk limit is maximum jerk allowed in DeltaAcc/Sec^2 .
For most, its just a number, which upon getting larger allows more and more shudder to occur. Set to a number like 5,000,000 it approaches Mach3's acceleration as a bang bang planner.( not a bad thing) Set to a low 5000, it applies it in a sinusoidal motion. This can have the effect of adding hundreds of pounds to a machine in terms of stability. Generally, the heavier a machine is the better, so adding virtual weight doesn't hurt. It isn't really noticeable on the higher end or better built machines as they don't suffer much from rigidity issues. But there is also an acceleration benefit, if a machine found itself to have an upper limit of accel of say.. 5000, to pick a number at random, under Tempest it could go as high as 10,000 on some machines since its applied slowly to its max so the motors don't cog trying to get to that acceleration.
In CV, Tempest doesn't do the co-acceleration method, instead it allows the user to specify the maximum rounding to occur as any two lines blend. When the planner gets a line, it plans its acceleration, speed and deceleration up front, so it knows exactly whats going to happen from start to end. That single motion is now ready for motion on the next update cycle it will begin to move.
When the planner see's it has another line coming in making more than one line and they need to be blended, it does several things. First, it creates a thing called a Hermite curve to join the two motions together,this can entail removing a bit of each line and injecting this Hermite curves polynomial into the motion. The Hermite blends always run at constant speed, acceleration isn't allowed in them as that would create jerk and intractable calculations to do a limited jerk blend. then it checks to see how fast such a curve could be run without violating jerk limits. Finally, it will attempt to plan its speed not from zero, but at the fastest speed it can TO zero, and then re-plan the moves behind it to match.
The result after the line is added and all lines are re-planned, is the fastest motion possible across all lines, and blending curves, with jerk below the limit and always ending at zero speed on the last line added. This means each line or arc of motion contains within it, in series..., a blending polynomial from last line , followed by up to 8 coefficients to the main polynomial of speed
and acceleration, followed finally by a blend polynomial for the blend into the next motion.. or just a stop.
Obviously this isn't important to know, but I explain it to foster an understanding of why something like a feed rate override above 100 % is near impossible, though overrides downward are not. The calculations involved in all this have to be lean and mean as each line added forces all previous lines to be re-planned on the fly going backwards from the end till we hit a spot where the speed and accel changes can match up with a previous line somewhere back in the chain of "lookahead" moves.
During this re-planning backwards as each line is added, the lines back in the chain may notice they can go faster now as there is more distance before the end. This causes the tool-path to dynamically speed up as a result of whats way up ahead. Like hitting the highway and knowing you can now go faster up to the speed limit.
There's an implication to the above you need to understand. Blending between lines is done as I said at a constant speed.
This means as each line, no matter how small , must begin and end at zero acceleration.
This example will point why that's important. Lets say you have 100 lines to do each 5mm long, feed-rate 5000, in the first move, the system finds it can accelerate in that 5mm distance to a speed of 5000mm/min, it will do so and all 100 lines run at 5000.
Now you command 20,000 feed-rate and repeat, but the system finds it can only accelerate to 11000 in the first 5mm.
Now you'd think intuitively that in the second move you'd speed up to 20,000. (If indeed your system can do 20,000). After all , the first move accelerated to 11,000. Trouble is, your now doing 11,000, so the time for the next motion is much much less. Worse then that accel and decel can only be applied during that line, it MUST end and start with zero accel. Its speed can go up, but its accel must go up and down following the laws of jerk so that it is zero at the end. So the speed during the next 5mm will only increase as far as jerk limits and accel allows.
As it looks ahead it can vary its end planned speed by considering up to 150 lines of motion if selected to determine the various blending arcs , their limits, and distance needed to stop , so in small segment motions, the lower the jerk limits the more variable the speed can become, but its the system trying to do up to the requested speed and constantly and dynamically optimizing as new lines are added.
When you see this happen, turning up jerk, or lowering the requested feed-rate will cause it to stabilize at a speed, as its
happy knowing though at times it can go faster, its at its limit. This means some programs have a "natural feedrate" based
on their line segment length and such. Mach3 also exhibited this in the way various systems would have trouble with
small segment code when too fast a feed rate was requested.
So Tempest, like any planner has its limitations, but it does allow higher accelerations, and smoother motions for many types
of machines, On some machines this will mean a 20% slower job run, smoothness, like a slowly accelerating driver takes time.
In small segment code it can appear to vary its feed rate, but in a smooth manner. Feedrate override is limited to a range of 5% - 100%, but is instant at all times as the result of simply running the polynomials slower in feed moves. Each move is a complex dance requiring vastly more computation than my older planner, and its fairly new so I just don't know where bugs may lie, but so far so good, we'll figure that out as we go... its a process...and a hobby.. :)
Feel free to ask on any topic in Auggie in terms of how it works, Im happy to elaborate if it helps better use the program to its limits.
Art
All others should immediately hit "back" or "close" and never again open this document. Users need not know, but may appreciate knowing how it all works.
TO most, a hammer is just a tool to bang in a nail, and when they go to buy a hammer, they are stunned by the actual range of possible hammers. To them, it seems overkill, but talk to a person who uses a hammer all day,and he'll regale you with stories of his favorite hammer type,the swing, the balance and the heft. Understanding Trajectory Planners is similar. TO the average user, you tell it to run a list of motion commands, and it does. It will suck or be great depending on what that user runs and what his expectations are... some will like it, others will not. Why?
To answer this one needs to understand the complexity of what a planner is asked to do. It must take a list of motions, determine the proper acceleration and feed-rate for each motion while not exceeding any individual axis limit of speed and
accel. To most, it would be useless without Constant Velocity, or CV as we call it.
So we can say the most important part of any planner is the acceleration of the tool path itself , as computed from the desired overall feed-rate and the settings of the individual axis(s) involved in the move.
Mach3 has a Bang-Bang planner. Tempest is a sinusoidal S Curve planner. They differ in approach and each has its strengths
and its weaknesses.
Whenever any planner cycles,( planners run in cycles, usually every 1ms), it looks at its current queue and determines where it will be 1ms from now. It computes that as what is sent to the hardware for positioning.
Planners differ in how they look to where they will be, and how they handle joining any upcoming lines.
First, lets understand Mach3's planner a little bit to illustrate the differences.
Lets say we're at stop in Mach3, and you command a move of 100mms in just the X axis. Mach3 will take your maximum accel
value and apply it, so the speed set to that axis will be (accel * .001)+ previous speed, thus raising X's speed to a new value from zero.
The planner will then take that speed, and see where it would put the axis at that point in time. The axis will continue to accelerate each cycle until M3 calculates that its endpoint can only be arrived at as it stops by applying deceleration, so it then applies maximum accel every cycle until speed is equal to zero. Since the calculations were done correctly , we are now in position. If, during this run, the speed hits the feed-rate, which it may or may not do depending on distance, acceleration is
turned off and we run at the speed we arrived at each cycle until its time to decelerate.
Now consider if Mach3 has two lines added to it, One a move to X100, followed by a move to Y=100. If CV is off, its as above with each line done one after the other. If CV is ON however, we must join the lines together. This is done with co-acceleration. As soon as MAch3 senses its time to decelerate in order to stop the X move at 100, it will begin to accelerate the Y move to 100. This has the effect of creating an ellipsoidal blend with the elliptical properties a ratio of the X accel to
the Y accel values. As the decelerating speed of the X axis is countered by the acceleration of the Y axis, the tool-path remains
near constant. This, in a nutshell, is CV under Mach3.
This is a very robust planning strategy and works for the vast majority of people. It has limitations and can be a bit jerky in
certain types of code, but is a very good design. Its a modified planner from EMC and is very good about joining small segment code as the accel of the next line starting at the start of decel allows motions to join together at speed, though this can in some
cases cause jittery mechanical motion as the trade-off.
Tempest Planner:
Tempest was written the year after I left Mach3. With time to spare and to waste I spent a year investigating various higher order planning strategies, Higher order planning held promise of a smoother motion less damaging to machines and allowing mechanics not as tight to do the job. While high order planning was usually on multi-million dollar machines, I felt that in the case of the hobby world where I often saw machines made of plywood and threaded rod, higher order may be able to allow
such machines to perform without pulling themselves apart.
I released an early version in a special release of Mach3 and had many requests to finish it, as it couldn't stop or pause.. but as a smoothing agent, it did do well, and my older router tables liked it a lot.
So lets compare how they work.
In Tempest, when the single move to X100 is commanded, we calculate from your maximum acceleration and the Jerk Limit you specify , the amount of acceleration it can apply to get the axis either up to speed, or as close as can be, while applying that acceleration in sinusoidal phases. Wait a sec, how does a jerk get limited. WTF IS jerk really..
This is key to understanding Tempest, its limitations and its strengths.Jerk is a math term, it means the change in acceleration divided by the change in time. It is the effect you get when , while cruising at slow speed in a Ferrari, you stomp the pedal to the floor. Traditional planners never move by any other means than to stomp the pedal to the floor to begin motion, and hit the brakes pedal hard to stop. They use the maximum accel and decel in each case, so the brake is no stronger then the gas pedal. The only time the gas isn't on full is when your at speed.
In a good stout machine, this doesn't matter, but in many home brew machines, or heavier machines, this type of thrust isn't good for the machine itself or the motors. To correct for Jerk, planners apply the gas slowly , then back it off slowly when they get up to speed. Now if you do that in a constant speed, that's 4th order correction, if you linearly get faster as you go down
or up, that's 5th, and Tempest goes one extra mile and applies the gas pedal in a set of polynomial equations different on each line and pre-planned so the guy sitting next to you feels no more motion than what you declare in your Jerk-limit setting. In Math terms the jerk limit is maximum jerk allowed in DeltaAcc/Sec^2 .
For most, its just a number, which upon getting larger allows more and more shudder to occur. Set to a number like 5,000,000 it approaches Mach3's acceleration as a bang bang planner.( not a bad thing) Set to a low 5000, it applies it in a sinusoidal motion. This can have the effect of adding hundreds of pounds to a machine in terms of stability. Generally, the heavier a machine is the better, so adding virtual weight doesn't hurt. It isn't really noticeable on the higher end or better built machines as they don't suffer much from rigidity issues. But there is also an acceleration benefit, if a machine found itself to have an upper limit of accel of say.. 5000, to pick a number at random, under Tempest it could go as high as 10,000 on some machines since its applied slowly to its max so the motors don't cog trying to get to that acceleration.
In CV, Tempest doesn't do the co-acceleration method, instead it allows the user to specify the maximum rounding to occur as any two lines blend. When the planner gets a line, it plans its acceleration, speed and deceleration up front, so it knows exactly whats going to happen from start to end. That single motion is now ready for motion on the next update cycle it will begin to move.
When the planner see's it has another line coming in making more than one line and they need to be blended, it does several things. First, it creates a thing called a Hermite curve to join the two motions together,this can entail removing a bit of each line and injecting this Hermite curves polynomial into the motion. The Hermite blends always run at constant speed, acceleration isn't allowed in them as that would create jerk and intractable calculations to do a limited jerk blend. then it checks to see how fast such a curve could be run without violating jerk limits. Finally, it will attempt to plan its speed not from zero, but at the fastest speed it can TO zero, and then re-plan the moves behind it to match.
The result after the line is added and all lines are re-planned, is the fastest motion possible across all lines, and blending curves, with jerk below the limit and always ending at zero speed on the last line added. This means each line or arc of motion contains within it, in series..., a blending polynomial from last line , followed by up to 8 coefficients to the main polynomial of speed
and acceleration, followed finally by a blend polynomial for the blend into the next motion.. or just a stop.
Obviously this isn't important to know, but I explain it to foster an understanding of why something like a feed rate override above 100 % is near impossible, though overrides downward are not. The calculations involved in all this have to be lean and mean as each line added forces all previous lines to be re-planned on the fly going backwards from the end till we hit a spot where the speed and accel changes can match up with a previous line somewhere back in the chain of "lookahead" moves.
During this re-planning backwards as each line is added, the lines back in the chain may notice they can go faster now as there is more distance before the end. This causes the tool-path to dynamically speed up as a result of whats way up ahead. Like hitting the highway and knowing you can now go faster up to the speed limit.
There's an implication to the above you need to understand. Blending between lines is done as I said at a constant speed.
This means as each line, no matter how small , must begin and end at zero acceleration.
This example will point why that's important. Lets say you have 100 lines to do each 5mm long, feed-rate 5000, in the first move, the system finds it can accelerate in that 5mm distance to a speed of 5000mm/min, it will do so and all 100 lines run at 5000.
Now you command 20,000 feed-rate and repeat, but the system finds it can only accelerate to 11000 in the first 5mm.
Now you'd think intuitively that in the second move you'd speed up to 20,000. (If indeed your system can do 20,000). After all , the first move accelerated to 11,000. Trouble is, your now doing 11,000, so the time for the next motion is much much less. Worse then that accel and decel can only be applied during that line, it MUST end and start with zero accel. Its speed can go up, but its accel must go up and down following the laws of jerk so that it is zero at the end. So the speed during the next 5mm will only increase as far as jerk limits and accel allows.
As it looks ahead it can vary its end planned speed by considering up to 150 lines of motion if selected to determine the various blending arcs , their limits, and distance needed to stop , so in small segment motions, the lower the jerk limits the more variable the speed can become, but its the system trying to do up to the requested speed and constantly and dynamically optimizing as new lines are added.
When you see this happen, turning up jerk, or lowering the requested feed-rate will cause it to stabilize at a speed, as its
happy knowing though at times it can go faster, its at its limit. This means some programs have a "natural feedrate" based
on their line segment length and such. Mach3 also exhibited this in the way various systems would have trouble with
small segment code when too fast a feed rate was requested.
So Tempest, like any planner has its limitations, but it does allow higher accelerations, and smoother motions for many types
of machines, On some machines this will mean a 20% slower job run, smoothness, like a slowly accelerating driver takes time.
In small segment code it can appear to vary its feed rate, but in a smooth manner. Feedrate override is limited to a range of 5% - 100%, but is instant at all times as the result of simply running the polynomials slower in feed moves. Each move is a complex dance requiring vastly more computation than my older planner, and its fairly new so I just don't know where bugs may lie, but so far so good, we'll figure that out as we go... its a process...and a hobby.. :)
Feel free to ask on any topic in Auggie in terms of how it works, Im happy to elaborate if it helps better use the program to its limits.
Art