Echelon LNS - Manual (Page 170)

LNS Programmer's Guide 156
D
G
C A
E F
H J
B
R
T
S
U
Figure 7.3 Ceiling Lighting With Occupancy Sensors And Connections
Assuming each occupancy detector has only one relevant output network variable, a
multicast connection will be used to connect sensor R to lamps A, B, D and E. By default,
LNS will use a group to accomplish this. A group ID will be allocated, and one address
table entry will be used on each of the five participating devices.
When connecting the sensor S to lights B, C, E and F, another group will be created. This
requires another address table space on each of these five devices, and another group
identifier.
Each light (apart from the ones in the outermost row and column) will have to have four
address table entries to accomplish these connections. On a large floor with more than
four occupancy sensors, this will quickly exhaust available group IDs, and eventually the
integrator might fail to add new sensor/lamps segments due to a lack of available group
identifiers.
Broadcast addressing provides a way to avoid the use of group identifiers in this
situation. Most of the lights will reside in the same subnet as the occupancy sensors, and
the combination of subnet broadcast addressing and the unacknowledged/repeat
messaging service may also seem like an attractive option. However, in order to comply
with rule 6 of the connection rules introduced in this chapter, you would have to allocate
the same selector Z to both intersecting sensors (e.g. sensors R and S). This is required so
that the input network variables on lights B and E do not violate rule 6.
This has an unpleasant side-effect: each network variable update from, say, sensor R will
not only effect the lights A, B, D, and E, but also lights C and F. The effect is known as a
network variable leakage, in this case caused by a phenomenon known as intersecting
broadcasts. LNS can detect this problem beforehand, and will refuse to connect the
second sensor (and any further sensor) due to the detection of a leak in this scenario.
A solution to the problem is to use aliases for unicast connections, instead of using
multicast connections. Since each unicast connection can have its own unique selector,
the leakage problem will disappear, and the group identifier will remain available for
other connections.
This is accomplished at the expense of alias table space and address table space on the
occupancy sensor devices, and at the expense of network bandwidth. The different