cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - New to the community? Learn how to post a question and get help from PTC and industry experts! X

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

sjohnson-3
4-Participant

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

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 13

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.

sjohnson-3
4-Participant
(To:sjohnson-3)

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.



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

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.

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.

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
sjohnson-3
4-Participant
(To:sjohnson-3)

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?


BenLoosli
23-Emerald II
(To:sjohnson-3)

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.

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

sjohnson-3
4-Participant
(To:sjohnson-3)

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.

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.

Just realised that when I originally replied to this I somehow managed tostart a new thread. Hopefully this one works.


My opinion on this is that tabulated anything on a drawing is a piece of evolutionary baggage best consigned to the “Yes we used to work like that, wasn’t it quaint” category. Really you need to aim beyond communicating metadata on the face of a print, it is expensive, awkward to do, and ultimately adds no value. Use your PDM system to manage and communicate metadata and keep your CAD system for pure geometry. Putting everything on the face of the print is something you used to have to do, there are better more efficient approaches now.

Regarding family tables, the fundamental thing you have to remember is that there is only one CAD file. Interpreting it as different things is something the CAD system makes possible, which in turn drives “unique” EPM/CAD Documents into PDM. But the reality is that to modify any of those documents you need modify permissions to them all because they share the same file. This always leads to a compromised solution, where you have to either give someone more access than they should, not allow them to modify something, or treat all the family table contents as a collection when you don’t really want to. From a purely end user perspective there is also the issue of managing which of those documents go into the workspace.

Based on our lengthy and varied experience with CAD and PDM wherever possible you should avoid family tables altogether, the bottom line is that family tables really don’t work together well in any data management system for the reasons described above. We have spent considerable effort exploding many family tables in PDM for these reasons. All that said we have not done anything to prevent their use, but we only really encourage/support the following use cases.

1) Same geometry from different materials. Although many of our product lines have simply moved the material definition to the WTPart, so this one is not actually that common.
2) The same assembly shown in a multi-stage layout drawing, so showing the same content in different positions/offsets.
Note that in both of the above examples the physical geometry/configuration you are representing is basically the same, this means that if you are making changes/updates it makes sense to treat it as a collection.

To get back on topic. In terms of adding an instance to a Released family table we have two options.

1) In most product lines we have an experienced and trusted Windchill user with “Engineer Admin” permissions. This grants them the ability to modify Released data without a Change object, so that user has to add the instance. Any new EPMDocument has to be added to a Change Notice to Release it.
2) With our change process we also have the option of a “Zero track iterative change”, this is an “I1” category change in our terminology. The same as we use to first Release new data. This allows a user attaches Released data to a Change Notice with I1 disposition, upon approval this changes the affected data state from Released to Rework, allowing the user to update the affected data. They then send the Change Notice back for approval and if approved it changes the state back to Released.

I hope all of the above is useful,


-----

Lewis

We had some custom programming done and I assume with PTC's assistance.  Prior to the custom programming CAD Support would manually manipulate the WTPart revision.  We use FTIteration (Family Table Iteration) when we do not want the WTParts to advance revision.  For instance I am adding more instances to a Family Table.  There is nothing changing to the existing Family Table instances.  We will add the WTParts to Affected Objects and choose to run an FTIteration on the WTParts.  This will add the WTParts to Resulting Objects of the Change Notice, but keep the existing revisions.

Note the State of FT Iteration which does not advance the WTP revision.  I could ask our CAD Support how this was accomplished if necessary.

FTITeration.JPG

Announcements


Top Tags