Tutorial:Assembly Modeling
From DocR23
This tutorial guides the ACIS Assembly Modeling customer through the steps an end-user would follow in order to create, modify, and save an assembly in a typical application. This section provides a concrete framework for introducing the concepts and interfaces that the customer uses within ACIS Assembly Modeling.
Note: Throughout this document, "customer" refers to an application developer writing an ACIS-based application ("the application"), that is, a Spatial customer (or, to be more precise, the person reading this documentation), while "end-user" refers to a user of that application, that is, the customer's customer. Technical details are distinguished by italics.
Contents |
Assembly vs Part Modeling
One of the first things that the end-user notices when working with the application is that he may choose to work on either an assembly model or a part model. This dichotomy extends to the way in which model information is persisted to disk; most applications have different file-name extensions for assemblies and parts. (ACIS, for example, uses the extensions ASAT and SAT, respectively, to distinguish the two.) If the end-user chooses to work on a part model, he is placed in a context ("part modeling mode") where he manipulates the equivalent of ACIS BODY objects to make a single part. When finished, he saves the data to a part file, the application writing a SAT segment, together with whatever metadata (for example, a feature tree) it associates with the part.
Note: SAT segments are embedded by calling api_save_entity_list on an already open file.
If the end-user chooses to work on an assembly, however, he is placed into a sub-application where he is able to load copies of part models and/or assembly models into memory, position them in space relative to one another, organize them hierarchically into an assembly, and make changes to the way in which the copies of the parts (and/or sub-assemblies) are expressed in the assembly. This context is "assembly modeling mode"; it involves organizing pre-existing content (parts and sub-assemblies) into more complicated structures. When the end-user saves his work, the work is saved in an assembly file, rather than a part file. This file contains an ASAT segment and the assembly meta data. The application may give the end-user the option of saving the entire assembly into a single file (monolithic saves), or breaking it up into multiple files (atomic saves). ACIS (and hence the ACIS-based application) supports this functionality. One of the important responsibilities of the customer's application is to include in the meta data information that allows references between atomic files to be re-bound if any of the files is changed.
Concepts
- See also: Basic Concepts in Assembly Modeling and :Category:ACIS Concepts
The following topics discuss the two sets of concepts that have been introduced in this section.
Modeling Modes
Part modeling and assembly modeling perform fundamentally different types of operations. Part modeling creates indivisible units of content (parts), while assembly modeling arranges copies of parts into assemblies. The set of operations performed by the application may thus be subdivided according to mode: part modeling operations are performed in part modeling mode, while assembly modeling operations are performed in assembly modeling mode. This dichotomy is expressed within the ACIS interface through the interface function names; the API functions, with names beginning api_, are used in part mode; functions with names beginning asmi_ are used in assembly mode.
Parts, Assemblies, and Models
An assembly aggregates both parts and sub-assemblies. From the point of view of the high-level assembly structure, there is little difference between the two. For example, the wheel model that occurs in a car might be a part (if the designer does not wish to go into detail about the actual manner in which the wheel is constructed), or the wheel might be a sub-assembly (containing tire and hubcaps, for example). However, the person looking at its image on a monitor, in either case, regards it as "a wheel."
For this reason, we introduce the concept of a model, which is something that can be aggregated by an assembly (for example, "a wheel"). Models come in two varieties: those which contain an assembly (assembly models) and those which do not (part models).
Assembly models may, however, directly contain part data (that is, BODYs), referred to as assembly-level entities. The application can place assembly-level features (for example, weld beads) within an assembly without requiring the creation of a separate model.
In the ACIS Assembly Modeling interface, the assembly object ( ASM_ASSEMBLY) is an aggregation ENTITY that is hidden behind the model object (asm_model). This allows the contents of an assembly to be expressed differently when it is included as a sub-assembly within another model. In turn, the contents of an assembly object do not necessarily represent the "final result" when it is being used as a sub-assembly. (As an example, the containing model may change the color of the sub-assembly, a change that appears only in the context of the containing model.) Interface functions that provide component queries access the ASM_ASSEMBLY object and take any modifications from higher-level assemblies into account, and so are the functions that should be used to read the assembly tree.
Interoperability
In both examples given above (of part and assembly modeling), we assumed that the end-user intends to use his saved models for use in a later session of the application. If he instead wants to use them in a different ACIS-based application, he needs to save the models into a SAT or ASAT file, as appropriate. We strongly recommend that ASAT files written for the purpose of export to another modeler be saved as monolithic, rather than atomic files.
Tutorial: Example - Car Assembly
- Creating a wheel part (single component)
- Creating an axle part (single component)
- Creating an axle assembly (subassembly)
- Creating a chassis part (single component)
- Creating the Car Assembly
Summary
As noted above, the purpose of the example is to illustrate why Spatial strongly recommends using the component interface when walking the assembly tree; it is designed to be easy to use and insensitive to the details of how the assembly is represented internally in terms of occurrences, decorations, and model references.
