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

We are happy to announce the new Windchill Customization board! Learn more.

Managing Family Tables in Windchill

pwdmarshall
1-Newbie

Managing Family Tables in Windchill

Wondering if any of you have any wisdom you can share on managing Family
Tables in Windchill.

In our experience, typically when Revising any instance of a Family Table,
it requires the entire Family Table to be regenerated and hence every
instance must be Checked-In.

Today, where we currently use Windchill for managing CAD Data Only,
procedural work-arounds have been found - they have a "CAD Admin" Set
State to In Work on all instances NOT being revised, and then Set State
back to Released once the Family Table has been Checked-In.

However, as we look to bring WTPart data into the system, the implication
of using the Owner link from the instances to the WTPart is that any
Check-In of the instances requires the WTPart to also iterate, so that it
can push attributes to the WTPart.

That leaves us either having to take the same 'work-around' approach with
the WTPart, or to have to actually revise all the WTParts that have Owner
linked instances in the Family Table. Neither of these options are
particularly desirable, especially when you consider a Family Table with
50-100 items on it.

The other option would be NOT to use an Owner link, but in many cases we
need to pass attributes such as Mass back to the WTPart, so that doesn't
feel like the right answer either.

Those of you that are using Windchill to manage Family Tables today ...
how are you working with this? Are we missing some major piece of the
jigsaw puzzle here? Is there some golden config.pro or Windchill setting
we need so we don't have this administrative nightmare (but can still pass
attributes)?


Kind regards,
Paul Marshall
Business Analyst Principle - Corporate PLM

Cell +44 (0) 795 718 7014
paul.marshall@cummins.com
7 REPLIES 7
AL_ANDERSON
5-Regular Member
(To:pwdmarshall)

We are just now moving into the use of owner links from WTParts to Creo
objects. Our plan is to revise all members of a family table tied to the
same revision of a drawing as a new WTPart, along with all WTParts tied to
the other members of that family table tied to that same drawing revision.
This causes a lot of churn to change family table parts, but it keeps the
part revisions, drawing revisions, and family table generic and instance
revisions at the same revision for easy understanding of what "revision"
you are on when looking at etiher a Part, or a drawing, or a Creo object.
Our belief so far has been that use of the Collection rules associated
with the ECT revision process will make this mass of simultaneous
revisions management - which it would never be if we revised everything
one at a time.

Al Anderson
Solar Turbines Incorporated









[solutions] - Managing Family Tables in Windchill

Paul Marshall

Worth a read. Might still apply, there are follow ups in this blog later on.

Somewhere in WF5 - Creo Elements/PRO 5.0 (I think it's M050), there is a discontinuity regarding the implementation of family tables in Windchill. FT's created before this point have indeed to be revised completely, but only once! Once passed this point, or when creating new FT's after this point, there is no need to revise all instances for the sake of one instance. So, there is no issue with WTParts as well.


Regards, Hugo.
<< ProE WF5 - PDMLink 9.1 M060>>

Hello,


Weatherford also use Associations between CAD data and WTParts, we are also managing our Enterprise (not the same as Engineering) Change Process using Windchill. We have a lot of legacy data in the system that utilises family tables, so we have had a good number of discussions around the relative merits of how best to handle them. Our Change Process had always required that when any document (EPM or WT) that “describes” multiple WTParts is being revised, then all the WTParts must be included on the change. We have adopted the same approach with Family Tables, so forcing all the instances to be revised if one is. For our process this isthe best way to handle modifications in a controlled way.


Managing all the data in Windchill with associations to WTParts has also made us question the merits of using Family tables in the first place, we don’t have any hard or fast rules in place and we continue to support Family Tables being used. But we generally agree with our colleagues in Engineering that Family tables make (some) sense when they are for identical geometry, like in the case when you have the same exact part made from different materials, or finished in different colours. However, dimensional parameter changes are better handled using separate files. We have exploded many family tables into separate files since moving the CAD data to Windchill, we have a home brewed script based solution to take some of the grunt work out of it.


My personal opinion is that Family Tables are a legacy concept that doesn’t really fit any more in the newer toolset. In nearly all cases any time you might save by using family tables is more than outweighed by the extra time involved in taking care of the data management complexity that is unavoidable with their use.


In other words they are a right pain inthe behind and in most cases they are not worth the hassle.


-----

Lewis




In Reply to Paul Marshall:


Wondering if any of you have any wisdom you can share on managing Family
Tables in Windchill.

In our experience, typically when Revising any instance of a Family Table,
it requires the entire Family Table to be regenerated and hence every
instance must be Checked-In.

Today, where we currently use Windchill for managing CAD Data Only,
procedural work-arounds have been found - they have a "CAD Admin" Set
State to In Work on all instances NOT being revised, and then Set State
back to Released once the Family Table has been Checked-In.

However, as we look to bring WTPart data into the system, the implication
of using the Owner link from the instances to the WTPart is that any
Check-In of the instances requires the WTPart to also iterate, so that it
can push attributes to the WTPart.

That leaves us either having to take the same 'work-around' approach with
the WTPart, or to have to actually revise all the WTParts that have Owner
linked instances in the Family Table. Neither of these options are
particularly desirable, especially when you consider a Family Table with
50-100 items on it.

The other option would be NOT to use an Owner link, but in many cases we
need to pass attributes such as Mass back to the WTPart, so that doesn't
feel like the right answer either.

Those of you that are using Windchill to manage Family Tables today ...
how are you working with this? Are we missing some major piece of the
jigsaw puzzle here? Is there some golden config.pro or Windchill setting
we need so we don't have this administrative nightmare (but can still pass
attributes)?


Kind regards,
Paul Marshall
Business Analyst Principle - Corporate PLM

Cell +44 (0) 795 718 7014
paul.marshall@cummins.com






BenLoosli
23-Emerald II
(To:pwdmarshall)

I have always found it best to force a change to the whole family table and then check them in.
Restrict who can edit family tables.
Limit what you put into family tables to things that are in a Library, like families of fasteners or similar items.
Avoid multiple layer family tables...generic-5 instances-1 of those have its own 3 instances. Keep it simple!
Product family tables can be created, but you need to revise them all every time you revise any one of them. This way you don't end up with 3 instances at rev 5 and 2 at rev 3 and 1 at rev 1.

Hey Greg,

Almost correct. Family tables prior to WF5 M??? in Windchill 9.1 M??? have to be checked out and back in ONCE with ALL the instances. If you have sufficient permissions, e.g. you do it as an administrator, you don't have to revise at all. After this one time check-in of the complete FT, you can again revise and check-out/in one instance at the time, whether or not it fits into your business processes (cfr. Remarks of Ben).

Regards, Hugo.
Top Tags