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.
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.
<< ProE WF5 - PDMLink 10.1 M040>>
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,
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.