Skip to main content
M
MikeLockwood22-Sapphire I
22-Sapphire I
October 12, 2015
Question

Family Tables - Modify permission on General for Verify

  • October 12, 2015
  • 4 replies
  • 5866 views

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

    4 replies

    R
    rjones1-Visitor
    1-Visitor
    October 12, 2015

    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.

      M
      MikeLockwood22-Sapphire IAuthor
      22-Sapphire I
      October 13, 2015

      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

      B
      BenLoosli23-Emerald III
      23-Emerald III
      October 14, 2015

      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.

      M
      MikeLockwood22-Sapphire IAuthor
      22-Sapphire I
      October 14, 2015

      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.

      B
      BillRyan16-Pearl
      16-Pearl
      October 14, 2015

      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.

        M
        MikeLockwood22-Sapphire IAuthor
        22-Sapphire I
        October 21, 2015

        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).

        T
        TomU23-Emerald IV
        23-Emerald IV
        October 22, 2015

        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.

        R
        RandyJones20-Turquoise
        20-Turquoise
        October 22, 2015

        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?

        Terms & ConditionsAccessibility statement