CMS ECAL Endcap High Voltage PVSS System Expert Manual

Transcription

1 CMS ECAL Endcap High Voltage PVSS System Expert Manual v3.0 last updated: 26/08/2005 Maintained by: CMS Group CCLRC Rutherford Appleton Laboratory

2 Contents 1. Brief Introduction 3 2. Expert Configurations Section System Installation Device Configuration Datapoint FSM Unit Settings Trending (Plot) Panels and Parameters Control Scripts (Including Interlock) OPC Connection Configuration DB Access Control Archive and Runtime Database System Integration System Backup, Relocation and Install Update Hardware Change Problem Shoot General Information 52 Glossary 53 Appendix (Scripts) 55 2

3 1. Brief Introduction The control and monitoring of the high voltage, is based on the commercial software PVSS and a JCOP framework specifically developed for the LHC experiments. The structure of PVSS II Figure 1.1 Typical PVSS application structure A PVSS application is composed of several processes, in PVSS nomenclature: Managers. Event Manager (EV): the heart of the system, responsible for all communications. Database Manager (DBM): provides interface to the run time database (DB) User Interface Manager (UIM): 1) In application mode: graphical visualisation of messages received by EV, can get device data from DB and send data to DB to be send to devices; 2) Can also be run in a development mode. Control Manager (Ctrl): provide data processing in background by running a scripting language which complies with C syntax. Application Programming Interface Manager (API): allows user to write own programs in C++ using PVSS API to access the data in DB. Driver (D): provides interface to devices to be controlled. e.g. OPC client A PVSS System is an application containing one EVM, one DBM and any number of other managers. All PVSS applications, as well as the majority of PVSS tools, are essentially built of panels and scripts. Panels can be created using the Graphical Editor and may include static or dynamic (i.e. independent or dependent of datapoint elements) widgets. 3

4 JCOP Framework The JCOP framework is being developed in common for the four LHC experiments. It is based on PVSSII and provides guidelines and components for the different teams to build their control applications in a coherent manner. The most important component of the framework is the FSM, which is responsible for the abstract modelling of the physical/non-physical devices. Figure 1.2 Experiment Control System Structure The relationship between the framework and PVSS is illustrated in Figure 1.2. As can be seen on the right hand side, the FSM is built on top of PVSS while the latter communicate with the physical hardware via OPC/DIM protocols which serve as the interfaces. OPC connections are used for the CAEN hardware and more details can be found in Chapter 2.7 of this manual. The main tools for project management are: 1) Project Administrator, the control centre of all the existing projects; 2) Console - the control centre for a single project; 3) Graphical Editor - where all the development processes (including database management and operation panel design) are done; 4) Log Viewer - a record of all the process and error messages; 5) Device Editor Navigator: the main interface to the Framework 4

5 2.1 Software Installation The current agreement with ETM covers the LHC experiments. If you are working on or off the CERN site, but for an LHC experiment, you are eligible for a PVSS license and software. CERN IT-CO-BE The software is available from the CERN IT website: Follow all the online instruction for the PVSS installation process. A license is required to run the PVSS software properly, enquiry should be sent to ITcontrols.support@cern.ch. Installing PVSS: Extract the zip file and run the setup.exe in the English folder. Choose an installation path and follow the onscreen instructions. Project Creation: Firstly it would be useful to distinct the concept between 4 different Paths : PVSS Installation Path: It is the folder where the PVSS is installed; Project Path: It is the folder where everything related to a particular Project is stored (including scripts, panels, pictures etc), it is determined when the project is created (see below); Framework Component Path: It is where all the component of the JCOP Framework sit. This path is created when running the Framework installation from a Project for the first time. Framework Original File Path: It is the folder to store the extracted framework2.x.x.zip file. Start PVSS Project Administrator and create (Figure 2.1.1) a distributed project with: System number: 97 System name: CMS_ECAL_HV_EE In this process a Project Path will be chosen as the developer s choice. Figure

6 Framework Installation Download the latest framework from the CERN IT/CO website: Note: 2 files will be needed, one is the FW installation file (fwinstallation2.x.x.zip) and the other is the FW component file (framework2.x.x.zip). Extract the FW component file into a folder (this will be the Framework Original File Path). Unzip the FW installation file (fwinstallation2.x.x) into the project path (For the moment C:\PROJECTS\CMSECALHVEE_97, but depend on where the project is located in the control PC, note: NOT the PVSS path), replacing the existing folders. Figure Start project (by opening Project Console from PVSS Project Administration Panel, and press the green light button) and run fwinstallation panel (Figure 2.1.2) from Graphical Editor, by clicking on the open symbol and choose fwinstallation folder - > fwinstallation.pnl. Now select a destination directory, anywhere convenient, this is where the framework components will be stored (i.e. Framework Component Path). Look for new components in the Framework Original File Path s PVSS subfolder (Figure 2.1.3), make sure the framework version is the right one. Select the following 5 components (Figure 2.1.4) to install: 1. fwaccesscontrol 2. fwcaen 3. fwconfigurationdb 4. fwcore 5. fwtrending 6

7 Figure Figure After installing the components, follow the onscreen instruction and restart the project. Custom Managers: The following managers should have been added automatically after the project restart (Figure 2.1.5), IF not, then they have to be added manually by appending managers (using the button highlighted by the blue ring) with the following options: add Control manager (options: fwfsmsrvr, start mode: always) add Control manager (options: -f fwscript.lst, start mode: once) add OPC client (options: -num 6, start mode: always) add user interface (options: - fwdeviceeditornavigator/fwdeviceeditornavigator.pnl, start mode: always) 7

8 Figure CAEN HV Software: CAEN provides two software for the OPC communications: CAEN OPC Server and OPC Server Configurator. They both are downloadable from the CAEN website following the links: User may need to register on the CAEN website first to gain the privilege of downloading the software. Install both of them. The OPC server will run automatically whenever the windows is started (in the background) and the OPC configurator will be used later for connecting hardware to the PVSS system. 8

9 2.2 Device Configuration The following configurations are set via Device Editor Navigator (DEN, see Figure 2.2.6). Object Creation to Database: In Hardware View go to Editor Mode: 1. Create two CAEN SY1527 crates for the system, with names crateem for the endcap- and crateep for endcap+ (Figure 2.2.1) 2. Add one A1833 board per crate, naming convention: boardxx, actual xx is any number between 00-15, depending on position of board in crate. (Figure 2.2.2) Using two digits is obligatory due to the OPC specification. 3. Add eight channels per board: any number between channel000-channnel015, depending on the actual channel connected. Three digits are also required. (Figure 2.2.3). Alternatively, one can choose the also create children option in step 2, to make use of all channel slots in that board. Figure Figure

10 Figure Device Logical Alias: In DEN Logical View: Create tree nodes with Alias- 10

11 The top three layers correspond to the overall ECAL Endcap HV system, individual endcap sub-systems, and the eight quadrants, respectively. To create the first layer, left click on the system name (the first line), then right click on it, and choose add node on the new menu. The rule to create a lower layer is always to left click on the parent node first, then right click to add, otherwise there will not be a layers. At the base layer, add two corresponding channels under each quadrant node using add From Hardware (Figure 2.2.4), e.g. crateep channel000-channel001 for ECAL_HV_EPQ1 (Figure 2.2.5) etc. The channel supplying the VPT anodes should be given an Alias channela1 and the other supplying dynodes should be given channeld1. Should extra channel pairs need to be added to a quadrant, they will be called channela2-d2, A3-D3 etc. Figure

12 Figure The completed system in the three views of DEN should look like figure (the complete setup of FSM view is discussed in section 2.4). Figure

13 2.3 Datapoint In order to operate hardware devices from software, the very first thing to be done is to create a structure in the database to model the actual device behaviour. The device data in the PVSS database is structured as Data Points (DPs) of predefined Data Point Types (DPTs). PVSS allows devices to be modelled using these DPTs/DPs as such it allows all data associated with a particular device to be grouped together rather than being held in separate variables. A DPT describes the data structure of a device type (e.g. HV channel) and a DP contains the information related to a particular instance (e.g. channel1, channl2) of such a device. The DPT structure is user definable, with its hierarchy as complex as required. Each of the folders as well as the individual parameters are called Date Point Elements (DPEs). The DPE can be of various types, including float, integer, Boolean, string and dynamic array etc.. For example, in Figure the structure of DP CAEN/crateEM/board12/channel001, of DPT FwCaenChannel, is fully expanded, with its DPEs grouped in different folders actual, settings, readbacksettings etc.. Typically a DPE is connected to a specific aspect of a hardware, for example, to monitor the actual run time voltage of a HV channel, a DPE of a HV channel DP naming actual.vmon can be created. The DPEs can be seen as at the lowest layer in the PVSS system, as any process in the PVSS system wanting to communicate to the hardware is via these DPEs. In the OPC connections, it is the DPEs that will be connected to the OPC server s OPC items (see Chapter 3.8), therefore the operations on the DPEs can be treated as the operations directly on the actual hardware devices. There are also certain configs which enable specific behaviours to be configured for a DPE, these include the peripheral address (in this system, OPC item address), archive and alarm handling etc.. When a DPE is referred to in a panel or script, its full address is : System Name + DP name + DPE name. For example, the address of DPE setting.v0 of a HV channel DP CAEN/crateEM/board03/channel005 is: CMS_ECAL_HV:CAEN/crateEMboard03/channel005.setting.v0 A Graphical Parameterisation tool PARA is provided in PVSS to manage the database. Generally, it is where the creation and modification of DPTs and DPs should be done. Alternatively, control scripts can be used to do the same job, which is actually more convenient for a project containing a large amount of DPTs/DPs. In the Framework those control scripts are provided and graphically visualised in the Hardware View of the Device Editor Navigator (DEN). 13

14 Figure The hardware devices in this HV project are the CAEN crates, boards and channels. As they are also the common devices that will be used in the other LHC experiments, they are already pre-defined in the JCOP Framework, i.e. when installing the Framework the DPTs (FwCaenCrateSY1527, FwCaenBoardSY1527, FwCaenChannel) modelling the CAEN crates/boards/channels are automatically created in the PVSS database. For more detail on the CAEN DPT settings and functions, please refer to the CAEN OPC user documentation (as the DPEs of those DPs are all connected with the OPC server items, see Chapter 2.7). Note it is recommended not to modify the Fw datapoints as it may lead to version crash with the later Framework releases. Procedure of creating a Datapoint: 1. The first step is to create a Datapoint Type (DPT). Click on the Para button from Graphical Editor (Figure 2.3.1) to open the Parameterisation panel. Right click in the white blank area (i.e. do not choose any of the existing lines) of the table, choose Create datapoint type and give a name to the new DPT. The name should be a summary name of a class of object (e.g. HV channel etc). Do not close the small panel yet. 2. Define the structure of the newly created DPT. Left click on the DPT line and right click to choose Insert node. These nodes will be used to define a structure for this DPT and they will become the Datapoint Elements (DPE) of the Datapoints (DP) to be created. By right clicking on the nodes they can be defined to various types, e.g. the VoltageMonitoring node would be of type float and the On/Off node is of type Boolean etc. A node can also be a 14

15 folder, which can contain further layers of structure. After the full structure is designed, click OK to close the small panel and save all settings. 3. Create Datapoints (DP) of a particular DPT. Note that all PVSS applications operate on DPs rather than DPTs, the latter is just a blank structure and only the DPs has physical meaning in the Database. To create a DP, choose the DPT and right click on it, choose create datapoint option and give it a name, e.g. channel001, channel002 etc. Multiple DPs can be created in a similar way. 4. Now double click on the DPT and it should show all the DPs of its type, as can be seen all DPs contains a same structure which was defined when creating the DPT. That also mean in the future any change to the DPT content will be automatically inherited by all the DPs of the same type. Those DPEs of a DP all has unique addresses (mentioned above). As the scripts/dynamic graphical objects operate on these DPEs, it is necessary to know how to refer to them when programming. There are 2 DPTs specifically created for the EE HV system: CMS_ECAL_HV_EE_Interlock CMS_ECAL_HV_EE_OPCserverCrate The first DPT is used for storing interlock information. It contains 8 DPs: ECAL_HV_EMQ1-4, ECAL_HV_EPQ1-4, they all contains a same structure of 3 DPEs: interlocked, which indicates the quadrant is interlocked or not, and channela channeld, which indicates which Anode/Dynode pair has been interlocked. The scripts referring to these DPEs can be found in the EE_HV_Interlock.ctl (see chapter 2.7), and in the Quadrant panel (see chapter 2.6). The second DPT is used for storing OPC connection information. It contains 2 DPs: OPC_EM and OPC_EP. They both have a same structure of a single DPE: connected, which indicated whether the OPC connection of crate EM/EP is alive. The scripts referring to these DPEs can be found in the OPC_EP.ctl, OPC_EM.ctl (see chapter 2.7), and in the Main panel (see chapter 2.6). 15

16 2.4 FSM Unit Settings Comprehensive tools to create and configure the FSM units are also integrated in the Framework, they can be accessed from the Finite State Machine view of Device Editor Navigator (click on button Create/Configure FSM Object Types ). Figure shows the panel for creating Device Units (via Add Device Type) and Control Units (via Create Object Type). The unit types will appear in the list after creation, their properties are configured from specific panels. Device Unit: Figure The Device Unit configuration panel is shown in Figure States are created with names and colours standardised in order that the tree structures in different subdetectors/sub-systems can be integrated into a central Detector Control System tree properly. A set of conventions is defined by the Framework group. The states must be comprehensive to be able to represent all possible status of a HV channel. The states are connected to the Datapoint Elements actual.status of Datapoints of type FwCaenChannel, a reading from actual.status return a bit which correspond to one particular hardware channel status output, the bits and corresponding status is defined in CAEN OPC server manual. A control script (click on configure device -> configure device state -> edit script to see full script) is written to connect the states with the correct bits, this script is evaluated at the start-up of the state machine and whenever the data of the channel changes, thus when the channel data changes the Device Unit can change state accordingly. Having done all the above, the monitoring of the channels states is fully configured. For controlling, actions are added to appropriate states where required. In this system three actions are created: SWITCH_ON, SWITCH_OFF and RECOVER, they are connected to the boolean type DPEs setting.onoff of type FwCaenChannel Datapoints, as such they can switch on/off the channels when a command from the 16

17 parents or operator is received. This is done by writing a control script ( configure devise -> configure device actions -> edit scripts ) as shown in Figure Figure Control Units Figure The configuration on a Control Unit is slightly different: as they are not directly connected to the real hardware, there is no need to set up the connection to any DPE, instead its states is defined using logical operation on the states of its children. This is done by scripting in SML with a list of WHEN clauses (Figure 2.4.3). Each state has a unique set of WHEN clauses which is carefully designed so that any change in the children state will only result in a single state in the parent (the system may crash when the parent is both ON and OFF!). Like the scripts for DUs, these clauses are evaluated whenever a State of a child changes. The settings on the DCSNode is relatively simple, it only has five states: ON, OFF, NOT_READY, WARNING and ERROR (note these are different from the states in FwCaenChannelStd), with three actions: SWITCH_ON, SWITCH_OFF and 17

18 RECOVER, these actions will propagate all the way down to the DUs. The detailed WHEN clauses for state transitions can be found by clicking on the State name and double clicking on one of the when lines. The QuadrantNode is the busiest unit in the tree, as mentioned above the States defined in DCSNode differ from those in FwCaenChannelStd, the role of QuadrantNode is to summarise the states of FwCaenChannelStd into different classes and translate them upwards to DCSNode. There are also three actions defined for this unit: SWITCH_ON, SWITCH_OFF and RECOVER FSM Hierarchy Creation: Figure Having created and configured the Unit types, the next step is to group them together to form a complete FSM tree structure. The FSM tree is created from the FSM view in the DEN. The naming on the tree nodes are defined in the CMS database, and it is rather similar to the aliases in the Logical View, the creation is done in four steps: 1) At the top level, ECAL_HV_EE is added as a CU of type DCSNode, it serves as the system top node; 2) The second level contains ECAL_HV_EM and ECAL_HV_EP, which represent the two endcaps, they also are of type DCSNode; 3) At the third level, four nodes are added under each endcap node, they are of type QuadrantNode. The structure and names are identical to the quadrant alias in the logical view. (as the above Control Units are not directly linked to the hardware, they are fully configured) 4) The channel DUs are added at the button level. The addition of the Device Units is different, because they have to be selected from the Logical View so that the Units know exactly which hardware channel they are connected to. 18

19 Two FwCaenChannelStd Device Units is added from logical view under each quadrant (Figure 2.4.4), with layout similar to the Logical View. Figure Finally, in navigator mode, type in the DNS address of the pc where the project is running. The overall system and the two endcap sub-systems are modelled as Device Units of Type DCSNode. The characteristics of the DCS are shown in the following table: State Actions State Transitions PHYSICS OFF NOT_READY WARNING ERROR SWTICH_ON SWTICH_ON SWTICH_ON SWITCH_OFF SWITCH_OFF RECOVER when ( $ANY$FwCHILDREN in_state ERROR ) move_to ERROR when ( $ANY$FwCHILDREN in_state WARNING ) move_to WARNING when ( $ANY$FwCHILDREN in_state NOT_READY ) move_to NOT_READY when ( $ANY$FwCHILDREN in_state OFF ) move_to NOT_READY when ( $ANY$FwCHILDREN in_state ERROR ) move_to ERROR when ( $ANY$FwCHILDREN in_state WARNING ) move_to WARNING when ( $ANY$FwCHILDREN in_state NOT_READY ) move_to NOT_READY when ( $ANY$FwCHILDREN in_state ON ) move_to NOT_READY when ( $ANY$FwCHILDREN in_state ERROR ) move_to ERROR when ( $ANY$FwCHILDREN in_state WARNING ) move_to WARNING when ( $ALL$FwCHILDREN in_state OFF ) move_to OFF when ( $ALL$FwCHILDREN in_state ON ) move_to PHYSICS when ( $ANY$FwCHILDREN in_state ERROR ) move_to ERROR when ( $ALL$FwCHILDREN in_state OFF ) move_to OFF when ( $ALL$FwCHILDREN in_state ON ) move_to PHYSICS when ( $ALL$FwCHILDREN in_state OFF ) move_to OFF when ( $ALL$FwCHILDREN in_state ON ) move_to PHYSICS 19

20 The only physical unit (Device Unit) type in the system is FwCaenChannelStd, which model the behaviour of all the CAEN channels. The characteristic of the Device Unit FwCaenChannelStd is as follows: State Action(s) DPE connected Value Class ON SWITCH_OFF State: actual.status 1 PHYSICS Action: settings.onoff 1 OFF SWITCH_ON State: actual.status 0 OFF Action: settings.onoff 0 RAMPING_UP SWITCH_ON State: actual.status Bit 1 NOT_READY SWITCH_OFF Action: settings.onoff 0,1 RAMPING_DOWN SWITCH_ON State: actual.status Bit 2 NOT_READY SWITCH_OFF Action: settings.onoff 0,1 OVER_CURRENT SWITCH_OFF actual.status Bit 3 WARNING OVER_VOLTAGE SWITCH_OFF actual.status Bit 4 WARNING UNDER_VOLTAGE SWITCH_OFF actual.status Bit 5 WARNING EXTERNAL_TRIP actual.status Bit 6 ERROR OVER_HVMAX actual.status Bit 7 ERROR EXTERNAL_DISABLE actual.status Bit 8 ERROR INTERNAL_TRIP RECOVER State: actual.status Bit 9 ERROR Action: settings.onoff 1 CALIBRATION_ERROR actual.status Bit 10 ERROR UNPLUGGED actual.status Bit 11 ERROR UNDER_CURRENT SWITCH_OFF actual.status Bit 12 WARNING OVER_V_PROTECTION actual.status Bit 13 ERROR POWER_FAIL actual.status Bit 14 ERROR TERMPERATURE_ERROR actual.status Bit 15 ERROR 20

21 The Control Unit type QuadrantNode represents the modelling of the Quadrants, it serves as a bridge summarising the states of type FwCaenChannelStd and propagating them upwards to type DCSNode. The setting on this type is the most complicated and its characteristics is as follows: State Actions State Transitions PHYSICS OFF NOT_READY SWTICH_ON SWTICH_ON SWTICH_ON SWITCH_OFF when ( ( $ANY$FwCHILDREN in_state UNPLUGGED ) or ( $ANY$FwCHILDREN in_state EXTERNAL_TRIP ) or ( $ANY$FwCHILDREN in_state EXTERNAL_DISABLE ) or ( $ANY$FwCHILDREN in_state INTERNAL_TRIP ) or ( $ANY$FwCHILDREN in_state CALIBRATION_ERROR ) or ( $ANY$FwCHILDREN in_state OVER_V_PROTECTION ) or ( $ANY$FwCHILDREN in_state POWER_FAIL ) or ( $ANY$FwCHILDREN in_state TEMPERATURE_ERROR ) or ( $ANY$FwCHILDREN in_state OVER_HVMAX ) ) move_to ERROR when ( ( $ANY$FwCHILDREN in_state OVER_CURRENT ) or ( $ANY$FwCHILDREN in_state OVER_VOLTAGE ) or ( $ANY$FwCHILDREN in_state UNDER_CURRENT ) or ( $ANY$FwCHILDREN in_state UNDER_VOLTAGE ) ) move_to WARNING when ( ( $ANY$FwCHILDREN in_state RAMPING_UP ) or ( $ANY$FwCHILDREN in_state RAMPING_DOWN ) ) move_to NOT_READY when ( $ANY$FWCHILDREN in_state OFF ) move_to NOT_READY when ( ( $ANY$FwCHILDREN in_state UNPLUGGED ) or ( $ANY$FwCHILDREN in_state EXTERNAL_TRIP ) or ( $ANY$FwCHILDREN in_state EXTERNAL_DISABLE ) or ( $ANY$FwCHILDREN in_state INTERNAL_TRIP ) or ( $ANY$FwCHILDREN in_state CALIBRATION_ERROR ) or ( $ANY$FwCHILDREN in_state OVER_V_PROTECTION ) or ( $ANY$FwCHILDREN in_state POWER_FAIL ) or ( $ANY$FwCHILDREN in_state TEMPERATURE_ERROR ) or ( $ANY$FwCHILDREN in_state OVER_HVMAX ) ) move_to ERROR when ( ( $ANY$FwCHILDREN in_state OVER_CURRENT ) or ( $ANY$FwCHILDREN in_state OVER_VOLTAGE ) or ( $ANY$FwCHILDREN in_state UNDER_CURRENT ) or ( $ANY$FwCHILDREN in_state UNDER_VOLTAGE ) ) move_to WARNING when ( ( $ANY$FwCHILDREN in_state RAMPING_UP ) or ( $ANY$FwCHILDREN in_state RAMPING_DOWN ) ) move_to NOT_READY when ( $ANY$FwCHILDREN in_state ON ) move_to NOT_READY when ( ( $ANY$FwCHILDREN in_state UNPLUGGED ) or ( $ANY$FwCHILDREN in_state EXTERNAL_TRIP ) or ( $ANY$FwCHILDREN in_state EXTERNAL_DISABLE ) or ( $ANY$FwCHILDREN in_state INTERNAL_TRIP ) or ( $ANY$FwCHILDREN in_state CALIBRATION_ERROR ) or ( $ANY$FwCHILDREN in_state OVER_V_PROTECTION ) or ( $ANY$FwCHILDREN in_state POWER_FAIL ) or ( $ANY$FwCHILDREN in_state TEMPERATURE_ERROR ) or ( $ANY$FwCHILDREN in_state OVER_HVMAX ) ) move_to ERROR when ( ( $ANY$FwCHILDREN in_state OVER_CURRENT ) or ( $ANY$FwCHILDREN in_state OVER_VOLTAGE ) or ( $ANY$FwCHILDREN in_state UNDER_CURRENT ) or 21

22 WARNING ERROR SWITCH_OFF RECOVER ( $ANY$FwCHILDREN in_state UNDER_VOLTAGE ) ) move_to WARNING when ( $ALL$FWCHILDREN in_state OFF ) move_to OFF when ( $ALL$FwCHILDREN in_state ON ) move_to PHYSICS when ( ( $ANY$FwCHILDREN in_state UNPLUGGED ) or ( $ANY$FwCHILDREN in_state EXTERNAL_TRIP ) or ( $ANY$FwCHILDREN in_state EXTERNAL_DISABLE ) or ( $ANY$FwCHILDREN in_state INTERNAL_TRIP ) or ( $ANY$FwCHILDREN in_state CALIBRATION_ERROR ) or ( $ANY$FwCHILDREN in_state OVER_V_PROTECTION ) or ( $ANY$FwCHILDREN in_state POWER_FAIL ) or ( $ANY$FwCHILDREN in_state TEMPERATURE_ERROR ) or ( $ANY$FwCHILDREN in_state OVER_HVMAX ) ) move_to ERROR when ( $ALL$FWCHILDREN in_state OFF ) move_to OFF when ( $ALL$FwCHILDREN in_state ON ) move_to PHYSICS when ( $ALL$FWCHILDREN in_state OFF ) move_to OFF when ( $ALL$FwCHILDREN in_state ON ) move_to PHYSICS To append a PVSS Panel on a FSM node, go to DEN FSM view, enter Editor mode, click on the required FSM tree node and choose settings, then select a panel. For which panel correspond to which FSM node, please refer to chapter

23 2.5 Trending (Plot) Development: All plots are called trendings in the PVSS terminology. In the HV system, trendings are used to display the current and voltage values over time. Trendings use reference parameters that will be replaced by actual variables in different instances i.e. different voltage channels. Figure Figure

24 The Trending development panel can be opened from Graphical Editor (Figure 2.5.1). Press Run panel button and choose the Framework Component Path (normally the 2 nd line), then open folder fwtrending, among the files there is a fwtrendingmanagechildren panel, now open it. A panel as shown in Figure will be opened. After choosing the right required type of plot, press create. The plots used in the HV channel operation panels are of type Trending Plot (value over time). Trending in channel operation panels (Figure 2.5.3): Create plot with name Plot_ivMon. In the DP Element column type in sdpname.actual.imon and sdpname.actual.vmon respectively, sdpname being the reference parameter in this plot, it will be replaced by the actual channel name in the channel operation panel. Runtime Control: Figure The main plot window (Figure 2.5.4) display the runtime values of the channel voltage (in blue) and current (in red), the latest values are also displayed underneath the plot. If the two elements are archived the history values can also be displayed by adjusting the display time range. There are five tabs for the plot control: 1. Freeze/Run: Plot can be frozen to be manoeuvre arbitrarily (with Controls function in the Other tab); 2. Time Range: Set start time and end time of the plot; 3. Y Axes: display the scale of Y axes (blue for voltage and red for current); 4. Save Settings: Save all the current settings- including time range, scale etc as default for all plots in the system; 24

25 5. Other: Including functions Zoom (to enlarge plot), Export, Controls (to manoeuvre plot in the Freeze condition) etc. Figure The purpose of the trending is to display the overview of channel behaviour in a time interval, thus it may not be easy to read an exact value of a particular time stamp. Therefore if exact reading is required, it is advised to use either the Event Panel (see chapter 2.11) 25

26 2.6 Panels and Parameters A main feature of PVSS is to visualise all the processes, that is to hide the complex scripts behind the graphical objects. The architecture of PVSS is based on Object Oriented Technology, thus it allows a panel to be recalled at many different instances, this is done by representing the variables in the panel scripts as $parameters, when a panel is referenced its $parameters are replaced by the actual desired values. In this system we will classify the panels into three classes: 1. Operation panels 2. Reference panels 3. Widgets Operation panels are those which will be displayed in the FSM view, Reference panels are those used as components of Operation panels, and the Widgets are the fundamental parts of the Reference panels. Operation Panels are stored in folder project_path\panel\cms_ecal, they are the usable panels to be opened to work along with the FSM tree, and they all contains Reference Panels. Reference Panels are stored in folder project_path\panel\objects\cms_ecal, they basically look the same as the Operation Panels, however, they only contain the undefined parameter values which when being referred in the Operation Panels, will become a known variable. (e.g. the parameter $schannel can be replaced by channel1 in the reference process) Widgets are stored in project_path\panel\objects\cms_ecal\widgets, they are essentially the reference panels within another reference panels, therefore they are the most basic units in the panel composision. Development work is done in the PVSS Graphic Editor (Gedi) (Figure 2.6.1), it is implemented as a PVSS manager can be started from the PVSS Console (Figure 2.1.5). To edit a graphical object property, double click on the object and a property sheet will appear on the left hand side. It contains two tabs, the Normal allows the change of normal properties like text content, size, colour etc. The Events tab allows dynamic functions to be attached to the objects, to respond to user action or changes of Datapoint values. Double clicking on one line on the table in the Events tab (which line to click depends on when the action should be triggered i.e. when panel open, when double click, single click etc.) will bring out a wizard (Figure 2.6.2), it will direct user to different options. Note: when using the wizard the graphical objects should always be connected to a Datapoint Element rather than a Datapoint, it should be, for example, channel1.actual.vmon rather than channel1. Alternatively if more complicated script is needed, which is beyond the scale of the wizard, one should directly right click on that graphical object (or background if the action is object independent), and choose Events, this will open a script editor panel (Figure 2.6.3). The right cascade button allows developer to choose when to trigger the script (basically the same as the table in the wizard. 26

27 Figure Figure If the chosen graphical object is a reference, the property sheet on the left is different: rather than allowing the change of properties, it only shows the reference panel name/location, along with the reference parameters and their substitutions (Figure 2.6.1). 27

28 Figure The following tables show the details of individual panels: Operation Panels Panel Name Reference-Panel(s) Parameters and substitutions EEHV_Main EEHV_Main_ref $ssystem: CMS_ECAL_HV_EE $scrate: EM, EEHV_EM EEHV_EM_ref $ssystem: CMS_ECAL_HV_EE $scrate: EP EEHV_EP EEHV_EP_ref $ssystem: CMS_ECAL_HV_EE $1: $1 EEHV_Quadrant EEHV_Quadrant_ref $ssystem: CMS_ECAL_HV_EE $1: $1 $2: $2 EEHV_Channel EEHV_Channel_ref $sdpname: $2 $ssystem: CMS_ECAL_HV_EE Description Main EEHV Operation Panel Endcap EM Operation Panel Endcap EP Operation Panel Quadrant Operation Panel Channel Operation Panel 28

29 Reference Panels Panel Name Reference-Panel(s) Parameters and substitutions Description EEHV_Main_ref EEHV_EM_ref EEHV_EP_ref Led_1 x 3 $scrate: EM/ EP $ssystem: $ssystem $dpe_value: $ssystem:_caenopcserver.connected (client-server) $dpe_value: $ssystem:opc_em.connected (server-em) $dpe_value: $ssystem:opc_ep.connected (server-ep) System main information panel EEHV_EM_ref EEHV_bar_double x 4 EEHV_Button_ExtraCH x 4 EEHV_QuadrnatLED x 4 EEHV_Button_OpenQuad x 4 $schannel1: A1 $schannel2: D1 $squad: Q1 / Q2 / Q3 / Q4 (anticlockwise, staring from upper left quadrant) $scrate: $scrate $ssystem: $ssystem Endcap EM information panel EEHV_EP_ref Same as above As above Endcap EP information panel EEHV_Quadrant_ref N/A N/A Quadrant information display EEHV_Channel_ref fwtrendingfaceplate $sdpname: $ssystem:plot_ivmon $templateparameter: sdpname=$2 Channel information display 29

30 Widgets Widget Name Reference-Panel(s) Parameters and substitutions Description EEHV_bar_double EEHV_bar_single x 2 $f_max: 800/600 $f_min: 0/0 $sad: Anode/Dynode Channel Pair voltage bars EEHV_bar_main N/A N/A Bar open channel panel mechanism EEHV_bar_single EEHV_bar_main $Dire: 1 $Num: 1 $b_ibit: $b_pvrange: $b_showalert: $dpe_value: $s_col: 0,0,175 Single channel voltage bar EEHV_Button_ExtraCH EEHV_Button_OpenQuad EEHV_QuadrantLED N/A N/A Indicator of Quadrant Extra Channel N/A N/A Button for opening Quadrant panel N/A N/A LED for quadrant status summary 30

31 2.7 Control Scripts (Including Interlock) PVSS Control script can be used in panels (as mentioned in chapter 2.6) or as standalone processes. These scripts comply to the C syntax. PVSS provides a large library of functions and some examples of use can be found in the PVSS Online Help. The three key functions for datapoint access are: dpget(): Get the current value of a DPE from the database once. dpset(): Set the current value of a DPE to DB. dpconnect(): Execute a call-back function when the value of a DPE change, to update the DPE value continuously. The two main functions for graphical functionality are: getvalue(): Get a property of a widget, like the, colour, size and the text etc. setvalue(): Set a property of a widget. If scripts have to be run all the time independent of panel, it should be created as a Control Manager. This can be done in two steps: 1. Create a.ctl file in ther folder project_path\scripts\cms_ecal, use WordPad (Figure 2.7.1) to open the file and edit the content and save it. 2. In the PVSS console, append a new Control manager (Figure 2.7.2), in the Options field, enter the name of the control file, including the folder name CMS_ECAL, for example, CMS_ECAL\AD_Interlock.ctl for the interlock script. Then choose a start mode: always mean the script will run continuously after project start up, manual mean it will run when user switch the manager on (but does not start automatically with project), while once mean the script will run once after the project start up and then stop until user switch it on again. At the moment there are three Control Managers specific for the HV system, as can be seen from the PVSS console: EE_HV_Interlock.ctl: scripts for interlocking a pair of channel if voltage different exceed 200V or if either channel trip. Start_FSM.ctl: Run DNS.exe and start all Finite State Machines. OPC_Mon.lst: this is a list file containing two ctl files OPC_EM and OPC_EP, they monitor the OPC connection between server and the two crates, respectively. Those scripts can be found in folder project_path\scripts\cms_ecal. One advantage of using the scripts as control managers is: they can be turned on/off deliberately, for example the Interlock can be turned on during operation and off during testing to allow the ramping of a single channel.

32 Figure Figure

33 2.8 OPC Connection The hardware connection mechanism depends on the type of devices being used and in the CAEN HV case the OPC protocol will be used. OPC is based on Microsoft s COM/DCOM technology, which means the OPC Clients/Servers can only be run on the Windows platforms. The communication between the PVSS system is via OPC protocol. There are two layers of connections: 1. Connection between PVSS (as an OPC client) and OPC server 2. Connection between OPC server and the HV crate The OPC server is provided by the hardware manufacture CAEN. An OPC server is an abstract layer between the user and the actual hardware, it provides a set of OPC items of the data available from the hardware and the commands they can receive. OPC items are in a way very similar to the DPEs in PVSS. When a HV device (crate, board) is connected to the OPC server, OPC items corresponding to the device data are automatically generated in the server. 1. Status Monitoring: The status of the connections is monitored from the lower left corner of the system master panel. Connection 1 is done automatically when the PVSS project is started up. In case of error i.e. the LED turns red, open the Windows Task Manager and stop the CAENHVOPCServer.exe, the process will automatically start up again in a short while and the connection will resume. There is currently no direct monitoring on connection 2 from the database. The makeshift solution is to monitor the fan speed of HV crate and if the value is not updated for a few second the connection is assumed to be lost. If the LED stays red for over 30 seconds, try to follow the same process as to connection 1. At the same time open the CAEN HV OPC Server Configurator (go to Start -> All Programs -> CAEN -> HV OPC Server Configurator, and check that the P.S.Name s are the same as the crate names in the DEN Hardware View, and the IP addresses are correct (this can be done by checking the status next to the address: ok is the correct state provided the crate is on, while ko is the error state). If any of those values is wrong, it is necessary to turn off the PVSS project and remove the incorrect entry in the OPC Server Configurator, replace it with a new entry, an example is shown in Figure

34 Figure OPC Connection settings: In the DEN, click on the Editor Mode in the Hardware View, then right click on the crate name and select Settings in the cascade box (Figure 2.8.2). A Mass Configuration Panel (Figure 2.8.3) will pop up. Click on Search and wait till the table is filled with full search results (Figure 2.8.4), now choose Set next to Hardware connection and the connection between OPC client (PVSS) and OPC server is automatically set up. Repeat the same process for all the crates in the system. Figure

35 Figure Figure

36 Note: The connection between the client and server is established by bridging the OPC client (PVSS) item addresses to the OPC server item addresses. The former is generated when the devices are created in the DEN hardware view, and the naming is related to the device name in the view. The latter is automatically created whenever the crate is connected (i.e. not static) to the server via network, the naming on the server item addresses is fixed by CAEN firmware and is unchangeable. That mean the name to the devices in the DEN is constrained by the OPC specification. The general rule is: board names are always board + two digits which start from 00 (note: not 01), and the channel names are channel + three digits starting from 000. Also note that if the PVSS system is turned on before the HV hardware is on, the OPC connection will not establish correctly. If this is the case, one needs to turn on the hardware and repeat the setting instruction as shown above. The way to avoid this is always turn on the hardware first before turning on the software. 36

37 2.9 Configuration Database The configuration database stores entities to start up a run and has the potential of becoming a very large database. It should be accessible to DAQ, DCS, and the detector monitoring systems. This database should contain information that is necessary to bring each system to operational state. It should also contain information for other components necessary for data taking. Static configuration data: Config data that does not change or change only infrequently and certainly not on a run by run basis, e.g. DPT structure, DPs, hardware addresses, geographical locations, which process run on which machine etc. Changes in this data typically follow a hardware intervention. There are two sub-types of static config data: System static configuration data: correspond to the overall control system, e.g. framework version installed, which process run where, which managers/drivers are running etc. Device static configuration data: directly related to devices, e.g. device structure, instances of devices, address configuration etc. (DPT and DP appear in both types of static config data.) Dynamic configuration data: configuration data which may change frequently e.g. alarm limits, hardware settings, archive settings etc. Recipe: set of dynamic configuration data for a particular device. The development on an external configuration database is currently underway by the central CMS DCS persons and a trial version had been installed with the barrel HV system for testing purpose. Once positive result is obtained the tool kit for interfacing PVSS and the database will be distributed to different sub-systems. 37

38 2.10 Access Control The main aim of the access control component is to secure the system against nonmalicious attacks. It is not possible to effectively secure the system against malicious attacks. Key words: Domain: user defined grouping of objects e.g. sub-detectors. For each domain there will be a list of privileges defined. Groups: with privileges (in one or more domains) corresponding to specific roles Users: can be allocated privileges through association with a particular group Every user has to log in when starting the system, it should not matter whether the operation panel is already opened or not. When leaving the system the current user must log out. The current Access Component in the Framework has just been rewritten and it is still very buggy and not very well integrated into the whole PVSS system. It is an area requires further developments. 38

39 2.11 Archive and Runtime Database By default there are five runtime databases in PVSS, namely Five-minute Archive, Hour Archive, Day Archive, Command Archive and State Archive, ranging from high-definition short time storage to low-definition long time storage. New archive can be custom-made for special purpose. There is currently no official document on what data and how the system monitoring data should be archived. The archives will need to be continuously tested to evaluate the optimum balance between record resolution and disc space consumption, and if needed, custom archives should be created. There are several ways to set up the archive, the normal way is to configure the archive config of the actual.vmon and actual.imon DPEs in the PARA tool, but it can take a long time for a large system. There is a mass configuration tool provided in the Framework and from here the archive of several DPEs can be configured in one step. To access the Mass configuration tool, go to the DEN Hardware view in Editor mode (Figure ), right click on a node. Which node to click depends on requirement, for example if I want to config all the channel in crateem then I should click on the node crateem. Choose settings. Then the Mass Configuration panel will be opened. Figure

40 Figure Figure

41 Since the archive mass setting only work for a group of Datapoints (DP) of the same type (DPT), it is necessary to use the filter out the other components (for example by choosing device type CAEN Channel, only the channel will be displayed). And then press search. A list of available channels should appear in the table below and check that all the channels waiting to be configured are included. Then choose the Datapoint Elements (DPE) to be archived, for example voltage/current etc. And finally, press set archiving. (Figure ) The new window is the Archive Config panel (Figure ), choose configure and select one of the available archive class (depends on which one is required, for information regarding internal settings of different archive class, please refer to the PVSS Online Help). Now all the settings are done, but the archive may not be turned on straight away, so one should go to the project Console (Figure ). The number of the Archive Manager correspond to the number next to the archive class choices in Figure , therefore if a particular archive class is used for archiving, the corresponding Archive Manager also need to be turned on. To do so, double click on the Archive Manager and choose the start mode to be always in the new window. Figure To view the archive values, one can use the Event Screen (Figure , accessible from EEHV system Main panel). By clicking on the Property button at the bottom, one can open a new window to choose which datapoint to display, at what time range etc. Remember to press the Run button to see the value being updated. 41

42 Figure

43 2.12 System Integration General Distributed systems (comprising two or more component systems, where each system is a run-time instance of a project) in PVSS II allow to connect two or more independent PVSS II systems via a network. A sub-system mean in this connection means a server on which an Event manager is running on. In a redundant system both redundant running servers are considered as one system. In the distributed system, each system can process and display data (values and alerts) of other systems. It is also allowed to access online values, alerts and history of each system by using distributed systems in PVSS II ("distributed database"). Requirement: An appropriate License for distributed systems. The same PVSS version (v3.0 for the moment)has to be installed on all subsystems. The configuration of the languages on all systems has to match. Distributed Manager (DistM): The Distribution Manager is the interface, providing the logical connection to all Dist managers of other PVSS sub-systems within the same distributed network. Only the Dist manager is responsible for the communication between the sub-systems. Thus, the Dist manager has to be added to the console and started. The distributed systems are parameterized easily when creating a project by using a wizard, its detailed configuration will be discussed later. Each system in a distributed system has to have a unique system name and a unique system number. The manager number of the Dist Manager is assigned automatically when the Data Manager starts. This means also the number of the particular system. DP Name (Identifier): The DP identification of the systems are exchanged when a sub system and the Dist Manager start. Each datapoint name in PVSS II contains as first part the system name (default is the own system). All datapoints within a sub-system contain the same system name. Thus each involved system has to have a unique system name and a unique system number. Datapoints of remote systems are addressed specifically by adding the system name and a colon (e.g. CMS_ECAL_HV_EE: ). All scripts and 43

44 all panels that should process or display data of other systems have to use complete datapoint names. The data of other systems is accessed like the data of the local system (the connected systems and DPTs/DPEs are visible in the PARA module). Datapoints of remote systems are not copied to the local system. Thus, it is only possible to access the remote data when the connection to the specific system exists (when the connection to the sub system is lost queries are not possible anymore) - only active queried information is transferred. Topology of a distributed system: In PVSS II V3.0, all systems are always able to act as servers, accepting incoming connection requests from elsewhere. However, Distributed systems in PVSS II can also be structured hierarchically: one system is on the top of the hierarchy, the further systems are located in the levels below. The system on the top is the "server" and the systems below "clients". This structure simplifies considerably the parameterization of distributed systems. Note that the client/server roles are only applicable to who establishes a connection with whom. Once a connection is established it is bi-directional, i.e. both systems at either end of the connection can see each other. Thus, the parameterization of the connection in one direction is sufficient. In PVSS V3.0 indirect connections are not possible. If Pc3 wants to connect to Pc1 then it has to make an explicit connection. The fact that Pc3 is connected to Pc2 and that Pc2 is already connected to Pc1 is irrelevant. Project Configuration Edit the following two lines into the config file (Figure ) of every project: [general] distributed = 1 This ensures that each system will start up as a server to (i.e. willing to accept connections from) any other system. Now specify which system(s) we want each of the systems in turn to connect to. Edit the client system s config file inserting a [dist] section and one line for each connection to be established. For example, if Project 2 on Pc2 want to connect to the Project 1 in Pc1, in Project 2 on Pc2 we insert the following lines: [dist] distpeer = "Pc1" 1 #Connect to Pc1 s system, numbered 1 44

45 If a fully interconnected system is required (i.e. without a hierarchy), then the dist entries for all of the system config files can be the same. All of the connected projects will then operate as Servers and Clients in establishing the initial connections. An example of such a config file is: [general] distributed = 1 [dist] distpeer = "Pc1" 1 #Connect to Pc1 s system, numbered 1 distpeer = "Pc2" 2 #Connect to Pc2 s system, numbered 2 distpeer = "Pc3" 3 #Connect to Pc3 s system, numbered 3 FSM Integration Figure After setting up the distributed manager correctly, the system is fully distributed at the PVSS layer. For the integration of FSM component of the framework, more settings have to be done. In order that the top system in the hierarchy can display the correct states derived from the child-systems, all the children have to have the same definition on the states and the method them being propagated. This issue will need to be discussed between the sub-system developers. 45

46 2.13 System Backup, Relocation and Install Update Backing up: To back up the whole system, the best way is to stop the project, go to PVSS Project Administrator, choose the project to be backup and click on Copy project (Figure ). Choose a name and a path for the copy. In order to run a project (the new one), it has to be registered, however if it is can still be registered manually later if it is not chosen now (the register button is just next to the copy project button. Relocating: Figure If any of the following path is changed: PVSS Installation Path, Project Path, Framework Component Path (see chapter 2.1 for definition), the project config file need to be modified. To open the config file, go to PVSS Project Administrator, choose the project line and click on the Change project properties and choose edit config file in the new window (Figure ), then open the config file. The first 3 lines in the scripts (Figure ) determines the three paths mentioned above, if any one of them is changed, just change type in the new path and save the file. Then the project should be able to start up properly. 46

47 Figure Figure Installing Update: Updating is essentially the same process as mentioned in Framework Installation section in chapter 2.1. But remember to backup the system before installing new updates. 47