L1Calo Analogue Cable Testing

Introduction

This page contains some instructions for running the procedures to test the analogue cables from the calorimeters (so far only TileCal) via VME readout from the PPMs.

Hardware setup

The L1Calo infrastructure consists of two Preprocessor crates, one for the C side (-z) and one for the A side (+z). Each crate contains one PPM, one TCM (or at least the ALC part) and is controlled by a VP315 CPU. In the database, the C side crate is l1calo-pp0 with CPU sbc-l1calo-rcc-03 and the A side crate is l1calo-pp0 with CPU sbc-l1calo-rcc-04

The TTC signals come from an optical fanout whose input can be either a fibre from TileCal, or one from LAr (which need to be rereouted) or else one from our local TTC crate (l1calo-ttc with CPU sbc-l1calo-tcc-01) for testing.

The four analogue cable inputs to the PPM may come directly from the TCPP outputs (typically just one via a special "flying lead") or more normally via four temporary cables from a single receiver on each side (C,A) which is in turn fed by four temporary cables from the TCPPs.

The software expects these sets of four temporary cables on each side to be connected to a sequential block of four TileCal modules (or 4 LAr phi bins). This is one LAr sector or half a Tile sector. LAr sectors are numbered from 1 to 16. Tile sectors are twice as big and use only the odd numbers in the same scheme.

Accounts at point 1

To run the software, you first need to login to the pc-l1calo-pm-01 machine on the ATLAS control network. If you are starting from the main CERN network, you first need to connect via the ATLAS gateway, atlasgw.cern.ch.

The production software is installed and run from our common project account. Please ask for the username and password.

Software updates

From time to time we update the production version of the software used for the tests. This is typically done by a software expert. If you just want to run it, skip to the next section.

It is not possible to build new versions of the software on machines on the ATLAS control network. The recommended way is to build releases on lxplus and then transfer them and install them on the ATLAS control network. This is the procedure we follow.

So first, login to our common project account. To build a new release use the p1build.pl script. Note that this builds a new version only using tagged versions of all our packages. After that script has finished (one or two hours!), use the p1copy.pl script to transfer a tgz file of the release binaries, database and scripts to the ATLAS control network. You will need to supply a password.

Finally, login to pc-l1calo-pm-01 via the ATLAS gateway and run the p1install.pl script. This will unpack the new release and allow you to make it the default one.

Points to note:

  • although the binaries are not rebuilt at point 1, it is possible to edit both database XML files and scripts by hand. Such local changes may not always be propogated back to the CVS archive. So you may want to check that there are no local changes which need to be carried over to the new release which has its own separate database area and scripts directory.

Running it all

The cable test procedure uses the standard TDAQ system and multistep runs to read events from the PPM via VME (until we have real RODs). This is all driven by a complex shell script called auto_tile_run.sh.

The script requires that the TDAQ already be running and that all run controllers have been booted.

So you need to type:

  • runme&
  • (when the IGUI appears, click Boot and wait until the Initial state)
  • auto_tile_run.sh

The auto_tile_run.sh script will ask you a number of questions.

  • Use the last hardware configuration? At the moment, the hardware configuration is just stored as a test file. If you answer no here, you will be asked to edit a new file. This will also trigger an automatic DAC scan in case a change in hardware configuration (eg swapping PPMs, exchanging MCMs etc) affects the DAC values recorded by the last DAC scan. Change of which Tile/LAr cables are being used is dealt with in the next question.
  • Enter cabling setup. The script can only handle a limited set of cabling configurations. It expects that four cables from consecutive Tile modules (or LAr equivalents) are connected to consecutive receiver inputs. In LAr terminology there are 16 sectors in phi (numbered 1-16), each with four cables coming to the trigger. Although the Tile terminology combines pairs of such sectors into eight Tile sectors each with eight cables, the script uses LAr numbering even for Tile cables. If you have just four cables from sector 12 in the C side, enter 12C. Or 12A for the same just on the A side, or just 12 if there are four cables connected on both side (to the same sector).
  • Enter test number. The script can perform three basic procedures:
    • DAC scan (test 0): finds the DAC values required to see a pedestal of (typically) 40 counts in each channel
    • FIFO run (test 1): really just accumulate statistics with chosen DAC values
    • PHOS4 scans (tests 2-N): run through all PHOS4 delays (with pos-edge and neg-edge clocking) to examine the shape of the pulse. The different test numbers all do exactly the same thing in the L1Calo system, but assume that different configurations of signals are being sent by the calorimeter. This requires coordination with eg TileCal experts - see below.

Interaction with TileCal

Our test procedures mostly assume that the TileCal is sending us some signals and a trigger (at a fairly low rate, eg a few Hz). They developed some simple programs to configure the charge injection calibration system of all TileCal modules (or a subset) to provide pulses in a few configurations that we requested. These setups correspond to the possible test numbers accepted by our script. You will need to coordinate (preferably some time in advance) with TileCal experts to have them run these programs for us.

Checking the results

The script and the programs it runs produce a large number of files. These are stored in a directory structure under ~/inst. The various levels in the directory tree are as follows.

  • tileNNN
    A new tileNNN directory is created for each new hardware configuration (for TileCal tests) and should include a file tileNNN.txt with the text description of the configuration and any changes since the previous one.
  • dacscan
    For a given hardware configuration, all DAC and FIFO scans are stored in this directory tree, irrespective of the cabling configuration.
  • cablingNNX
    There is a separate directory tree for all the tests performed with a given cabling setup.
  • testNN
    Within the cablingNNX directory, there is a directory tree for each of the numbered tests the script knows about. Note one small confusion: the DAC and FIFO scans are also referred to as tests 0 and 1 and the script creates such directories for them (test00 and test01) but these remain empty as the results are in the dacscan directory tree.
  • runNNN
    Every time you run a particular test the script creates a new runNNN directory. This applies both to the cablingNNX and dacscan directory trees. This directory contains a logfile, the event data files, saved and new database XML files, a ROOT file with processed data and a postscript file containing all the overview histograms.
  • postcal
    Within each runNNN directory will be a postcal directory with the results of the post calibration analysis - assuming that the run completed successfully.

Possible problems

Many things can go wrong:

  • TDAQ fails to start: maybe one of the crates is off? Unless the database is edited to disable the corresponding TDAQ Segment, both PPM crates and the TTC crates must be on even if not being used for a particular test.
  • No triggers: during the multistep run the monitoring program which collects events prints out the size of each event. Sizes less than 100 indicate that there are no triggers.
  • Pedestal problems: the analysis program checks that the pedestals seen in every channel are close to the expected 40. If this is not so, the script is aborted. Odd pedestals after a DAC scan have in the past been fixed by swapping MCMs.


Major updates:
-- MurroughLandon - 30 Mar 2006

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r2 - 2006-03-30 - MurroughLandon
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Sandbox All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback