The files should contain no feature information (i.e. geometry, annotations, assembly interface definitions, datums, etc. information only [almost like generating a merge model]). This would be similar to the existing .xpr and .xas instance accelerator files, except these are real .prt and .asm files & can contain additional information like annotations. The user should be allowed to determine when and what instances are published as well as what information is included in the published file. As an analogy, you use a word processor to generate textual information and then “publish” that to another format (like a .pdf) for consumption. This idea is similar in that the user would be using a generic to generate the feature information with family tables for the variations, and then the information (the instance) is “published” into a non-feature based model for downstream use. Please don’t confuse my use of the word publish with anything related to publishing viewable information from Windchill.
Expanding on the idea a little further, it would be nice if there was a capability of running a compare on the instances after an update to the generic & table. To help clarify by example, I have a generic with 5 instances and all the instances have a published .prt file. I now edit the generic to add a feature to the model and include that feature in the family table. However, I only add the feature to the fifth instance. The other four instances have NO in the family table column to exclude that new feature. It would be helpful to be able to run a compare (mass props, geometry, annotations, etc.) on the existing published .prt files with the (potentially) new .prt files from the updated family table. In this example, since the feature was only added to instance five, the other four instances would not need to be published as the resulting geometry is unchanged.
General Advantages
- No need to generate and maintain instance accelerator files (.xpr and .xas) to enable graphics and geometry simplified reps of family table instances.
- No need to generate and maintain instance index files (.idx) files for folder containing family table objects.
- FILE > OPEN > PREVIEW will work for instances.
- Would support any new “lite weight” viewable formats because actual .prt and .asm files exist.
- Creo View will be able to open the instances because actual .prt and .asm files exist.
- Regeneration times are shorter because only geometry/graphic information is required.
- Memory requirements are lower because no feature information is included.
- Could be used in place of shrink wrap, neutral formats, merge, etc. models, to convey geometry information only because no feature information is included.
- Since the user would decide what instances are published after changes to the generic, there is no need to unnecessarily update instances because of non-geometry or non-annotation changes. If a compare functionality is included, it would be easier to determine what actually needs to be published.
- Unless the capability of adding color to the family table is added, the user can open the individual .prt/.asm files and change colors as necessary.
- Unintentional modification of the instances is reduced because no feature information is included.
Data Management Advantages
- You will have real .prt and .asm files that can be managed individually from all the other instances. [The user defines what files are generated and when, not the PDM system]
- The compare functionality could help drive what is actually flagged as modified or not.
This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.
