Design: In a project specific context, the "Design" section describes active and passive models, how they appear and be have on different platforms, and how they are used as avoidance zones.
This section also describes file revisions before and after synchronization, exceptions regarding file formats and how tags are used to enable smart filtering of models in MC1 and ConX.
Passive models: A passive model is in effect defined as any model that is not active – it is used as "background" with all objects (Points, lines and surfaces) visible, but not selectable.
A machine operator will not be able to work on any object in a passive model.
A passive model can only be viewed in the runscreen if it is part of the models selected in MC1 “Select Models” menu.
Active models
With the exception of distance to avoidance zones, all calculation in MC1, including creation of as-built data, is only done in relation to the currently active model.
Only one model at a time can be active in MC1 – all other models are defined as passive. Thus, an active model becomes passive the moment another model is defined as active.
The operator can define which model should be active, directly from the runscreen or in "Select Models" menu.
Avoidance zones
All supported model types, including 3D models, can be used when defining avoidance zones.
Avoidance zones can be based on passive models containing points, lines and surfaces.
The entire model is used as avoidance zone, and should initially be prepared as such.
Model tags
Tags enable smart filtering of models in ConX and MC1.
Models are tagged when imported or synchronized with ConX. Un-synchronized models created in MC1, and models in USB projects, are NOT tagged.
Tags are named after the project sub folders in ConX, but to simplify data access for the machine operator, no folders are displayed on the panel. Instead, the machine operator can filter and thus find relevant models by selecting tags in MC1.
The number and hieararchy of tags attached to a model depends on the sub folders leading to where the model is stored (See illustration below). This means, that tags can be used as a bread crumb reflection of where a model can be found, and in what context it should be seen.
Model appearance
Objects have the same appearance in all models, even if file types are different, making it easier for the machine operator to work with different models.
Plan view provides guidance based on current selections. It is recommended to use plan view in 2D mode when working with .dxf models. The reason for using 2D mode is that model files, including .dxf files, often contain objects with zero height.
Model behaviour
All models can be synchronized, including those created on the panel in MC1. Models created in MC1 are generated in open formats, making them easy to use outside the Leica ecosystem.
MC1 allows simultaneous use of a model reference for height calculation (Point, line and surface) and a model reference for side distance calculation (Line).
Choosing a single element, not an entire model, as height reference, always creates a surface through extention of the chosen element.
MC1 supports "corridors".
Use of corridors is a Leica concept, and indicates that two lines are connected by a virtual 3D surface.
Corridors behave just like triangulated surfaces. A triangulated surface can be used as height reference, but it is recommended to use corridors instead, as they will enable much faster and more accurate calculation.
Corridors effectively allow perfect grading of an area between two lines, without the need for triangulation.
Available corridor model formats: LandXML, LMD and MBS.
Exceptions
DXF files contain texts in labels that are not available in other files. This text information can be viewed in the 2D plan view.
DXF files contain layers of objects.
The machine operator can access all elements, but cannot select/deselect layers or turn layers on/off.
Revisions
ConX is master, and after synchronization, files in MC1 will mirror files on ConX. A ConX synchronization effectively deletes files in MC1 that are not in ConX, and overwrites files with identical names. It is recommented to let ConX handle file revisions, and not keep multiple versions of the same file in ConX.
A USB synchronization overwrites files in MC1 with files of identical names from the USB stick. A USB synchronization does NOT delete files in MC1.
Files on the USB stick, or in ConX, will NOT be deleted or overwritten as a result of synchronization. 