On 2/19/2012 5:31 PM, Kent A. Reed wrote: > Gentle persons: > > Eric said of my recent bout of pneumonia, "[A]nd the antibiotics leave > you like a wrung-out dishrag too, ISTR." > > Truer words were never spoken. > > While lazing about, I visited www.camzone.org for the first time. As I > understand it, the site was created by and most of the blog entries are > written by a person named Daniel who would seem to be German and living > in Brazil (but maybe I was just too wrung out when I visited the site). > I like the way Daniel thinks, the way he writes, and the topics he > chooses to write about. His blog entry "Why PLM is killing the > innovation in CAD/CAM" made me wish I'd known him while I was still > working. The entry on Component Technology should be required background > reading for all of us. > > I was induced to compose this email by his blog entry "Post-processors > --- What you should know about them." I commend it to you. > > My question is, how much of the total (choose your favorite spec > here---RS274D, RS274X, RS274/NGC, LinuxCNC) capability do these > commercial post-processors span? > > A first step in answering this question would be to tabulate all the > codes that can possibly be emitted by specific post-processors. I tried > searching the web but couldn't find any tabulation more specific than > http://www.enotes.com/topic/G-code which speaks of "Fanuc and similarly > designed controls" and is pretty schematic. I looked at the websites of > several CAM programs and see they typically claim to support a number > CNC controller dialects in their post-processors, but that is the color > of a different horse. > > And, yes, I own a copy of the Machinery's Handbook and a copy of Smid's > CNC Programming Handbook should be in my hands soon. > > In my experience with neutral-format data exchange standards in the CAD > world, the variations in the capabilities of various CAD systems led to > standards with large scopes. Despite the resulting smorgasbord of > capabilities, the post-processor writers tended to stick to a relatively > small number of entities within those scopes. We achieved very good > interoperability over a relatively limited span of the total capability > supported by the standards. > > Of course, in the world of CAD, many of the data exchanges occur between > CAD systems, so the pre- and post-processor writers face a different > problem that in our world where we are most concerned about moving data > between some CAM system and some CNC controller. Still, I suspect the > CAM post-processor writers also work with a relatively small number of > entities (e.g., G-Codes). > > At the outset, it seems likely that our O-codes are completely outside > the ken of post-processor writers, but that's just one aspect. Thank you for the pun.... -- although I'm not a post-processor writer.
Ken > > Any thoughts? > > Regards, > Kent > > > ------------------------------------------------------------------------------ > Virtualization& Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
