LonWorks Tutorial from Control Solutions

LonWorks®
A Bird's Eye View

LonWorks is a building automation protocol created by Echelon Corporation in 1989. The two most commonly used physical layers are “Free Topology” which is a 78K baud twisted pair, and LonWorks IP tunneling over Ethernet. The protocol is now known as the standard ISO/IEC 14908.

LonWorks is a peer-to-peer network, meaning there is no single master on the network. Control devices are free to communicate directly with each other, avoiding some of the problems that can occur if a single master fails. Addressing is most often made known to all devices on the network through a process known as “binding”, and this process is carried out at network commissioning time using a network management tool such as Echelon’s LonMaker.

LonWorks devices most often communicate by sending messages containing network variable updates. A network variable is a data element that may consist of a single number, somewhat analogous to the Modbus register. However, a network variable may also contain a collection of data, which would be analogous to a set of multiple Modbus registers. Even though the variable is a collection of data, it is still considered a single “variable”. (If you are a C programmer, network variables with multiple pieces of data are defined as a typedef struct.)

Protocols like Modbus have a very limited set of data types, most often just signed or unsigned 16-bit integer. LonWorks, on the other hand, has over 170 different data types. Not only are values defined in terms of signed or unsigned, and 8 or 16 bits, floating point, etc, but also defined in terms of whether the variable contains temperature data, pressure or humidity data, etc. Most data types, except floating point, are scaled according to the Standard Network Variable Type definitions.

Why is it so complicated?

We'll start with the question we get most often. People who have become accustomed to Control Solutions' Modbus configuration tools being easy to use often wonder why the LonWorks tools seem so much more complicated. Compared to the Modbus tools, we went to even greater lengths to make the LonWorks tools as easy to use as possible. The fact remains, LonWorks is simply a more complicated protocol than Modbus.

The most frequently used data point in Modbus is a holding register. It contains a number, and it is up to you to know what that number means, and whether it is scaled. The same holding register can contain a voltage reading, temperature, pressure, etc. The same holding register might be scaled x10, x100, etc. LonWorks, on the other hand, has close to 200 different types of data points referred to as Network Variables. Each variable has only one standardized use, and only one standardized data scaling. A voltage variable is always, and only, a voltage variable, and its scaling is always the same regardless of who manufactured the equipment using it. When binding LonWorks devices to each other, a voltage variable can only be bound to another voltage variable. The same applies to temperature variables, pressure variables, and so on.

The fact that LonWorks is peer to peer communication protocol, and normally does not use any polling scheme, requires additional configuration of each device so that they know how to send data to each other. This configuration normally happens in the "binding" process.

When you take on the project of connecting Modbus to LonWorks, your generic holding register needs to know what type of Network Variable is on the LonWorks end. Your Modbus gateway also needs to somehow get acquainted with the configuration that otherwise happens in the binding process. Network management tools used to bind LonWorks devices to other LonWorks devices ultimately make that process easy as a result of the "complicated" stuff hidden inside each device. When you need to connect LonWorks devices to a non-LonWorks network (or vice versa), then you have to take on some of the responsibility for dealing with that same "complicated" stuff inside.

What is LonWorks?

Echelon's mission in developing LonWorks was to develop a commodity solution to the problems of designing and building control networks. The term LON stands for Local Operating Network, defined as groups of intelligent, independent products (nodes) using a variety of communication media to implement sense & control systems.

Each LonWorks node includes local processing and I/O to process input data from sensors, handle control of actuators, and interact with other devices. Each node also includes the capability to communicate with other nodes because it contains the LonTalk protocol in firmware. The LonTalk protocol is a 7-layer communications protocol which ensures that nodes can inter-operate using an efficient and reliable communications standard. The LonTalk protocol provides an open architecture; the tools, modules, and ICs are readily available for embedding LonTalk into any product.

What is LonTalk Protocol?

The LonTalk protocol supports inter-operability at the node and product levels using the 7-layer OSI Reference Model for network protocols. LonTalk includes four standard message delivery services and a variety of access levels to meet specialized requirements.

LonTalk is optimized for control applications, emphasizing reliability and response time over data rate. Control systems incorporating a network of sensors and actuators do not need to transfer large volumes of data, but do need quick and reliable response. Therefore, LonTalk is optimized for short messages (12 bytes typical, 250 bytes possible). LonTalk is also optimized for low node and network support costs.

What is a Neuron Chip?

The Neuron chip is a sophisticated VLSI device that incorporates communications, control, scheduling, and I/O support. The Neuron chip is a symmetric multiprocessor with the LonTalk protocol firmware and basic network communication interfaces built in. Application I/O interfaces and a real-time operating system executive are also built in. CMOS, EEPROM, and analog technologies are integrated in a low cost implementation. The Neuron is designed to be a "system on a chip", and many applications will require only a Neuron chip for system hardware.

What is a LonWorks Transceiver?

The Neuron chips may communicate with each other using any of several transceiver technologies. The transceiver is the physical line driver and receiver. The most widely used transceiver for LonWorks is the TP/FT-10 (FTT-10) Free Topology transceiver.

TP/FT-10 is a twisted pair communications at 78kbps with distances to 2700 meters in a doubly terminated bus topology. The TP/FT-10 also supports free-topology wiring to 500 meters which eliminates the need to install an exact multi-drop arrangement. Star, home run, multi-drop, and loop wiring, or any combination, are supported by the TP/FT-10.

What is Neuron C?

LonWorks is more than just a very robust communications protocol. The Neuron C programming language includes features that support and enhance development of control systems. An event driven operating system is integrated into the language. Communications features are built in. Software timers are supported as an integral part of the programming environment. There are over 30 different I/O models supported by software for operation of the Neuron chip's I/O lines.

Where do I find data type or format information for a manufacturer’s device?

This information is contained in something called an XIF file. There is a copy of this file contained within any LonWorks device, and it is extracted automatically by network management tools such as Echelon's LonMaker. It is available on the LonMark web site (www.lonmark.org) for any LonMark certified product. It is generally available from the manufacturer of the device.

Where do I find a definition of SNVT’s?

This information is available from LonMark (www.lonmark.org). Download the collection of information known as "resource files".

How do I put a non-LonWorks device on a LonWorks network or vice versa?

Control Solutions offers several gateways that accomplish this for certain configurations. Refer to the Gateways page for more information about available gateways.

Can I use a gateway to just listen to data on a LonWorks network?

No. Only a protocol analyzer can just "listen" to all traffic on the network.

Can I just add a gateway to a LonWorks network?

All devices on a LonWorks network must be "bound" to each other. A gateway device will only receive data from devices it is bound to. The only exception, found only in certain Control Solutions gateways, is when the gateway periodically and explicitly polls other devices. Even then, some sort of commissioning process is needed to inform the gateway of the network addresses of the other devices.

It is important to understand here whether you are contemplating adding a gateway to a LonWorks network, or adding a LonWorks device to a non-LonWorks network. If the network is LonWorks, then you will need to engage in the proper network commissioning of the LonWorks network, including binding the network variables found in the gateway. However, if you need to access a LonWorks device without being a participant on the LonWorks network, then you would use the -NB (non-bound) version of Control Solutions gateways. These gateways provide the means of attaching legacy LonWorks equipment to either BACnet or Modbus networks.

How do I bind Network Variables?

You need to use a network management tool such as Echelon's LonMaker, or any equivalent tool that knows how to write address tables and other configuration tables in the LonWorks device. In addition to performing the configuration update process, the tool keeps track of the connection database that defines the logical connections between all of the devices on the network.

Glossary of common LonWorks terms:

SNVT - This is the acronym for Standard Network Variable Type. There are over 170 different data types defined for LonWorks protocol. Data type defines size in bytes, format such as signed integer versus floating point, and in many cases defines a structure of multiple pieces of data within a single entity referred to as a variable.

NV - A Network Variable (NV) is the most commonly used and only standardized method of exchanging data between LonWorks devices. Normally the NV will be automatically propagated over the network by the originating device any time its value changes.

LON - Stands for Local Operating Network. LON and LonWorks are trademarks of Echelon Corporation.

Binding - This is the process of “connecting” network variable sources to destinations so that the automatically propagated network variables will reach the intended destinations. This process largely consists of making address table entries in the various devices.

LonMaker - Echelon’s network management tool used to do the process of binding along with other house keeping involved in commissioning a network.

XIF - An acronym used to denote “standard program interface”, and is the definition of the network variables contained within a device. This is effectively the “road map” telling you how to connect to this device.

SCPT - Stands for Standard Configuration Property Type. Each network variable is required by LonMark standards to have several configuration properties associated with it. These properties further define behavior of the variable, such as a maximum rate at which it may be transmitted on the network, etc.

Function Block - A logical association between an application level function, and one or more network variables and confiburation properties. A function block may be a simple sensor, or may be an HVAC controller, for example.

Echelon, LON, LonWorks, LonMark, LonBuilder, NodeBuilder, LonManager, LonTalk, LonUsers, LonPoint, Digital Home, Neuron, 3120, 3150, LNS, i.LON, LonWorld, ShortStack, the Echelon logo, and the LonUsers logo are trademarks of Echelon Corporation registered in the United States and other countries. LonLink, LonResponse, LonSupport, LONews, LonMaker, Panoramix, Open Systems Alliance, OpenLDV, Powered by Echelon, LNS Powered by Echelon, Panoramix Powered by Echelon, LonWorks Powered by Echelon, and Networked Energy Services Powered by Echelon are trademarks of Echelon Corporation. Other trademarks belong to their respective holders.