New Revision of family tables - PDMlink 9.0

[ptc-457507]

Hi,



I've been told by PTC the following functionality is not possible -



In PDMlink 9.0 when you do a "New Revision" on a family table item there is
no way to Set the state of the other family members to "In work"
automatically.



So..if you are not uprevising the whole family the other members remain at
RELEASED and the users cannot checkin/out the whole table.

Having to do a "Set state" on the other instances is a nuisance.



This was not the case in Intralink 3.x. Has anybody else came across this
problem ?



Cheers

Jamie

[HugoHermans]

Hi Jamie,

Maybe I don't understand 100% your question, and maybe has our approach
to be reconsidered, since we are still in 8. Anyway, this is how I try
to teach our designers to handle family tables in Windchill.

First, you have to treat the generic differently from the instances.
The generic has always to be revised, whatever happens. This means that
generics may never be used for other purposes then for generating
instances.
Second, if you simply want to add an extra instance, only the generic
have to be checked out.
Further, if you want to change an existing instance, without changing
the table, you checkout the generic and the instance to be changed.
Finally, when the table changes (additional columns), all the instances
are affected, and so have to be checked out.

Can you give it a try, and give some feedback, since the approach above
is only proven in 8.

Regards, Hugo.

[matthew.yacono]

Jamie,

We use state based versioning as well and experience the same issue.

The safest best practice we follow is that a family table must be completely verified in Pro/E before it is checked back into Windchill. This requires all instances and generic to be at a modifiable state. This is usually done by revising the generic and instance(s) we intend to change, and setting the state of the other instance(s) to a modifiable state without changing the revision.

Matthew Yacono (x7559)

[BenLoosli]

body{font-family: Geneva,Arial,Helvetica,sans-serif;font-size:9pt;background-color: #ffffff;color: black;}
Are you using family tables for more than standard items?
What we did was to put family table items in a Library and make the Library RO to all of the users.
The family table itself is never released, as the Library protects it from accidental user chnages.
A good practice is to always change something that causes the all of the instances to be updated and checked back in.

Ben

[ptc-457507]

Hi Hugo,



Sorry for the late reply.



We use family tables for 2 things:



- Standard parts. i.e Nuts & Bolts. We have no problem with this because
all instances are up revised so go to "in work".



- Familys of sheetmetal panels.



It is this second category causing me the problems. Usually if one instance
needs to be up revised the whole table has to be at "in work" to allow it to
be verified. (The other instances are not being up revised with the generic
unused & unreleased).



I have a user level of "Approver" it's actually the document controller -
who does up-revisions for me. In Intralink there was no problem. Instances
automatically changed to "WIP" now I find myself having to do a "Set State"
on these family tables, which means I would be as well doing the up
revisions myself.



I logged a call with our maintenance provider (PTC reseller) to come up with
a fix. Giving my "Approver" Set state rights would have solved my problem.
It seems the "set state" function is only available to objects created in
Windchill but not migrated data.



So, first a "Reassign Lifecycle" has to be done on the Family table before
the approver has the rights to set state



( Still with me....)



"Reassign lifecycle" can only be done by an admin as well so alas that is no
good. So, I'm back to square one.



Reading your situation, are you getting round this by allowing non-verified
tables to be checked in ?



Regards

Jamie







_____

[HugoHermans]

Hi Jamie,

Sheetmetal is to a certain extent an exception. When you have to simple
bended part with a flat state, the flat state is the instance, and the
bended part is the generic. In this case, it's obvious that you revise
and check-out the complete family table, beiing two parts.

As soon as your sheetmetal part as family tabled as such, regardless the
flat states, I advice our users to build the family with isntances for
the bend state and for the flat state. So, you will end up with a flat
list of an even number of instances.

Regarding verified instances. It's a fact that you can't check-in a
family table that isn't completely verified. But if you start from the
fully verified family table, and you simply add an extra instance, the
verified instances stay verified. In this case, I see no need to check
them out. I think this should solve your problem (unless you can't
reproduce wha I'm saying ... 😞

Regards, Hugo.