Understanding Trail Files

[russelld.wooten]

Hello ProE gurus,

Does anyone know what the contents of a trail file mean? I contacted PTC and you guessed it...they do not have any documentation, help, or training on this....I would like to edit my own trail files to create some training files, but I need to understand the syntax.....

Russell

[ptc-1977371]

I was going to post my own question asking the same thing. I am surprised that nobody has responded to this. I am sure there is someone out there that understands the syntax. I am stuck supportinga perl script that generates a trail file. I assume that somone in the past captured a trail file, massaged it, then put it inside print statements of a perl script. Now I am in a situation where I need to change the script and the trail file, but I don't really understand what it is doing. If anyone has any knowledge about this, any help would be greatly appreciated.

[ehill]

Well it used to be very straightforward, back in the day of full
right-side menus. It was possible to compile a trail file or a mapkey
just using your knowledge of the menus. Still, it was almost always
easier to record a trail file, then cut and paste parts of the result to
get what you wanted.



Then R20 came along, with pull-down menus and dialog boxes, and that all
changed. The syntax has rhyme and reason to it, but in my experience
there are just too many variations on menus, buttons and other subtle
differences to bother trying to comprehend it all. It's too easy to
record a trail file that executes what you want to make "learning the
language" worthwhile. Just record the sections you need, and
concatenate them into an end product.



If it makes your trail generation programming easier, there are still
some "behind the scenes" right side menus, so that even very old
mapkeys/trail files will work. For example, #FEATURE;#RELATIONS; will
still bring up the relations dialog, even though those menus aren't
directly available anymore. They don't always work, though, so it can
be a tough trial-and-error process to determine what works and what
doesn't.



Best Regards,

[ptc-752395]

I haven't been able to get this to workyet, but theoretically, you find the most recent version of the trail file while you are in Windows, and then open it with Pro/E. Use model player to play the commands recorded, and get to the point where your model crashed, and save a copy as "whatever".



You have to rename the file while you're in Windows, because Pro/E will juststart another trail file with the same namewhen you open the program.



But the idea is to rename the file in Windows, open it in Pro/E and play it in Model Player.



When I try it, I get an error message that says the file is a Versioned File and stops.



I have opened the system file and used the "purge" command to remove all of the extraneous versions, but no success to date.



I hope this helps.

[ptc-1612625]

Not sure where this thread initiated from but for whomever is interested in trail file recovery see the below article By Mirza Saqib Saeed of Wahid Industries

The key is to remember step 5: Set "set_trail_single_step" in your config.pro

Regards,






Robert Pomarico
Application Engineer, TriStar, Inc.

[ptc-752395]

Robert,

Thanks for responding. I have a copy of this article too. It doesn't work very well. It wants you to modify your config_pro file for one reason, but it does have a couple of things that are valuable. It doesn't solve my problem, but it does capture the idea of a trail file to be the backup if you make a mistake while deleting things. Somehow, anything I try gets stopped by this idea of a "versioned file. The "Help" instructions with WF2 don't even touch the definition of the words.

The Pro/E help files say to just change the name of the trail file and run it with the Model Player. Apparently, you can take a model and change its name and change the extension from .txt to .txa and then there are ways to insert "directives" or instructions to do things and make a training file with Notepad.

That's kind of a neat idea.



James

[ptc-752395]

Welll guys I appreciate the help, but I don't think there is any answer to this situation. I looked in one of the assemblies I had, and all of the parts and the assembly are "versioned files", so there's nothing to do.

Since I've tinkered with the config file based on the instructions higher up in this thread, I don't think Pro/E is creating any trail files any more anyway, at least I don't see any changes when I modify an assembly. This is a solution of a sort.

I worked a month with WF3, and found out that if you pay $25,000 for a seat with Advanced Assembly and Surfaces and about anything else you could imagine, the program does work better. They've fixed many of the issues where the screens dissappear behind one another, for example.That makes the program "feel" better, if nothing else.

On that program, Pro/E added subscripts on parts and generated a history of each one, so you would see blivit.prt.1, for example. Windows doesn't show me that this is happening for me and my program.



Someone volenteered to review one of my trail files to see if they could solve this, but I would have to send all of the parts in the assembly, so that would be pretty tough. Besides, between different issues of Pro/E and all of the different add-ons, it's doubtful that any answer obtained would work for me.

So thanks anyway, sorry for the trouble.

James

[ehill]

James,



It sounds like you are having trouble finding the information you are
looking for on trail files. It has unfortunately always been a bit
confusing for people new to Pro/E, or even experienced in using Pro/E,
and has never been well documented. Some of the information you have
been directed to is outdated, so I will try to clear things up for you.



1. Pro/E always creates a new trail file named trail.txt.# when you
start a new session. You can't stop it from happening; the only thing
you can do is control where it creates these files using the config.pro
option trail_dir.
2. Pro/E always versions trail files (and model files, and
practically every other file it ever stores, regardless of the file
type) by appending a .# suffix onto the file name. This is how Pro/E
keeps track of the change history (rather crude, and unchanged over the
last 20 years). When you save a model file, or start a new Pro/E
session, it makes a new file with the same core file name, but with an
incremented version suffix. For example, the first time you start
Pro/E, it creates a trail file with the name trail.txt.1. The next time
you start Pro/E, the trail file will be named trail.txt.2. And so on.
This is a holdover from the days when Pro/E only ran on UNIX-based
systems, which handle file names much differently than Windows-based
systems.
3. Windows does not play nice with Pro/E versioned files. Windows
wants to identify a file's type by looking at the last suffix (usually
called the file extension) in the file name. For example, it identifies
an Excel file when it sees .xls as the last suffix, or a text file when
the suffix is .txt. This does not work well with Pro/E's file
versioning scheme of adding a .# to the end of each and every file it
stores. There are more issues related to this (program-file
associations, for example) that I won't go into here because they aren't
too relevant to trail files.
4. Windows hides the file extension (suffix) by default. That
means it displays only the prefix in a file name to you when you are
browsing with Windows Explorer. This can make it confusing to deal with
Pro/E versioned files (and other files too, in my opinion). You can
turn off this feature if you like (see this link
<">http://support.microsoft.com/kb/307859/en-us> ). I always turn it off,
because I like to have full visibility and control over my files.
5. If you want to play a trail file that you "recorded" in a
previous session of Pro/E, you must rename it by changing the prefix to
something other than trail. You must also remove the versioning number
suffix. For example, if you record a trail file that is stored as
trail.txt.44, you must rename it to something like trainingfile.txt.
Just renaming it to trail.txt will not work. Renaming it to
trainingfile.txt.44 will not work, either. Note that although spaces
are usually not allowed in any Pro/E file name, this is an exception.
6. To play back trail files, you do not use the Model Player.
Model Player is for stepping through the regeneration cycle of a model,
so you can follow along in how the model was built. For trail files,
you can use one of two options to play back so that a user can follow
along (i.e., as a training program):

a. Use the config.pro option set_trail_single_step. In
Wildfire releases of Pro/E, this will bring up a little dialog box with
Step, Continue and End buttons that the user can click to progress
through the trail file. You can also just press enter to step through
the file. This method can be a little bit cumbersome (lots of enters or
button clicks) for trail files that have too many little steps that
don't do much, so you have to be stingy with the picks when recording
your trail file.
b. Use the config.pro option trail_delay. This will put a
fixed delay (in seconds) between each action recorded in the trail file.
This method saves the user on lots of enters or Continue clicks. The
down side is that they will have to wait too long for simple actions
(even mouse model spins!), and not long enough for more complex actions.

7. Trail files will go OOS (Out Of Sequence) if they encounter a
step that can't be executed properly. This can happen for a variety of
reasons, such as trying to open a file that does not exist in the
location where Pro/E expects it to be. If this happens, Pro/E will
exit. You can keep Pro/E from exiting by setting up a Windows
environment variable: CONTINUE_FROM_OOS TRUE.
8. Playing back trail files successfully (without an
out-of-sequence error) can be very difficult, and sometimess impossible,
if you are running Pro/E linked to a Pro/INTRALINK Workspace. If you
are trying to make trail files for training purposes, you should avoid
using Pro/INTRALINK if at all possible. If you must use Pro/I, the
Workspace state when initiating the trail file must be identical to when
it was recorded. You can attempt to make this happen by undoing frames,
but check-ins are not undo-able, so it can be hard to accomplish this
when data recovery is your objective. I don't know how this works in
the latest versions of Pro/INTRALINK, but if past experience is any
clue, it is just as difficult.



Best Regards,

[ArnoldCollett]

One more thing to add, is if your windows isn't displaying the file
extension, then you won't be able to rename the file and remove the ".#"
extension with explorer. That might be the reason that you are getting
the "versioned file" error. I think that you can rename it from a DOS
prompt. Or try creating a simple batch file to rename it. (ex. "rename
trail.txt.23 training.txt")

Hope this helps,
Arnold

[iturner]

That is pretty complete but I would like to add a tip

rename the trail.txt.44 to something like testtrail.txa (it is then a
training file)
Then when the trail file is loaded it won't crash if it doesn't like a
command and avoids having to set the continue_from_oss variable.

Ian Turner
CAD Manager

Flight Refuelling Ltd

[DamianCastillo]

All of you have some great input on Trail Files, but I will think out of the box and make a suggestion. Don't use Trail files for training. There are great programs out there designed for this purpose. They will record your Pro/E session and allow you to add effects, dialog boxes, highlight items and most importantly, talk them through the process.

Camtasia is one of the best, but you can also use an Open Source one called Camstudio. Just Google it. Try it and see what you think.


"If you are not living life on the Edge, You are taking up too much space"

[ocorten-2]

To enable the display of the file extensions in Windows Explorer do
Tools -> Folder Options -> View -> uncheck Hide extensions for known
filetypes.

(it's one of the first things I do when I logon to a new windows box)

[ptc-752395]

I’m not sure that we all aren’t talking about the human appendix is some way. The PTC help file says you play the trail file in model player, and then I hear that you don’t do that. I guess someone is right in the issue, but it takes a long time to resolve all of the possibilities. Perhaps the trail file thingy isn’t used anymore, and the instructions have been allowed to lapse? This question was originally posted back in February.



I wanted to use the idea, since I lost an entire assembly in Wildfire 2 due to circular references or something. Even though many people tried to help, I never did recover the assembly, and have been worried should it happen again.



I received a couple of emails that explained how to get the suffixes on my trail files. What I have done is to go into Windows and Control Panel/Folder Options/File Types, and then select anything Pro/ENGINEER related. Using the “Advanced” button, I can check the box that says: “Always show extension”, and then I can see the trail.txt.x kind of mention. You really do have to do this before attempting to use a trail file to recover data.



Here are some other things I found out:

If I rename the trial file to “Copy of trail.txt” and delete the version, the icon changes to the one for a text file. The representational Pro/E icon disappears.

If I add the set_trail_single_step option to yes, no matter how I try to save that configuration to make it permanent, I have to either check or re-do that operation to get it to actually do what I want.

If I use Model Player to play the file, it plays rapidly through the steps and then exits Pro/E.

If I use a text editor to change the last few of lines in the “copy of trail.text.a” file from “yes” to “no”, the file plays rapidly and then stops without exiting. These lines are the record of my exiting Pro/E in the last session. Unless I make this change, the program exits. Duh!

If I use the trail_delay and set it to three seconds, the program ties up my 3.6 G computer screen so I really can’t use it for anything else. If I try to x-out the program to stop it, Windows says the program is not responding, even though I can see the model indexing through the commands. With the screen locked up, I can’t stop the model player at all, so were I to wish to stop the commands before my error, I couldn’t do it.

If I go into Windows, find the copy of trail.txt file and use Pro/E to open it, the file plays, but since I can’t find a way to save the config_pro file with the set_trail_single_step set to “yes”, it just plays through with no opportunity to stop the player before the error.

I don’t remember at the moment what I did to get the little screen with the ‘Single Step” command button, but when I did get that possibility, the Pro/E sash screen was extended, and I couldn’t see the model. The monitor screen wouldn’t respond and let me retract it.



Neat, huh?



I really do appreciate the folks like Eric Hill and Robert Pomarico and other people for taking the time to try to solve this. I just have the feeling that this trail file subject has changed from one edition of Pro/E to the next, and it’s being phased out by PTC. Who knows?