Mange Family Table in Windchill ?

[hsuryaprakash]

In Windchill , we have mapped part_name & part_number as an attribute .

File name : Cad Name

Number : part_number

Name : part_name

So that, the attribute will be updated in Windchill based on the value assigned in the parameter list inside the care (Tools-Parameter).

In family table Generic & Instance, we have assigned the value for part_name & part_number (Ex: Part_name: Plate, part_number: 12345).

The value remains same for Generic & Instance.

Since, the parameter part_number: 12345 is same for generic & Instance (Note: enabled WT Parts), not allowing to upload.

It is showing error like"CAD part is not unique".

And we can't assign different part_number for generic & Instance as per our standard.

So, I want to know the best way to handle the family table part like above mentioned scenario

[BenLoosli]

Revise your company standards!

The generic ahould be named something that relates to the family type (SHCS.prt) with the instances having the unique names (1254586.prt).

Also, a generic should NEVER be used in an assembly, only an instance. I usually create the generic with weird values just to force the designers to use an instance from the family table.

[kpritchard]

Building on Ben's response... a WTPart for a generic should not be needed. (this may address the issue you're having).

Fully agree on the approach for generic/instances. Unique values of part_number and part_name for each instance and you could probably leave these blank for the generic.

[ahamblett]

We have a generic w/ multiple lengths, defined by dash number, and the issue we are running into is when we release the generic and all existing dash numbers, w/ assoc. .drw, additional dash numbers can not be checked in unless the entire dataset is in an uncontrolled state. Thus, a change notice must be written against the entire package in order to add new dash numbers. As opposed to just releasing the new dash numbers via a Release Notice. Apparently, this is due to model check. In other words, if new instances are to be added to the generic family table, ALL instances must be in an unreleased/unlocked state so that modelcheck may run. Is our only option advancing the revision of the entire dataset? Or are there any other suggestions?

[dschenken]

This is because there is only one CAD file for all the items in the family table. It's a sort of fiction that there are any other parts. The problem of control is that PTC doesn't have a way to tell if changes made to the one CAD file affect all the fictional parts or not. In a way it is more like a copy of a specification, where adding additional items revises the specification, including all existing items covered by the spec.

Even so, I thought one could request that only the generic and a subset of instances be subject to revision.

An alternative is to use inheritance where there is a primary part from which others are derived. This would allow multiple children parts, each with their own revision scheme. OTOH, if a change is made to the primary part there is no guarantee the children parts will be correctly revised.