<!DOCTYPE html
  PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<!--
Copyright (c) 2006 UGS Corp.

All Rights Reserved.

This software and related documentation are proprietary to UGS Corp.
-->
<html>
   <head>
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <title>Part table best practices</title>
      <script language="javaScript">
        abridged="false";
        displayConditions=new Array();
      </script>
      <link type="text/css" href="../css/main_styles.css" rel="stylesheet">
   </head>
   <body class="bodydocs" onload="top.pageLoader()" bgcolor="#FFFFFF">
      <div class="title_topic2" id="xps10_pagetitle">Part table best practices</div>
      <hr noshade="true">
      <table cellspacing="4" align="center">
         <tr valign="top">
            <td bgcolor="#f7f7f7" colspan="1" rowspan="1">
               <p class="para_td"><a class="links" href="javascript:void(0)" onclick="top.openFile('routingadmin/table_overview.html');return(false);">Overview</a></p>
            </td>
            <td bgcolor="#f7f7f7" colspan="1" rowspan="1">
               <p class="para_td"><a class="links" href="javascript:void(0)" onclick="top.openFile('routingadmin/table_desc.html');return(false);">How To</a></p>
            </td>
            <td bgcolor="#f7f7f7" colspan="1" rowspan="1">
               <p class="para_td"><a class="links" href="javascript:void(0)" onclick="top.openFile('routingadmin/refset_charx.html');return(false);">Options</a></p>
            </td>
            <td bgcolor="#f7f7f7" colspan="1" rowspan="1">
               <p class="para_td">Related Topics</p>
            </td>
         </tr>
      </table><br><p class="para_topic">This topic provides a set of guidelines for managing Routing part libraries. This topic is useful for site administrators who will be customizing the standard part libraries provided with the different Routing applications. Prerequisite knowledge for using this information is a good understanding of the topics in the <a class="links" href="javascript:void(0)" onclick="top.popUpPage('routingtools/index.html?goto=routingtools/title_page.html&vars=-aux,-home','linkInter','menubar=yes,status=yes,resizable=yes,toolbar=yes,scrollbars=yes,location=no,directories=no');return(false);">Routing Tools Help</a> on Part Libraries, Part Tables, and the part table utility programs.
      </p>
      <p class="para_topic">The most important concept for the proper maintenance of a Routing part library is that there are two locations where geometric information is maintained, namely the part table (ptb) file and the part family template file (prt), and the ptb file is the master data. The information in both locations must be synchronized for the proper operation of the library and the utility for ensuring this is the update_fam_from_ptb program. Updating a part family template file's part family spreadsheet data independently of the ptb file, such as not using the update_fam_from_ptb program, will cause problems when instantiating or placing the member parts.</p>
      <p class="para_topic">Best practice suggestions:</p>
      <ol type="1" start="1">
         <li>
            <p class="para_item">Spend time up front designing your .ptb and template parts. The ptb file contains geometric columns which will drive the geometry of the part and non&ndash;geometric columns, such as material, fitting or connection type, etc. Decide on the minimum set of geometric values needed to create all possible member parts and only include those in the .ptb file. That is, examine the part file to determine the set of expressions that all of the other expressions depend upon and use that minimum set of expressions as REAL columns in the .ptb.</p>
         </li>
         <li>
            <p class="para_item">You can reuse geometry by having multiple rows in the .ptb file contain the same values for the geometric columns (and the same MEMBER_NAME column value), but with different non&ndash;geometric column values, such as MATERIAL. For example, suppose the .ptb has geometric columns OD and ID and non-geometric columns MATERIAL and CONNECTION_TYPE. I could have rows in the .ptb such as:</p>
            <p class="para_item">OD &nbsp;&nbsp;ID &nbsp;&nbsp;MATERIAL CONNECTION_TYPE &nbsp;&nbsp;&nbsp;MEMBER_NAME &nbsp;PART_NAME</p>
            <p class="para_item">&nbsp;&nbsp;&nbsp;2 &nbsp;&nbsp;&nbsp;&nbsp;1 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Copper &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Flanged &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;M1001 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;template.prt</p>
            <p class="para_item">&nbsp;&nbsp;&nbsp;2 &nbsp;&nbsp;&nbsp;&nbsp;1 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Bronze &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Flanged &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;M1001 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;template.prt</p>
            <p class="para_item">These rows share the same geometry, such that they will both use member M1001 from the template.prt part's family.</p>
            <table border="0">
               <tr>
                  <td valign="top" align="left"><img align="left" src="../graphics/note.gif" alt="Note" title="Note"></td>
                  <td valign="bottom" align="left" width="100%">
                     <div class="para_note">
                        <p class="para_note_body">You are not required to use this feature. If you want, you can have each row in the table specify a different MEMBER_NAME and thus generate a separate part file when it is instantiated. If, in this situation, you use different MEMBER_NAME values for rows which have the same &quot;geometry&quot;, the update_fam_from_ptb program will issue a warning to alert you to this, but this is <b class="uiTerm">OK</b> and is not an actual error.
                        </p>
                     </div>
                  </td>
               </tr>
            </table>
         </li>
         <li>
            <p class="para_item">The update_fam_from_ptb program can be used in two ways:</p>
            <p class="para_item">To update the part family template part with the information in the ptb file.</p>
            <p class="para_item">To validate that the information in the part family template part agrees with the data in the ptb file. This is the cross check mode and is the mode that the program executes in whenever the <b class="uiTerm">&ndash;update</b> option is not specified.
            </p>
            <p class="para_item">Use the <b class="uiTerm">Cross-check</b> mode anytime you are unsure as to whether or not the ptb and part family template part are synchronized. For example:
            </p>
            <p class="para_item">update_fam_from_ptb &ndash;pd . my_part_table.ptb</p>
            <p class="para_item">will check that the data in the part family template part(s) referenced by my_part_table.ptb agrees with the data in the .ptb. No actual update or modification will take place.</p>
         </li>
         <li>
            <p class="para_item">The update_fam_from_ptb program is rather cryptic in its display of status and error messages. Always check the update_err_log.txt file after executing the program to see a full list of warnings and errors.</p>
         </li>
         <li>
            <p class="para_item">It is not required that the .ptb file actually reference part family template parts. If you do not wish to use part family templates, you can create your .ptb file to reference individual part files directly, instead of the template file. These individual files can be part family members that you have instantiated or standard NX part files that do not belong to a part family. In these situations, you omit the MEMBER_NAME column from the .ptb file and specify the different file names in the PART_NAME column.</p>
         </li>
         <li>
            <p class="para_item">The <b class="uiTerm">&ndash;delete</b> option should be specified as an argument to update_fam_from_ptb only when you need to delete the existing part family data within the template part. The two times that you need to do this are:
            </p>
            <p class="para_item">When you are changing the MEMBER_NAME values of existing rows in the .ptb / template.</p>
            <p class="para_item">When you are changing the set of geometric columns that define the part family, for example, you are adding or removing columns from the .ptb that correspond to geometric expression in the template part. For example, in Item 2 above, if I removed the ID column from the .ptb (and the ID expression from the template part), I would need to specify &ndash;delete. This is so that the family data in the template part which used to contain ID would be removed and a new set of family data created without this column.</p>
            <p class="para_item">If you are not in this situation, for example, you are merely adding one or more rows to the .ptb, you do not need to use <b class="uiTerm">&ndash;delete</b> and you should <em>NOT</em> use it.
            </p>
         </li>
         <li>
            <p class="para_item">Using <b class="uiTerm">&ndash;delete</b> causes a new part family object to be created in the template part and requires that you (manually) update all of the existing part family members based on the new template. The update_fam_from_ptb program does <em>NOT</em> update existing part family members. This is because in native mode we do not know where the member parts might be located, and in Teamcenter mode we do not want to update members of the previous revision of the template part. Typically, in Teamcenter, you will update your template part and assign it a new revision and then create new revisions of the member parts.
            </p>
         </li>
         <li>
            <p class="para_item">If you modify the .ptb file and merely add a non&ndash;geometric column (or columns) for the existing rows in the .ptb, you do not need to run update_fam_from_ptb. This is because the purpose of the update program is to synchronize the geometric information in the two files. If only non&ndash;geometric columns are being added (or removed) from the .ptb file, there is no need to update. You might, as a precaution, execute update_fam_from_ptb in <b class="uiTerm">Check</b>mode, for example, without the &ndash;update flag, to verify that the two files still agree.
            </p>
         </li>
      </ol>
      <p class="para_topic">This rule applies for APPLIED characteristics as well, as they are non&ndash;geometric. For example, suppose I add an APPLIED characteristic to my .ptb to define the COMPONENT_NAME dynamic input box. And I add a non&ndash;geometric column, REFERENCE_SET. I do not have to execute the update_fam_from_ptb program against this .ptb (and its part template).</p>
      <p class="para_topic">This rule does NOT apply if you add rows to the table that specify new MEMBER_NAME values, such as no current rows in the table contained these new MEMBER_NAME values. In this case, you do need to run update_fam_from_ptb, but do not need to specify &ndash;delete.</p>
      <p class="para_topic">If you are adding rows, but all of the new rows have MEMBER_NAME values that already are in the table, you do not need to run the program. (Again, running it in <b class="uiTerm">check</b> mode is recommended).
      </p>
   </body>
</html>
