Family Tables management in Windchill 10.2

[jhall2]

Greetings all.

I was once a big proponent of FT at another company, (Which did not have Windchill) and saw it grow into a terrible mess, that was so bad we had to start deleting them. I am now at a company that has not had them in the past, but headquarters has now decided to implement them. Unfortunately, they have no idea about how to go about that, and that task seems to be ending up with our local group. We are running Creo 2 and Windchill 10.2

I have some questions, that I hope can be answered.

1. We have the generic part/instance name issue resolved, but what I am concerned about is editing Released files in the future. What is best practice for Releasing a FT? Do you Release the Generic, or only the FT instances?

2. We will be associating the Instances with WTParts. Are they to be set to Owner or ....?

3. And is there anywhere where I can find information discussing the fine points of Windchill FT Management?

Thanks in advance,

James.

[BenLoosli]

I do not like releasing FT parts, but it depends on what type of parts you are putting into your FTs.

For purchased commodity items, create the family tables, populate with as many instances as you think are reasonable at the beginning and check the FT into a Part Library. By using a Library instead of Product, you limit accesss to the files for changes and for users without Library access (should be most of your users) the file can be configured to come into a workspace as Read-Only.

There are a few CS artciles on PTC.com dealing with FTs but like anything there, hard to find unless you hit the right search keywords.

[jhall2]

Thanks Ben,

We are going to have to Release them, since they are machined parts. Such as various lengths of a shaft, or housing. Sometimes various materials.

Part Library sounds interesting, I need to explore that, but we aren't looking to do FT for purchased parts.

We are wanting to plan ahead and not end up making such a mess that FT gets banned, which happens a lot around here.

James.

[kpritchard]

One thing I would caution against is when family tables get too large. I prefer to restrict to dimensional variability and would suggest that you avoid feature vairability (example = having hex head capscrews in the same table as socket heads). If using in conjunction with Chart/Table Drawings I would avoid blending materials as well.

In general each instance is associated to a WTPart. Generics do not have WTPart (exception is Sheet Metal... as sidebar, I would prefer a PTC recommended best practice for Sheet metal and Flat Patterns that did not mean Generics as the real thing, or suppressed features in the functional model but that's for another day). Association type is your call, but I don't see a compelling reason that they would not be Owner Associations.

Be cautious with Relations! Evaluating relations can cause an entire FT to want to modify. Anything in the Generic than can drive differences in Instances needs to be included in the Table. Relations in the Generic can impose a new truth on all instances with each instance that gets loaded.

Release, Release, Release! You want to make sure that you don;t leave FT's open for all to modify. You'll end up with earlier versions that have instances that are not present in later versions of the generic (major headache!). Most common cause is anyone can edit anytime FT's. Force revision to the Generic to add an instance. Force revision to all Instances and generic for any Global modifications (such as material). Release Generics and all Instances. Adding an instance should only require the Revision and modification of the Instance. Using ACL and Lifecycle States also supports Read Only in Workspace similar to Library described by Ben Loosli‌

Keep an eye on FT Generics and Instances in the Workspace. If they are modifying for no apparent reason, then check for and remove circular and/or external references. FT Instances should be stable for simple use.

KISS Principal - it's easy to get too much of a "good" thing. Nested Family Tables can increase complexity and challenges of managing. Discretion should be used when considering whether or not to FT an assembly using one or more FT components. (I still have not figured out a way to set up a Chart BOM)

Understand the requirements driving the use of FT's and establish criteria for when, when not to use. Again - FT's are highy effective for dimensional variation of a family of components. One benefit is being able to specifiy mulitple parts on a single drawing with a table listing dimensional and parametric differences (yes, don't forget things like Name, Description, Part Number etc.). Big advantage is that when a non tabled dimension is modified (or featre added) it ensures that the change is applied to all in the family. if you don;t want this, then it should probably not be a FT.

[Dan_Harlan]

Keir & Ben both have some good info. A few more things to add;

• Define their acceptable and unacceptable use prior to using them (this may impact company policies and procedures)
• Consider how the instances are going to be detailed. If you allow/require instances to have their own drawings, this will add complexity. It is easiest/most robust when all instances are controlled on one single drawing. That drawing is of the generic and uses tables with repeat regions to define the instances and the associated dimensions. Don't override the shown dims, but rather change the dim text to "@S" and then the values are shown in a table.
• Make sure the table dims are all named, or the above won't work well.
• Define your numbering policy. For instance, are you going to use dash numbers? i.e. the generic is numbered "123456" which matches the drawing number and then the instances are; "1233456-1", "...-2" etc. Does everyone (mfg, purchasing, doc control, etc) have the same concept of what a dash number is? This can be a big thing in terms of ISO type certifications.
• Revisions; can instances have different revisions? From a practical point, the generic must be equal to or "higher" than the highest instance. i.e. if one instance is at rev G, the generic must be at least at rev G. Or, must all instances, the generic and the drawing all be at the same rev? (easiest)
• What happens to obsoleted instances? Deleting an instance is a VERY BAD thing. So, how are you going to obsolete an instance when it is no longer wanted? (Setting to an OBS release level works, but access control impacts a users ability to later modify the generic.)
• I will also reiterate a comment from above, nested family tables are a bad idea unless use is very strictly controlled and you have a very robust process in place to insure proper use.

Note, FTs are really good for commercially purchased library parts like fasteners.

[jhall2]

Thanks everyone. With these responses here are some ideas I have to plan. I really like Keir's mention of the KISS idea. Family Tables can get FAR too complex, quite quickly.

1. Our drawings are named (numbered) D000XXXXXX, so we are also planning to name the Generic the same, D000XXXXXX. Each instance would then receive the same name as the WTPart number 02XXXXXX. There are no dash numbers. People here are used to seeing the CAD model with the same name as it's associated WTPart number. We then would associate and release each instance with it's WTPart number. I think that would work in the way that Keir mentioned about not keeping the FT's "open for all to modify." That is also quite concerning.

a.Dan's point about all instances on one drawing is well taken, and I believe that is what we would do.

b. I am very concerned about instances having different versions. I don't normally see this as a problem, but wonder if there could be a conflict, and how to resolve it.

c. Obsolescence sounds really scary. We do obsolete parts from time to time.

d. I still am not certain that the Generic should be Released or not?

I suppose not, since Keir indicated that Generics would not have a WTPart ever associated with them.

2. FT are currently limited to exact geometry but different materials (we only have two or three materials). We are considering adding length to that list, so different materials and lengths would be the variables, and only those. Clearly the simpler the better.

James

[kpritchard]

1a - suggest using this as criteria for FT or not FT. Never say never, but I would never put mambers on a Family Table on different Drawings.

1b - you may run into a scenario where an instance gets added to a FT that has had Instances Revised. You would have to skip your initial Revision for the added Instance to align with existing ones. I see this as being more of a challenge keeping straight than allowing different Revisions (versions). Where you get into trouble is when the generic is open and users concurrently add instances in their individual workspaces at different versions.

1c - use Lifecycle State to Obsolete. I encourage and cultivate a no-delete philosophy and use Lifecycle State as a flag of believability. You could then have Obsolete and current instances in the same family Table. You could choose to remove references to the obsolete instances from the Drawing.

1d - definitely change the State of a Generic to somehting that is not editable. I think of "Released" as "real" so would "Release" the Generic with each "Release" of the Drawing in order to lock it down.

[jhall2]

Thanks again, Keir.

1a - I agree, why would you want to put them on different drawings?! It sounds like a perilous undertaking.

1b - Yup, sounds like we just let the Instance Revisions move around naturally, instead of forcing uniformity. I'm good with that.

1c - Very interesting, Obsolete wouldn't mess with the actual FT, it seems. But it would let you know not to use it.

1d - Ok, now that is information that I can use and like. That makes perfect sense.

This is a very, very fruitful discussion, thanks to all!

[Dan_Harlan]

Keir, am I missing something? Your statement "Where you get into trouble is when the generic is open and users concurrently add instances in their individual workspaces at different versions" shouldn't be a concern given the need to check out objects and only one person can have a generic checked out at a time. You would have to make sure that users are not allowed to check-out/revise non-latest, but otherwise ACLs should cover this, right?

[kpritchard]

Dan - you'd think so, but we have run into this. Your statement holds if users adhere to best Workspace practices. Where it can (and at times does) fall down is in combination of one or more of the following...

• User(s) keep working in one Workspace for long enough for the generic to get out of date (later version exists on Server)
• Family Tables are unstable and modify/iterate virtually any time an instance is opened
• Family Table is never "locked down" (i.e. set to an ACL non-modifiable State such as "Released")
• User(s) do not use Check Out to proactively "tag" the files that they intend to modify
• User(s) blindly Check Out everything that modifies locally, without understanding why (reasons include but not limited to changes to layer display in a model, circular references, relations in a generic affecting instances, dimensional changes, tolerance changes etc.).
• User(s) Check everything modified in Workspace rather than overwriting unintended modifications (files not Checked Out) with Server side versions

It can, and has happened with let's say a User adding an instance to Rev A Generic and another User adding an instance to Rev B. The Allow Check Out of non latest iterations may not have been set when this occurred, but to satisfy my own curiosity I will probably attempt to add Instances to different (unReleased) Revisions of the generic to see if I can replicate... (I fear that iterations are per Revision)

[dschenken]

User(s) blindly Check Out everything that modifies locally, without understanding why

This is my favorite. Every so often a user picks a layer in an assembly, changes and saves the status and then has hundreds of parts modified. So why not? Check them all out so everyone else on the program is looking at hundreds of out-of-date parts. I called it carpet bombing. I figured that carpet bombing was a flag for better training.

Intralink (RIP) and Windchill not automatically locking items on copying them out is the UI equivalent of staging bum fights. The development team has to know that of the tens of thousands of adding items to the workspaces for the 1% or less that are to be modified that the worst choice in a multiuser environment is the one that maximizes the chance for conflict between users, but it's the most fun.