A Relationship Matures in CAE

By John Wedrychowski

In design and manufacturing, the debate about the relative importance of design versus manufacturing continues. Some say that without design there would be no manufacturing, and others say that the real action takes place in the realm of CAM. We can, however, agree that both of these environments need to proactively coexist.

The relationship between CAM and MCAD, or CAE or CAX, has passed through various stages over the years. As engineering organizations have sought to gain maximum benefit from both realms, the relationship has fluctuated between harmony and discord. By looking at where this relationship stands now, and where it is going, some light might be shed on CAM’s connection with new visualization formats such as JT and 3DXML.

CAM came on the scene with the arrival of the intelligent machine tool controller and highly specialized programmers who could read drawings and translate the machining requirements into code that could be typed into a system. These engineers needed both a deep understanding of the desired end product and expert knowledge of the capability of the machine tool. These two aspects combined to produce a program that resulted in something actually being cut. The only input from the MCAD system came via the printed drawing read by the part programmer.

Early on, CAM programs were created on either punched cards or tape that were then fed into the controller. The machine tool programmer developed great expertise balancing the commands at hand with the command cycles built into the machine tool. Add to that the birth of CAM technology and something of a gulf appeared between manufacturing and design. MCAD systems “didn’t understand” either the machine controllers or the critical processes in cutting metal, and yet CAM could work just fine from the drawing.

Even though there was rapid development of the technology that brought physical communication between MCAD and CAM systems, the gap in understanding remained. CAM and MCAD grew closer and closer until, finally, a cable and the RS-232 protocol actually linked them.

With the arrival of the Internet and Ethernet, the barriers to communication were potentially all removed, but still CAM and MCAD could not “talk” to each other. Cleary, this state of affairs could not last, and as a response to user demand, two different solutions began to appear.

One of these came from MCAD system vendors who realized they could expand their market by embracing manufacturing technology. As a result, they developed their own CAM systems to operate from the geometry already created by the design engineers. These software tools enabled manufacturing engineers to create things like fixtures, fittings, and parts from within the same environment used by the MCAD operator.
The great benefit of this approach is that there is no need to translate the geometry between two systems, which completely removes the potential problem of data incompatibility. On the other hand, the great challenge was to find software specialists who had sufficient understanding of the manufacturing environment to be able to create the ideal set of software utilities for manufacturing people to effectively do their work.

The second solution approached the challenge from the opposite direction. Vendor companies that had been working in the manufacturing environment from the beginning decided to apply themselves to the creation of niche manufacturing systems. These looked like MCAD systems, but their whole reason for being was the creation of manufacturing toolpaths. Sometimes they tried to create the best of both worlds: on one hand having a graphical interface through which the user could see components, fixtures, and graphical tool paths, as well as having the ability to create a text file tool path if desired. The vendors of these systems had to overcome the challenge of receiving design data in a different format than their own graphical database, but this is largely achieved. Many of the suppliers of niche manufacturing systems now have a range of MCAD import utilities that work very well.

These MCAD systems have different origins and the differences in the way they operate still exist, but both approaches have worked and now the user has the choice of investing in closely coupled CAD/CAM or specific MCAD and a specialty CAM applications designed to meet the needs of a specific job, such as surface machining, flame cutting, or punch press operation. Things are made even easier because different CAM and MCAD systems can now also communicate via standard translators or direct translators often created by niche translation vendors.

So that’s it, right? The merging of MCAD and CAM has happened, end of story, and they lived happily ever after. Not quite. Life is not that simple, and some recent developments in geometry formats have implications for CAM systems and the source geometry they import. This means some CAM systems must receive data from a different direction, and they might require a whole new range of interfaces.

As the CAE (computer-aided engineering) environment has been evolving, a gradual merging of systems has taken place in the direction of business applications. There has also been a migration of data from engineering toward a holistic business system that supports engineering organizations, giving rise to PLM (product lifecycle management) systems that require new data formats developed specifically to meet their criteria.
At first it seemed that all that was required was a “light” view of the drawing, but it has quickly become clear that the various needs of the greater business environment also include light 3D models, product manufacturing information, the ability to measure accurately, and the wealth of data (i.e., weight, center of gravity properties) usually reserved for MCAD users. The world of design manufacturing is now also changing, with a number of large companies implementing manufacturing definition processes based upon 3D annotations and dimensions. In turn, these representations are being translated into visualization formats—such as JT—to enable the data to be used by non-CAD engineers. These new formats have become so sophisticated that they are on the verge of playing an entirely new role in the PLM world.

Each of the three major PLM vendors have taken on a different role. PTC has a dataset that feeds ProductView, UGS does the same for VisMockup with JT, and Dassault Systemes has announced plans to implement 3D to implement 3DXML.

Make no mistake, the battle for the high ground is on, and we can expect to see a great deal of action around the applications that comprise this broader business environment.

The new competition is having a direct impact on the world of CAM. Originally a UGS system, the JT format gained rapid acceptance for its initial application in visualization of 2D and 3D designs, but that changed very quickly. The JT Open initiative has put the JT format firmly into the public domain, and a number of members of the JT Open Initiative (including several major automotive OEMs) plan to use JT as a means of exchanging data with members of their supply chains.

This is where the future is going to become interesting:

• If the supplier manufactures components, will it be possible to manufacture directly from the JT format in the same way that it has been possible from the MCAD format?
• Is it possible to apply toolpaths and to create part programs for machine tools?
• Is it going to be necessary to request MCAD models, and if so, which is the master, MCAD or JT?

These three questions are beginning to build and though the answers are not yet clear, it is possible to work with JT in an MCAD system outside of the UGS suite of NX and I-deas products. Currently, this relates to the CATIA user, for both versions 4 and 5 and also for users of the PTC ProductView application. Theorem Solutions has developed a translator that takes accurate geometry from the detail held within a JT file and creates a real CATIA V5 or CATIA V4 model or assembly that the CAM user can work on.

Theorem plans to create a family of JT to MCAD translators for a range of MCAD systems, and many of these will be able to pass the attendant benefits on to manufacturing environments.

Time will tell whether the JT format is to be endorsed by standards translators such as STEP or IGES, and the same applies as to whether the vendors of the niche CAM systems provide direct interfaces to their own formats.

Once 3DXML becomes more widely deployed, similar questions to those posed above will be asked again, and the response is likely to be as optimistic. If 3DXML becomes a means of exchanging data between OEM and supply chain, and if there is a strong requirement to manufacture from it, sooner or later someone will do it.

CAM and MCAD have been getting on well for years now, and it appears a new bond in the relationship will form. The existing methods of data exchange are unlikely to disappear any time soon, if at all. Perhaps a gradual incorporation of these new formats and methods will supplement the existing methods in a world where they can happily coexist.

John Wedrychowski is the business partner manager for Theorem Solutions. He has more than 20 years of experience within the CAD/CAM industry. You can contact him regarding this article via e-mail by clicking here.

Company Information

Theorem Solutions
Loveland, OH

Dassault Systemes
Paris, France

PTC
Needham, MA

UGS Corp.
Plano, TX