CAM – A great invention

Hi folks,

Well, now I feel that the second post is as hard to write as the first one. It’s easier to write about my history than writing about a thing I’m sure lots of people reading this now knows better than me: CAM. As I said in my previous post, I fall in love with CAM a decade ago… in the company I used to work there was a guy who was in charge of the post-processors and softwares. From my first contact with the expression “post-processor” on I started to dream about becoming a post-writer myself too… wow… many things happened after that time… 8)

The importance of CAM in the modern industry

Well, the fact is that CAM is behind nearly everything we have in the modern life. CAM takes place in turning into reality nearly every industrial process. It does play a critical role in how competitive the manufacturing companies are, although many of them do not promptly realize this. Some don’t even know where CAM plays a key role in their processes. Manufacturing, in a great extent, drives the world’s economy. And CAM is a big part of this mess.

CAD, the predecessor and foundation of CAM, is essential, no discussion about that. But equally important is to perceive that in the modern days, a CAD model in a fancy 24″ display is nothing but an intangible figure. Ok, you could say that you can generate a 2D drawing to allow the part execution in a conventional, machine… but if this was your point, you wouldn’t be here reading an article in a CAM blog. ;-)

I don’t intend, for now, to go to the roots of CAD/CAM, but basically say that as soon as CAD turned into a reality, some geniuses realized that the same equations and know how could be somehow adapted and used to control machine tools. The automated machine tool project at MIT also realized that as soon as the machine hardware was operational, then they would need to program it using computers as well. One of these freaks was Patrick Hanratty. May God bless him.

In the sixties, seventies and eighties lots of things were R&D’ed as the computer hardware evolved. This is a great thing about CAM: As the hardware evolves, the limitations are overcame, with a few exceptions.

CAM and the current hardware

Well, I skipped the list of inventions and innovations in CAM in the past 30 years as it’s not my aim to go through all them in this post. There was a very nice set of documents at http://www.cadhistory.net/ with an excellent coverage of this period, but the link is broken now. If someone finds it again on the web, please let me know and I’ll update this post accordingly. For now, I’m using Wayback machine to make it available here: CADHistory.net (Not sure how long this will work though) – Thanks to Evan Yares for this tip!

Back to the point, I could say that the doors for decent performance in CAM were opened when the architecture of PCs and UNIX machines (UNIX is a O/S so this is not the proper term, but it rings the bells I want)  started to double the number of bits for that particular architecture. Due to the legendary reliability and performance demands, the UNIX platform and its hardware dominated the CAM arena for decades. In the shadow of UNIX, CATIA, IBM, PTC, UGS, Computervision and many others ruled the game for high-end CAM, which was a must for big parts and applications consuming big amounts of RAM. In the meantime, smaller systems such as Mastercam were conquering the mid-end market for PC (2D) based applications. The problem is that back then two things were always taken to the edge: Memory and processing power.

One way or another, storage, graphic cards and hardware were extremely expensive, and as such, performance never was the best thing in your day. Thanks to Intel and AMD, who today are part of the very few companies that are really inventing the future and innovating since the day they opened their doors on (See this interview with Mike Payne – Founder of SolidWorks / PTC / SpaceClaim) , we got the 64 bits architecture in the PC (It was available since the middle of eighties on UNIX), which came in a moment where storage and memory were cheap. That was the perfect marriage and CAM could finally address the longstanding performance issues.

64 bits – That’s cool!

I use to associate the 64 bits fever with the MMX fever Intel marketing used to leverage Pentium sales years ago. MMX was essentially instructions of the processor that could enhance and deliver better multimedia capabilities – There were only one problem with that: Programs should be rewritten to take advantage of this technology and that the sales rep didn’t say. Intel sold millions of processors due to this marketing move. I really wonder how many products were really rewritten to use MMX back then…

So, I make an analogy to the MMX fever when we talk about 64 bits in modern CAM – Looks like that many companies are working towards this, but the truth is that with a few exceptions, nearly everyone is porting old legacy code and trying to adapt them to use 64 bits architecture. Porting old legacy code does not mean it will be efficient, as the core algorithm is still the same invented decades ago, so they are basically recompiling the source code using 64 bits compilers… in computer programming, the term “word” is a small group of bits which are handled simultaneously by processors of a particular architecture. The size of a word is thus CPU-specific. If I put this in a very shallow manner, we could say that to port a code to another architecture, all you have to do is to recompile that code in a similar hardware with a specific compiler, without changing a single line of code (Ok, maybe some #Pragma statements for the experts reading this)  – Yes, is not that simple, but that’s the essence of the thing – Porting does not make your applications efficient, and to be honest, it may cause the totally inverse: Worse performance.

If you want more technical details, please read this nice article written by a CAM developer who decided to start fresh with 64 bits architecture and some of the problems with the current systems that are being exhaustively ported over the last three decades.

Porting, porting, porting… Ugh… :-?

Well, financially speaking, porting is great because the financial resources put into the product rehab are lowered at a great extent. And that’s the very reason why most companies are porting and not R&D’ing as they should. The problem is that some major players out there have many lines of code (Millions) to rewrite and a freak despair to launch their products as fast as possible in order to capitalize, so they caused the phenomenon we have today: We’re using old technology wrapped in a very fancy cover. Our maintenance dollar goes to keep proven code, and that’s the beauty of the software industry – They have to do big investments in R&D when they start, but after that… it’s all about increasing the size of their bank safes… This money is going to their marketing sharks and with this we have a vicious circle where companies making a living in manufacturing are constantly financing marketing and advertising instead of innovation.  And that sucks!  :cry:

Software is a good business because:

  • No Product Shipping / No Inventory Needed
  • Auto-Pilot Business 24/7
  • High Income Potential

So, the bad news here is, with a very few exceptions which I unfortunately can’t share because I don’t know, your CAM software was ported at least once. You’ll have to live with that. But don’t worry, I’m sure the software I use today was ported much more than yours… mrgreen

The thing here is to determine how much R&D a vendor is putting on their product and avoid the common pitfalls when choosing CAM. That is going to be one of my next articles.

Parallel processing – You are going to love it

When the PCs started to offer cheap memory and the 64 bits architecture, an ability of UNIX based hardware was then available in the x86 too: Parallel Processing.

Parallel processing consist in splitting the toolpath computation in multiple cores so that the algorithm uses the full potential of the current hardware, thus, reducing the time it takes to get the job done. Moldmakers use to love this and I’d say that a company in this segment is no longer able to compete in the global market without using a CAM system with this technology.

Parallel processing is something that is not automatically inserted in the code when you port it. Many companies prefer to keep a safe distance from this technology as its usage would demand a total rewrite of their algorithms, what some companies like PTC are not doing yet. The interesting is that their direct competitor Siemens PLM, former UGS, already adopted this in the current versions of Unigraphics NX. This clearly shows me the importance of this technology, no matter how hard it is to adopt it.

The parallel processing technology is so complex and hard to be mastered that often CAM developers struggle to adopt it entirely. But it has proved to be the key element to deliver the demanded performance in the current days - Component technology vendors such as ModuleWorks and MachineWorks already take advantage of this, so are toolpath engines such as Volumill or complete CAM systems like HSMWorks and Delcam Powermill, the last two ones being clear leaders in multicore toolpaths.

This is just in the beginning of the retake in toolpath technology! Wait and see.

Thanks for getting here!

Cheers,

Daniel

12 thoughts on “CAM – A great invention

  1. Interesting blog keep it up Daniel! Aside from parallel processing what other advancements would you like to see implemented into CAM software?

    • Hi Nick!

      Well, in the recent years I’m deeply involved with complex MilTurn machines and because of this I can see the nasty side of CAM these days… lots of complex requirements and outdated / ineffective approaches to deal with them… but one thing that comes to my mind now is what we could name “active stock management” – This is essential for clean and elegant air cut free toolpaths… but unfortunately CAM companies are ignoring this for decades… I think that next CAM era will demand this from the vendors though… my plan for the next articles is to go really deep in requirements and technical information about nearly everything associated to CAM… such as probing, multiaxis, pitfalls, manufacturability, process management, hardware, machine simulation, verification, post-processing, licensing pitfalls, trends, machine design, etc…

      So I invite you to subscribe to CAMZone.org because I’ll make it rock…

      What kind of things you’d like to see here?

      Greetings,

      Daniel

      • I absolutely agree about stock management that is a major issue for me. I struggle with material removal features in Pro E and I wait for the time when a better solution will be implemented. I have had a chance to look at some of Volumills tool paths and would like to know what you thought about their ideas and innovations. What do you think about integration between software packages? What if someday we could easily put together general CAM packages with more specialized Toolpath generators such as Volumill.

  2. Nick,

    I think that adaptive clearing toolpaths are reaching maturity and they are the way to go for massive material removal. But for small parts and production machining, these toolpaths are welcome but not a must. I work in a segment where we barely mill off big amounts of material, so the key there is to have smart approach / departure moves, none air cut, concise control of feedrates and speeds in material transitions, good toolpath linking, fast UI… this is where we need solutions and our current CAM can’t deliver with efficiency.

    About integration of software packages, I think it’s a very good alternative as long as both sides are willing to partner. The problem is when one side does not help the another.

    I’ll write an article about adaptive clearing algorithms such as Volumill and another about component technologies for CAM. Hope we can expand the discussion around these themes soon…

    Keep commenting, very nice to have you here with us!

    Daniel

  3. As a developer of PyCAM – a 3-axis toolpath generator licensed under the GPL – I am happy to say that PyCAM supports parallel and distributed processing: http://sourceforge.net/apps/mediawiki/pycam/index.php?title=ServerMode
    But feature-wise it surely does not compare well with mature CAM packages out there, since the project is still quite young.

    Anyway: using an existing parallelization infrastructure (for PyCAM: Python’s Multiprocessing) and given a well structured code base, it is not too hard to parallelize the toolpath generation. But I guess, code quality and single-thread oriented performance optimizations complicate matters a lot for good old CAM systems …

  4. Pingback: Component Technology – There’s no fun without it | CAMZone

Share your thoughts

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Connecting to %s