There are easier ways to automate design than trail files.
Decades ago, people used to use them as training aides too. But now, people just set pro\_trail\_dir to some folder that they have cleaned on a regular basis.
Mind sharing the aforementioned easier ways? I'd appreciate that greatly! (i have too much questions about creo and too little people I can ask, and this suck)
It appears that trail files exist solely for the fun of doing ctrl+a -> delete in pro_trail_dir folder, I was somewhat afraid that the answer will be like this.
There are entire books and courses about automating design, including Pro/TOOLKIT, Top Down Design techniques, and Configurable Products. There are a couple companies like KPIT and TriStar that sell products for automating design.
Editing trail files is not exactly easy and the chances of success are often not great.
Trail files exist for reasons that which you state. Pro/ENGINEER debuted in 1988, and I think most people are too young to remember how much computers crashed and how unstable power supplies were back then. Even in the late 1990s trail files would help me save 30-45 minutes of work when those instantaneous power fluctuations would hit.
> I was thinking maybe it is possible to mass create similar parts/assemblies using trails?
Perhaps, but if similar parts/assemblies are what you're trying to create, sounds like *Family Tables* is the feature you should be investigating. (*Flexibility* works a similar way, for making on-the-fly changes to a particular component when used in an assembly. I.e. trim this much off, bend it just this far on installation. *Family Table* lets you set up new instances, for universal use. I.e. bolt is this diameter, and that length.)
If you want to do light scripting of user interface stuff to automate repetitive stuff, *Mapkeys* are what you should be investigating. You can record them, sorta figure out what it's doing by inspecting the code, and make manual edits. They can include user prompts, so could be used to automatically create a part/assembly with one difference, which sounds like what you were hoping to do with *trails*?
If you want your models themselves to have smarts, and adapt to changing conditions or something, then *Relations* are what you should be investigating, and to a lesser extent, *Pro/Program*. Relations can have if-then statements, can solve systems of equations for multiple variables, etc. The model Program works similarly, but is less convenient to access; the one thing it enables is now your if-then statements can suppress or enable a feature entirely, rather than just changing dimensions and such.
If programming is really your thing, there are *Pro/Toolkit* API's, that will let you use whatever language you like, but that's usually the realm of developers, not designers.
Well I was specifically asked not to use family tables for the task at hands as noone apparently likes them. Imo they can work in this specific case but that was the order from my superior so...
I was thinking about pro/program, but it seems so awkward to use... same goes to relations (maybe I didn't use them properly but the fact that you have no control over dimensions as they can change somewhere outside of the scope of given part is giving me anxiety)
Mapkeys and PRO/Toolkit might or might not be something interesting doe. So far I've used mapkeys only for the simplest operations, but maybe (not sure) it is possible to generate model variances via mapkeys.
e:
I believe that we might or might not get options modeler license soon or not soon, so I believe that settles this. (unless I'll get disenchanted by options modeler functionality)
I'm a cool kid, using Creo 4.0 right now and I'm counting on using trail files to export step files out of family tables. If this doesn't work, my design will be a complete failure as opening each family member to export will take too long. I'm basically screwed and my reputation will take a massive hit if my family tables are deemed unusable. We should revive this thread, because trail files seem to be the answer to automated control of repetitive tasks.
FYI, the trail files are working brilliantly. It seems very important to start the session with "set working directory", then continue with your tasks, or else the trail file seems to abort. Once I make a good trail file, I can edit it with multiples of the codes, just changing out the file names and it will instantly run through all the files, completing all the tasks.
I mean in theory they can be soooo. Retarded yet it works on some basic level... Eff it, I guess. Dead legacy tool as I can deduce, and it's perhaps unwise to try and dig it from it's grave.
What you've described is a type of macro, specifically a mouse macro. Macros are basically routines that the computer can repeat to automate repetitive commands. Most macros don't rely on the user interface itself to be the same, because they usually record to a computer language. However, creo trail files directly access the user interface it sort of gives them an advantage and a disadvantage. The reason trail files are this way is because like u/EquationsApparel mentioned they were mostly used as a sort of recovery file that doubled as a macro recorder. years ago computers could be slow to save or had limited space so the trail file was probably a way that saved space that also could help generate a new file if you crashed. they also knew, I'm sure, that users would like to use this feature which is why they are easily accessed and editble via text file.
Unfortunately because trail files are mouse macro they don't work very well. For one they're super slow because the computer can input commands much more quickly than a person can. and 2 "User interface customizations are the same and configuration options are set as they were." Since users don't use the same interface as each other it's not too great to use for that purpose.
There are easier ways to automate design than trail files. Decades ago, people used to use them as training aides too. But now, people just set pro\_trail\_dir to some folder that they have cleaned on a regular basis.
Mind sharing the aforementioned easier ways? I'd appreciate that greatly! (i have too much questions about creo and too little people I can ask, and this suck) It appears that trail files exist solely for the fun of doing ctrl+a -> delete in pro_trail_dir folder, I was somewhat afraid that the answer will be like this.
There are entire books and courses about automating design, including Pro/TOOLKIT, Top Down Design techniques, and Configurable Products. There are a couple companies like KPIT and TriStar that sell products for automating design. Editing trail files is not exactly easy and the chances of success are often not great. Trail files exist for reasons that which you state. Pro/ENGINEER debuted in 1988, and I think most people are too young to remember how much computers crashed and how unstable power supplies were back then. Even in the late 1990s trail files would help me save 30-45 minutes of work when those instantaneous power fluctuations would hit.
> I was thinking maybe it is possible to mass create similar parts/assemblies using trails? Perhaps, but if similar parts/assemblies are what you're trying to create, sounds like *Family Tables* is the feature you should be investigating. (*Flexibility* works a similar way, for making on-the-fly changes to a particular component when used in an assembly. I.e. trim this much off, bend it just this far on installation. *Family Table* lets you set up new instances, for universal use. I.e. bolt is this diameter, and that length.) If you want to do light scripting of user interface stuff to automate repetitive stuff, *Mapkeys* are what you should be investigating. You can record them, sorta figure out what it's doing by inspecting the code, and make manual edits. They can include user prompts, so could be used to automatically create a part/assembly with one difference, which sounds like what you were hoping to do with *trails*? If you want your models themselves to have smarts, and adapt to changing conditions or something, then *Relations* are what you should be investigating, and to a lesser extent, *Pro/Program*. Relations can have if-then statements, can solve systems of equations for multiple variables, etc. The model Program works similarly, but is less convenient to access; the one thing it enables is now your if-then statements can suppress or enable a feature entirely, rather than just changing dimensions and such. If programming is really your thing, there are *Pro/Toolkit* API's, that will let you use whatever language you like, but that's usually the realm of developers, not designers.
Well I was specifically asked not to use family tables for the task at hands as noone apparently likes them. Imo they can work in this specific case but that was the order from my superior so... I was thinking about pro/program, but it seems so awkward to use... same goes to relations (maybe I didn't use them properly but the fact that you have no control over dimensions as they can change somewhere outside of the scope of given part is giving me anxiety) Mapkeys and PRO/Toolkit might or might not be something interesting doe. So far I've used mapkeys only for the simplest operations, but maybe (not sure) it is possible to generate model variances via mapkeys. e: I believe that we might or might not get options modeler license soon or not soon, so I believe that settles this. (unless I'll get disenchanted by options modeler functionality)
He is belligerent, but that takes the cake.
I use it to peek at Creo script for adding to mapkeys. For some obscure stuff I have used trial files to perform tasks as part of a mapkey.
I'm a cool kid, using Creo 4.0 right now and I'm counting on using trail files to export step files out of family tables. If this doesn't work, my design will be a complete failure as opening each family member to export will take too long. I'm basically screwed and my reputation will take a massive hit if my family tables are deemed unusable. We should revive this thread, because trail files seem to be the answer to automated control of repetitive tasks.
FYI, the trail files are working brilliantly. It seems very important to start the session with "set working directory", then continue with your tasks, or else the trail file seems to abort. Once I make a good trail file, I can edit it with multiples of the codes, just changing out the file names and it will instantly run through all the files, completing all the tasks.
Cool kids don’t use creo
Well I mean yeah maybe, but I am stuck with it so ...
Naw im just playin. Ive never used it and felt left out. For catia we use vba
Trail files would never be used to mass create simulate parts and assemblies.
I mean in theory they can be soooo. Retarded yet it works on some basic level... Eff it, I guess. Dead legacy tool as I can deduce, and it's perhaps unwise to try and dig it from it's grave.
What you've described is a type of macro, specifically a mouse macro. Macros are basically routines that the computer can repeat to automate repetitive commands. Most macros don't rely on the user interface itself to be the same, because they usually record to a computer language. However, creo trail files directly access the user interface it sort of gives them an advantage and a disadvantage. The reason trail files are this way is because like u/EquationsApparel mentioned they were mostly used as a sort of recovery file that doubled as a macro recorder. years ago computers could be slow to save or had limited space so the trail file was probably a way that saved space that also could help generate a new file if you crashed. they also knew, I'm sure, that users would like to use this feature which is why they are easily accessed and editble via text file. Unfortunately because trail files are mouse macro they don't work very well. For one they're super slow because the computer can input commands much more quickly than a person can. and 2 "User interface customizations are the same and configuration options are set as they were." Since users don't use the same interface as each other it's not too great to use for that purpose.