Our weekly Did You Know series focuses on providing users with informative, “how-to” tips to help them get the most out of PTC Creo. This week’s post, provided by Director of Product Management Paul Sagar, shows users how to create family tables in PTC Creo Parametric. Users will learn how family tables enable you to create a large number of common parts quickly, based upon a generic design model.
Family tables are a collection of parts or assemblies which are similar, but deviate slightly in some aspect – such as size or included features. Bolts are a common example because they look similar and perform the same function regardless of their properties. It’s helpful to think of them as a family of part models. Parts in family tables are also known as table driven parts. In PTC Creo Parametric, you can create family tables in three easy steps.
Step 1: Identify Features Which Will Vary
First, you must identify which dimensions or features will vary for your family of parts. Click on the Model Intent overflow menu and select Switch Symbols. This will show you the symbolic name of the features dimensions in your generic part (such as size or depth). From here, you will know which dimension will be altered in your family of parts.
Click on the Switch Symbols command under the Model Intent drop down to understand the names of the dimensions in your part. This will help you identify what you need to change.
Step 2: Create the Family Table
Go back into the Model Intent overflow and select Family Table. Click Add Columns in the family table dialog box. With Dimension selected in the Add Item section, click on a feature in the model, and then select the dimension you wish to add to the family table.
From the Family table command, we can choose which parameters we want to alter in each of the instances we create.
We can also add parameters into our family table (such as descriptions). In the Add Items section, click Parameter, then choose what you want to add (description for instance), and click Insert Selected. You can see the parameter has been added to the table. Parameters added to the table can be edited in each of the part instances. You can also add features from the model tree, which can be included or excluded in the part instances.
Step 3: Edit Instances
After choosing the parameters, we can chose the number of instances we want in our family table. Simply click Add Instances until you have the desired quantity. You can edit the parameters for each specific instance. To finish the table, click Verify instances. This will tell you if your changes can be regenerated. Finally, you can preview or open each instance by selecting the appropriate row and picking Open. In the family table menu you can edit and verify the specifications on each instance you will create. You can also preview each part.
In the family table menu you can edit and verify the specifications on each instance you will create. You can also preview each part.
In conclusion, family tables give you an easy systematic approach to creating a large number of related models.
Check out our video tutorial on the PTC University Learning Exchange (“Creating a Family Table”) to see this advice in action. We’d also love to hear your suggestions for working with family tables in PTC Creo Parametric.
For more in-depth product feature explanations, visit our Tech Tips area.
Have some ideas about what PTC Creo product features you’d like to learn more about? Send me a message or leave a comment below and we’ll write up the best ideas from the community. Thanks for reading, looking forward to all of your feedback!
In case you missed it, here are our recent Did You Know posts:
1) When will it be possible to control appearances via materials assigned to family table members?
Currently T.S. reports (through Creo 2.x) that it is intended functionality that family tables support material assignment, but model evaluation does not support the related material appearances. Since controlling color via family table has been the most frequent unique request going back to rev 13, this would seem to be a nice capability to have.
E.g. electrical assembly standoffs are often available in steel, aluminum, and nylon and it is important to tell at a glance that the correct material is used.
2) Silent fails need better handling. It is irritating to have a complex assembly lose a number of parts because a family table item could not be placedor regenerated, causing all downstream items that depend on it to be silently suppressed. It drastically increases debugging time to determine where the flaw is when the error is covered up.
3) Feature groups are very handy for collecting items. A single group can replace dozens of items in a family table, collapsing dozens of columns into a single, manageable column. However, feature groups are considered features, not groups, which is not obvious when Group is a family table selection. Also see (2) above.
4) A high leverage control can be had by adding a parameter to a family table that is used in a Program relation. This needs to be coupled with moving Pro/Program visualization into the family tree. Presently, re-ordering items in the family tree causes unexpected edits to the Program, such as silently introducing additional If/Endif blocks that circumvent Parameter control.
5) When working in an instance, it is less important to be warned about changing a value controlled by the family table than it is to be warned about changing a value that is common to all members. Think about it this way - the user can see the value change in the instance immediately and determine if that is desirable. If it affects all the instances though, the user won't know if damage has been done to other members, even if the verify as OK. The better interface would allow the user the choice to dynamically add the dimension to the family table.
In the second to last pop up, you select the generic. All other names need to be continuous except "The generic". When you go to select this, you have to click and drag instead of double clicking because it is not continuous. This is especially true if you have a lot of instances and you can't easily pick them out of the table. See suggestion below:
Also, when opening an generic from an instance it always asks if you want generic. Could you change this to a three teired option: the generic, the instance your currently at, and another instance. See this suggestion:
6) When working on a family table, when the table is opened, most of the time the column widths need to be adjusted to make them wide enough to either read the contents or the titles. The columns widths are not persistent (to WF5) so any adjustments made are lost when the table is closed.
We use Creo with PDMLink, we have the Creo instances data attached to the ebom PARTS (linked to the mbom PARTS) for design & catalog data and when we modify an instance (revision of generic and modified instance), we use a specific state to allow modification of "non modified" instances and the associated PARTS (minor modification). This change of state, it's very risky, we unfreeze the eboms... and the state change of PARTS provokes the creation of a new version and the link between the ebom and the mboms is broken!
We decided to start an analysis to replace the Family Tables because it causes too many risks and constraints in our context!
When in WF5, the ProWorkAround, is to set the column widths, open one of the instances, save that instance, then typically (about 95% of the time) the column widths of the generic are kept.