Skip to main content
S
sjohnson-31-Visitor
1-Visitor
July 17, 2014
Question

How to maintain same revision level while added a family table instance?

  • July 17, 2014
  • 13 replies
  • 5462 views
Does anybody have a solution in Windchill for added a family table instance to a generic while still keeping the revision of the generic and all existing instances the same? Currently when we have the need to add an instance it falls on the WC admin to set the state of the generic and all instances from Released to In Work, and then the designer adds the new instance, Checks In, and generates the Promotion Request. Upon approval the generic and all instances are back to Released at the same revision. We are trying to offload this burden from the admin to a standard workflow practice for all designers.

Ordinarily this would involve a Revise, but we cannot burden our CNC programmers here with updating all revisions to existing programs whenever we add an instance (the existing instance geometry is not changing, essentially we are just generating a new object). Further to this logic we want to keep all instances, the generic, and drawing lock-stepped in revision. New instances come in at the latest revision level of the rest of the existing instances, and any global geometry change that affects all or most of the family table instances would then follow the typical Revise workflow, taking all objects up to the next revision letter.

Thanks

Sasha Johnson
Sr. Design Engineer
[cid:image001.jpg@01CFA11C.65B32830]
Russ Bassett Corporation
8189 Byron Road
Whittier, CA 90606
Phone 800-350-2445 X 3345
Fax 562-447-2228
sjohnson@russbassett.com<">mailto:tsimon@russbassett.com>
www.russbassett.com

13 replies

S
SteveVinyard1-Visitor
1-Visitor
July 17, 2014
Just to clarify, you have a generic (with many instances) and a drawing linked to it. The drawing shows the revision of the generic model. Both are released. You need to add an instance and when you revise the drawing shows the new revision. This causes issues downstream in production.

S
sjohnson-31-VisitorAuthor
1-Visitor
July 17, 2014
Correct. The generic (with many instances) and the linked drawing are all released at the same revision. The drawing format shows the revision of the generic. A revise bumps the revision which is not acceptable to production, as it burdens them with revving up all existing programs when in fact their geometries did not change.
K
kimndave91-Visitor
1-Visitor
July 17, 2014



In Reply to Sasha Johnson:


Correct. The generic (with many instances) and the linked drawing are all released at the same revision. The drawing format shows the revision of the generic. A revise bumps the revision which is not acceptable to production, as it burdens them with revving up all existing programs when in fact their geometries did not change.



To add an instance requires modifying the generic, if only to add features that are suppressed. If your system is such that it requires the generic and related instances to be released before manufacturing, then to add the instance requires a new revision of the generic.


There is no good method to prove that some change that affects the generic and all its instances does not occur when the addition is made. Change layer display, change accuracy, some other change, and all the items in the family table can be affected during the addition of the instance.


It seems like having the Admin involved to manually override is the best choice.


x

S
SteveVinyard1-Visitor
1-Visitor
July 17, 2014
I'm not sure that the generic is required to be released or not though the situation around the tabulated drawing is challenging on how to handle that. I've seen people just not release the generic or drawing but it's tricky if it's tabulated.

M
MikeLockwood22-Sapphire I
22-Sapphire I
July 17, 2014
We've been living with this every day for 7+ years - and looking for a way around - but haven't really found anything elegant and foolproof. It's a fundamental constraint of using Family Tables with Windchill.

////
Each company has to make a fundamental decision, then document it clearly, train users and enforce methodically (we use the 2nd):

- Generic, Drawing and all Instances at same Revision

o Generic attributes drive the drawing format cells and geometry shown on drawing

o Instances generally tabulated on drawing

o All Revised together every time
or

- Generic and Drawing at same Revision, each instance at an independent Revision

o Generic and Drawing at same Revision; these Revised every time any Instance is Revised or added

o Instances generally tabulated on drawing

If you choose the first, the issue sort of goes away since all are Revised every time - but the downsides that you list below are significant.

If you choose the 2nd, need a way to manage the Generic and Drawing, as you say. We've tried various approaches. Currently doing this:

- Lifecycle includes Set State transition from Released to the working state

o Set state permission at Released given to a select small group of users (design leads). Set State done on Generic and Drawing.

- Designers who need to work request Set State using the Discussion Forum on the Generic. Posting done by the Design Lead using standard wording.

- Designer requests Set State back to Released when finished; Posting done again by Design Lead using standard wording.

- We built a query builder report for discussion forum postings and periodically run this to "find" any postings that have the 1st action but not the 2nd action.

Interested in how others have approached this.
D
DonSenchuk12-Amethyst
12-Amethyst
July 17, 2014
If I understand what you're asking...

(Generally this sort of thing is reserved for library parts like fasteners and such, but since you didn't specify I'll just assume it could happen to any CAD Doc.)

I think it could be set up in a customized workflow of some sort. It would be a bit involved to get it running, so I suppose someone would have to decide if it's worth the time investment.

First thing it would require is changes to the life cycle template's transitions. Typically, something in a Released state has one transition, Revise, used to advance the revision to the next value in the sequence. For the task you're talking about another transition could be added, probably Set State, to change the CAD Doc from Released to In Work. Once that is set up and applied to all the relevant CAD Docs, then a workflow could be crafted to take advantage of this. It would be custom, of course, but I'm not really sure if it would be best to base it on one of the Promotion workflows or perhaps one of the lesser used workflows.

The workflow would be started by the user requesting the new instance. The workflow would change the CAD Docs from the current Released state to In Work through the previously mentioned Set State life cycle transition. Once that happens, the user gets a task and notification that they're approved to add the new instance. Once the new instance is done, they go to their task list and complete it. The workflow changes the generic and all instances (old and new) to Released again.

Having laid it out, the logic is quite simple. It's really a matter of how complex the existing life cycle template and their transitions are.

I also don't like setting a Released object to In Work since that would presumably give every user in the company the ability to check the object out, even by accident, and make modifications. If I were building a system from scratch there would be another life cycle state besides In Work that could be used to designate it was being modified in this way, and then simply assign a small handful of users to be custodians of this process. They would have the rights to make changes to the "Instantiate" state (or whatever it's called) and would be responsible for all assignments to do this work.

Anyway, having modified the Change Notice/Change Activity workflows pretty substantially for our needs, I'm fairly confident this could be done. It's really a matter of a few things: Setting up the Life Cycle template, making sure the Policy Administration is correct and figuring out the expressions needed for the workflow to change object states correctly. Now, those few things are pretty involved, but either your WC admin or your PTC account manager could speak to that.

Regards,
Don
    S
    sjohnson-31-VisitorAuthor
    1-Visitor
    July 17, 2014
    Thanks Mike! I was really hopeful of using your second method a couple of months ago, with the added drawing detail of having the title block revision cell show "(SEE TABLE)" exactly like we tabulate our instance weights and powdercoat consumption (see below). To automate the relations would be as follows:
    /*
    /*
    /* RETURNS "SEE TABLE" FOR GENERIC REVISION:
    IF REL_MODEL_NAME!="NULL"
    pointer=search(REL_MODEL_NAME,"XX")
    IF pointer==0
    REVISION=PTC_WM_REVISION
    ELSE
    REVISION="(SEE TABLE)"
    ENDIF
    ENDIF
    /*
    /*
    Unfortunately Windchill parameters (specifically PTC_WM_REVISION) cannot be using in a family table, so getting that revision data in the 2d repeat region is out.

    [cid:image003.jpg@01CFA1A7.4B4DE440]

    We are now leaning towards method 1. Our current thought is to give all designers (currently all veteran ProE guys) the ability to SET STATE on objects (non Library only) from RELEASED to IN WORK, but then a promotion required to go back to RELEASED. This would provide a safety net as they would always pipe thru an approver that could reject the promotion if the changes were undesirable.
    Is there something missing or anything we are not considering with this logic?


    B
    BenLoosli23-Emerald III
    23-Emerald III
    July 17, 2014
    What sort of parts are in your family table that requires adding new instances frequently?
    Can the family table be put in a library instead of a product, then give a few users librarian status?
    Set Windchill so Library objects come in as read-only objects to prevent others from modifying them.
      H
      HugoHermans12-Amethyst
      12-Amethyst
      July 17, 2014

      I haven't read the complete thread in detail, and maybe I'm missing the point. My advice to our users is to never use the generic but as a model to spawn instances. So there are no drawings to consider, nor life cycle procedures. An exception is of course sheetmetal parts. And an valuable alternative for parts is the inheritance feature, more flexible but a little more finger gymnastic.

      I keep it short, hope it helps.


      Regards, Hugo.


      << ProE WF5 - PDMLink 10.1 M040>>

      S
      sjohnson-31-VisitorAuthor
      1-Visitor
      July 17, 2014
      Library is out of the question as they are modular sheetmetal make components for furniture partitions and such. We are constantly adding new sizes as they are needed.
      C
      ClearBlueSky851-Visitor
      1-Visitor
      February 2, 2018

      You can first checkout the Generic and existing Instances, then update the Family Table to add the new Instances. After you save the model, then the new Instances will appear in your Workspace. Then you can perform an "Upload" to Windchill on all the modified items. When you perform an upload, it will cause Windchill to assign the Location, the Number, and the Version (Revision, Iteration) to the new items. After performing the Upload, that made Windchill assign the Version, then now you are able to select the new Instances in your Workspace, and then perform a "Revise" on the new Instances, setting the Revision level to whatever you want. When you perform a Revise, the existing Generic and other existing Family table Instances are ineligible to be revised, so they will stay at the revision when checked out, but you can assign a revision to the new instances.

      Show more replies
      Terms & ConditionsAccessibility statement