These people include:
• The software developers on both sides of the exchange (readers and writers),
• The CAD operator who is initiating the exchange,
• The CAD operator on the receiving end of the exchange.
If all these parties are wide awake at the appropriate time, IGES, STEP or any of the other recognized standards can produce excellent results. If any one of them is not fully conscious when they are supposed to be, the results can be atrocious.
Another way of stating our bumper sticker is: "Data communication requires human communication." Before getting into the technicalities of the data exchange standards, let's look at the roles and responsibilities of the people involved.
Software Developer (Writer)
Obviously, the first thing a competent data exchange software developer must do is read the specification. Obvious as this may sound, it is amazing how often this step is omitted. Frequently, IGES files are produced by major CAD vendors that violate the specification. Some major systems are guilty of this in regard to their trimmed surfaces.
The second step in organizing an accurate and efficient translator is to decide how best to map the CAD system's internal entities into the array of entities available in the standard. For instance, a surface may be written out as either a parametric spline (IGES entity 114) or a B-spline (entity 128). The 114 is appropriate to systems based on cubic splines, the 128 for more general splines. Invariably there will be some idiosyncrasy of the CAD system that is not fully accommodated in the specification. In these cases, an intelligent compromise must be made. For example, one CAD vendor's view restriction allows an entity to be seen differently in different views. On output to IGES, the system generates lots of redundant data to accomplish this.
The third thing required of the software developer is much more difficult and is much easier to understand when it is omitted. Developers must consider not only how their own systems' entities should be mapped into the available format, but also how they should be presented so as to be understood by receiving systems. For instance, a receiving system may expect a certain level of smoothness or continuity in its surfaces. This is almost never considered by the writer and hence leads to the bad reputation of the standards. But remember, it's not the gun pulling the trigger.
CAD Operator (Sender)
Now consider the responsibilities of the CAD operator initiating the exchange. Ideally, the data being sent should be organized so that the receiving party will understand what they are getting. For instance, if a single radius has changed in some humongous part, the CAD operator should make a unique level containing only the changed circle, assign it a noticeable color (red) and then provide some human-readable notes explaining how this affects the overall job. Instead, most often, the operator simply sends out the latest revision of the design in its entirety and leaves it to the receiver to figure out what has changed since the last release.
Software Developer (Reader)
Once again, the software developers should understand the spec, understand the mapping of the spec into their own system and, most importantly, realize that other systems are not identical to their own and may therefore require some adjustments as the data is read. Surprisingly, this last factor is considered by readers more often than by writers. This may have something to do with the marketing of CAD systems which invariably involves a benchmark in which data must be introduced from some other system.
CAD Operator (Receiver)
Unfortunately, the receiving CAD operator is very much at the mercy of the preceding cast of characters. If the software developers were asleep at the switch and the initiating CAD operator did not clean up the data prior to transmission, there is precious little the receiving operator can do (although some tips are presented here).
State Of The Standards
Now for the technical bit. IGES is a standard almost 20 years old, now in its sixth revision. Its successor is known as STEP (Standard for Exchange of Product information). After release 5.1, IGES was supposed to metamorphose gracefully into STEP 1.0, like a caterpillar into a butterfly. But it hasn't worked out that way. There are simply too many active IGES users and too few STEP users to shut IGES down completely. So they both exist side by side (two caterpillars).
Now what is IGES; what are its limitations; what is STEP; and what's the difference? IGES is a format designed by a committee. Think of it as government form, like IRS form 1040. Just like a form, there are spaces in which values can be entered. These are then interpreted automatically by the receiving system, just as your income and deductions are interpreted by IRS computers. The IGES format includes basic geometry like curves, surfaces and solids, as well as drawing information like dimensions. In addition, there are grouping or associative entities like levels.
The biggest criticism that can be made of IGES is that there is more than one way to describe some entities. For instance, a cubic spline may be presented as IGES entity 112 or 126 or even as a polyline of points (entity 106). This creates an easy excuse for vendors who can point to the letter of the law and say they are IGES compliant when they support one of these forms, but not the others.
The STEP committee, on the other hand, has tried to make their definition "canonical," or unique. It too contains specifications for curves, surfaces and solids (part 42, AP203) as well as drawing information. It fact, as of IGES 5.1 and STEP 1.0, there is very little difference between the two entity sets. However, STEP has the ambition of handling far more information about a product than did IGES. It seeks to embody any attribute (like surface finish, for example) that may be associated with a product.
Given this greater ambition, is STEP more likely than IGES to succeed in providing accurate, efficient data exchange? We go back to our original statement borrowed from that NRA bumper sticker and our cast of characters. Is there anything inherent in STEP that will force the people involved in the process to be more alert? Perhaps, because unlike IGES, STEP is an international standard (sanctioned by the International Standards Organization) and could in theory be enforced by the new World Trade Organization. Only time will tell.
Common Sense On Data Exchange
1. Before you accept a contract that stipulates CAD data exchange, ask for a representative benchmark. Read it into your system and note what happens. You should not have much trouble with raw spline curve and surface geometry (entities 126 and 128).
2. Pay special attention to trimmed surfaces (IGES entity 144). Frequently the trimming curves were misplaced or are self intersecting. Make sure that they not only appear on your screen, but are usable (for NC or other applications).
3. Be sure to look for curves or lines that extend beyond their required limits.
4. Check the organization of the data, especially in terms of how engineering changes will be presented. Make sure the data is organized on your system in the same groupings as on the originating system. Otherwise, you will spend hours cleaning up each release.
5. Glance at the drawing information. Most likely it will have text and dimensions misplaced. Ask for a print.
6. If any of the above leave you with a reason to doubt the process, look into a direct translator. A direct translator extracts the data from one CAD system's data base and deposits it directly into another. At least two out the cast of characters mentioned here, the software developer responsible for reading and the developer responsible for writing the data, will be directly answerable to you.