Hello Guest it is March 29, 2024, 05:50:17 AM

Author Topic: Tempest Planning - Preliminary information and testing  (Read 333585 times)

0 Members and 1 Guest are viewing this topic.

Offline ART

*
  • *
  •  1,702 1,702
  • Tough as soggy paper.
    • View Profile
Re: Tempest Planning - Preliminary information and testing
« Reply #90 on: February 02, 2010, 10:21:53 AM »
piv:

   Its a very complex topic. Overhead really isnt that high , the problem of short section code is a well known on by almost all planners. Rules on angular deviation
and smoothing are variable between them and they all aim for a faster path, the question is always what do you wish to give up as its always a tradeoff. Detail your idea and Ill tell
you why it failed in testing when I attempted it. (Ive attempted a LOT of ways..)  lol ..

Art

Offline piv

*
  •  91 91
    • View Profile
Re: Tempest Planning - Preliminary information and testing
« Reply #91 on: February 02, 2010, 07:30:44 PM »
Hi Art:

First of all thanks for sorting out a great package.  Im really impressed with how easy it is to set up and how well it works.  What I am trying to do is possibly a bit higher end than what it was originally intended for, but it is almost there so I thought I would give it a go. Im on demo version at the moment but will change over to licensed soon I think. Only limited testing with 500 lines of code. What should run in 0.5 sec is taking about 3 to 4 seconds.  Im an OEM/system integrator and this will go on more than one machine if it works out. FYI the end application is Foundry patterns from wood and foam. Upgrade to existing machines and for new machines.

Ive got my DSPMC hooked up to a linear motor and Mach3.  It all looks pretty good.  Ive run a few tests and it looks like Mach3 will process about 170 blocks per sec in CV mode with 50 to 200 lines of look ahead on my 3 year old single core 1.6GHz laptop. The good thing is it doesnt get "data starvation", it just slows the feedrate down so it feeds smoothly at whatever speed it can read the file at.  Some other controllers just feed fast and then come to a dead stop when they run out of data and then go jerky jerky as they then read the code one line at a time (even if it is at 250 or 1000 blocks per sec), until they get to a slow part of the program and the look ahead can catch up again.  So yes it is OK if the CAM output is good, but its not real good for working with bad CAM files at high speed. 

Heres my 2c worth on how it might be made better for a servo system. Sounds like you might have already tried it, so lets find out! Basically simplify the trajectroy planner so it does less work and can process every block faster. If the overhead isnt in the trajectory planner, then simplify whatever else is slowing things down (eg "graphics mode off", or "feed overide off" or whatever it takes). Dont worry too much about the acceleration or jerk and corner blending, the servo tuning will look after that to a certain extent. Use the corner angle to decide if it should go to exact stop or stay in continuous feed. Only do linear interpolation on the segments with no corner blending. Check the accelerations (average acceleration as dumb as (Vfinal-Vstart)/period over a period (of say 10ms) and alter the feed rate if the average acceleration is above a certain value. Of course this method would be useless for stepper systems.  But what I am talking about here is fast servo systems. Most servos have a time constant of at least 1 to 10ms so there is no point in getting too fussed about things in a shorter time frame.  The problem is that its real hard with CAM systems and their lazy operators to get them to put out sensible code and the easiest way is to process the blocks fast.

In the ideal world Mach3 would feed the required axis accelerations into the DSPMC and then the DSPMC could use that as feed forward in its control.  If it did this, it would be truly first class.  But I guess I am dreaming.

Another idea I have had is to re process the G code file before it goes to the CNC controller and have it output position in 1ms increments, preferably with a feed value and an acceleration value at each point. Then the CNC doesnt have to do any real time trajectory planning, it basically just hands over the programmed points to whatever is doing the PID/servo control and that PID control has the input it needs to do proper feed forward. In this kind of high speed application there is no need to have real time feedrate overide.  If the feed rate is wrong, the operator will never have time to correct it anyway.

I havent tried Tempest yet as I think (wild guess?) the issues are related to the complexity of the trajectory planning slowing things down.  Or should I try it?

Is there any way at all to get the block processing speed up to around 1000 blocks per sec? It can be done, I have used one controller that runs at up to 10 000 blocks per second with full kinematics and everything going.  But the cost is fairly high and it has other issues.  Seems like everything has one issue or another.

Regardless of whether this high speed stuff works out, I will be putting Mach3 on a few flat bed routers that need a controller upgrade.

Offline piv

*
  •  91 91
    • View Profile
Re: Tempest Planning - Preliminary information and testing
« Reply #92 on: February 02, 2010, 07:32:18 PM »
Art:
By the way, the CV mode is OK except for the block processing speed.

Regards
Mark

Offline ART

*
  • *
  •  1,702 1,702
  • Tough as soggy paper.
    • View Profile
Re: Tempest Planning - Preliminary information and testing
« Reply #93 on: February 02, 2010, 10:37:21 PM »
>>Another idea I have had is to re process the G code file before it goes to the CNC controller and have it output position in 1ms increments, preferably with a feed value and an acceleration value at each point. Then the CNC doesnt have

Actually, it kinda works that way now. The dspmc uses ( as all plugins) a 1ms trajectory point information stream. The only reason more blocks arent processed is that the buffer is kept 2048 entries long, and the 1ms incrments makes that 2 seconds worth of motion, processing more woudl be useless. It isnt the blocks per second, that is totally unimportant, the thing is how many blocks vs how much distance. The issue is one of the 1ms between blocks. This is calcuated based on the rules of motion in terms of accel and dece, distance and CV..

    The problem being the small block sizes and the calcuated decel and accel between them, while it seems intuitive, once you start to program for it you find the mathmatics near impossible, whats necessary in most instances may not be necessary in all..ect..The type of job, the distance per move and all the rest need to be generalised or else youll get intermittant areas of fault that will even trip out a servo..depending on servo speed and capability. SO while it woudl be possibel to ignore many paramters to make a particular servo system work, it woudl work only for that system, and even then probably not in all circumstances.. and that woudl be very bad for reliable cutting.

    Lookahead plays an importantpart, different in tempest as opposed to mach3, but lookahead is how it figures the max speed for a motion, it isnt enough in small block code to make the decision just on this move and the next, you need to know several moves ahead..so lookahead does that. Again, it needs to be general in nature..specifics is a nightmare and would only work on the target machine..

  Ive tried a great many such methods and they usually turn out very badly..

:0
Art

Offline piv

*
  •  91 91
    • View Profile
Re: Tempest Planning - Preliminary information and testing
« Reply #94 on: February 03, 2010, 12:23:30 AM »
Hi Art,

Yes I have come up against trajectory planners that almost work in most situations but then give me grief.  Like I said, CV mode is good.  How can I get it to handle blocks 1mm apart at 60m/min (contour cutting foam), or about 1ms travel time per block?

The best result I have had is from a controller I set up that can read spline input. I wrote a bit of software that does the tool offsets and makes a G code program (kind of a dumb CAM system) that takes a mesh as a 3D DXF file and then generates widely spaced points that lie on the spline. The motion is beautiful and the contours smooth, it shapes surfboards, a cut across the deck of the surfboard in five axis mode only has about 10 or 20 control points over 300mm.  It runs at about 30m/min.  But the problem is its not a general solution.  I have tried to set up UG NX with spline output and it kind of works. But it took a lot of head banging with the guy writing the post to cover most of the situations and even now its not "production" ready for every possibility.

Your approach to tempest and normal CV is very good I think. Could it be made to preprocess the data to make the 1ms point stream so that it can run at full speed at run time with short segments. The only issue I see at the moment is that Mach for me is only processing about 170 blocks per second, which means if the stupid CAM system is putting out blocks at spacing closer than 5.88mm (60m/min = 1000mm/sec.   1000/170 = 5.88mm at 170 blocks per sec), even if the curve is very slight and the physics says it doesn't need much acceleration, then the motion will slow down because the G code isnt being read fast enough.

Here is another example. Running aluminium with a three flute cutter at 24000 rpm and 0.1mmpt chip load, feed is 24000*0.1*3=7200mm/min = 0.12m/sec = 122mm/sec.  On a machine that can have 1g acceleration, at a feed rate of 7.2m/min, it should be able to go around a radius of  R = (v^2)/a = 0.12^2 / 10 = 0.00144m = 1.44mm at full speed. So any smooth contour with a local radius greater than 1.44mm should be traversed at full speed. At 122mm/sec, and 170 blocks per sec, the point spacing has to be 122/170 = 0.7mm or greater, which will not properly define any curve of say less than 10mm radius. But at 1000 blocks per sec the spacing is 122/1000 = 0.12mm. which will nicely define even the 1.44mm radius that can be traversed at full speed.

Have you got an old planner that didnt work on steppers but might work on highly dynamic servos?

Offline piv

*
  •  91 91
    • View Profile
Re: Tempest Planning - Preliminary information and testing
« Reply #95 on: February 03, 2010, 12:36:54 AM »
Hi Art,

I just wanted to clarify, I understand DSPMC takes points on 1ms interval.

CAM package puts out closely spaced points at say 1mm spacing so to feed at 30m/min needs G code blocks to be processed at 500 blocks per second. Mach3 should turn this into a point stream at 1ms interval or about 0.5mm spacing if its a straightish path. But it doesnt, it reads G code at 170 blocks per second and so travels 170mm per second at a feed rate of about 10m/min and DSPMC point stream spacing of 0.17mm instead of 0.5mm.

Ive been testing points on a straight line, so physics shouldnt come into it (except at the ends where it has to start or stop).

My wish is to somehow get Mach to do it at full speed.  Do I just need a computer 3 times faster? I am willing to help out with this.

Offline ART

*
  • *
  •  1,702 1,702
  • Tough as soggy paper.
    • View Profile
Re: Tempest Planning - Preliminary information and testing
« Reply #96 on: February 03, 2010, 09:04:51 AM »
  Piv:

  I do understand what you face.The problem you describe is really caused by the way Mach3 ( and emc) compute the path capability. 
Its really a generalization problem. Ill see if I can explain, though its a hard one to fully explain.


Take a straight line of 1ms motions which add up to 3 feet. You have an acceleration that allows a 1 foot move to hit 30m/min at about 6mm in. ( thats considering the time necessary to accelerate, and the time to decelerate... ( just an example ).

  SO then we queue up a bunch of 1ms motions but each motion is only 4mm. Each motion is first planned separately so the full speed of the 4mm move is not 30m/min, but it only reached 20M/min due to the move being too short to simply push at full accel, it must instead plan an accel,cruise and decel motion. ( in this case there is no cruise).

  So we end up with say 1000 moves, each one individually having a top speed of 20m/sec not 30m/sec as one woudl desire for the full motion. The planner ( same as emc by the way ), uses an additive property where as the first decel's , the next move accell's.. this makes them smoothly join togeher BUT the top speed is 20m/min ..not 30 even though the distance total would allow 30m/sec in real world physics. In the end the planner will allow for 2 seconds of motion to be put out at a time.
 
Block processing speed has nothing to do with it typically, the slowdown is because the individual motions dont allow for full speed. Straight lines are a separate issue as the system determines they are in a straight line and joins them as one line. BUT in the case of any other situation, angular devationos, corners etc.. the top speed will be the top speed of one 1ms motion, when observin the accel ( and decel of that one move.

  So the real problem is that all moves, even short ones have a accel, cruise and decel time calulated into them, it is that which slows the feedrate, not the block processing speed. Since each short motion can only move as fast as it could move if it had to stop after the 1ms, the end speed is reduced. The cv simply adds the decel of one to the accel of the next. ( causing the top speed to be the 1ms obtainable speed.)

  This is what I think you face, its not block processing speed, its the way CV works, the addition of the accel/decell zones is limited to the 1ms calculated top speed. In the case of Mach3's planner, when it goes to output the steps or 1ms points of the entire trajectory, it iteratively runs each block at the same time.. so if we have 10 blocks in the queue, it may run all 10 before it figures where it shoudl be after 1ms, BUT the accel/decel time of each block inherantly limits the end speed to be much lower than if the system had a longer time to accelerate and decelerate.

   SO in a few ways your right, if the accel was modified to be a calulation based on total distance instead of the 1ms distance youd go much  faster. The block processing speed you see is simply the result of not being able to go faster than the 1ms accel rate for such a short motion. Concatenation doesnt remove the limitation, it just makes a smooth transition from one motion to the next.

  In Tempest this doesnt work that way. In tempest, the lookahead determines the accel and decel. For example, if two 1ms waypoints bend aroudn a corner, tempest joins them mathmatically into a bezier type curve, and calculates the true jerk of that curve, then allows any accel up to the jerk limitation desired. Because of this it runs faster in many situations, ( slower in others.). If email wasnt so bad at drawing I could show you graphically why each planner is limited in one way or the other. But it isnt block processding speed, I could process thousands of blocks per second, but it wouldnt speed anythign up, the block speed of processing is limited to the feedrate of the motion, since at any time, only 2 seconds of motion is queued.

   In tempest youd be closer to the truth on slowdown. IF using a lookahead of 100 for example, and you have 100 1ms motions, tempest will basically attempt to make one motion 100ms long, and set a decel and accel profile for that motion, it too is limited though. The fastest speed one 1ms motion can achived is the most the speed can increase per 1ms waypoint. Each motion can be made to go faster than the motion before it unlike MAch3 and emc, as long as the following motions added up can allow enogh time to decelerate. 

    This is all a generalization of course, many circumstances are taken into account and create limitations of their own. Try tempest and see if it helps, I suspect youll hit some other limitation in speed as a result, but may find it faster in a surf baord type of application.
Youd just need to set the jerk very high as opposed to limitin it to a low value. Setting Jerk limit to 1million or so will make it as fast as it can be.. 

  SO in essence, MAch3 and EMC suffer from having to calculate the decel of even a move which doesnt or shouldnt decel as its goign into the next motion, thus the top speed is limited to some degree, where tempest modifies the first motion calulated to increase its speed as it adds the next motion in. This ups the top speed of short segments, but again not always. Angualr devaitions of short moves are more sensitive to the math as a sharp angle at .001mm of motion can look acute where it realy isnt due to segment length.

   The problem with planners is they integrate tighty to a system, so changing them isnt easy... it leads to a whole lot of error throughout
the system. Its why Tempest exists only as a test program, with some limitations as it isnt fully developed or attached. ( though I cut with it frequently as it produces a smoother finish.

Art
 

Offline piv

*
  •  91 91
    • View Profile
Re: Tempest Planning - Preliminary information and testing
« Reply #97 on: February 03, 2010, 06:58:34 PM »
Hi Art,

Thanks for such a good detailed reply.  Ive got the surfboard thing nailed, no need to consider that because it works great with the spline contouring (G5 in www.Eckelmann.de  ENC55 controller if you are curious). But there are other issues with it that are tricky to resolve for some applications and important for me. It does however have a very good trajectory planner that works well until it runs through its buffer and then it reads one line at a time and goes jerky jerky until it gets to a slow part of the program like a corner and gets to fill its buffer up again, thats because my version interprets 250 blocks per sec (can get a newer ENC66 that does 1000 blocks per sec), but if the block throughput is lower or you use splines then it will run short segment code at the programmed feed rate and observe acceleration limits. Its got adjustable filters in its setup.

Anyway, I think you can do better based on what I have seen you do so far.

Im not sure I understand the limited speed that occurs in each motion segment but to my way of thinking (which is probably a bit weird) for a servo system it is the average acceleration over a short time period (like 10ms) that is important, since any jerk or pulse type acceleration on a shorter time period is masked by the servo response (and also by the 1ms waypoints).  Of course this is bad for a stepper system, but then hey, who is ever going to run short segment code in exact stop, it horses for courses and the choice would be great.  Have to change a CNC program so will reply again.

Offline piv

*
  •  91 91
    • View Profile
Re: Tempest Planning - Preliminary information and testing
« Reply #98 on: February 03, 2010, 07:55:37 PM »
Hi Art,

Ive read your post again (and again) and I think I now understand the issue. To clarify, In Mach3/emc, Each segment is "planned" with accel and decel, but then the decel portion of segment n, has the accel value of segment n+1 added to it so that the segments join together smoothly. I guess there is more detail to it but I think that is the essence and it also explains why programs run faster as the segment length increases.  OK, so what we are dealing with is the physics of a single segment rather than the overall physics of the path.

Tempest however fits a curve to it and has a jerk limitation. In theorey then a "smooth" path should be able to run at "full speed". I will do some tests. In theorey a 90 degree corner should be slower in tempest than in Mach3 CV mode for a given acceleration because in CV mode it "cuts the corner" and starts to accelerate into the new segment before it gets there, in tempest it will "exact stop" on the corner.  This sounds real good.  Its exactly how it should be.  If I want round corners I will get my cam package to do them.  This also means if you are cutting say a square with sharp external corners, the toolpath can have a corner radius smaller than the tool radius so it cuts the corner sharp but then tempest will follow the toolpath arc "exactly". Very Nice! Now if we can get Tempest to feed the path acceleration at each waypoint into the DSPMC then we can have proper "pre control" feed forward! Its a dream but the way of the future.

Now to find the speed limit.

Offline piv

*
  •  91 91
    • View Profile
Re: Tempest Planning - Preliminary information and testing
« Reply #99 on: February 03, 2010, 07:57:04 PM »
Hi Art,

Just ot clarify , I think you can do better than the competition.