Where and how is the variable _USTN_WORKSETDGNWS defined?

I am trying to configure ORD CE for ProjectWise.

Our folder structure does not support worksets under workspaces but there a videos on how to configure that. I have been successful in making out projects work as worksets and associating them with a workspace. However, my efforts to enable the sheet index (and whatever else a DGNWS file provides)have failed. I have defined a common location for the Workset CFG files and location where the DGNWS file should be created using _USTN_WORKSETSDGNWSROOT. 

But I cannot figure out how to define  _USTN_WORKSETDGNWS in PW. According to its description, it should be the full path file name of the DGNWS file. But in my PW Managed Workspace, it is being defined to the Workset name only and according to the Configuration Dialog box, it is being set at a System Level, While most of my workset variables at reported to be correctly set to Workset Level.

I discovered that if I list the Configuration Variables using the Show Configuration Variables command of the dialog box and compare its list to the Summary of Variables from an MSDEBUG.TXT file, there are a number of assignments that are missing. Particularly glaring is the _USTN_WORKSETDGNWS assignment. In fact, I have searched every CFG I could find and do not see it listed anywhere.

If it is automatically generated, are there rules and conditions that can effect its assignment? I need to figure out why I cannot get the variable and its operational purpose to function in Project Wise.

Parents
  • Well, this is sort of embarrassing! But it's not 100% my fault!

    First and foremost, it turns out that my inability to get the DGNWS file to work was due to a permissions setting in my target folder location. Once I realized that, I was finally able to get the DGNWS file to get created once a file was opened in the Workset. However, do you think an error message, like "Unable to create DGNWS file. You do not have sufficient permissions to complete that task." might have helped.

    With that out of the way, allow me to rant a little:

    There are a lot of variables in CONNECT that are potentially stupid! I know that sounds harsh, but hear me out.

    There is a variable named _USTN_WORKSETDGNS which is defined as the "Search Path for design files". I don't know how others work, but in a large organization like a DOT, or on large projects, DGN files are spread all over the place in a project folder structure. Usually, by discipline but even within one discipline, many departments keep sheet files separated from drawing or model files. If there is a purpose for this "search path" that would justify defining it to all the possible DGN file locations, it would be nice to know what this actually does. 

    Another variable is _USTN_WORKSETSTANDARDSDIRNAME which is defined as the "Base directory name for Standards of WorkSet. At the time of creating new WorkSet, this name is appended to the WorkSet root directory path". By default, it is defined as "Standards". Additionally, there is a variable _USTN_WORKSETSTANDARDS which appears to be the combination of the previous variable and the WorkSet root directory path, as the previous variable's definition explain. Well, on our project folder setup, I needed to redefine the _USTN_WORKSETSTANDARDSDIRNAME to match our folder names. After making that changes, I thought that _USTN_WORKSETSTANDARDS would naturally adjust to match this new definition. But no, it had no effect. I had to redefine _USTN_WORKSETSTANDARDS to use the WorkSet root directory path plus my definition of _USTN_WORKSETSTANDARDSDIRNAME to get it to work.

    One last observation - this is a ProjectWise observation, but it might apply to a non-PW workspace: When you review a path variable in the configuration dialog box, if the Value displays back-slashes as the path separators, that is an indication that the path defined actually exists. If you see the Value is still using forward-slashes, it means that the folder specified is non-existent. For example, the previously mentioned _USTN_WORKSETDGNS variable displays using forward slashes since my DGN folder names is seldom DGN nor is it located right below the top level folder of the WorkSet.

    I still have no idea how or where the default location for the DGNWS is defined, but in ProjectWise, I finally undefined it in my Predefined CSB's to get the full path definition to stick. However, even though its definition claims it to be a full path variable, it may work when defined as a name only value if the variable _USTN_WORKSETSDGNWSROOT is correctly defined to its folder path. 


    Charles (Chuck) Rheault
    CADD Manager

    MDOT State Highway Administration

    • MicroStation user since IGDS, InRoads user since TDP.
    • AutoCAD, Land Desktop and Civil 3D, off and on since 1996
  • Those are very good points and I agree with all of them.  Working outside PW, the DGNWS file and the functionality that can be associated with it would helpful, especially when using fields in title blocks and all that.

    In the past, I configured our workspaces to a central location distant from the actual project CAD files.  This was done to have all our users resource standards from once central location (DUH!), prevent them from editing said standards and allow our IT folks to easily assign the necessary file access permissions.  Its been a disappointment that even at Release 16, the DGNWS file still can't reside "outside the standard "Configuration" folders.  At to your point, _USTN_WORKSETSDGNWSROOT is a variable that serves no purpose.

    I filed an SR several months ago and it is indeed a defect (as they call it) Defect 1116741and its anticipated to be addressed in Release 17.  16 Releases too late.

  • I've been working on some non-ProjectWise configurations for users over the last few weeks and offer the following suggestions relating to the DGNWS.

    1. Where a configuration and project folder structure is consistent I'm recommending that key folder redirections are made in the WorkSpaceSetup.cfg in the custom configuration.
    2. For clarity of purpose we use the name 'Standards' for the root folders containing DGNLIB and other resource folders.
      For WorkSets this name is set by _USTN_WORKSETSTANDARDSDIRNAME. That's easy to spot, however I've noticed that MicroStation hardcodes the 'Standards' folder name in msconfig.cfg (which I will follow up on). 
      This is easily fixed by first defining _USTN_WORKSETSTANDARDSDIRNAME with a user's folder name, then defining:
      _USTN_WORKSETSTANDARDS = $(_USTN_WORKSETROOT)$(_USTN_WORKSETSTANDARDSDIRNAME)\ to include the redefined folder name.
    3. having done that the DGNWS can then be located in the WorkSet 'Standarsd' folder by defining:
      _USTN_WORKSETDGNWS = $(_USTN_WORKSETSTANDARDS)$(_USTN_WORKSETNAME).DGNWS
    4. _USTN_WORKSETSDGNWSROOT does not need to be defined for this to work so appears redundant. However it could be used if the DGNWS was required to be in a sub-folder of _USTN_WORKSETSTANDARDS, e.g.:
      _USTN_WORKSETSDGNWSROOT = $(_USTN_WORKSETSTANDARDS)/<path>/
      _USTN_WORKSETDGNWS = $(_USTN_WORKSETSDGNWSROOT)$(_USTN_WORKSETNAME).DGNWS

    The complete block I've put in WorkSpaceSettings.cfg is:

    MY_PROJECT_SERVER = <path>/
    _USTN_WORKSETROOT = $(MY_PROJECT_SERVER)$(_USTN_WORKSETNAME)/
    _USTN_WORKSETSTANDARDSDIRNAME = <MyStandardsFolder>
    %lock _USTN_WORKSETSTANDARDSDIRNAME
    _USTN_WORKSETSTANDARDS = $(_USTN_WORKSETROOT)$(_USTN_WORKSETSTANDARDSDIRNAME)\
    %lock _USTN_WORKSETSTANDARDS
    _USTN_WORKSETDGNWS = $(_USTN_WORKSETSTANDARDS)$(_USTN_WORKSETNAME).DGNWS
    %lock _USTN_WORKSETDGNWS

    The variables are locked to ensure that other CFG files do not change them. OpenBuildings Designer for instance, to ensure that the delivered example WorkSets operate as designed, sets _USTN_WORKSETSTANDARDSDIRNAME = Standards.

    In multiple WorkSpace scenarios where perhaps the root folder for the WorkSets vary, some or all of these could be put in the WorkSpace CFG.

    The other interesting thing which may help, obvious in hindsight, is OOTB the configuration results in the folder structure: ....\<WorkSpaceName>\<WorkSetName>\ so WorkSets are always contained within a WorkSpace folder.

    By redirecting _USTN_WORKSETROOT to a path that does not include _USTN_WORKSPACENAME as shown above, the WorkSets can be stored in any required location, while the benefits (if needed) of assigning differing resources by WorkSpace within the configuration are retained, and the grouping of projects in the UI is retained. 

    I'll post some examples over the next month, probably in my blog.

    Hope this helps.

    Marc

    Answer Verified By: caddcop 

  • Thanks for that explanation Marc.

    A follow-up to this, our organization has several different disciplines and utilizes both Bentley and Autodesk apps. We have adopted a standard project folder structure and is standard across all these disciplines. Project folders are created to the production drive by our IT dept. using a script that automates the process (copying folders from a master and assigning permissions).

    The Configuration folder is located on a "workspace drive". The workspace drive supports all our CAD products. We currently have basically 2 main WorkSpaces types, Corporate, Public client (ie PennDOT, WVDOH).  The project folders are the same for both.  Once the folder is created, if the project is using Bentley CAD apps, I create the projects workset files by just copying a master and editing a variable or two in the applicable WorkSpaces/Worksets folder. This process has always worked for in the past.

    So following your recommendation, I edited my WorkSpaceSetup config file to the following

    _USTN_WORKSETROOT = $(Client_Project)$(_USTN_WORKSETNAME)/
    _USTN_WORKSETDGNS = $(_USTN_WORKSETROOT)02 Draw/
    _USTN_WORKSETSTANDARDSDIRNAME = 02 Standards
    %lock _USTN_WORKSETSTANDARDSDIRNAME
    _USTN_WORKSETSTANDARDS = $(_USTN_WORKSETROOT)02 Draw/05 Application/$(_USTN_WORKSETSTANDARDSDIRNAME)/
    %lock _USTN_WORKSETSTANDARDS
    _USTN_WORKSETSDGNWSROOT = $(_USTN_WORKSETSTANDARDS)
    _USTN_WORKSETDGNWS = $(_USTN_WORKSETSDGNWSROOT)$(_USTN_WORKSETNAME).DGNWS
    %lock _USTN_WORKSETDGNWS


    In my configuration testing sandbox, I created a NEW project workset in my corporate WorkSpaces/Worksets/ folder following my existing workflow.

    Using MicroStation Connect, I selected the corporate WorkSpace and the NEW Workset..BANG, a NEW DGNWS file got create to the _USTN_WORKSETSDGNWSROOT location from the standard DGNWS template file that had all of my custom fields. Perfect! I closed MicroStation.

    SO NOW THIS IS THE FRUSTRATING PART!

    I re-launched MicroStation Connect, selected the same WorkSpace and Workset. The custom fields are no longer shown. I confirmed the DGNWS file IS in the desired location.

    I created a new file to the "New" project. I the created another file in the same project and folder. I closed MicroStation.

    I relaunched MicroStation, the Corp WorkSpace and NEW Workset stuck and the two NEW files I created were listed as associated with the Workset.

    I added a couple of custom fields, opened a file then exited MicroStation, I relaunched MicroStation and the custom fields are gone.

    So, it "Appears" that I was able to redirect the DGNWS file to another location, BUT it also appears that MicroStation really doesn't recognize it after the original creation of it. I've deleted and re-created the DGNWS several times with the same results.

    BUT... if I copy the DGNWS file to the Workset folder, all the fields are present and works "as it should".

  • so you move the DGNWS file from the workset standards folder, to the actual workset root folder and then it works ?

    I am having similar issues when trying to separate my engineering/working data from the configuration. 

    The other frustrating part on my end is the generic exception logs that get generated - not much help for me.

    I can get the Bentley products to read the new locations and have no issues. My problem comes with the creation process for anything new. For some reason the creation process (for me) doesn't like the data being located outside of the Bentley directory structure.

    but the both of us - as well as others - are not configuring things the exact same way - so it seems that Bentley has issues with us changing these. 

    Timothy Hickman

    CADD Manager | CADD Department

    timothy.hickman@colliersengineering.com

    Main: 877 627 3772| 

    1000 Waterview Drive Suite 201 | Hamilton, New Jersey 08691

  • *sigh*
    Perhaps Bentley should have asked the user base how we normally store project information vs. workspaces?

    MaryB

    Power GeoPak 08.11.09.918
    Power InRoads 08.11.09.918
    OpenRoads Designer 2021 R2

        

  • Tim,  yeah, it works. BUT our worksetsroot folder is located within the WorkSpaces folder (<WorkSpace_Name>/Worksets) and since its on another drive and write locked, users can't write to it and taking away all the cool functionality of the DGNWS.

Reply Children