Engström, M

Westlin, E

CERN Document Server

CONTROL SYSTEM FOR CRYRINGE. Westlin, M. Engström, Manne Siegbahn Laboratory, Stockholm, SwedenAbstract  A new modular control system architecture usingCOM/DCOM for the CRYRING synchrotron/storage ringin Stockholm is described. The purpose of the system is toprovide access to control system parameters in a genericsense. The current communication hardware consists of aCAMAC bus, serial modbus and socket  connections.Client programs communicate with servers usingDCOM[1]. A basic server controls access to one hardwarecommunication port. Each client connects to one or moreservers.1  SYSTEM ENVIRONMENTThe CRYRING, a 52 m circumference synchrotron andstorage ring at the Manne Siegbahn Laboratory inStockholm, is in operation since 1990 for research mainlyin atomic and molecular physics. The facility includes,beside the ring, a number of ion sources, an RFQ pre-accelerator, and beam transport lines to a number ofexperimental stations using the low-energy ion beamsdirectly from the ion sources.The number of  parameters to be handled by the controlsystem is presently around 300. Out of these, around 250are of the simple type having a static output value, andaround 50 are of the time-varying type being controlled byautonomous function generators. The system is expandingwith the accelerator facility. The present data distributioninfrastructure is based on serial CAMAC and local G-64controllers, but other types of communication and localcontrol will be used for the future installations.2  PARAMETER MODEL2.1  GeneralBasically a parameter is the object of interest in anycontrol system. Since this new control system is to replacean old one with as little inconvenience as possible andmaybe also because it is a good way to structure thesystem, the old parameter concept has been kept intact.The system also has, apart from the old parameters, tohandle new types of equipment the old system didn’t orcouldn’t handle. Because of these requirements a moregeneric parameter concept has been adopted, resulting in ahierarchy of parameter types, where some functionality iscommon and other is specific to each parameter type.Two types of access methods have been implemented, onestructured and fixed, the other unstructured and flexible.2.2  Structured AccessThis method of access uses COM/DCOM versions of theparameter access methods. This design gives convenient,efficient and robust access methods. These methods usescalars, vectors or structures as values. The maindrawback is that they are predefined and can handle onlyone type of parameter. So either one squeezes newparameter types into one already existing, or write newdedicated interface functions.2.3  Unstructured Access  However to facilitate a  more generic access to allparameters, regardless of type, a set of generic accessmethods has been developed. These methods haveadopted the concept of a path to a data point. The value totransport to or from this data point could be of any type(within certain limits of course) as far as the client/servercommunication concerns. It’s the responsibility of thesender/receiver to serialize/unserialize the data. The basicbuilding block for data transfer is an encapsulated unionnot unlike the VARIANT datatype. To aid thedevelopment of client/server serialization a specialarchiver, derived from the MFC CArchive class, is beingdeveloped, enabling a technique similar to the onedeployed in  ConSys [2], the new control system of theASTRID ring in Aarhus.   Typically a data point corresponds to an attribute of aparameter but it could also be an attribute of  a moduledriver to be used when adjusting the behavior of thecontrol system. It could also be a more abstract point suchas a ‘SCRIPT’ point as explained below. The basicrequirement on the path is that it should begin with aparameter or module name, the rest of the path is parsedby the intended parameter or module implementation, sothis could be quite free formed, similar to an OPC itemdefinition [3].3  CLIENT/SERVER COMMUNICATION3.1  General OperationThe communication is based on DCOM. Clients interestedin some parameter value have two choices of readingvalues, either they use the forward on demand interface orregister a subscription and at a later time gets called backby the server. The callbacks could be conditional asordered by the client. The subscription/callbackfunctionality is in the following referred to as the alarmsystemInternational Conference on Accelerator and Large Experimental Physics Control Systems550International Conference  Accel rator and L rge Experim ntal Physics Control Systems, 1999, Trieste, Italy3.2  ClientsA rather fat client library communicate with one or moreservers. The client hide most of the DCOM system calls.A database object/server lets the client know whichparameter belongs to which server. The same databaseobject is also accessed by the servers. End user programseither link with the client, as is the case with some legacyprograms, or communicate  with the client  viaActiveX/OLE.3.3  Server StructureThe system is built to solve specific needs and there hasbeen no deliberate attempt to build a system handlingevery conceivable situation. However when using theadopted method, which is influenced by the UnixSTREAMS modular system [4], the situationsencountered have found straightforward solutions.The basic building block of a server is a Module Driver, aconcept inherited from the old control system. In the newsystem this has been made into a more generic term. Theend user client communication over the net via DCOMconnects to a client proxy object in the server process.Internal to the server is a head module driver which is theconceptual module driver object. This object persists inthe system database and keeps record of the parametersaccessible through the server. The head module driver inturn connects to other module drivers implementingembedded protocols.A module driver is typically implemented in a separateDLL. It is accessed through a COM in-process serverinterface. Each module driver has a unique name andseveral module drivers can be instances of the same COMclass. Which module driver instance to select isdetermined with a special login method in the COMinterface. All clients on all levels, also inside a server, arerequired to first call this method.3.4  Server ExecutionAll access through a hardware port is controlled by a mainwork thread, residing in the head module. When a clientmakes a request the server converts this into a job object,similar to a process instance in a regular operating system.This job object is placed into a queue where the mainwork thread, awaken by the system heartbeat or by thearrival of a new job, later picks it up, executes it, and thentypically wakes the client proxy thread, which can returnthe result to the client process.The queue is actually implemented as two separatequeues, one sleep queue and one run queue. When thework thread runs, it first checks which jobs in the sleepqueue has timed out, and moves those to the run queue.Next the work thread takes the highest priority job fromthe run queue and executes it. This execution preferablyshould not contain any wait states, but it’s up to theimplementation of the job object to exit and return sincethere is no preemption. To improve concurrence, jobexecution should be short, and if longer jobs are needed,they could be divided into several invocations of the job.When the jobs execute method finishes to the main workthread loop, it returns a code which is interpreted asfollowsJOB_DONE:  The job was successfully executed. Signalthe client proxy.JOB_MORE: A longer job yields to give other jobs sometime to run. The job is reinserted into the run queue.JOB_SLEEP: A job has a wait state. It is placed in thesleep queue.JOB_ABORT:  There was an error. Signal the clientproxy.JOB_BLOCKED: The current job has a wait state and themodule driver can not execute other jobs. This causes themodule driver to enter a blocked state, and to be placed inthe sleep queue of it’s parent module.3.5  Batch Processing and Server Internal JobsThe inherent scheduler can be used to implement batchprocessing. This has been used to implement caching andthe alarm event handling in the system. It could also beused to implement a scriptable scheduler. This batchprocessor could accept sleep commands and parameterset/get requests. Using the alarm system one couldimplement triggers similar to those found in databasemanagers.An example of what a trigger might look like:When C9CAMSM.ACQ > 100.0 doC9CAMSM.CCV=0.3Other module drivers combine several parameters intonew ones. And using the scheduling, closed loopregulators can be built. An example of this is a simple PIDregulator.REFERENCES[1] Randy Abernethy, COM/DCOM Unleashed.[2] ConSys. http://www.isa.au.dk/consys/[3] OPC, OLE for Process Control. Data AccessStandard Version 1.0A September 11, 1997.[4] Dennis M. Ritchie, A Stream Input-Output System,AT&T Bell Laboratories Technical Journal 63, No. 8Part 2 (October, 1984).551

Control System for CRYRING

Abstract

Similar works

Full text

Available Versions

CERN Document Server