Family Table Settings - PDM Link

[ptc-1077260]

WF 4.0 M060

PDM Link 9.0 M010

We introduced PDM Link about a year ago. During this implentation, we brought in several family tables of common hardware components. We have been running into a major problem. The problem is that when we need to revise an instance of the family table, we are required to check out and revise all instances of the family table. For instance we havepin type component and a diameter tolerance needs to be changed for one size. This currently requires all instances to be revised and checked out.We are looking into possibly putting tolerances into the family table itself as well as looking through the config.pro options to see if there is something in there that we can change. I am assuming others have this pain out there? Any clues?

A suggestion was to set this create_drawing_dims_only" to Yes, but that will tie our hands.

Thanks,

James

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.

[HugoHermans]

Hi James,

Handling family tables in PDMLink isn't easy nor straight-forward, but what you describe isn't correct. At least, to a certain point. As long as you haven't to add an extra column to the table, you only check-out the generic and the instance to be changed. Adding an extra column affects all the instances, even if they aren't changed geometrically, so in this case you will have to check-out all the instances.

For this reason, I advice my users not to use the generic in any other way then producing instances. In the revise/promote cycle, the revision of the generic will by augmented by each revision of an instance. Anyway, if you are dealing with a set of parts that could be considered as a family, but with a high expectancy for changes of the instances, consider the use of inheritance feature as an alternative.

Regards, Hugo.

<< ProE WF3 M190 - PDMLink 8.00 M040 >>

[HugoHermans]

Compared to the simple-part-with-drawing case, family tables add an
extra dimension of complexity to their data management. When you go
into assembly family tables, or even nested family tables, you have to
be very very proficient and carefull in the procedures to be executed.
We haven't had any software issues as such, but lots and lots of issues
caused by human mistakes.

Actually, we are on Windchill 8.0 (with Wildfire 3), and preparing to
upgrade to Windchill 9.1. I haven't tested the following case in
Windchill 9.1 yet, a case that leads to a dead end in Windchill 8.0 :

You start with a family table AABBCC.prt with 3 instance AA.prt - BB.prt
- CC.prt
You assemble instances BB.prt and CC.prt to the same assembly
You check everything in.

Then, someone else makes a mistake :
He checkes out AABBCC.prt
He removes instance BB.prt
He checkes back in.

Later, you see in your workspace some out-of-dates, and try to update.
Since both instances refer to a different iteration of the generic, you
are unable to update the workspace.
But you need both instances in order to have the assembly resolved.
So you decide to add a new instance with the same name, what Windchill
will refuse to do.

The work-around is the replace the cullprit in the assembly by a new
instance, rename it to a cryptic set of characters and throw it into
oblivion.

Met vriendelijke groeten,
Kindest regards,

Hugo Hermans

-

NV Michel Van de Wiele
Michel Vandewielestraat 7
8510 Kortrijk (Marke)
Tel : +32 56 243 211
Fax: +32 56 243 540
BTW BE 0405 450 595
RPR Kortrijk

[kwsauter]

I have learned from hard experience that generics are good for nothing
other than creating a glom of everything that shows up anywhere in a
family table. And then you have to make certain that all assembly
constraints are not tied to instances where a parent component is
suppressed for a child component in another instance. It takes quite a
bit of management skill to make a family table work properly in the
first place. It shouldn't be this hard to use this very expensive piece
of software to do a relatively straightforward job. Expensive software
should save us time and aggravation, not cause it.


Ken Sauter
DRS Reconnaissance Surveillance and Target Acquisition
Infrared Technologies Division
PO Box 740188
Dallas, TX 75374
214-860-6826
- <">mailto:->

[ptc-1077260]

PTC Gurus,

Thank you for all the suggestions. I am intrigued to learn more about the inheritance modeling that Mark von Huben suggested. However, we mostly use family tables for simple shared hardware components so the features that are dimensioned are only a handful (length, diameter, shoulder height, etc). Since these are easy, we had success in adding the tolerances of these features into the family table and as long as all dimensions are "shown", it works out.


James

[JoshuaHouser]

Hi James,

Inheritance features are one of my favorite topics J



For more info you can review this thread