Jeram, B

Kenda, K

Kriznar, I

Lesjak, B

Perko, M

Platise, U

Plesko, M

Smolej, M

CERN Document Server

ACCELERATOR CONTROL WITH THE LONWORKS FIELDBUSM. Smolej, B. Jeram, K. Kenda, I. Kriznar, B. Lesjak, M. Perko, U. Platise, M. Plesko;J. Stefan Institute, Ljubljana, Slovenia, http://kgb.ijs.siAbstractThe device access layer of the control system of thelight source ANKA is almost completely based onLonWorks. We have developed and produced custom I/Oboards that use the LonWorks micro-controller (theNeuron). The hardware comprises a high-precision 16-bitDAC/ADC/function generator board, a 40 channel digitalI/O+counter board and a serial interface. The device logichas been programmed already at the Neuron level, suchthat for example power supplies that are controlled eitherthrough a DAC/ADC board or through a serial interfacelook the same on the fieldbus network. The featuresinclude state machine, remote command invocation andevent driven communication with monitors and alarms.The nodes are automatically configured at start-up timefrom a PC-resident, version-controlled database for whichan ftp-like protocol has been developed. Other tools,which allow for a generic control implementation, are anetwork node installation and configuration tool, a nodeinspection and management tool and a template compiler,which allows us to use the same database data on the PCand on the Neuron.1 INTRODUCTIONThis work represents the I/O control sub-unit of thecontrol system for the light source ANKA[1]. The controlsystem is based on PCs, so the appropriate solution forinterfacing devices is to use a fieldbus, thereby avoidingthe complexity of VME.We were looking for an integrated solution, whichwould hide all communication details, so that we couldsave development efforts. The LonWorks technologyproved as the most optimum currently available solutionfor our needs. Its network protocol, which comprises all 7layers of the ISO/OSI model, reduces networkprogramming to merely formatting the application levelpackets or even only assigning variables. Each node onthe LonWorks network has a special micro-controller –called the Neuron chip – with built-in networking, I/Oand application functionality. It is programmed with theNeuronC programming language which has, besidesnormal C syntax, constructs such as declarative syntax fordefining I/O objects, network variables and softwaretimers, plus exhaustive run-time library for controllingI/O, network communication, etc. Programming andnetwork communications are event-driven, by simplydefining 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 monitorsthe physical device, generates alarms, sends asynchronousvalue updates, etc.. The device server is running on thePC. It communicates with all device drivers of the sametype, manages them, and exports the functionality of theirdevices as a CORBA server to the rest of the controlsystem.2 I/O BOARDSAlthough many commercial I/O interface boards werealready available, we decided to develop our own boards.This decision allowed us to keep the number of differentboard types as small as possible. A total of three typescover all cases of control system’s I/O requirements. Allour 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 Europaformat (160x100 mm). The individual I/O boards are:Ariadne is a serial interface board, which supports EIA-232, EIA-422 and EIA-485 standards at maximum baud-rate of 115kbps. It has a 16k bytes long buffers on receiveand transmit lines and an on-board power supply unit thatcan source current from 230 V AC line, unregulated DC7-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 16-bit 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 channelswith a nominal sampling frequency of 1 kHz aremultiplexed to the ADC, which is oversampled at 4 kHzto ensure 0.3 LSB precision. The DAC operates at amaximum rate of 10 kHz. An additional on-boardperipheral micro-controller, specially designed to controlbooster and storage ring power supplies includes: functiongenerator synchronized with DAC trigger input, 32 kb ofmemory to buffer DAC function and ADC data, andperipheral self test.3 SOFTWARE3.1 Node levelThe software controlling the devices in our controlsystem is “device aware” and hides the I/O details fromthe higher levels. Due to CPU power restrictions of theInternational Conference on Accelerator and Large Experimental Physics Control Systems401International Conference  Accel rator and L rge Experim ntal Physics Control Systems, 1999, Trieste, ItalyNeuron chip, this encapsulation is done only to areasonable extent, e.g. the conversion to engineering unitsfrom hexadecimal values is done on the PC due to poorfloating-point performance of the Neuron chip.Our control system includes over 20 different devicetypes. The requirement for having devices as intelligent aspossible 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 newdevice drivers and also the development of software,which communicates with our devices (in our case deviceservers running on PC).The device driver API also allows for implementingmultiple 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 requests2. propagate monitored parameters and their alarms tothe observer3. device can also have a state machine or additionallogic programmed withinWith LonWorks, using request/response mechanism forimplementing a simple RPC can easily cover the firstrequirement.The second is achieved by defining proper networkvariable types and simply updating the network variableseach time the value is read from the device. Thesenetwork variables are called monitors. An adjustable pairof software timers controls propagation of each monitorvariable. “Max timer” defines the heartbeat of the monitorand “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 toorapid propagation. Each monitor has a complementarynetwork variable called alarm, used to communicatealarms and the values responsible for that alarm.The monitor and alarm communication is asynchronoussince 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 interfaceboards and exactly defined communications interface.The simulation proved extremely helpful during codedebugging and testing.3.2 PC side communicationEchelon provides LNS (LonWorks Network Services),a platform independent, object-oriented architecture formanaging LonWorks networks. Under Windows, there isan ActiveX wrapper of LNS called LCA (LonWorksComponent Architecture). Unfortunately, the currentversion of LCA is too heavily interoperability-oriented.For this reason and to automate and simplify networkservices, 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 LCAwhich helped us to deliver the control system prototype ina relatively short period. In second phase we imported theexplicit messages functionality and needed the LNS layerfor that. Now, we have completely avoided the LCA andthus have gained the full control over the networkservices and also avoided the overhead of ActiveX.3.3 Device configurationIn order to eliminate hard-coded constants and thusmake the device driver flexible we downloadconfiguration parameters to the device. For that purposewe implemented a custom windowed file transferprotocol, 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 nodeif it has a valid running application. If not, the executablepath is found in the database and application downloadedto 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 dataare stored in engineering units, which must be convertedinto raw format before being used by Neuron application.To simplify device configuration process and to eliminateoccurrence of the same configuration constant in multipleplaces within the database or in multiple formats, atemplate compiler has been written. This compiler takesthe original header file from the NeuronC application andcompiles it into a template, which is then filled withdatabase data and converted into a binary version. Thisbinary version can be downloaded via FTP and copieddirectly into the same data structure that was used tocreate the template. So we have a generic way forconverting database data into a Neuron applicationrecognizable format.The FTP feature was implemented by providing an FTPserver on the PC who can handle up to 256 multipletransactions, running in concurrent or sequential mode.Integrated notification mechanism allows for handlingFTP notification events. Transactions can be started oraborted locally using PC API or remotely by Neuronapplication.A good example of using FTP and template compilerfor configuration is mapping logical devices to I/O pinson the board. Those maps are part of device’sconfiguration file, which is generated by templatecompiler and downloaded if needed each time the deviceserver starts.4 PERFORMANCEThe most demanding case during control of ANKA iswhen the maximum number of possible nodes (64) on one402fieldbus branch send regular updates of 3 parameters at 1Hz and simultaneously one parameter of one board is setand read-out at 20 Hz. This translates to 212 (3*64+20)incoming unacknowledged packets and 20request/response packets per second.Measurements showed that our system is able to handleup to 230 incoming unacknowledged packets per second(which is also the upper limit of “throughput/offeredtraffic” linearity) and can transmit up to 40request/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 atthe level of approx. 190 packets/s. The average packetsize 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’sPCNSI card was the interface to the PC. Themeasurements showed that this interface is the bottleneckfor data throughput.5 CONCLUSIONSThe ANKA control systems is now composed of morethan 200 Neuron nodes. For efficiency and topologicalreasons, there are 7 independent branches each connectedto a PC. The fieldbus system runs absolutely stablewithout interference, even when the rest of the controls isbeing shut down or restarted.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, EchelonCorporation, November 1996403

Accelerator Control with the LonWorks Fieldbus

Accelerator Control with the LonWorks Fieldbus

Abstract

Similar works

Full text

Available Versions

CERN Document Server