How to maintain same revision level while added a family table instance?
Tip of the iceberg to a bigger set of issues:
- Need to consider related WTParts, Revisions of these (may not yet be using)
- May get someday to model-based approach and eliminate drawings
- May have options and variants based on WTParts, and CAD should "follow" rather than drive some of this
- May have ESI or at least ERP Connector in place, with a transaction to SAP that results from getting to Released; bring back to Released multiple times may trigger unwanted consequences
- Probably more... 🙂
Assuming all this is future, what I didn't mention before is that the Revision of each instance does have to be on the drawing tabulation - but yes, it's difficult to make this parametric. The drawing itself is an object and needs to have a Revision - but this is separate from the Revision of each Model / WTPart / Part Number of physical things in cardboard boxes in inventory. Seems best to drive the Drawing Revision with the Generic Revision; this will be higher or same as the Rev of any Instance.
Does sound good to require a promotion request to bring back to Released. Another option is to never release the generic, but release the drawing, and always revise the Drawing and just the Instances that are affected.
Major, important area that deserves careful thought. Would like to see what others are doing with family tables / tabulated drawings.
RE: How to maintain same revision level while added a family table instance?
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.