Jumping back into OPM-CE, but before I do I wanted to see if OPM etc will work with No Workspace and No Workset??
Thanks,
Hi BearThanks for posting query to Bentley plant forum, what's the agenda of loading OPM CE without workspace and workset? OpenPlant Modeler is a schema driven product so to load all the configuration/schemas properly we need to have proper folder structure
ThanksRegards | Deepak Singh
Deepak, we don't use the exact same folder breakdown as Bentley, out of the box, and want to retain the abilities we have with V8i to be able to set our own location for these build directories. We've had issues with packages, like OpenBuilding, were the Connect versions lock out the ability to be able to use these custom locations, which creates some real issues for us. In MicroStation, we negotiated the ability to have NoWorkspace and NoWorkset which allows us to use our custom locations. I'm hoping this is also available in OpenPlant.
Anything more on this Deepak?
Hi Bear,Custom folder structure can be defined while creation of workspace and workset but No WorkSpace and No Workset we would be load OpenPlant Modeler as for loading of any model file in OpenPlant Modeler backend schemas are required
All of the schemas etc. are loaded and used Deepak, it's just that where they sit is in a different location to what Bentley have as a standard. Directory structures are even the same, but they are loaded in such a way that I can run additional cfg files after loading any application builds. Very disappointing the way Workspaces and Worksets have be used by some applications.
If you actually have a look at the build and what it ALL does, it’s little about control and a lot about adaptability and ease of use.
If it helps at all, a little history lesson.
The build, itself, began it’s life as the main building blocks of the Hatch build back around 2000.
I worked a lot on it’s early development, but saw it could be a lot more, but didn’t really get the chance to develop it further until after I left in 2006.
The idea of the build was for it to be an easy way to deliver a build that catered for (in descending order):
Company
Site (office Location)
Client
Project
User
The initial version of the build worked within the existing Bentley config structure, which presented issues.
On top of this, I was looking for a way to manage user issues like referencing, etc. Which were almost daily as there way no easy to lock configs with the cascading config structure we had. Locking too early or too late created other issue or having to manage lengthy project cfg files when I didn’t need them.
So, CADmanage, as it currently exists, was born.
Firstly, no more PCF files. Too hard to work with for my structure.
What changed was a way to cascade the cfg files in such way that I can include site.cfg, client.cfg and project.cfg (or variations of) and still be able to lock variables at the end without effecting builds or users.
Basically, the client cfg files are set in such a way that they run in an order from the company build location:
….\_CADmanage\Bentley\Standard\MS811_SS3\Standards\
To start with I set drive and basic folder location.
I then use the STD_15_Variables_MAIN.cfg to set the building blocks that are then use by most packages. Things like dgnlib, guidgnlib, cells and so on.
Portions of the build are then controlled by the named expressions via STD_21_named_express.cfg.
Next, the magic happens. Using STD_30_Inclusions.cfg I then let the build add (append or override):
Site
%if exists ($(SITE_STDS))
%include $(SITE_STDS)*.cfg
%endif
%include $(ClientDir)$(Client).cfg
%if exists ($(STD_PROJECT)$(PROJECT).cfg)
%include $(STD_PROJECT)$(PROJECT).cfg
I have also set it up in such a way that I can plug in any application as required. Cfg files are added to Client builds and read in the same way:
%if defined (NO_STD)
STD_EC_CFGDIR = $(ClientDir)cfg/
%include $(STD_EC_CFGDIR)*.cfg
NET_EC = 1
%else
STD_EC_CFGDIR = ${parentdevdir{_USTN_SITE}}cfg/
AER_EC = 1
The NO_STD variable allows me to turn off reading the Company build and means less rereading of cfg files. The variable is then used in the named expressions to turn off items not to be used in other Client builds.
For a Client like Worsley, the cfg files would sit under:
The next few cfg files load reference paths, mdl, macros etc.
Nexis where I set the user interface files. Each user gets their own dgnlib, function key menu, cfg file and upf. The big difference here is that we were seeing a lot of issues with upf files where users were in and out of different applications. Now we have upf created by application. Issues gone.
Next bit is a massive time saver. Rather than having to worry about where I lock things or when, because all of my build is running in cfg file order, I can load all of my required build and then lock what ever I want in one file and one location. Can’t emphasise how much time this has saved me over the years as everything is now also locked from user interference before the user files load.
I’ve effectively done all of this before a pcf file or ucf file is read. It also means I can add or take away any part of the inclusions I need at any time, depending on the requirements of the company.
In V8i, we have consistency in the way programs run so I have had very few issues in plugging in different packages and to date have run:
MicroStation
AECOsim
OpenPlant
OpenPlant Isometrics Manager
ProStructures
InRoads
And more.
All of this run from a single little cfg file added to the ….\Config\appl\ directory for any application:
Std_appl.cfg
#---------------------------------------------------------------------------
# Determine MicroStation Version
# Set Version 85 to be the default
STD_MS = MS89
%if defined (_VERSION70)
STD_MS = MS70
%if defined (_VERSION80)
STD_MS = MS85
%if defined (_VERSION_8_11)
STD_MS = MS811_SS3
# Set standard configuration based upon MicroStation version
%if exists ($(hta_sBentley)Standard/$(STD_MS)/Standards/.)
_USTN_SITE = $(hta_sBentley)Standard/$(STD_MS)/Standards/
The big addition to this has been a hta front end that allows the users to pick the variables required for the build to run. Again, this can be customised to run any company system, including one for me as admin:
There’s a lot more functionality built into this, but not really relevant to the current discussion.
So, along comes Connect. All hell breaks loose with the early versions and our lack of flexibility when it comes to the Workspace and Workset use.
Credit to Bentley for listening and making the necessary changes, but then packages like OBD go against the grain and ignore the changes.
For those of us who don’t WANT to be forced down this option we now don’t have a choice, even if I don’t need one I still have to have these set for the program to run. Not to mention I have lost all of the simplicity I have now with eh cascading cfg files.
Feel free to correct me if I have the wrong information, but I hope this gives some insight as to where my current thoughts are with a Connect build.