Understand the VCL Design Exchange Format

Introduction

Previous Trimble construction workflows exchanged design data using several different file formats saved into a complex folder hierarchy in a data synchronization area used by Trimble Business Center (TBC) and the Trimble Connected Community (TCC). Using myriad file types to send designs to field devices and machine control boxes introduced unnecessary complexity when manually transferring designs, synchronizing data, and troubleshooting problems.

You can now use simplified office-to-field and field-to-field workflows by leveraging the single, unified VCL file format for designs. VCLs also make it easier to share design data with disconnected devices and machines via a USB flash drive.

Trimble VCL (*.vcl) is a file format used for the exchange of civil engineering and construction data. The format was originally derived from TBC’s native VCE (*.vce) project file format. VCE stands for virtual construction environment; these files contain all of the data for a TBC site or corridor construction project. VCL stands for virtual construction link; these files contain just the objects that a user selects within a VCE project to share to another VCE project (plus any dependent objects; see Object Dependencies in VCLs below) and now to share with WorksManager, Siteworks and Earthworks.

A VCL file can contain most* of the data that a regular VCE project file contains, but in a format that is suitable for transfer. As such, object dependencies and ‘intelligence’ are retained with no loss of (or change to) their properties when you transfer the data between VCE and VCL formats (and vice versa). This preservation of native TBC objects (and the relationships between them) when you use VCL files for exchange, gives you the flexibility to share both entire TBC projects and subsets of projects.

*Note:  VCL files do not support some survey object types, such as GPS baselines, vectors, trajectories, and level data.

Note: One benefit of using a VCL file is the ability for machine operators to clean up their screens (e.g., by turning off linework) so they see only what they need.  

Difference between Office > Office VCLs and Office > Field VCLs

When exchanging data between TBC projects using VCL import, ‘intelligent’ dependencies (and dependent objects) described above are retained.

When sending data from TBC to field systems as designs (that the firmware opens) via WorksManager, dependent objects for surfaces and road surfaces (e.g., the points and lines that define them) are not included. Typically, those objects are not needed for field work, and eliminating them makes the VCL files much smaller and usable by the field devices and machine controllers.

This behavior is controlled by the Cleanup VCL file property in TBC. By default, this property is set to Yes for WorksManager projects. To change the setting, click a WorksManager project in the TBC Project Explorer, press F11 to open the Properties pane, and change the Cleanup VCL file property. Then, dependent objects will once again be sent to the field in VCL designs when using WorksManager as the intermediary.

How VCLs are Used Between TBC Projects

Prior to now, VCL files were used only to exchange data between TBC projects by:

Object Dependencies in VCLs

VCL files are powerful because the objects they contain retain all of the dependent relationships to other objects they had in the VCE project (regardless of whether those objects were selected for export to the VCL). If the other (non-selected) objects have additional dependencies, every object within the ‘dependency chain’ is exported to the VCL. For example, exported surfaces will bring in all of the ‘members’ required to form the surface. These typically include: points, lines, and alignments. Note that (as shown above), the surface object itself has to be rebuilt in the new project.

This process provides a significant advantage over exchanging native TBC objects using other CAD formats, such as DXF, in which much of the ‘object intelligence’ and dependencies are lost.

Using VCL as a Field Data Design Exchange Format

TBC supports hundreds of object types. Therefore, VCL files do too. For example, linear objects in TBC include lines, polylines, linestrings, alignments, boundaries, breaklines, and closed polylines that form polygons (rectangle, circle, arc). Each of these specific object types can be exported to VCL. For an overview of VCL components for field system exchange, see VCL Components below.

This fundamental simplicity makes VCL files readily extensible for use as the format for construction data exchange with other CEC software, particularly as data flows from the office design phase to the field construction phase. For example, DSP900/Groundworks applications for compaction, drilling, and piling use VCLs to exchange data with TBC. Drilling, piling, and compaction plans are sent out to Groundworks, field work is performed, and as-drilled/piled/compacted results are brought back into TBC for quality analysis. This shows the potential for exchanging design data (linework, stakeout points, surfaces, alignments, corridors, etc.) between office and field using the powerful VCL file format.

Note:  Currently, project data (shown below) is not exchanged using the VCL file format.

Project level

VCL Components

VCL objects and data that other programs can load include:

Design level

For descriptions of these objects, see Connected Construction Terminology.

Importing versus opening a VCL

If you open a VCL as you would open a VCE, all of its data (such as the coordinate system) and dependencies (surfaces will not try to rebuild) stay intact. If you import a VCL, it will use your project’s current coordinate system and will try to rebuild surfaces, even if the objects on which they depend have been removed.

Limitations