Working with Imported Data from Other CAD Systems
The previous sections of this Primer have assumed that the data is all created and utilized in one CAD/CAM software system. This simplifies matters because the data is in a form fully understood by the system and compatible/consistent with the numerical techniques used in the system. Things get significantly more involved and potentially unreliable when data from CAD/CAM system A is to be used in system B, especially if the incoming data is to be a parent leaf in a part history tree and if this part is to be referenced as a parent by other children parts.
Often the data is received from the originating CAD/CAM system in a standard interface file format such as IGES (or STEP or VDA). Some background on what then happens or needs to happen:
- The surfaces and edge curves for the part are read from the IGES
file. Hopefully the receiving system can store the curves/surfaces in
original form and not have to map to another form -- this is today usually
not a problem since most all systems handle non-uniform rational b-splines
(NURBS) directly.
- The first challenge is that if the geometry was modeled in a surface modeling system (rather than solid modeling system), the end user probably took no care to assure that surfaces met without gaps or overlaps (since surface modelers don’t themselves assure that the quilt work can be “stitched” into anything).
- Each edge curve is compared to its neighboring surfaces to see if
it lies on both of those surfaces within a numerical tolerance.
- For planar surfaces there is no numerical consideration because two planes intersect exactly at a straight line.
- For a plane and a cylinder we can get a circle or ellipse as the exact intersection. Planes and cones intersect as conic curves (circle, ellipse, parabola, hyperbola).
- But for anything much more than these trivial cases, the problem gets very intriguing (at least for mathematicians) very fast.
- The end effect is that all modelers compute the edge curves (or sometimes called intersection or trimming curves) to within some numerical “tolerance” of the anticipated precise value.
- One approach is to force the user to interactively re-intersect the
disconnected surfaces (where edge curves do not lie on their neighboring
surfaces within tolerance) and resolve gaps and overlaps interactively. This
is tedious but is often the only way.
- Software vendors have tried to automate the cleanup of such messy
geometry:
- One approach, usually unacceptable, is to merely loosen the
tolerance in the receiving system and therefore allow a sloppy fit to
nonetheless stitch together. This can have very adverse effects when
downstream algorithms try to “slice” the quilt work… as is
effectively what’s done when drawing section views are cut, mold bases
are split, or tool paths are generated on the part.
- Another approach is to provide partially automatic routines
that, with user input and steering, search out “section loops” that
span the gaps (numerical and geometric) and remove surface overlaps.
This effectively “moves” the edges to the underlying surfaces.
- Another approach is to try to stretch the surfaces (by some
form of refitting; by some systems called “zip gaps”) to meet the
defining edges. A danger here is that the resulting surfaces may be ill
conditioned (and explosion of file sizes is a symptom of this), i.e.
have undesired ripples or creases… again with very adverse effects
when downstream algorithms try to “slice” this quilt work.
A brief digression into some special case surface types:
- One approach, usually unacceptable, is to merely loosen the
tolerance in the receiving system and therefore allow a sloppy fit to
nonetheless stitch together. This can have very adverse effects when
downstream algorithms try to “slice” the quilt work… as is
effectively what’s done when drawing section views are cut, mold bases
are split, or tool paths are generated on the part.
|
|
|
In the case of "from scratch" modeling of native geometry (as opposed to data import) in a surface or solid modeling system, the software will generally prevent or warn the end user if the user is modeling in such a way that either a self-intersecting surface or creased surface would be generated. This is done because of the likelihood that some downstream operation will need to "slice" the geometry and the mathematics of slicing self-intersecting or creased surfaces is generally avoided because of numerical instabilities. Strictly speaking the rippled surface (as long as it is not self-intersecting or creased) would cause no real mathematical problems although the ripples themselves may not reflect the user's desire for surface fairness.
But if the software itself happens to generate self-intersecting and/or creased surfaces as it seeks to auto-stitch imported geometry, we could indeed expect significant (and undesirable) instabilities (including crashes) in downstream slicing operations. The introduction of surface ripples would not necessarily cause software instabilities in slicing, but would result in inappropriate and overly complex NC tool paths.
- Some specialty software companies (e.g. ITI, Theorem) have as their primary business developing software to attack this difficult problem of “healing” imported geometry. And their solutions are well short of fully automatic.
So the bottom line is that using imported data from another CAD/CAM system can be a difficult task. User intervention is usually involved to arrive at a reliable model that cleanly (and repeatably) stitches together to bound a solid object that is numerically consistent with other part features and reference parts that we desire to be associative children of the imported data. And the stitched part must have clean geometric surfaces that can be successfully "sliced and diced" to support all the necessary downstream operations, e.g. mold splitting, drawing section views, and NC tool path generation.
™