3-D CAD TRANSLATION By Matt Heinzen In the 3-D CAD world, translation of data between different applications is a major issue. In an ideal design world, every CAD package would use a single perfect data format, and part designs could be shared seamlessly between different packages with no loss of data, features or design process. In the real world, every CAD package has its own native format, as well as varying abilities to import and export neutral formats and possibly other vendors' native formats. In addition, there are service vendors who have developed custom translators that are capable of translating directly from format A to format B regardless of whether CAD packages A and B contain any support for each other. There are two basic approaches to handling the problem of CAD data exchange: direct translation and the use of neutral formats. Direct translations attempt to preserve feature hierarchies and parent/child relationships, and they are preferred when multiple parties may be required to perform significant editing of a part, especially in the nature of modifying existing features and dimensions. Due to the complexities of feature hierarchies and the differences in implementations across CAD packages, neutral formats only contain the exact geometric definition of a part. Parts exchanged in neutral formats are generally imported into a CAD application as "dumb solids" without individual feature data. An example of a limitation of a dumb solid would be changing a set of four evenly-spaced identical drill holes in a circular pattern into six evenly-spaced holes. In the native CAD format, the user only needs to select the pattern and change the hole count to update the pattern. However, with a dumb solid filling the original holes, extruding new holes may be the only option. The same goes for changing the depth or diameter of existing holes or basic parameters of most other features. While CAD exchange through neutral formats is limited, direct translators carry their own set of issues. The easiest direct translators to use are the ones built directly into the available CAD packages, but translations vary quite a bit from package to package. The most popular package formats, such as Pro/Engineer's *.prt format, are widely supported for import and sometimes export, but translation to or from less popular package formats may only be supported on the end of the less popular CAD system. Solidworks can import and export Pro/E files, but Pro/E neither imports nor exports Solidworks' *.sldprt files. In addition, even if translators are available between two CAD systems, the latest versions are often not supported. If a new version of a hypothetical CAD package named CadXYZ is released with an updated native file format, competing packages will usually not be supplied with an updated translator until their next version (if not later). The new version of CadXYZ will typically be able to export older versions of its own native format, but these files may lack features or data used in the new version. Finally, although direct translations support transfer of feature hierarchies, differences in the representations between two packages may cause some degree of mangling in these structures. To the fill the void in direct translations, as well as bridge the version gaps, a large number of service vendors have emerged with their own custom translators. These services should provide the most complete translations available and work through electronic transfers such as e-mail and FTP, or over physically mailed media. The primary drawback is price: while translators built into already licensed CAD packages are free to use, translation services incur a cost for every model translated. Despite offering the most complete translations available, in some cases, an exact translation between two CAD formats is simply not possible. There are many ways to represent some types of features and most CAD packages do not support every method. This is especially true with packages free form curves and surfaces, and is less of an issue with standard parametrics, such as planes and cylinders. Other information, such as dimensional tolerances and annotations, may be lost or simply not translate cleanly due to the differences in CAD systems features beyond standard geometric entities. In situations where editing of a part is not as important as simple accuracy and portability, such as with input for CNC machining, neutral formats are preferred when native formats are not supported directly. The two most popular neutral CAD formats are IGES and STEP, though others also exist such as SAT and VDAFS. IGES (International Graphics Exchange Specification) is an older format and serves a more general purpose, supporting a wide variety of graphical entities including points, curves and polygons as well as parametric and free-form NURBS surfaces. STEP (Standard for the Exchange of Product Model Data) is newer are designed more strictly for engineering, based fundamentally around solids rather than surfaces (IGES represents solids as piecewise closed surfaces), but is not yet quite as widely supported. Native formats offer simple translation of dumb solids, but even still there are a few pitfalls to watch out for. If two CAD packages use different representations for one type of geometry at some point the representation must be converted, or even discarded (though this is thankfully uncommon), regardless of the type of translation. STEP was designed in part to solve this problem, but no format can completely eliminate all translation issues. The best method for translating CAD data really depends on the specific application. Neutral formats are the simplest and most widely portable solution and generally do a fine job supporting solid models for machining and CMM (coordinate measuring machine) inspection. Direct translators are superior for more complicated tools of any multi-party design process. However, for truly collaborative projects in which CAD data must be continuously transmitted and edited between different locations, nothing will live up to working through a single, common CAD package. Matt Heinzen Data Engineer QC Inspection Services, Inc. About the Author Matt is a Data Engineer in QC Inspection Services' Engineering Department. Before Matt arrived at QCIS, he was an Applications Programmer at the University of Minnesota's Department of Oral Sciences. Matt has a Bachelor of Science in Computer Science from the University of Minnesota. Some of Matt's previous work has been published in the Journal of Dental Research. Comment on this article