Difference: RichSSB2 (1 vs. 17)

Revision 172007-11-23 - StephenWotton

Line: 1 to 1
 
META TOPICPARENT name="RichOperations"

The SSB2 wiki

Line: 474 to 474
 
    1. Open your root file: root {your .root file name}

-- Main.wotton - 24 Jun 2007

Deleted:
<
<
META FILEATTACHMENT attachment="SSB2Manual_v02.pdf" attr="" comment="" date="1182682291" name="SSB2Manual_v02.pdf" path="SSB2Manual_v02.pdf" size="827831" stream="SSB2Manual_v02.pdf" user="Main.wotton" version="1"

Revision 162007-10-31 - StephenWotton

Line: 1 to 1
 
META TOPICPARENT name="RichOperations"

The SSB2 wiki

Line: 10 to 10
  2007-08-09 [SW]: L0 board 5 on the SSB2 column appears to be malfunctioning (bad data transmission from both GOLs). The board is switched off and should be left off. HPDs 660 and 661 therefore cannot be read out at present.
Added:
>
>
2007-10-31 [SW]: pcukl105 firmware and PVSS controls have been updated.
 

SSB2 infrastructure

It is mandatory to keep the He-free air flow to the SSB2 box always operational. The main valve at the bottle rack

Revision 152007-10-29 - StephenWotton

Line: 1 to 1
 
META TOPICPARENT name="RichOperations"

The SSB2 wiki

Revision 142007-09-12 - HughSkottowe

Line: 1 to 1
 
META TOPICPARENT name="RichOperations"

The SSB2 wiki

Line: 396 to 396
 
  1. ssh tfc@odinv221 pass: tfc-expert
  2. cd ODIN_v2
Changed:
<
<
  1. source setup_v2r50
>
>
  1. source .setup_v2r50
 
  1. ps -aux
  2. sudo kill {rich TFC_server}
  3. TFC_server3.0 -s tfcodin21 {dim_dns_node of pc to run odin}
Added:
>
>
sudo kill $(ps afx | grep "[T]FC_server" | gawk '{ print $1 };')

no 2nd argument necessary in line starting TFC_server3.0 ???

 dim_dns_node should be lbtbxp01
Added:
>
>
(or should dim_dns_node be lbontfc01 ?)
 

Monitoring

Online data monitoring

Revision 132007-09-10 - unknown

Line: 1 to 1
 
META TOPICPARENT name="RichOperations"

The SSB2 wiki

Line: 349 to 349
 
  1. Make sure "Exceed" is running. If it isn't, start it from the Hummingbird Connectivity folder on the Start Menu.
  2. Double click on the Putty icon on the desktop and double-click on lhcbrich@lbt9lxco01 in the list of sessions.
  3. Use the password of the lhcbrich account to log in as that user.
Changed:
<
<
  1. source /group/rich/sw/scripts/Online_v3r3_Setup.sh
>
>
  1. source /group/rich/sw/scripts/Online_v3r5_Setup.sh
 

To START:

  1. source /group/rich/scripts/hltrx.sh when you want to start a run.

Revision 122007-09-07 - StephenWotton

Line: 1 to 1
 
META TOPICPARENT name="RichOperations"

The SSB2 wiki

Line: 357 to 357
 
  1. diskwr & (Optional. Writes the MDF data to disk. If running, DiskWR should appear in the buffer manager display.)
  2. You may now start sending triggers from the ODIN (see below).
Changed:
<
<
Note: If the disk writer is running, data from the run will be stored in /scratch/RICH/mdf/rich{timestamp}.mdf.
>
>
Note: If the disk writer is running, data from the run will be stored in /data/rich/mdf/rich{timestamp}.mdf.
 
Changed:
<
<
Automatic scripts archive data from the two directories (and subdirectories):
  • /data/RICH/CASTOR/
  • /scratch/RICH/CASTOR/
>
>
Automatic scripts archive data from the directory (and its subdirectories):
  • /data/rich/CASTOR/
  The archived data are stored at /castor/cern.ch/lhcb/testbeam/lhcbrich/SSB2/.
Changed:
<
<
At present, the disk writer is configured to write data to /scratch/RICH/mdf/. So to get the data to CASTOR you should first package together all the files for a given "run" from this directory "by hand" and move the packaged file to /scratch/RICH/CASTOR/.
>
>
Data are no longer exported from /scratch/ but the directory /scratch/RICH/ may be used for storing temporary data files. Note that this area is not backed up. You must ensure that the data you want to keep are archived.

At present, the disk writer is configured to write data to /data/rich/mdf/. So to get the data to CASTOR you should first package together all the files for a given "run" from this directory "by hand" and move the packaged file to /data/rich/CASTOR/.

  Don't forget to package the files. CASTOR is much more efficient for larger files. Generally it is also helpful to compress the packaged files as the subsequent file handling is quicker. Packaging and compressing can be done in one step using tar with the z option.

Revision 112007-08-29 - unknown

Line: 1 to 1
 
META TOPICPARENT name="RichOperations"

The SSB2 wiki

Line: 44 to 44
  The outlet of this laboratory is: 0156 R-0002 (0914/01). This plug connects a fan-out. All the information are accessible on http://network.cern.ch .
Changed:
<
<
An Electronic Logbook (ELOG) has been created to upload in a live-time any important information available to anyone who is registered. Everybody can register himself on: http://lbtbxp01.cern.ch:8080 .
>
>
An Electronic Logbook (ELOG) has been created to upload in a live-time any important information available to anyone who is registered. Everybody can register himself on: http://lblogbook.cern.ch/RICH/.
 Notice that it is possible to attach any kind of files (like graphs, photos, tables, data files, etc.).

PC

Revision 102007-08-13 - StephenWotton

Line: 1 to 1
 
META TOPICPARENT name="RichOperations"

The SSB2 wiki

Line: 6 to 6
 
Added:
>
>

SSB2 news

2007-08-09 [SW]: L0 board 5 on the SSB2 column appears to be malfunctioning (bad data transmission from both GOLs). The board is switched off and should be left off. HPDs 660 and 661 therefore cannot be read out at present.

 

SSB2 infrastructure

It is mandatory to keep the He-free air flow to the SSB2 box always operational. The main valve at the bottle rack

Revision 92007-07-31 - unknown

Line: 1 to 1
 
META TOPICPARENT name="RichOperations"

The SSB2 wiki

Line: 315 to 315
 

L0

Added:
>
>
See here for operating L0 instructions
 

L1

See here for general information about operating the UKL1 boards.

Revision 82007-07-31 - StephenWotton

Line: 1 to 1
 
META TOPICPARENT name="RichOperations"

The SSB2 wiki

Line: 387 to 387
  A new ODIN firmware and PVSS version is available to run locally in SSB2 useful for calibration runs
Changed:
<
<
1. ssh tfc@odinv221 pass: tfc-expert 1. cd ODIN_v2 1. source setup_v2r50 1. ps-aux sudokill TFC_server3.0 -s tfcodin21
>
>
  1. ssh tfc@odinv221 pass: tfc-expert
  2. cd ODIN_v2
  3. source setup_v2r50
  4. ps -aux
  5. sudo kill {rich TFC_server}
  6. TFC_server3.0 -s tfcodin21 {dim_dns_node of pc to run odin}
 dim_dns_node should be lbtbxp01

Monitoring

Line: 435 to 436
 
  1. . /home/daq/cmtuser
  2. cd /home/daq/cmtuser/Rich/TestBeam/r1r1/cmt
  3. . ./setup.sh
Changed:
<
<
  1. =../slc3_ia32_gcc323/TestBeam.exe ../options/run_on_current_output_file.opts → =
>
>
  1. ../slc3_ia32_gcc323/TestBeam.exe ../options/run_on_current_output_file.opts
 
  1. produces root file: current-run.root

Another old version (from september 2006 testbeam):

Revision 72007-07-24 - unknown

Line: 1 to 1
 
META TOPICPARENT name="RichOperations"

The SSB2 wiki

Line: 383 to 383
 

To STOP run:

  1. Select END_RUN from the top-level FSM state menu.
Added:
>
>

Odin setup for calibration runs

A new ODIN firmware and PVSS version is available to run locally in SSB2 useful for calibration runs

1. ssh tfc@odinv221 pass: tfc-expert 1. cd ODIN_v2 1. source setup_v2r50 1. ps-aux sudokill TFC_server3.0 -s tfcodin21 dim_dns_node should be lbtbxp01

 

Monitoring

Online data monitoring

Revision 62007-07-19 - unknown

Line: 1 to 1
 
META TOPICPARENT name="RichOperations"

The SSB2 wiki

Line: 323 to 323
 
  • There is only one UKL1 board, pcukl105.
  • The project runs on pclbrich01 under the lhcbrich account.
  • The GUI is running on the same PC as the project.
Added:
>
>
    • The project is started by clicking start on the Windows start menu and selecting Start PVSS 3.6.
    • The project R2DAQL1 should be started.
    • The panel fwUkl1 should open and once it has configured the FSM tree, the button Open FSM can be clicked and the project is usuable as described here.
  Note that the UKL1 boards may normally be left in the RUNNING state.

Revision 52007-07-03 - StephenWotton

Line: 1 to 1
 
META TOPICPARENT name="RichOperations"

The SSB2 wiki

Line: 6 to 6
 
Changed:
<
<

General operation rules

>
>

SSB2 infrastructure

 
Added:
>
>
It is mandatory to keep the He-free air flow to the SSB2 box always operational. The main valve at the bottle rack outlet should be open and the flowmeter should indicate a minimal flow of ~10 l/h. Please have a regular look at the flowmeter to check that the flow is OK.

In case the bottle rack is empty, or in case of problems, please call Erich (16-0183) or Didier (16-3846).

Computing

  We deal with a distributed system: please avoid any system-wide change without consulting everybody. In a distributed system non local effects might happen.
Line: 18 to 25
 Be careful when forcing logoff of any other user: improperly ended PVSS sessions give troubles. Maximum number of users equal to one will be enforced on Win2003 Server machines to avoid concurrent sessions.
Deleted:
<
<

General design rules

No potentially dangerous action (like switch on) should be triggerable by one "single-click". Use standard tricks like: cascading two or more buttons.

The Experiment Control System

The RICH PVSS control processes (SSB2)

RICH2 was assigned the following PVSS project numbers: 170-179.

RICH2 DCS will have, tentatively, numbers 170-174.

RICH2 DAQ will have, tentatively, numbers 175-179.

RICH2 project names and numbers will be:

R2DCS1 LV and SiBias plus top RICH FSM 170
HPDVolt: UHV 171
R2DCS2 (monitoring) 172
R2DAQ1 (L0) 175
R2DAQ2 (UKL1) 176

Computing

 The lhcbrich generic user account exists on all the computers in the SSB2. The password is: {ask}.
Line: 89 to 71
  The DIM DNS running in pclbcecs04.cern.ch should not be manipulated.
Added:
>
>

The Experiment Control System

The RICH PVSS control processes (SSB2)

RICH2 was assigned the following PVSS project numbers: 170-179.

RICH2 DCS will have, tentatively, numbers 170-174.

RICH2 DAQ will have, tentatively, numbers 175-179.

RICH2 project names and numbers will be:

R2DCS1 LV and SiBias plus top RICH FSM 170
HPDVolt: UHV 171
R2DCS2 (monitoring) 172
R2DAQ1 (L0) 175
R2DAQ2 (UKL1) 176

General design rules

No potentially dangerous action (like switch on) should be triggerable by one "single-click". Use standard tricks like: cascading two or more buttons.

 

UHV control

The UHV control is done via CCPC.

Revision 42007-07-03 - HughSkottowe

Line: 1 to 1
 
META TOPICPARENT name="RichOperations"

The SSB2 wiki

Line: 377 to 377
 

Monitoring

Changed:
<
<

To START online monitor:

>
>

Online data monitoring

To start the online data monitoring display (testbeam version):
 
  1. Find onlineMonitoring window
  2. bash
  3. cd /home/daq/test_beam_for_dummies/
Line: 385 to 386
 
  1. keep typing fg until GaudiOnlineMonitor window will appear
  2. In the Gaudi Online Monitor window, click connect
  3. Find HPDMoni in the tree and select histograms from the list
Changed:
<
<
  1. Select cdz in H2D options
>
>
  1. Select colz in H2D options
 
  1. Select 1D in stats options
  2. Click select
  3. Click start
Line: 394 to 395
  Fig 2.
Changed:
<
<

Run "offline" analysis/monitoring:

  1. log into lbt9lxco01 as user Adinolfi
  2. bash
>
>

Offline data monitoring

For new software (ONLINE_v3r3), works with both LHCb and ALICE modes:
  1. Log into lbt9lxco01 as lhcbrich
  2. . /group/rich/sw/scripts/Online_v3r3_Setup.sh
  3. . /group/rich/sw/scripts/offline_monitoring_setup_ssb2_2.sh
  4. nice /afs/cern.ch/lhcb/software/releases/BRUNEL/BRUNEL_v31r5/Rec/Brunel/v31r5/slc3_ia32_gcc323/Brunel.exe /home/daq/Online2/ssb2_hit_ntuple.opts
(note: warnings about channels being suppressed are expected -- normally there should be 20 such messages in the first event, corresponding to (nLevel1Boards-nHPDs)=36-16)

For older software (but still post-testbeam: ONLINE_V2r2):

  1. Log into lbt9lxco01 as lhcbrich
  2. . /group/rich/sw/scripts/Online_v3r0_Setup.sh (note the "v3r0" rather than "v2r2")
  3. . /group/rich/sw/scripts/offline_monitoring_setup_ssb2.sh
  4. analysis2 (which will already have been created as an alias to nice ../slc3_ia32_gcc323/TestBeam.exe ../options/ssb2_ntuple.opts by the previous line)

Old version (from september 2006 testbeam):

  1. log into lbt9lxco01 as user adinolfi
 
  1. export CMTPATH=/home/daq/cmtuser
  2. . /home/daq/cmtuser
  3. cd /home/daq/cmtuser/Rich/TestBeam/r1r1/cmt
  4. . ./setup.sh
Changed:
<
<
  1. ../slc3_ia32_gcc323/TestBeam.exe ../options/run_on_current_output_file.opts → prod
  2. uces current-run.rout
>
>
  1. =../slc3_ia32_gcc323/TestBeam.exe ../options/run_on_current_output_file.opts → =
  2. produces root file: current-run.root
 
Changed:
<
<

Offline monitoring:

>
>
Another old version (from september 2006 testbeam):
 
  1. On current run (or the last run, if data is not currently been taken)
    1. Log into lbt9lxco01 as adinolfi
    2. bash
    3. cd /home/daq/cmtuser/Rich/TestBeam/r1r1/cmt/
    4. export CMTPATH=/home/daq/cmtuser
    5. source setup.sh
Changed:
<
<
    1. ../slc3_ai32_gcc323/TestBeam.exe ../options/run_current_output_file.opts
>
>
    1. ../slc3_ai32_gcc323/TestBeam.exe ../options/run_on_current_output_file.opts
 
    1. File current_run.root is produced
    2. View histograms with root: current_run.root
  1. On an older run
    1. Steps a to e from above (on current run)
Changed:
<
<
    1. Create a copy of /home/daq/cmtuser/Rich/TestBeam/v1v1/options/run_on_current_output
>
>
    1. Create a copy of /home/daq/cmtuser/Rich/TestBeam/v1r1/options/run_on_current_output.opts
 
    1. In your new copy, edit times containing:
      • EventSelector.input: for you to chosen input data file (e.g. mdfOut.dat using full path)
Changed:
<
<
      • HistogramPersistencySrc.OutputFile: for you to chosen output file name (eg file.root)
    1. Run ../slc3_ai32_gcc323/TestBeam.exe {path to your new options}
>
>
      • HistogramPersistencySvc.OutputFile: for you to chosen output file name (eg file.root)
    1. Run ../slc3_ia32_gcc323/TestBeam.exe {path to your new options}
 
    1. Open your root file: root {your .root file name}

-- Main.wotton - 24 Jun 2007

Revision 32007-07-03 - StephenWotton

Line: 1 to 1
 
META TOPICPARENT name="RichOperations"

The SSB2 wiki

Line: 345 to 345
  Note: If the disk writer is running, data from the run will be stored in /scratch/RICH/mdf/rich{timestamp}.mdf.
Added:
>
>
Automatic scripts archive data from the two directories (and subdirectories):
  • /data/RICH/CASTOR/
  • /scratch/RICH/CASTOR/

The archived data are stored at /castor/cern.ch/lhcb/testbeam/lhcbrich/SSB2/.

At present, the disk writer is configured to write data to /scratch/RICH/mdf/. So to get the data to CASTOR you should first package together all the files for a given "run" from this directory "by hand" and move the packaged file to /scratch/RICH/CASTOR/.

Don't forget to package the files. CASTOR is much more efficient for larger files. Generally it is also helpful to compress the packaged files as the subsequent file handling is quicker. Packaging and compressing can be done in one step using tar with the z option.

 

To STOP:

  1. First stop sending triggers from ODIN (see below).
  2. Wait a few seconds to allow buffers to empty.

Revision 22007-06-24 - StephenWotton

Line: 1 to 1
 
META TOPICPARENT name="RichOperations"

The SSB2 wiki

Line: 312 to 312
 

L1

Changed:
<
<
The L1 control interface is implemented in PVSS and is currently under development. This document will provide a summary of the currently implemented features and how to use the available tools to configure single L1 registers or to configure whole boards for running.
>
>
See here for general information about operating the UKL1 boards.
 
Changed:
<
<
The purpose of this document is to provide an outline of how to use the framework provided FSM to configure groups of L1 boards for runs or to read (write) from (to) individual L1 registers using the FSM. A description of how to start the appropriate project, open and use the appropriate panels is described.

Starting the project.

The project is located on the Windows PC pclbrich01, which can be accessed via the generic RICH account (User name: lhcbrich). Once logged in PVSS can be started by either selecting the desktop or start menu short cut for "PVSS project administration". It can also be found in Start->Programs->PVSS->PVSS project administration. Figure 1 shows the project administrator screen that should be presented. Using this the R2DAQ2 project should be started by selecting it and then clicking the green traffic light button (highlighted). Once running the project will automatically start PVSS console and log viewer and begin the start up routine for the project. The console provides control over the various PVSS managers and does not need to be used for the L1 configuration. The log viewer will show all message, both errors and status, that the PVSS project produces and it should be monitored, especially in the event of unexpected behaviour. In addition to these two managers that are started with any PVSS project the framework provided Device Editor and Navigator (DEN) is also start and it is through this that we can access that finite state machine (FSM) and access the L1 boards. It is the use of this that this document describes.

Using the FSM

Once the project has been loaded it will automatically start the Device Editor and Navigator, DEN, and the FSM can be accessed via the FSM tab. Figure 2 shows a picture of the DEN in the FSM view, highlighting the tree structure. It is useful at this point to explain this view using a combination of PVSS and FSM terminology. At the highest level of the tree the PVSS project name and number can be seen, which in this case is ukl1:1 (project name:number) as the screen shot is taken from the Cambridge development system. The CERN FSM would show R2DAQ2:176 for its system name. Below this can be seen control unit, CU, which is the level above the list of device units, DU. A device unit or DU is used by the FSM to represent a specific hardware object, in this case the DU unit represents a single physical L1 board. The control unit or CU is used to manage this collection of L1 boards. Figure 2 has a CU called UKL1, however in the CERN system it is called L1, and below this the DUs. Each DU will have a name of the form FSMCCPCUKL1/`L1 name as in DIM server'. It can be seen in Figure 2 this is pclbcc01. The following steps must be taken in order to run the state machine and utilize its functionality:
  • Select UKL1 (or other top level control unit).
  • Click the Start/Restart all or right click and select Start/Restart node.
  • Right click on UKL1 (or other top level control unit) and select view.
Once this has been done the state machine top level panel will be started, which can be seen in Figure 3. It is from here that the L1 boards can be configured on mass from predefined settings. The panel shows the CU name and its state under the System heading and the available L1 boards and their states under the Sub-system heading. Configuration of all the present L1 boards from this interface is relatively straight forward and the following steps should be followed:
  1. Take control of the system. Initially all state markers will be greyed out and the pad lock on the right of the system state will be unlocked. Click on this and then select the take option. The panel should then look as it does in Figure 3.
  2. Click on the System state (in this case it is running) and a list of possible actions will appear. In order to move the board from an unconfigured to configured state typically two actions will need to be performed, configure followed by start. This will allow the board to take data. The available actions and their consequences are listed below:
    • Reset: Does not affect any of the hardware settings at present, however it puts the state back to unconfigured. It has limited use at present, however its will eventually be linked to a reset and should be considered as such at the moment. Leaves the L1 board in an unconfigured state.
    • Configure: This is the most time consuming action. It loads all the register settings from, at present, a single configuration stored in a PVSS data point and in future releases this will interface with the configuration database. This should be used any time boards have entered an unconfigured state or they need to be reset to their defaults. It will leave the L1 board in the ready state.
    • Stop: This disables all the inputs and outputs from an L1 board, preventing any data flow through the L1 chain. Puts the board in a ready state.
    • Start: This enables all the inputs and outputs from an L1 board, allowing data to be received, processed and sent on to the next readout stage. Puts the board in a running state.
  3. The boards states will update in the sub-system section to indicate if their transitions were successful.

State transitions can be performed for the individual L1 boards by clicking on the state next to them in the sub-system section. The same method to configure the control unit is then used on a per L1 board case. Further by double clicking on an L1 board name a new panel is opened that allows control over the individual board either through an FSM style interface or by configuring the individual registers, that is described in the next section.

Individual configuration

In order to access the individual L1 configuration FSM panel it can either be accessed via the CU level panel as described in the previous section or by right clicking and selecting view on the DEN FSM tree. The former method is preferred as it allows overall system control to be maintained. When the panel shown in Figure 4 is first loaded it will update all its fields from the L1 registers, so will reflect the current values in the L1 registers. Each of two tabs FPGA and GBE are used to configure those settings that are associated with the L1 board FPGAs and giga-bit ethernet (GBE) output ports respectively. The GBE settings once configured from their defaults will almost never need to be changed, the FPGA settings on the other hand control how the events are processed by the L1 boards and on occasion will need to be changed from the defaults. The FPGA also has some settings that are for expert manipulation only and these are in the ‘Advanced’ frame and also the L0 emulation. The use of the tabs is the same for both the FPGA, GBE and also L0 emulator (which is opened from the FPGA tab) and their use will be described generically.
  • Using the Get from L1 button the settings here can be updated from the L1 board. Updates are done automatically only the first time that the panel is loaded. If configurations are done via the state machine they will not be reflected until either a manual read is performed or the panel is closed and reopened.
  • The Set to L1 button retrieves all the settings off the panel and sets them to the registers in the L1 board. It is only those settings that are visible on the tab that are set. Changes can be to any field and some field restrict the possible inputs by using drop down boxes. For the majority of none expert settings the User is restricted by drop down boxes or to entering a specific format, such as IP address, and it is only for the expert settings that a User needs some knowledge of what the register really does.

Errors

All errors that occur are sent to the PVSS log viewer and also the state machine message box. A few errors and their solutions will be outlined, any errors that are encountered should be reported to the nearest L1 expert. There are also some features of using the current versions of the software that a User need be aware as this can cause apparently mysterious behaviour, which is typically due to timing issues that are currently being overcome.

The main one is that it is possible to read from the L1 board while it is being configured, which will result in apparently inconsistent settings in the L1 registers. If this is found again a short period of time should be left (of the order of 10-20secs) before reattempting to read from the L1 registers. The channel and FPGA enable settings are always the last to be set and also got so if these can be read repeatedly with consistent and expected settings then this will likely indicate an actual problem with the other registers. As for actual errors, those that are outlined here are easy to stop and fairly obvious as to their solution. Those problems described are FSM not starting correctly, locating the DIM server, L1 boards not being found or problems retrieving the settings from the database.

The first can be caused if the state machine is started too soon during the project start up. During the start up a script runs that finds the available L1 boards and performs the relevant configuration for each. If this is not finished before the state machine started it will generate some errors from the FSM. If this is the case the state machine should be stopped and after 30secs-1min the state machine should be restarted.

If DIM server communication is the problem then this will be reflected by a large number of failures to write to data point elements often coupled with errors from the fwCcpc library. If this is the case it should be confirmed that the DIM server is indeed running and that the DIM_DNS_NODE environment variable is set to the appropriate value. To do this the RICH ECS operation manual should be consulted. A failure to communicate with the DIM server because it is not present will be reported as a PVSS error due to the perceived problem from the software’s prospective. If there is a problem with connection to the L1 registers that handled by the DIM server, this will appear as a DIM server error and indicates that the error is not with the DIM server itself but with the registration of the relevant PVSS data points on the DIM server. At present this will typically require expert intervention to solve.

A failure due to the L1 boards not being found will be reflected in a number of write errors due to the DIM server error being reported. This can be solved in a number of ways. The most simple is the L1 boards are not powered up and turning on the crate will solve this problem. It is also possible that the CCPC server may not have started, in this case the instructions for starting a CCPC server on a credit card pc must be followed.

The final error discussed here is will be apparent as either the data points containing the settings loaded by the state machine will not be found or the errors will complain about an invalid value that is being set (typically this will be zero). In the case where the data point cannot be found it likely means that the data point is not present in the project, in which case the install did not complete successfully and needs to be reinstalled. The later case of passing invalid data means the data point values have become corrupted and will need to be reconfigured. In both cases an expert should be consulted to reapply the defaults and to check that they do exist. Only three possible errors are outlined here and many more are possible (and many not yet encountered), your nearest L1/FSM/PVSS (in that order) should be consulted when any strange or unexpected behaviour is encountered.

>
>
At the SSB2 lab the PVSS control is the same as described here except that:
  • There is only one UKL1 board, pcukl105.
  • The project runs on pclbrich01 under the lhcbrich account.
  • The GUI is running on the same PC as the project.

Note that the UKL1 boards may normally be left in the RUNNING state.

In case you think you need to do a complete reinitialisation all you have to do is:

  • Select Stop from the pcukl105 top-level FSM menu.
  • Select Reload from the FSM menu.
  • Wait about 15s (the UKL1 FPGAs are being reinitialised).
  • Select Configure from the FSM menu (you are asked to select a recipe at this point).
  • Select Start from the FSM menu.
 

The Event Builder

Changed:
<
<

Procedure 1 (normal running):

>
>

Preparing the environment

 
  1. Log into the Windows PC lbtbxp01 as user lhcbrich if not logged in already.
  2. Make sure "Exceed" is running. If it isn't, start it from the Hummingbird Connectivity folder on the Start Menu.
  3. Double click on the Putty icon on the desktop and double-click on lhcbrich@lbt9lxco01 in the list of sessions.
  4. Use the password of the lhcbrich account to log in as that user.
Changed:
<
<
  1. Type start_run when you want to start a run.
  2. Wait until the Buffer Manager Monitor window appears, and until a HPDMoni item is listed in it. Wait another minute (to allow HPDMoni fully to finish loading), and then the event builder is ready for you to start sending triggers from the ODIN. (Note: data from the run will be stored in: /home/daq/data/mdfOutput{theDate}-{theTimeAtStartOfRun}.mdf)
  3. When ready to end the run, stop sending triggers from the ODIN, wait a minute, and then type end_run.

Procedure 2 (Recovery after major crash):

  1. Open LBTBXP01 user: ADINOLFI, Password: xxxxxxxxxx
  2. Click on Shortcut to startxwin.bat (ignore fatal error)
  3. In the xterm type ssh -y lbt9lxco01 same password as above:
    • xterm-name KillAll &
    • xterm-name EventBuilder &
    • xterm-name OnlineMonitoring &
    • xterm-name Offline Monitoring &
    • xterm-name CopyCastor &
  4. Follow procedure 1 above

To STOP the Event Builder:

  1. Go to xterm called KillAll
  2. do source /home/daq/cleanall.sh
>
>
  1. source /group/rich/sw/scripts/Online_v3r3_Setup.sh

To START:

  1. source /group/rich/scripts/hltrx.sh when you want to start a run.
  2. Wait until the Buffer Manager Monitor window appears, and until a HPDMoni item is listed in it. Wait another minute (to allow HPDMoni fully to finish loading), and then the event builder is ready.
  3. diskwr & (Optional. Writes the MDF data to disk. If running, DiskWR should appear in the buffer manager display.)
  4. You may now start sending triggers from the ODIN (see below).

Note: If the disk writer is running, data from the run will be stored in /scratch/RICH/mdf/rich{timestamp}.mdf.

To STOP:

  1. First stop sending triggers from ODIN (see below).
  2. Wait a few seconds to allow buffers to empty.
  3. pkill Gaudi.exe
 

ODIN run control

To START a run from ODIN:

  1. Open the window called Partition_ODIN V2_21:TFC manager
Changed:
<
<
  1. Click on the top Run_Ready (should be blue)
  2. Select START_RUN: should become green
>
>
  1. Select START_RUN from the top-level FSM state menu.
  2. Set the run number and number of triggers desired (0=free running).
 
  1. The Auxiliary Trigger box should start counting at the first spill
Changed:
<
<
  1. The green box shows RUN_RUNNING.
>
>
  1. The green box shows RUNNING.
  Fig 1

To STOP run:

Changed:
<
<
  1. Select RUN_RUNNING and click
  2. Click on end_run
>
>
  1. Select END_RUN from the top-level FSM state menu.
 

Monitoring

Revision 12007-06-24 - StephenWotton

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="RichOperations"

The SSB2 wiki

The contents of these Wiki pages are based on the SSB2 lab manual version 0.2 that is attached to the bottom of this page. The figures have not yet been imported.

General operation rules

We deal with a distributed system: please avoid any system-wide change without consulting everybody. In a distributed system non local effects might happen.

In order to avoid clashes/confusion the lhcbrich account should not be used for remote desktop, especially on machines running Win2003 Server (not "to steal" the local session).

Use your personal account for remote desktop.

Be careful when forcing logoff of any other user: improperly ended PVSS sessions give troubles. Maximum number of users equal to one will be enforced on Win2003 Server machines to avoid concurrent sessions.

General design rules

No potentially dangerous action (like switch on) should be triggerable by one "single-click". Use standard tricks like: cascading two or more buttons.

The Experiment Control System

The RICH PVSS control processes (SSB2)

RICH2 was assigned the following PVSS project numbers: 170-179.

RICH2 DCS will have, tentatively, numbers 170-174.

RICH2 DAQ will have, tentatively, numbers 175-179.

RICH2 project names and numbers will be:

R2DCS1 LV and SiBias plus top RICH FSM 170
HPDVolt: UHV 171
R2DCS2 (monitoring) 172
R2DAQ1 (L0) 175
R2DAQ2 (UKL1) 176

Computing

The lhcbrich generic user account exists on all the computers in the SSB2. The password is: {ask}.

Be careful that this account has, so far, administrative privileges on all the machines. As soon as the situation is more stable its privileges will be downgraded to the minimum required to just RUN the projects.

Each subsystem developer/responsible will have administrative privileges on its machines. The desktop redirection for the lhcbrich account is disabled, so that each PC desktop layout will be local only.

Do not change the lhcbrich account settings on NICE.

In addition to the desktop, that is now not redirected anymore, it is essential that the roaming profile stay disabled.

The outlet of this laboratory is: 0156 R-0002 (0914/01). This plug connects a fan-out. All the information are accessible on http://network.cern.ch .

An Electronic Logbook (ELOG) has been created to upload in a live-time any important information available to anyone who is registered. Everybody can register himself on: http://lbtbxp01.cern.ch:8080 . Notice that it is possible to attach any kind of files (like graphs, photos, tables, data files, etc.).

PC

The following machines are strictly reserved for development/running of the different sub-systems:

pclbcecs04 DCS / monitoring Antonis / Ulrich Win XP
lbh6lx01 ELMBs Antonis Win XP
pcphdt2006 ECS / DCS / UHV Flavio / Alessandro Win XP
lbriwico01 DAQ / L0 / Specs Stig / Sean Win 2003
pclbrich01 DAQ / L1 Steve / Hugh / Gareth Win XP
lbt9lxco01 DAQ / event builder Steve / Niko / Marco SLC4
lbtbxp01 DAQ / ODIN Steve / Marco Win XP
pclhcb84 Beamer / Mag Distortion Aleixandre / Barbara Win XP
Pc161331 General use All Win XP

All of these machines should be left typically free for their own use and that a lot of development work (as long as it does not involve any interaction with the hardware) can be done by the responsible remotely.

One PC is available in the SSB2 lab for personal use.

DIM Name Server

The "DIM Nameserver" (DIM DNS) is a system service in pclbcecs04.cern.ch. As long as this PC is up and running the server should be available, regardless of who is logged on, if any.

In a distributed PVSS system there must be a unique DIM DNS process (dns) addressed by all the components which need to communicate among each other.

Therefore the dns process must be running at all the times on a fixed machine, for the distributed system to run. It has therefore to be installed as a system service.

The DIM DNS running in pclbcecs04.cern.ch should not be manipulated.

UHV control

The UHV control is done via CCPC.

The interaction vi the CCPC is via a PVSS interface project.

Please keep in mind that all the monitoring, control and configuration are done by a C program running on the CCPC; the PVSS interface is only an interface to that program.

CCPC

The cold startup should proceed as follows:

The CCPC boots from the network It then shows the following prompt for login:

pclbcc30 login:

Login name: rhv
Password: xxxxxxxx
The following prompt appears:
[pclbcc30] /home/rhv >

At the prompt:

  • tcsh
  • Make sure the dns runs somewhere if PVSS is needed.
  • Make sure the environment variable DIM_DNS_NODE is defined accordingly (only if PVSS is needed) setenv DIM_DNS_NODE pclbcecs04.cern.ch
  • Change to the following directory: cd vhv
  • Execute the following program: ./hvcont  --dns  -u (Which will point to the most recent executable, currently hvcont7 in folder ./hvcont7)

Command line options

  • You can not anymore run 2 instances of the program, a lock mechanism avoids that, in case of a wrong lock (perhaps due to a previous crash) you may force
the running with the command line option -u (for unlock)
  • Data is recorded on file only if you ask so, the default is not to do any logging, to log data please use the --log option (beware it is a double dash: --log)
  • To connect to PVSS you have to start the DIM server: --dns (with double dash again)

Note: when in the program, the backspace key is not properly emulated. It is replaced by Ctrl-h.

The screen that shows up is self-explanatory and it is updated every 3 s.

Commands are listed on the bottom line and are reproduced in the table attached.

The normal HV ramp-up procedure should be as follows:

  • Set the maximum current limit by typing “i”, then choose the channel and enter the value 280.0 [A].
NOTE: there is no default channel anymore, existing channels are 0, 1 and 2 but only channel 0 is connected to ISEG for the time being.

  • Set the desired voltage by typing “v”, then the channel and the desired value, eg 5000 [V]. The ramp up starts automatically. The execution can be paused only entering the actual voltage.

If the terminal displays gets error messages it might show wrong things: in this case, or if you suspect your are reading wrong values, just quit and restart it

List of available commands

Command name Key Default value (where applicable) Unit (where applicable)
Set V V (or v) V
Set I Max I (or i) 350.0 A
Set Ramp Up U (or u) 50.0 V/s
Set Ramp Down D (or d) 500.0 V/s
Kill one channel K (or k)    
Trip time T (or t) 20.0 s
Refresh screen R (or r)    
Help H (or h)    
Quit Q (or q)    

PVSS interface

Make sure that he process on the CCPC, hvcontx, is running before using the PVSS interface.

The PVSS project is a project called RICH_HPDVolt-x.y. It normally runs on pcphdt2006.cern.ch. The project with the higher version number (x.y) should be always started, unless explicitly required otherwise.

Setup after booting: none required.

The PVSS project is started via the PVSS project and administration icon: start PVSS by clicking on the desktop shortcut "PVSS Project Administration", select the line corresponding to RICH_HPDVolt-x.y and then click on the green traffic-light.

Fig 1.

Give some time to PVSS to start all its processes (about one minute).

After the PVSS project is started, it should normally do itself all the required startup steps.

All the monitoring and control, for a 3 column SSB2 system, happen via the main panel which pops up at startup (see the figure 2).

There are only two mandatory operations to do before starting to work.

  • To click on the padlock near the UHV icon on the top-left of the panel and issue the Take command to take full control of the UHV tree; as a consequence of this operation all the State icons should move from a grey color to color depending on the current state. This operation cannot (and must not) be made automatic. In fact, taking the full control of the FSM tree implies that one can send commands to the system. For this same reason, it is a good practice, for security reasons, to click on the padlock and release the tree after finished working, even if a single click is not enough to issue a command. This ensures, among other things, that one cannot mistakenly issue commands.

  • To click on the UHV State button and issue either the command LOAD or CONFIGURE (they do the same, for the time being) in order to load the recipes from the database.

Fig 2.

A crucial issue is the connection to the CCPC. If the connection to the CCPC is not working, for any reason, the monitoring and control from PVSS have no meaning. For the time being the safest procedure to check that the connection is active is to watch the vMon icon in the control panel and check that the number is updated about every three seconds.

Common symptoms of lack of connections are:

  • the icon connection to the CCPC red;
  • the colunn icon displays a number like -9000, -9001, -9002;

General issues

For the time being, tentatively, the following voltage settings were introduced:

  • vSet = 0 Volt (OFF)
  • vSet = 200 Volt (STANDBY1)
  • vSet = 2000 Volt (STANDBY2)
  • vSet = 20000 Volt (READY)

Control of all the channels via the FSM

When clicking on the UHV button a menu shows all the available commands in that state.

Single channel detailed control

The two ovals at the top of each column indicate:

  • whether the column is in an emergency state (red) or not (green);
  • whether there is a link to the CCPC or not.

For each column the main panel shows the monitored data (updated from the CCPC every 3 seconds).

For each column you can set the voltage (vSet); after setting vSet you must click on switchOn to start ramping towards vSet.

The switchOff button sets the voltage to zero and starts ramping down at the rampDown speed.

The kill button sets the voltage to zero and start ramping down at the rampDown speed of 2000000 (i.e. it ramps down to zero in the shortest time allowed by software/hardware).

Expert configuration opens a small panel with some more configuration values (some defaults are present); to actually send them to the HW click on the configure button.

Plots shows a plot of vMon, iMon and a numerical code for the status flag; until the plot is kept open the data are kept in memory.

The Low Voltages and Silicon Bias control

LV hardware:

Cooling System MARATON:

  1. check the level of the water
  2. press the "switch on button" on the front
  3. In the Compatible Control CC1 to start the control system turn the knob (it is like a black button but you can also turn it) to select "ON" on the screen and then press it to confirm the action. You must see: the green light LED of pump ON, the blue LED of cooling flashing
  4. You can set the working temperature by pressing the “set button” and then turning the knob. To confirm the temperature press the knob.

When the temperature is near the working-point (to select it see 1.d), switch on the Primary Rectifier.

Switch on the MARATON.

The Remote Control Wiener:

  1. Switch on the power of the crate
  2. Check that in the screen there are setting: +5V and 3A

NOTE: - On the front panel of the Wiener RCM the on/off state of each channel is indicated by a LED.

Si Bias hardware:

  1. Check that the supply button at the back of the CAEN is ON. You must see that the "main LED" is ON (red light)
  2. Turn the key on the “local position”
  3. Switch on the screen. You must see that the operating system is starting
  4. Press "enter". A login screen must appear.
  5. Login with: username: admin, password: admin
  6. Access to the “main menu” and select “channels” from the list You must see all the channel status
  7. To change a value you can insert it in its field and then press the spacebar to confirm the action

NOTE:

  • if the status column is Ext-Dis it means that this channel is disable by the patch-panel. You can change the position of the channel lever on the patch panel to change the channel status.
  • to switch on/off each channel you have to access to the field and then press the spacebar to confirm the action

Location of the hardware in the racks:

Detector Control System:

PVSS ELMBs:

1. Run the PVSS II Project Administrator (fig 1). It normally runs on lbh6lx01.cern.ch.

Fig 1.

2. Select R2DCS2 and then push the start project button.

Fig 2.

PVSS DCS:

1. Run the PVSS II Project Administrator (fig 1). It normally runs on pclbcecs04.cern.ch.

Fig 1

2. Select the R2DCS1 and then push the start project button. Some new windows will appear: the console (fig 2), the Log Viewer, Graphical Editor (fig 3) and the "RICH2 Columns Overview Window" (fig 4):

Fig 2

Fig 3

3. Select the column to see information about the selected column: (In the SSB2 lab the column is R2 Column 1)

Fig 4

4. Run the Window User Interface related to the Device Editor Navigator from the console. The Device Editor & Navigator window will appear

5. Select the FSM tab and press Start/Restart All button

6. Double click on RICH2 and double click on RICH2_DCS

7. Right click to the R2A_DCSCOL1 and select View. A R2A_DCSCOL1: R2DCS1:Manager2 window will appear.

8. Click on the padlock and then click the take button: the state field will become yellow like the channel001 (channel referred to the Si Bias) field with the written NOT_READY. The Channel2, channel3 and HPDCOL_TEMP1 will become blue with the written OFF (fig 4).

Fig 4

9. In this step you have two options to start the system:

  1. Click on the state button and select Switch on
  2. Click on the state button of each sub-system

NOTE: if you want to access to one sub-system manager you have to double click on the sub-system name.

L0

L1

The L1 control interface is implemented in PVSS and is currently under development. This document will provide a summary of the currently implemented features and how to use the available tools to configure single L1 registers or to configure whole boards for running.

The purpose of this document is to provide an outline of how to use the framework provided FSM to configure groups of L1 boards for runs or to read (write) from (to) individual L1 registers using the FSM. A description of how to start the appropriate project, open and use the appropriate panels is described.

Starting the project.

The project is located on the Windows PC pclbrich01, which can be accessed via the generic RICH account (User name: lhcbrich). Once logged in PVSS can be started by either selecting the desktop or start menu short cut for "PVSS project administration". It can also be found in Start->Programs->PVSS->PVSS project administration. Figure 1 shows the project administrator screen that should be presented. Using this the R2DAQ2 project should be started by selecting it and then clicking the green traffic light button (highlighted). Once running the project will automatically start PVSS console and log viewer and begin the start up routine for the project. The console provides control over the various PVSS managers and does not need to be used for the L1 configuration. The log viewer will show all message, both errors and status, that the PVSS project produces and it should be monitored, especially in the event of unexpected behaviour. In addition to these two managers that are started with any PVSS project the framework provided Device Editor and Navigator (DEN) is also start and it is through this that we can access that finite state machine (FSM) and access the L1 boards. It is the use of this that this document describes.

Using the FSM

Once the project has been loaded it will automatically start the Device Editor and Navigator, DEN, and the FSM can be accessed via the FSM tab. Figure 2 shows a picture of the DEN in the FSM view, highlighting the tree structure. It is useful at this point to explain this view using a combination of PVSS and FSM terminology. At the highest level of the tree the PVSS project name and number can be seen, which in this case is ukl1:1 (project name:number) as the screen shot is taken from the Cambridge development system. The CERN FSM would show R2DAQ2:176 for its system name. Below this can be seen control unit, CU, which is the level above the list of device units, DU. A device unit or DU is used by the FSM to represent a specific hardware object, in this case the DU unit represents a single physical L1 board. The control unit or CU is used to manage this collection of L1 boards. Figure 2 has a CU called UKL1, however in the CERN system it is called L1, and below this the DUs. Each DU will have a name of the form FSMCCPCUKL1/`L1 name as in DIM server'. It can be seen in Figure 2 this is pclbcc01. The following steps must be taken in order to run the state machine and utilize its functionality:
  • Select UKL1 (or other top level control unit).
  • Click the Start/Restart all or right click and select Start/Restart node.
  • Right click on UKL1 (or other top level control unit) and select view.
Once this has been done the state machine top level panel will be started, which can be seen in Figure 3. It is from here that the L1 boards can be configured on mass from predefined settings. The panel shows the CU name and its state under the System heading and the available L1 boards and their states under the Sub-system heading. Configuration of all the present L1 boards from this interface is relatively straight forward and the following steps should be followed:
  1. Take control of the system. Initially all state markers will be greyed out and the pad lock on the right of the system state will be unlocked. Click on this and then select the take option. The panel should then look as it does in Figure 3.
  2. Click on the System state (in this case it is running) and a list of possible actions will appear. In order to move the board from an unconfigured to configured state typically two actions will need to be performed, configure followed by start. This will allow the board to take data. The available actions and their consequences are listed below:
    • Reset: Does not affect any of the hardware settings at present, however it puts the state back to unconfigured. It has limited use at present, however its will eventually be linked to a reset and should be considered as such at the moment. Leaves the L1 board in an unconfigured state.
    • Configure: This is the most time consuming action. It loads all the register settings from, at present, a single configuration stored in a PVSS data point and in future releases this will interface with the configuration database. This should be used any time boards have entered an unconfigured state or they need to be reset to their defaults. It will leave the L1 board in the ready state.
    • Stop: This disables all the inputs and outputs from an L1 board, preventing any data flow through the L1 chain. Puts the board in a ready state.
    • Start: This enables all the inputs and outputs from an L1 board, allowing data to be received, processed and sent on to the next readout stage. Puts the board in a running state.
  3. The boards states will update in the sub-system section to indicate if their transitions were successful.

State transitions can be performed for the individual L1 boards by clicking on the state next to them in the sub-system section. The same method to configure the control unit is then used on a per L1 board case. Further by double clicking on an L1 board name a new panel is opened that allows control over the individual board either through an FSM style interface or by configuring the individual registers, that is described in the next section.

Individual configuration

In order to access the individual L1 configuration FSM panel it can either be accessed via the CU level panel as described in the previous section or by right clicking and selecting view on the DEN FSM tree. The former method is preferred as it allows overall system control to be maintained. When the panel shown in Figure 4 is first loaded it will update all its fields from the L1 registers, so will reflect the current values in the L1 registers. Each of two tabs FPGA and GBE are used to configure those settings that are associated with the L1 board FPGAs and giga-bit ethernet (GBE) output ports respectively. The GBE settings once configured from their defaults will almost never need to be changed, the FPGA settings on the other hand control how the events are processed by the L1 boards and on occasion will need to be changed from the defaults. The FPGA also has some settings that are for expert manipulation only and these are in the ‘Advanced’ frame and also the L0 emulation. The use of the tabs is the same for both the FPGA, GBE and also L0 emulator (which is opened from the FPGA tab) and their use will be described generically.
  • Using the Get from L1 button the settings here can be updated from the L1 board. Updates are done automatically only the first time that the panel is loaded. If configurations are done via the state machine they will not be reflected until either a manual read is performed or the panel is closed and reopened.
  • The Set to L1 button retrieves all the settings off the panel and sets them to the registers in the L1 board. It is only those settings that are visible on the tab that are set. Changes can be to any field and some field restrict the possible inputs by using drop down boxes. For the majority of none expert settings the User is restricted by drop down boxes or to entering a specific format, such as IP address, and it is only for the expert settings that a User needs some knowledge of what the register really does.

Errors

All errors that occur are sent to the PVSS log viewer and also the state machine message box. A few errors and their solutions will be outlined, any errors that are encountered should be reported to the nearest L1 expert. There are also some features of using the current versions of the software that a User need be aware as this can cause apparently mysterious behaviour, which is typically due to timing issues that are currently being overcome.

The main one is that it is possible to read from the L1 board while it is being configured, which will result in apparently inconsistent settings in the L1 registers. If this is found again a short period of time should be left (of the order of 10-20secs) before reattempting to read from the L1 registers. The channel and FPGA enable settings are always the last to be set and also got so if these can be read repeatedly with consistent and expected settings then this will likely indicate an actual problem with the other registers. As for actual errors, those that are outlined here are easy to stop and fairly obvious as to their solution. Those problems described are FSM not starting correctly, locating the DIM server, L1 boards not being found or problems retrieving the settings from the database.

The first can be caused if the state machine is started too soon during the project start up. During the start up a script runs that finds the available L1 boards and performs the relevant configuration for each. If this is not finished before the state machine started it will generate some errors from the FSM. If this is the case the state machine should be stopped and after 30secs-1min the state machine should be restarted.

If DIM server communication is the problem then this will be reflected by a large number of failures to write to data point elements often coupled with errors from the fwCcpc library. If this is the case it should be confirmed that the DIM server is indeed running and that the DIM_DNS_NODE environment variable is set to the appropriate value. To do this the RICH ECS operation manual should be consulted. A failure to communicate with the DIM server because it is not present will be reported as a PVSS error due to the perceived problem from the software’s prospective. If there is a problem with connection to the L1 registers that handled by the DIM server, this will appear as a DIM server error and indicates that the error is not with the DIM server itself but with the registration of the relevant PVSS data points on the DIM server. At present this will typically require expert intervention to solve.

A failure due to the L1 boards not being found will be reflected in a number of write errors due to the DIM server error being reported. This can be solved in a number of ways. The most simple is the L1 boards are not powered up and turning on the crate will solve this problem. It is also possible that the CCPC server may not have started, in this case the instructions for starting a CCPC server on a credit card pc must be followed.

The final error discussed here is will be apparent as either the data points containing the settings loaded by the state machine will not be found or the errors will complain about an invalid value that is being set (typically this will be zero). In the case where the data point cannot be found it likely means that the data point is not present in the project, in which case the install did not complete successfully and needs to be reinstalled. The later case of passing invalid data means the data point values have become corrupted and will need to be reconfigured. In both cases an expert should be consulted to reapply the defaults and to check that they do exist. Only three possible errors are outlined here and many more are possible (and many not yet encountered), your nearest L1/FSM/PVSS (in that order) should be consulted when any strange or unexpected behaviour is encountered.

The Event Builder

Procedure 1 (normal running):

  1. Log into the Windows PC lbtbxp01 as user lhcbrich if not logged in already.
  2. Make sure "Exceed" is running. If it isn't, start it from the Hummingbird Connectivity folder on the Start Menu.
  3. Double click on the Putty icon on the desktop and double-click on lhcbrich@lbt9lxco01 in the list of sessions.
  4. Use the password of the lhcbrich account to log in as that user.
  5. Type start_run when you want to start a run.
  6. Wait until the Buffer Manager Monitor window appears, and until a HPDMoni item is listed in it. Wait another minute (to allow HPDMoni fully to finish loading), and then the event builder is ready for you to start sending triggers from the ODIN. (Note: data from the run will be stored in: /home/daq/data/mdfOutput{theDate}-{theTimeAtStartOfRun}.mdf)
  7. When ready to end the run, stop sending triggers from the ODIN, wait a minute, and then type end_run.

Procedure 2 (Recovery after major crash):

  1. Open LBTBXP01 user: ADINOLFI, Password: xxxxxxxxxx
  2. Click on Shortcut to startxwin.bat (ignore fatal error)
  3. In the xterm type ssh -y lbt9lxco01 same password as above:
    • xterm-name KillAll &
    • xterm-name EventBuilder &
    • xterm-name OnlineMonitoring &
    • xterm-name Offline Monitoring &
    • xterm-name CopyCastor &
  4. Follow procedure 1 above

To STOP the Event Builder:

  1. Go to xterm called KillAll
  2. do source /home/daq/cleanall.sh

ODIN run control

To START a run from ODIN:

  1. Open the window called Partition_ODIN V2_21:TFC manager
  2. Click on the top Run_Ready (should be blue)
  3. Select START_RUN: should become green
  4. The Auxiliary Trigger box should start counting at the first spill
  5. The green box shows RUN_RUNNING.

Fig 1

To STOP run:

  1. Select RUN_RUNNING and click
  2. Click on end_run

Monitoring

To START online monitor:

  1. Find onlineMonitoring window
  2. bash
  3. cd /home/daq/test_beam_for_dummies/
  4. source start_hpd_viewer_on_lxplus.sh
  5. keep typing fg until GaudiOnlineMonitor window will appear
  6. In the Gaudi Online Monitor window, click connect
  7. Find HPDMoni in the tree and select histograms from the list
  8. Select cdz in H2D options
  9. Select 1D in stats options
  10. Click select
  11. Click start
NOTE: may need to redo Select and Start whenever options are changed.

Fig 2.

Run "offline" analysis/monitoring:

  1. log into lbt9lxco01 as user Adinolfi
  2. bash
  3. export CMTPATH=/home/daq/cmtuser
  4. . /home/daq/cmtuser
  5. cd /home/daq/cmtuser/Rich/TestBeam/r1r1/cmt
  6. . ./setup.sh
  7. ../slc3_ia32_gcc323/TestBeam.exe ../options/run_on_current_output_file.opts → prod
  8. uces current-run.rout

Offline monitoring:

  1. On current run (or the last run, if data is not currently been taken)
    1. Log into lbt9lxco01 as adinolfi
    2. bash
    3. cd /home/daq/cmtuser/Rich/TestBeam/r1r1/cmt/
    4. export CMTPATH=/home/daq/cmtuser
    5. source setup.sh
    6. ../slc3_ai32_gcc323/TestBeam.exe ../options/run_current_output_file.opts
    7. File current_run.root is produced
    8. View histograms with root: current_run.root
  2. On an older run
    1. Steps a to e from above (on current run)
    2. Create a copy of /home/daq/cmtuser/Rich/TestBeam/v1v1/options/run_on_current_output
    3. In your new copy, edit times containing:
      • EventSelector.input: for you to chosen input data file (e.g. mdfOut.dat using full path)
      • HistogramPersistencySrc.OutputFile: for you to chosen output file name (eg file.root)
    4. Run ../slc3_ai32_gcc323/TestBeam.exe {path to your new options}
    5. Open your root file: root {your .root file name}

-- Main.wotton - 24 Jun 2007

META FILEATTACHMENT attachment="SSB2Manual_v02.pdf" attr="" comment="" date="1182682291" name="SSB2Manual_v02.pdf" path="SSB2Manual_v02.pdf" size="827831" stream="SSB2Manual_v02.pdf" user="Main.wotton" version="1"
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback