Mirrored connections, Listing connections and connection members – Echelon LNS User Manual
Page 158
LNS Programmer's Guide
144
Mirrored Connections
LNS allows network variables to participate in multiple connections. As a result, it is
possible to create arbitrarily complex network variable connections on a L
ON
W
ORKS
network (subject to the constraints of the LonTalk protocol). A consequence of the
superposition of connections is that a network variable may find itself in a "mirrored"
connection segment. This situation occurs when one network variable (A) is the hub of a
connection containing a target network variable (B), and B is the hub of a connection
containing A. Thus, connection segment AB is mirrored by segment BA.
When removing connections, it is important to recognize that the network variables
involved in mirrored connections will remain bound until both connections are removed.
Mirrored connections may also appear as a side-effect of network recovery.
Listing Connections and Connection Members
LNS provides several connection-related collections you can use to identify what
connections a network variable or message tag is involved in:
• Each NetworkVariable object contains an NVHubs property. This
property returns a NetworkVariables collection containing the hub
network variables of each connection that the network variable is part of.
If the network variable is the hub for any connections, it will also appear
in the collection.
• Each NetworkVariable object also contains an NVTargets property. If
the network variable is a connection hub, this property returns a
NetworkVariables collection containing the connection’s target
network variables. If the network variable is not a connection hub, this
collection will be empty. Note that network variables may be involved in
connections as both hubs and targets. Thus, to list all network variables
to which a network variable is connected, you must iterate through its
NVHubs and NVTargets collections.
• Similarly, each MessageTag object contains an MTHubs property. This
property returns a MessageTags collection containing the hub message
tags of each connection that the message tag is part of. If the message tag
is the hub for any connections, it will also appear in the collection.
• Each MessageTag object also contains an MTTargets property. If the
message tag is a connection hub, this property returns a MessageTags
collection containing the connection’s target message tags. If the message
tag is not a connection hub, this collection will be empty.
• Each AppDevice object contains an NVHubs property and an MTHubs
property. These properties contain collections of network variable and
message tag connection hubs the device contains. This may be useful if
you are removing a device from the system, and want to make sure its
removal will not affect any connections.
• Each Network object has a Connections object, which contains
collections of all the message tag or network variable connection hubs in
the network. You can access these collections through the Connections
object’s NetworkVariables or MessageTags properties. These
collections contain only those NetworkVariable or MessageTag objects
on the network that are currently acting as connection hubs. Like other