tolerance modeling and application programming interfaces - CiteSeerX

0 downloads 0 Views 80KB Size Report
interfaces. 1. INTRODUCTION. Information on tolerances and attributes (e.g., surface finish) of .... from this Forum appeared in the ASME Manufacturing Review,.
TOLERANCE MODELING AND APPLICATION PROGRAMMING INTERFACES Giovanni Moroni Industrial Engineering Department Universitá di Cassino Cassino, Italy Aristides A. G. Requicha Computer Science Department and Institute for Robotics and Intelligent Systems University of Southern California Los Angeles, CA, USA

ABSTRACT Tolerances, surface finishes, and other technological attributes of mechanical parts and assemblies must be represented in product models that support the entire life cycles of the products. This paper describes an experimental tolerance modeler and an associated API (Application Programming Interface) that hides the modeler’s internal details. Our tolerance modeler can be attached to any nominal-geometry modeler through a tolerance adaptor. Two tolerance adaptors, for PADL-2 (a Constructive Solid Geometry system) and for Parasolid (a boundary modeler) are presented. Applications that use tolerancing information can be written in a modeler-independent fashion by invoking the API introduced here. Our approach supports incremental construction of the tolerance model as the nominal-geometry model evolves, and provides archival, persistent representations.

KEYWORDS Tolerances, geometric modeling, solid modeling, adaptors, APIs, procedural interfaces

1. INTRODUCTION Information on tolerances and attributes (e.g., surface finish) of mechanical parts and assemblies is crucial for many activities in a product's life cycle. For example, the selection of manufacturing processes and assembly strategies is strongly dependent on tolerances, and dimensional inspection amounts mainly to checking that tolerance specifications are met. Therefore, modern systems for Computer Aided Design and Manufacturing (CAD/CAM)

must be able to associate tolerances and attributes with the solid models that they use to describe the nominal geometry of parts and assemblies. Representation of tolerances, also called tolerance modeling, is a considerably less developed technology than solid modeling. Today’s CAD/CAM systems typically have rudimentary or non-existent tolerancing capabilities. The current approach t o tolerance modeling in the industrial world favors proprietary systems that are tightly integrated with their nominal counterparts. Interoperability is addressed through proposed standards for the interchange of tolerancing data between disparate systems (Feng et al., 1993). In this paper we take the opposite tack, and describe an experimental tolerance modeler that can be used in conjunction with any nominal-geometry modeler. Our research was motivated by practical considerations—we run in our labs several solid modelers, none of which has good tolerancing facilities—but it has interesting implications. For example, it shows that it is possible for a third-party vendor to develop and market a “universal” tolerance modeler, which can be connected to any of the commercially-available nominal systems through relatively simple tolerance adaptors (discussed below). We think that a tolerance modeler should have the following characteristics. 1. Be independent of the nominal-geometry modeler, as noted earlier. 2. Provide an Application Programming Interface (API) that hides the internal details of the tolerance modeler. In conjunction with an API for nominal geometry this would make it possible t o

write applications that are completely modeler-independent. Of course, modeler independence may carry performance penalties, but these are likely to become less and less important as hardware speeds keep increasing; interoperability is becoming more crucial than raw speed.

through Remote Procedure Calls (or higherlevel services when these become generally available). Application

3. Support incremental construction of the tolerance model, as the nominal model evolves. Forcing users to specify tolerances only after all the nominal geometry has been defined is very inconvenient, and precludes solid-model editing after tolerance assignment.

API

Nominal Adaptor

4. Have representations that are archivable in a persistent repository.

Tolerance Modeler

Tolerance Adaptor

Figure 1 shows the system architecture we advocate. A typical application interacts with both a tolerance modeler and a nominal modeler. Communication with the tolerance modeler is channeled through an API, which provides methods for building and interrogating a graph data structure that represents the tolerance and attribute information. Nominal-geometry dependencies are localized within adaptors. These, in essence, provide a modeler-independent API for solid modeling. Adaptor software is divided into two major components. One deals with nominal geometry, and the other with variational (i.e., tolerancing and attribute) data. Nominal adaptors map the “universal” API methods into modeler-specific procedure calls, and are described elsewhere (Han & Requicha, 1996). Adaptor code is modelerspecific, and therefore a separate adaptor is needed for each solid modeler. The tolerance modeler associates tolerances and attributes with nominal-geometry entities through adaptor calls. As a result, the tolerance modeling software does not have to know which solid modeler is being used. (Note, however, that a tolerance representation cannot exist by itself; it must be associated with a nominal model, and the same tolerance specification for a given part may correspond to different tolerance representations, depending on the specific solid modeler, and sometimes even on the sequence of operations used to construct the nominal geometry in a given modeler.) We envisage a distributed environment, in which an adaptor and a solid modeler are linked together and run as a single process, while the tolerance modeler runs as a different process possibly in a different machine. Communications are effected

API Solid Modeler

Figure 1 - System Architecture The remainder of this paper is organized as follows. Section 2 surveys the literature on tolerance representation. Our approach is based on the VGraph concept, introduced a decade ago (Requicha & Chan, 1986), and briefly described in Section 3. Section 4 discusses the tolerance modeler, and Section 5 the tolerance adaptors. A final section summarizes the paper and presents conclusions.

2. PRIOR WORK The PADL-1 system, developed at the University of Rochester in the mid 1970s (Voelcker et al., 1978), was the first solid modeler that represented tolerancing information. PADL-1’s tolerancing scheme was based on parametric tolerancing, i.e., the specification of allowable part variations through limits on the values of the parameters used to define the part. Similar, but more elaborate schemes were reported in several other publications—see e.g. (Gossard et al., 1988). Representations based on parametric tolerancing do not capture the semantics implied by the current ISO (ISO, 1989) or ANSI standards (ANSI, 1994), which define certain tolerance zones in which an object’s features must lie. Tolerance zones may be described through offsetting (i.e., growing and shrinking) operations, as proposed initially in (Requicha, 1983), or through regions in parameter space (Guilford & Turner, 1993) or kinematic chains (Rivest et al., 1994). Research and development in tolerancing was surveyed at a recent ASME International

Forum. Selected papers from this Forum appeared in the ASME Manufacturing Review, in the December 1993 issue and its successor. A survey of the field was published in (Roy et al., 1991). Typically, the published research on tolerance modeling assumes that a complete boundary representation (BRep) is available, and ignores issues of nominalmodeler independence and application programming interfaces. Static file or database representations of tolerances in a standard format have been proposed by the STEP community (Feng et al., 1993). They are BRep-oriented and

DatumSystem Q Q

assume a complete representation is available prior to tolerance assignment. Procedural interfaces for tolerance modeling were tackled by CAM-I (Consortium for Advanced Manufacturing, International, Arlington, TX), in its Dimensioning and Tolerancing Feasibility Demonstration (CAMI, 1986) (Ranyak & Fridshal, 1988). This work was based on an earlier CAM-I proposal (Johnson, 1985), which also influenced later developments at Arizona State University (Shah & Miller, 1989). CAM-I’s proposed API for tolerancing also assumes a complete BRep is available.

Q

SFeature

Datums

CFeature

AttributeList SFeature

SFeature

AttributeList CFeature

AttributeList

CFeature

AttributeList VEdge

Features

VEdge

AttributeList VFace

VFace

VFace

AttributeList ClassOp Solid

NFace

Nominal Geometry NFace

Figure 2 - VGraph structure

NFace

3. VARIATIONAL GRAPH STRUCTURE The Variational Graph (abbreviated VGraph) structure was proposed in (Requicha & Chan, 1986) to represent tolerancing and attribute information associated with mechanical parts. (It is called “variational” because tolerances define allowable variations from the nominal part; it is not directly related to “variational geometry”, a phrase that in the geometric modeling jargon connotes the ability t o parametrize an object through geometric constraints.) The VGraph provides facilities to express the tolerances specified in the ANSI standards (ANSI, 1994). Their semantics are based primarily on a theory described in (Requicha, 1983, 1993), which attempts t o define mathematically the meaning of ANSI specifications. The VGraph structure is shown diagrammatically in Figure 2, which is explained below. (This version of VGraph is slightly different from the original, 1986 version.) The lowest-level entities in the VGraph are Nominal Faces (NFaces), which are references to the lowest-level bounded surfaces in a nominal model. For boundary modelers these are BRep (Boundary Representation) faces. For CSG (Constructive Solid Geometry) modelers they are the faces of primitive solids. (For basic notions of solid representation see e.g. (Requicha, 1980).) NFaces do not carry geometric information directly. Their geometric meaning is slightly subtle. Suppose that an NFace N in the tolerance representation of a part P refers to a bounded face O, called an Original Face or OFace, in a nominal representation. (OFaces themselves are not part of the VGraph; they live within nominal models.) Then, geometrically, N is the union of the connected faces (abbreviated CFaces) in the boundary of P that intersect the OFace O. (A CFace is a maximal, connected subset of the boundary of a solid that is homogeneously 2-D, lies in a single surface, and locally has solid material on only one of its sides (Requicha, 1980); most BRep modelers use CFaces.) Figure 3 illustrates this definition for the simple case in which there is only CFace that intersects the corresponding OFace. At the top, the figure shows an Lshaped object represented by a BRep. T o attach a tolerance to the top CFace F o f t h e object’s boundary (F is denoted by a thicker line), we define an NFace N that points to the OFace O = F. Here the meaning of N is straightforward, since N = F = O. However, if

O is a face of some object Q (e.g. a primitive solid) and P is the result of applying some operation to Q, then N ≠ O. An example is given in Figure 3, at the bottom. Again, we have an L-shaped object and we want t o tolerance its top CFace F. But now the object is defined in CSG by subtracting the two primitive blocks Q1 and Q2. The NFace N now refers to an OFace O that is the top face of the primitive Q1. We still have N = F, but now N ≠ O. Note that this definition of NFace differs slightly from that given in (Requicha & Chan, 1986); our original definition used socalled BFaces, and was computationally unpleasant because it required 2-D Boolean operations on faces, or old-fashioned boundary evaluation algorithms. O=F

Q2 F O

Q1

Figure 3 – NFaces for BRep and CSG objects NFaces are used to construct Variational Faces (VFaces). These are either entire NFaces or subsets of NFaces carved out by Boolean intersection of an NFace with a solid object. More precisely, a VFace is defined by an NFace, a Classification Operator (ClassOp), which can take one of the values {in, on, out, null}, and a nominal Solid. For example, when ClassOp = in, the VFace corresponds to that portion of the NFace that is inside the specified Solid. A null ClassOp indicates that the VFace and NFace coincide. A face subsetting capability is needed, because tolerances may be assigned to portions of faces, as in so-called “local” tolerances defined in the standards.

Surface Features (SFeatures) are either single VFaces or unions of several VFaces. For example, the opposing sides of a slot may be defined as an SFeature. Variational Edges (VEdges) are the intersections of VFaces, and may be grouped into Curve Features (CFeatures). SFeatures and CFeatures are collectively called Variational Features (VFeatures). Tolerances are expressed through named attributes of VFeatures. For example, a flatness tolerance of 0.001 is assigned to an SFeature by constructing an attribute node with data ‘flatness, 0.001’ and inserting it into an attribute list linked to the SFeature. Some tolerances imply relative positioning, and therefore require that reference entities be specified. The standards provide entities called datums for these purposes. Datums are mathematical idealizations of physical entities; for example a datum plane is a perfect plane that is “tangent” to an imperfect planar face of a part. (More precise definitions are given in the standards.) The standards state that a datum may be associated with a single feature, it may be a “compound” datum constructed from several features (such as two holes), or it may be composed of “datum targets” (which are small user-defined areas within faces). Datum reference frames are defined by an ordered set of up to three datums. VGraph provides DatumSystem entities for representing datum reference frames. A DatumSystem points to up to three VFeatures, and each of these may correspond to a set of SFeatures or CFeatures. These sets of features are used to represent compound or target-based datums. A VGraph structure may represent the tolerance specifications of several objects, and supports incremental construction of tolerance specs, as the nominal object evolves. In a CSG system the VGraph typically contains the specs for all the intermediate objects defined in a CSG graph. In a BRep system the VGraph may contain only the specs for the final object or also some intermediate ones that were saved by the user. For example, our feature recognizer (Vandenbrande & Requicha, 1993) asks the nominal modeler to perform several Boolean operations on the given part. The tolerance spec of the part obviously cannot be discarded. To support incremental construction, VGraph must be able to refer to OFaces, as discussed below in Sections 5.1 and 5.2.

We note parenthetically that incremental construction of tolerance specs could also be supported as an user-interface function. For example, when a user combines a part with another through a Boolean operation, copy the tolerances associated with the CFaces of the arguments to the resulting object; if a face splits, propagate its tolerances to the various resulting CFaces; and if faces merge, merge their specs. In essence, a new, single-object VGraph would be constructed by the user interface by copying previously-assigned tolerances from other VGraphs, which could then be discarded. The user could subsequently modify or augment the resulting VGraph. This approach is reasonable for BRep systems but unsuitable for CSG modelers, and not considered further in this paper. A typical application requires the nominal and variational information for a single solid part. The variational data relevant to the given solid must be extracted from a VGraph that may correspond to several solids, as noted earlier. We call this operation tolerance extraction and discuss it below in Section 4.3.

4. TOLERANCE MODELER We designed and implemented a VGraph version in C++. Much of the implementation is straightforward, because the entities described in the previous section can be mapped directly into C++ classes. But there are some delicate issues associated with the linkage between variational and nominal data. In the subsections below we discuss the tolerance modeler classes, and the interfaces of the tolerance modeler with nominal modelers and with application programs.

4.1. Class structure VFeature is a base class. Each VFeature possesses an AttributeList. SFeature and CFeature are derived classes from VFeature. SFeatures represent unions of bounded subsets of surfaces through lists of pointers to other SFeatures or VFaces. CFeatures and VEdges behave similarly. VFaces are derived from SFeatures, and VEdges from CFeatures. Elements of all these classes contain variables for representing the appropriate information, described in Section 3. The DatumSystem class is used to represent datum reference frames. Each element of this class contains an array of three pointers t o VFeatures (some of these pointers may be null), plus a parallel array of Qualifiers that

apply to the features. Qualifiers are defined in the ANSI standards as MMC (maximum material condition), RFS (regardless of feature size), and so on. A VFeature may be part of several DatumSystems, perhaps with different Qualifiers.

SFeature Id: 5 attributes sfeats

Base class Attribute has derived subclasses ToleranceAttribute, SurfaceFinish and TechnicalAttribute (e.g., a thread). These classes contain several slots that carry the information specified in the standards.

VFace Id: 1 NFace: 2 (6) attributes

All of the classes have constructors and destructors, and methods for retrieving the relevant data. In addition, there are methods for adding and deleting Attributes to attribute lists of VFeatures, and for adding and deleting SFeatures and CFeatures to feature lists associated with SFeatures and CFeatures.

Attribute Id: 15 parallelism 0.05 datums

VFeatures, Attributes, DatumSystems and NFaces have persistent identifiers, which are assigned to them by constructors in the tolerance modeler. (Identifier assignment is done naively in the current implementation, simply through a sequence of increasing integers.) These Ids are inherited by the elements of derived classes.

0.01 (3)

D (2)

VFace Id: 3 NFace: 4 (4) attributes

Attribute Id: 16 flatness 0.01

DatumSystem Id: 14 D

DatumSystem Id: 12 A B C

VFace Id: 6 NFace: 7 (1)

VFace Id:10 NFace: 11 (9)

VFace Id: 8 NFace: 9 (2)

(7)

(4)

(6) (5)

(8) A

(1) (9) C

(10) B

Attribute Id: 13 position 0.01 datums

0.01 A B C

Figure 4 - A partially toleranced part Figure 4 shows a simple example. The surface feature to be toleranced is a slot composed of two planar faces. The slot has a position tolerance with respect to a datum reference frame constructed over three faces. One of the faces of the slot has a flatness tolerance.

Figure 5 – A VGraph fragment The corresponding VGraph structure, shown in Figure 5, contains only one composite SFeature that points to the VFaces corresponding to the slot faces. All VFaces equal their associated NFaces in this example. (This happens often.) The SFeature has a single ToleranceAttribute, which is a position tolerance of 0.01 and refers to a three-datum reference frame constructed with three planar faces of the part. One of the slot faces also has a ToleranceAttribute, corresponding to a flatness constraint. Notice that the flatness tolerance is attached to the VFace at the bottom level, because it constrains only the individual face, whereas the position tolerance is attached to the higher-level slot feature, because it constrains the entire slot SFeature. The parallelism tolerance also appears at the bottom level. For explanatory purposes, in the

part drawing of Figure 4 we show a number within parenthesis attached to each of the part’s CFaces, which coincide with its OFaces. Each node in theVGraph has an Id, as shown in Figure 5, where we also indicate, within parenthesis, the CFace that corresponds t o each NFace.

4.2 Nominal Geometry Interface NFaces are the primary links between variational data in a VGraph and nominal data in the associated solid model. Three problems must be addressed: How is the correspondence established initially? How is it preserved when both a tolerance and a solid model are archived and then de-archived? What happens when the solid model is edited? The connection between a tolerance model and a nominal model is established through an adaptor. Every geometric entity in an adaptor is named by a Tag (which implementationally is an integer). Tags are not persistent across modeling sessions. They may change when models are saved and subsequently retrieved. The constructor for a VFace takes an adaptor Tag for an OFace as argument (plus a classification operator, and a Tag for a solid if the ClassOp is non-null) and creates a VFace and an NFace, both with persistent VGraph Ids. (Implementationally, an NFace is just an Id, it carries no explicit information.) The adaptors are responsible for maintaining the correct correspondences between NFace Ids and persistent entities in the solid modelers. They use Tags as an intermediate naming scheme between VGraph and nominal modeler face “names”. We will discuss how to do this in Section 5. We will see that drasticaly different approaches are needed for BRep and CSG modelers. The correspondences between NFace Ids and persistent modeler face labels are stored in appropriate data structures, which are modeler-dependent, and archived together with the tolerance and nominal models. Dearchival is conceptually straightforward. Tags for the relevant entities are generated in the adaptor, and correlated with the persistent names in the nominal modeler. Then the data structures that contain the correspondence data are used to link adaptor Tags to VGraph Ids. Let us now turn to editing. Suppose that a designer has saved the toleranced part shown in Figure 4, and then decides that he or she needs a similar part but with an added boss, as

shown in Figure 6. The new object has an additional size tolerance applied between the front and back faces of the boss. The editing operation may be done as follows: (i) define a solid boss, (ii) identify its front and back faces as a surface feature, (iii) assign a size tolerance to the new feature; (iv) union the boss with the original object. (13)

(14) U* (12) 30±0.1 (11)

(2)

Figure 6 – Editing a nominal object

SFeature Id: 21 attributes sfeats

Attribute Id: 22 size –0.1, +0.1

VFace Id:17 NFace: 18 (11)

VFace Id:19 NFace: 20 (12)

VFace Id: 8 NFace: 9 (13, 14)

Figure 7 – Modifications to the VGraph Figure 7 shows what happens to the VGraph. NFaces corresponding to CFaces (11) and (12) of the boss, plus corresponding VFaces are added. An SFeature consisting of the two new VFaces is also added, together with a new size Attribute. But something more interesting has happened: CFace (2) of the initial object has been split by the union operation into two connected components. The geometric meaning of an NFace has changed because of the editing operation. We do not have t o change the VGraph or the NFace/OFace associations, but the tolerance extraction

procedure must take into account that, for the edited object, the NFace with Id=9 corresponds to the two CFaces (13) and (14). NFace 9 still points to CFace (2) of the unedited object, and CFaces (13) and (14) of the edited object are not OFaces in this specification. More generally, the following situations may arise as a result of a solid-modeling editing operation. 1 . A part face may be split. This was discussed just above. 2 . A new face may appear. This simply implies a new NFace entry and associated data. 3. A face may become smaller (but non-null), for example, because of a Boolean difference operation. This requires no action. 4. A face disappears completely. This causes serious problems if the face was previously used to construct a datum. Because the datum disappears, any tolerance that refers to it is meaningless. In the current implementation we take a simple “lazy validity checking” approach: when an application requests variational data we check that all relevant NFaces correspond to non-null part faces, and raise an error flag if they don’t. 5. Two (or more) faces merge, for example because of a union operation. Figure 6 provides an example: the bottom face (1) merges with the bottom face of the boss. Now the NFace with Id=7 has grown. The tolerance extractor must take into account the new face correspondence.

4.3 API and Tolerance Extraction The set of constructors, destructors and query methods provided by the classes described in Section 4.1 are part of the tolerancing API. However, what most applications need is essentially a list of CFaces, or CFace aggregates that form surface features, plus their associated attributes. These data often are not explicitly carried in the VGraph, and require tolerance extraction. The tolerance extraction procedure compares each CFace in the BRep of the solid with the OFaces that lie in the same surface. (OFace representation is modeler-dependent and will be discussed below in the adaptor sections.) All the CFaces that intersect an OFace are considered part of an NFace. Intersection tests between faces lying in the same surface are required, but faces lying in different surfaces do

not have to be compared, and the actual (boundary) evaluation of face intersections is not necessary. (Unfortunately, many modelers do not provide face intersection checks in their APIs.) The result of this first step is a list of OFace/CFace intersections. The following cases are possible. 1. A CFace has no intersecting OFaces and therefore has also no NFaces. This simply means that no tolerances were assigned explicitly to it, and only default tolerances apply. 2. One CFace intersects exactly one OFace. Then, the CFace, OFace and NFace coincide. This is precisely what happens when tolerances are assigned to the faces of a BRep solid, and the solid is not subsequently edited. 3. Several CFaces intersect the same OFace. The union of the CFaces is the corresponding NFace. 4. An OFace does not intersect any CFace. The corresponding NFace is null. This information is kept for later use in checking datum validity. Several OFaces intersect the same CFace. This means that several NFaces overlap. In the current implementation we treat this as an error because it implies that a user is referring to the same piece of physical boundary by two different “names”. (More sophisticated approaches could be taken. For example one might merge the NFaces, but this is not consistent with our definition of NFace, and also causes problems when the overlap is partial.) At this point the tolerance extractor knows what is the geometric meaning of each NFace in terms of CFaces or groups of CFaces. It also knows which NFaces are null. Next, for each VFace that has non-null ClassOp and Solid, the extractor must invoke the nominal modeler to compute the VFace by classifying the associated NFace with respect to the Solid. Unfortunately, most modelers do not provide API functions to do this, although they usually have internal procedures very similar t o face/solid classification. In the current implementation we assume that VFaces equal NFaces. The tolerancing API provides functions t o extract attributes. Currently we have three such functions. One traverses the VGraph and outputs a list of ToleranceAttributes, each

with the associated VFeature and corresponding CFace Tag(s). If a ToleranceAttribute refers to a datum that corresponds to a null NFace, an error is flagged. Null faces that are not datums are ignored. The two other procedures operate similarly, and return a list of SurfaceFinish attributes and a list of TechnicalAttributes.

5. ADAPTORS Most geometric modeling systems provide procedural APIs, but these are not standardized. Moreover, radically different systems such as CSG and BRep modelers, typically have very different APIs. At USC’s Programmable Automation Lab we have been developing over the past few years software interfaces, called adaptors, which provide a uniform API for all modelers. We have partially implemented adaptors for the two modelers we use routinely in the lab: PADL-2 (abbreviated P2), developed at the University of Rochester, and Parasolid (abbreviated PS), a commercial system marketed by EDS/Unigraphics. The development of nominal-geometry adaptors is reported in (Han & Requicha 1996). Here we discuss adaptor facilities for tolerance modeling. Each entity in an adaptor is identified by an associated (integer) Tag, which is assigned to it by the adaptor at construction time. These Tags provide fast retrieval of entities, but are not persistent. They may change between modeling sessions, and therefore are not suitable for archival. Tags are used to establish a connection between VGraph persistent Ids and persistent “names” in the underlying solid modelers. Unfortunately, not all solid modelers have persistent identifiers directly associated with objects’ faces. These identifiers must be created by the adaptors, as explained in the following two subsections.

5.1 Parasolid Tolerance Adaptor Parasolid entities have internal names, which we call PS-tags, and are volatile. PS-attributes can be attached to any entity represented in PS. We use PS-tags as adaptor tags. That is, the adaptor, instead of generating an arbitrary Tag for a nominal-geometry entity, just uses the entity’s PS-tag. When an NFace is assigned an Id in VGraph, the Tags of the corresponding CFaces are known (they are input to the VFace constructors), and therefore their PS-tags also are known. We attach the NFace Id to the corresponding PS CFace(s) by constructing PS-attribute(s) for

the CFace(s) and storing the Id as the attribute’s value. Thus, OFaces are represented by PS-faces with appropriate PSattributes. In the current implementation a user must save, through a keep adaptor call (Han & Requicha 1996), the BRep of any object whose CFaces are used to define OFaces. This is important because BRep systems normally discard the boundaries of all intermediate solids. (One could also store only the OFaces and discard the rest of the BRep.) Tolerance extraction is implemented as discussed in Section 4.3. Intersection testing is done by converting each OFace and CFace into a “sheet body” and calling intersection procedures in PS’s API to determine the NFaces.

5.2 PADL-2 Tolerance Adaptor P2 is a CSG modeler. Its BRep is volatile and therefore we cannot persistently associate VGraph Ids to boundary entities. We solve the problem by defining OFaces as solid-primitive faces, and referring to these through path names (Requicha & Chan 1986). To construct a path name, first we number the faces of each primitive solid according to some convention. Then we traverse the CSG graph from the root until we reach the relevant primitive leaf, and build a sequence of all the nodes encountered. At the end of this list we append the index of the desired face. For example, in Figure 8 the path names for faces F1 and F2 (or, more precisely, for the primitive faces from which they are derived) of object C are: F1: C/A/1 F2: C/B/A/1 Note that both F1 and F2 derive from the same primitive face A/1 and therefore cannot be distinguished without additional information. Instead of the full path names shown above, we can use short path names, which are obtained from their full counterparts by discarding those nodes that do not have associated rigid motions. For our example the short path names are: F1: A/1 F2: B/A/1 Short path names automatically ensure that the associations between VGraph and nominal entities are correctly mantained. To see why, suppose that in the figure we associate tolerances to (VFaces constructed with) faces F1 and F2 of C, then move C so as to create

D, and union D and C. The tolerances of F1 and F2 should not be propagated to the new faces F1′ and F2′ of E, which do not even lie in the same surfaces as F1 and F2. Since the short path names for these faces are F1 ′: F2 ′′:

D/A/1 D/B/A/1

they are associated with new OFaces and do not inherit the tolerances of F1, F2. On the other hand, the original path names A/1 and B/A/1 still denote the same OFaces, although the geometric meaning of the NFaces associated with them may have changed between solid C and solid E. (In fact, the NFace that corresponds to A/1 is smaller in E than in C.) E = C U* D

F2'

F1'

F2 F1

D = mov C

C = A –* B F1'

F1

B = mov A

2 1

5.3 Feature-Based Representations Tolerances and attributes may also be incorporated in feature-based representations of solids. Suppose that features are solids that are added or subtracted to an evolving part model by means of Boolean operations. (This is how most of the current feature-based design systems operate.) We can use the faces of each feature as OFaces and apply the methodology discussed earlier. For example, we can treat a feature as a generalized CSG primitive, number its faces, and construct an adaptor similar to the PADL adaptor described in the previous section.

6. SUMMARY AND CONCLUSIONS F2'

F2

A

P2’s faces are not CFaces, and a converter is needed to generate them from a P2 BRep. At the moment we ignore this issue because we have not yet implemented a converter. Second, P2’s API does not provide a face intersection checker. We currently assume that there is a non-null intersection between a BRep face and all the primitive faces that lie in the BRep face’s host surface. Both limitations are conceptually easy to remove, but involve programming effort.

3 4

Figure 8 – CSG path names The VFace constructor takes an adaptor Tag that corresponds to the short path name of an OFace (a primitive-solid face), and produces Ids for both a VFace and an NFace. Therefore it is easy to construct within the adaptor a table of correspondences between NFace Ids and OFace short path names, both of which are persistent. The table is stored when the models are archived. The tolerance extractor operates essentially as explained in Section 4.3, but the current implementation has two limitations. First,

This paper discusses an experimental tolerance modeler and its interfaces with application programs and nominal-geometry modelers. Application programs that use the API described here do not have to know which tolerance modeler and nominal modeler are used. That is, they are completely modelerindependent. The tolerance modeler itself is independent of the nominal modeler. All the modeler dependencies are seggregated into adaptors. This methodology is very general, and applies to such diverse systems as CSG, boundary, and feature-based modelers. The tolerance modeler is currently being used to support research in process planning for machining, and in inspection planning for Coordinate Measuring Machines. The current implementations have limitations pointed out in the previous sections. They arise primarily because the underlying solid modelers do not provide API facilities for classifying faces with respect to solids, and for checking if two faces lying in the same surface intersect. Future work should address issues of user and database interfacing. Currently, tolerance representations must be built by programs that directly invoke the constructors. These require

information about the internal names of faces in a solid model, which are very inconvenient to obtain. What is needed is a point-and-click graphic interface that allows a user to select a face and automatically generates the data needed by the constructors. Implementation in a database environment would have advantages in dealing with large amounts of data, and with persistent identifiers.

Acknowledgements The research reported in this paper was supported in part by the National Science Foundation under grant DDM-92-14996, the Consiglio Nazionale per le Ricerche (Italy), and the Industrial Associates of the Programmable Automation Laboratory, Institute for Robotics and Intelligent Systems (IRIS) of the University of Southern California.

References

Proc. ASME Int’l. Computers in Engineering Conf., pp.275-280. Requicha, A. A. G., 1980, “Representations for rigid solids: theory, methods, and systems”, ACM Computing Surveys, Vol. 12, No. 4, pp. 437-464. Requicha, A. A. G., 1983, “Toward a theory of geometric tolerancing”, Int’l J. of Robotics Research, Vol. 2, No. 2, pp. 45-60. Requicha, A. A. G., 1993, “Mathematical definition of tolerance specifications”, ASME Manufacturing Review, Vol. 6, No.4, pp. 269274. Requicha, A. A. G., and Chan, S. C., 1986, “Representation of geometric features, tolerances and attributes in solid modelers based on constructive geometry”, IEEE J. Robotics & Automation, Vol. RA-2, No. 3, pp. 156-186.

American National Standards Institute, 1994, Dimensioning and Tolerancing, ANSI/ASME Y14.5M 1994.

Rivest, L., Fortin, C., and Morel, C., 1994, “Tolerancing a solid model with a kinematic formulation”, Computer-Aided Design, Vol. 26, No. 6, pp. 465-472.

Consortium for Advanced ManufacturingInternational, 1986, “Dimensions & Tolerances Feasibility Demonstration”, Vols. 1, 2, 3, 4.

Roy, U., Liu, C. R., and Woo, T. C.,1991, “Review of dimensioning and tolerancing representation and processing”, ComputerAided Design, Vol. 23, No.7, pp. 466-483.

Feng, S., et al., 1993, “STEP part 47: shape variation tolerances”, ISO 10303.

Shah, J. J., and Miller, D., 1989, “ A structure for integrating geometric tolerances with form features and geometric models”, Proc. ASME Int’l. Computers in Engineering Conf., Vol. 1, pp. 395-402.

Guilford, J. and Turner, J., 1993, “Advanced analysis and synthesis for geometric tolerances”, ASME Manufacturing Review, Vol. 6, No. 4, pp. 305-313. Gossard, D. C., Zuffante, R. P., and Sakurai, H., 1988, “Representing dimensions, tolerances, and features in MCAE systems”, IEEE Computer Graphics & Applications, Vol. 8, No. 2, pp. 51-59.

Vandenbrande, J. H., and Requicha, A. A. G., 1993, “Spatial reasoning for the automatic recognition of machinable features in solid models”, IEEE Trans. Pattern Analysis & Machine Intelligence, Vol. 15, No. 10, pp. 1269-1285.

Han, J.-H. and Requicha, A. A. G., 1996, “Modeler-independent procedural interfaces for solid modeling”, to appear in Proc. Computer Graphics International, Pohang, Korea, June 24-28, 1996.

Voelcker, H. B., Requicha, A. A. G., et al., 1978, “The PADL-1.0/2 system for defining and displaying solid objects”, ACM Computer Graphics, Vol. 12, No. 3, pp. 257-263. (Proc. of SIGGRAPH '78.)

International Organization for Standardization, 1989, ISO 5459-1989 (E), Geneva, Switzerland. Johnson, R. H., 1985, “Dimensioning and tolerancing: final report”, R84-GM-02-2, CAM-I. Ranyak, P. S., and Fridshal, R., 1988, “Features for tolerancing a solid model”,