When we build custom Configurations for clients there are some general rules by which we abide. These general rules are also passed on to our students attending our CAD Manager training. These apply to MicroStation, PowerDraft, OpenRoads Designer, and every other MicroStation-based application. We’ve published previous articles related to this topic (see links below) but seeing as those are now several years old it’s time for an update for the CONNECT Edition products.
I call these my Ten Commandments for Creating Configurations.
- Thou shalt not edit the Bentley delivered configuration files.
I cannot stress this enough… DO NOT EDIT ANY OF THE BENTLEY DELIVERED CONFIGURATION FILES!
Create your own configuration files and copy them into the appropriate configuration folder so they get included at the proper level during the MicroStation startup sequence. You can overwrite most of the default definitions and lock them if you need to. There is a reason many of the delivered configuration files contain warnings not to edit. Editing the delivered files leads to problems and headaches you don’t need, we’ve seen it happen too many times. - Thou shalt not co-mingle thy seed files, dgnlibs, cell libs, rsc files, etc. with those delivered with the product.
While it may be tempting to just copy your custom resource files in with the Bentley defaults, don’t do it. We’ve seen configurations like this and the client then becomes confused as to which files are their custom files, and which ones are the Bentley delivered files. They start making updates to the delivered Bentley files (violating the first commandment) as if they were their files. This creates a big mess to sort out when you want to reinstall, upgrade, etc. You replace the new defaults with your older edited defaults and suddenly things in the new release aren’t there, or don’t work correctly. - Thou shalt configure WorkSpaces and WorkSets.
As clients move to the CONNECT Edition we’ve seen too many instances where they want to go with the No WorkSpace and No WorkSet option for everything. Configuring WorkSpaces and WorkSets are a great way to separate work between different clients, disciplines, departments, projects, etc. By not using WorkSets you can’t take advantage of WorkSet properties to make your title block definitions easier, nor can you take advantage of the Sheet Index capabilities. Almost as bad as using No WorkSpace and No WorkSet is making your WorkSpace and WorkSet definitions too broad. - Thou shalt replicate the default folder structure.
Take a look at the C:\ProgramData\Bentley\MicroStation CONNECT Edition\Configuration folder structure. When creating your custom configurations on a network drive replicate the Organization, WorkSpace, and WorkSet folder structure. This makes your work in setting up your custom configuration much easier. By making just one or two custom variable definitions in the start up of your custom configuration all of your .cfg files and resources load without any additional work. - Thou shalt not name thy custom variables with an MS or USTN prefix.
Creating custom variables is encouraged, just don’t prefix your variable names with MS or USTN. This causes confusion as to which variables are your custom definitions, and which ones are Bentley variables. Use your company/department/agency acronym, or other unique identifier, as a variable name prefix. This not only allows you to quickly determine which variables are yours, but it also groups them together in the Configuration Variable dialog listing and other displays. Using an AA prefix is also a good choice so that all of your variables are at the top of the list when sorted. - Thou shalt separate thy dgn files from thy WorkSet configuration files.
This seems to contradict commandment 4 above, but it is a necessity. Most organizations have some type of Projects folder with a sub folder for each project. These project folders store not only the design files for a specific project, but also other documents and resources related to the project used by other non-MicroStation users. You don’t want users to have to navigate through the WorkSpace, WorkSet folder hierarchy to find their files. By separating them it also makes it easier to restrict access to the configuration and standards files so only the CAD Managers and/or Project Managers can edit them. - Thou shalt not share user preference (.upf) files.
– Between Users: User preference files are meant to be user-specific. Sharing files between users creates conflicts and can lead to frequent corruptions.
– Between Applications: While PowerDraft, MicroStation, OpenRoads Designer, etc. may have similar preference settings, they are unique to each product.
– Between Versions of the same application: The MicroStation V8i version of the user preference file is different from the CONNECT version. Do not move the old .upf files forward. - Thou shalt not number thy levels.
Old habits die hard, but level numbers are no longer needed. Level names that get defined with duplicate level numbers are not visible in MicroStation. (See link to level numbering tip at the end of this post) - Thou shalt define a resource in only one location.
We do a lot of CAD Audits. One thing that is a part of most audits is reviewing each dgnlib file to determine what resources are defined in each one. Invariably we find the same levels, text styles, etc. defined over and over again in multiple dgnlib files. When users update a level in what they think is their level dgnlib file it doesn’t update in the configuration as MicroStation is using the definition from a different dgnlib. This does not mean throw everything into a single dgnlib file (we’ve seen that too). Logically separate resources into separate dgnlib files, and name the dgnlib file so that you know what resources it has. For example your dgnlib files with level definitions should have the word LEVEL somewhere in the file name, and if the levels in the dgnlib file are for a specific purpose (like Survey) put the word SURVEY in the file name too. Some resources it may make sense to combine into a single dgnlib file such as Text Styles and Dimension Styles. OpenRoads Designer requires that Levels and Element Template definitions reside in the same dgnlib file, it also requires your Feature Definitions be in there as well.
There is one instance where having duplicate definitions is required; custom line styles for use with Standards Checker. When creating and updating custom line styles the line style editor will only work with line styles stored in a .rsc file. If you want to configure Standards Checker to report on custom line style definitions then they must reside in a dgnlib file. In those cases only configure the line style dgnlib files in your production configuration. Reserve the .rsc line style files for a development version of your configuration. - Thou shalt make thy standards easy to follow.
One common issue we find is that organizations have a problem with users not following standards. During our CAD Manger course we discuss making your standards easy to follow so that it’s easy for the users to follow. Making the standards easy to follow greatly increases the likelihood they will be followed. These are some things that will make your standards easier to follow:
– Define the appropriate configuration variables: You don’t want users to have to navigate through multiple folders to find a cell library, plot config file, pen table, etc. Configure the corresponding MicroStation variables to the locations of these files so that they are automatically populated in the corresponding MicroStation dialogs.
– Consistent naming of levels, element templates, etc.: You not only want to be consistent in the way you name your levels, but also related resources. For every element template there should be a corresponding level with the exact same name so there is on confusion as to the correlation. The same thing goes for OpenRoads Designer feature definitions, they should have the exact same name as the level and element template they are using. There should be a one to one to one correspondence between Level Name, Element Template Name, and Feature Definition Name. If you really want to go all out you can create a custom color book with matching color names to use for the ByLevel color for each level. This prevents color changes if users attach a different color table.
– Create custom tool boxes/menus/ribbons: Once you’ve created the levels and element templates, create a custom tool button for each one that sets the element template and launches the appropriate tool (Place Cell Icon, Place Smartline, etc.).