managing standards

[AM_9243347]

Hi;

I hope you all are doing fine.

In our company we defined a set of standard for start parts, formats, materials, .dtl, etc ... and as we need to keep updating these files time to time my question is that what is the best practices for managing these file centrally for all users and enforcing all users to these standards.

Sincerely yours.

[kdirth]

I would suggest creating a config.sup file to place in the load point folder (e.g. C:\Program Files\PTC\Creo 7.0.5.0\Common Files\text/) to control the config settings that you want to control.  The config.pro settings cannot be overwritten by personal config.pro files.  This does not force the use of these files and settings, but does make users choose to not use the default to get away from them.

Some configs to consider for the .sup file:

tolerance_standard ansi

drawing_setup_file K:\std_draw.dtl

make_aux_view_notes yes

make_parameters_from_fmt_tables yes

pro_dtl_setup_dir K:\ptc_configs

pro_format_dir wtpub://Windchill/Libraries/Standards/Formats/

pro_symbol_dir wtpub://Windchill/Libraries/Standards/Symbols/

pro_table_dir wtpub://Windchill/Libraries/Standards/Drawing Tables/

symbol_instance_palette_file K:\symbols

todays_date_note_format %Mmm-%dd-%yy

pro_unit_length unit_mm

pro_unit_mass UNIT_KILOGRAM

pro_material_dir K:\Materials

search_path_file $CREO_COMMON_FILES\afx\parts\prolibrary\search.pro

template_designasm wtpub://Windchill/Libraries/Standards/Templates/start_assembly.asm

template_sheetmetalpart wtpub://Windchill/Libraries/Standards/Templates/start_sheetmetal.prt

template_solidpart wtpub://Windchill/Libraries/Standards/Templates/start_part.prt

layout_symbol_dir K:\symbols

pro_plot_config_dir K:\plot_configs

weld_ui_standard ansi

[sacquarone · Accepted solution]

Hello @AM_9243347 

Suggestion of @kdirth is VERY GOOD, as long as number of Creo Parametric users is low-to-medium.

Nevertheless, if number of users is high, above approach, even though always working, is nevertheless challenging due to following constraints in lots of situations:

• Not all users install Creo in the same path (so .... how to ensure that "latest config.sup" is being used and placed at the proper location?)
• Several users are working in different projects, using different versions of Creo parametric (so ... how to ensure that "the good config.sup of the version in use" is the good one for the given version, and up to date, in other words latest?)

With pure Creo Parametric capabilities, those kind of challenges just cannot be handled. This is the reason why the administrators of most of our "big customers" (with lots of end users, working for lot of different projects, sometimes lnked to different windchill instances in different versions):

1. Control exactly where the different versions of Creo Parametric are installed by forcing users to perform Silent Installations (refer to article 81760 for further technical details on this)
2. Are configuring the "startup phase" of Creo Parametric with Windows scripts. Usually, those scripts:
   • Are batch files (*.bat extension)
   • copy config.pro and sup files:
     • from a network location ("read" access for most of users, "write" access ONLY for administrators)
     • to the startup directory (or Creo Parametric Common Files "text" folder)
   • ensure "protkdat" entries point to the "good location" of eventual toolkit being used
   • launch the "parametric.exe" at the end of the script

I'm sorry not being able to provide an "easier way" to achieve this, but above challenges cannot be covered from a technical standpoint without a good control of what happens "behind the scene" in the folders - working/startup directories and creo load points (requiring a setup therefore via an approach to be considered outside from PTC Application).

Regards,

Serge

[BenLoosli]

I use a network install of Creo so all users are using the same set of files. I have the config.sup and config,pro file in the <loadpoint>/text folder for the company settings. I use a launch script (batch file) for the users to start Creo that copies a config.pro file to their home folder every time they launch Creo. They also have a local config.pro file in their start-in directory that they can add custom mapkeys or other settings in. I do this because I have 2 groups of users with different requirements and drawing templates. One group is also still on Windchill 11.0 with Creo4 while the other group is on Windchill 11.1 and Creo 7. It is very easy to upgrade the launch batch file when that group gets upgraded. The launch file also controls which licenses the users are using.

[sacquarone]

Thanks @BenLoosli !!

Indeed, a Creo Parametric installation configured as "software server" may get rid from local installations (and therefore => no need of the Silent Installation approach previously mentioned).

Your approach sounds indeed really very good, and it seems to definitely be an easy way later from a maintenance perspective (especially config.sup), as long as "network bandwith" allows a quick answer to "ping" commands to the network location where Creo Parametric is installed (and therefore used by all end users).

I see just one risk with this approach. If network is down or machine (where Creo is installed) is down, all users cannot work anymore. This risk could be avoided without using this notion of "software server" (if users have local Creo installed, eventually with an access to a triad server for the licensing), but would complicate the maintenance and installation process (my earlier post).

Regards,

Serge

[TomU]

I also run Creo over the network.  I can't imagine doing it any other way.  I can install and configure Creo one time for each new version and simply change one line in the startup script whenever I want our users to start using a different version.  Changing maintenance builds is completely seamless to the end users.  They do need to re-register Windchill when switching between major releases since the caches are kept separate, but there is no need to do anything else on the local computers.  I love this setup!

If the server that runs Creo ever goes down, we have bigger problems...

[AM_9243347]

@sacquarone @TomU @kdirth @BenLoosli 

Thank you all for you replies. I really appreciate it.

Why it is important to copy config.pro file to home folder or startup directory every time? I'm confused, if the launch script is being executed by user then config file copied to whichever directory is modifiable by user also, no?

Also may you please explain more on your startup scripts if possible? As much as I know we should create a .bat file with local working directory pointing to parametric.exe on network drive.

Sincerely yours.

[MartinHanak]

---

@AM_9243347 wrote:

@sacquarone @TomU @kdirth @BenLoosli 

Thank you all for you replies. I really appreciate it.

Why it is important to copy config.pro file to home folder or startup directory every time? I'm confused, if the launch script is being executed by user then config file copied to whichever directory is modifiable by user also, no?

Also may you please explain more on your startup scripts if possible? As much as I know we should create a .bat file with local working directory pointing to parametric.exe on network drive.

Sincerely yours.

---

Hi,

1.] config.pro is copied during Creo start to reflect the changes made by the CAD admin in main config.pro

2.] to disable user to change some config.pro setting CAD admin can apply config.sup file

[TomU]

@AM_9243347,

The approach you take will vary some depending on where Creo is installed.  Since we install Creo to a shared network location, all of the installation files are automatically read only and can't be changed by the end users.  Even with this installation method we still have a config.sup file in the each of the loadpoints (where Creo is installed) to make sure all of our company settings cannot be overridden by the end users (very similar to what @kdirth shows above).

Some companies do not allow the users to have their own local config.pro files.  In these situations the startup scripts are configured to overwrite all of the local config.pro files with the company versions.  I don't agree with this approach since there are lot of things a user can tweak to make their lives easier while still conforming the the company standards, but to each their own.

As far as the startup script, the main thing we're doing is controlling which Creo licenses and options different groups of uses get depending on the command line options passed in by their startup shortcut.  The end result is just setting half a dozen environment variables and then launching Creo.

I'm not sure how useful it will be to you, but I've attached the entire script as a text file for you to look through.  The stuff you will probably care about is near the end.

[AM_9243347]

@TomU 

Thanks so much for sharing your script. It is really helpful.

Thank you all friends @BenLoosli @MartinHanak @sacquarone @kdirth 

Sincerely yours.

[BenLoosli]

There are 3 config.pro files available to Creo when launched.

The system wide file, and config.sup, are in the <loadpoint>/text folder and cannot be changed except by the admin.

The copied file is in the user's home directory. The reason for copying it is that the user may change it (by accident?) so I delete it and copy my master copy over every time Creo starts. This guarantees that they get the settings for their group's needs. I have 2 different groups using Creo and they have different drawing templates as well as Windchill home pages that are set at this config.pro.

The local config.pro is to allow the user to customize settings to their liking and create their own mapkeys if needed. Like Tom said, this should not be locked down as each user may like a little change to suit them and their workflow.

The batch launch script sets the licenses that users will use as well as copying the right config.pro to their home directory.