OBD U6 - Catalog Editor vs Config Dialog

Hi Sean,

DG_CATALOGS_PATH is a child variable driven by preceding variables such as TFDIR, it should not be locked.

Out of the box TFDIR points to the installed datasets and includes folders at Organization, WorkSpace ad WorkSet levels.

TFDIR is defined by $(TF_DATASETS)$(TF_DATASETNAME)\

I'm assuming that a) you want the default dataset to be in the N:\ path shown above, where you copy Dataset AU to the network and customise it to your needs, and b) your dataset update strategy is to pull in updates from future dataset versions as they become available (e.g. additional or new content required for new/updated features)?

Once you have defined the path to your network configuration using ConfigurationSetup.cfg, the standards CFGs in that location can modify TF_DATASETS to the appropriate path in your custom dataset.

TF_DATASETNAME sits in the WorkSet.cfg, e.g. at line 14 TF_DATASETNAME = Dataset_AU.

Hope this helps to set you in the right direction?

'Hope this helps to set you in the right direction?'

Not really, the problem I now have is because it seems we're forced down a config path is breaks what I need to happen. I'm not interested in returning to a situation where ucf files create chaos. 

I need to work with this more.

SR7001054217 logged. More to follow.

Hi Sean,

Just a couple of notes on the above:

In CONNECT Edition the UCF plays a very minor role, personal.ucf just stores the last used WorkSpace and WorkSet:

• _USTN_WORKSPACENAME = xxxxxxxxxxx
• _USTN_WORKSETNAME = xxxxxxxxxxx

“We're getting back to the bad old days where it seems each group is developing things how it likes.”
The Open applications are named to reflect increasing convergence. They all have their origins is separate products that were installed on top of and extended MicroStation’s capabilities. As CONNECT Edition products evolve we are working to converge configurations and product features, for instance the continuing replacement of legacy AECOsim structural code with more capable ProStructures code, more of which will soon be available in OpenBuildings Designer update 7.

'

In CONNECT Edition the UCF plays a very minor role, personal.ucf just stores the last used WorkSpace and WorkSet:

• _USTN_WORKSPACENAME = xxxxxxxxxxx
• _USTN_WORKSETNAME = xxxxxxxxxxx'

Sorry Marc, but I disagree. You'd be surprised how much time I waste on issues like users adding reference file paths. It's why it concerns me greatly to see so much more that requires user input. From my point of view, I don't want it. I don't want users adding anything. It's how things get out of control. As I've said before, the interface added is great for small firms who don't have CAD guys or the lone wolf, but it still needs the flexibility for those of us who need more custom options to be able to still do them.  

Hi Bear,

Did you get this sorted because I'm going through exactly the same exercise with exactly the same problems.

I've wasted days trying to get my handrailing and custom shapes to work, and they still don't

I have no problem in AECOSim, but it's a pain in Connect.

I also agree wholeheartedly about Workspaces and Worksets - it removes my ability to customise the way I want and it complicates the builds no end.

Bob Waller said:

it removes my ability to customise the way I want

Hi Bob,

Please can you expand on this, the configuration structure supports as much customization as V8i, just in a different and IMHO clearer way. Maybe we can advise..

Bob Waller said:

it removes my ability to customise the way I want

Hi Bob,

Please can you expand on this, the configuration structure supports as much customization as V8i, just in a different and IMHO clearer way. Maybe we can advise..

Hi Marc,

The problem I have is with the way Worksets seems to overrule the cfgvars I set. I have no control over where the UCF goes - it's always sent to C:\ on the client PC so it never gets backed up as it would if located on the server.

From looking at Bears comments above I realised that the 3 or more days that I have spent trying to get the handrail and custom sections to work in Connect was a total waste of time and company money. I have it working with no problems in AECOSim, but OBD Connect is a can of worms.

My path settings seem to be overwritten so that no matter where I tell the files to go, they always end up on C:\. I picked up on this from your comment above about Bear having only a single path to his Catalogs, because that's exactly what I get. I am telling the files to go to Organization, but the program tries to send them to Worksets (which I don’t have)

I have no problem with the Organization - WorkSpace - Workset construct, it's actually quite easy to understand and if Worksets wasn’t tied down it would be easy to work on. However the way Worksets has been implemented is an absolute pain.

I can’t just browse for a file and open it, I have to browse within the Workset otherwise nothing works. I don’t care if the Designers open a file in the wrong Workset as long as they are using the correct CAD Build so that the client levels, annotation, Vba, etc. is correct.

I don’t want to use Worksets because there is no gain for me or our designers. At present I use NoWorkSet but this has its own problems. I even tried deleting the NoWorkSet.cfg file but OBD won’t run. We also have no use for the drawing indexing system because it’s just another complication. I am a firm believer in the KISS principle and Connect does not meet this criteria.

I get the feeling that Worksets has come from the world of Architecture where drawings are broken down into sets, worked on as sets, and then printed as sets. We don’t do any of that.

Our drawings are created and issued at different times with different Revision Numbers by different disciplines. They will then most likely be modified numerous times by the client and/or another of the client consultants. If they don’t all have the appropriate Workset how does all this happen. Like I said before it’s a can of worms.

I work for a group of consulting engineers who in turn work for 3 of the 4 largest iron ore miners in the world, plus numerous other clients. At any point in time we are working on about 10 projects from Greenfields to Brownfields. A lot of our work is sustaining works so we get a lot of smaller projects in the office. In the course of a year we would probably handle about 300 projects.

I have about 6 client CAD builds to look after plus numerous builds that I have created for clients who don’t have their own. Controlling these is relatively easy because they all have similar architecture. However I need to keep them all separated so that I don’t get cross contamination between builds, and I really don’t intend to create 300 Worksets to control project flow. I don’t see why I have to use CAD Admin hours to create lots of Worksets when there is no gain for us. Our company workflow is not set up to handle Worksets, and we don’t want to spend thousands getting our customised Document Control software updated. When the Bentley programmers have one of their blinding flash of light moments do they ever stop to consider the cost to the client of having to change their current systems, retrain people, and integrate the Bentley changes with the company workflow.

I have to keep placating our directors when they query why everything to do with Bentley Systems costs so much, and I don’t really have an answer. Sadly I have come to the conclusion that in the last few years Bentley has lost its way in looking after their clients. These days they just foist their latest great new thing on us and expect us to wear it.

 Can we please put Worksets under the control of the CAD Administrator, not the other way around.

Hi Bob,

Here are a few notes that may help. I have not tested your scenario and don't know all the details of your setup but I think the suggestions will be relevant.

1. Controlling location of UCF. This is now possible: https://communities.bentley.com/other/old_site_member_blogs/peer_blogs/b/marc_thomass_blog/posts/connect-edition---configuration-tips-user-preferences-in-onedrive-or-other-locations
2. The OpenBuildings configuration will not work without at least one WorkSet, that is why we did not include the NoWorkset option in the delivered configuration. Where WorkSets are unwanted I recommend using a single workset directed to the root of your existing folder structure.
   At the root of your configuration define:
   _USTN_WORKSETDGNS                = <MyProjectFilesRoot>/<Path>/
   That will then be the start folder presented in the UI. The file and folder MRU lists in all file open/save dialogs will save recent files/folders
   You could perhaps set at the organization level

_USTN_WORKSETNAME = <MyWorkSetName>

%lock _USTN_WORKSETNAME

_USTN_WORKSPACENAME = <MyWorkSpaceName>

%lock _USTN_WORKSPACENAME
(but I have not tried that…)
And:
You can hide the WorkSpace and WorkSet pickers as described in: https://communities.bentley.com/other/old_site_member_blogs/peer_blogs/b/marc_thomass_blog/posts/connect-edition---configuration-tips-managing-workspace-and-workset-creation

1. The WorkSet configuration, like the PCF in V8i (the file contents are very, very similar), contains all of that configuration statements that we think might want to be set for different projects (most of which are commented out). If you want to apply the same settings to every DGN just put all of the required statements at the organization level.
   The reason why we recommend users open the application then browse to the WorkSet (project) is to ensure that the appropriate settings are applied, if your settings apply to all DGNs and are set at the organization level then you can open a DGN from your DMS.
2. Drawing indexing is optional. Sheets are only added to the sheet index if the add to sheet index box is ticked when creating drawings.
3. Normally the DGNWS must be user writable, you may be able to work with its location being read-only location as you are not using sheet indexing and would only have one WorkSet.
4. Regarding handrails are you using the enhanced handrail tools that we provide in OpenBuildings via the Catalog or the legacy tool? The enhanced tools offer a lot more capability regarding both placement and handrail construction. As many pre-set variations as required can be stored in the Catalog.

Hi Marc,

Thank you very much for the feedback.

I have now implemented a modified Organisation - Workspace - Workset arrangement along the lines you suggested and it appears to work well. The control I now have over the front page regarding selecting and creating Workspaces and Worksets is exactly what I needed.

We are using the enhanced handrail tool and I have finally got it working correctly (a path problem).

I have yet to modify the user file locations but I don't think this will be a problem as long as the ucf file location can be controlled.

There is a lot of information in your reply that I have never seen before, and I was wondering if it could be made available in a centralised location along with all the other information in Bentley Communities regarding configuring OBD.

I have had to put together my build by using the Help files in OBD and the many and varied pieces of data available in Bentley Communities.

It may sound a bit radical (old fashioned even) but it would be nice to have all this data at my fingertips in an online administrator manual with an index. I waste a lot of time trying to find information on various subjects by randomly searching the net.

You previously created a tech report on the use of Helmert Transformations for use with OBD. I had never even heard of this until one of the other CAD Admins in town pointed it out to me. This is a major part of being able to use OBD when one of our project sites can run for 100 or more kilometres. Without this we would be in deep strife.

If this was in a properly indexed manual I would find it. But just being a tech report means I don't know it exists because I don't even know I'm supposed to be looking for it.

Anyway, thank you again.

I have almost finished our build for OBD but I am still having problems with the Catalog Editor.

No matter what I do I can't get the editor to save data at the Organization level, everything goes to C:\ instead of my server. I have specified every cfgvar I can find that may have anything to do with the Catalogs (see attached) but it still refuses to play ball. I figure that I must have a cfgvar set incorrectly, but after 2 days of trying to find it I am at a loss.

I have attached 4 files which show clips from the various windows.

CatalogTypes.png shows the Structural types that I am seeing, but not the new ones that I have created.

CFG Settings.png shows an extract from one of my cfg files. I've set every variable that I can find that I think would influence the way the Catalog Editor is working.

Slabsxml.png shows an extract from the xml file that I created that went to C:\.

Validate.png shows an extract from the Validation tool showing that all my new items can't find their types.

The Catalog Editor won't hold types after I save them and then close OBD and restart.

Can you please point me in the right direction because I'm getting dizzy going in circles.

Hi Bob,

Try modifying BB_DATASET_ORGANIZATION_FILTER by adding it to your organization standards and pointing to the required location, the root folder containing your organization DataGroupCatalogs, DataGroupSystem and DataGroupLayouts folders.

Out of the box, BuildingDesigner.cfg sets:

BB_DATASET_ORGANIZATION_FILTER            : $(TFDIR)

which feeds (these do not need to be changed!):

DG_CATALOGS_ORGANIZATION_SUBFILTER             : $(BB_DATASET_ORGANIZATION_FILTER)DataGroupCatalogs/
DG_SYSTEMS_ORGANIZATION_SUBFILTER             : $(BB_DATASET_ORGANIZATION_FILTER)DataGroupSystem/
DG_SCHEDULE_LAYOUT_ORGANIZATION_SUBFILTER     : $(BB_DATASET_ORGANIZATION_FILTER)DataGroupLayouts/

That should direct the Catalog editor UI to your resources instead of the delivered dataset.