: David Janes wrote:
: > Almost sort of a translation tool or the typical unix workaround.
: <snip> better than *no* workaround sometimes, yes ?
I think the point is that while it might suffice in an extreme emergency,
techniques like this have been around for years. They have not grown in
because, for day to day use, they are just too cumbersome, time consuming and
unreliable (which accounts for some of the time consumption).
What we need is not some junky translators that say they save in another
software's native format ~ SW saying it saves to a Pro/e part file comes to mind
because it comes across as another single feature import like IGES ~ but a
based, parametric neutral file format. STEP has been saying for years that they
are working on such a thing. Anyone heard anything, know how far they've gotten?
: I haven't managed to get the go-back trail file thingy
: working yet tho (another obvious approach)... got any
: tips on that method ?
There may be CAD data translation services that have figured this out. Couldn't
say for certain that it's impossible. But, just to begin with, PTC isn't making
easy. Just to begin with, you have the header problem where a trail file is
identified by the rev that created it. IIRC, this is used to prevent the go-back
use on other, earlier revs. But, let's say this can be _easily_ defeated; no
spending half a day just tweaking the header or this method's viability just
dropped to null. Then there are the other charming features of the trail file to
contend with: a) It is the literal record of everything that was done in a whole
session of Pro/e on a particular workstation. So if you worked on half a dozen
models, assemblies and drawings, you are again editing to find and isolate the
file you need to reconstruct. Hopefully, you didn't interrupt your work on a
to work on something else because, now, you are piecing together sections of the
trail file to make a start to finish coherent modelling session. AAACK! b) The
difficulties with literal operation of the trail file carry over into such things
parameters, directory structure, menu structure. You could possibly get around
difficulties with parameters and directory stucture by doing it yourself. So if
you want to send a 2001 file to a vendor that has only that rev., you have both
Wildfire and 2001 installed and run your WF trail file on 2001; identical start
parts in a parallel directory structure; identical configuration files, just to
on the safe side. It just might work! But wait, what does the literal trail file
do when your modelling session went to Tools>Parameters to set a parameter or
Tools>Relations to create a relation but, in the earlier rev, it was
Utilities>Parameters or when any other part of the menu structure or interface
changed: how will this effect trail file execution? You know, of course, that its
simple error handling is a typical Pro/e exit, session cancelled, reconstucted
file lost. Does this seem like something you'd like to try under time pressure,
a real emergency!?! Could you just send a trail file to your model making vendor
and say, with some assurance of easy success, "just run the trail file, that'll
give you the part in your version of Pro/e" or do you think you might have to
them a 12 page booklet on how to edit, run and debug a trail file for them to
even a glimmer of a hint of a chance of succeeding. If so, sounds like a great
formula for losing vendors. I guess I'm just lazy because I'm sure I'd be sending
files to CAD data translation specialists before I ever seriously thought of
this trail file thing.