lost in translation30 Nov, 2003 By: Don LaCourse
This month's Modeling column is dedicated to Mark Boucher, an applications engineer with Mitutoyo America in Charlotte, North Carolina. Mitutoyo designs and manufacturers CMMs (coordinate measuring machines) and develops a CAD product called Mitutoyo Computer-Aided Technology that ships with its CMM machines.
Mark wants to know how data is lost during IGES translations and whether the accuracy of the part is significantly altered during the process. Because this month's focus is on data exchange, I thought his questions typify the issues that all users face when using neutral file formats to exchange data.
Neutral-format data exchange standards such as IGES and STEP are extensive in structure and scope so they can support a variety of disciplines-MCAD and AEC are only two among many. In the process of neutral-format data exchange, a 3D model file is translated from the native CAD format of the sending system to an IGES or STEP file. The receiving system then translates this file into another native CAD format (figure 1).
The process involves extensive entity mapping. The sending system maps native entities to supported neutral entities. The receiving system then has to map the neutral entities from the IGES or STEP file into its own native CAD entities. Sometimes this entity mapping
Figure 1. I imported this IGES file from one system into a different system, and then back into the original system to see if any data was lost.
Also, because of the size and scope of the standards, MCAD systems support only a subset of each. While System A may support entities a, b, c, d, and e, System B supports only entities a, c, and e. When this happens, System B ignores entities b and d, and the data is lost (figure 2). This is not to say that data is lost due to nonsupport during every translation. It's most likely to occur when the two systems are fundamentally incompatible (such as between a high-end and a low-end system) or when the receiving system is outdated.
Figure 2. Each CAD system supports a subset of the IGES standard. The entity types that both systems support are mapped from the sending system to the receiving system. Other entities within the subset may be ignored.
There are many ways that data accuracy can change. Starting from the native sending system, what you see on the screen is not necessarily what is in the 3D database. 3D modeling kernels can force geometry to connect or treat it as if it connects, even though it doesn't. Neutral-format data exchange exposes these inconsistencies (figure 3).
Figure 3. 3D modeling kernels can force geometry to connect or treat it as though it connects, even though it doesnt. Neutral-format data exchange can expose these inconsistencies. Note: The conditions portrayed in this figure are enhanced for better understanding.
Many mechanical CAD applications today are very strict and require geometry to be healed before they add data to the database. For example, duplicate vertices must be removed and faces extended and trimmed to form new edges to eliminate gaps (figure 4). For many systems, all geometry is stored as NURBs. Primitives are all polynomial definitions converted to NURBs. During the healing process, surfaces may be extended to catch trim loops that are defined off the surface.
Figure 4. A receiving system can automatically perform topology healing when it opens a neutral-format data file. This example illustrates how healing extends and trims faces to form new edges (see window C), eliminating gaps. Note: The conditions portrayed in this figure are enhanced for better understanding.
Large deviations typically originate from the on-screen issue shown in figure 3. Geometry can also be malformed by defining coincident intersections or gaps with neighboring geometry. The receiving system must clean all of this up in its attempt to produce a valid part file. Sliver surfaces are particularly difficult because they are used by the sending system to patch gaps in the part even though they are below the sending system's registered tolerance (figure 4, window B). These cases can also be healed by extending surfaces and re-intersecting with neighbors.
On top of this, the receiving system must deal with neutral data files that don't conform to the specifications-trim loop curves out of order, reversed, not matching end to end, missing geometry, and so on. You may also run across hand-edited neutral data files that are missing large sections, contain control characters, and so on. Some systems do a very good job of identifying and healing these anomalies on the fly.
CLEARING THE AIR
I hope this discussion clarifies some confusion about data loss and accuracy issues related to the exchange of neutral-format data files such as IGES and STEP. I can't stress enough the importance of interoperability testing to bring potential problems to light before depending on neutral format data exchange for production purposes.
If you uncover problems with your system's translators, be sure to submit a bug report to your application vendor and if possible include relevant error logs and neutral data files. You can initiate improvements to your application. Don't be afraid to let your vendor know about any problems you experience. Users have a strong voice and vendors do listen.