Recovery and mirrored connections – Echelon LNS User Manual
Page 277
LNS Programmer's Guide
263
ConfigProperties collection of the AppDevice for a
ConfigProperty object with the TypeIndex property set to 17
(SCPT_location).
D) When you find a SCPTlocation configuration property, parse it for
the device’s subsystem path and name. Create the subsystem if it
does not exist, and then invoke the AddReference() method to move
the AppDevice to the new subsystem. Set the Name property of the
AppDevice to the proper name, if it is available.
E) If a SCPTlocation configuration property was not found, move the
device to a default subsystem of your choice using the
AddReference() method.
3. Loop through each Router object in the Discovered.Installed
subsystem of the recovered network, and use the AddReference()
method move each router to a default subsystem of your choice. Start
with the last router and end with the first router in the subsystem’s
Routers collection, since this step will delete the routers from this
subsystem.
Recovery and Mirrored Connections
Mirrored connections contain segments that are mirror images of each other. For
example, a connection with hub network variable A and target B is a mirror of a
connection with hub B and target A. Typically, mirrored connection segments appear in
pairs, created by superimposed connections in complex connections.
Sometimes, network recovery introduces mirrored connections in place of the original
connections. This is a side effect of the network recovery process. When recovering a
network, the LNS Object Server cannot determine which network variables were hubs
and which were targets. It sees only the resultant connections. Thus, the LNS Object
Server assigns hubs to connections as best it can, in an attempt to minimize hub usage.
It is unlikely that the hub selection algorithm will reproduce the same hub/target set
that was used in creating the network. As a result, your application should not make any
assumptions as to the hub/target relationship when accessing, removing or modifying
connections on a recovered network. Interoperable tools should always examine both the
hubs and targets when accessing a connection on a recovered network, since the
hub/target relationships on the recovered network depend on the arbitrary results of the
network recovery.