Dissolving Family Table

[erine]

Hi everyone,

Sort of a long explanation, but i feel like it's necessary to explain our situation and hopefully give you guys who are way more experienced than i am, a better understanding of what i need help with.

We're having issues with our family tables.  My suggestion is to dissolve our family tables, but I want to have a full understanding of how this is to be accomplished before we take the leap, since I will be leading the effort.

My personal philosophy on family tables are that they should only be used for parts that little to no chance of being revised.  An example would be hardware parts, such as bolts, screws, washers, nuts, spacers, ect.  Building intermediate/advanced parts and assemblies using family tables is asking for trouble and can become a situation where simple changes result in a snowball of unintended issues.

In our case, we have tri-level family tables.  What i mean by that is that you'll have parts (1) built by family tables.  Those parts will live in an assembly family table (2) which is a subassy (ex: parts with hardware that are ordered in kits).  Those subassy family tables will then live in a top assy (3) family table.  So a change at level 1 can also means updating level 2 and level 3 assemblies and drawings.

We know we want to eliminate the family table setup because it is causing simple engineering changes to become very involved and by default, time consuming.

We do not use windchill or any other PDM at the moment, so that simplifies the process.

My understanding is that when you want to dissolve a family table, you go into the generic, open up all instances and while all of those instances are in session, you delete the generic file and save all instances as their own file.  Do the drawings of those parts need their set models updated or do the set models automatically update to the new standalone part?

[BenLoosli]

I would only dissolve the level 2 and 3 family tables. Start from the top down in breaking up the family tables.

In theory it should be as you described, but some internal references may get changed that cause issues with the upper assemblies and drawings.

I would take 1 file and use it to experiment with. Copy it to a test folder.

Leave the part files in family tables if they are hardware items and such, like you said, change infrequently.

I have done some assembly family tables, and they do grow into a convulted mess. Mine was a plastic wire tray with a cover and nuts to hold the cover on. We had these trays for different lengths, depending on where in the higher assembly they were used. It became complicated when we got over about 10 lengths, sinc ethey all had different dash numbers for the tray and cover.

[erine]

I think i've got the level 1 portion down, after backing up some files locally and doing a bit of trial and error.

The following step-by-step is for users who are not actively using a PDM.

1. Pull drawing, using backup, to local folder.
2. Exit all, Erase Not Displayed.
3. Open drawing from local folder.
4. In drawing, open the GENERIC from tree. The part should have “<PARTNAME>” next to it, identifying it as a family driven part.
5. Open part instances that you want to make standalone and keep them in session. You will go back to the generic and open directly from there, until all instances are open and in session.
6. Open the generic and delete all targeted instances from the generic table.
7. Verify table.
8. Switch over to each part that is open in session and save.
9. That drawing you opened in step 3 should now list the standalone part. It should not have the “<PARTNAME>” by it anymore.  You may have to regenerate the active model.
10. Save the generic that you deleted all those instances from.
11. Exit all.
12. Erase not displayed.
13. IF ALL INSTANCES WERE DELETED, delete the generic file.

I am assuming this will work from top-down as well, just more steps of the same.  I think the end goal is to control your drawings and look for the set model within it to not have that <generic part> beside the name, indicating that it is in fact standalone and "looking" at the correct model.  Feature ID's are not being altered, so constraints should not be affected in higher-level assemblies (I have not confirmed this, yet).