1. Deutsches Elektronen-Synchrotron DESY Helmholtz Association of German Research Centres 22603 Hamburg, Germany www.xfel.net The European X-Ray Laser Project XFEL X-Ray Free-Electron Laser Control System Studio (CSS) CSS New Widget Jan Hatje, Matthias Clausen, Markus Moeller, Helge Rickens DESY, Hamburg Synoptic Display Studio (SDS) Motivation Dm2kSDS Running only on Unix platformRunning on each platform providing a JVM Direct connection to Channel Access (EPICS)Control System independent because of DAL Adding new features is complicated (requires knowledge of the whole system) SDS APIs and abstract classes makes it easy to extend SDS Abstract The Synoptic Display Studio (SDS) is an application to create, manage and run displays for control systems. It will replace dm2k at DESY and is integrated in the operating system independent platform Control System Studio (CSS) based on Eclipse. All widgets of SDS (bar graph, meter, polygon, …) are separated components and are inherited from an abstract widget model. To add new widgets the developer has to extend the java classes of the abstract widget model supported by the eclipse extension mechanism. For the communication with the control system SDS uses the Data Access Layer (DAL) integrated in CSS. Therefore it is possible to show values of different control systems in the same display. The settings of a display are stored in XML format. SDS provides an editor with rich functionality to arrange and configure the widgets for a display. It is not necessary to have any programming knowledge to create displays. To reuse the current dm2k displays an ADL-Converter has been developed. It converts the adl files into XML files of SDS displays Widgets Common parts necessary for every widget are located in abstract classes of SDS. Therefore it is easy to add new widgets by extending just three classes and adding special features for the new widget. SDS is using the Model-View-Controller design pattern from the underlying framework GEF. Each class of a widget corresponds to one element: WidgetModel (Model) – Holds all available properties for the widget. WidgetFigure (View) – Sets appearance of the widget. WidgetEditPart (Controller) – Defines behavior for user actions and events. For each widget one or more initializers can be implemented. An initializer sets all default properties for each new widget created by the user on a display. In the preferences the type of initializer is selectable. ADL converter Each property of a widget can be dynamised. That means it is connected to a process variable (PV) and depends on the changing of the value. A very simple example is a dynamised text property showing the current value. The dynamisation of a property is indicated by a gear wheel. SDS Design Eclipse RCP CSS Core GEF/Draw2D SDS CSS App. Draw2dFigure NewWidgetFigure AbstractWidgetEditPart NewWidgetEditPart IWidgetModelNewWidgetModel SDS Workbench The SDS workbench is a combination of navigator, property view and the editor in CSS. It is offered as a CSS perspective. Navigator: shows all configuration files for SDS displays (and files for other CSS applications) organized in projects. It provides the standard Eclipse CVS support for revision control and group development of SDS displays. Dynamisation and Rules Action Alias WorkspaceEditor field Property View Widget palette SDS is built on Control System Studio (CSS) and the Graphical Editing Framework (GEF). CSS is a platform for any kind of control system applications. Like SDS CSS applications can be integrated as plugins in CSS. Because CSS is an Eclipse Rich Client Platform (RCP) it is operating system independent. The Eclipse open source project GEF and its part Draw2D provides an environment for layout, rendering and editing. Editor: shows a SDS display in editor mode. Unlike the run mode the channels are not connected to avoid accidentally updates. Functions like grid, ruler, alignment, match size for selected objects, … assist arrangement of widgets. On the right side of the editor is the widget palette with all available widgets. Property view: shows all properties of the currently selected widget in the editor. If more than one widget is selected only the common properties are displayed and can be changed for all widgets. ADL Converter is an application integrated in CSS for converting ADL in SDS displays. Control System PV 1 (Double) PV 2 (Double) DAL SDS Rule: Double → RGB Widget Color Property Widget Text Property Rules manipulate values from PVs before the dynamised widget property is updated. On the one hand rules are necessary to calculate a new value with another data type if the data types of PV an widget property is different. On the other hand with rules any manipulation or transformation is possible. There are two kinds of rules: Java rules are implemented as java classes in SDS plugins. To add or change java rules it is necessary to edit java code and build a new SDS application. Script rules are implemented as script files. Unlike java rules they are located in the workspace of CSS. Therefore the user is able to edit and create script rules in a running CSS instance. The disadvantage is the lower performance compared to java rules. Connection and Condition States can be visualized by every property of a widget. Each state is mapped to a special value of the property and shows the current status on the running SDS display. Like static widget properties the configuration of dynamisation and connection states can be set in initializers. EPICS Data Access Layer (DAL) EPICS PluginTINE PluginTANGO Plugin EPICS Plugin TINE EPICS Plugin CSS Plugin Data Access Layer (DAL) The Data Access Layer (DAL) is a layer to access dynamic data of control systems. It decouples the data access from the implementation for a specific control systems. DAL stores for each Process Variable (PV) characteristics to reduce the number of connections to the control system. Characteristics are meta data of PVs like resolution or display maximum. The DAL notation for a PV connection begins with the prefix for the control system. After the delimiter ‘://’ is the PV name. Optionally a characteristic can be added in brackets followed by the data type. In case a record is used frequently in a display or widget an alias can be defined for its name. To identify an alias it has to enclosed by character ‘$’. Aliases will be inherited to sub elements. E. g. aliases set for displays are available in all widgets and are overwritten if an alias with the same name is defined in a widget. With actions users can execute commands on displays in run mode. Actions are related to displays or widgets and will be inherited like aliases. There are two types of actions: Open as View/Shell: Open a new display from the workspace as a View or Shell. To reuse displays for similar facilities aliases can be passed to the new display. Send Value: Write a value to the control system.