Tempest Planner explanation of Function.. (Boring warning..)

[ArtF]

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





 



 

[DanL]

that was understandable thanks Art, would Tempest make 2.5D/3D files run a little bit slower but better, that's the main thing I am after doing just a straight cut out in M3 and M4 is fine for that,when it comes to 2.5D/3D, that's where you run into problems.

[ArtF]

Hi Dan:

  >>would Tempest make 2.5D/3D files run a little bit slower but better,

  Hard to say at this point, its a subjective question. It will definitely make
things better on some systems, may make it worse on others..

  Lets put it this way, Ill be working to smooth out motion where I require it,
and I do wish to make smooth profiles, Im thinking perhaps of a routine that reads in small
segment Gcode, and then creates a runnable bezier curve that doesnt have any stuttering ..
kinda like Nurbs.. but just get it from the gcode that is small segment code... as a mode
of operation perhaps.. like a conversion on the fly to a bezier motion..maybe..who knows.. :)

Art

[DanL]

if it works good for a laser burning a pick, what looks top notch, it will be close, my little router goes slow so it may be fine for how you want it for your laser's

[Joakim]

Art:

Very good explanation - I think I understand it now...  :) Thank you.

Elegant to simplify the GCode line segments to curves before planning - its like the simplify or smooth functions in more advanced drawing programs to lower the numbers of control points.
(Have done that manual in the past to reduce the number of line segments in DXF files, before the CAM and post)

- Joakim

[chicoxiba]

Love it!

I have to make more time to be part of this. I will be demoing the releases that's for sure. Hopefully in a few months I will be able to allocate more time and really give it a good run.
I will order a pokeys sometime soon, I can feel it.

Thanks Art.

F

[chicoxiba]

Art,

I have just relived a really interesting conversation you had with a user named Piv, clever guy. What an inspiring talk about the trajectory planners and the strategy behind it. I have to say I agree with this guy in his points on that there must be an easier way to make a planner run through a 3 dimensional path of coordinates defining "organic, amorphic" forms.. "contouring". Here is the link, it starts on page 9 and gets really good around page 11,12. http://www.machsupport.com/forum/index. ... 42.80.html

As a matter of fact I have used a machine controller program for PC that does that, but it is proprietary and I cannot use it. Also it is quite costly to build a machine to use it because it needs a galil controller to work.
I could post a video or two I made of it working, its really quite good; Cuts absolutely true to the path and it runs very smooth and very fast, very smooth accelerations, never twitchy. You can set corner speeds for angles from 0,10,20,30-90 and 180 degrees. I have been able to achieve 40000mm/min while doing G1 with it. http://www.motion-solutions.com.au/Moti ... tware.html

[ArtF]

chicoxiba:

    Thx for that, I had forgotten that thread. :)

  Its funny all these years later that I'm hitting that point again.. I think 3d code under
tempest will be slow at times, (though much faster than the old tempest..), and I think
I have to start adding a curve processor soon to attempt what the thread speaks of.

  My understanding of curve control wasn't as good back then, and so perhaps
its possible to allow for a mode where incoming GCode data is used as control point entry
to the processor to create a polynomial path of motion that could indeed run at full speed.
The only real prerequisite to doing that is to know you will start at speed 0 and end at speed 0.
  While Id hate to try that on a stepper, servo's are superior at following and maintaining
their own limits of acceleration and speed..

    The entire point of Auggie is as an experimental platform, so that kind of thing fits in
well.

    One can exemplify the problem well with the 1mmSpiral file which is really a raster file
for my laser to burn in circular spirals. My table is now capable of 30m per minute. It runs
the spiral slowly at first, gathering speed till it end on tight circles of 5" or so at about
11meters/min.  The real hold up is that accel may only be performed in a line, blends must
be entered at zero accel no matter what. Its the only thing that holds tempests' speed down,
otherwise it would show no upper limit in speed. So a bezier mode which implies blending
without blends, ( as all the motion is one entity,) would make it very fast indeed. I have
a few idea's on this and I "think" I could make it magnitudes faster..
Thats what Auggie is really all about, functional experimentation. BUT, I do need to finish control first, once people are moving about and having fun, Im more than willing to look at experimental phases of operation.

  I started all this because I need a laser controller, M3 just doesn't do what I need in
that respect, and while I could have cajoled a hardware provider into giving me capability,
( Actually Pokeys were GREAT in that respect by working to give me a spec on PWM
that gives Auggie real time PWM capability), I didn't feel I was in a position to ask for
experiments to be put into M4 for me to play in. M4 has to be reliable for their
customers.

    Auggie has no need of reliability, each user can determine for themselves the
reliability level they want, use M3 and M4 as their primary system, ( Pokeys
works on both) and join us with Auggie when they are persons such as yourself
who like to play in concepts for such things.

  So I too, would like to see a planner that perhaps can switch on the fly when it
detects the need, to allows a language modification to perform such things. When
I read the specs on the software in your link, well, that's pretty much what I'm
aiming for, plus making the scripting interface easy enough that people
feel they can play.

  I don't see Auggie competing with any controller out there commercially, but its Free,
its Powerful and empowering to the user, and I don't see why we cant get at least a core group of
us who like to play with motors and experiment with various forms of control. Perhaps
such things can be ported to other controllers or .. at a minimum we can impress the
community out there with functional capabilities.

  So yeah, stick around, play with the new tempest, I suspect you'll find its still limited
for what you need, though I can run your surfboard files at 17m/min max, I think we
can probably get them to 30m/m eventually. Maybe.. Possibly.. :)



Art

 

[chicoxiba]

Art,

Sounds good with the preprocessing of the points and fitting a curve to them. May the force be with it :)

>>"The only real prerequisite to doing that is to know you will start at speed 0 and end at speed 0.
  While Id hate to try that on a stepper, servo's are superior at following and maintaining
their own limits of acceleration and speed.."

Id be happy with starting from zero sp and coming to a full stop at the end of the curvilinear moves, specially with scurve decel :o) and also I'd love to try it on steppers;

Take your time Art, have fun, finish what you want to finish first. ...btw I love the way mach4 has a responsive screen with high refresh rate and the new openGL toolpath display. Hey and if you could, let us add transparent objects on top of the toolpath display... just saying :P

Regards,
F

Thanks for the interest,
Francisco

[ArtF]

F:

>>.btw I love the way mach4 has a responsiv e screen with high refresh rate and the new openGL toolpath display. Hey and if you could, let us add transpare nt objects on top of the toolpath display.. . just saying

  I should point out, many people are still unaware, that I left Mach3's development almost a decade ago, and Im not involved in Mach4 in any way except as a plugin developer of Darwin for the printer port. But Im sure the M4 guys will hear the
compliment. :)

Art