Home > Support > Product Documentation

Echelon Product Alerts

ID# 1019	Single point monitoring cannot create implicit network variable connections on LNS® 3.07 or later

Date
January 29, 2004

Products Affected
This alert affects LNS applications that use single point monitoring and request implicitly-connected, event-driven network variable updates, when running on top of LNS 3.07 or later. A PC is running LNS 3.07 or later if an LNS application installation program installed the LNS Server redistribution v3.07 or later, or if the end-user applied LNS 3 Service Pack 7 (SP7) or later to a prior revision of the installed v3.0x LNS Server redistribution. Many popular Echelon and third-party LNS based tools include the LNS Server redistribution; for instance, Echelon's LonMakerT Integration Tool and LNS DDE Server products include the LNS Server redistribution.

Summary
In certain instances, LNS will poll a network variable even though the LNS application has requested that an implicit connection be created to get event-driven updates. Note that this problem does not occur when using monitor point monitoring (the preferred monitoring method that debuted in LNS 3). For definitions and explanations of the terms single point monitoring and monitor point monitoring, see the LNS for Windows Programmer's Guide (078-0177-01) available from http://www.echelon.com/support/documentation/Manuals/.

Because this problem occurs only under a specific set of conditions, the conditions will be described below as a set of If/Then statements. Note that all of the If statements must be true in order for the problem to occur:

If an LNS application employs the single point monitoring technique in order to monitor an output network variable on a LonWorks® device,
     - and -
If the DsUseBoundUpdates property of the NetworkVariable object to be monitored is set to True,
     - and -
If a network variable connection does not pre-exist between the output network variable on the LonWorks device and the LNS host where the LNS application is running,
     - and -
If this is not the first implicit network variable connection to be created on the LNS host where the LNS application is running

Then LNS will fail to create the required network variable connection that is needed to receive event-driven updates, and thus will poll the network variable.

The request to create an implicit network variable connection is designed to fail silently, and to revert to polling. When an LNS application runs on LNS 3.07 or later, the implicit network variable connection will fail every time except for the first time. This silent failure to implicitly create network variable connections may not be noticed until the number of network variables that is polled grows to the point of LonWorks channel saturation. LonWorks channel saturation can occur much more quickly when using an LNS High Performance Network Interface, such as the PCC-10 PC Card Adapter, PCLTA-10 PC LonTalk Adapter, PCLTA-20 LonTalk Adapter, i.LON® 600 Internet Server or i.LON 1000 Internet Server.

Note that this problem is not a general problem with the LNS component that creates network variable connections between devices or between devices and the LNS host(s).

Note that this problem does not affect an LNS application that explicitly creates the network variable connections into the LNS host, in the instances where single point monitoring is being employed.

Note also that this problem does not affect an LNS application that is using monitor point monitoring, even if the LNS application requests LNS to implicitly create a network variable connection for the monitor point.

Thus the workarounds below take advantage of these noted facts, so that polling is avoided in the cases where an application desires event-driven updates.

Workaround
The following workarounds are offered:

Explicitly create the network variable connections with a network management tool.

This workaround does not require the modification of the monitoring application; however a network management tool, such as the LonMaker Integration Tool, must be used to create the desired network variable connections.

After making the network variable connections, re-start the monitoring application. Since network variable connections now exist, the implicit network variable connection problem is eliminated-LNS will rely on event-driven updates from the network variable connections-and thus won't poll the network variable, except initially, if the monitoring application asks for an initial value. Explicit creation of the network variable connections offers the following advantages:

Known connection topology. The LNS application can be absolutely certain at the time of the network variable connection request as to whether or not the connection was created.
LNS application control over connection properties such as service type, alias, and group connection settings.
Optimization of network variable connections to optimize for application performance and network traffic reduction.
Improved scalability such that a greater number of network variable connections may be made to the LNS host.

Modify the monitoring application to use monitor point monitoring.

This workaround does require a modification of the monitoring application.

There are numerous feature and performance advantages of monitor point monitoring when compared to single point monitoring. Echelon highly recommends that application developers move to monitor point monitoring whenever an application is modified in the monitoring code area.
Modify the monitoring application to explicitly create the network variable connections.

This workaround requires a modification of the monitoring application. Note that this works around the problem with single point monitoring, but does not take advantage of the numerous feature and performance advantages of moving to monitor point monitoring.

After the monitoring application is modified, this workaround is similar to the first workaround above. Since the monitoring application will create network variable connections if they do not exist, the implicit network variable connection problem is eliminated-LNS will rely on event-driven updates from the network variable connections-and thus won't poll the network variable, except initially, if the monitoring application asks for an initial value. The advantages of explicit creation of the network variable connections by the monitoring application are the same as those listed in the first workaround above.

Resolution
Echelon plans to fix the underlying problem with single point monitoring in a future LNS Server redistribution release. This will solve the problem for Echelon and third-party produced products that include and install the fixed LNS Server redistribution.

If you have a question about which of the workarounds is most appropriate for you, contact Echelon Support at www.echelon.com/support. Echelon's LonSupportT Services offer a combination of annual fee-based and free email support.