Andeweg, A H

Connell, S H

Hogan, M E

MacLear, R D

Sellschop, J P Friedel

Weehuizen, H F

CERN Document Server

SOFTWARE DESIGN OF THE SCHONLAND 6MV EN-TANDEMACCELERATOR CONTROL SYSTEMR.D. Maclear, S.H. Connell, A.H. Andeweg, J.P.F. Sellschop, SRCNS, Johannesburg, South AfricaM.E. Hogan, NAC, Faure, South AfricaH.F. Weehuizen, Massey University at Wellington, Wellington, New ZealandAbstractCurrently the 6MV EN-Tandem van der Graaff acceleratorat the Schonland Research Centre for Nuclear Sciencesis being upgraded for computer control. A distributed,network based control architecture has been implementedand successfully installed to control two sections of theaccelerator. A graphical user interface (GUI) is beingdesigned which is both didactic and easy to use. The entirecontrol system software has been written to use OS/2 andexploits the multi-threaded and real-time nature of theoperating system. Source code has been written in C andC++. A client-server type architecture is used to controlelectronic components to provide dynamic prioritisationof control instructions and monitoring events. A relationaldatabase is used to store all system and control variablesto facilitate upgrading needs. The modular nature of thecontrol system allows minimal down time when installingnew sections for computer control. We present here thedesign concepts, a status report and first results of theaccelerator control system.1 INTRODUCTIONThe Schonland Research Centre for Nuclear Sciencesoperates a 6MV EN-Tandem van der Graaff particle ac-celerator. There are two ion sources capable of producingboth light and heavy particle beams. The Duoplasmatronion source is a gas ion source producing proton and alphaion beams. The 860A sputter ion source is used to produceheavy ion beams of almost all elements of the periodictable. The Centre is also in the process of developing andinstalling an Accelerator Mass Spectrometer facility. TheCentre is involved, not only in physics experimental work,but also in routine geological, biological and medicalsample trace analysis using an Ion Microprobe [1]. Anyfacility that is involved in this broad spectrum of workrequires a stable, user friendly accelerator control system.A multiple PC-based control system is in the process ofbeing developed and installed for the accelerator facility.The control system has been designed to require lowmaintenance during and after installation. A GraphicalUser Interface (GUI) has been designed for control ofthe accelerator with both ease of use and education inmind. This allows non-specialist users and students theopportunity to learn from using the facility.Working on a limited budget, a variety of decisions hadto be taken. It was decided to use OS/2 Warp 4 as thebase operating system as the National Accelerator Centrein South Africa had already implemented a networkbroadcast system written for OS/2 [2]. OS/2 is alsoa stable operating system with excellent real-time andmultitasking capabilities. All control software has beenwritten in-house, and interfaces with a commercial SQLdatabase sever.The control system has been designed to be distributed,making extensive use of databasing and networking. AVariable Table Program is used as a standard communi-cation system for broadcasting across the network, whiledistributing the control system reduces maintenance andinstallation down-time, and allows for local intelligentcontrol.2 THE DISTRIBUTED CONTROLSYSTEMThe control system was designed to be as homogenous aspossible with very little maintenance. This facilitates easyupgrading and installation of future sections of the accel-erator, and requires little expert computer knowledge. Thearchitecture of the system is based on the Standard Modelfor accelerator control [3]. Software interfaces and controlsare on two levels, while hardware control resides on a third.Fig. 1 illustrates the architecture and logical layout whichis also explained below. The software of the system can bedivided into four parts, while a computer network is usedto distribute the system.2.1 The NetworkThe network used is an Ethernet 10BASE2 network whichwas chosen because the product was mature and readilyavailable. The network has been separated from the LocalArea Network (LAN) of the Centre to avoid unnecessarytraffic. Since there are only a few computers connected tothe network (a maximum of 7 is foreseen), loading is keptto a minimum, thus reducing network collisions. This alsoreduces the transmission delay of the Ethernet system.The communication system is designed to be event driven.In event-driven systems, traffic is proportional to thenumber of events. Since the control system is a reasonablysmall system, with an average of 30 control variablesper control node, the number of events on the network isalmost always at a minimal level.International Conference on Accelerator and Large Experimental Physics Control Systems561International Conference  Accel rator and L rge Experim ntal Physics Control Systems, 1999, Trieste, ItalyBottom LayerTop LayerVariable Table Program10BASE2 Ethernet BackboneConsoleComputerDatabaseServerNode 1 Node nRS232-485ConverterNudamModulesTo equipment to be controlledHardware LayerTerminatorFigure 1: Logical layout and architecture of the control sys-tem.2.2 The Variable TableThe Variable Table Program [2], written by the NACcontrol group, is used as the base message broadcastsystem of the control system. Each control variable has it’sown entry in the table with fields for actual and referencevalues, and actual and reference status. Other fields inthe entry are used for general house-keeping and variablelinkage status. The variable table serves as a commoninterface between each control node and console node onthe network, broadcasting state and variable changes toeach node. A local and global interface is available. Thelocal interface is used on controlling nodes so that onlyvariables associated with that node can be accessed. Theglobal interface is used on the console node for accessto all variables. In this way, an operator can change anyvariable in the table, while only the controlling node forthat variable is able to respond.2.3 Control NodesControl nodes are used to respond to operator requests andconvert these requests into actual controlling instructions.The hardware used for electronic control are Nudammodules [4] which accept ASCII instructions via theRS232 port of the PC. Since there is always more thanone controlling application on a node, a COM port serverhad to be designed to coordinate COM port access. Apriority queue is used between the controlling clients andthe server. All write instructions have a higher prioritythan read instructions. When a variable is being controlledby the operator, both the reading and writing priorities forthat variable are dynamically increased, thus this variablewill have the highest priority in the queue, causing theserver to process these instructions immediately.When an operator initiates an instruction, the variabletable notifies the corresponding client via a network-widebroadcast, which in turn processes the value change into acommand which is sent to the server. The server removesthe command, writes to the electronics and returns the re-sult back to the calling client. The calling client processesthe result and performs error checking. Fig. 2 illustratesthe software layout for a controlling node. When noinstructions are issued by the operator, the clients performpolling for the variable through the server. Any changes inthe variable value are written directly to the variable table.The nature of the controlling electronics ensures that theVariable Table ProgramThread 1Read VTCreatestringThread 1Read VTCreatestringThread 2ParseServerStringWrite VTThread 2ParseServerStringWrite VTS2Client 1 Client 2PriorityQueueThread 2Read PQThread 1Read PipeS1SSCOM PortServerTo Nudam modulesClient Named Pipe Client Named PipeServerNamedPipeFigure 2: Typical software layout for a local controllingnode. Each client and the server have a semaphore (Sn andSS respectively) which indicates whether the program isrunning or not.written instruction gets a return value or state before thenext instruction is performed. This removes the problemof determining which result from the electronics corre-sponds to which instruction, and therefore no unnecessaryprocessing is needed by the server.5622.4 Console NodeThe console node is used to interface to the entire controlsystem. The operators use a GUI for control, which hasbeen written to be as generic as possible. This is achievedthrough the use of object oriented programming and classinheritance. Instead of each variable being controlledseparately, a dialog box is constructed to control allvariables for the electronic device. For example, a standardvoltage controlled power supply would have a variablefor the voltage, current and digital state. This would beincorporated into one dialog box with a slider control forvoltage, digital control buttons and feedback variables,instead of three separate dialogs for each.Each controlling dialog box is created at real-time, basedon information stored in the database. A set of genericdigital and analog controls is used to construct each dialogbox. This reduces the rewriting of any code when a powersupply is changed. All that is needed is for the database tobe modified and the dialog box will be created accordingly.2.5 Database NodeSince the control system is still in its development stage,and a large number of parameters are modified regularly,it is important that the system is readily expandable andflexible. This is most easily achieved through basing theentire control system on a database which is easier tomaintain than redesigning any software. This also allowsthe system to be reconfigured and modified at one singlepoint.A relational, network-aware database, DB2/2, is used forstoring all control and system variables. The variabletable uses this database to create each variable entry, andeach node reads this database at startup. The consolenode, using a variety of database objects, retrieves all thenecessary information for system control and this is storedlocally. The control nodes retrieve only the informationthat is necessary for that node, and stores it locally inmemory. Storing the database information locally oneach node, provides for any problems on the databasenode. This way, if the database manager develops someproblems, the control system can continue to function,losing only some functionality. The database classes thatare used are written to determine the database structureat startup, so that no code needs to be regenerated if thestructure of the database is modified in any way.The database consists of a variety of tables, but two maintables are used for controlling hardware. The Main tablecontains all variable definitions while the second containsall power supply definitions, cross referencing with theMain table. This way, any power supply object can becreated directly from the database, allowing for easymodification.3 INTEGRATION AND PRELIMINARYRESULTSSoftware integration of the control system is a very quickand easy procedure. All that has to be done is placinga few entries in the database for each power supply andcontrol variables. All other aspects are automaticallyupdated. The hardware integration is a far more timeconsuming task, as the existing electronic controls areold and still use buttons and dials, and all this has to bereplaced and new electronics interfaced. All electronicsare tested off-line before installation and commissioning,reducing accelerator down time.Preliminary results indicate that the software control isvery reliable and error free, with no errors being reportedapart from operator errors. The average response time forinstructions to be processed from the client through theserver, to the electronics and back to the client is 94 ms.This excludes the overhead of network broadcasting. Theresponse time is acceptable for our control system, as thereare no time-critical processes that need control. Analogfast response is done by faraday cup meters and beamprofile monitors.4 CONCLUSION AND FUTURE PLANSThe control system has been successfully installed for twosections of the accelerator. It has been functional for nearly6 months now and has proved to be very successful. Someproblems have arisen from operators who have becomereliant on the old control system, but are slowly becomingaccustomized with the new PC-based version.Currently, the control system is used only for standardcontrol. Future plans include logging, automatic beamselection, safety implementation, continuous variablemonitoring and intelligent variable control. This wouldneed a separate program to monitor a variable, and basedon some preset physics laws and procedures, determinewhat the value of that variable should be.The entire control system is envisaged to be installed andoperational by the end of the year.5 REFERENCES[1] A.H. Andeweg, et al, “The Schonland Micro-Scanning IonBeam Analysis Facility”, Nucl. Instr. and Meth. B130 (1997),37-44[2] H.F. Weehuizen, I.H. Kohler, M.E. Hogan, P.J. Theron, “ThePC Based Control System of the NAC”, ICALEPCS’97, Bei-jing, China, 1997[3] A. Daneels, “Behind the Scene of Experimental Physics Con-trols”, Nucl. Instr. and Meth. A352 (1994), 1-5[4] A.H. Andeweg, S.H. Connell, R.D. Maclear, J.P.F. Sellschop,“Computerised Control of the 6MV EN-Tandem Accelera-tor at the Schonland Research Centre for Nuclear Sciences”,These proceedings563

Software Design of the Schonland 6MV EN-Tandem Accelerator Control System

Abstract

Similar works

Full text

Available Versions

CERN Document Server