Pro/ENGINEER: Anatomy of a Trail File, Part 2

Read Part 1

Recording/Editing Techniques

Trail files are often touted as a crash recovery mechanism. While they can serve this function in very limited circumstances, they are usually not that helpful for this activity. For repetitive tasks, however, trail files are extraordinarily helpful.

To make them extraordinarily helpful, trail files must be recorded and edited very carefully. Right out of the box, Pro/ENGINEER doesn't record very efficient trail files. They will function, but can be excessively verbose and difficult to edit.

Here is an example of a trail file segment that opens a part file. It's a good example of how not to record trail files. Generally speaking, avoid typing in names when you can select them.

~ Select `main_dlg_cur` `MenuBar1` \
1  `File`
~ Close `main_dlg_cur` `MenuBar1`
~ Activate `main_dlg_cur` `File.psh_open`
< 2 0.256000
~ Input `file_open` `Inputname` \
 `a`
~ Input `file_open` `Inputname` \
 `ab`
~ Input `file_open` `Inputname` \
 `abc`
~ Input `file_open` `Inputname` \
 `abc.`
~ Input `file_open` `Inputname` \
 `abc.p`
~ Input `file_open` `Inputname` \
 `abc.pr`
~ Input `file_open` `Inputname` \
 `abc.prt`
~ Update `file_open` `Inputname` \
 `abc.prt`
~ Activate `file_open` `Inputname`
!Command ProCmdModelOpenExe was pushed from the software.
!15-May-08 17:39:09  Start ./abc.prt.2
!15-May-08 17:39:11  End   ./abc.prt.2

 
Compare this against a trail recorded by selecting (not typing) the name of the model to open, and using the config.pro option CMDMGR_TRAIL_OUTPUT set to YES. This option is meant to simplify trail file output and make the menu picks less dependent on the menus. If Tools / Customize Screen is used to move menus around, this mapkey will continue to work, but the previous one might fail.

~ Command `ProCmdModelOpen` 
< 2 0.256000
~ Select `file_open` `Ph_list.Filelist` \
1  `abc.prt`
~ Activate `file_open` `Open`
!Command ProCmdModelOpenExe was pushed from the software.
!15-May-08 17:36:11  Start ./abc.prt.2
!15-May-08 17:36:16  End   ./abc.prt.2

 
As you can see the results are much simpler. In fact, following the rules from Part 1, four of the eight lines can additionally be reduced:

~ Command `ProCmdModelOpen` 
~ Select `file_open` `Ph_list.Filelist` \
1  `abc.prt`
~ Activate `file_open` `Open`

 

There will be times when you need to automate something using an existing trail file but you either don't have the luxury or the desire to re-record the trail file. In this case you want to eliminate the fluff, but keep the necessary elements. From the verbosely recorded sequence, the following can be completely eliminated:

~ Input `file_open` `Inputname` \
 `a`
~ Input `file_open` `Inputname` \
 `ab`
~ Input `file_open` `Inputname` \
 `abc`
~ Input `file_open` `Inputname` \
 `abc.`
~ Input `file_open` `Inputname` \
 `abc.p`
~ Input `file_open` `Inputname` \
 `abc.pr`

 

Of the remaining lines, the first two can typically be eliminated.

~ Input `file_open` `Inputname` \
 `abc.prt`
~ Update `file_open` `Inputname` \
 `abc.prt`

 

Which leaves this as a result:

~ Update `file_open` `Inputname` \
 `abc.prt`

 

When you are replaying a trail file without changing the model used (i.e. for running a benchmark), a lot of these edits are not required. When you are using the trail file as a template for different models, these type of edits are very important, making it much easier to adapt the trail file.


Next time: Robust selection techniques with trail files

Pro/WebLink: Changing Model Relations Quickly with Wildfire 4

Changing relations is often a frustratingly difficult task to perform in a Pro/ENGINEER model. This is especially true for assemblies, even ones with only a few dozen parts.

Up until Wildfire 4, there were many ways to accomplish this involving some kind of file export/import process. These include mapkeys, J-Link, and Pro/WebLink, each having its own complications.

Starting with Wildfire 4, the PFC API's (Pro/WebLink, J-Link, VB API) have been enhanced to allow more direct access to relations. Relations can be read into a string sequence (a form of dynamic array), modified within the sequence, then re-applied to the model very quickly. This makes programmatic editing of relations very simple, fast, and easy.

While using the PFC API's to perform this action on a single part model may seem overkill compared to using mapkeys, consider that mapkeys don't scale well. If you're doing a one-off task, mapkeys work great. When you need to perform the task for all components of an assembly, whether large or small, the API's can accomplish the task much more quickly and reliably. For assemblies with thousands of components, mapkeys just won't get the job done.

What follows is an example of a Pro/WebLink function to add relations to a model from an array. First, existing relations are obtained from the model using the "Relations" property (a stringseq object), then elements of the array are appended to the stringseq using the Append() method. Finally, the modified stringseq is reassociated to the model. The change is immediate and does not require a regeneration.

function addRelations ( model, array ) {

    // get relations as stringseq object
    var rel_seq = model.Relations;

    // append array elements to stringseq
    for (var i=0; i<array.length; i++) {
        rel_seq.Append(array[i]);
    }

    // assign modified stringseq to model relations
    model.Relations = rel_seq;

}

 
Code to call the function is also pretty basic. Using the CurrentModel property of the session object, the model object can is obtained. Here an array is defined, but even better would be to pull the values from an HTML TextArea or some other data source. Lastly, the addRelations() function is called with the model object and the relations array.

// get current model
var session = pfcGetProESession();
var model = session.CurrentModel;

// define new relations as array
var array = new Array( "abc=123", "def=456" );

// add relations
addRelations(model, array);

 
A recursive procedure to apply relations to assembly components is only moderately more complicated. See my other examples only how to rcursively process assembly components with Pro/WebLink.

• Sending Data from Pro/ENGINEER to Microsoft Excel with JavaScript
• Sending Pro/ENGINEER Point Data to Excel
• Sending Your Pro/ENGINEER Assembly BOM to Excel
  

Comments and questions are always welcome, either here on my blog or via email at MarcMettes@InversionConsulting.com.

Pro/ENGINEER: Anatomy of a Trail File, Part 1

Trail File Basics

Despite a diverse set of API's, Pro/ENGINEER trail files represent a reliable and robust method of automating Pro/ENGINEER activities. They are not the perfect fit for every application, but for many needs they work great.

Trail files are best used after recording specific actions, then combining the resulting content to create the finished trail file. In order to edit trail files it is important to understand their content.

Here is an example of a trail file header. These entries are generated by Pro/E upon startup without any action from the user. The first line is always present and always required in your trail files. Some other lines that stand out indicate that Wildfire 2 was used and the ProE to JT Translator is started via a protk.dat file. Both of these are status messages and are not required.

!trail file version No. 1301
!Pro/ENGINEER  TM  Wildfire 2.0  (c) 2004 by Parametric Technology Corporation  All Rights Reserved.
< 0 1.135407
< 0 0.964741
< 0 0.879000
< 0 0.842000
!Application (VisProducts): started via registry.
!    exec path: /opt/UGS_JtTranslators/ProE/EAI_Proe/proe/sun/proclientWF2
!    type: synchronous Pro/TOOLKIT EXE
< 0 0.846000
~ Move `splash_dlg` `splash_dlg` \
2 7.472141 6.432063

 

I have never needed to keep lines that start with the 'less than' symbol and typically always remove them if piecing together a trail file:

< 0 1.135407
< 0 0.964741
< 0 0.879000
< 0 0.842000

 

As the lines relative to the 'splash_dlg' are unnecessary, all that is needed from the above is this:

!trail file version No. 1301

 

Although we don't need the lines associated with the 'splash_dlg', the syntax is important to understand as it is used throughout trail files. The trail file 'interpreter' sees the backslash continuation character (\) as an instruction to treat the following as a single line:

~ Move `splash_dlg` `splash_dlg` \
2 7.472141 6.432063

 
If the entry is to be removed, both lines should be removed, or the trail file will not work. Don't try to combine the lines. That won't work either. If you need the entry, leave it as is. The interpreter can handle it, and you shouldn't worry about it consuming more than one line.


Another note in the JT Translator startup messages is that they start with an exclamation point. This is the 'comment' indicator, instructing the interpreter to ignore the line. All lines starting with an exclamation point are not needed and can be removed, if desired. In some cases, I'll leave a comment in place to help identify the end of an action, but typically they are removed.

To assist in editing trail files, I usually add comment lines before and after sections. This makes it very easy to copy or move sections within the file.

!!!
!!! Run massprop calculation
!!!
~ Select `main_dlg_cur` `MenuBar1` \
1  `Analysis`
~ Close `main_dlg_cur` `MenuBar1`
~ Activate `main_dlg_cur` `Analysis.psh_analysis_modelanl`
~ Activate `modelprop` `Compute`
!%CIMass Properties calculation completed.
~ Activate `modelprop` `Close`
!!!
!!! Exit session
!!!
~ Select `main_dlg_cur` `MenuBar1` \
1  `File`
~ Close `main_dlg_cur` `MenuBar1`
~ Activate `main_dlg_cur` `File.psh_exit`
! Message Dialog: Warning
!               : Do you really want to exit?
~ Move `UI Message Dialog` `UI Message Dialog` \
2 14.561095 12.836755 
~ FocusIn `UI Message Dialog` `no`
~ FocusIn `UI Message Dialog` `yes`
~ Activate `UI Message Dialog` `yes`
!End of Trail File

 

Part 2: Recording robust trail files

Pro/Toolkit: Simplifying Your protk.dat File with Environment Variables

If you find yourself editing your protk.dat files because you are changing the location of the application or you are using multiple hardware architectures (i.e. Unix and Windows, Win32 and Win64, etc), STOP! Put down the mouse, and slowly step away from the keyboard.

If you use environment variable creatively, you will need one protk.dat file for all of your installations. That's it, just one. Unix and Windows you ask? YES! 32 bit and 64 bit Windows? YES!

The first thing you need to do is to setup an environment variable for the install folder of your application. Call it what you want, but be consistent. I am going to give examples here about the open source Pro/ENGINEER to BRL CAD converter. I'll use the environment variable PROE2BRL_INSTALL for the install folder.

The resulting protk.dat file looks like this:

name PROE2BRL
startup dll
exec_file $PROE2BRL_INSTALL/proe2brl.dll
text_dir $PROE2BRL_INSTALL/text
allow_stop TRUE
end

 
I know what you're thinking, you think you'll have to change those paths for Windows machines. WRONG! It's a little known secret that Pro/ENGINEER on Windows can handle unix style pathing and environment variable syntax, and not just in protk.dat files. This includes the config.pro file. It may seem strange to those die-hard Windows guys, but it works.

Now the 64 bit Windows guy in the audience (I'll call him Dustin), shouts out "What if we have 32 bit and 64 bit DLL's?!" Well Dustin, no problem there either because Pro/ENGINEER sets some platform specific environment variables that we can use.

We can separate the 32 bit and 64 bit DLL's into two folders. For Windows, this would be "i486_nt" for 32 bit DLL's and "x86e_win64" for 64 bit DLL's. If we plug in the MC environment variable, Pro/ENGINEER uses the correct DLL based on the current architecture.

The resulting protk.dat file looks like this:

name PROE2BRL
startup dll
exec_file $PROE2BRL_INSTALL/$mc/proe2brl.dll
text_dir $PROE2BRL_INSTALL/text
allow_stop TRUE
end

 
Now the Unix guys, bored with talk of mere a 32 bit application, rant "On Unix, our DLL's are called shared objects and have a .so extension and ... blah blah blah ...". Again, not a problem. If that's a concern, setup another environment variable, let's call it PROE2BRL_EXEC. On Unix this can be set to "proe2brl.so" and on Windows "proe2brl.dll". (Or, just call it "proe2brl.dll" and skip this step)

The resulting protk.dat file looks like this:

name PROE2BRL
startup dll
exec_file $PROE2BRL_INSTALL/$mc/$PROE2BRL_EXEC
text_dir $PROE2BRL_INSTALL/text
allow_stop TRUE
end

 

In the config.pro, we can use this:

protkdat $PROE2BRL_INSTALL/protk.dat

 

These techniques get us much closer to the mythical "one install" for all platforms. Also be sure to check out my previous article on how to conditionally load your Pro/Toollkit applications.


Questions and comments are always welcome, either here on my blog or at MarcMettes@InversionConsulting.com.