Removing Instances from Family Tables that are in Windchill

[lhoogeveen]

Family Tables are a headache with Windchill. One many of many issues is it's very easy for Creo users to remove Instances from Family Table by simply hitting Delete Row inside of Creo but this can create undesirable scenarios if the objects are already in Windchill. Since the Deleted Instance is now longer attached to the latest Generic model, if a previous Assembly in Windchill used the Deleted Instance, you are unable to update to the latest Generic rev in a workspace. You're stuck with out of date objects in your workspace. However Creo lets you delete instances without telling you that could be bad for Windchill. Our 'standard' has been to tell users not to delete instances from Family Tables once they're in Windchill and simply filter the undesirable instances off the drawing. New users have a habit of finding out the hard way that they shouldn't delete instances. I was curious what other people do... Not worry about it? Found a way to prevent users from deleting instances from Creo? Found any easy fix to get the Creo/Windchill instances associated back together with the generic?

[BenLoosli]

Limit family tables to library type of parts (nuts, bolts, screws, washers), put the files in the Part Library and have a librarian who you trust to know how to treat family tables.

Make Library objects come into user workspaces as read-only parts.

Do NOT let all users have access to edit family tables.

NEVER delete a line from a family table that FT has been used.

[MikeLockwood]

can be done - but nothing is more fraught with peril

[lhoogeveen]

I would love to do that but our company sold our souls to family tables decades ago. We use Family Tables for virtually everything.

[BenLoosli]

What is your change rate on family tables? How frequently do they get modified?

Training issue!!! Teach the users that they can create family tables and add to an existing family table but NEVER delete from one.

Have good backups so you can always restore to a previous iteration.

[lhoogeveen]

I agree. It's probably a training issue but it's hard to enforce but even more annoying to try to undo. The most common thing is to add new parts to a family table which is fine but occasionally users obsolete (stop using in Production) or kill parts that never made it to Production which people think that means delete them from the Family Table.

[BenLoosli]

Just because a part is no longer used in production or has been obsoleted does that make the past uses of an instance mean it can be removed.

If a part must be noted as being no longer eligible for future designs, rename the part with a something to indicate that. I rename parts and change the name to 'OBS <old part number>/USE <new part number>'. A regenerated drawing will show that in the BOM table and that flags the designer to replace the part in their assembly.

[lhoogeveen]

Ben, how do you prevent users from having access to edit family tables? Obviously, if they don't have access to edit the CAD then they wouldn't be able to edit the family table. But nothing would really stop them from making their own family news on new parts they do have access to?

[BenLoosli]

I prevent it here by putting our hardware family tables in the Part Library and set a config option that any files loaded from the library are read-only. Works for family tables and single files.

Nothing can prevent users from doing 1D10T errors!!! They can do a save-as and rename all of the existing instances, but intuition should tell them that they should not do that.

If your files are fairly static, move them to the Part Library and that should reduce the problems as they now have to think "If this file is read-only, should I be changing it?"

[TomU]

I prevent it here by putting our hardware family tables in the Part Library and set a config option that any files loaded from the library are read-only. Works for family tables and single files.

So this can be controlled on a context basis?  What is the config option?

[BenLoosli]

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.

[MikeLockwood]

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

[BenLoosli]

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.

[dschenken]

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.

[BrianToussaint]

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.

[manjunathrv]

Agree.

This is the same procedure that we too follow to make the existing/new parts as instance to another existing part.

And we have also trained our designers on this procedure.

But we can't restrict them from creating family for assemblies since this is widely used practice across different products and teams, so we frequently face issues when there is a need to remove or add instance and designers don't follow the right procedure, which sometimes makes it impossible to fix the issue due to references to released drawings or assemblies.

[lhoogeveen]

I think I'm at the very difficult (but maybe not impossible) level of fixing the deleted instance. The deleted instance(s) are used in several assemblies as well as the objects are at a 'Released' state. One option could be setting the family table back to an 'Unreleased' state, open the new generic in session, delete the bad revision/iterations from Windchill, and then add the instance(s) manually back into the family table. This way I'll make sure not to undo the users changes. Once I had it reattached, I could consider separating the instance(s) out from the generic if desired. This would be a lot of work from something to takes 1 second for the user to incidentally do.

[GregoryPERASSO]

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....

[manjunathrv]

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.

[bradlawrence]

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.

[BenLoosli]

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.

[lhoogeveen]

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.

[manjunathrv]

If the instance is already been deleted then you may have to go back to the previous version of the generic by deleting the latest set of family table to the iteration where the deleted instance is still part of the family table. Then you will have to follow the above steps to make it standalone.

But its not always easy to do this unless there is no complex references of the other instances.