Resolve Data Conflicts Between TBC and WorksManager

Publishing data

Three commands in Trimble Business Center (TBC) publish data to WorksManager as a VCL file:

• WorksManager Project automatically publishes project data like the name, units, boundary, site calibration, control points, and avoidance zones as you specify them.
• WorksManager Design Manager publishes design data like the stakeout points, model, and design map when you click Publish.
• Publish to WorksManager publishes previously unpublished or modified design data when you click OK.

Each of these commands pushes data to WorksManager by way of the ‘data synchronization area’ (the default location of this folder is C:\Trimble Synchronizer Data\WorksManager\<project name>) where files are stored on a project, design, and version basis. From there, the data is then synchronized with the same data on WorksManager. If you are working offline when you publish, the synchronization occurs when you go online. Publishing also occurs when you resolve a conflict using the Publish to WorksManager option. See Revolving conflicts below.

Note: The WorksManager Field Data to USB Drive command does not actually publish a VCL; it simply copies a previously published VCL (or other file types for the job site field data workflow) to a local drive that you specify.

Synchronizing data

Synchronization is the process of making files or data in two places match each other, usually by having the latest version (per date/time stamp) overwrite an earlier version. In TBC, synchronization is done on files in the data sync area. Beneath C:\Trimble Synchronizer Data\WorksManager\<project name>\, each field system may have a slightly different structure to accommodate its unique firmware.

Note: You may have placed your data synchronization area in a different location or named it differently. To see where it is currently located, select File > Options on the TBC ribbon. In the Options dialog, click File Locations in the left pane and see Data synchronization area (Synchronizer Root Folder).

To be in a state of synchronization, a file with the same creation/modification date must appear in WorksManager (and the field devices/machine control boxes using its data) and in the data synchronization area used by TBC. Files are synchronized so that office staff using this software and field crews using Siteworks and Earthworks are using the same (and most current) data.

Note: The data synchronization area is meant for data exchange only, as a temporary repository for data that is in transit between the office and the field. You should not directly modify its structure or contents, but manage all your construction project files in a separate location.

A WorksManager folder (separate from the one used by the field data workflow for job sites) is created within the data sync area for the WorksManager field data workflow. If a new WorksManager project is referenced by an existing TBC project, and that project name already exists in the data sync area, then TBC will maintain synchronization with the existing job site.

Resolving data conflicts

A conflict is triggered by a difference between project or design data in your project in WorksManager and data for the same WorksManager project or design in the data sync area.

A conflict is indicated by an active Resolve button with an icon in either the WorksManager Project or WorksManager Design Manager command pane. The icon prompts you to resolve the differences by choosing which data to use across TBC, WorksManager, and your field systems (Siteworks and Earthworks). Depending on your choices, either your TBC or WorksManager data is updated, thereby resynchronizing it.

Project Explorer icons indicate sync status

As is done for existing job sites, field data icons for WorksManager projects and designs in TBC’s Project Explorer are appended with red badges when they need to have conflicts resolved or otherwise be synchronized. In addition, the label text becomes red in these cases.

• When you resolve differences between TBC and WorksManager, data in the sync directory will match the data in WorksManager.
• When working offline, the sync directory will be the staging location for data published to WorksManager (pushed to WorksManager when you are back online).
• When you publish from TBC, the sync directory and WorksManager will match TBC.
• The resolve button will be enabled if:
  • The sync directory does match WorksManager (user added a file to WorksManager)
  • The TBC project changed and no longer matches the Sync Directory
  • A different user of TBC publishes to the same design name while in off-line mode and using a shared Sync directory.
• The folder structure does not contain information about the account. As a consequence, two different projects with the same name but different accounts will cause TBC to mark files as out of date whenever the other project pushes out file. Therefore, it is possible for different TBC projects to modify the same synchronized folder data and also the WorksManager project.
• The design VCL name contains all of the attributes needed to map it between TBC and WorksManager. The layout is-

<design name>.<created time>.<Version>.<State Flag>.VCL

• Design name - human readable name assigned to the design (same in TBC and WorksManager)
• Created time- number of ticks (as defined by .Net) since January 1, 0001 that elapsed since this design version was created.
• Version- version number of this design.
• State Flag- Marks what product has defined this design.

Prevent overwriting project data

As a WorksManager project Administrator, you can prevent colleagues from intentionally or accidentally overwriting project units, avoidance zones, a feature code library, site calibration, and control points. In TBC, select Project Settings > Computations > Field Data > File Overwrite Protection.

Resolve conflicts in project data

When you first open a WorksManager project that you created in the web app in TBC, all project data will need to be resolved; TBC is not aware yet of the WorksManager data, so you are synchronizing the two programs. The dialog will look like this:

Resolve a units conflict

In TBC, the default units (meter, US survey foot, or International foot) are based on the template used when creating the TBC project. WorksManager does not specify units anywhere, so a conflict arises:

• When you open the WorksManager project in TBC for the first time
• If you publish WorksManager project data that specifies units from TBC to WorksManager via VCL, and then change the units in TBC.

1. When the Resolve button in the Units group turns red, click it.
2. In the Resolve Units dialog, select an option:
   • Publish to WorksManager - Push TBC’s current project units to WorksManager again. This is generally what you will choose.
   • Adopt from WorksManager - Pull the units in from WorksManager, thereby changing them in your TBC project.
3. Click OK.

Resolve a boundary conflict

When you create a project in WorksManager, you must draw a boundary for use as a geofence for your assets. When you subsequently open the WorksManager project in TBC in the WorksManager Project command, the boundary is shown. If you are starting in an offline mode in TBC, you can pick a boundary object that has its property set to Type = Project.

• A boundary is not currently required by field devices or machine control boxes, but is in WorksManager.
• WorksManager has these boundary requirements:
  • Only one boundary is allowed per project.
  • Boundary coordinates are in latitude/longitude, which requires a site calibration to map from grid coordinates.
  • The start and end points of the boundary must be identical (forming a closed shape)
  • The boundary must contain at least 4 points (e.g., triangle w/ duplicate ends).
  • The ‘wrapping direction’ is counter-clockwise, and segments cannot cross-over or touch each other (except for the start and end points).
  • There is no maximum on the number of points that can be used to draw the boundary.

A conflict arises:

• When you open the WorksManager project in TBC for the first time
• If you pick a new project boundary from a TBC view and then resolve the conflict by publishing to WorksManager.

1. When the Resolve button (enabled when versions conflict) in the Project Boundary group turns red, click it.
2. In the Resolve Boundary dialog, select an option:
   • Publish to WorksManager - Push TBC’s current project units to WorksManager again. If the label shows (Undefined), no boundary is defined within TBC, so the option is not allowed.
   • Adopt from WorksManager - Pull the boundary from WorksManager, thereby overwriting it in your TBC project.
   • Import from WorksManager - Pull the boundary from WorksManager so you can preview the location, but keep your TBC boundary also so you can pick the one to keep. If you then select the imported one as the project boundary, there is no need to publish a new boundary version back to WorksManager.
3. Click OK.

Resolve a site calibration conflict

In WorksManager, you can add a site calibration as a .cal or .dc file from TBC, SCS900, or Siteworks. In TBC, you can also either import a site calibration or calibrate your site ‘from scratch’.

Note: Because site calibrations may originate in the field (using SCS/Siteworks) and are then imported into this software, you can publish from TBC to WorksManager without specifying a coordinate system/calibration. Nevertheless, you are prompted to resolve the conflict if you have not included a calibration, but it is just a warning you can bypass if you know that the field crews have established one.

Note: If you do not export a site calibration, but instead rely on using one from the field, you are not warned in TBC if you do not subsequently import that field calibration. After the site calibration is created in the field, and stored in WorksManager, you should import that field calibration back into TBC.

A conflict arises:

• When you open the WorksManager project in TBC for the first time.
• If you calibrate or recalibrate the site in TBC and publish project data to WorksManager, thereby making the versions different.
• When no calibration is defined in either TBC or WorksManager

1. When the Resolve button in the Site Calibration group turns red, click it.
2. In the Resolve Units dialog, select an option:
   • Publish to WorksManager - Push TBC’s current site calibration to WorksManager, which also leaves the resulting calibration file in your local data sync area.

     Note: If a GCS900 calibration exists in WorksManager, you will not be able to publish from TBC; an error message will post and the publish will abort.

   • Adopt from WorksManager - Pull the calibration in from WorksManager, thereby replacing TBC’s definition and invalidating any defined projects.
3. Click OK.

Resolve a control point conflict

In WorksManager, you can add control points as an office.csv file. In TBC, you can also either import them in the same way or create points and set their quality to Control. When calibration file versions conflict or the calibration is not defined on either end of the transfer (button is disabled if TBC and WorksManager reference the same Site Calibration).

A conflict arises:

• When you add a control points file in WorksManager and open the WorksManager project in TBC for the first time.
• If you specify new control points in TBC and then resolve the conflict by publishing to WorksManager. If you change control points in TBC and publish project data to WorksManager, thereby making the control point versions different.
• When control points are not defined in either TBC or WorksManager.

1. When the Resolve button (enabled when versions conflict) in the Control Points group turns red, click it.
2. In the Resolve Control Points dialog, select an option:
   • Publish to WorksManager - Push TBC’s control points to WorksManager. This requires that you have already added control points using the button in the group. Control points are saved to WorksManager with a version. If no points are selected, the current TBC version is zero.
   • Adopt from WorksManager - Pull the control points in from WorksManager, thereby overwriting the ones in your TBC project.
3. Click OK.

Resolve an avoidance zone conflict

In WorksManager, you can add one or more avoidance zones as an avoid.dxf file. In TBC, you can create them from closed polylines.

A conflict arises:

• When you add an avoidance zone file in WorksManager and open the WorksManager project in TBC for the first time.
• If you specify new avoidance zones in TBC and then resolve the conflict by publishing to WorksManager. If you change avoidance zones in TBC and publish project data to WorksManager, thereby making the avoidance zone versions different.
• When avoidance zones are not defined in either TBC or WorksManager.

1. When the Resolve button (enabled when versions conflict) in the Avoidance Zones group turns red, click it.
2. In the Resolve Avoidance Zones dialog, select an option:
   • Publish to WorksManager - Push TBC’s avoidance zones to WorksManager. This requires that you have already added avoidance zones using the button in the group. Avoidance zones are saved to WorksManager with a version.
   • Adopt from WorksManager - Pull the avoidance zones in from WorksManager, thereby overwriting the ones in your TBC project.
3. Click OK.

Related topics

Understanding Connected Construction Data Exchange

Assign and Configure a WorksManager Project for Siteworks

Assign and Configure a WorksManager Project for Earthworks