Hi All,

I do industrial controls and realtime motion control at work. This differs drastically from the pre-planned and highly optimized motion planning that is used in the CNC world. I was wondering if anyone had any good "brain-leaking-out-of-the-ear" kind of reading on how CNC path planning and look ahead are accomplished. I'm particularly interested in understanding how/why increased lookahead changes the performance of CV motion control and how motion commands are buffered in PVT data for motion controllers.

Mach 3 had some great technical reading on how the motion planner actually functioned, especially when pulses were generated out the parallel port. I could have read that content for weeks! I don't need to limit myself to Mach 3/4 either if someone knows a good read.

Thanks!

Mike

Weird... I got an email with a reply to go look at a forum link that I couldn't open and now that response is gone?

Either way, still interested if anyone has info 

It was probably SPAM that got in and an Admin removed it. 

As to what is going on in the planner, the Mach 3 planner description is still applicable.

Increasing the look ahead may or may not actually increase performance.  It is highly dependent on what kind of G code (or motion path) is being run.  For a typical 2.5D milling application, a look ahead buffer of 5 is probably VERY sufficient.  Increasing the look ahead buffer to 200 lines would NOT help in any sense in this case.  Increasing the look ahead becomes advantageous when processing very granular 3D style CNC paths like making a lithograph on a router, etc..  Because the 3D moves may be very very small.  But keep in mind that CV isn't about precision.  It is about speed.  Or being able to maintain a speed  within a range.  Obviously, the slower the speed, the more precisely the given path can be followed.  Hence high speeds for roughing and slower speeds for finishing. 

Also, CV is a bit of a misnomer.  It should actually be called VB for Velocity Blending.  Because that is what is actually going on.  How the velocity is blended depends a lot on the capabilities of the machine.  Motor acceleration is a primary component as the higher the accel values, the closer the machine can follow the actual path. 

I can say this too...  CV is one of the hardest tasks that the planner does.  There are 3 big pain points while programming Mach and CV is one of them.  Next is Single Block, if you can believe that.  It seems so simple, yet it is VERY complex to implement.  I'd rather poke knitting needles through my ear drums than mess with Single Block.  And finally, any compensation functions like cutter comp, rotation, and scaling are just a nightmare.    If it were easy, everyone would do it, right? 

There are a lot of papers out on the interwebs about trajectory planning.  Terms like Trapezoid, S-curve, 20nd order, 3rd order, etc...  However, there will not be any reading I could point to that describes exactly how to implement any type of trajectory in PT (V can be calculated) type data.  What you really have to do is be able to describe a velocity based trajectory, virtually, and be able to pull a position from any point in time.  In other words, divide the whole trajectory up into time slices of any given width of time, usually around 1 or 2 milliseconds and build calculation function to accomplish this task.  The PT data comes out sequentially, of course, but you could just as well ask the planner for the first time slice's position or the last time slice's position.  Or any time slice in between. 

But wait... there is more!  Take all of that and throw in CV.  So now your calculation function has to include this variable.  And throw feed hold on top of that for an addition few knitting needles through the ear drums.  With feed hold or single block, you now have calculated a trajectory, applied the CV variables to it, but now you have to back all of that out and reduce the velocity to zero.  No, I'm afraid there isn't any paper I could point to that describe that pain.  Other than what I just wrote. 

Steve

Steve,

Wish I could buy you a beer and just pick your brain - I have a feeling it would be a very interesting conversation. Thanks for the detailed reply! I certainly learned something. Never would have thought that single block would be difficult.

The motion control we do at work is continuous real time programming with dynamic adjustments to trajectory. Pretty much the polar opposite mindset from CNC and robotics. It is great for say, following a target based on a camera input, or adjusting a valve position to maintain a pump head pressure, but it is very bad at complex pre-planned trajectory. I did write a basic G-code interpreter for it for fun a couple of years ago, but it mostly parsed the code and used the existing motion instructions to execute the moves. I can't really wrap my brain around calculating CV and stuff like that. I did get basic cutter comp programmed though which I am proud of. It wasn't 100% perfect, but it did work!

Thanks again for the great reply!

-Mike