Click here to return to Avalon Engineering Electronic Design Services home page.
Avalon Engineering is a LonWorks Independent Developer.

A word to design engineers: Our job at Avalon Engineering is not to take over your job. We're here to help you when you've got too much to do and too little time to do it.

One way we help other engineers is by working as part of your design team up front. We get you up to speed on new technology, and then let you run with it. In the long run, we will save you some headaches, save your boss some money, and together get the job done faster.

Avalon Engineering electronic design services include LonMark certification support.

A LonWorks Primer for Design Engineers

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. Local Operating Networks (LONs) provide:

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.

The elements of the LonWorks technology include the LonTalk protocol, the Neuron chips, LonWorks transceivers, and the LonBuilder Developer's Workbench. The Neuron chips, developed by Echelon, are produced by semiconductor giants Motorola and Toshiba. Echelon produces transceivers, the LonBuilder developer's workbench, and various software and board level OEM products.

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.

The LonTalk protocol provides the following features and benefits:

Inter-operability is supported by the LonTalk protocol which conforms to the 7-layer OSI Reference Model for communications. In order to achieve inter-operability, a few simple guidelines need to be followed at the physical and application layers of the protocol. Consistency at layers 2 through 6 is achieved by using the LonTalk protocol embedded in the Neuron chip firmware. Consistency at the application layer is facilitated through the use of Standard Network Variable Types (SNVTs) and LonMark functional profiles, which are standardized by the LonMark Inter-operability Association.

A network variable is a data object on one node that can be accessed by one or more additional nodes. A node's network variables define its inputs and outputs from a network point of view and allow the sharing of data in a distributed application. Whenever the application program running on a given node writes into one of its output network variables, the new value is propagated across the network to all nodes with input network variables connected to that output variable. This is done automatically by the LonTalk protocol, therefore explicit messages across the network do not have to be generated by the application.

The 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.

The Neuron chip minimizes application overhead for network communications and improves response to network events with 2 CPUs dedicated to network communications. (The third CPU is dedicated to running the application.) The Neuron provides a low-cost interface to a variety of I/O devices, including dual slope A/D converters, triacs, voltage to frequency converters, and shaft encoders. The Neuron can decode input from infrared controllers, and read input data from ISO 7811 compatible magnetic card readers. The Neuron can interface via its Neurowire input/output with any device using a Motorola SPI or National Microwire compatible serial interface. Asynchronous serial input/output (e.g., RS-232) is possible. The Neuron can also interface to other processors via a parallel bus interface, making the Neuron a high performance network communications coprocessor. Over 30 different types of I/O models are supported using the 11 programmable I/O pins of the Neuron chip.

There are currently two base models of Neuron chips, the 3120 and 3150. Both include three 8-bit pipelined CPUs, at least 512 bytes of EEPROM, two 16-bit hardware timer/counters, and the 11 programmable I/O pins. The 3120 includes 1K or 4K of static RAM, 512 to 8192 bytes EEPROM, and masked ROM with the LonTalk protocol and system firmware embedded. The 3150 includes 2K of static RAM, and an external memory interface allowing up to 56K of Flash EPROM. The external memory address space may also include additional EEPROM, RAM, or memory mapped I/O.

The Neuron chip's interface to the network is via its 5-pin programmable network communications port. This port enables the Neuron to be used with a variety of transceivers, including twisted pair, power line, radio frequency, fiber optic, coax, and infrared. The port includes a built-in transceiver for a direct-connect twisted pair network, and can operate at 610bps to 1.25Mbps. Packet collision detection is supported by the Neuron Chip when supported by the physical media.

Each Neuron contains a unique 48-bit ID. No two Neurons will ever have the same ID, and this ID is used to uniquely identify the node on the network. The service pin is used to cause the Neuron to transmit a message over the network containing its ID. The network management tool then uses this message to communicate with the node and install it in the network. Once installed, communication by group or other logical address is possible.

LonWorks® Transceivers

The Neuron chips may communicate with each other using their built-in transceivers within a limited range. Standard, inexpensive EIA-485 transceivers may be used over twisted pair installed according to EIA-485 guidelines. The open architecture of LonWorks allows users to develop their own transceivers, and Echelon offers a variety of other transceivers for use with LonWorks.

Transceivers offered by Echelon include the following.

FTT-10A for twisted pair communications at 78kbps with distances to 2700 meters in a doubly terminated bus topology. The FTT-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 FTT-10.

LPT-11 for twisted pair communications to 78kbps with distances to 500 meters free topology, or 2200 meters with doubly terminated bus topology. In addition, the LPT-10 allows network powered nodes, with the transceiver providing +5 VDC at up to 100 mA to power the node from the network. A single twisted pair provides both communications and power.

PL-3120 and PL-3150 Smart Power Line Transceivers for communication over AC or DC power lines, or even unpowered telephone lines. Spread spectrum signaling, or A- or C-band carrier is used, along with error correction and automatic sensitivity adjustment for highly reliable communications even in the presence of electrical noise from motors, ballasts, dimmers, and other sources. Using the PL-31x0 family, the LonWorks network is broadcast over a buildings power distribution system.

Neuron C Programming Language

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 11 I/O lines. A few examples of Neuron C code follow, showing typical control system program requirements.

A typical control application requires some initialization at reset. The Neuron chip's I/O lines are initialized automatically based on the I/O model declared. All RAM is zeroed automatically at reset. If any unique initialization is needed at reset, it may be accomplished as shown below.

IO_1 output bit io_relay;
IO_5 input bit io_switch;

when (reset)
{
if (io_in (io_switch)) io_out (io_relay, ST_ON);
}

 In the above example, the IO_1 pin is defined as an output, and the IO_5 pin is defined as an input. These pins will be initialized automatically upon reset. The code shown in the reset event will turn on the relay if the switch is found to be on at reset.

Neuron C is based on ANSI C, but the "when" statement is one of the more significant differences. There is no "main" in a Neuron C program. Each "when" statement constitutes a task which will be executed when the given condition tests true. A typical program will have many "when" statements or tasks. The task scheduling conditionals are normally sampled in round robin fashion, but the programmer does have optional control over the scheduler to create priority tasks.

One of the many uses for the "when" statement is event driven I/O processing. The following task will be executed only when the input changes to logic zero.

IO_0 output oneshot io_jog_conveyor;
IO_4 input bit io_sensor;

#define PULSE_1_SEC 39062 // 1-second pulse

when (io_changes (io_sensor) to ST_ON)
{
io_out (io_jog_conveyor, PULSE_1_SEC);
}

The above task will jog the conveyor for 1 second any time the sensor input turns on. A parameter in the output to the oneshot I/O model determines the programmable time period that the output will be activated.

Software timers are built into Neuron C, and may be used as events to schedule a task (execute a "when" statement). The following is an example of use of software timers:

IO_0 output oneshot io_flasher;

stimer ti_flash_timer;
mtimer repeating ti_update_timer;

unsigned long seconds_count;

when (reset)
{
ti_flash_timer = 5;
ti_update_timer = 1000;
}

when (timer_expires (ti_flash_timer))
{
io_out (io_flasher, 19531);
}

when (timer_expires (ti_update_timer))
{
++seconds_count;
}

In the above example, ti_flash_timer is declared as a timer with a resolution of seconds while ti_update_timer is declared as a timer with a resolution of milliseconds. In addition, ti_update_timer, declared as repeating, will automatically reset and continue counting when it times out. Therefore, the second task in the above example will give a very accurate count of elapsed time in seconds. The first task will simply flash the "flasher" output for 1/2 second once, approximately 5 seconds after reset.

It should be noted, for the record, that all of these code examples are complete and functional as shown. There is no hidden code or user defined subroutines needed to accomplish what is being demonstrated. Programming a real time application in Neuron C really is this easy!

The last example is probably the best. Communications with other nodes in the network can be done in a variety of ways, but the network variable method is the simplest and most elegant. The following segment of code "communicates" with one or more other nodes. The data type SNVT_lev_disc is a LonMark standard data type that is guaranteed to be inter-operable with other products.

IO_0 output bit io_control;
IO_4 input bit io_sensor;

network input SNVT_lev_disc nv_command;
network output SVNT_lev_disc nv_status;

when (io_changes (io_sensor))
{
if (io_in (io_sensor)) nv_status = ST_ON;
else nv_status = ST_OFF;
}

when (nv_update_occurs (nv_command))
{
if (nv_command == ST_ON) io_out (io_control, 1);
else io_out (io_control, 0);
}

The above example will transmit a status when the sensor input changes state, and change the control output when a valid status is received. Received messages simply arrive as new values in a variable. Transmitting messages simply requires assigning a new value to a variable. The only requirement is that these variables be declared as network input or output.
The above examples don't show who we are talking to on the network. The programmer does not need to know who is at the other end - that's part of what makes LonWorks so flexible and so powerful. The "who" at the other end will be assigned at network installation time. Installation may take place at the factory or in the field, depending on how the system is designed and intended to be used. Using LonWorks and network variables, communications over a complex network can be relatively simple.

For more information on LonWorks technology visit www.echelon.com/products/lonworks.