Hello,
I am fairly new to the Bentley World and want to set it up properly for my users who haven't used it at all. What I would like to do is setup the standards and DNG templates and other items that the end users will need on the server and have Bentley look there for these items.
Dimension Styles, Layers, Wall Configs, tags and callouts.
What I am lacking is what to look for and where in the configuration would I find the paths to point the others to? Is there a book or a white paper somewhere that I can refer to for this?
Thank you for the help
To be honest, I think you can take one step back and look at how you can set things up at the most basic level and then build to supply your vertical apps as well.
Here's something I posted a while ago:
The way my build works is very scalable.
I have a cfg file in the appl directpry that helps me set my build location, it also allows me to have the build locally if users are travelling. This is controlled by login scripts and copied fresh to the users machine in each version of MS at login. It looks similar to:
#--------------------------------------------------------------------------- # Set SPS drive mappings #---------------------------------------------------------------------------
build_drv = X:/ P_DRIVE = P:/
#--------------------------------------------------------------------------- # Determine MicroStation Version #--------------------------------------------------------------------------- # Set Version 85 to be the default MS_VER= MS85
%if defined (_VERSION70) MS_VER = MS70 %endif
%if defined (_VERSION89) MS_VER = MS89 %endif
%if defined (_VERSION_8_11) MS_VER = MS811 %endif
#--------------------------------------------------------------------------- #Set build locations #--------------------------------------------------------------------------- %if exists (C:/standard/bentley/$(MS_VER)/Standards/.) _USTN_SITE = C:/standard/bentley/$(MS_VER)/Standards/ %endif
%if exists ($(build_drv)standard/bentley/$(MS_VER)/Standards/.) _USTN_SITE = $(build_drv)standard/bentley/$(MS_VER)/Standards/ %endif
#--------------------------------------------------------------------------- #set client and project configs #--------------------------------------------------------------------------- %if exists (c:/cad_var.cfg) %include c:/cad_var.cfg %endif
_____________________________________________
Under the 'standards' directory I now have my cfg files split to make it easier to debug and change. The directories under 'standards' are exactly the same and the install directories for MicroStation. This helps me and Bentley to sort issues.
Part of the cfg files I have looks for cfg and pcf files in my working locations. This allows me to run the build as it is for all projects out of the box, but also allows me to append or overwrite using these cfg and pcf files. This is where the '%if exists' and '%include' come in. If these files have been created in the build locations, they are read and then the variables in them become part of the build.
The out of the box build also uses the project and client to set reference paths and so on. It does mean having a good standard build, but it also means that anything outside of the build can be appended at the client\project config files.
The cadvar.cfg files simply reads:
Project= CLIENT= USERNAME=
The only reason I've used batch files for this Company is that they won't purchase VB and I'll be buggered if I'll by it for them so I have to supply something they can look after if\when I move on. In the past I would use a small vb app started by a mate of mine that allows the user to pick a Client and Project read from a text file and also have links to the available apps. MS, BS and so on.
The beauty about the vb app is that we also included a 'version' ext file in the project, if required, that allowed us to only make certain apps available once a Client and Project were selected. If done similar with the batch build, but to work around no vb I have added a version directory to the client and project builds that allows me to use a cfg file to help lock out particular version. It reads similar to:
%if $(MS_VER)=='MS811'
% error MicroStation Exiting, V8i not approved for this project. Please Use
%endif
The beauty of this is that, batch or vb, it is very flexibly and scalable without having to do too much work.
How to deliver the build:
http://communities.bentley.com/products/microstation/microstation_-_all_pre-v8_versions/microstation_-_all_pre-v8_versions_programming/f/163/t/21510.aspx
It might take a little reading, but it's a really good base for any beginner, and to be honest, none of this stuff is going to be super easy for any newby to the admin side of things.
Basically, what ever the structure you build with, stick to the directory structure that Bentley use to make it easier to degug any issues you may have.
Using:
allows you to set a location on the network as your site build. If you have a look at the way MS is installed on your machine you then get an idea of what you need to replicate on the network.
What this then means is that when MS starts up it will read any cfg file in the directory:
$(build_drv)standard/bentley/$(MS_VER)/Standards/
This could be:
X:\standard\Bentley\811\Standard\
and so on.
To start with you could hard code the paths in the cfg file you have in the appl directory until you work around the issues of setting a Client\Project etc. you could even just use a batch that copies in a new cfg file into the appl directory each time to set the build.
Thanks - I'll plow through this as best I can - It's starting to look familiar.
"None of this is going to be super easy for any newby to the admin side of things." Bentley's marketing department needs to look very long and hard at that statement. Some of us are "having" to come to this cold because of no other reason than contract requirements. Now that we're trying to use the software our impression of it will go a long ways toward whether or not we'd recommend it to other users.
I'll also add little tidbits as I find them, in hopes they may help shed more light on the overall scheme...
"Datasets" and "Project" installation components:
The "Datasets" portion refers to the content installed under workspace\triforma\. This is where we populate cells, parts, DataGroup catalogs, etc, specific to that dataset; i.e., usually corporate or standards level stuff.
The "Project" portion refers to the folders installed under workspace\projects\examples\, which is a predefined directory structure for storing project-specific data. The delivered content is minimal, but does includes the BB_FloorMaster.dgn file as well as MasterProject.dgnlib for Project Explorer.
The arch_roles.cfg file's path is defined by the configuration variable ATFDIR_ARCHROLES, in the architecture.cfg file, located under the program\TriForma\Architecture\config\appl folder. It is by default set to $(TFDIR), or the main dataset folder or workspace\triforma\. However, this variable can also be set at the project level; i.e., in the *.pcf file, in order to change it's location as needed.
Note: If the same part & family name exists at both the "dataset" and "project" level, the part at the project level will override its dataset equivalent. This allows you to define a corporate or standard dataset to be used across the board, while allowing project-specific parts of the same name to take precedence only if and when they exist.
Another thing I just thought of... While in the Workspace Configuration dialog, change the sort order from Alphabetical to By Level. This will show you how variables are grouped at the System, Site, Application, Project and User level. And this will more or less show you the "load sequence" of those variables - with User variables being the last to load.
Looking at this aspect could help show how some variables are overwritten or prepended/appended during the load process, which in turn may give you ideas about how to redefine variables for some projects but not others.