Echelon OpenLNS Commissioning Tool - Manual (Page 264)

248 Maintaining Networks
which no permanent server is needed. In most cases, however, it may be easier (if not necessary)
to install each floor as a separate network. Once the entire site has connectivity, the individual
floor networks can be merged into a single network representing the high rise.
To support these scenarios, OpenLNS CT provides the ability to merge OpenLNS CT networks.
Network Merge Considerations
When you create a new L ON W ORKS network that will entail merging individual networks, minimize
the number of objects in the top-level subsystem. When you merge two OpenLNS CT network
designs, the merge process will be disruptive to the operation of the networks. For example, devices in
the source network will be assigned new subnet/node addresses, connections will be recreated, and
authenticated devices will have authentication disabled for a period of time. Devices in the destination
network will generally be impacted less, but they can be affected if their connections are modified to
accommodate the new devices from the source networks.
Limitations
The network merge process has several limitations:
• Server support only. You can only merge networks from a local client. You cannot merge
networks from a remote client.
• Single direction only. You cannot stop the merge process once it has begun. You can, however,
restore a network from an OpenLNS CT backup file, if needed.
• Single root subsystem. You can only merge networks that have a single top-level subsystem (this
is the default for OpenLNS CT drawings). If the network has more than one top-level subsystem,
as may be the case when using an OpenLNS network database created by another network tool,
the pre-merge utility will fail. You must remove or relocate all but one of the top-level
subsystems, before retrying the pre-merge utility.
Information Loss
When you merge networks, the following information in the source network will be lost:
• Registered plug-ins. Plug-ins registered in the source database but not in the destination database
must be re-registered following the merge.
• Non-channel object descriptions. Channel descriptions are stored in the channel SmartShapes as
well as in the network database; therefore, they are transferred to the destination database. Other
object descriptions that are not stored in the SmartShapes are lost.
• Source network addresses, group IDs, NV selectors, and other related information. All
devices in the source network are assigned new addresses in the destination network domain and
all connections are reconstructed. Therefore, all subnet/node IDs, group IDs, and NV selectors,
will likely change. In addition, all previously commissioned devices in the source network must
be recommissioned.
• Commission Status. Devices in the source network are unconfigured in the destination network
upon the completion of the network merge. However, the Neuron IDs of the devices are preserved
in the destination network.
• Network service devices. All network service devices (and their functional blocks and
connections) in the source network are removed during the merge.
• Unreferenced device templates. Device templates that have been imported but do not have any
corresponding devices are not created in the destination network.
• Unreferenced connection descriptions. Connection descriptions that have been created but do
not have any corresponding connections are not created in the destination network.
• User profiles. User profiles in the source network are not created in the destination network.