Showing results for 
Search instead for 
Did you mean: 
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Did you get called away in the middle of writing a post? Don't worry you can find your unfinished post later in the Drafts section of your profile page. X

Family Tables


Family Tables

Hi All,
I have always felt that family tables are a powerful tool. But seeing how my company uses them makes me wonder if it's worth the hassle on the management side. We currently create tables for our product components. They are not very complex tables but some have a large number instances. None of them are nested.
The point of the family table (as we use them) is that it is easy to create/edit/manage a large group of related parts (similar but different).
Our standard management practice is to keep all the instances at the same revision so that it's less confusing to the end users. We also create individual drawings of each instance.
So you can imagine the amount of time it takes an engineer to make a change to a single instance. It is this process that made us decide to never store a full product assembly of a standard product (you read that correctly)....we only manage the components because revising one table of components would have a ripple effect across a very large number of products that use those components.
When a customer requests to see one of our product drawings, we literally put the components together in a new assembly on the fly, create a drawing, export it and then erase the assembly. If the next customer requests the same product, guess what happens? We recreate it again.
The benefit of the family table is that it should be EASIER to manage the group of parts together as a whole rather than individual should not be more complex and challenging.
So my first question is...does anyone manage instances independent of other instances in your family tables? My belief is that any issues with managing family tables are mainly related to user knowledge and not a limitation of the data management tool (Windchill) to manage the relationships but I guess I want that confirmed by you guys.
Have any of you moved away from family tables to some other technique instead? If so, what techniques do you use to manage these parts? Do you manage them independently? Have you had any issues going this direction?
It seems logical to me that if you can create a family table, manage the instances individually, and use a single tabulated drawing, that revisions should take minutes to complete instead of hours/days. But I could be mistaken if managing instances individually really does cause a lot of grief.

Mike -
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.
21-Topaz II

Back at PTC/User '07 (I think) I saw a presentation on using replacing
family tables with a master model and related models using an
inheritance feature from the master.

Worked something like this:

1. Build master model.
2. Create a new model and import the master using an inheritance
3. Create differences in the inheritance feature (suppressed
features, modified dims, etc.) for the new model
4. Add any new features needed in the new model.
5. Create a drawing of the new model.

Now, the new model is driven by the master, but changes to the new one
don't necessarily mean changes to the master, like they do with a family
table. Need a new 'instance'? Copy an existing 'instance' and its
drawing and modify as needed.

Not sure how it effects part interchangeability.

Doug Schaefer
Doug Schaefer | Experienced Mechanical Design Engineer

Hi Mike.

We're currently managing CAD Docs with Windchill 9.1. We use Family Tables primarily for hardware type models. We do also use the Flat State instance for sheet metal models. It is our practice to manage the generic/instance as one object when it comes to editing and check in. If you edit the generic, you edit the instance(s) and check in the entire table. We adopted this practice with 8.0 m020 and haven't changed. Yes, it is possible to edit only the generic and asingle instance then check in those edits. This will create a scenario though where user1 has a WS with generic a.5/instance1 a.5. Then user2 may have a WS with generic a.6/instance2 a.1. If user 1 tries to update generic a.5 to generic a.6 there could be issues because instance1 a.5 needs parent generic a.5.

Kind Regards, Jim


We are using Pro/E outside of any PDM system so our revision level is just a part parameter. Some family table parts are just simple bent/flat sheetmetal and go on the same drawing and have the same rev level. Other family table parts have many instances, those that have their own unique drawing have independant rev levels in the family table. One thing that users have to be aware of is that some dimensions & features are common to all instances so a change there will change every instance and therefore every drawing has to be changed. Alternately, that dimension or feature can be added to the family table so that only one instance can be changed. We only use one level tables. Once or twice in the past I made some parts with multiple levels and found it nearly impossible to manage.

We make family table assemblies from all our family table parts. This is one of the best features of family tables as you can easily swap alternate instances at will and create new assemblies. In some cases we may have hundreds of finished products built from families of components. There are assembly drawings of every step of the way including customer outline and installation drawings.

PTC quality philosophy: We've upped our quality standards. Up yours.

Top Tags