|
[Editor's Note: This article is based upon the award-winning presentation given at the 2003 PTC/USER World Event in Orlando, Florida.]
Using family tables in a Pro/INTRALINK environment is easier than most people think. The secret to success is to understand the problem areas and to follow a few simple rules. These rules include:
- Always verify all instances—NOT just the new instance.
- Always check in a new version of each instance whenever you check in a new version of the generic.
- Always rename instances in Commonspace—never in Pro/ENGINEER.
- Never delete instances from the family table without also deleting them from the database.
If you follow these basic guidelines, you will find that family tables and Pro/INTRALINK get along just fine. Read on to learn why.
The “library conflicts” phenomenon is probably the least understood, though most important, issue regarding family tables and Pro/INTRALINK. This conflict would be more accurately named “generic version conflicts” because it occurs whenever you attempt to check out multiple versions of the same generic.
If you’re asking yourself how this can happen, you are not alone. But happen it does, and always unintentionally. Let’s say you have a generic that has been checked into the database twice. Version 0 of the generic has two instances, a.prt and b.prt, while version 1 of the generic has two instances, b.prt and c.prt. Now let’s say you have an assembly that requires both instance a.prt and instance c.prt. If the assembly and required objects are checked out, a library conflict will occur because the two instances try to include the latest version of the generic of which each is a family table member. In this example, a.prt is attempting to include version 0 of the generic while c.prt is attempting to include version 1 of the generic. To resolve the conflict, you can pick the Library Conflict button (v3.2) or Family Table Versions tab (v3.3) and attempt to find a single version of the generic that includes all required instances, a.prt and c.prt.
In the example below an assembly that contains two instances, a.prt and c.prt, is checked out with a dependency set to:
Configuration is set to latest.
Note that only the assembly and the instances appear in the object versions list. You might be wondering why the generic is not included in this list. The answer is that there is a conflict regarding which version of the generic should be checked out. This conflict is readily apparent by the red hexagon in the Family Table Version tab (v3.3) or Library Conflict button being available (v3.2).
(Click image to enlarge)
Selecting the Family Table Version tab will reveal the problem generic.
(Click image to enlarge)
To revolve the conflict, you must select a version of the generic that contains all required instances (i.e., a.prt and c.prt). In this case, however, no such generic version exists. As a result, you would have to check out the latest version of the generic and put instance a.prt back into the family table. You would then check in this new version of the generic with new versions of all instances (a.prt, c.prt and b.prt). Now you could check out the assembly without conflict.
Administrators should occasionally search their databases for potential library conflicts. This is done by opening a Locate window and searching the following criteria:
- Instance? = true
- Version = Latest
- Revision = Latest
(Click image to enlarge)
After the search list is generated, use Ctrl+A to highlight all objects in the search window and check them out all at once. When the check out window appears, note the Library Conflicts button. (In v3.3, the Family Table Version tab replaces the Library Conflicts button and displays a red hexagon with an X if there are any conflicts.) If it is grayed out, cancel the check out since your database is free of the most common source of library conflicts. If it is not grayed out,
1. Select Library Conflicts to display a list of all generics that are potential problems.
2. Click on each generic and make a list of each associated instance that is not in the latest version of the generic.
3. Once the list is complete, generate a “where used” report on the instances that are not in the latest version of the generic.
4. If the “where used” report reveals the instance is not used, you can delete the instance from the database. If it is used, you should put the instance back into the generic’s family table.
It should be noted that an addition check to perform would be to generate a list of all instance and all generics. Search for the latest version and latest revision of all these names then check them all out at once. This will find any generic name whose latest version\revision has had its family table removed. Let's say a generic is opened in Pro/ENGINEER and its family table deleted. If that file ,which is no longer a generic, is checked out with an instance from its earlier version a library conflict will occur as the instance will attempt to checkout with it the latest version of the generic that it is a family table member of. The resolution to this scenario is to put the instance back in the generic.
For an instance to be recognized by the Pro/INTRALINK database, it must be verified in Pro/ENGINEER. This verification must be done to the entire family table, not just to the new instance. If you only verify the new instance, the Workspace will no longer recognize the pre-existing instance after the generic is saved. As far as Pro/INTRALINK is concerned, you have just deleted all of the old instance out of the family table. A family table report on this new generic version would therefore include just the new instance. This could in turn lead to:
- Unresolvable library conflicts during check out.
- Check out/update conflicts warning that the Workspace version of the generic object for this instance has more/different instances than the latest Commonspace version.
In Pro/INTRALINK there are two areas of concern regarding editing a family table: renaming an instance and deleting an instance. The rule for renaming is easy. Do it in Commonspace, not in Pro/ENGINEER. Renaming an instance in Pro/ENGINEER results in the removal of one instance and the addition of a new instance because the database will not recognize any renaming performed outside of the database. Note that you cannot use the config.pro option, LET_PROE_RENAME_ILINK_OBJECTS, to prevent the renaming of instances.
Before we discuss deleting an instance, it is critical to understand that an instance version in the Pro/INTRALINK database is part of a group. That group consists of every family table object in every family table report in which that instance appears. If an instance version is deleted, all object versions that share a family table report with that instance are also deleted. This is why it is so important to check in a new version of each instance every time you check in a new version of the generic. You do not want a single version of an instance reporting to multiple family table reports. (PTC recognized this as a problem and Pro/INTRALINK 3.3 and later versions now require you to check in every instance with every new version of the generic.)
As a result, you cannot simply delete an instance. You must first remove it from the generic’s family table in Pro/ENGINEER. If a family table instance is to be deleted from the family table, it should also be deleted from the database. If not, you open the door to library conflicts down the road. Before deletion, perform a “where used” report on the instance to be deleted. If it is used in anything other than the infamous “junk.asm,” do not delete it. If it is not used, you can delete by following these steps:
1. Check out the latest version of the generic and all instances.
2. Open the generic in Pro/ENGINEER and remove the instance to be deleted.
3. Verify the entire family table.
4. Save generic to Workspace.
5. Check in new versions of generic and all remaining instances.
6. Delete the instance from Commonspace.
Ever gotten a message from Pro/ENGINEER that you cannot save an assembly because all instances of a modified generic have not been checked out to the Workspace? This message can leave users frustrated because Pro/ENGINEER suggests:
1. Retrieving the missing instance
2. Using File, Replace to bring the generic update into session
3. Recreating your work.
It’s that last one that really stings. In Pro/ENGINEER’s defense, preventing you from saving a generic that does not have all of its instances checked out is a good idea. In this way, users cannot check in generics with only the checked out instances. This in turns prevents removal of all instances that were not checked out from the new generic version’s family table report.
Here are two workarounds to resolve this dilemma.
1. Use File, Backup and save the assembly to disk. You can then import files to the Workspace as required.
2. Create a simplified rep that excludes the problem instance. Erase the problem instance using Erase Not Displayed. You will now be able to save the assembly. 
David Graham is an independent Pro/ENGINEER and Pro/INTRALINK consultant. He can be reached by email at dgraham100@juno.com.
|
