I have been playing with MicroStation CONNECT and studying ProjectWise CONNECT.
While Bentley has changed names and operability of its MicroStation configuration levels (organization, workspaces, worksets, roles), it appears that Bentley has not made any changes to the managed workspace levels (site, project, discipline, etc.) in ProjectWise .
Is Bentley formally defining any parallels between MicroStation CONNECT configuration levels and the ProjectWise CONNECT managed workspace levels? Will the managed workspace levels change names or operability in ProjectWise CONNECT in future releases? Does the MicroStation CONNECT WorkSpaceSetup.cfg file have any impact on ProjectWise managed workspace CSB's? Will MicroStation users experience anything in the interface that says "WorkSpace" or "WorkSet" when working in the ProjectWise CONNECT environment?
We just completely redid our CONNECT managed workspace as our old one wasn't working very well. It mostly follows along with the link Phil posted, however we went through lots of rounds of troubleshooting to get the dgnws file to work the way we wanted.
We wanted the dgnws file in the project folder with other dgn files for that project. We did not want a single folder with all dgnws files for all projects in it. Both for security reasons and just easier management reasons.
Documents Office Project CADDLib dgnws
Our typical Projectwise structure is each office using a datasource gets a folder for their office. Under their office folder is a folder for each project they own (this folder is a ProjectWise WorkArea folder). Each project gets a CADDLib folder with a dgnws folder in that. We want the dgnws file to be in that folder. And we want Microstation (or vertical) to create the file in that folder.
What we found was that Microstation is very particular about what level (workspace, worksheet) certain variables are set at. To get it to work with ORD, OBM and MicroStation we did the following:
In the config file for the WORKSPACE we set:
_USTN_WORKSETROOT = DMS_PROJECT (_dgndir) _USTN_WORKSETSTANDARDS = $(_USTN_WORKSETROOT)CADDLib/ # Location of DGNWS files are per workset _USTN_WORKSETSDGNWSROOT = $(_USTN_WORKSETROOT)CADDLib/dgnws/ %lock _USTN_WORKSETSDGNWSROOT
The lock seemed necessary. Note that this configuration is pretty generic in that it doesn't reference the workspace, but if I set this anywhere other than the workspace config file all kinds of weird things would happen.
Then at the WORKSET config we set:
_USTN_WORKSETDGNWS = $(_USTN_WORKSETSTANDARDS)dgnws/$(_USTN_WORKSETNAME).dgnws
Again, putting that at a level other than workset seemed to cause weird behaviors (the weird behaviors were different for ORD and MicroStation. MicroStation was Update 14, I think the current ORD is built on an older Microstation version). Also it may seem a bit redundant to set both the _USTN_WORKSETDGNWSROOT AND _USTN_WORKSETDGNWS variables but we found we needed both set for ORD, OBM and MicroStation to all work.
Finally one last problem we ran into. If we let ORD create the dgnws file, it would create it in the correct location with the correct name but we would be unable to edit the dgnws file. If we let MicroStation Update 14 create the dgnws it worked fine in both MicroStation and ORD (and OBM). Thinking it was a problem with the template files in the older ORD we put the template files from MicroStation Update 14 in our Corporate standards and set:
_USTN_WORKSPACETEMPLATE = $(_HNTB_STANDARDS_ROOT)Template/WorkSpace.Template _USTN_WORKSETTEMPLATE = $(_HNTB_STANDARDS_ROOT)Template/WorkSet.Template _USTN_WORKSETDGNWSTEMPLATE = $(_HNTB_STANDARDS_ROOT)Template/WorkSetTemplate.dgnws
That is set in our Organization config file. I just noticed I left in _HNTB_STANDARDS_ROOT, that's the same as _USTN_ORGANIZATION, we just prefer using our own variable.
This is how we implementing also. Each project has a Workset folder in which a single workset CFG file is placed along with the matching dgnws file. The DGNWS file is automatically created by the CE design application. You must create the appropriately named workset config file in the location defined by _USTN_WORKSETSROOT. The file doesn't have to set anything but must exist in PW.
#----------------------------------
# Set Work set root path to project
_USTN_WORKSETSROOT = $(dms_project (_dgndir))DesignData/CAD_Standards/Worksets/
%lock _USTN_WORKSETSROOT
#-----------------------------------------
# Set Dynamic Workset Name to Project Name
_USTN_WORKSETNAME = $(WS_PROJECT_NAME)
%lock _USTN_WORKSETNAME
If you have issues with the wsdgn file not creating check your local dms folder and make sure you don't have any dgnws files left behind. When testing you end up deleting files but forget to purge first. If the dgnws file already exist in your local cache it will not be created in ProjectWise.
Greg Roberts said:If you have issues with the wsdgn file not creating check your local dms folder and make sure you don't have any dgnws files left behind. When testing you end up deleting files but forget to purge first. If the dgnws file already exist in your local cache it will not be created in ProjectWise.
Omg, I forgot to mention this. IT IS INFURIATING!
Yes it is! I wasted countless time with randomness (worked some times and not others). Something I'll never forget....
Thanks Mark, I have been struggling with ABD update 3 vs PW 280...
Finally got it to "work" although it still seems very temperamental... I set both the Worksetsroot and Workspacesroot (why make it simple when it can be oh so complicated...) in the predefined CSB, all else was failing miserably...
I actually disabled the _TF_WORKSPACEROOT also which didn't seem to have any negative side-effects...
All in all, hours spent during which I'd rather be designing :-) Thanks again.
Oh also I associated the files with Microstation, if associated with ABD CE I get the error message "cannot load mcm.ma".... Talk about trial and error ! :-)