>>>Ive read your post again (and again) and I think I now understand the issue. ..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.  ..we are dealing with is the physics of a single segment rather than the overall physics of the path.

  Exactly so. Its really the small individual motion that causes the slowdown.. not the totality of motion or the blocks/second.

>>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. 

  Not really. Picture 5 motions in have to be done. Say they are 1mm each. The accel and max velocity is such that a 1mm move can only go 100m/min because it then needs to slow down. Mach3 will be quite smooth at joinging them but the speed will be only 100 through the move. ( Segment n decel + n+1accel will cancel to 100m/min, the planned rate of each 1mm move.).


   What happens in Tempest is that motion #1 comes in and is planned at 100m/min, the fastest it can go and decel in 1mm. When motion #2 comes in , a hermite curve is put between the two points at a tolerance specified by the user. Say its .2mm. This means an arc will be produced to join the two motions. Then, the entire motion is replanned from 0 - 2mm.. so the end speed is higher, Jerk equations are used to determine what the maximum physical speed is that the arc blend can be run at, the preceeding and end portions of the two lines are then planned to join with the arc at a matched speed. This means the overall speed can be higher than Mach3's. As each segment is added, the entire line is replanned except where its partially put out already in which case its planned from a known start speed to a desired end speed, taking jerk into accoutn through all arc blend join points.

This means in Tempest there are no corners, all lines round at the blend point to the radii set by the user as a blend radius. Any planer that has sharp corners has to stop, physics demands it. If it doesnt properly do that, you get as you describe, your surfboard runs well, other code is problematic.. ( likely servo faults or cutoff areas where undesired.). If you specify zero as the blend radius, you get a sharp corner..but Jerk equations tell us that any sharp corner MUST come to a complete stop. SO the end speed will be faster as the blend radii get larger. The Jerk equations allow for this. However, in short segment, the users blend radius is lowered to be a maximum of 30% of the line length, so very short blcoks end up with tigth radial belends, and the Jerk Equations thus lower the speed to constrain tangental jerk on the blend arcs.

 No way aroudn it.. short code is a bitch..

Art
 

I am watching with interest and I guess the real solution is a better CAM program instead of beating up the planner.

Mike

Hi Art,

I just tried out tempest and its not suitable for short segment code. As you say, it never gets up to full speed. Have you ever seen a Makino machining centre work? They only run G01 and short segments. Moulds are programmed with short segments. They run at the programmed feed rate.  I dont know how they do it, but I suspect they just feed the G01 to the machine and have some kind of of feedoveride/accel/decel thing going on when the segement angle is like a corner or when there is a G00.

If the real physics indicates that a motion can be done, then it is the way it is being interpreted that is the problem, not the short segments. What is needed is a simple robust way that works.

The dynamics of the machine I am working with at the moment would get a better result (than tempest or Mach3 CV) up to 6000mm/min by just sending the 1ms points to the DSPMC, points worked out as if they had infinite acceleration (ie jump straight to feed velocity, no acceleration). It will get up to 6000mm/min in 0.5mm, provided the following error is set above say 1mm, no problem. Of course rapids would have to see acceleration, but that is G00 not G01.

Of course it would be better to look at the average acceleration and reduce the feedrate when required.  Maybe some minor changes to the existing trajectory planner can achieve that. The motion has to be planned as accel, cruise and braking over the whole buffer, not for each segment. To do this it might have to start at the begining of the buffer and keep accelerating until it gets to maximum feedrate. It also has to look at the end of the buffer working backwards from the end where it is stopped, and decelerating as it moves backwards until it is at maximum feed rate, or it meets the acceleration phase.  Following that logic the planner would fill its buffer, the limit being say time of motion or end of feed (say encountering G00) or number of blocks or whatever you feel like really. Then it plans the accelleration, accelerating over each block and subsequent block or 1ms waypoint until it is up to full speed.  It also plans its deceleration, working from the end of the buffer backwards until they meet in the middle. Then as the buffer is used and new waypoints are added, the first part of the buffer has already been planned, so the new plan just works backwards until it meets the old plan, somewhere near the middle.  There are some tricks that could be done to simplify the maths and make it robust. Yes it is a bit itterative, but it doesnt have to have many entries in the buffer.  If there are few entries, then it will limit the speed when the accel and decel meet in the middle. The required number of waypoints can be worked out based on feedrate and allowable acceleration. As the motion across a 1ms waypoint segment is "fictional" motion, we can use a theoretical SpeedStepChange = accel*0.001sec,   say for 1g acceleration its SpeedStepChange = 10000/0.001 = 10mm/sec/msec. The speed of each axis can increase by a maximum of that amount for each waypoint.  Now the trajectory planning is done with simple step changes in speed.  

I dont think any curve fitting needs to be done. Just assume a constant velocity across each 1ms waypoint segment, with velocity greater or less than last waypoint by the deltaV=acceleration*0.001seconds, unless the vector speed is at the programmed feed rate.

There will be an issue to be dealt with in that the ramp up and ramp down may not meet exactly according to 1ms waypoints.  This doesnt matter if the buffer is just normally full, it becomes a special condition when the buffer is terminally full because it has run out of code or hit a stopping condition (like G00 or M30), then the ramp down has to be replanned from the meeting point to the end of the buffer so it is continuous. Id say start the deceleration from the true waypoint on the ramp up (or coast), before it met the ramp down, then ramp down at maximum deceleration, this will get to the second last waypoint, then move to the last waypoint at slightly less decceleration so it matches up properly.

I know Ive left out heaps of detail.  Maybe it wont work, but I dont see why not yet.  If I can help in any way, let me know. If this is implemented it will give exact stop in corners and blend all motion at full acceleration and at maximum speed. There will be jerk but that could be limited by more complex planning if need be.  I dont know if the iterative nature will let it get done in time, if that is the problem, then I would be happy to pre process before run time and give up feed rate overide. But really it shouldnt be much more difficult than the current planner.  Does it need a drawing to clarify my ramblings?

Totally RC, Yes i agree, a better CAM package is (almost) thel answer.  But have you ever tried to get one of the high end CAM packages to do something for you or get something changed? At least we can talk to Art!!!

Anyway if the CAM package is doing its job properly, in G01 mode (and Mach3 doesnt support G5 splines) then its not that simple.  If the machinist wants to achieve a 0.001mm (Ok hes dreaming or lazy) or 0.01mm tolerance, even 0.1mm tolerance,  then tight radii will have very close points, then even though theoretically the dynamics of the machine would allow it go around the radius at full speed (eg 7000mm/min feedrate goes around a 1.4mm radius at 1g), the Tempest and Mach3 and EMC planners would limit the speed savagely because its the segment length that is limiting feed rate, not block processing speed or physics of the true toolpath. 3D continuously changing contours arent practical with G02/G03 and splines can have issues as well.  G01 is the general robust solution.

What I am trying to get across is that trajectory planning might be better if it happens according to physics (taking account of the discreet 1ms cyclic nature of our data transfer and the real time response of motors) across the full motion path rather than across adjacent segments. Jerk and acceleration over a 0.5ms period mean nothing because the motion controller is only getting points to use in its PID at 1ms. The response of the serovs results in Following error that smoothes out anything that happens in a period of a few ms. Think about what happens in the PID.  It compares actual position with command position to get an error value that is used to command torque on the motors.  That happens cyclically (this is a digital not an analogue world) so every 1ms (or 02ms for the DSPMC) the drive is getting an entirely new torque value which implies an instantaneous infinite jerk.  Of course the response of the drive and any filters in it then the inductance of the motors and everything smoothes it out over a few ms.  So what I am saying is, use that imperfection in everything else to make the trajectory planning easier.

If you crack this planning properly then you open the door to a whole new world.

FYI I have a customers machine running a step controlled servo drive and a parrallel port based motion control (wont mention any names here, its not Mach or EMC). It is programmed with short segment g code and will run over contours at 16m/min quite smoothly.  The problem is it ques the motion up before hand and takes a while to load the buffer.  The buffer has a size limit and thats a problem for big programs and long motion. Also there are limitations as to what can be interfaced with it and it wont do what I want to do in the future. So what we want done as a planner can be done in a non real time way, the question is can it be done real time?

>>Have you ever seen a Makino machining centre work?


  Hmm, lets see if I can create a way to explain this the way I see it.

Lets say you get in your car for a drive around the block. You have a very fast car.. ferarri say..


 To a ferarri, you have a very short run on each street as you go around the block..

Now we all realize that you will accelerate , then brake as you hiut the cvorners.. if you dont youll skid out and lose
position as you try to do the corner. The skid is created by the math expression "Jerk". One can calculate jerk as a function of velocity
and acceleration as the vectoral direction changes. This is refered to as tangental jerk. How much tangental jerk you can accept before
skidding is a function of your tires and how well they grip. Lets say we remove the tires and put a set of rails around the block with
very small arcs at the corners to allow for a directional change without stopping. ( CV)..
  Because the car is now locked to the rails with top and bottom clamps, you can now make the same car go very fast around the corners.
A Makino is such a device. Its designed that it can accept a Jerk of very high magnitude before losing position of straining mechanics.
There are time in such machines if you listen that they clunk quite a bit..doesnt hurt them at all , but that clunck is the inflection
point of the highest jerk experienced.

  Now CNC in general, certainly in Mach3 users generally, have machines on tires..no rails. They will lose stspe or fault servo's if forces
go too high, its why MAch3 doesnt allow infinite acceleration. I highly suspect if that restriction alone was raised you'd go much faster indeed. I just happened to pick a limit that was lower perhaps than what woudl be optimal for someone like yourself that wants higher speed
through small blocks. Might be interesting to raise that substantially to see in a test version for you.

  All things in CNC are tradeoffs. If you go for high speed ou sacrifice stability or position, there is by the laws of physics no way
around this limitation, positional accuracy requires lower speed OR high Jerk capability. High speed requires the desire to go out of
position ( rounded corners) , or very tight mechanics and very high power. A Makino has both very powerfull servo's, and very tight mechanical connection and slides. The software for it knows that and uses VERY high acceleration, and unique ways of joining
line commands to create fast motion.

  Tempest KNOWS the jerk at vectoral changes, its why in small blocks it still wont go too fast , in fact in a lot of code its slower
than MAch3, testers report a finer finish but slower completion, this is because tempest is also a SCurve genrator, makign it slower by 30% in accelerated takeoffs, but much less jerky to the mechanics, again, all a tradeoff on performance. When I watch tempest do a 3d mould, it almost never clunks, where MAch3 clunks a lot. My machien can take either but the difference is audible, which tells me somethign about
how Im treating my linear ways and such.

  You idea's on simply taking 1ms waypoints is a bit off the mark, its not waypoints you want, their already there. Its very very high acceleration that you need. Decisions on when to apply that as opposed to normal accelration are difficult to generalize to specific
situations. Thats what you find when you try to do it.   
 
   Ill see if I can generate a very high accel version to test with. Im not sure the math of the planner will allow such high accel, but in theory it should..so it may. Again, generalities dont allow me to say for sure it will do what your looking for. Planner technology is very difficult to do, and theres a lot of discussion on how to do it. Tempest was written from idea's in a doctoral thesis from a Canadian university. But agin, was heavily modified to meet the general nature of peoples machines.. No-one writes anythig for a speciic machien execpt its manufacturer.

Art

Hi Art,

Firstly, I hope you understand that I really like Mach, for lots of applications its fantastic. I also think the work you are doing is fantastic. Im just putting in my $2 worth (bit more than 2c now), and offering to help in any way I can. There are lots of us who are building more advanced machines, its like a drug or arms race, once you start to do CNC,you just want to do it better and better. Control of chip load, contouring and speed of running are all relevant to lots of people.  The planner I am discussing should be general for all machines, not specific ones. Its just that the machines and applications I am working on make it easy to see the effects and cost savings of good trajectory planning.

I dont think Tempest is taking advantage of the laws of physics. I have one axis set up with a linear motor.  The test setup is highly dynamic, it can go to 8g since it had no extra mass on it. It could handle very high Jerk.  I have it set to 1g in the motor tuning so it limits it to a realistic acceleration. Thats not the point, Ive got other machines that have acceleration capability of only 0.01g so understand what you are saying.

Here is what I did on my Tempest test. I will send the code when I get into work so you can try it. I set up just X moves, all 0.1mm segment length for a total distance of 50mm. If I do just one G01 move over 50mm Say G01 X50 F50000 the motor accelerates fery fast (1g) and very smooth and goes straight to the endpoint. With the lots of short moves it goes much slower and and with varying speed along the way, as in faster slower, faster slower...   Worse at jerk 50 000, ok at jerk 1000 000 (but still with visible speed changes) and worse at Jerk 10 000 000.

I know jerk affects the dynamic response of a machine. The acceleration sets the size of the force while the jerk is the rate of onset of that force. Acceleration depends on the force of the servos while Jerk can be higher as the mass and stiffness and natural frequency of the machine increase. A planner needs to control position, velocity, acceleration and jerk.

Using the road and rails analogy, what I have is a straight road with a lot of lines across it. The car should just drive over the lines and go from start to stop as if they arent there. But is doesnt, it is likethe driver is trying to brake and start at each line, with Tempest and CV just helping the driver roll over each line. If the Trajectory planner looked over the whole straight road and kept accelerating then there would only be a jerk at the start and stop of the acceleration as constant acceleration gives zero jerk.
A cnc program is like dots or witches hats along the edge of the road. Mach is trying to drive between each marker, thats fine if the markers are 100 yards apart. But CAm packages are like road workers paid per marker and drop the markers 1 foot apart. So long as the makers follow a smooth path around the race track, you can drive your Ferrari at 200mph within an inch of every marker, the markers are a blur and the driver doesnt really see each marker, he sees the overal path. mach would be doing it at a walking pace as it tries to drive a straight line between each marker with just a bit of coasting and a turn at each marker.  Its not what everyone wants. Mach is doing a good job at proper corners but it is doing a pretty slow job of points on a smooth trajectory.

I dont want infinite average acceleration. What i want is constant acceleration or as high acceleration as possible within machine and overal trajectroy limits. If you can add in a jerk limit then that is great.

Art, is there someway for me to get into DSPMC a premade list of points (say the 2048 points in the buffer) at 1ms separation so I can take a video of various plans and then compare them against Mach and Tempest.  With my Elmo servo drive I can get it to log the actual position,velocity, motor current etc and send a picture. But only for about a second or so. This might be an easier way of looking at trajectory methods rather than going through the pain of writing and integrating an entire planner.  I can just construct whatever physics we want to look at with a spreadsheet or bit of stand alone code.

It was a long way of saying the planner needs to look at the whole buffer (path) and go to as high a speed as possible within the constraints of acceleration (and jerk if your machine is wobbly). What can I do to help?

piv:

>>Im just putting in my $2 worth (bit more than 2c now), and offering to help

  No problem there, I never take offense and it allows me to rethink many things when I have these discussions,
its sometimes a long time betwen code sessions so even I forget how things work.

   When you say 1ms points..using what acceleration? 1ms presupposses that there is an acceleration as well
as a feedrate. If you mean can it send you points not separated by such things as slowdowns for junctions and such..not easily.
Its basically trying to defeat the way it works. It wasnt designed to look ahead that way. Closest you could get woudl be to have
as close as infinte acceleration as possibel and accelerate the data yourself.

   Im heavily bogged in code at th moment, so its not a project I could take on, but perhaps in the near future I coudl allow such high accels
in a test version.

 Your rigth about tempest. Its drawback is that it cannot add one line to another, its designed to always put an arc to join lines, that arc stop sacceleration
during its run and its 20% of the line length, so the accel is jerkier to apply so the speed is kept down. Tempest is far from finihsed though, its just sleepinmg till
summer sometime..

Art

 

Hi Art,

Thanks for your time.  I think I can get up and running with Mach on some of the existing machines so there is no immediate urgency.  Im looking ahead to see if it can be improved for the future.

 >>When you say 1ms points..using what acceleration? 1ms presupposses that there is an acceleration as well
as a feedrate. If you mean can it send you points not separated by such things as slowdowns for junctions and such..not easily.
Its basically trying to defeat the way it works. It wasnt designed to look ahead that way. Closest you could get would be to have
as close as infinte acceleration as possibel and accelerate the data yourself.

When I say 1ms points I mean points on the motion path, spaced 1ms apart, with the path acceleration (vector acceleration, sum of tangent and normal accel) limited to the motor tuning value (in my case 1g, 10 000mm/s/s) (or a programmed value). Because it is piece wise discontinuous (in the control loops), this effectively means the acceleration is just an allowable step change in velocity (v=u+a*t) for each 1ms waypoint. Its way easier to sort out than the way Mach does it at the moment I guess.

If it has infinite acceleration, then it might be feasible to accelerate the motion by putting a feed rate with each segment, but thats not the general solution for most CAM packages. But, it would have to be a mode of operation (or special G code) since G00 and G02 etc would still need an acceleration value like they do now.

>>When I say 1ms points I mean points on the motion path, spaced 1ms apart, with the path acceleration (vector acceleration, sum of tangent and normal accel) limited to the motor tuning value (in my case 1g, 10 000mm/s/s) (or a programmed value).

  Hmm, but thats exactly what MAch3 does now.. gives 1ms waypoints limited ot the motor tuning acceleration.. Thats the Mach3 planner in a nutshell really.
I think Im not grasping something maybe.. But that describes exactly what Mach3 puts out.. possible shortcoming that each segment is limited by mototr tuning to its max speed, but that cant be changed without simply using a different planning theory algorithm altogether..

Art

Yes art, it might need an entirely different planning algorithm because the current Mach planner speed is limited to what can be done on the G code segment and its next G code segment.  Or Im not understanding how the Mach planner works.  Certainly its not getting up to the physics limited speed over a long path (made of short segments).