CAD Worked Creo ignoring Environment Var PTC_CREO_ALT_SETTINGS_PATH to fetch configs

[Supp]

Hello guys, I'm setting up a new cad worker (creo parametric) to publish representations

I've noticed that when Creo is called in background to publish something (eg pdf/dwg) it's ignoring my Env Var PTC_CREO_ALT_SETTINGS_PATH that points to our config.pro / config.sup on a network folder

Instead it's usign the default ones in C:\Program Files\PTC\Creo 11.0.5.0\Common Files\text

I know that I can just replace the ones in  c:\program files\ptc\... as a workaround, but I'm wondering if there's a way to make it use the path in the Env Var

Tried both the env var at system and user level, and also manually adding it in the launch script bats  (parametric.bat, that is called by the adapter, and proeworker.bat) but seems it keeps using the default ones.

I know I've already faced this issue last time and used the workaround, figured this time i'd ask if anyone had a solution

random infos:

creo view adapter 12.0.0.0

creo parametric 11.0.5

windchill 12.1.2.10 

Thanks

[avillanueva]

You need to make sure the user running the service to do publishing can see that network folder. That has bit me before. If running as a local system account, they will not have access to network folders.  I had to copy config.pro locally. Eliminate that as being an issue. 

[Supp]

Yes thanks, but I've already checked that the user running has access to the network folder, must be something else

[joe_morton]

Per the help article here: https://support.ptc.com/help/creo/creo_pma/r12/usascii//index.html#page/fundamentals/fundamentals/About_Configuration_Files.html

it looks like Creo reads config files in the Startup directory AFTER it reads the config files in PTC_CREO_ALT_SETTINGS_PATH, so the config files here will override the config files from your network drive.

As a test, try deleting the config files in the startup directory and see if that works.

[Supp]

Hello Joe and thanks

https://www.ptc.com/en/support/article/CS384810

here the doc states:

• If the user has config.pro files present in user's %HOME%, and Creo #.#.#.#\Common Files\text directories, these files will still be read by Creo, however,  the values defined in the config files set through PTC_CREO_ALT_SETTINGS_PATH will take the precedence.

And this is what happens when I launch creo manually as a user on the Cad Worker Machine

What I'm saying is that when CREO is called by the CAD Worker Adapter this is NOT happening.

I have config files only in 

C:\Program Files\PTC\Creo 11.0.5.0\Common Files\text

and 

with env var PTC_CREO_ALT_SETTINGS_PATH on \\server\creo\configs_2025

it's ignoring the PTC_CREO_ALT_SETTINGS_PATH completely only when it's called by the cad worker adapter.

even if i delete the files in C:\Program Files\PTC\Creo 11.0.5.0\Common Files\text

[mmeadows-3]

I haven't used the alt settings path in CAD Workers (yet) and not sure why system environment variables are being ignored.  As a toolkit app, it could be publishing overrides OOTB behavior and just doesn't recognize PTC_CREO_ALT_SETTINGS_PATH from the environment or calling batch files.

In a CAD Worker, proeworker.bat initiates the Creo session by calling the *.bat that calls the *.psf file.  Maybe with a CAD Worker it needs to be set in the *.psf file?  I have passed environment variables to CAD Worker sessions before by setting them in the *.psf files.

Debugging...  Try launching an interactive publish session via proepublish.bat and check if PTC_CREO_ALT_SETTINGS_PATH shows up in the Creo session's environment variables.

If Creo's session shows the variable as set and it still isn't working, then I would log a call with PTC for clarification.  It might be a bug or that publishing simply doesn't support the option.

[Supp]

I've tried publishing from proepublish.bat and it is ok, the env var path is used and the proper config is used

(In our config we have date format changed to dd/mm/yyyy, so when we publish some drw, it's easy to spot  the date in that format vs the default one that seem like a timestamp)

When the publishing is done from the background service, I can also see via process explorer that processes under workerdaemon all sees the correct env var, but the outcome is with the wrong dateformat.

Tried with env var already set as system,  adding it in different bat (proeworker.bat first, then parametric.bat) and finally via the .PSF as you suggested.

I guess it's a bug, I'll file it when I've some spare time to play with ptc's support

Thanks for now