Creo 1.0 Default Install Path

[dgschaefer]

Anyone have trouble with the default path that Creo uses for
installation that includes the build code?







It seems that would cause potential headaches when doing build updates.
Do updates get installed alongside the old builds? Will I have icons
still pointing to the old install?



I realize that M010 is only been out for a few weeks, but I figure
someone must have been down this road by now.



Doug Schaefer

[ChrisCollinson]

We always change the install path and have done with the install to creo
1.0 parametric


Best Regards

Chris Collinson
CAD Administrator

[dgschaefer]

We always use the default path just to keep things simple.



I'm curious if setting your own path eliminates the build code folder.
The build number is a sub folder of the 'Creo 1.0' folder, actually 2
levels down within the 'Common Files' folder. I would assume that even
if you choose your own folder, the 'Common Files' folder would still
contain a folder with the build number. Is that true?



Doug Schaefer

[dgallup]

I never use the default path but I always install each update in parallel with the build code in the path. That way I can run as many different builds as I care to install. Currently we have 5 builds of WF 2, 3 & 4. I like to stay away from the bleeding edge.

PTC quality philosophy: We've upped our quality standards. Up yours.

[BryanBruder]

I just installed Creo 1.0 F00 and then installed Creo1.0 F010. The install asked me if I wanted to delete the old C:\Program Files\PTC\Creo 1.0\Common Files\F000folder or not. I chose to delete the C:\Program Files\PTC\Creo 1.0\Common Files\F000 folder and the install created a new folder C:\Program Files\PTC\Creo 1.0\Common Files\M010.

Bryan

[DamianCastillo]

I am with David on this. I always choose a simpler install path and add the _build to the install folder. This allows me to go back to an old build quickly if the new build had a bug that was going to hurt us.

I also install only once on the network so I can install new builds while everyone is still running the current build. Next time they close and relaunch Creo, they are running the latest build and have no clue. I like it this way.

In Reply to David Gallup:

I never use the default path but I always install each update in parallel with the build code in the path. That way I can run as many different builds as I care to install. Currently we have 5 builds of WF 2, 3 & 4. I like to stay away from the bleeding edge.

PTC quality philosophy: We've upped our quality standards. Up yours.

"Too many people walk around like Clark Kent, because they don't realize they can Fly like Superman"

[dgschaefer]

That's good info, at least it prompts you to delete the old install.



The problem for us, and I think many folks, is that we use a script to
copy config files into the text folder install directory. With every
upgrade, we'll need to change our script. If some users get the new
version and some do not, the script won't work properly.



However, looking at the config file that ships with Creo 1.0, it uses
the variable '$PRO_DIRECTORY' to point to the install folder like this:



drawing_setup_file $PRO_DIRECTORY\text\prodetail.dtl



I'd like to make use of that in my script, but I can't figure out where
it is defined. Unfortunately, it looks like it's defined during Pro/E
launch which would be too late. Entering 'set PRO_DIRECTORY' at a
command prompt gets 'Environment variable PRO_DIRECTORY not defined'.



Anyone know when this gets set?



Doug Schaefer

[mkelley]

Open a system window from withing Pro/E; type set, and presto you will have a listing of all variables currently set...! Based upon my experience, the PRO_DIRECTORY variable is not available; however there is usually something similar that will get you there. Simply refer to the desired varible via $<name> in your ProE config files, or %<name>% in your scripts. Good Luck!

[dgschaefer]

I checked that. There is no system variable that points to any PTC
product directory.



Doug Schaefer

[DonSenchuk]

I got the impression that $PRO_DIRECTORY is simply a placeholder for you to fill in with the directory path specific to your facility.

[mkelley]

That doesn't sound right to me - I've always seen a number of variables that are set by PTC; in my particular case now "PRO_DIRECTORY" is avialable.

Make sure that you try the "set" command from a *Pro/E* command prompt. To do this, you must choose: "Window / Open System Window" from within a live Pro/E session...

All of the variables displayed in this manner may be invoked from within a Pro/E session; via $<name> in the config files, or by %<name>% in a batch script triggered by Pro/E.

[dgschaefer]

That makes sense, but is of no help for copying company config files
from the server into the install/text folder before Pro/E is launched
and therefore before the PRO_DIRECTORY variable is set. We do that now
to maintain consistency through our installations as a lot of companies
do, but with Creo 1.0 the path to the text folder changes with every
build update. So, if you aren't diligent about making sure every user is
on the same build, copying the config files to the client machines gets
harder.



Having that variable set beforehand would be nice, but would create its
own set of problems for us in that we have 2-3 versions (WF3, WF4, etc.)
installed at the same time. Frankly, I'm not certain what value there is
in having the build in the install path and would just as soon take it
out.



Doug Schaefer

[davehaigh]

Those variables are in the parametric1.psf file. I can't imagine that the %CREO_COMMON_FILES% location would change between the different numbered .psf files in the bin directory. That's assuming you use multiple .psf files.

You might be able to grab it with findstr in a windows bat script.
Findstr "string to find" [file to look in]
You just need to figure out the correct argument to grab. Although it might be easier to use Perl to grab the value.

I agree, it's not the most admin friendly way to have configured Creo.

David Haigh

[dgschaefer]

Here's some batch code that I think will work. I need to test it more
and I'm not certain it's the most elegant way to do it, but it should be
able to capture the current build code of the local install
automatically.



First, I use the following to find the newest *.psf file (run it in the
parametric/bin folder):



for /f "delims=" %%A in ('dir /od /a-d /b *.psf') do set FILENAME=%%A



I think it's very unlikely that there would be an old *.psf file in
there pointing to an old build, but by checking for the newest file I
can be more sure that I'm getting the actual latest build installed.



Then, I parse that *.psf file for the SHIPCODE:



for /f "tokens=2 delims==" %%B in ('findstr "SHIPCODE" %FILENAME%') do
set BUILD=%%B



I can then use that BUILD variable in my paths for copying my config
files and be sure I'm copying into the right place based on the build
currently installed.



I'm not the best batch file programmer, I patched this together from
Google searches. If anyone has improvements on this, let me know.



Doug Schaefer

[davehaigh]

The reason to have multiple .psf files in the parametric/bin folder is to allow the user to choose between licenses with different startup options. Since these are configured with ptcsetup by the admin, I think you would be safe to just pick the first one, parametric1.psf. The only way you would have an old out of date one is if you re-ran ptcsetup and created fewer license configurations. Even in that case parametric1.psf would still contain the latest information.

I have 11 .psf files.
Having multiple .psf files presents the user with this dialog when they start ProE.
[cid:image003.jpg@01CC9D60.CB37BA30]

This allows me to offer licenses for which I only have one or two copies to any user.

David Haigh

[dgschaefer]

We have two *.psf files and neither are named parametric1.psf. What I
want to avoid is the, admittedly very remote, chance that a build update
happens, new names are given to the *.psf files and the old ones do not
get removed. It would then be theoretically possible to have the last
*.psf file alphabetically (which is what the second line would fine if
you had it scan each one in turn) point to the wrong build.



Admittedly, if one copied a *.psf file into the folder manually it still
may have a newer date stamp, so even this isn't fool proof.



I'm open to suggestions as to making this more automated.



Doug Schaefer

[dgschaefer]

OK, at the risk of beating a dead horse, I think this batch code is a
more direct means of determining the build and poses less risk of
finding the wrong build. It should be run from the 'Common Files'
folder of your Pro/E install. It will find the folder name of the latest
build:



for /f "delims=" %%A in ('dir /a:d /b') do set BUILD=%%A



Even if multiple builds are present, this will find the latest because
conveniently, build numbers end up in alphabetic order (C000 -> F000 ->
M010 -> M020 -> etc.) The assumption there is that you want to run the
latest build present, which seems like a safe bet.



Doug Schaefer

[mkelley]

Gotcha - *now* I understand what you are trying to accomplish...

Another way to go about this would be to figure out what build(s) are loaded (by parsing the file named "instlog.txt", which located in the <loadpoint>\uninstall folder) I have a script that I wrote a few years ago that does this that I could share if you want...

Just thining out-loud here - you could step thru all top-level folders in your PTC installation folder; find all the <loadpoint>\uninstall\instlog.txt files & compile a list of builds. Then I guess that you would have to figure out which one is the latest build - yikes!

I think that it would be best to get rid of the "build-code-in-the-path" thing. What is the value-added here? :^)

[DamianCastillo]

I quickly update all my scripts by using the Find and Replace function. This changes the path everywhere on my script and it takes only seconds to do.

"Too many people walk around like Clark Kent, because they don't realize they can Fly like Superman"