Library parts creation best practice

[Dmi3U]

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?

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

3. are you using interchange assy?

4. Shrinkwraps in family table?

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

Very much appreciated!

Dmitry

[hschimmoller]

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?

[BenLoosli]

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.

[soundman99]

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.

[hschimmoller]

On the ECAD front, we are using the ECAD-MCAD IDX interface for early design exchanges, before full change control kicks in. 

The major question we have is, "How do we address parts that share the same MCAD part file (the same physical shape and size) but are Electrically different part numbers?"

For example, we have dozens of different chip capacitors parts that are mapped to the same MCAD body part. Subsequently, when we check-in the Board Assembly, with Auto Associated set to YES, to create WTParts, we get WTParts identified as the MCAD part Name/Number and not the true, valid for ordering, Electrical Part Number.

Any thoughts?

[soundman99]

@hschimmoller You are doing the exact correct thing with IDX.  What you need to do, however is switch in CREO from using "ECAD_NAME" to "ECAD_ALT_NAME".  It should be a CREO preference setting.  I don't have CREO here at my current company, but I did previously and that's what I remember at least.  Each component comes over from ECAD in the IDX file with two identifiers.  The ECAD_NAME is typically the part number for each specific component, but the ECAD_ALT_NAME is typically the footprint. You may need to play with it and experiment, but you want to be using whatever is the footprint from ECAD.

This is not a perfect solution, because especially with things like multi-layer ceramic capacitors, they can have different heights for different values but they use the same footprint, depending on how your ECAD library is set-up.  The heights are typically pretty small differences (0.01 - 0.03 inches difference for example), but depending on what you are doing, that could be an issue.  If that's an issue, then you need to work with the ECAD team and have them maintain different footprints for the different scenarios.  If it's not an issue, then you're all set, pick the tallest (or shortest, or most common...) height and go with it.

NOTE: if you have a huge set of parts already defined and configured, this very well could mess all of that up.  My biggest issues in the past has been trying to re-do the thought process on these sorts of things.

Also, one additional piece of experience... if you do get this all set-up, make sure that you are involved on the MCAD side with any library changes on the ECAD side.  I've seen where the ECAD team will rotate or move the relationship to the origin of a component in the ECAD footprint model and not communicate that to MCAD and then when you auto associate, the origins are oriented differently now, and the parts do not display as you want.

[rreifsnyder]

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.