Family Tables - Modify permission on General for Verify

[MikeLockwood]

We're finally moving from Creo Elements Pro WF5 to Creo 3 (with WC 10.1)...Taking a close look at all processes and configurations.

Since first starting to use Windchill, we've always had a process that seems to be required but is a terrific nuisance.  Wondering if it's different (haven't tested yet) in Creo 3 and wondering if there is a smarter way in general to handle.

SITUATION

- Family Table with different Revisions allowed for each instance (not all companies allow this but many do)

- In general, Generic and all Instances Released; approved change must be made

- User assigned to make the change

    - Revises the Instance(s) that are changing and so can Modify them at In Work

    - Does not Revise the generic

    - Cannot Verify the family table with modified instance(s) without Modify permission on the generic

CURRENT PROCESS

-  A user with needed permission temporarily Sets State of the generic to In Work

- User assigned to make the change does so, including family table verification and check in of the generic and instance(s) being Revised and modified

- User with needed permission Sets State of the generic back to Released

- The instance(s) being changed are released via the Change Notice workflow

PROBLEMS

- Difficult to make sure that the generic always gets set back to Released

- Not good to have a group that can bypass controls and processes by being able to Set State to Released

How do others handle this?

Appreciate any input from PTC - especially if already documented somewhere.

thanks in advance

[rjones]

Our instances have different revisions as well. I am curious to know your requirement for not revising the generic.  The generic should not drive any parts that reside in a bill of material, it is a collector of instances for the most part (realizing it takes the generic to build all the instances).  We always revise the generic when one, two, or all instances are revised. The generic is a resulting object the same as the instance and is released upon approval of the CN. There are a few rare cases where a single instance can be released/revised without releasing/revising (verifying) all the instances but the generic always goes with it.

[MikeLockwood]

I stated this a little bit wrong.  Corrected here.

- We do in fact always Revise the generic, and only use generics for real parts for sheetmetal.

- It's the instances that are not Revised that are the issue.

Example

- Simple family table consisting of for example: Generic, 001, 002, all at Rev A Released.

- Need to make a change to 001only

- The generic and 001 get Revised to Rev B, In Work; 002 is not to be changed

- But, In order to Verify the family table, 002 has to be temporarily at In Work

- The generic and 001 go to Released at Rev B on normal Change Notice workflow

- 002 has to get put back to A Released via set state

[BenLoosli]

I find the concept of modifying only some instances in a family table, assuming it is a part FT, not assembly, as being against the intent of using family tables. The Generic should drive all instances, within parameters that are used to drive the instances. I have found it works best to always modify and check-in the generic and all instances. Newly added instances may be at a lower revision than the generic. I typically put family table parts in a library where the general uses have read-only rights and an admin or librarian or the only ones who can modify the FT.

[MikeLockwood]

Good points. Major "policy" decisions to be made for every company. Seems that most of us make these decisions w/o enough in-depth knowledge or understanding of the consequences.

This one deserves a second look here.

Still very interested in comments on this from all.

[BillRyan]

You will be very interested in the query reports I'm trying to develop!

Instances Residing in folders different from the Generic

Instances deleted and (not residing from the latest version
of the generic + residing in the latest version of a where used assembly.)

Unverified or Unknown Instances at Latest Iteration

Partially Checked out Family Tables

Instances not Iterated/Modified at the same time as the
latest Generic (Can Use Modifier Name or Last Modified)

Partially Released Family Table Instances if latest version
of generic is released.

Instance Accelerators modified Date not equal to last
modified of Cad instance document.

[HugoHermans]

Hi Ben,

Of course you can choose to always checkout the full family table when something needs to be modified, even for one particular instance.  But Windchill only demands this when you have to add an additional column to the table in the generic.  This additional column modifies implicitly every instance, so they need to be updated.

I'm with Russell, to take along the generic with every modification of an instance.

Apart from that, there is the aspect of association with a WTPart.  Our approach is to always associate both the instance and generic, the instance as owner or contributing image.

Regards,  Hugo.

[rjones]

Just to clarify Hugo, as you said, a column being added to a family table will force the verification of all instances. A column does not have to be added to a family table to force the verification of instances. A modification to a feature that is not tabled (it applies to all instances) will also force the verification; along with layer changes, new features, removal of features, sneezes, coughs, etc.   Basically there are a few rare situations where specific instances can be revised without affecting the other members of the family. Adding a new instance as long as new features or additional columns are not added, removing and instance as long as features or columns are not removed, and modifying existing tabled values will allow only the revision of the instance AND generic without verification of the other instances... if the user is careful...and doesn't have a cold .

I am not sure what association you have between your Wt Part and the generic. For us, there is no association between a generic and a Wt Part. The viewable is not accurate as it includes all the instance variations and the generic is not in a bill of material. Typically our generic has the same number as the first instance with an extension of "_gene".  Example:  Wt Part = 12345,  CAD generic = 12345_gene.prt - no link, instance 12345.prt owner link

I will admit that we have done some customization to "unlock" instances that are not true revisions but forced to be verified by the actions mentioned above. This customization was put in place to handle our legacy data with plans to eventually remove this option. The use of flexible features and/or inheritence models should be used in place of family tables whenever possible. Family tables work well in certain circumstances when either a revision to one SHOULD revise all, or to populate your family table with columns of all features that may need to change in the future so as to allow the revision of only one without affecting all.

[HugoHermans]

Hi Russell,

The reason to associate the generic to the WTPart along with the instance and drawing, is to have them all available when revising, when promoting, when copying.  For the same reason, we associate the driving skeleton along the assembly, or envelope parts.

Apart from that, I think you are right, I will pay some attention to my users and adjust my perception.

Thanks, Hugo.

[TomU]

Ben Loosli wrote:

I find the concept of modifying only some instances in a family table, assuming it is a part FT, not assembly, as being against the intent of using family tables.

As with all things Creo/Windchill, it depends.  We have a lot of family table parts that have unique drawings for every instance.  Each drawing is independently approved and released.  When  a new instance is added, or some table-controlled value is altered (for an existing instance), there is generally no reason to go back and revise, update, and re-release all the other non-changed instances.  Fortunately, Creo + Windchill handle this fine and only require the changed instances (and the generic) to be revised, checked out, and re-verified.

Keep in mind, I'm not saying you should do things this way, I'm just saying that it is possible, and does work okay.

[MikeLockwood]

More on this...

I created a document, attached, that goes thru a simple example, using a family table with just two instances.  It walks thru each step twice - without and then with WTParts.

Given the decision that instances can be at different Revisions, it seems like there must be a better way than to Set State on all the Instances which are not being changed - and having all of them get iterated.  More discussion here about abandoning Family Tables completely, but that would be a long-term project.  Meanwhile, we're attempting to make this process as good as it can be.

Note in the attached that we're doing some things that absolutely should not be done but don't see any way around them:

1. Every instance which is not changing is brought from Released to a working state, then brought back to Released, creating (for some active family tables) many iterations at Released for a given Revision.

2. Users must have permission to Set State of Released objects to a working state and then back; cannot easily not allow them to Set State on any object to Released, working outside of any change process.

We've been doing this for 8+ years but I never really looked at it until recently.  Looking for feedback if my document really captures things correctly and whether there is another way to approach (given the decision that instances can be at different Rev's).

[TomU]

I wonder if there is a preference set different.  We don't have any problem with this.  We do require all instances to be verified before check-in.

Video Link : 6443

P.S.  Just talking about CAD Docs.  We don't currently use WT Parts.

[RandyJones]

Tom Uminn wrote:

I wonder if there is a preference set different.  We don't have any problem with this.  We do require all instances to be verified before check-in.

How do you "require" all instances to be verified?

[TomU]

Looks like it's actually a Creo config setting, not a Windchill setting.

verify_on_save_by_default yes

We have this set in the company-wide config.sup (so users can't override it)

https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS62074

Config option to deny checkin of unverified family tables

[RandyJones]

Tom Uminn wrote:

Looks like it's actually a Creo config setting, not a Windchill setting.

verify_on_save_by_default yes

We have this set in the company-wide config.sup (so users can't override it)

https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS62074

Config option to deny checkin of unverified family tables

I see.

I though maybe you had figured out a method in which Windchill would not allow checkin unless verified like one could setup Intralink 3.x to do. This is one of the few biggies of missing Intralink 3.x functionality in Windchill PDMLink. The problem with setting verify_on_save_by_default to yes is some family tables take a long time to verify and when in the design phase (many changes and saves but no checkins) it is better to only verify once when finished and then checkin.

[BenLoosli]

You can also set up ModelCheck to verify that any family table being checked-in has been verified and set it to reject the check-in if they have not.

[RandyJones]

Ben Loosli wrote:

You can also set up ModelCheck to verify that any family table being checked-in has been verified and set it to reject the check-in if they have not.

That seems like a very heavy solution for a very simple check however I am not familiar with model check. From what I do know is that to do this one would have to:

1. configure modelcheck
2. have modelcheck running on ALL clients
3. family tables would have to opened in Creo Parametric in order to have modelcheck do its thing
4. some other steps maybe??

vs having a preference in Windchill PDMLink to set in one spot with nothing needed to be run on the client

[MikeLockwood]

Aha - Checkout of non-changing instances not required using an Empty PRT rather than and Alcon start PRT (without changing any preferences).  Our start part has all kinds of stuff - trying to isolate what is causing this now.  May be related to multiple versions of the generic though, so will study some more.