I/O CONTROL WITH PC AND FIELDBUS
K. Kenda, I. Kriznar, M. Perko, U. Platise, M. Plesko, M. Smolej,
J. Stefan Institute, Ljubljana, Slovenia, e-mail: matjaz.smolej@ijs.si
Abstract
The LonWorks fieldbus is a powerful dataacquisition/networking system that connects up to 32000
intelligent nodes with I/O modules directly to a PC thatruns under Windows 98/NT. LonWorks technology offers
a complete network system in hardware and software in asingle micro-controller (the Neuron chip) and eliminates
any need for network programming. Many LonWorksboards are commercially available, however it is also
relatively straightforward to interface own designs to theNeuron chip. After a careful analysis of all our I/O
requirements, three I/O boards were designed that cover
all cases: a multipurpose serial interface, a high precision
16-bit DAC/ADC board and 40 channel digital I/O board.
The software that we have written for the Neuron chips
implements quite complex functions such as statemachine and alarms, synchronous ramping in 0.1
millisecond steps and others. The communication to thePC is done through the LCA/LNS library throughnetwork variables and remote command invocation,
which allows also for network management. On top ofthis, we have written additional functionality such as atemplate compiler and a file transfer protocol, whichloads all run-time constants at start-up from a centralized
database. Thus each constant that is used by the Neuron
and the PC clients and servers, is stored in one place only.
Results of operations and performance measurements arepresented.

1 INTRODUCTION
This work represents the I/O control sub-unit of thecontrol system for the light source ANKA[1]. The control
system is based on PCs, so the appropriate solution forinterfacing devices is to use a fieldbus, thereby avoiding
the complexity of VME.
We were looking for an integrated solution, which
would hide all communication details, so that we could
save development efforts. The LonWorks technology
proved as the most optimum currently available solution
for our needs. Its network protocol, which comprises all 7
layers of the ISO/OSI model, reduces network
programming to merely formatting the application level
packets or even only assigning variables. Each node on
the LonWorks network has a special micro-controller –called the Neuron chip – with built-in networking, I/O
and application functionality. It is programmed with theNeuronC programming language which has, besides
normal C syntax, constructs such as declarative syntax fordefining I/O objects, network variables and software
timers, plus exhaustive run-time library for controlling
I/O, network communication, etc. Programming andnetwork communications are event-driven, by simply
defining tasks which are to be executed by a built-in taskscheduler when the appropriate event occurs.
All these features allowed us to bring much intelligenceto the device level instead of just mapping I/O to the PC.
We have thus two main processes on different levels: Thedevice driver is running on a fieldbus node. It monitors
the physical device, generates alarms, sends
asynchronous value updates, etc.. The device server isrunning on the PC. It communicates with all device
drivers of the same type, manages them, and exports thefunctionality of their devices as a CORBA server to therest of the control system.

2 I/O BOARDS
Although many commercial I/O interface boards werealready available, we decided to develop our own boards.
This decision allowed us to keep the number of different
board types as small as possible. A total of three types
cover all cases of control system’s I/O requirements. All
our boards have a MC143150 micro-controller MCU (theNeuron chip) with 24k bytes of SRAM and 32k Bytes ofFLASH memory and they are built in small Europa
format (160x100 mm). The individual I/O boards are:Ariadne is a serial interface board, which supports EIA232, EIA-422 and EIA-485 standards at maximum baudrate of 115kbps. It has a 16k bytes long buffers on receive
and transmit lines and an on-board power supply unit thatcan source current from 230 V AC line, unregulated DC
7-12 V and regulated 5 V DC.
Hera is a generic digital I/O card with 24 inputs (50 mA),
8 inputs/outputs (50 mA) and 8 solid state relays (1 A).
All I/Os are optically isolated. Two operating modes areprovided for inputs and input/outputs. There is also a 16bit frequency counter with range of 0-100 kHz (absoluteerror 1.53 Hz).
Zeus is a high precision I/O card with a 16-bit ADC andDAC, DAC trigger input, and optically isolated digitalchannels (8 inputs and 8 outputs). Four analog channels
with a nominal sampling frequency of 1 kHz are
multiplexed to the ADC, which is oversampled at 4 kHz
to ensure 0.3 LSB precision. The DAC operates at amaximum rate of 10 kHz. An additional on-board
peripheral micro-controller, specially designed to control
booster and storage ring power supplies includes:
function generator synchronized with DAC trigger input,

32 kb of memory to buffer DAC function and ADC data,and peripheral self test.

3SOFTWARE

3.1 Node level
The software controlling the devices in our control
system is “device aware” and hides the I/O details fromthe higher levels. Due to CPU power restrictions of theNeuron chip, this encapsulation is done only to areasonable extent, e.g. the conversion to engineering units
from hexadecimal values is done on the PC due to poor
floating-point performance of the Neuron chip.
Our control system includes over 20 different device
types. The requirement for having devices as intelligent
as possible increases the amount of device levelprogramming. With all that in mind it makes sense todefine a generic API for device driver implementation,
which would also include a generic communicationinterface. With such API we simplify development of
new device drivers and also the development of software,
which communicates with our devices (in our case device
servers running on PC).
The device driver API also allows for implementing
multiple devices of the same or different type on the sameI/O board, according to our paradigm of “device aware”
fieldbus nodes.
A generic device being part of a control system must beable to:
1. receive, process and answer foreign requests
2. propagate monitored parameters and their alarms tothe observer
3. device can also have a state machine or additional
logic programmed withinWith LonWorks, using request/response mechanism for
implementing a simple RPC can easily cover the firstrequirement.
The second is achieved by defining proper network
variable types and simply updating the network variables
each time the value is read from the device. Thesenetwork variables are called monitors. An adjustable pairof software timers controls propagation of each monitor
variable. “Max timer” defines the heartbeat of the monitor
and “min timer” defines minimal time that must passbetween two monitor updates. Min timer prevents fromflooding the network if the monitored parameter value ischanging to fast. Some types of parameters can have adelta threshold defined, which also prevents from too
rapid propagation. Each monitor has a complementary
network variable called alarm, used to communicate
alarms and the values responsible for that alarm.
The monitor and alarm communication is asynchronous
since the propagation is triggered by “timer expiration”,“change in value” or “alarm condition” events.
The generic device driver library has been written suchthat any device driver can be compiled into a simulationof the device via a single compiler directive. This ispossible due to the small number of different interface
boards and exactly defined communications interface.
The simulation proved extremely helpful during code
debugging and testing.

3.2 PC side communication
Echelon provides LNS (LonWorks Network Services),a platform independent, object-oriented architecture formanaging LonWorks networks. Under Windows, there isan ActiveX wrapper of LNS called LCA (LonWorks
Component Architecture). Unfortunately, the current
version of LCA is too heavily interoperability-oriented.
For this reason and to automate and simplify network
services, it hides some crucial details from the developer,
who is then forced to use the LNS API directly.
At the initial phase of development we used LCA
which helped us to deliver the control system prototype ina relatively short period. In second phase we imported theexplicit messages functionality and needed the LNS layer
for that. Our next goal is to completely avoid the LCA
and thus gain the full control over the network services
and also avoid the overhead of ActiveX.

3.3 Device configuration
In order to eliminate hard-coded constants and thus
make the device driver flexible we download
configuration parameters to the device. For that purpose
we implemented a custom windowed file transfer
protocol, similar to one described in LonWorksEngineering Bulletin [2]. Using FTP we are also able totransfer large amounts of data.
Each time the device server is started it checks the node
if it has a valid running application. If not, the executable
path is found in the database and application downloaded
to the node. Node’s configuration files are updated ifneeded.
The configuration data is stored in a database, which isused by both device driver and device server. All the datais stored in engineering units, which must be converted
into raw format before being used by Neuron application.
To simplify device configuration process and to eliminate
occurrence of the same configuration constant in multiple
places within the database or in multiple formats, atemplate compiler has been written. This compiler takes
the original header file from the NeuronC application andcompiles it into a template, which is then filled with
database data and converted into a binary version. Thisbinary version can be downloaded via FTP and copied
directly into the same data structure that was used tocreate the template. So we have a generic way forconverting database data into a Neuron application
recognizable format.
The FTP feature was implemented by providing anFTP server on the PC who can handle up to 256 multiple
transactions, running in concurrent or sequential mode.

Integrated notification mechanism allows for handling
FTP notification events. Transactions can be started oraborted locally using PC API or remotely by Neuron
application.
A good example of using FTP and template compiler
for configuration is mapping logical devices to I/O pinson the board. Those maps are part of device’s
configuration file, which is generated by templatecompiler and downloaded if needed each time the device
server starts.

4 PERFORMANCE
The most demanding case during control of ANKA iswhen the maximum number of possible nodes (64) on one
fieldbus branch send regular updates of 3 parameters at 1
Hz and simultaneously one parameter of one board is set
and read-out at 20 Hz. This translates to 212 (3*64+20)
incoming
unacknowledged
packets
and20
request/response packets per second.
Measurements showed that our system is able to handle
up to 230 incoming unacknowledged packets per second(which is also the upper limit of “throughput/offeredtraffic” linearity) and can transmit up to 40
request/response packets per second, i.e. more than weneed. Even if the nodes produce too much traffic on thenetwork, the throughput doesn’t fall to zero, but stays at
the level of approx. 190 packets/s. The average packet
size in the test setup was 12 bytes.
Our test setup included 11 Neuron nodes all running asimulated power supply device. Nodes were connectedvia 1.25Mbit twisted pair transceivers and Echelon’s
PCNSI card was the interface to the PC. The
measurements showed that this interface is the bottleneckfor data throughput.
The first real-world test of our system was on the 50
MeV microtron pre-injector of ANKA using 5 Ariadne, 2Hera and 30 Zeus boards, all on the same fieldbus branch.
The PC ran device servers for magnet power supplies,
vacuum gauges, pumps and valves. Installation anddebugging took three days, then no further service wasnecessary. The fieldbus system ran absolutely stable. Anew bottleneck was string-based communication over theserial board, as the conversion of strings to numericvalues is quite slow on the Neuron chip. So the fastest
update write/read cycle on this type of communication
was about 5-10 action pairs per second, which is stillreasonably fast.

REFERENCES[1] M. Dach et al, A Control System Based on Web, Java,
CORBA and Fieldbus Technologies, PCaPAC99
workshop, Tsukuba, January 1999.
[2] LonWorks Engineering Bulletin, EB176, Echelon
Corporation, November 1996