Recovery and mirrored connections – Echelon LNS User Manual

Page 277

Advertising
background image

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.

Advertising