Talk:IGES
From Wikipedia, the free encyclopedia
Contents |
[edit] CAD/CAM Interoperability
[edit] Introduction
Part of the problem with CAD/CAM interoperability is that vendors use different internal representations for geometry. For example, Vendor A may represent a circular arc as the 2D coordinates of the center point and the two endpoints of the curve, with the implicit understanding that the curve is drawn counter-clockwise, accompanied by a matrix representation of the plane on which the three points lie. Vendor B represents it as the 3D coordinates of the endpoints and an arbitrary midpoint on the curve, drawn from the first (Start) point to the third (Terminate) point through the midpoint, which is not necessarily in a counter-clockwise direction. Vendor C does it a third way, etc. (They may not even use the same name for a "circular arc".)
In one case, the Center point is given explicitly, and in the other case, it must be derived computationally. IGES defines a representation for a circular arc that may be more like one vendor's native representation than another's, but neither vendor has to know anything about the other vendor's representation to be able to read a CIRCULAR ARC entity from an IGES file, or to write one in IGES format ... someone will either have to calculate a Center point when it writes the entity to the IGES files, or else use a matrix to position the circular arc in 3D space when it reads the IGES file.
This is a fundamental rule of Product Manufacturing Information (PMI) translators, even when a neutral format like IGES is used ... either the import side or the export side is going to have to do some extra work to read or write some of the entities, and if you're lucky, it's only half of them.
[edit] Donut/Hole Problem
There is something called the Donut/Hole Problem in manufacturing, which occurs when you use a circle to represent a hole in a surface ... do you mean to remove the material inside the circle (leaving a "donut" shaped part), or the the material outside the circle (leaving just the "hole"). In the Right Hand Rule, your upwards pointing thumb represents the Z axis, and curling your fingers moves them in the direction from the X axis to the Y axis. The rule is that material to the right of a curve is removed, so the answer of which part to keep depends on which direction the circle is drawn, clockwise or counter-clockwise.
Vendor A might generate IGES files so that all circular arcs are counter-clockwise when viewed down the Z axis, but some of them might have been originally created in the opposite direction, and that caused a problem for users of Vendor B's system, not in the display of the part geometry, but when they tried to run CNC software to actually cut metal from the translated part representation. These kinds of "oversights" in the IGES standard (an attempt to keep it from being too restrictive) were one cause for the many versions published over the first decade of its life cycle.
The IGES Committee established a Recommend Practices subcommittee that produced the Recommended Practices Guide, informing translator implementors of pitfalls discovered by vendors and users. Some of these led to Request for Change (RFC) submissions to the appropriate IGES subcommittee (Drafting, Geometry, Electrical, etc.), and if approved by a general ballot, they became an Edit Change Order (ECO) for inclusion in the next published version of IGES. As soon as the ECO was approved, users could require them in a Request for Purchase (RFP) or a Purchase order, although many vendors had already incorporated the updates in beta test software released even before the RFC balloting phase.
Early versions of IGES did alright for simple 2D manufacturing operations, but as solid modeling became more common, a problem was discovered in the way IGES defined trimmed surfaces, or the 3D Donut/Hole Problem.
Imagine a sphere, represented as a parametric surface. Cut it with two planes parallel to the equator. Do you keep the area around the equator and discard the areas around the poles, or the other way around? The early IGES representation, using the TRIMMED (PARAMETRIC) SURFACE (Type 144) and CURVE ON A PARAMETRIC SURFACE (Type 142) entities, lacked sufficient information for systems to be able to correctly read the data from IGES files they wrote themselves. "That's not a bug, that's a feature!"
After a year's work in the IGES Geometry subcommittee, vendors and users had tested and agreed upon the BOUNDED SURFACE (Type 143) and BOUNDARY (Type 141) entities, which were quickly approved by RFC ballot, and publication of the next version of IGES was delayed until the ECO could be included. (Your humble friend and narrator was sent to Europe by his employer twice in six months to explain to the Vice-Presidents of Engineering at Audi and FIAT why they could not have what the salesmen of our CAD/CAM system had promised them, because the problem was with the definition of the IGES entities, not our translator, and that withholding payment from us was not going to make it happen any sooner.)
[edit] Foreign Language Support
The IGES Committee was quick to respond to these kinds of errors and omissions. Due to its growing international popularity (several countries, including Australia and the U.K., adopted IGES as their own National Standards for PMI interoperability), support was added to the TEXT (Type 212) entity to support the ISO 8859 (Latin-1) alphabet for European characters. In the next published version, IGES added support for the JIS encoding for Kanji (漢字) as double-byte characters (JIS-6226), allowing members of the Japan Automobile Manufacturers Association (JAMA) to exchange part models with their American and European partners without loss of the Kanji text.
The last version of IGES was delayed to include Manifold Solid BREP Object (MSBO) geometry to supplement the older (and not very widely supported) Constructive Solid Geometry (CSG) entities. The MSBO entities construct objects from vertexes, edges, faces, and shells in a hierarchy that preserves the geometric, parametric, and topological relationships between the components.
In spite of these improvements, some vendors only support the older versions of surface and solid representations in their IGES translators, which means that other vendors and users are forced to support these legacy entities as a concession to interoperability. Although a few entities in IGES were marked obsolete and moved to an appendix, they are inoperative only as of a certain version of the standard, and there are warehouses full of IGES files conforming to earlier versions that will have to be readable at a future date.
[edit] IGES Flavoring
This has led to "flavors" of IGES files that reflect which vendor's system generated them, or which system is the intended recipient. There was a serious bug in the very first Applicon IGES translator ... a programmer confused the row/column order for matrices defined in IGES with the order of the programming language they were using. (FORTRAN and the C programming language use different orders of rows and columns for arrays, i.e.., what is a [3,4] matrix to one is a [4,3] matrix to the other.)
Since the MATRIX (Type 124) entity is used to orient all entities represented by 2D coordinates (circles, conics, text) into 3D model space, as well as SUBFIGURE INSTANCE (Type 408) entities, when the Computervision (CV) IGES translator read an IGES file from the Applicon translator, the results looked like an explosion had occurred, with pieces of geometry randomly dislocated.
The developers at Applicon never saw the problem when they read their own IGES files, because they reversed the rows/columns on the matrices again, which restored them to their correct values. But they got the same "exploded" parts when they read Computervision's IGES files, because they were reading the matrix incorrectly.
There was a lot of finger pointing, because each vendor could read their own files, but not the other's. The developers at CV thought that the error was their's, and so they also swapped the rows and columns in their translator. After CV changed their translator, someone discovered that Applicon should have been the one to change, so now two vendors were creating bad IGES files.
Unfortunately, a lot of users had created IGES files using those early translators for as long as six months before it was corrected, and a few users delayed the upgrade even longer, so two flavors of IGES files are "Applicon: pre-1981" and "Computervision: pre-1981" ... each translator had to recognize its own legacy files to correct the problems caused by the earlier versions, and to protect their users from bad legacy files created by the other system. As other vendors implemented IGES translators, they also had to contend with these two flavors of legacy files.
[edit] Further Thoughts
Although there is currently no public domain or free open-source software library for reading and writing IGES files, some work was done under a contract from NIST in the 1990s to create a Web based IGES file viewer. Perhaps there will be a GNUiges library someday, because there are IGES files in storage from over 25 years ago, and someone may want to read them 25 years from now to create replacement parts for airplanes, vehicles, and ships that have been put into mothballs in some bone yard.
[edit] IGES 5.x is available in PDF
Last night, I had an epiphany ... I spent a few minutes with Google, downloaded MiKTeX, a free DOS based LaTeX => PDF system, opened a DOS window, went to the directory D:\WebSites\IGES5x\ARCHIVES\VERSION5X (which contains version6.dvi) and typed:
-
-
- dvipdfm version6
-
The next thing I knew, I had a PDF file of "DRAFT v6.0 1998-01-05" ... the only thing missing was the figures.
All I had to do was take the LaTeX files for that version and change "Version 6.0" to "Version 5.x", reintegrate the figures (some of the X-files will be in color), and add the 39 supplemental TEX files I sent to the IGES Editor on 1998-08-21 ... note that these files have been on the Web since 2001-05-30.
Next I copied the directory with the 1998-01-05 TEX files, renamed a few, did some changes to 5 style files, made PostScript files from the 154 IGES figure files, and typed:
-
-
- pdflatex version5x
-
Please see http://www.IGES5x.org/archives/version5x/ for the PDF version of "DRAFT v5.x 1999-01-12", complete with the Table Of Contents, List Of Figures, and the figures ... plus, all of the sections and figures are hyperlinked.
So, let us hear no more talk of IGES 6.0 ... after a decade of use, I have updated the Web based IGES 5.x from the 1992-01-26 draft to the 1999-01-12 draft as a 732 page PDF document ... it's 4.3Mb, so it takes a while to download, but man, is it ever worth it! --Dennette 16:06, 16 June 2006 (UTC)
