Read Part 2
In my experience, there are three main uses for trail files: Recovery, Benchmarking, and Templating. Generally speaking this series of articles is about templating trail files. Templating is the modification of trail files to perform actions that are not specific to a particular model.
In more complex trail files, selection of items eventually becomes a necessity. Doing this in a repeatable way can become very challenging, especially if working with different models or models that are changing often.
Selections of models, features, annotations, and notes can be accomplished in various ways, but selections of geometry items such as surfaces and edges are very difficult in such a manner that it works for different models. Trail file selections using the graphics window are almost never transferable for use with other models.
Model Tree
When you click on an item in the model tree, you'll see, for example, "node4" or "node31" appear. Here is an example of a trail file entry caused by selecting 'Note_1'.
~ Select `main_dlg_cur` `PHTLeft.AssyTree` \
1 `node6`
!Note_1
These node numbers are assigned by Pro/ENGINEER on a first come, first served basis. When the model is first opened the node numbers are assigned in a bottom first, upwardly increasing sequence, based on what is displayed at that time.
For example, if the model tree of a part is shown with features and annotations when the model is opened, the following table reflects the node number assignments. The top level item (the part itself) is node 0 (zero), then working up from the bottom the node numbers increase. As you can see, even the 'Insert Here' pointer has a node number.
Item Node #
ABC.PRT 0
Note_0 8
Note_1 7
Note_2 6
Feat1 5
Feat2 4
Feat3 3
Feat4 2
Insert Here 1
The tricky part comes when new nodes are shown either through expansion of existing nodes (i.e. to show features of a component) or modification of the model tree filters. Regardless of where in the model tree they appear, the new nodes are given new node numbers based on the previous largest value.
As an example, if your model tree initially shows nothing, then annotations are added, then features are added, you might get a result like this:
Item Node #
ABC.PRT 0
Note_0 3
Note_1 2
Note_2 1
Feat1 8
Feat2 7
Feat3 6
Feat4 5
Insert Here 4
The node numbers for a complex assembly might even appear to be randomly assigned. Disappointingly, use of 'Expand All' doesn't produce very orderly node number assignments.
Beyond the top level nodes, use of the model tree can be very complicated. It is definitely something that can be done, but requires some preprocessing to generate a trail file programmatically before it is run. Most likely, trail files making more than trivial use of the Model Tree will not be usable for other models.
Search Tool
Another approach to selections with trail files is the "Search" tool (i.e. Edit -> Find). The Search tool works very well when selecting items with a trail file. Selections of specific models, features, or numerous other entities can be accomplished easily.
The downside to this approach is that you lose some control over where in an assembly hierarchy objects can be located. An option exists to search only in the top level, but an 'All Levels' search will return results from any level.
Another difficulty is that multiple results will be obtained when searching for common objects, such as hardware parts, shared subassemblies, and models with standard features, etc. There is a mechanism to select specific items, but this requires a great deal of information that has to be provided ahead of time.
Defaults
Another thing to keep in mind is that the last option you use in the Search Tool may be the default option when the Search Tool is used a second time. A recommendation is always to set explicitly every option (even if it is the default) every time the Search Tool is used with a trail file. This will produce more robust trail files.
It may be extra work to click on other options that you don't want in order to record the selection that you do want, however it's worth the effort. Extra baggage code in the trail file can usually be removed, if that is desirable.
Example
A typical scenario is the need to select an item such as a component, a feature, or a note using its name. Here is an example of using the Search tool to search an assembly for a subassembly called 'A.ASM'. I have added comments to indicate the major sections.
!! Start the Search tool
!!
~ Select `main_dlg_cur` `MenuBar1` \
1 `Edit`
~ Close `main_dlg_cur` `MenuBar1`
~ Activate `main_dlg_cur` `Edit.Find`
!!
!! Select entity type to be searched for
!!
~ Open `selspecdlg0` `SelOptionRadio`
~ Close `selspecdlg0` `SelOptionRadio`
~ Select `selspecdlg0` `SelOptionRadio` \
1 `Prt_or_Asm`
!!
!! Limit search to top level
!!
~ Activate `selspecdlg0` `SelScopeCheck` \
0
!!
!! Enter name
!!
~ Update `selspecdlg0` `ExtRulesLayout.ExtBasicNameLayout.BasicNameList` \
`A.ASM`
!!
!! Perform search by clicking 'Find Now' button
!!
~ Activate `selspecdlg0` `EvaluateBtn`
!!
!! Selecting item(s) in results
!!
~ Select `selspecdlg0` `ResultList` \
1 `-1:69:[39]`
!!
!! Hit 'Close' in Search dialog (even though it says 'CancelButton')
!!
~ Activate `selspecdlg0` `CancelButton`
If you follow along in your trail file while performing the search, you can see that each action produces a certain output, which is mostly self explanatory. What is not so obvious is the syntax of the output when items are selected in the search results.
Selections
The syntax used for selection of components differs from the selection of other types of entities, but it is similar. The `-1:69:[39]` specifier is a colon separated list of three fields: ID, Type, Component Path.
The first field is an item ID field (i.e. feature id, note id, etc), except for components where it always shows -1. The second field is a numeric code corresponding to the type of entity in the search, whether that be 'Feature', 'Annotation', 'Component', etc. The third field specifies a "Component Path" which is a list of component feature IDs from a top level to a subassembly or component. The "[39]" indicates that the selected component is feature ID 39 in the top level assembly.
A selected item generating this syntax `2:147:[40][40][41][61]`, is a note (or some other annotation) with id 2 and found through the component id sequence of 40 (level 1 component id), 40 (level 2 component id), 41 (level 3 component id), 61 (level 4 component id).
Select All
The "Select All" action (Ctrl-A) can be used at any time and generates the following trail code. Even if a selection of an item is required for an interactive user prior to using "Select All", this can be used without it in a trail file.
~ Select `selspecdlg0` `ResultList` \
-1
Depth
The depth of the search is controlled by the "Include submodels" option in the Search Tool dialog. Checking or unchecking this option adds one of the following code sequences to the trail file.
!! Limit search to top level ('Include submodels' is not checked)
!!
~ Activate `selspecdlg0` `SelScopeCheck` \
0
!! Search all levels ('Include submodels' is checked)
!!
~ Activate `selspecdlg0` `SelScopeCheck` \
1
Closing The Dialog
As you can see from my comment, hitting Close in the dialog adds a curiously named "CancelButton" entry. Just remember if you're editing the trail file, that this means "Close".
!! Hit 'Close' in Search dialog (even though it says 'CancelButton')
!!
~ Activate `selspecdlg0` `CancelButton`
Types
One of the first things typically done when using the Search Tool is the choice of entity type. If you're familiar with the tool, you know that there is a very wide range of type options to choose from.
Type selection generates code such as this:
~ Open `selspecdlg0` `SelOptionRadio`
~ Close `selspecdlg0` `SelOptionRadio`
~ Select `selspecdlg0` `SelOptionRadio` \
1 `TYPENAME`
Some examples of `TYPENAME` are `Prt_or_Asm`, `Component`, `Feature`, `Annotation`, `Note`, `Location`, `Datum`, `3D Curve`.
As discussed earlier, the numeric code for the type is reflected in the code generated when selecting items in the search results. The type code for `Annotation` and `Note` are both 147, while `Prt_or_Asm` ("Solid Model" from the GUI) and `Component` are both 69.
By Name
The Search Tool allows case-insensitive name searches, and wildcards can be used to make the search criteria more generic. The basic syntax is as follows:
~ Select `selspecdlg0` `RuleTab` \
1 `Attributes`
~ Update `selspecdlg0` `ExtRulesLayout.ExtBasicNameLayout.BasicNameList` \
`NAME`
Examples of `NAME` with and without wildcards might be `12345678_OBSOLETE.PRT`, `DEFAULT`, `ASM_TOP`, `ASM_*`, `*65-5*`, `*side*`.
By ID
If a specific feature ID or note ID is known, this can be searched for as well. This appears in the GUI under the "History" tab and generates the following entry:
~ Select `selspecdlg0` `RuleTab` \
1 `Misc`
~ Select `selspecdlg0` `RuleTypes` \
1 `ID`
~ Update `selspecdlg0` `ExtRulesLayout.ExtBasicIDLayout.InputIDPanel` \
`IDENT`
Where `IDENT` is an integer number such as `1`, `2`, `3`, etc. Note that the History tab goes by the name of Misc in the trail file. All other tabs follow their name in the trail file more directly.
By Parameter Value
In addition to entity name searches, the Search Tool can perform searches based on parameter values, using the "Expression" radio option in the "Attributes" tab. Keep in mind that there are differences in the behavior of "Component" searches versus "Solid Model" searches. Testing will ensure your searches produce the desired results.
This sequences will prep the dialog box for searches based on parameter values:
~ Select `selspecdlg0` `RuleTab` \
1 `Attributes`
~ Select `selspecdlg0` `RuleTypes` \
1 `Expression`
The type must be selected first (real number, string, integer, yes/no), then the name of the parameter. Be careful when selecting the parameter name from the drop down list, because only a sequence number will be recorded. For a different set of models, the sequence number may not correspond to the same parameter name as when you recorded the trail files.
This results from choosing a parameter from the list:
~ Open `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList`
~ Close `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList`
~ Select `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList` \
1 `51`
This results from typing in a parameter name:
~ Open `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList`
~ Close `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList`
~ Input `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList` \
`DES`
~ Input `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList` \
`DESC`
~ Update `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList` \
`DESC`
The typed syntax can be simplified, by removing the 'Input' entries and leaving the 'Update' entry, to this:
~ Open `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList`
~ Close `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList`
~ Update `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList` \
`DESC`
The 'Value' field in the dialog box corresponds to the 'ExprValuesList'. Any value can be entered, and wildcards can be used as well. Note that string searches seem to be case insensitive only when used with wildcards.
~ Update `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprValuesList` \
`brack*`
The "Comparison" can be changed from the default of "is equal to". There are seven operators available, with this being an example of greater than (more useful for numeric comparisons):
~ Open `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprOperandLabel`
~ Close `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprOperandLabel`
~ Select `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprOperandLabel` \
1 ` > `
The list of comparisons (for ExprOperandLabel) is:
` == ` is equal to
` != ` is not equal to
` < ` is less than
` > ` is greater than
` <= ` is less than or equal to
` >= ` is greater than or equal to
` * ` exists
` !* ` does not exist
When searching by parameter, the parameter type must be selected first.
~ Open `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList`
~ Close `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList`
~ Select `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList` \
1 `TYPEID`
Where `TYPEID` is 50, 51, 52, or 53 for Real Number, String, Integer, and Yes/No, respectively.
Look In
The 'Look In' drop down list allows for user control of the model (or hierarchy) to be searched. Here are some examples of selections made from the drop down list.
Top level selected:
~ Input `selspecdlg0` `LookInDrop` \
`12345678.ASM`
Component selected:
~ Select `selspecdlg0` `LookInDrop` \
1 `12345678_SKEL.PRT (12345678, id 43) (43)`
It is also an editable field in which you can attempt to enter model names. Unfortunately, the rather strong autocomplete nature may prevent entering the correct model name, or stop at another model, or result in garbage entered. None of this will produce a useful trail file.
The good news is that the syntax used for top level example can be used for any model at any level:
~ Input `selspecdlg0` `LookInDrop` \
`23456789.ASM`
This differs from other trail file entries in that typically the "Update" statement is kept while the "Input" entries are eliminated, because they are typically redundant. It is most likely the autocomplete functionality that makes this necessary.
When using this syntax, which lacks the component path (list of component ids), you'll lose some control if the model is used multiple times in an assembly hierarchy. Not a major problem, just something to be aware of. Based on my testing, the Search Tool uses the model that appears last in the model tree, if multiples exist.
Tabs
A specific tab in the Search Tool dialog can be selected using the following example:
~ Select `selspecdlg0` `RuleTab` \
1 `TABNAME`
Where `TABNAME` is `Attributes` for the Attribute tab, `Misc` for the History tab, `Status` for the Status tab, and `Geometry` for the Geometry tab.
Another Example
Combining several of these elements, here is an example that searches for parts and assemblies within all levels of ASM0002.ASM that for parameter DESC have a value matching "brack*", selects all found, and closes the dialog:
!!
!! Start the Search tool (via Ctrl+F)
!!
~ Activate `main_dlg_cur` `ProCmdMdlTreeSearch.edit_t`
!!
!! Select "Solid Model" as entity type to be searched for
!!
~ Open `selspecdlg0` `SelOptionRadio`
~ Close `selspecdlg0` `SelOptionRadio`
~ Select `selspecdlg0` `SelOptionRadio` \
1 `Prt_or_Asm`
!!
!! Restrict search to a subassembly
!!
~ Input `selspecdlg0` `LookInDrop` \
`ASM0002.ASM`
!!
!! Search all levels ('Include submodels' is checked)
!!
~ Activate `selspecdlg0` `SelScopeCheck` \
1
!!
!! Go to "Attributes" tab, select "Expression" radio button
!!
~ Select `selspecdlg0` `RuleTab` \
1 `Attributes`
~ Activate `selspecdlg0` `selspecdlg0`
~ Select `selspecdlg0` `RuleTypes` \
1 `Expression`
!!
!! Select "String" from parameter value type pull down
!!
~ Open `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList`
~ Close `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList`
~ Select `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprTypesList` \
1 `51`
!!
!! Enter parameter name
!!
~ Update `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprParamsList` \
`DESC`
!!
!! Enter parameter value search string
!!
~ Update `selspecdlg0` `ExtRulesLayout.ExtExprLayout.ExprValuesList` \
`brack*`
!!
!! Perform search by clicking 'Find Now' button
!!
~ Activate `selspecdlg0` `EvaluateBtn`
!!
!! Select all in search results
!!
~ Select `selspecdlg0` `ResultList` \
-1
!!
!! Hit 'Close' in Search dialog (even though it says 'CancelButton')
!!
~ Activate `selspecdlg0` `CancelButton`
Both the Model Tree and Search Tool are useful when used in trail files. Use of the Model Tree is more limited because it requires knowledge of its contents before the trail file is generated. The Search Tool, when used properly, provides one of the most robust methods of performing selecting with trail files. With minor editing, trail files utilizing the Search Tool can be generated quickly, easily and can be applied to a wide range of models.
Next time: Mapkeys and Trail Files
No comments:
Post a Comment