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

Removing Instances from Family Tables that are in Windchill

Re: Removing Instances from Family Tables that are in Windchill

It can be controlled by ACL's on the context so any file downloaded is read-only.

I am trying to remember what the Windchill preference is that can be set, too.

Re: Removing Instances from Family Tables that are in Windchill

Problem is - any PRT or ASM in any context used for any reason can be a family table.  May not start out as one.

Re: Removing Instances from Family Tables that are in Windchill

This is where most of the issues come from when using family tables!

If you have a part and use it in 3 assemblies and then have to do an almost identical part, only 1/2 inch longer. Do you create a new standalone part or make the original part a generic and add the new one as an instance? If you do the latter, you have just shot yourself in the foot! PTC will tell you that the generic should NEVER be used, always use an instance. To take an existing part and make it a generic, it has to be renamed, 2 instances added, one matches the generic, the other is longer. Then all uses of the generic need to be replaced with the new 1st instance that matches the generic. If you only have 3, not too bad. If you have a few hundred uses, suicide!

Family tables need to be thought out and applied where they provide proper functionality. Ok it is easier to add an instance than create a new part and drawing, but you have still created a new part number that needs released into the system. Unless these parts may need to be interchanged, like using a longer bolt, or have very common features, washer or nut, why are you doing family tables? Like most things in CAD, just because it can be done doesn't mean it should be done. There are ususally multiple ways to accomplish a task, but only one, maybe two, or good for long term usage and part reuse.

Re: Removing Instances from Family Tables that are in Windchill

Yes to this. Too many users see family tables as a magic part factory where they can just create and delete parts without any thought. Add in the 'tidy up' users who feel like if -they- don't see a need then there must be no need, so just delete to clean up what they don't understand and not just family tables are ruined. In the real world these people would be seen using belt sanders to wash cars.

Re: Removing Instances from Family Tables that are in Windchill

I haven't done that for a long time, but

In WC 9.1,   we have a particular method that allow to remove a PRT from the familly table and transform it as a "standalone" classic PRT EPMDocument

To allow assemblies working well , without using the last version of generic that does not contain anymore the PRT as instance

something like:

download the Full FT in the Workspace

Open the instance in Creo session  (important to have the instance in session)

Open the Generic in Creo session

activate the Generic and remove the instance and save

activate the instance and save it.

should be now a standalone classic PRT

Windchill keep history iteration so we can see that old itérations are instances.

and if get old assemblies "as_stored", get the instances, not the last standalone PRT

Don't know is still work in 10.2 or 11....

Re: Removing Instances from Family Tables that are in Windchill

Correct. We use WC 10.1 and this still works. We usually use this method to make the obsolete instances standalone.

So ideally the entire family table along with the drawing will be revised together to the next revision before making the instance standalone.

Re: Removing Instances from Family Tables that are in Windchill

To piggy back on Greg Perasso comments about making instances standalone........We have tons of legacy family table data, especially with all types of fasteners, fittings, clamps, etc, etc.

But a lot of the instances are at different revisions.  We do have them all in a library context which is read only so the users cannot modify the family tables.  But we have begun to associate CAD docs to wtpart for CAD driven purposes.  Family Tables, Windchill and CAD driven BOM can be a headache at times.

So, we decided to strip the instances from the family tables on an as needed basis.  This is a slick way so all instances will become stand a lone and the assemblies they belong to will not fail.

As an admin.........

  • get the whole family table generic and instances into your workspace.
  • Modify the whole family table, verify all instances.  Save.  Make sure whole family table generic and instances are modified.
  • Now this is very important, bring in the instances you want to strip out (make standalone) into session.  One or more.
  • Then delete those particular instances out of family table generic table.  Save the generic.
  • Look at workspace, you will see those particular instances will not have the instance symbol next to it, it is now stand a lone.
  • Check in the whole family table generic, instances and those stand a lone parts.


Now, all assemblies in Windchill will have stand a lone parts in their assemblies, not instances.


One downside, if those family table files were in other workspaces, it will not let you update those components in your workspaces, PTC confirmed this.Here are some options........

  • Option 1 (best method): save work, erase all out of session, then within the workspace, delete all the out of date family table generic and instances (use family table collector to gather all generics and instances), then select all components in the workspace and update all components.  Workspace detects the missing components from the assemblies and the update function will add all needed missing components back into the workspace.
  • Option 2: save work, erase all out of session, delete all the out of date family table generic and instances out of workspace, add the deleted components back to workspace.
  • Option 3: Check in all modified and new items first.  Delete all items in workspace and add back in.
  • Option 4: Check in all modified and new items first.  Create new workspace and add all components.

Re: Removing Instances from Family Tables that are in Windchill

Brad, George and Al must be having a fit at this!

The family tables would have parts at different revision levels as they were not fully populated at the same time. There is nothing wrong with adding new members to a family table at iteration 20. Just remember that the users will need to sync their workspace to replace the iteration 15 file they have in order to get that new addition.

Re: Removing Instances from Family Tables that are in Windchill

Great idea/trick for making the obsolete instance(s) standalone but it seems like that needs to be done before instances get deleted/checked in? I have been trying to test if this could be done after the someone had already deleted the instance from the generic but I haven't had much luck as you have to check out the generic again to do the trick. I could look at combining it with leapfrogging but that seems like it could be hard to remember/repeat consistently even if it worked.

Re: Removing Instances from Family Tables that are in Windchill

You can actually create a family table from an existing part and not lose the references to existing assemblies.  I've written it as a 17 step process but at least you don't have to open up 100's of assemblies to change them.  Here are the instructions that I wrote for doing that.

We don't allow family tables for assemblies, but do on parts.  Needed to have a little bit of give and take.  But we also have different instructions for if a family table object becomes obsolete, and for creating new instances when the revision of the table isn't the first revision in the revision table.  Before we came up with these instructions and rules, there were so many family table issues that could not be undone that we put a moratorium on creating new family tables until we resolved all of it.  Since then, there have been an issue here or there, but not like it was when we first went to Windchill and had users with a Wild West mentality.  We also limited family tables to users that passed a family table test.  So far users that shouldn't use family tables are pretty good at not.