Community Tip - Did you get an answer that solved your problem? Please mark it as an Accepted Solution so others with the same problem can find the answer easily. X
A couple of things to look at that I have seen in the past:
If either of these are incorrect Creo will not be able to find the path to the correct files.
Checked those items and all were good.
I totally agree... there's ALWAYS something more to learn with both Creo and Windchill 😀
Do you have multiple lines of the same config option in the config.sup file?
I am assuming you copied the config.sup file from machine 1 to machine 2.
Those settings are not normally in a config.sup but in the system config.pro.
Paste the config.sup file so we can look at it.
Yes... copied the config file from machine 1 to machine 2
Also put it in the config.sup file since my entire group uses the same formats and kept people from inadvertently editing them
Config file below since I'm having issues getting the file itself to upload
pro_symbol_dir wtpub://EngWCApp-p-t/Libraries/Library/ProE Standards/Symbols
rem pro_dtl_setup_dir wtpub://EngWCApp-p-t/Libraries/Library/ProE Standards/Setup_Files/drw_setup.dtl
pro_format_dir wtpub://EngWCApp-p-t/Libraries/Library/ProE Standards/Format
pro_table_dir wtpub://EngWCApp-p-t/Libraries/Library/ProE Standards/Tables
drawing_setup_file C:\PTC\Creo 4.0\M040\Common Files\text\new_drw_setup.dtl
pro_font_dir c:\windows\fonts
trail_dir C:\PTC\Creo 4.0\drafting\Trail Files
pro_plot_config_dir C:\PTC\Creo 4.0\drafting\ProPlot Files
pen_table_file C:\PTC\Creo 4.0\drafting\Pen Tables\table2.pnt.2
system_colors_file C:\PTC\Creo 4.0\drafting\System Colors\syscol.scl
sketcher_intent_manager yes
start_model_dir wtpub://EngWCApp-p-t/Libraries/Library/ProE Standards/Setup_Files
template_designasm wtpub://EngWCApp-p-t/Libraries/Library/ProE Standards/Setup_Files/neptune_start_asm.asm
template_solidpart wtpub://EngWCApp-p-t/Libraries/Library/ProE Standards/Setup_Files/neptune_start_part.prt
force_new_file_options_dialog yes
save_texture_with_model yes
Do both computers have the Windchill server defined as EngWCApp-p-t
If one user defined it differently that will prevent Creo from seeing it, check for capitalization, too.
Do you have any of these settings also in a config.pro file? If the Windchill server name is wrong, the config.pro settings may come into play.
One of things PTC told us when we configured Windchill was to put the templates and start parts on disk and not in Windchill. The only file I have pointing to a Windchill library is the pro_format_dir setting.
Good morning Ben.... yes, both servers are defined the same, caps and all. None of the config.sup settings are included in the config.pro file
Are you saying that PTC recommended putting the templates and start parts on the hard drives of each individual and pointing to those paths? I've actually done that if I have a user who is running Creo in stand-alone mode and not connected to our Windchill system, but this guy is connected to Windchill.
Yes, that was their recommendation when we set up Windchill/PDMLink 7.0 16 years ago.
I do keep my drawing formats, drawing templates and start parts in Windchill, but the only Windchill library pointer is to the pro_format_dir.
These are my directory and template settings in the system-wide config.pro:
pro_dtl_setup_dir X:\OR\PTC_Settings\Drw_Setup
pro_format_dir X:\OR\PTC_Settings\Formats
pro_note_dir X:\OR\PTC_Settings\notes
pro_palette_dir X:\OR\PTC_Settings\symbol\palettes
pro_symbol_dir X:\OR\PTC_Settings\symbol
pro_table_dir X:\OR\PTC_Settings\Tables
symbol_instance_palette_file X:\OR\PTC_Settings\symbol\palettes\default_palette.drw
drawing_setup_file X:\OR\PTC_Settings\Drw_Setup\cts-d4.dtl
format_setup_file X:\OR\PTC_Settings\Drw_Setup\cts-d4.dtl
start_model_dir X:\OR\PTC_Settings\Templates
template_solidpart X:\OR\PTC_Settings\Templates\start_part.prt
template_designasm X:\OR\PTC_Settings\Templates\start_asm.asm
template_sheetmetalpart X:\OR\PTC_Settings\Templates\start_smetal.prt
template_drawing X:\OR\PTC_Settings\Templates\cts-d.drw
The X:\OR is a shared network drive.
After the system config.pro is read, I then read in a project specific config.pro that gets copied to the user's home directory every time they start Creo. It contains the following, which override the system settings:
template_drawing X:\OR\PTC_Settings\Templates\trisox-d.drw or cts-d.drw depending on project
restricted_val_definition X:\OR\PTC_Settings\Configs\restricted_param-cts.txt this also is project dependent
web_browser_homepage http://Windchill
pro_format_dir wtpub://PDM-CTS/Libraries/System Config Library/Main/PTC Settings/Formats
@dthornton wrote:
I am using Creo Parametric 4.0 M040
Issue revolves around config.sup paths to formats and start parts. Same config.sup file is used on 2 machine. On machine #1, paths work correctly. On machine # 2 belonging to a new user with new install, paths appear to work for some items (ex. start parts) but not not others (ex. formats) It is the exact same config.sup file. Ideas or suggestions appreciated.
Hi,
I would check new user's access rights intowtpub://EngWCApp-p-t/Libraries/Library/ProE Standards/Format directory. Is he able to browse into this directory and open drawing format manually ?
Good morning Martin... yes, he has permission to that area. Right now, that is his work around, browse to this directory and open drawing format manually
Did you ever get this resolved? I'm experiencing this exact behavior now, and have conducted the same troubleshooting steps. The only variable factor I've found is that some users have the default cache location (C;|PTC\wfroot\), and some have it in APPDATA. But the issue is still not consistent to either setup.
Try going to File / Help / System Information.
Near the bottom is a section on Configuration files read. Is the config.sup listed?.
Yep. The launch script I wrote copies the standard configs (.sup, .pro) into the application folders (C:\Program Files\....\Common Files\Text, and then launches Creo reading the configs in proper order, no conflicting .pro files in the path.
There should only be 1 master config.sup file, usually in the <Loadpoint>\text folder. Any setting in the config.sup file cannot be overwritten by a config.pro setting (or another config.sup).
By sure the launch icon uses a consistent Start In folder location, we use c:\PTC_User\%username%. The users can make cahnges to this file, but be careful as it can become bloated when they save a mapkey as that process writes ALL config options to that config.pro.
I have the master config.pro and config.sup in the <loadpoint>\text folder.
I have a group config.pro that gets copied to the user's home directory, c:\users\%username%, from a file I maintain at start up. If they make a change to this file by mistake, it gets replaced by my master copy the next time they start Creo.
The third config.pro loaded is the one in their start in folder,
That's essentially the same setup I have. Users can have a config.pro with limited options to change that are not locked by the config.sup. There are no conflicting config files. The issue is with pro_format_dir pointing to a wtpub:// folder and having it work inconsistently for a handful of users. Registered server info is identical for all. I saw that this was a solution in another post, but it persists for us. The location works for start parts, but not for formats.
I'm doing the exact same thing:
pro_format_dir wtpub://Windchill/Libraries/CAD Standards/TM Formats
No issues at all as long as the users have the Windchill server named *EXACTLY* the same way. It is case sensitive.
Is there anything in the trail file or the std.out file that might explain why it's not working?
The std.out is regurgitating "Error: CommGenPoll WaitForMultipleObjects failed! GetLastError: 6", but I'm not sure if that being triggered by the Open dialog spawn. I'll have to test that further.
The only difference in the trail files is where the Open dialog that spawns when Browse is hit.
Good:
Server names are identical, but ours is formatted as wtpub://X-Y Company Name/Libraries..../Formats. I've checked for hidden spaces and proper case.
Does the launch script have the correct permissions to copy the files on the machines this isn't working?
Have you checked the "current session" on the users machines that are having the issue to confirm that the settings are correct and don't have the red prohibited symbol next to them?
Yep, I have confirmed that changes to the source configs are propagated via the script to the users target folders at launch.
Okay, I think I have this resolved. Rubber mallet works every time. I've reset all server info from scratch, and that seems to have done the trick. There had to have been some misspelling or syntax anomaly that I just couldn't see.
Thanks all for the help!