The Lon Link Manager view of the LonNetwork (Figure 25) is where you can review/manage the bindings of network variables. As the Niagara station is (typically) “the network manager” of the Lonworks network, you often use this view.
See the following additional Lon Link Manager sections for more details:
The Lon Link Manager has two separate tabs, where each provides a table-based view:
-
NetworkVariableLinks — the default tab, used to review and manage links/bindings between network variables.
-
MessageTagLinks — to manage bindings between “message in” and “message out” tags of Lon devices (if any devices are used this way).
NetworkVariableLinks is the default display tab in the Lon Link Manager. Often, this is the only tab you use in this view.
As shown in Figure 26, each row in this view represents either:
-
A connection between the station (LocalDev) and a specific nv (nvi or nvo) in a Lon device. Each rows corresponds to a particular Lon proxy point.
Proxy points for ncis, cps, and “read-only” nvi proxy points are not included.
-
A Lonworks nv binding directly between two other Lon devices. On each end, the binding is modeled in the station as a “graphical” connection (link) visible on the devices’ glyph (shape). See About the LonNetwork wire sheet.
Data columns provide the current information about each link/binding.
The NetworkVariableLinks tab of the Lon Link Manager provides two checkboxes in the lower left of the view (see Figure 26). These filter (hide) links from the view as follows:
-
Hide Proxy Links — Hides links from or to proxy points (LocalDev) from the view.
-
Hide Net Links — Hides links between other Lon devices/controllers from the view.
The MessageTagLinks tab (Figure 25) is available in the Lon Link Manager, although not typically used. Generally, Lonworks nodes use network variables to exchange data.
In some cases, applications require a different data interpretation model than that provided by network variables. In these
cases, nodes construct individual messages and assign them an address. These are referred to as explicit messages, and nodes can use logical input and output ports (message tags) to send and receive these messages.
All LonMark-certified nodes contain a “message-in” tag, which can be used to receive messages. In addition, nodes can declare bi-directional message tags that can be used to both send and receive messages. If message tags bindings are used, the Lon Link Manager displays their status in a fashion similar to that used to display network variable bindings.
Data columns in MessageTagLinks table provide the current information about each message tag link.
Data columns in both Lon Link Manager tables are predefined, using different NetworkVariableLink columns and MessageTagLink columns. As needed, you can click on table column headers to resort the table, and click and drag to resize column widths.
In the NetworkVariableLinks table, the following data columns appear, from left-to-right:
-
selector
Niagara selector number used to reference an individual network variable, stored in a table within the local Neuron chip. By default, the table is sorted by selector, ascending (1, 2, 3, so on).
-
linkStatus
Current status of each link, for example “Bound,” “New Link,” and so on. For details, see linkStatus.
-
srcDevice
Niagara name for the source Lon device, meaning output side of the link/binding. Any entry with “LocalDev” indicates a Lon proxy point for an nvi in the targetDevice.
-
srcNv
Niagara name of either:
-
LonComponent (nvo) under srcDevice, providing srcDevice is not LocalDev.
-
Lon proxy point for nvi in targetDevice, if srcDevice is LocalDev.
-
-
targetDevice
Niagara name for the target Lon device, meaning input side of the link/binding. Any entry with “LocalDev” indicates a Lon proxy point for an nvo in the srcDevice.
-
targetNv
Niagara name of either:
-
LonComponent (nvi) under targetDevice, providing targetDevice is not LocalDev.
-
Lon proxy point for nvo in srcDevice, if targetDevice is LocalDev.
-
-
linkType
Reflects the assigned Lonworks service type of the link (if bound). By default, new links use the “Standard” service type. You can selectively change the service type for any number of selected entries in this table, using the Set Service Type button. See Lon Link Manager commands for more details.
In the MessageTagLinks table, the following data columns appear, from left-to-right:
-
linkStatus
Current status of each message link, for example “Bound,” “New Link,” and so on. For more details, see linkStatus.
-
outputDevice
Niagara name for the source Lon device, meaning device with the message-out tag.
-
outputTag
Niagara name for the message tag in outputDevice.
-
inputDevice
Niagara name for the target Lon device, meaning device with the message-in tag.
-
inputTag
Niagara name for the message tag in inputDevice.
Two commands are “global,” whereas the other two (Selective Bind, Set Service Type) require you to select (click) entries in the table. Note that source nvs using structured data are not individually selectable—if you select one element in a nv’s structure, any other element entries (e.g., proxy points for the same nv) are also automatically selected.
At the bottom of the Lon Link Manager view (Figure 28) are four command buttons.
Commands Refresh, Bind, Selective Bind, and Set Service Type are described as follows:
Globally polls the status of the bindings on the network and displays that information in the table. See linkStatus. If unbound (deleted) links were previously listed, those entries are removed from the table.
A “global command” to establish nv bindings for all entries, per the “linkType” (service type) specified for each entry. The button remains available regardless if you any items selected. When you click it, a global “Lon Bind job” is performed, with standard station job visibility. To bind only selected items, use instead.
Selective Bind is enabled only when you have one or more items selected in the table. Use it to establish nv bindings only for those selected entries, per the “linkType” (service type) specified in each entry. When you click it, a “Lon Bind” job is performed, with standard station Job visibility. To globally bind all entries, use the button instead.
Set Service Type is enabled only when you have one or more items selected in the NetworkVariableLinks table. This allows you to set the LonTalk message service type, controlling parameters used for the next bind. When you click it, a popup dialog (Figure 29) provides a drop-down selection of message service types to use. Or, you can select “Poll Only”—this sets nvs to an unbound state.
Selections “Standard, Reliable, Critical, Authenticated” set parameters per settings in the LonNetwork’s LonNetmgmt “Link Descriptors,” where timers are applied to the address table entry used for the link. Other parameters are applied to the Nv ConfigData on nvs (output side of the link).
Also, a Priority checkbox is available. If you enable (check) this in combination with any of the message service types, upon a bind, the Priority flag is set in the nv’s Nv Config Data.
Assigned message service type displays in the far-right “linkType” column in the Lon Link Manager. See NetworkVariableLink columns.
If a link is already bound and you change it to another message service type, its linkStatus changes to “NewLink” until you (or ) it again.
The four LonTalk message service types available for a nv binding can described as follows:
-
Standard
(unacknowledged) is the least reliable, yet often most widely-used. This is the default service type for a Niagara binding. With this service, the message is sent one time and no response is expected. This service is typically used when the highest level of network performance is needed, network bandwidth is limited, and the application is not sensitive to the loss of messages.
-
Reliable
(unacknowledged/repeated) is recommended for messaging that has been classified as important—if there is a specific need to know that a status has changed. Reliable messaging sends a message three times. The srcDevice sends each message three times, and if the targetDevice receives the message, it simply throws subsequent messages away.
-
Critical
(acknowledged) means that the targetDevice must acknowledge the fact that it received a message. The srcDevice continues to send the message until the targetDevice acknowledges receipt of that message. You are limited to the number of bindings that can be defined as critical, because it taxes the system, and often causes communications issues (by loading down the network with message verification traffic).
-
Authenticated
is a security service reserved for secure messaging. When using authentication, the srcDevice must identify itself to the targetDevice, and vice-versa. This service is rarely used, and only in instances where messaging must be secure.
Each link/binding in the Lon Link Manager appears with a status in the second column, “linkStatus.” Typically, link status is one of the following values (assuming no error status):
-
NewLink
Appears for either of the following:
-
Proxy point was added, yet command (or for it) has not been given.
-
A link was created between two nodes, yet the command (or for it) has not been given.
Until bound, entries do not exist in the address tables of the nodes, and polling is used exclusively. Following a or command, link status should change to “Bound.” For more details on these commands, see Lon Link Manager commands.
-
-
Bound
Reflects a Lonworks binding established between two network variables/nodes. If Quik Learn was used to learn links in an existing (managed) network, learned links will appear as bound. In addition, following a Bind command, all entries for Lon proxy points will also list as bound.
-
Poll Only
Appears whenever you have Set Service Type to “Poll Only.” Upon the next command, nvs are set to unbound state.
-
Obsolete
Appears for either of the following:
-
Any proxy point (that was formerly bound) that was deleted.
-
A bound link between two nodes that was deleted.
In either case, the address tables in both nodes have not yet been updated—entries still exist. Use the command to change these Obsolete entries to Unbound.
-
-
Unbound
Appears for obsolete links following a command, just to verify that the link has been deleted. To remove these entries (rows) entirely, click the command button.
In some cases, a link/binding may appear in the Lon Link Manager showing an error-type linkStatus, as one of the following types:
-
AliasError — One or more connections have been made which require the use of alias nvs when none or insufficient aliases are available. Delete links and bind to remove error.
-
AuthicateError — Authentication error. Check the messaging service type for the network variable linkage.
-
ComError — Communications error occurred during the bind operation (for example, timeouts). Try binding the network variables again. If errors persist, check communications.
-
DeviceError — Device error. The state of the node will not support a network variable binding.
-
DirtyGroup — Typically means an address table problem. Usually, a second pass at a bind will clear things up.
-
DirtyPoll — An existing group has been disrupted by commissioning or removal of one of its member devices. Bind to reassign groups.
-
Error — An error apart from one of the other specified error types.
-
GroupError — Unable to assign the node to a group. A node can belong to 15 different groups (up to 15 address table entries) when acknowledged messaging service is used. To correct, either reduce the number of address table entries, or adopt unacknowledged/repeated messaging service.
-
GroupExcludeError — A set of connections has been created for which no set of groups can be assigned that meet all group assignment rules. Delete links and bind to remove error.
-
NvTypeError — SNVT types do not match. Either the Lon xml (lnml) file is not appropriate for the node, or (if Learn NvLearn Nv was used) the node’s self-documentation does not properly represent the actual data stored in that device. Obtain an up-to-date lnml file for the device, or use Learn Nv.
-
MaxCritError — Too many targets (bindings or linkages) are made to use the critical messaging service. Reduce the number of bindings or adopt a non-critical messaging service.
-
PriorityError — The priority setting of the link cannot be legally accommodated (that is, priority is selected but nv is not priority, and priority is not configurable).
-
ServiceTypeError — Message service type mismatch. The assigned message service type (linkType) does not match the actual service type found in the node.