Family Table Standard

[Amirtharaj_K]

Hi Guys,

I want to know the standardized method for the family table, like how we can use it in assembly, replacement, and change instances, only releasing the instance, not a whole model, etc.

Regards,

Amir

[avillanueva]

Vague questions. Treat them like a block or set. Release together. Revise together. Never ever ever ever ever remove instances once created and checked in. 

[Amirtharaj_K]

Thank you for the replay, Mr. Avilla. I apologize for the delay in responding.

I have one generic and fifteen instances that I do not want to release because whenever I choose to add a new variant, I can do so. If I release all, I may revise and modify and re-release. Based on my testing, I was able to release, revise, modify, and re-release one instance without the need to release generic and other instances. My question is, if I use this method in the future, will I encounter any errors or issues?

Furthermore, I would like to know how it reacts with assembly since I have used multiple activities in a single instance without generics.

Regards,

Aj

[avillanueva]

From a CM perspective, its possible to change the generic which will impact all instances which is a problem. It will ask you to check them out and that's a problem if the instances are released. Is this options and variants or some sort of master model assembly? Most of my generics are hardware like nuts and screws, cables (flats) or complex assemblies that the wanted  different configurations. In the latter case, they are all the same assembly so get locked together. 

[GrahamV]

For the most part, Windchill treats family table instances and generics as separate objects, allowing you to check in, release and revise the objects independently. Creo however adds some complexities, as avillanueva suggested, because some modifications will require regenerating and checking in the entire family table, so you either have to revise all instances, or have a process to make the objects modifiable, then you need some process to check the other instances haven't been changed accidentally.

Where I work, we use family tables for both parts and assemblies, instances are released but generics are not (they are only used to generate the instances, they don't themselves represent anything), instances are revised and released individually where required. Where a family table requires regenerating, we use Set State to get it to a temporarily modifiable state.

A note on removing instances from a generic, this can actually be done but the user must check in the (now standalone) removed instance at the same time as the generic, failure to do this creates some real headaches. 

Family tables can be very powerful, but should be used sparingly, as they do add complexity to systems.

[Hari_Vara]

@Amirtharaj_K 

I used to work as Windchill admin, I think what @GrahamV  is aligned to what my experience also might suggest. Well what @avillanueva  suggests is also a good practice , provided the access control and matured users only are authorised to work on FTs. and Instances.

There is no single suggested method.

In general, if your users are less experienced, then i would suggest that do not Release the Generic. This mechanism will give the users to add instances and Release them. The possible issue is that someone can accidentally delete some instances.

So, you can have a workflow where user requests a instance creation authorization, the WF demotes the Generic from "Locked" to "Unlocked", use WF to checkout the generic to the user. , User can add instance and check in. Once the WF gets approved, the Instance is Released and Generic goes to "Locked".

The WF approval can be only done by a "Librarian" (Super user). 

This was a method my previous company used.

Go with multiple options, first collect your use cases and design a solution / SOP.

Best Regards

Hari Varadharajan