Bakker, R

Birke, T

Kuske, Bettina Christa

Müller, R

CERN Document Server

‘NEARLY’ GENERIC MONITORING AND CONTROL PROGRAMSMAINTAIN BEAM QUALITYR.Bakker, T.Birke, B.Kuske, R.Mu¨llerBESSY, Bld. 14.51, Rudower Chaussee 5, D-12489 Berlin, GermanyAbstractFor beam focusing and steering at BESSY II applications are used that aregeneric enough to describe and correct all accelerator sections at BESSY II bysingle program instances. E.g. the program ‘Orbit’ provides the appropriateexecution modes to measure and correct the beam trajectory in the fast cyclingbooster synchrotron (different energy levels), in the storage ring (closed orbitand single turn measurement mode) and in the different transfer lines. Basicingrediends are an OO modelling toolkit, an ORACLE database providing theconfiguration data connecting magnets and power supplies and a well sepa-rated interface to the GUI. Physics methods dynamically adapt to the specificsystem. Device bookkeeping and screen update is generally based on call-backs. As residual non-generic program elements the data navigation features,like display options, meaningful operation modes etc., remain and reflect thespecific system differences.1. INTRODUCTIONThird generation light sources have to deliver beam quality beyond todays technically achievable passivestability. Requirements for well defined beam conditions are typically met by control system applicationsperforming periodic orbit recenterings and optics readjustments. Despite the fact that programs in useat other light sources or ‘particle factories’ are comparable with respect to functionality, precision andreliability there is no common or sharable approach available yet.The following description of the beam steering and shaping applications in use at BESSY II isfocused on the software modules and interfaces, not on achieved results or operational performance.These programs are not yet sharable but generic in the sense that single program instances describe andcontrol all different accelerator sections at BESSY II. The orbit measurement and correction program forexample reads and steers the beam trajectories in the fast cycling booster synchrotron (different energylevels), in the storage ring (closed orbit and single turn measurement mode) and in the different transferlines.2. GENERAL PROGRAM ANATOMY2.1 Program ComponentsThe application environment at BESSY II partly determines the fundamental layout of the programs:2.11 Graphical User Interface (GUI)User interaction and data presentation is handled by a dedicated GUI server [1]. Applications are graphi-cal clients using the API to this server, free from graphical code and not aware of any GUI element. Userrequests (type button, chooser) or data updates (type meter, message) are mediated by changes of thecorresponding application variables (type double, string). The actual representation instances (look andfeel, layout, multiplicity etc.) of the application variables are described independently and externally in‘form’ files (see Fig. 1). The data objects linking representation and application entities are maintainedwithin the graphics server. The only exception of a not fully decoupled graphical presentation is imposed97userrequestsX-resourcesevent protocol formsgraphicalserverevent-handler Motif 1.2widget setrepresentationdescriptionsdataobject sgraphicalserver APIApplicationcdevcdev support usercodegraphical  clientsdevice IOButtonChooserScroll Bar	xrtGraph...doublestringOP_CODE Control:ClipZoomLabelPrintSelect  Element	Select  Point	...Internal ProtocolGUIAPPLICATIONGraphic Server / Client Goemon: C++ Model ToolkitClass CategoriesAccelerator Object:Member Functions::Element - Drift - Quad - …- Marker - Sextupole - …- BPM - ...Beamline - Ring - Storage Ring …- Transfer Line - ...: Overloaded Operator=  B-Section   +  B-Section    +  ...-Section =   Elem Elem …-Section =  B-Elem B-Elem …N A BN A B1 2Component: InheritanceMachine: InheritanceSection CompositionBeamline++ ++ +ELength, TypeBStrenght, Transfer FunctionsMatrix / Vector: MathematicsGet / Set: Model Set PointsCalculation: Optical FunctionsFig. 1: Elements of the BESSY Development Environment: GUI Server/Client (left) and C++ Model Toolkit (right)by the complex xrtGraph[2] widget used for 2D diagrams (examples in fig. 5, 6): Here a simple one-by-one mapping of widget and application data sets is not possible: a ‘command and notify’ string is usedin an OP-code type manner to control basic widget functionalities (e.g. attach string array of labels toarrays of a datasets) or to report results of user actions (e.g. selection of a data region).2.12 Modelling ToolkitA C++ modelling toolkit (Goemon)[3] features inheritance of single lattice components as well as ofvarious beam line types (see Fig. 1). Different models are easily set up using overloaded assignmentoperators to model smaller sectors of an accelerator structure and collate them to the section understudy. Sequences of elements of certain type and length are turned into accelerator objects by addingmagnetic strength and appropriate transfer functions. Member functions of the accelerator object allowto manipulate the model (set points, displacements, etc.) and to perform optics calculations.2.13 Unique Reference DataA central ORACLE database holds the reference repository providing a unique data source for all relevantconfigurations[4]. Data are set up and maintained by the equipment responsible person (Fig. 2). Exportof data to the download area of the IOC’s or to cache files used by generic applications is done byprograms or scripts (Fig. 3). Dynamic programs use DB queries (OCI) for their configuration. For themodel toolkit element sequence, length and position are extracted from the database.2.14 Support UtilitiesThe C++ model object may be passed to utility packages by its pointer and queried or modified by the(optical) member functions. Magnet - power-supply wiring (Fig. 3), conversion factors, device I/O,98NameNameNameAutoCADMeasurement Text EditorEXCELIntermediateCSV TableOracleLoaderDatabaseORACLElispscriptsave as ...OracleFormsOracleFormsDataImportMain-ten-anceEquipmentSpecialistFig. 2: Role of the Reference Database: Data are Imported from Genuine Sources. Ownership is Preserved. Update is done bythe Equipment Responsible Person (left), For Model Construction Element Sequence and Length is used (right)NameNameNameDatabaseORACLENameReal TimeDatabaseOCIOCIC-Programsoratcl scriptsﬀModelCreatorSQLﬁQueriesﬂmixedtypeﬃProgramconfig.files dynamically!configuredProgramst" aticallyconfiguredProgramOracleFormsUpdateDevice Access:  CDEVEPICS / VME0 1 2 3 4 5mSection 1 BESSY-IIPower supply connections#S1MD1R - HS1MD1RS2M1D1R - VS2M1D1RS3M1D1R - VS3M1D1RS4M1D1R - HS4M1D1RQ1M1D1R- HQ2M1D1R - VQ3M1D1R - VQ4M1D1R - HBM1D1R - HBM1D1RS2M2D1R - VS2M2D1RS3M2D1R - VS3M2D1RS4M2D1R - HS4M2D1RQ1M2D1R- HQ2M2D1R - VQ3M2D1R - VQ4M2D1R - HBM2D1R - HBM2D1RS1MT1R - HS1MT1RS2M1T1R - VS2M1T1RS3M1T1R - VS3M1T1RS4M1T1R - HS4M1T1RQ1M1T1R- HQ2M1T1R - VQ3M1T1R - VQ4M1T1R - HBM1T1R - HBM1D1RQ5M1T1R - VS2M2T1R - VS2M2T1RS3M2T1R - VS3M2T1RS4M2T1R - HS4M2T1RQ1M2T1R- HQ2M2T1R - VQ3M2T1R - VQ4M2T1R - HBM2T1R - HBM2T1RS1MD2R - HS1MD2RQ5M2T1R - Vlow bhigh b$Q4PD1RQ3PD1RQ5PT1RQ4PT1RQ3PT1RQ2PDRQ1PDRQ2PTRQ1PTRS1PRS2PTRS3PTRS4PTRS4PDRS3PDRS2PDRS1PRBPRFig. 3: Role of the Reference Database: Data Export Mechanisms for various Generic Applications (left). Mapping betweenControl System and Model (Wiring, Conversion Factors, device I/O, Synchronized Model/Power Supply Update) (right)99Device Access ObjectDB callConnect Magnet - PowersuppyEnter Event LoopRUNS-MatrixSVDBumpOpticalFitDataNavigationDeviceBookkeepingCallBackDisplay OptionsOperation ModesParameter SetupPhysicsMethodsInitializationGraphicalUser InterfaceBeamShapingApp -option TargetSystemGraphic PresentationApplication V% ariablesBasic SetupSet DimensionsCreate Data ObjectsEvent Object(s)BeamlineModel Object/ Ring&GUI  ServerORACLEEventLoopSet Up Default ValuesDynamicProgramminggraphicalserver APIcdevcdev supportdevice IOData BaseCallsModelToolKit'BPMMonitorPS - MagnetSupportDisplay OptionsData NavigationGUIProgramOperationModesT. Birke(T. Birke(R.Bakker) R.BakkerR.MüllerR.Müller)B.KuskeDB-Adm.R. Bakker)T.BirkePhysicsMethodsFig. 4: Sketch of Program Flow (left), Corresponding Work Break Up (right)power supply set point synchronization, model update and fitting of optical parameters are taken careof by such a support library. Orbit measurements, BPM data validity checks and statistical analysis arehandled by another utility library.2.2 Program FlowOnly during start-up the programs branch according to the command line arguments: the applicationtriggers the GUI server to read the appropriate base form and marks (if needed) the accelerator sectionto be modeled. Further on the program auto-configures (see fig. 4):- Basic set up: from the variables and presentation elements found in the associated graphic descrip-tion file the GUI server configures screen and data objects, allocation of the corresponding datastructures within the application is initiated.- Model/Device access objects: replies from the database provide the informations needed to set upthe model and the magnet - power-supply correlations.- Data buffers and event objects are dynamically created according to detected dimensions, correla-tions and associated callback functions.Physics methods adapt to the particular system. Device bookkeeping and screen update is gen-erally based on callbacks. As residual non-generic program elements specific data navigation features,like display options, meaningful system or program operation modes etc., remain and reflect the specificsystem differences.100Fig. 5: The ‘Orbit’ GUI: Main Controller Windows (left), BPM Data, Orbit Correction and Bump Screens (right, from top)3. APPLICATIONS3.1 Orbit ControlThe ‘Orbit’ display and control program provides a wide variety of functionalities covering several areasof control activity in the different accelerator sections synchrotron, storage ring and transfer lines. Thefollowing basic program modes have already been described in more detail [5]:- support of an ‘All-in-One’ GUI (Fig. 5)- data presentation, statistical evaluation- control of the measurement system and manipulation of data validity- manual or automatic orbit correction with different methods under varying conditions- selection of closed orbit bumps from preconfigured lists (insertion device, achromat) or by freeconfiguration (click on coordinate, correction element)- data correlation, response matrix measurement:device stepping, data logging, postprocessor launching.101Fig. 6: The ‘Optics: Main Controller Window (left), Tune and Chromaticity Correction (right)Due to feedback of evaluated measurements into the current/magnetic field conversion factors andthe BPM calibrations the program works even in the model based mode very reliable and accurate.3.2 OpticsSince tune and chromaticity measurements are still offline the ‘Optics’ program is in a less mature stage.It serves more as an online model describing the optical properties of the actual machine set points andtheir dependencies on parameter variations (See fig. 6 and [5]). Fitting procedures adjusting the tunewith a selectable quadrupole group are first steps toward an automated compensation of tune shift andbeta beating caused by gap variation of not fully balanced insertion devices.4. SUMMARY, EXPERIENCESIn summary the consistency of a generic and completely event driven system has appreciable advantages.The reference repository and the C++ modelling toolkit have shown their benefits and established theenvironment for powerful support libraries. The generic applications evolved ‘down-stream’ with theinstallation procedure of the accelerator segments. They worked very reliable at start-up of the storagering and turned out to be essential for the commissioning procedure.5. LESSONS LEARNEDThe generality achieved with the applications developed at BESSY and the examination of portablesolutions successfully applied elsewhere give an idea of a possible framework for fully generic, sharableABS software.5.1 Required ModulesA precursor of generic ABS applications would be a common repository of easy integrable ‘component-ware’. The core of the typical beam steering control issues, like* Orbit recentering and manipulation* Dispersion control102* Coupling compensation* Emittance conservation* Lifetime improvementcomprise comparable software fragments with only slightly differing methods and implementationconstraints. The example of a reliable, precise and flexible orbit control program gives insight on theingredients of the major modules:- Solver/Calculation Module:A number of different mathematical methods are well established and known to find the cor-rection suited ‘best’ for a specific situation (SVD, harmonic correction, MICADO, etc.). Theachievable ‘improvement’ depends strongly on the appropriate weighing of the different figure ofmerits (RMS deviation at electronic/photon BPM, ‘fixed’ source point, etc.) as well as on thespecific problem break up strategy (global/local correction subsystems, model based/experimentalresponse matrix etc.).Data conditioning strategies have an equally strong effect on the performance of a correction pro-cedure. BPM data require a plausibility analysis, weighing, detection of improper operation of themeasurement system. Limits on the adressable setpoints of the involved correctors (status, maxvalues, digital resolution) add the necessity of boundary condition handling to the calculation ofthe ideal correction.In this context implementation issues (API, programming language) as well as dependencies onexternal software packages are more technical portability aspects.- Data Aquisition, Apply Procedures:This program segments strongly depend on the specifics of the measurement system and the dif-ferent control system protocols. This is reflected in the principles of sending corrections (synchro-nization) and by the implementation variants (control system communication paradigm). But thereare still a number of common procedures, e.g. the orbit measurement data have to undergo validitychecks, fault detection analysis etc. Ramp utilities have to handle proper step size, react on errorsand exceptions. Drift compensations (‘slow feedback’ procedures) require adjustable regulatoralgorithms (PID).5.2 Minimal Common Ground: Interfaces, ArchitectureThere are numerous ways to glue different software modules together to make up applications with acomparable spectrum of functionalities. For generic ABS software a minimal granularity seems to benecessary (Fig. 7): Various solver and correction calculation facilities as well as an integrated modelare the obvious core of any ABS application. The GUI and the control system I/O should be separatedby appropriate interfaces, preferable API’s. CDEV [6] as middleware between application and controlsystem has already proven to enhance program portability. For the GUI java is a promising candidatealready under study at various places. In addition the data taking and evaluating engine as well as theset point applying ramp unit should be well encapsulated to allow for specifics of BPM and correctorsystems. Finally localization of program configuration is a must for any generic solution.5.3 Remaining Problem Source: DiversityOn the way to operational application programs a number of different implementation variants are feasi-ble that are well suited to impair the usefulness of an ABS program for another site:* Model Integration: sucessfully applied solutions comprise toolkit libraries, model servers, shellscripts using standard tools (e.g. MAD) in a filter/pipe mode or sets of precalculated output data.* Configuration Management: if a RDBMS is properly set up, online queries are feasible. Otherwise(more or less) standardized file/data set formats are necessary.103Data ViewerAquireDataSendCorrectionDevice I/O  (CDEV)ConfigurationRampValid ?GUI:ActionMenueDiagramModelSOLVERCALCULATIONApplyFig. 7: Sketch of a possible Architecture for Sharable ABS software* Architecture: agreement on a number of established, canonical toolkit modules is certainly lessflexible than well defined APIs or pipe chains (SDDS) allowing for a variety of underlying mod-ules.* Flow control: extreme flavours are ‘sequential’ (allowing for command file configuration, inter-preted interfaces) and ‘data driven’ (asynchronous, based on callbacks, event oriented)* GUI technology: a common understanding of a minimal and sufficiently powerful set of userinteraction and data viewing elements is hard to achieve.References[1] T. Birke, R. Lange, R. Mu¨ller, Proceedings of the 1995 ICALEPCS, Chicago, 1995, p.648[2] XRT/graph is a trademark of KL Group Inc., Toronto, Ontario[3] H. Nishimura, Nucl. Instr. Meth., A 352 (1994), p.379[4] R. Bakker, T. Birke, B. Kuske, B. Martin, R. Mu¨ller, Proceedings of the 1997 ICALEPCS, Beijing,1997, p.407[5] R. Bakker, T. Birke, B. Kuske, R. Lange, R. Mu¨ller, Experiences with Commissioning SoftwareTools at BESSY II, Proceedings of the 1999 PAC, New York, 1999 (WEP49)[6] J. Chen, W. Akers, G. Heyes, D. Wu, C. Watson, Proceedings of the 1995 ICALEPCS, Chicago,1995, p.97104

"Nearly" Generic Monitoring and Control Programs Maintain Beam Quality

Abstract

Similar works

Full text

Available Versions

CERN Document Server