Part three of a continuing series of articles on how to customize workspaces to increase productivity

Clearwater, Florida, USA —This is the third in a series of articles on workspaces and what they can do to solve many of your headaches. A workspace is a MicroStation environment or configuration. Customizing your workspace on a per-project basis goes a long way in helping users comply with standards and increase production speed. It also helps reduce potential errors caused by using incorrect resources (such as fonts, text styles, line styles, macros, seed files and dimension styles) and saves on mouse clicks. While we recommend that you read the previous articles, I’ll provide a lot of information in this article that you will be able to use whether you’ve read the previous articles or not. However, if you find yourself getting stuck or having some difficulty understanding something in this article, I recommend that you read the first two parts of this series, as those articles contain definitions for many of the terms used in this article. [Editor's note: See Part 1, "MicroStations little known secret saves massive amounts of time and money" and Part 2, "Optimizing MicroStation workspaces for faster production" for previous articles on workspaces. You can also find all articles on workspaces by clicking here.]

You can reduce potential errors caused by using the wrong resources such as fonts, line styles and seed files by correctly configuring workspace variables.

Making projects easier
Anyone working on more than one project will benefit from optimizing workspaces (and that’s an understatement). If there’s more than one person working on the same project, the benefits will be compounded. Improved productivity and quality are two benefits of a well-designed workspace. Getting you home on time is another.

When you use the MicroStation Manager dialog box to open a design file, how your design environment looks and behaves is determined by hundreds of settings inside MicroStation. A major portion of these settings are determined by something called “configuration variables”. Just like the name sounds, these are variables (things you can give different values to in order to cause different things to happen) that configure (set up) MicroStation for you. These configuration variables control many things. For example, they can control what resources can be made available for you as you design. By “resources” we mean things such as font libraries, text styles, line styles, macros, cell libraries, seed files and dimension styles, to name a few. [Editor's note: It's actually amazing just how much easier life can be if you know how to get MicroStation to do a lot of the work for you. That's what this article is all about.]

Configuration variables reside in configuration files. When MicroStation starts up, it processes configuration files in a hierarchy referred to as “configuration levels”. These levels are processed in a predefined sequence starting with the system level, then going to the application level, the site level, the user level and the project level. One type of configuration file is the “project configuration file”. The project configuration file is the last of the configuration files to be processed and includes configuration variables that are used to load the right resources for the specific project. Unfortunately, many users never take advantage of the power of the project configuration file. Setting each project’s standards once in a project configuration file and using that file over and over saves hours (possibly hundreds or even thousands of hours) in making corrections to design files (due to some wrong resources being used) and in browsing around the network searching for project resources.

Setting up a standard folder structure for all projects helps users know where to find the resources they need and helps prevent CAD anarchy.

Before I go into how to set some of the variables in your project configuration files, I want to mention something on a related topic. One of the main problems that I’ve encountered when working with a project’s design files is that companies don’t always use the same folder structure for each of their projects. This leads to inconsistent locations for project resources which results in users having difficulty finding the needed resources. Also employees that are trained on one project will then have difficulty locating resources when working on another project due to inconsistent folder structure. This is easily handled by simply deciding on a folder structure that all projects will have. Some projects will have a few unique features, but that just keeps life interesting. When you develop a standard folder structure, be sure to keep all project data together.

I remember restoring a 12-year-old project from tape. We had all the design files, but no pen tables, cell libraries, color tables or fonts. They all had to be recreated or gathered up from other sources. Now I keep all project resources together with the project deliverables. You can use sub-folders to help keep things organized. That way, when you archive a project, you know that you won’t have to waste time recreating or searching for project resources some time in the future.

Also, users depend on the standards folder having the correct resources. If unauthorized changes get made to these files, users will have a tendency to make unauthorized copies to ensure that they have the “right” files. The best way to set this up is to keep your company CAD standards in their own separate folder and make the files “read-only” to everyone that has no reason to modify them (which will be mostly everyone except the CAD manager). This prevents CAD anarchy (not a pretty sight).

Configuring project variables
As mentioned above, the project configuration file contains configuration variables that are used to load the right resources for the specific project. Before we start changing the project configuration file, you first need to know a bit about how configuration variables are set up in a configuration file. MicroStation uses these configuration variables to determine information such as where your project resources are located. For example, if the font you need to use for a particular project is stored on a network drive, you will want MicroStation to know the name of that network drive, so it can make that font resource available.

In order to change your project configuration variables, you first need a project configuration file. As a starting point, you can use a file called “untitled.pcf” which gets delivered with MicroStation. By default, this file is stored in the WorkspaceProjects folder. Although you can use this project file as is, many companies develop their own project template or adopt one from one of their larger clients.

Each configuration variable in your project configuration file is listed on a single line. The most common way to configure a variable is to use the following syntax:

<VARIABLENAME> <operator> <new_value> # comment

The first three parts are required and the last, “# comment”, is optional. The first part is a variable name such as “MS_DEF”. [Editor's note: The value set for the variable MS_DEF tells MicroStation the location of the folder to open for design files (it sets the default folder that will be the first one that comes up when the user clicks on File|Open)]. Variable names can only contain alphanumeric characters (A-Z, 0-9) and must be at least two characters long. Although variable names are not case-sensitive, uppercase letters are used by convention. As a note, nearly all variable names used by MicroStation begin with “MS_” or “_USTN_”.

The next part is called an “operator”. An operator is a symbol that represents some function. In most cases, you will be doing one of four things:

1. Assigning a value to a variable using the equal sign (“=”).

For example, let’s say that you wanted to use the file “2dEnglishGeneral.dgn” as the default seed file. The variable name that MicroStation uses for this is “MS_DESIGNSEED”. To assign the file “2dEnglishGeneral.dgn” to this variable, you would use the “=” symbol as below:

MS_DESIGNSEED = 2dEnglishGeneral.dgn

I’ll go over more examples later in this article.

2. Adding a folder or file to the end of a variable definition that defines a path that’s already in the variable (called appending) using the “>” symbol.

For example, let’s say that the configuration variable “MS_CELL” was previously defined as “F:CellMyCells”. However, for the purposes of this project, you also want to have the cell libraries stored in “G:MyCells” available. Although you want the cell libraries stored in “G:MyCells” to be available, the cell libraries stored in “F:CellMyCells” should be searched first. In this case, you don’t want to assign the value “G:MyCells” to the variable “MS_CELL” but instead you simply want to add the value “G:MyCells” to the end of the available paths for MicroStation to search when searching for cell libraries. To do this, you would use the “>” symbol. For example, assuming that “MS_CELL” was previously assigned the value “F:CellMyCells”, then you would append to this by using the following:

MS_CELL > G:/MyCells/

Note that file path names should be entered using a slash mark (“/”). Windows converts all forward slashes (/) in values assigned to variables to backslashes (). Also, all folder definitions should end with a trailing forward slash.

The new definition for “MS_CELL” is now “F:CellMyCells; G:MyCells”. You’ll notice that there are now two paths separated by a semicolon. When you append or prepend a path to an existing variable, MicroStation automatically separates the paths using a semicolon.

This means that MicroStation will first look for cell libraries in the “F:CellMyCells” folder and then look in “G:MyCells”.

3. Adding a folder or file to the beginning of a variable definition that defines a path that’s already in the variable (called prepending) using the “<” symbol.

Sometimes, you want to do the opposite and place a file path at the beginning of the list. To do this, you use the “<”symbol. For this example, let’s say that the configuration variable “MS_CELL” was previously defined as “F:CellMyCells”. However, you want “G:MyCells” to be searched first. To do this, you would use the “<” symbol. For example, assuming that “MS_CELL” was previously assigned the value “F:CellMyCells”, then you would add to this by using the following:

MS_CELL < G:/MyCells/

The new definition for MS_CELL is now:
“G:MyCells; F:CellMyCells”. This means that MicroStation will first look in the “G:MyCells” folder and then look in “F:CellMyCells” when searching for cell libraries.

As a note, if you append or prepend a value to a variable and that variable has not previously been defined, then the variable is now defined as that value. In other words, MicroStation treats the “<” or “>” symbol as an “=” symbol if the variable has not been previously assigned a value. As an example, if the variable MS_CELL had not been previously defined and you used the following in a configuration file:

MS_CELL < G:/MyCells/

The new definition for MS_CELL would be “G:MyCells”.

4. Assigning value to a variable (where that variable doesn’t yet have a definition), using the “:” symbol.

The “:” symbol works just like the “=” symbol except that it will only assign the variable a value if that variable has not yet been defined (in other words, if that variable currently has no value). This is useful when you want to ensure that a variable has a value but you do not want to overwrite an existing value for that variable in cases where a value has been assigned for that variable on a previous level.

For instance, let’s say that you want variable “MS_DESIGNSEED” to be assigned the value “2dEnglishGeneral.dgn” but only if the variable “MS_DESIGNSEED” has not been previously defined. To do this, you would use the “:” symbol as follows:

MS_DESIGNSEED : 2dEnglishGeneral.dgn

As long as the variable “MS_DESIGNSEED” had not been previously defined, then “MS_DESIGNSEED” would now be defined as “2dEnglishGeneral.dgn”. If this variable had been previously defined, then the statement above would simply be ignored (the previous definition would not be changed).

After the operator, the last required item is the value being assigned or added to the variable. Here’s an example showing how to assign the value “C:” to the variable “LOCAL_DRIVE”:

LOCAL_DRIVE = C:

The last item, which is optional, is a comment. Comments are preceded by a “#” symbol. It is good to comment all changes for those who look at the configuration file in the future, even if it is you. MicroStation will ignore anything after a “#” symbol in a configuration line. For example, MicroStation will ignore the string “Local drive for non-networked resources” in the line below:

LOCAL_DRIVE = C: #Local drive for non-networked resources

Getting the most out of variables
Now that you understand how to put together the configuration variable, let’s look at how to efficiently set up some variables by first defining one variable and then using that variable to define another variable. This is useful when assigning a variable like a network drive that may change over time. For instance, let’s say that the network drive that you are using is “O:”. You could simply use “O:” as part of the path for all of your different resources on that network drive. However, if the network drive changes for any reason, you would have to go back through all of your configuration files and change any configuration variables to the new network drive. There’s a better way to do this using “variable references”. What this means is that the value stored in one variable can be used when defining another variable. To do this, first set the “NET_DRIVE” to “O:” (as an example). In subsequent configuration variables, rather than using “O:” as part of the value for a configuration variable, I would simply refer to the variable “NET_DRIVE”. This way, if the network drive ever changes to a different drive, I simply change the “NET_DRIVE” variable in one location and my other configuration variables (that reference the “NET_DRIVE” variable) are automatically assigned the correct information. The above gives us the general rule that you shouldn’t explicitly assign folder paths to a configuration variable unless it’s the first time you’re assigning that path. After that, you should simply refer to the variable that was first assigned the value. Let’s see how this would be done.

Below are the four variable definitions that I use in my site configuration file. Note that these are variable names that I have created. All other variables that I define use variable references to either these variables or to default variables (variables that get defined automatically when MicroStation is installed). The four variable definitions that I use in my site configuration files are as follows:

NET_DRIVE = O: #Drive location for ­network workspaces and projects
LOCAL_DRIVE = C: #Local drive for non-networked resources
PROJECT_DIR = /Projects/ #folder used for project configuration files
WORKSPACE_DIR = /CADStandards/ #folder used for specific CAD standards resources

When MicroStation starts it will assign variables as follows:

_USTN_PROJECTSROOT=$(NET_DRIVE) ­$(PROJECT_DIR) #Location of project files on network
_USTN_WORKSPACEROOT = $(NET_DRIVE) $(WORKSPACE_DIR) #Location of workspace files on network

An obvious question would be “What the heck does ‘$(NET_DRIVE)’ mean?” “$(NET_DRIVE)” means to use the value of the variable “NET_DRIVE”. This is called “variable referencing” which means that a variable is defined by using the value of another variable. The most common way to use variable referencing is by putting parentheses around the variable name precede it by a “$”. For example:

_USTN_PROJECTSROOT = $(NET_DRIVE)$(PROJECT_DIR) #Location of project files on net

If “NET_DRIVE” was “O:” and “PROJECT_DIR” was set to “/Projects/”, then “_USTN_PROJECTSROOT” would now be set to “O:/Projects/”. If I ever need to change that to a different drive, I simply change the “NET_DRIVE” variable (in the site configuration file) and my user and project configuration variables are automatically assigned the correct information. Remember to use forward slashes (/) inside the value for the variable. When MicroStation processes this, forward slashes (/) will be converted to backslashes () automatically.

The “_USTN_PROJECTROOT” and the “_USTN_WORKSPACEROOT” variables are the variables designed to define the root project and workspace folders respectively. By setting the variables as above, if someone decides to upgrade the server or tells me that I need to move files from one drive to another, I only have to change the drive letter and folder names in one place. Since my user and project configuration files use a variable name (that was defined at the site level), I don’t have to make any further changes. As long as I’m connected to the network, I always have the most up-to-date company and project resources.

Creating paths
Earlier, I said that you can prepend (using the “<” sign) or append (using the “>”) information. Prepending and appending is different than assigning (using the “=”) a value to a variable. When you assign a value to a variable, that variable is now equal to that value. When you prepend or append information to a variable, you’re adding to the existing value of the variable rather than overwriting an existing value.
For instance, system and site level settings are set to cover standards that should be used when a client has not specified a project standard to use. However, if there are client-specified standards such as your cell libraries that need to be used, then I want to have MicroStation search for that information first, before looking at the settings on the system or site levels. If I were to simply assign a value (such as “O:/Projects/I-75/Cell/”) to the variable “MS_CELL” at the project level, then that would be the only folder path defined for that variable. This may be okay if this held all of the cell libraries that I could possibly want. But what if I also want to have other libraries available as well such as my cell libraries that are defined at the site level but wanted to have MicroStation search my project level folder first? To do this, I can prepend an additional folder to the value stored in the variable “MS_CELL”. By prepending or putting your project folder in front of the MicroStation default folders (which are usually set by MicroStation when it was first loaded or by a CAD manager), your project cell libraries will be searched first by MicroStation. This improves the productivity of your users by reducing the number of mouse-clicks to locate your project cells.

Let me show you how this all fits together. First, we’ll look at some variables that were defined at the system and user levels and then we’ll prepend a cell folder at the project level using these variables. (Note: We will not be modifying a value that was set at the user level with a value set at the project level. You cannot do that. Instead, we will reference the value of a variable that is set at the user level to define a variable at the project level.)
For this example, let’s assume that the two following variable assignments are made at the system level:

_USTN_PROJECT: $(_USTN_PROJECTSROOT)
_USTN_PROJECTDATA: $(_USTN_PROJECT) $(_USTN_PROJECTNAME)/

Additionally, we’ll assume that the following variable was set at the user level:

_USTN_PROJECTNAME = I-75

After processing, “_USTN_PROJECTDATA” is now defined as:

“O:projectsI-75″

Now, at the project level, we can define where the project cell libraries will be found:

MS_CELL < $(_USTN_PROJECTDATA)cell/

Assuming that the value for “MS_CELL” was set at both the system and site level (which it typically is) the value for “MS_CELL” now includes “O:/Projects/I-75/Cell/” as part of it’s definition. So typically, the full definition for this variable (including the prepend you just made) would be:
O:/Projects/I-75/Cell/;C:/Program Files/Bentley/Workspace/Projects/System/cell;C:/Program Files/Bentley/Workspace/Projects/Standards/cell/
A semi-colon is used to separate the folders in which MicroStation will search for files. If the variable MS_CELL had not been previously assigned, then the full definition for this variable (after the prepend you just made) would simply be:

O:/Projects/I-75/Cell/

With Global Workspace Manager, the CAD manager can monitor and control workstations anywhere in the world without leaving his desk.

By the way, Global Workspace Manager is a great way to monitor and maintain a few or a few thousand workspaces and see what variables have been set at which levels and change them — easily — as needed.