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

Best Practices for replacing Family Tables?


Best Practices for replacing Family Tables?

We have a bunch of models that are using Family Tables that really shouldn't be family tables and we're considering alternatives.   Some of the alternative methods we are looking at are:

  • Inheritance Features
  • Flexible Features for assemblies with springs and things.
  • Leaving some Family Tables for hardware type items.
  • Mechanism for assemblies that need to show multiple positions of moving parts.

Does anyone have any best practices, lessons learned, advice, presentations, or documents that they would be willing to share?

We do use Windchill for our PDM/PLM solution, so that will need to be considered as well.



Re: Best Practices for replacing Family Tables?

We avoid family tables if all possible, Windchill and family tables have a tendency to cause issues sometimes especially for CAD driven BOM's.  We have tons of legacy family tables and I break them up on as needed basis, especially when the instances are at different revisions.

The method is to checkout the whole family table into a workspace, then bring up in session the generic and instances you want to make standalone, this is very important!.  Then delete those instances out of family table.  Save the family table.  Then in the workspace you will see the instances are not part of the family table, but now standalone parts.  Check the whole family table and standalone parts back in. 

Downside, other users will see those old instances "out of date" in their workspaces.  They will not be able to update, they have to delete the old instances out of workspace and add the new standalone parts back in.  Or just start a new workspace and bring in everything fresh again which is a cleaner method.

Re: Best Practices for replacing Family Tables?


We have been breaking up family tables when we can as well.   I agree with you that there are numerous issues with Windchill and Family Tables.  Like you said we have a lot of legacy data that needs to be dealt with too.

Some of the family tables were created for good reasons, even if misguided.  I think we could really help drive the adoption if there were a good proven alternative to the family table instead of just breaking them up into separate models.  Like inheritance features / models for example.


Re: Best Practices for replacing Family Tables?

What sort of issues do you think family tables are causing?

Re: Best Practices for replacing Family Tables?

I know we run into issues when people don't revise the entire family, drawings, and WTParts at the same time, then the associations become a mess.

Especially when the family table of a component is partially revised up, and goes into an assembly family table, and one instance of the assembly calls for the new component revision, and another instance calls for the old component revision.   You cant have both in the same workspace and so you are stuck.

An easy mistake to make, especially when you don't work with family tables all that often.  Thats why I think some of our models really shouldn't be family tables, but use other methods.

Re: Best Practices for replacing Family Tables?


I totally agree with you, same problem here.

Re: Best Practices for replacing Family Tables?

One of the things I learned early with family tables was to keep it simple.

Don't do nested family tables.

Use a family table where one value may need to be changed; length of a bolt, maybe a diameter. Think of why you may need a different instance and limit the family table to that choice. You may change the length of a screw/bolt to get 2 threads beyond the mating nut face. Changing diameter is seldom done, but may be for strength reasons. If you have multiple material types, they could be in the instances, too. While this may sound like a complicated file, set it all up as a single level.

Do NOT let everyone have access to the Generic models! Limit the editing to a select few librarians.

Put the family tables in your Windchill Part Library for control. Set Windchill so all files in the Part Library come into a designer's workspace as Read Only.

Avoid Family Table assemblies unless you have thought out the full design up front. I did one of a plastic wire tray with a lid that was held on with studs and thumb nuts. The number of studs/nuts varied depending on the length of the part. The width and height of the tray were also variables. All component parts were in their own family tables. While it worked well for the first 8 assemblies, after that the number of columns to edit for a new instance became unwieldy. so we broke the assembly family table to individuals but left the components as instances. We reasoned that we would not be replacing one assembly for another that often, if at all.

The prior system admin here, who set up Windchill did not like Family Tables so there were few when I arrived other than sheet metal flat patterns. I have since added some for things like 1-1/2" stainless steel tubing that we cut into any number of lengths (28 last count). We have also done other tube diameters. Some that are individual files, 1" has 138 file, are not in a family table since it is just as hard to convert an individual part to an instance as it is to turn an instance into an individual file. There are a few other things in family tables but the common theme is different lengths.

I would love to move hardware into family tables but there are just too many to do. We did use Part Solutions and their modeling is terrible! We stopped using that when we went to Wildfire 4. Every feature has new datum planes that may duplicate an existing one. I am replacing them as we edit the file for other reasons. The also have about 3Xs the number of parameters in a sketch than is needed to define the shape and half of those are reference dimensions. Delete all of that junk.

Re: Best Practices for replacing Family Tables?

Hello Marc DeBower

thx for this topic, it´s realy interesting. Some basic operations from my point of view.

Where l will use Family table? (FT)

1. Make some dimmension diferent (length of screw, washer thickeness etc.)

2. Change string parameter value (drawing number, note etc.)

3. Suppress feater (hole at the end of bolt = YES/NO)

Where l can use FT and what are alternativies?

1) Make assembly settings. (part YES/NO)

      A) - use simply representations (cheap solution)

          - possibility to use graphic or geometry rep = less hardware demand

          - more flexible than FT

      B) - use Creo option modeler (costly solution)

          - Introducing Creo Options Modeler - PTC - YouTube

2) Unbend sheetmetal part (bend back = YES/NO)

       A) - l like thise trick Creo 2.0 Sheetmetal - Simplified Reps for flat pattern drawings

Some alternativies...

Have some other ideas, but don´t have more time



Re: Best Practices for replacing Family Tables?

Are you using As-Stored for retrieving models? Otherwise I don't see a way to require specific versions that could conflict. I can understand where users stamp on each other's work and make incompatible models where one version used to work, but a later version doesn't. That happens all too frequently.

Re: Best Practices for replacing Family Tables?


It is confusing, and seems to only come into play when you have a component family table going into an assembly family table.  For example if I have a model, COMPONENT.PRT with three instances and iterate (Check out, Modify, Check In) one of those instances, the generic and one instance is a different version.


This is fine by itself, and even when assembled into a regular assembly.  (Until you try to switch component instances in the assembly.)

However, the trouble starts when you have an assembly family, ASSEMBLY.ASM with three instances that use the instances from the component.  Now you have a mess.

  • assembly instance ASSY-1 that uses COMP-A at version 2.4 and needs the generic, COMPONENT.PRT at version 2.4
  • assembly instance ASSY-2 uses COMP-B at version 2.5 which needs the generic version of the component to be version 2.5
  • We end up with a conflict in the workspace of needing both version 2.4 and 2.5 of the generic component.