Installation panel / Commissioning controller

v01 – May 13, 2005

Andrew Haas and Dominik Dannheim

Columbia University

Introduction

Installation of the FEBs will require a series of tests to be performed on each crate, both in the EMF and down on the detector, to insure that the boards are installed correctly and are functioning properly. The Installation panel is a Java plugin panel to the TDAQ GUI which automates these installation tests into a small number of pass/fail steps. The full tests can thus be performed easily by a non-expert.

Where necessary, certain tasks are performed behind the scenes by the Commissioning controller, a C++ plugin to TDAQ. For instance, interaction with HFEC library for communicating with the hardware and certain data analysis tasks are more easily performed from within the C++ environment. Communication between the Java panel and the C++ plugin takes place through the IS server, which allows for information to be posted, and callbacks for information to be registered.

Use

Upon starting the TDAQ GUI, the Installation panel appears as a panel which is selected by clicking on the tab called “InstallationPanel”. The panel has instructions in text to the right of each of the 5 buttons, which outline a step to be performed by clicking on the button. The steps can only be performed in order, starting with the step at the top (Boot). Pressing a more advanced button before a previous task has been completed successfully will do nothing. During each step, any warnings or errors will be displayed in the MRS message window at the bottom of the GUI. If the step succeeds, the button takes on a green light, but if the step fails, a red light appears on the button. In this case, the MRS errors should be read carefully, the problem corrected, and the button should be pressed again.

Here are the 5 steps:

Boot
This first step loads all the necessary software controllers, such as the ROD/ROS and the Commissioning controllers. The Commissioning controller starts cycling the FEB LEDs in order. This should be checked visually on the crate itself. IF the LEDs are not in order, then the SPAC addresses on the boards are swapped, compared to what is entered in the database. This should be corrected, either on the boards or in the database, before continuing to the next step. Due to the need for visual inspection, this step can not be fully automated, so the panel trusts the user to check the lights before continuing to the next step.

Configure
When the next button is pressed, the FEB lights will stop cycling. The FEBs are fully configured, and the controller checks that the gain settings can be read-back correctly. The controller also starts reading the DCU values for all of the FEBs, and publishing the info in IS.

DCU Values
The Java panel checks the DCU values against hard-coded limits, and will show either a red or green light for this step depending on whether the DCU values for all FEBs are within acceptable ranges or not. If a red light is shown, check the MRS messages for warnings which will indicate which board is out of range, and for which DCU value. Correct the problem, and push the DCU values button, to clear the previous error state.

Pedestal checks
A series of runs is started, which configures the FEBs' gain settings, and takes noise data from all of the FEBs. The average level of noise (the pedestal) should be within a well-defined limit, and so should the RMS of the noise value from sample to sample. A series of plots are displayed to the screen from ROOT, showing the pedestal means and RMSs for each channel of each board in each of the 3 gains. Channels which are out of range are highlighted in red.

Calibration checks
A series of runs is started, which configures the FEBs and calibration board, and takes calibration data from all of the FEBs. Again, a series of plots are displayed to the screen from ROOT, showing the calibration for each channel of each board in each of the 3 gains. Channels which are out of range are highlighted in red.

Code

The Installation panel extends the IGUIPanel class from the TDAQ library. The code is located in the MobileDAQ library of the LargOnline release.

Each of the buttons is connected to a class such as “Presser 1” which implements the MouseListener interface. Buttons change which icon they are displaying (red, greed, etc.) using the setIcon function.

Commands are sent to the DSA supervisor commander in order to change the TDAQ state. A “Commander” is instantiated with the partition name given as an argument.

The panel registers with the IS to receive a callback whenever any IS info of the name “*STATUS” or “*STATUS_SPAC” is updated. These fields contain all the info about DCU values from the FEBs.

The panel also registers to receive the new TDAQ state whenever the state is changed. This is used for determining when configuration has succeeded, or a run has ended, etc., so that new actions can be taken. One detail is that certain actions must be taken in a separate thread, so that this thread can sleep while waiting for a new state to be reached, while the main thread is still able to update the state. The new thread is called “CommanderThread” and extends the “Thread” interface by implementing the “run()” method. When the run() command has completed, the thread is destroyed.

In order to change the parameters for various runs which must be taken, the panel can modify the RunParameters (in the IS) and the GlobalParams.dat file.

The panel crates an IS entry called RunParams.installation_control, which is a simple string. The Commissioning controller registers a callback, for whenever this string is updated. Thus the panel can send any arbitrary command to the controller. The controller also registers a callback for the RunParams.StorageInfo.ROS-1 entry in the IS server. This allows the controller to know when a run has ended, and where to find the data file that was used to record the run.

When a run has ended, the controller calls code derived from the “EventDump” program to parse the run data and convert the information into a custom ROOT ntuple format. A script can then be called which makes plots from this ROOT ntuple.

2005-05-13T10:39:39