Hi Linda...
Ah, the fun of family tables. I can't think of any feature of Pro/E more maligned than family tables. Sometimes the criticisms are deserved but admittedly, sometimes they are fair and reasonable. I read your scenario a few times to insure I understand what you're asking. I think I'm on the same page with you... and you're asking fair questions. Family tables are very powerful... and they have some great benefits for designers. They also come at a price... and companies occasionally come to the conclusion that this price is too high.
It's true that when you modify an instance of a table (either assembly or part instance), you have to check out the generic thus locking it and preventing others from modifying it. In many cases, the tables are simple. Tables are great for libraries of hardware and other items that are not frequently being modified. When the hardware tables are completed, they're rarely modified... therefore the problems you're raising do not come up.
Beyond hardware libraries there are also other great reasons to use family tables. Sometimes in an active design you can make a great case for using family tables... even nested tables. This is what you've presented in your scenario. You've got an active design under development... multiple engineers working in collaboration. On top of this, you have nested tables complicating things. This is where things get interesting.
To paraphrase, you asked (at minimum) which objects need to be checked out" for the scenario you mentioned. You're modifying assembly instance #2 which requires the assembly generic... thereby locking out all assembly instances. You're modifying the 3rd part... so you'll need the generic for that part, too ... thereby locking out all the instances within that generic (and all sublevels, too). You correctly determined that your entire assembly and most of the parts will be locked... and no one else can modify them until changes have been completed.
In many cases, this is STILL not a big problem. If you're assemblies and parts are small enough... and your team is small enough, you can usually manage this situation. Collaborative engineering requires... communication. Most of the time, a small team is agile enough to understand the limitations posed by family tables. Yet they opt to work through the issues because the tables offer a fantastic set of options that speed modifications, drawing creation, and interchangeability. Basically, the pain of dealing with the tables is worth the benefit in these cases.
Sometimes though, you have a large team... and a big project. In these cases, having an entire assembly checked out to ONE individual is a real problem. Other designers are waiting to make changes- and are prevented from doing so. Some of these problems can be mitigated by careful planning of the assembly structure. By breaking the assembly into sub-structures, you can minimize the impact of family table changes on the entire team.
I'm sure it seems like I'm dancing around the topic... but the point is that there are several ways to navigate the family table issues and mitigate their negative effects. If you've already got a large assembly built with nested tables and you're already passed the point of being able to manage it, your options are increasingly poor.
Yes, iterations will change as objects are modified in Windchill. Yes, nested tables cause many objects to be locked while modifications are underway. And yes, if you make a mistake editing the instance, you can inadvertently mess up other related instances. These are all fair criticisms. And yes, one way to eliminate the problem is to break apart all of the instances and keep the parts as standalone objects. But I think this method completely throws out the beneficial aspects of tables for the convenience of having individual parts.
You can mandate that designers use NO family tables. You'll certainly make life easier on the Configuration Management people. However, you're tying the hands of your designers to use the full power of Pro/ENGINEER to create models. The whole reason companies spend so much money on the software is that is has the ability to save time... and get products to market more faster with less expense, higher quality (less mistakes), and fewer resources. Family tables keep a design consistent. Individual models can have individual errors that slip through the review cycle. Individual models require individual management... and individual changes... and individual drawings. You pay a price in productivity when you remove tables from your palette of options.
Is there any way to gain some of the benefits of family tables... YET keep the models separate? YES! There are a few options you might want to investigate. First... take a look at Inheritance Models. You can mimic some of the benefits of family tables... without the table... using inheritance models. Second, consider keeping the parts tables as-is. Individual part tables are much easier to handle in Windchill... and they don't have the far reaching negative effects of tabled assemblies. Third, in some cases you can remove assembly tables and get some of the same benefits using Flexible Components. For cases where the table is helping to show various mechanical states of an assembly (like a boom being raised, lowered, extended, etc), Flexible Components and flexible features can take over these duties. Thus you can remove the table and still get the variety of mechanical states you need.
If you can tell me more about your situation, I can try to be more specific. I'd like to give you as much help as I can but it's tough when I'm not sure exactly what your specific goals and requirements are. If you'd like to talk more in email or call to discuss things further, let me know and I'll get you my contact information.
Thank you and good luck!!!
-Brian
.
