Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project!

## RE: [Emc-users] trajectory planning

 RE: [Emc-users] trajectory planning From: Leslie M. Watts - 2003-12-29 19:13:27 ```Hi Jon If others could look at the code it would be great. I have little experience in a multi-tasking rt operating system-just some c programming in dos way back. I know the math but am no expert on code. Fred told me not to feel too bad about not following the code though...he said I am not alone in that problem :^). It was written as a demonstrator for NML and has an awful lot of globals in it. As far as one segment lookahead working with a sharp bend... it will work if there is enough force in the prime mover to supply the needed accel in the blend region. Example- say your motor/ballscrew can supply 1000 lb force to a mass that weighs 500 lb. with reasonably low friction as in ballscrews and ball profile ways. Those are fairly common numbers, even including screw moments of inertia and such. That's 2 g!! So a sudden right angle bend could be done at 2 in/sec with a corner radius of 4/768 or .005". It would miss the waypoint by about one third that amount. This of course does not include following errors due to finite servo gain etc. My machine is built to do 1g (386 in/sec^2) but I have to run at 15 in/sec^2 in the .ini due to the tp problem. I think most run even lower...less than 5. Ideally I would like to run at about 50-100. Beyond that I would be spindle hp limited and would only be causing extra wear and tear. However single point look ahead is very poor performance compared to a routine like segmentqueue that can look ahead through the entire program and make better planning by knowing all that information. It uses psuedo waypoints to create a true spline path that will pass exactly through waypoints. Spline tightness is dependent on how much accel you specify. (in the .ini) Anyway the planner is emcsegmot.c. Fred has it checked in. It runs smaller programs nicely but on long ones it stops motion, gives an error message about not enough time to perform a rt task, and then repeatedly thrashes the disk writing something to the log. We have checked things like slowing down, increasing buffer size, shared memory, etc. It is not simply a case of too many calcs per time period in a machine. We suspect some kind of race condition involving the queue but that is speculation. I would be happy to gather some test programs up for you as I have time. I need to run them all again and carefully note the exact behavior. Note that G02/03 moves do not have a problem and execute smoothly at the servo rate using the cubic sub-interpolator. They do not blend at the ends though. The test programs were to document the problem with the CURRENT tp in hopes of a quick work-around fix while we wait for segmentqueue to be resolved. It might be better for anyone that is willing to build the segmentqueue version and explore that. If you could set it up you might have some insight into what is wrong, as you are one of the most experienced emc users/developers. It may be very simple. It's certainly true that sw authors can miss a bug simply because they don't recognize the error. I have the segmentqeue in a separate box and just switch out the card. Of course it is on the shelf now as I must do production work with the original emc box. With Fred's permission I can also shoot you a copy of the NIST segmentqueue paper. It is about a 50 page report. Les Leslie M.Watts L M Watts Furniture Tiger Georgia USA (706) 212-0242 http://www.lmwatts.com Engineering page: http://www.lmwatts.com/shop.html CNC surplus for sale: http://www.lmwatts.com/forsale.html CNC carved signs: http://www.lmwatts.com/signwp.html -----Original Message----- From: emc-users-admin@... [mailto:emc-users-admin@...]On Behalf Of Jon Elson Sent: Monday, December 29, 2003 12:37 PM To: emc-users@... Subject: Re: [Emc-users] trajectory planning Leslie M. Watts wrote: >Hi Jon > >Well rather than finding the problem with the trapezoidal >planner we have simply tried to replace it. > >Let me give you an overview of what we have done so far. > >It has long been known that the emc trajectory planner >fails dramatically under certain circumstances. > > I've never seen it on my machine, but as several people have reported it, I believe you. I don't do contouring-type stuff, so I just haven't run into it. >My tests have shown that even in G64 emc often breaks into >a psuedo exact stop mode with violent exteraneous tangential >accelerations. > >This has been observed with close waypoints, distant waypoints, >long motion strings, and short ones,and execution timing. >For example one test circle program I ran >(consisting of G1 moves) would blend the first time it was run, >then break into exact stop mode in the third quadrant the second >time! > > How long were the arc moves? A whole quadrant at a time? Could you send me the program? I'd like to try it on several different versions of EMC with different motion hardware. This one sounds pretty easy to duplicate. >Fred wanted to get a functional higher performance planner >installed way back and assigned the project to Rogier Blom, >a guest researcher. A new planner was written but not quite >finished. (ran out of time) > >I managed to have the good fortune of getting Fred and Rogier >together again down here in the Georgia mountains to try and >get the new planner going. > >The old planner (had it worked) used blended trapezoidal velocity >profiles with cubic sub interpolation at the servo rate. As you can >see from my previous post trapezoidal planning is simple... just a few >lines. It needs one segment look ahead only. > It seems to me that can't work! If you have a bunch of nearly straight, very short moves, the machine can just race through them, but when it comes to a right angle turn at the end of one "row", it can't possibly slow down in time. It HAS to look ahead farther than that or it is going to crash at the end. > These days it is >quite obsolete though. It was mainstream 20 or 30 years ago or so I guess; >little processing power was needed. > >The new planner uses cubic trajectory planning in real time and is >capable of looking ahead the ENTIRE program! It is fairly sophisticated- >much more that a simple cubic spline. > >They set up the new planner in my big gantry machine and it ran great. >Super smooth motion at high speeds. No violent wear on the machine. > >But on larger programs it just stops midway through. It is some kind of buffer thing perhaps. > Gee, this should not be that hard to find. Maybe it needs somebody else to look at it. Sometimes the author just keeps looking, but fails to see the problem. I wonder if the traj. planner could be pulled out of the RT section and run under Linux mode so a big debugging trail could be written out and then examined to see where the trouble comes from? > >Rogier has to be the one to find this because he wrote the code. >He has some new business assignments back in Holland though, so >we have had to be patient. > >This issue is very important to me because I am ramping up to some >real production on my emc driven machine. The planner problems >pretty much cripple emc... one has to run much slower with lower >accels and lower gain just to keep it from tearing a machine to pieces. >Even then path velocity often slows down uncontrollably with loss of chip >load causing rapid tool dulling and work damage. > >To me fixing the malfunctioning trajectory planner is the most important >task that can be done...above anything else. > > Yes, it sounds pretty serious. I'm not sure I consider it more serious than lathe threading, but it sounds like it is at least that level. >If the new planner can be made to work it would turn emc into a >a free truly high performance modern control. Right now it can be >no more than a hobbyist's curiosity. I hope this happens because >I have invested a good bit of time in emc. I will have to go to >a commercial control otherwise. > >Obviously any new manifestation of emc should have the modern >planner. The code would not be the same, but the math would. > >We do have to wait for Rogier to get some time to look at this. >It is so close! In the mean time I have been looking at tp.c, >tc.c, and emcmot.c to get some insight into why the trap planner >doesn't work. Trapezoidal planning would get me by while we wait >for the new one. The code is very very hard for me to follow though, >even though the math is simple. At least I can run tests >to characterize this in an effort to track it down, and report >results to Fred. > > Yes, this is a problem with EMC. Logically, what it does is fairly easy to grasp, but when I look at the code, except in a few small cases, I find it totally baffling, too. Over a year ago I did a huge exercise to add a small structure to the emcmot struct-of-structs and move the auxilliary I/O over to the RT side. I needed to do this to serialize access to my PPMC and USC hardware through the parallel port. It was an incredible effort to do something that was logically so simple, and I had to put big hacks into about 6 totally unrelated modules to accomplish it! John Kasunich's HAL would have made this trivial, of course. >Oh, I also want to publicly thank Fred and Rogier for working >on this pretty much pro buono (sp?)...they (Like me) really want >to see a free, open source, high performance control. I don't like >the idea of being trapped with a commercial one. > > Yes, I think all of us EMC users want to thank Fred, Will and all the others who have contributed effort to EMC, both those associated with NIST and those of us on the outside, like Paul Corner and Ray Henry, who have been pushing it to be more accessible to the average user. Jon ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Emc-users mailing list Emc-users@... https://lists.sourceforge.net/lists/listinfo/emc-users ```