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
