Library parts creation best practice

I would like to start a discussion on the best practices for the library parts creation. can you share your best modeling practices? I have the following question:

1. how do you make the best use of the family tables?

- Recommend only using family tables for geometry creation but break them up into individual parts when moved into Windchill. This allows for individual parts to be revised independently when appropriate.

- The exception to the rule is that if the entire governing specification (say Mil Standard hardware) is captured at one time, then it is unlikely that an individual instance would need to be revised independently.

2. Simplified representation or combined states for library components? Making a light weight representation

- Only when the library components represent an assembly.

3. are you using interchange assy?

- No

4. Shrinkwraps in family table?

- No

5. ECAD library components? we do a lot of Mentor imports. ecad_hint.map is good, but there are LIMITATIONS!

- I am just getting back into ECAD library components... what are the limitations that you are concerned with?

1) Limit family tables in the Library to items that do not change frequently. I put things like screws, nuts, washers, etc. into the Library family tables.

2) I build family tables with a range of sizes. This eliminates to=he need for future editing. Like for socket head cap screws, we decided on #0 to 1-1/2 diameters and lengths up to 6". We used Fastenal catalog as our primary reference. If it is in the Fastenal tables, it was put in the family table within those ranges.

3) I am the only librarian. The users do not have anything but read access to the family tables.

4) Set Windchill so Library items are only loaded as read-only.

5) Keep the models simple, no threads, split lock washers are flat, etc.

6) if the user needs a new family table they come to me to create it. I may allow them to create a new one and then take it over to 'standardize' it in the Library.

7) Things that are good for a family table, but need frequent changes, are in the machine folders, not the Library. All users can then add new items as they need. We use this method for tubing that needs lots of different lengths to get the fit right. In some cases we have length differences of only .015, but usually they are larger.

I can only really speak to the ECAD side of things, but what I have seen work the best is to include the mechanical CAD modeling as part of the new part creation side in ECAD.  When someone requests a new part to be added to the ECAD library, they know what the part looks like in order to get a footprint added to the EDA tool, so at that same time the 3D model is being built in the MCAD tool.  Creo does have the ability to allow you to use two different things to map when bringing in files; either the part "name" or the footprint "name".  Each EDA tool sends this type of information slightly differently and I don't know the specifics on Mentor, but map your 3D models to those same names that the EDA tools are using.  If you do it "right", then you don't need an ecad_hint.map file and it will just use the right models.  That takes some coordination between the ECAD librarians and the MCAD team though, which tends to be the biggest challenge.

One of the main reasons for using family tables for hardware is the ability to replace parts for size with no downstream issues. That's one of the factors that I use to decide whether to table it or not, how likely is the part going to be replaced in an assembly? One thing however is that we will NOT use nested family tables. An example would be that a family table of screws might have instances for the different nominal thread sizes but that instance is actually the lead for a family table within it to handle all of the lengths for that size screw. It seems like a great way to keep things organized but there are issues like needing to regenerate twice at times to make sure it is completely updated correctly.

We do not use interchange assembly but if we had a set number of COTS parts that wouldn't fit a family table model very well but does have the potential to be replaced for each other in an assembly then I definitely would. EXTREMELY powerful in the right circumstances.

One thing I do try to use with family tables is Accelerator files. If you use Windchill it can handle them as attachments to the instances. Basically one of the drawbacks of family tables is that it needs to regenerate the instances based on any differences from generic. In reality with a family table there is only 1 .prt file, the generic. When you save the generic the finished geometry of that part is saved in the .prt file but that is why any other unique instance will need to regenerate. The accelerator files store the finished geometry of each of the instances so it can just open and not have to regenerate. I haven't done performance testing to verify any improvement but that's the logic for them.