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
