Model Tree, tracking part identity 1

[freerangequark]

The new company I am working for uses the part numbers as the CAD file name. The description is locked in Windchill and is sometimes not very descriptive.

As a result, other engineers here are inserting datum points in to the assembly before each part or subassembly so that they can rename the point to help identify the CAD part or assembly which follows it. They're essentially using the datum point rename as a REM statement. This makes a long mess of the model tree.

What better ways are there to quickly identify parts in the model tree when only abstract part numbers are displayed?

Thank you,
Glenn

 

[3DDave]

I recall that each component in an assembly can have a component related parameter, called a feature parameter (a component is a feature of an assembly,) but it still requires effort to name them.

This is a handy for identifying different uses for the same part, like Front-Left-Tire on a car assembly. Add the feature parameter column to the model tree and you can click to edit the field from the tree itself; it may be you need to manually create a feature parameter to start before you can add it to the tree.

I used to use this to drive components to particular item numbers to match an existing BOM. The parameters were used to create item balloons by setting rpt... (it's been a long time, but look for rpt parameters.) It was easy to see any cases where the item number was not assigned as those components would be listed at the end of the BOM.

I also placed components into functional groups which helped a lot. For example a group might be a cover plate, the cover plate gasket, and the screws and washers to retain the cover plate. This gives a functional description and organization to the model tree and selecting the group highlighted the parts, making it easy to see that all items were where they should be.

 

[geesaman.d]

I've used component parameters and part parameters.

Part parameters are great as long as you can live with all instances having the same data everywhere it's used, which sounds appropriate for your case.

Component parameters live in the assembly per each instance, so they can have different values in each assembly even though it's the same part. Additionally, you can have varying instances hold a different value. I used component parameters to hold a part location number because sometimes a part would appear multiple times in one assembly with different part location numbers. The component parameter can be pulled into a repeat region to drive an assembly drawing BOM. The major downside is that creating and populating the component parameter is 100% manual. I once wrote a J.Link app to create the component parameters for an existing assembly because that was the only practical answer.