TBC Office/ Field Collaboration Workflow

Is anyone else building a model in the office, then sending it to the field job trailer for foremen to use for data and asbuilts? I’m having trouble efficiently working with the same vce between the field and the office as projects change and models need updated…

Are you using Works Manager as your delivery system?

We are not using Works Manager, at least not on the front end. Someone tried it a couple years ago and decided to stick with Office Synchronizer (TCC) for rover files and manual export for machine files. But poor internet speed on both ends makes sharing a vce difficult on any network-dependent system.

We are utilizing Trimble Stratus, a Propeller product, to house aerial survey’s, ground surveys/scans, and project designs/BIM. This allows for the full utilization of the model by all parties. Owner, PM, Supervision, grade-checkers, etc can get access to this information and can compute quantities and evaluate planning, etc without ever having to be in the design project. However, this isn’t free

I have a couple of hands on the office side that do some minor detail work from time to time. I have a master project that I work out of and they get a copy. They do the task and then export the detail model and I apply to the master. I found that more than one person in the main design file is chaos.

If the project is really big and the field data sets are going to be large - I will copy my master and create a field import project that spj will go first to get sorted and prepped. Data needed for asbuilts will go back to master, the rest stays in the field import project.

All that being said, I have found (I am hardly the last word on this) that separation is needed between field data and office design. It all gets really muddy if everything is going to one place without clean-up along the line.

1 Like

It is a good idea in theory but we continuously run into issues and unfortunately there are not enough users on the TBC/WorksManager workflow to advocate for change.

The biggest pain is the varying degree of vcl acceptance. There is work that it is being done to address this but not at a super aggressive pace.

I couldn’t agree with this more! @nate_doyle. If multiple people are managing a central “master” file chaos will become an understatement. Likely leading to hours of re-organization at some point on some project. I understand the question is how to use a singular .vce but unfortunately I think the answer is don’t. Instead look for alternate solutions to the reason why you’re using a shared file. For example if the foreman is cleaning up the survey data try using the feature code manager for data collection, processing on the backend can become automated. I also like Nate’s suggestion of a copy file for the field where they could just send vcl’s back for the new information. On the design side, leverage works manager, designs go straight to devices ( all of them), you can enter in design change notes in the web portal if needed. and if the foreman wants to view the design in TBC he can download any version of that design from the web portal as a vcl.

If you must share a .vce, use the view filters and lock them. Maybe create a view filter for the foreman and make certain layers and data non-selectable. Also make sure everyone has good habits when opening, closing, saving, connecting and disconnecting from the network. If someone just closes the laptop and walks away you stand a good chance of corrupting data, creating bad lock files, etc…