Table of Contents
|
|
3 Modification to Family Table Generic Model
|
|
4 Post-Modification Steps
|
|
|
|
|
This article is a modification to a PTC TPI (141775) that explains how to remove instances from a family table in PDMLink. The TPI's flaw is that it does not work for large reductions or large family tables. The steps below should be handled by the PDMLink Librarian only and require known what instances are used by designs in PDMLink. No instance that shows usage can be removed. Failure to follow the steps exactly can result errors that are not correctable without help from PTC.
These are steps that can occur before actual modification of the family table occurs.
-
Run the following Oracle Script (in Toad) to determine exactly which instances are used by current designs:
SELECT DISTINCT M1.DOCUMENTNUMBER GENERIC, M2.DOCUMENTNUMBER INSTANCE
FROM EPMDOCUMENTMASTER M1, EPMDOCUMENTMASTER M2, EPMDOCUMENT P1, EPMDOCUMENT P2, EPMMEMBERLINK, EPMCONTAINEDIN C1, EPMCONTAINEDIN C2
WHERE
M1.IDA2A2 = P1.IDA3MASTERREFERENCE AND
M2.IDA2A2 = EPMMEMBERLINK.IDA3B5 AND
P1.IDA2A2 = C1.IDA3A5 AND
P2.IDA2A2 = C2.IDA3A5 AND
C1.IDA3B5 = C2.IDA3B5 AND
P1.FAMILYTABLESTATUS = 2 AND
P2.FAMILYTABLESTATUS = 1 AND
M2.IDA2A2 = P2.IDA3MASTERREFERENCE AND
M1.DOCUMENTNUMBER = '';
-
Open Generic in Pro/E and export the family table to Excel. This is done by going to Tools - Family Table - Edit in Excel. Save a copy of the family table spreadsheet and make another copy for modifications/reductions.
-
Review spec and family table spreadsheet with Engineering to determine which instances can be removed. Mark up paper copy of spec (color sizes used, examine options, materials and finishes available, active vs inactive). Review results of the Oracle extract and keep sizes still in use by current designs.
 
-
Check with other sites and obtain agreement on reductions.
-
Remove rows from family table spreadsheet no longer needed based on engineering markups. Send copy to Librarian.
These are steps that actually modify the family table and generic. These steps should be done by the Librarian.
-
Check out entire family (generic and all instances) to a new workspace.
-
Open generic model and open family table in Excel.
-
Create a new workbook in Excel and copy column A from the original family table spreadsheet to this new workbook. Label this 'Original'
-
Rerun Oracle query from pre-work step 1 to make sure that no new instances have been used in current designs. Check against spreadsheet from pre-work step 5.
-
Return to Family Table Excel Sheet and determine which rows are to be removed. Clear rows 6 and below and paste in spreadsheet from pre-work, step 5 above.
-
Copy column A from modified spreadsheet to new workbook from step 3 above and paste to column B. Label this 'Current'.
-
In the third column, use the following expression to determine what has been deleted from the family table. Fill down expression to all rows in column A. Label this column as 'Deleted'.
=IF(ISNA(MATCH(A2,B:B,0)),A2,"")
-
Copy 'Deleted' column and paste to a new text file in NOTEPAD. Results should be a list of instances that were removed. Gaps in the list are ok. Save this text file.
-
Return to the family table spreadsheet. Click File - Update Pro/E to commit the changes to the generic model. Check family table list for any issues. All instances must be modified. The easiest way to do this is to toggle a layer to hidden, save status, then revert it back and save status again. Save generic model. Note: Workspace may not only reflect remaining instances and generic (all deleted instances may disappear). This is ok.
-
Feed the text file from step 8 into the following batch script in a DOS window. Be sure to specify a replacement part model as shown below (STARTPART). This script will make a new part for each file of the deleted instances in the current folder.
@ECHO OFF
REM Batch for mass creation of Start Part copy models for replacement of FT instances
REM Author: Antonio Villanueva
@set STARTPART=\\dby0fp09\share2\proe_std\start_files\0000-start-part.prt.1
FOR /F "tokens=1" %%G IN (%1) DO @COPY %STARTPART% %%G.prt
-
Return to the workspace screen and click Tools - Import to Workspace. Browse to the folder where the parts from step 10 where created. Select all parts (Control-A). Click Next. Import all parts to the workspace. (This has been tested with file counts as high as 2200 files and there was no issue).
-
Select all items in the workspace and click Check-In. Check-In will fail on upload initially. This is expected and normal.
-
From the Event Manager, retry the upload by accepting the default overridable conflict. for large numbers of instances removals, the event manager can be slow to appear. (ex: 2200 instances took 18 minutes for the resolve conflict screen to render).
-
Perform the Check-In again and it should preceed without issue. Clear the workspace once complete.
Post-Modification Steps |
Top
|
At this point you can resume following TPI 141775 where it talks about purging the instances and the family table and eventually deleting the unused instances.
Link to TPI 141775
The TPI directs the user to open the instances that are going to be removed into a session of Wildfire. Once in memory, the generic family table is edited to remove the rows that drive those instances. At this point, the instances in memory are free of the family table. When they are saved to the workspace, they will be stand-alone models. They can then be checked into PDMLink.
To complete the steps, a purge job is created. This erases the history of these items ever being part of the family table. Once this is done, the items can be deleted from PDMLink. So long as these items are not used by any assemblies, the delete should work properly.
The issue with the TPI is that if there are a large number of instances to delete, it will be a very manual task to open each instance in memory. Beyond a few dozen, you might not be able to even accomplish this since Wildfire could run out of memory.
Dostları ilə paylaş: |
