Tridium - The Application of EC-NetAX in an LNS Based System

The Application of EC-NetAX in an LNS Based System


The EC-NetAX system is well known for its versatility and flexibility in managing a variety of control products and protocols. This flexibility can even be extended to the application of the EC-Net system on an LNS Network. This combination of the EC-Net System on an LNS network provides the power and enhanced features the EC-Net multi-protocol web based platform is known for while maintaining conformance with LNS based specifications. The following document describes how to implement the EC-Net System in an LNS environment while maintaining the integrity of the LNS database.
Any EC-NetAX “device” with a LonWorks interface can be used as a simple LonWorks node. This is the basic idea that will be used in this LNS/EC-Net system. There are a few things that need to be observed when doing this to ensure that the network is only managed by the LNS system and not by EC-NetAX.
The recommended procedure is to commission all nodes and create all bindings using a LNS network management tool. Even if there are other devices on the network that are not required in the LNS system, by commissioning them within EC-NetAX they will be addressing a second network manager (being the EC-BOS) and this could cause minor network issues (or complicate greater issues) on the same channel. As such in order to maintain the integrity of the LNS database, EC-Net Pro is not to be used as a Network Management tool.
Essentially there are two methods to correctly create this type of network. The first technique while requiring a few less procedures can be difficult to maintain in the long run and is also the most likely to cause issues on the network if strict rules are not followed. The second and preferred method discussed here, while requiring a few more procedures initially, ensures the most logical arrangement on the LonWorks network of EC-Net Components and the LNS database. Either way will allow the EC-NetAX’s enhanced functionality to coexist in an LNS-managed environment, including all trending, scheduling, alarming, and user interface abilities.
Method 1: Discovery and Polling
One way of using EC-NetAX in an LNS environment is to create the LNS network and then “discover” the network in the EC-BOS. It is important to note there that once the network has been discovered you should NOT commission any of the devices that are discovered. They can still be dropped into the LonNetwork folder, which will allow the EC-BOS the ability to work with the data presented by these devices, but by commissioning them, their links in the LNS database will be severed.
Once the previously created LNS network has been discovered by EC-NetAX and the targeted devices added to the LonNetwork folder, the points from these nodes can also be discovered and the data utilized in the normal manner for an EC-NetAX system. However, if any device is replaced in the LNS network, it will have to be re-discovered by EC-NetAX and the specific logic and settings that reside within the EC-BOS will have to be reapplied as well.
It is also important to note that if there are any changes to the LNS network relevant to the specific nodes being monitored by the EC-NetAX system, then these devices will also have to be rediscovered and re-setup.
If any new device is added to the LNS network that would also be manipulated by logic or trended from within the EC-BOS, this too can be discovered after the initial setup and configured the same as previously done for the other devices.
Any node configured in this way will remain in the LNS network database and therefore will be able to be manipulated from LNS in any manner that would have been possible in a tradition network configuration. This device will also be able to be manipulated by the EC-NetAX system by way of direct polling. For devices with critical update requirements this method is not recommended as the node itself does not know of the existence of the EC-BOS and will not send any network variable updates without being polled by the EC-BOS, and this poll time may not be fast enough to accommodate critical response times.
If any configuration properties (CPs, SCPTs or UCPTs) are modified on any LNS node by EC-NetAX, these changes will not be reflected within the LNS database without the device’s configuration being manually read. The same is true in reverse, where the EC-BOS will not be aware of any configuration property changes that are made by the LNS system. It is highly recommended that, in this 05DI-TECH205-10 Distech Controls, Inc.
Tel. toll-free North America: 1-800-404-0043
Tel. international: 1-450-444-9898
05DI-TECH205-10 Distech Controls, Inc.
Tel. toll-free North America: 1-800-404-0043
Tel. international: 1-450-444-9898
configuration, EC-NetAX is never used to read or modify any configuration properties from any LNS node.
Method 2: Using the EC-BOS as a Node
The preferred method of setting up this LNS/EC-NetAX system is to treat the EC-BOS like any other generic LonWorks node. This technique is recommended as the preferred way to use an EC-NetAX device in an LNS environment as it will help insure that the integrity of the LNS database is maintained. It does initially require a few more procedures and requires more knowledge of each individual device in the LNS system.
In any EC-BOS with a LonWorks interface, local network variables can be created that are visible externally to any other LonWorks network management device or node. However, when creating network variable in an EC-BOS for the intended ability to be linked to network variables in other nodes, it is important that identical Standard Network Variable Types (SNVTs) be created or this binding will not be able to be created. For convenience, the EC-BOS can be physically placed on the correct LonWorks channel, and the intended binding targets can be discovered and studied so as to create the correct type of local SNVT but if this is done, be sure to delete the discovered devices when finished to avoid accidentally polling the same device.
Once all of the desired local SNVTs have been created, add the EC-BOS to the LNS network using the LNS network management tool and it will “see” these created network variables. They can then be bound to other network variables in the standard way. From within the EC-NetAX Framework these same SNVTs can be read and written to in any typical manner without worrying about affecting their association with the LNS system.
When new devices that are intended for use with the EC-BOS are added to the LNS database, more local SNVTs must be created in the EC-BOS. If new network variables are created then the EC-BOS must be re-learned into the LNS network as its external interface has been changed. Once this is done the EC-BOS needs to be deleted from the database and its device profile be removed. Then it can be re-added and re-learned with the new network variables included and then all bindings can be replaced. This recommended procedure will result in improved integrity of the LNS/EC-NetAX network.
Whichever method is chosen should successfully combine the EC-NetAX with the LNS database allowing the advanced front-end capabilities of EC-NetAX framework to be used with the stable database design of LNS. All of the data being brought in through the network variable bindings can be logged, manipulated, alarmed, and scheduled, and the resulting data can be sent back out through the EC-NetAX device.
Running Plugins Versus Wizards
With devices residing on two systems in this manner, it is technically feasible to run both LNS Plugins and EC-Net Wizards to set up and configure the same device. That being said, it is important to note that running the configuration tool on one system will not update the database of the other, so there will be a need to manually synchronize the device with the other network tool. In EC-NetAX this can be done by simply performing an “upload” action on the device(s) that have been (re)configured in LNS. If they were configured in EC-NetAX then perform a configuration property resync in the LNS tool. It is important that this resynchronization is done as soon as possible after (re)configuration to prevent accidental corruption of the database. The risk of this corruption is much less in EC-NetAX so it is advised that LNS is used to (re)configure the device as opposed to EC-NetAX.
A Special Note on Using WebSupervisor Stations
From the viewpoint of an EC-Net Supervisor, it is not important where the device data originated from. Since the EC-Net Supervisor is communicating to the EC-BOS’s directly, the data that resides inside them has already been converted to EC-NetAX objects. This also means that a WebSupervisor, connecting to multiple EC-BOS’s can display and manipulate data from many different network topologies and protocols. Perhaps one EC-BOS is monitoring an LNS-based LonWorks system, and another EC-BOS is connected to BACnet devices. Of course the same EC-BOS also has the ability to handle multiple protocols simultaneously. All device-level integration (including integration to an LNS-based network) is handled at the EC-BOS level only.
Note: All system Integration work has its unique challenges and the application of the EC-Net system with and LNS database is no exception. While Distech Controls provides this Technical Tip as a service to our customers we cannot accept any responsibility for any difficulties that the System Integrator may encounter when implementing the procedures described within this document. As such the degree to which Distech Controls can provide support for a LNS/EC-Net implementation will be limited to the controller level functionality only.
This tech-note is intended to provide general technical information on a particular subject or subjects and is not an exhaustive treatment of such subjects. Accordingly, the information in this web site is not intended to constitute application, design, software or other professional engineering advice or services.
Distech Controls does not warrant the completeness, timeliness or accuracy of any of the data contained in this web site and may make changes at any time in its sole discretion without notice.

Configure an Ax station to be managed by an LNS database.

Niagara LonNetwork database requirements to properly configure an Ax Station to be managed by an LNS database.

For a Niagara station to properly function in an LNS database the proper self-documentation must be setup in the station database. The device "Self Doc" string property on the LocalLonDevice must be setup to include all LonMark objects that will be used in the station. If you wish to omit the device self-documentation string you can just type an asterisk into the "Self Doc" property. If self-documentation is supplied it must comply with the format described in The LonMark Interoperability Guidelines.

The syntax for the device self-documentation:

The ampersand ("&") prefix denotes an interoperable device.
3.0 identifies the major and minor version the station device implements.
An at-symbol ("@") is used as a seperator.
The functional profile numbers are listed in order of the corresponding functional-block index 0, 1, 2, etc.
The node object must be the first of the indices (0).
NodeObjectName is the description of the node object (0).
FunctionalBlock includes any other LonMark or non-LonMark functional profiles that you wish to add to the station database.
selfDocText is any text that you might want to add that describes the functional profiles.


&3.0@0NodeObject;Niagara Server Node

The node object (0) has two mandatory network variables, SNVT_obj_request and SNVT_obj_status. Network variables are created on the LocalLonDevice "Local Nv Manager" view.

Select new from the "Local Nv Manager" and add the following network variables:

The ampersand ("&") prefix denotes an interoperable device.
Name Direction SnvtType
nviRequest Input Snvt Obj Request
nvoStatus Output Snvt Obj Status

Now that you have created the two mandatory network variables for the node functional block you must setup the network variable self-documentation. From the properties of each newly created network variable assign the "Self Doc" string per The LonMark Interoperability Guidelines. If you wish to omit the network variable self-documentation string you can just type an asterisk into the "Self Doc" property.

The syntax for the network variable self-documentation:

"@" is used to denote the start of NV self-documentation.
fbIndex is the functional block index.
"|" is the functional profile seperator.
memberNum is the member number within the functional block.
text is optional for describing the NV.



Add Feedback