Family Tables management in Windchill 10.2

I do not like releasing FT parts, but it depends on what type of parts you are putting into your FTs.

For purchased commodity items, create the family tables, populate with as many instances as you think are reasonable at the beginning and check the FT into a Part Library. By using a Library instead of Product, you limit accesss to the files for changes and for users without Library access (should be most of your users) the file can be configured to come into a workspace as Read-Only.

There are a few CS artciles on PTC.com dealing with FTs but like anything there, hard to find unless you hit the right search keywords.

One thing I would caution against is when family tables get too large. I prefer to restrict to dimensional variability and would suggest that you avoid feature vairability (example = having hex head capscrews in the same table as socket heads). If using in conjunction with Chart/Table Drawings I would avoid blending materials as well.

In general each instance is associated to a WTPart. Generics do not have WTPart (exception is Sheet Metal... as sidebar, I would prefer a PTC recommended best practice for Sheet metal and Flat Patterns that did not mean Generics as the real thing, or suppressed features in the functional model but that's for another day). Association type is your call, but I don't see a compelling reason that they would not be Owner Associations.

Be cautious with Relations! Evaluating relations can cause an entire FT to want to modify. Anything in the Generic than can drive differences in Instances needs to be included in the Table. Relations in the Generic can impose a new truth on all instances with each instance that gets loaded.

Release, Release, Release! You want to make sure that you don;t leave FT's open for all to modify. You'll end up with earlier versions that have instances that are not present in later versions of the generic (major headache!). Most common cause is anyone can edit anytime FT's. Force revision to the Generic to add an instance. Force revision to all Instances and generic for any Global modifications (such as material). Release Generics and all Instances. Adding an instance should only require the Revision and modification of the Instance. Using ACL and Lifecycle States also supports Read Only in Workspace similar to Library described by Ben Loosli‌

Keep an eye on FT Generics and Instances in the Workspace. If they are modifying for no apparent reason, then check for and remove circular and/or external references. FT Instances should be stable for simple use.

KISS Principal - it's easy to get too much of a "good" thing. Nested Family Tables can increase complexity and challenges of managing. Discretion should be used when considering whether or not to FT an assembly using one or more FT components. (I still have not figured out a way to set up a Chart BOM)

Understand the requirements driving the use of FT's and establish criteria for when, when not to use. Again - FT's are highy effective for dimensional variation of a family of components. One benefit is being able to specifiy mulitple parts on a single drawing with a table listing dimensional and parametric differences (yes, don't forget things like Name, Description, Part Number etc.). Big advantage is that when a non tabled dimension is modified (or featre added) it ensures that the change is applied to all in the family. if you don;t want this, then it should probably not be a FT.

Keir & Ben both have some good info. A few more things to add;

• Define their acceptable and unacceptable use prior to using them (this may impact company policies and procedures)
• Consider how the instances are going to be detailed. If you allow/require instances to have their own drawings, this will add complexity. It is easiest/most robust when all instances are controlled on one single drawing. That drawing is of the generic and uses tables with repeat regions to define the instances and the associated dimensions. Don't override the shown dims, but rather change the dim text to "@S" and then the values are shown in a table.
• Make sure the table dims are all named, or the above won't work well.
• Define your numbering policy. For instance, are you going to use dash numbers? i.e. the generic is numbered "123456" which matches the drawing number and then the instances are; "1233456-1", "...-2" etc. Does everyone (mfg, purchasing, doc control, etc) have the same concept of what a dash number is? This can be a big thing in terms of ISO type certifications.
• Revisions; can instances have different revisions? From a practical point, the generic must be equal to or "higher" than the highest instance. i.e. if one instance is at rev G, the generic must be at least at rev G. Or, must all instances, the generic and the drawing all be at the same rev? (easiest)
• What happens to obsoleted instances? Deleting an instance is a VERY BAD thing. So, how are you going to obsolete an instance when it is no longer wanted? (Setting to an OBS release level works, but access control impacts a users ability to later modify the generic.)
• I will also reiterate a comment from above, nested family tables are a bad idea unless use is very strictly controlled and you have a very robust process in place to insure proper use.

Note, FTs are really good for commercially purchased library parts like fasteners.

Thanks everyone. With these responses here are some ideas I have to plan. I really like Keir's mention of the KISS idea. Family Tables can get FAR too complex, quite quickly.

1. Our drawings are named (numbered) D000XXXXXX, so we are also planning to name the Generic the same, D000XXXXXX. Each instance would then receive the same name as the WTPart number 02XXXXXX. There are no dash numbers. People here are used to seeing the CAD model with the same name as it's associated WTPart number. We then would associate and release each instance with it's WTPart number. I think that would work in the way that Keir mentioned about not keeping the FT's "open for all to modify." That is also quite concerning.

a.Dan's point about all instances on one drawing is well taken, and I believe that is what we would do.

b. I am very concerned about instances having different versions. I don't normally see this as a problem, but wonder if there could be a conflict, and how to resolve it.

c. Obsolescence sounds really scary. We do obsolete parts from time to time.

d. I still am not certain that the Generic should be Released or not?

I suppose not, since Keir indicated that Generics would not have a WTPart ever associated with them.

2. FT are currently limited to exact geometry but different materials (we only have two or three materials). We are considering adding length to that list, so different materials and lengths would be the variables, and only those. Clearly the simpler the better.

James