Best Practices for LON NVO-to-NVI creation, linking and binding when designing

Spyder controller applications.

When creating Network Variable Inputs (NVIs) and Network Variable Outputs (NVOs) it is
important to understand the way the peer field device addresses are stored inside the Neuron
transceiver chips, since each Neuron chip in a typical field device, including Honeywell Excel 10
and Spyders, has an address limit of only 15 entries. The peer controller addresses are stored in
an echelon chip's Address Table which can be viewed in a controller's property sheet.

The analogy here is that each field device on a LON trunk has an old fashion address book (little
black book) with only room for 15 names and addresses in it. Even though there is a limit of 15
Address table entries, an entry is re-used when more than one data point is using the same
address.

Careful NVI and NVO design is required when an application has LON peer-to-peer
communication between more than 15 field devices as one might do when sharing a single data
point like outside air temperature, or retrieving data from multiple controllers, such as terminal
load information. Knowing when and where address entries are stored, we can design our NVOs
and NVIs to avoid instances where we might otherwise fill up an address table in a field device
(resulting in constant "New Link" messages even after a successful binding in the Lon Manager).
Don't fret...It IS possible to send data from more than 15 field devices to a single address, as well
as sending data out from one device to more than 15 destinations without this "New Link" error
if designed correctly.

The LON Link Manager handles the configuration and maintenance of the chip's address tables
automatically as part of normal linking and the BIND function. Note that the echelon LON card
used with on a JACE controller utilized the echelon HOST stack, which has a much larger
address table associated with it so there are more than 4000 available slots,. A JACE is not
limited to 15 devices addresses, but proper data communication still requires linking and binding
to and from the JACE. When an NVO from a field device is represented by a PROXY point in
the JACE database, a link is automatically created between the field device neuron chip and the
neuron chip in the JACE and must be bound.

Peer-to-Peer data transfer between Lon devices (including the JACE) falls into 2 general
categories: Data transfer from one source controller to only one destination controller, and data
from one source controller to MANY different destination controllers...

One-to-one data transfer requires only a single entry in the address table of the sending source
device (source NVO) with no address entry stored in the receiving device. This is akin to sending
a letter in the mail where only the sender requires the address of the recipient, but the destination
doesn't need to know the address of the sender to receive the mail. In this instance, the data
transfer packet includes the identifier for the specific receiving neuron chip, and only the specific
matching destination device identified will processes the data when it is received on the bus.

One-to-many data transfer requires address entries in BOTH the source device (NVO) and ALL
of the destination devices (NVIs). The data packet includes a SINGLE broadcast group identifier
(NOT a specific list of all of the multiple reciepents). Using a group identifier, when the source
data message is broadcast across the entire bus, ANY and ALL devices that have the same
specific group identified process the data. This is akin to a CB radio broadcast where the
transmitter has to have a selected channel to broadcast on, and all of the receiving devices must
also have the identical channel selected to receive the data.

Note: when a NVO from a source controller is linked to BOTH a field device NVI AND is also
represented in the JACE database via a PROXY point, it is, by definition, a one-to-many data
transfer, meaning both the JACE and ALL of the destination devices (with NVIs) will require an
address table entry for the group identifier!

Real-world implications for peer-to-peer communication between more than 15 devices:

When NVOs from multiple field devices are to be sent to a single field device (as in processing
terminal loads from multiple VAV boxes in a single AHU controller), it is best to create/utilize a
single NVO from the source controller and a single NVI in the receiving controller for each data
point. If the NVO data is also required as a proxy point, then it is recommended to create a new
NVO in the receiving device to echo the original NVO's data. (for example, received terminal
load "nvoTermLoadRcvd").

The new NVO will require an address entry for the JACE, but that address entry should already
be in the address table for any other proxy points in the AHU controller. This new nvo should be
linked internally to the NVI input for data transfer. The added advantage here is that the actual
received data is available as a proxy point.

(See the examples on the last page of this document)

If this is not done, and the VAV's terminal load is linked to both an AHU controller AND is
exposed as a proxy point, then the data address is processed as a group, filling the AHU
controller's address table with group identifiers for each separate VAV controller, quickly filling
up the 15 available slots and resulting in link errors.
Many To One Example

One To Many Group Broadcast Example