Skip to main content
P
pintopower1-Visitor
1-Visitor
January 28, 2014
Question

Family Tables - Best Practices

  • January 28, 2014
  • 2 replies
  • 1508 views

Hello,


I have been tasked to fix the catastope that a number of engineers have created while making family tables. External refernces, unverifiied instances, overly complex instances (in my opinion) and unrelated part instances. I am looking for some information on what you all feel would be a best practice on the creation and management of family tables. I am working on a new Windchill deployment so it is critcal that these family tables be clean. I have a number of my own ideas but I am curious to see what some of the more seasoned users have done. I am certainly not an expert on the "Family Table" so I am hoping some of you experts can enlighten me.


Thanks,


Alberto M.


Senior Mechanical Engineer


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.

2 replies

J
jstone12-Amethyst
12-Amethyst
January 28, 2014
Alberto,
In addition to cleaning up external references & unverified instances get every instance in the table up to the same revision and add any additional parts that would complete the family table. There are previous threads that discuss family tables and usage with a PLM system (Windchill). I agree with most that family tables do not work well with PLM systems in regard to rev. control and adding new instances/updating existing in addition to causing failures during PLM system updates and migrations.
Thanks,
jef
K
kimndave91-Visitor
1-Visitor
January 29, 2014

Alberto,


I feel your pain.


Simple parts family tables are not too bad, like for a series of fasteners. It's when users start creating things I'd call similar tables, not family tables. Cases where members of the family share no characteristic, but have had components and features glommed on or deleted.


For similar tables, the first step I use to manage it is to name all the parts and features with something significant. I can see it's a nut or a bolt - what's it in the assembly for?


Second, I group all the items that are there for a purpose - so a lid, its gasket, the screws, and washers are grouped into a lid_install group.


Then I look through the family table and match against the named items to see what columns could be eliminated from the table and replaced as part of a group column.



One thing I have found to be unhelpful is that instead of failing a defective instance on opening or retrieving it, WF5 just marches along. It takes some time to figure out why an item that is included in an instance row isn't displayed or retrieved when the reason is a dependency on an item that is not in the instance row. Instead of complaining it can't be placed, even during verify, related items just quietly dissappear. I've seen cases where a pattern of fasteners quietly collapses due to a lost reference and users fill in all the empty places. I can imagine the same thing happening with lost components in instances.


My best rework so far is 139 unnamed columns for a dozen instances. Since it was a similars table, not a family table, it only came down to 80 columns or so. No doubt others have come up with worse.



Another method that works well is to include a conditional via Program. The family table can have a value to control the Program. Groups work more easily than they did in previous versions, but Program can still be of great help. This is mentioned in http://portal.ptcuser.org/p/fo/st/topic=3&post=88178#p88178, courtesy of Guilherme Rocha.



What would help is if there was a place in the model to include a write-up of how the model works, in plain text. Something to give users a heads-up and act as a reminder. Same goes for any number of complex uses.



**************Search of PTCUser for "family table" ********************


Some interesting ones about the tables, not about repeat regions.


Michelle McMasters
Summary: To Family Table, or Not To Family Table
February 11, 2005 03:43 PM


http://portal.ptcuser.org/p/fo/st/topic=19&post=12753#p12753



Use Family Tabled UDFs to Speed Design and Reduce Drafting Effort
Last Updated By: David Haigh on Jun 05, 2009


http://portal.ptcuser.org/p/do/sd/topic=405&sid=533

Terms & ConditionsAccessibility statement