SLAC PEP-II
BABAR
SLAC<->RAL
Babar logo
HEPIC E,S & H Databases PDG HEP preprints
Organization Detector Computing Physics Documentation
Personnel Glossary Sitemap Search Hypernews
Unwrap page!
Det. Search
Who's who?
Meetings
FAQ
Images
Archive
Systems
Performance
Intern. region
Vertex Tracker
Drift chamber
DIRC
Calorimeter
IFR
LST
Magnet
Electronics
Trigger
Operations
Run Coordination
Contact Experts
Shift Takers Info
Operations Manual
Electronic Logbook
Ops Hypernews
Shift Signup
Check this page for HTML 4.01 Transitional compliance with the
W3C Validator
(More checks...)

The wonderful online world of the Level 1 Calorimeter Trigger

General information about the EMT and EMT online software
Setting up (environment variables etc)
The EMT packages, what they contain, and the dependency rules
Building the EMT online code
Libraries, scripts and links
Setting the links to use libraries from an online release
What machine should you use for what?
Platform number and crate mask
TPB front panel LEDs
A glossary of all the configurable parameters of the EMT
EMT document repository

Keeping the EMT running smoothly in IR2
Instructions for changing the EMT prescale
The EMT on-call shift rota (The old rota can be found here)
What to do about a hot tower
Recent trigger monitoring histograms
Checking the alias tree
Fast monitoring code
Spare boards
The TRB
Cable swaps status and history (and OLD Times )

How the EMT configuration system works
The configuration database
CalCycleTC files: how to make and use them
How to interpret the flat files used to make our configuration objects (.ax, .fx, .fcx)
How to change the input tower mask
How to change the thresholds and/or jitter windows
How to change the data volume we read out
The new EMT configuration system
How to create an EMT run type alias

The Spy
Overview
Configuring the behaviour of the spy fifos on the TBP
How to run the spy
How to interpret the output

How to take test runs
How to select the run type
Current list of top keys
Cable Error (frameclash) run
An important subtlety in choosing the frame offset
Serial number run
How to make a file of playback data and take a playback run
How to take a special EMC test run where the EMC writes out the UPC trigger tower data
How to log data onto disk (into an xtc file)

The teststand
Using the teststand
Running the EMC and EMT teststands together
How to update the version of dataflow running on the teststand

Looking at data offline
How to run over an xtc file
How to stage real data xtc files from tape
How to stage calibration run xtc files from tape
Programs in L1EmtOep to look at EMT data.
How to interpret the bitmap DAQ data

Some other handy bits and pieces
EMC<->EMT map
Decoding the ODF time
Talking to a rom using the Xyplex connection
Setting the platform/crate/detector number using the dip switches on the FCDM
How to ask a UPC its serial number (without pulling it out!)
How to find out what trigger configuration was used for a particular run
How to run the level 3 event display on trickle stream data
Some useful scripts
Level 3 monitoring histograms
EMC electronics status
Known faulty EMC channels
Commiting code changes, making tags etc, in CVS


General Information about the EMT and EMT online software


Setting up

  • It is a good idea to have a dedicated area in your afs space for trigger related work.
    To get such an area fill out this web-form requesting a new sub-volume called, say, trigger, of about 250MB.

  • There is also a dedicated area in nfs space for building EMT code for common use:

    /nfs/bbr-nfs03/detector/trg/emt_builds/

    Use of this area is documented in the various HOW-TO files in the above directory.

  • Add the following lines to your .cshrc file

    source /nfs/bbr-nfs03/detector/trg/emt_builds/emtSetup.csh

    This will set up a load of environment variables you need and also some useful aliases.


The EMT packages and what they contain

The following online or dual-use packages have libraries which are used on the ROM:

L1EmtOnline           - Objects used to ship data round the online system and to the TPBs,
                                   eg tagged containers (TCs), and raw data objects interpreted by the TPBs
                                   such as L1EmtAxRawData
L1EmtCalOnline      - Objects to readout data from calibration (test) runs
L1EmtOdf                - Classes used by the ROM in talking to the TPBs, eg low-level 'commands'
                                   such as read CSER, write AX constants etc.
L1EmtCalOdf           - The 'actions' executed on transtions during data-taking and tests,
                                   eg  configure, begin run, etc
L1EmtSpy                 - The online error-checking (the spy)
L1EmtDiagnostics   - Contains low-level TPB test code for running in a xyplex window

L1EmtTeststand also exists (in the /afs/rl.ac.uk/bfactory/repouk CVS repository at RAL) but is not an official SLAC package and is being phased out. The useful code in this package should be migrated into L1EmtDiagnostics.

We also have the following offline packages. Note that of course the dual-use packages above also appear in the offline.

L1EmtData                - The transient data objects (the digis) read in offline jobs
L1EmtDataP              - The Objy persistent versions of the digis, stored in the database
L1EmtDataK              - The Kanga persistent versions of the digis, for use in CM2 simulation
L1EmtEnv                  - The EMT offline environment
L1EmtOep                 - TC to digi converters, and monitoring and diagnostic code which runs on TCs
L1EmtConfig             - Classes to store configuration data in database
L1EmtConfigTools    -  Tools for inspecting and changing the EMT configuration data in the database
L1EmtSim                  - The EMT simulation used for MC production
L1EmtTools               - Various useful scripts and diagrams (no C++ code)

There is one package which does not contain runnable software:

L1EmtFirmware         - The Xilinx firmware code for the AX, FCX, FX and VX

There are also some non-EMT specific packages which contain EMT code. These are all offline packages:

L1TFMon                    - The fast monitoring code
L1TMonTools             - Tools for the above
L1TNtuple                   - The trigger ntuple production job
L1TOepSequences     - Sequences for TC/Digi tests
L1TOprMon                - The OPR monitoring code
L1TPlayback               - Trickle stream code (?) 

Dependency rules

Note that online code is not allowed to depend on offline code, and vice versa. Because there are some things needed in both, eg tagged containers, there is also a type of package called dual-use, and both online and offline may depend on these. But of course dual-use packages may not depend on online or offline.

This can get a little confusing: basically if you are going to add a class to a package, you must ensure that you do not create a forbidden dependency (eg no class in L1EmtOnline should
ever know about any class in L1EmtData or L1EmtSpy). But L1EmtOep may (and does) depend on L1EmtOnline, as does L1EmtCalOdf.

A note explaining all this in more detail can be found here.

A diagram of the EMT-related packages and their dependency structure can be found here.


Building the EMT online code

The emt code is routinely built in the online releases (see $BFDIST/online_releases). If you want to build your own test libraries then you should start with one of these releases:

newrel [-s <scratch area for libs etc>] -to <online_version> <test_release_name>

eg

newrel -s $BFROOT/work/d/dauncey -to 9.5.4 online9.5.4

You should usually use the latest online release. To find out what this is, and what tags make up that release, see the online releases hypernews.

Before you start building you need the environment variable

ODF_BASE=/afs/slac.stanford.edu/g/babar/dist/online_releases/<online_version>

This should already be set  for you by the emtSetup script (see Setting Up). But if, for example, you change the version of the online release you are using, you will need to change the value of ONCURRENT set in your .cshrc file and rerun the emtSetup script.
Remember to srtpath and gmake installdirs, as for an offline release. You add packages just like you would offline to, eg

addpkg L1EmtOnline

The online code is built using a different makefile system to the offline. The online makefiles are called Makefile, the offline ones are called GNUmakefile. So a dual-use package such as the confusingly named L1EmtOnline, which contains some fundamental classes used in both offline and online code, contains both types of makefile.

To make the segment level online library (i.e the one that runs on the rom, the only level of the online code we usually care about) do

gmake -f Makefile L1EmtOnline.segment

or alternatively,  if you are already in the L1EmtOnline directory

gmake -f Makefile segment

The library will appear in lib/vxworks/segment and will be called lib<package>.o, so in this case libL1EmtOnline.o.

Note that the libraries are dynamically linked on the ROM. So you need to also load your new library onto the rom along with all the other libraries and watch the xyplex window to make sure you don't get any link errors. Simply getting each individual library to compile correctly does not guarantee that the libraries will work together.


Libraries, scripts and links

Our production libraries live in the directory

/nfs/bbr-srv02/dataflow/emt

If you look in this directory you will see there are sometimes several versions of the same library, distinguished by the last bit of the filename. There is a separate directory

/nfs/bbr-srv02/dataflow/ir-2/emt/app

which contains softlinks to the particular version of each library that is to run in IR-2. When the rom boots up, a VXWORKS script is run to download the libraries and call any initial functions. This script (which lives in the same directory as the libraries, and has a link to it called startup in the links directory) uses the links to determine which libraries are downloaded onto the ROM.  There is another set of links (and another script) for the teststand, these are in

/nfs/bbr-srv02/dataflow/emt-test/emt/app

As you'll see if you read below, there is lots of room for getting these directory names wrong. For this reason, there are three aliases defined for you in the EMT setup file

libs = cd nfs/bbr-srv02/dataflow/emt              home of the libraries
links = cd /nfs/bbr-srv02/dataflow/ir-2/emt/app   home of the links for ir2
testlinks = cd /nfs/bbr-srv02/dataflow/emt-test/emt-1/app home of the teststand links

[Note that the teststand rom is an emt-1 rom. You must be careful to update the links in the right directory, because /ir-2/emt-1/app/ and /emt-test/emt/app/ also exist. This is because in the crate in IR2 there are 2 roms, the master rom in slot 1 (counting from 1, i.e. the leftmost slot), and the slave rom in slot 2. Our code runs on the slave rom, and we don't touch the master rom, which is under the control of dataflow. The directory structure is set up so that for every subsystem, xxx-1 refers to the master rom and xxx refers to all other roms in the crate, which are slave roms. The slave roms run different code to the master roms, but run the same code as each other.
In the teststand, however, we manage with only one rom, and our code runs on this. The dataflow system considers the leftmost rom in a crate to be the master rom and hence will load the code from emt-1 into it, whether or not it is actually in slot 1. So for the teststand our libraries live in /emt-test/emt-1/app/, while for the real system they live in /ir-2/emt/app/.
Take care not to get confused by the aliases used for the xyplinx  connections in IR2 (see below), which count from 0 not 1. So you would type
xyplex -f odf-emt-0
to talk to the master rom, in the leftmost slot, which gets its code from /ir-2/emt-1/app. To talk to the slave rom you use
xyplex -f odf-emt-1,
but this rom gets its libraries from /ir-2/emt/app/ not /ir-2/emt-1/app/.
Phew, glad we've sorted that  out.]

If you want to use your own library version instead of the production version, you must first copy it to the libraries directory, and then change the link. There are scripts to help you do this without making mistakes:

To copy the library use the script odfCopyAppTgt

odfCopyAppTgt  <library.o> <version number> <group>

<version number> is the label that gets appended to the filename and can be anything you want. If the library comes from a particular tag or release you should use this as the version number, otherwise use your initials or something informative (for others as well as you!).
<group> is emt for us.

To set the link use the script odfSetAppTgt

odfSetAppTgt  <platform> <type> <file> <group> <version>

<platform> is ir-2 or emt-test for the system in IR2 or the teststand, respectively.
<type>is emt in IR2 or  emt-1 in  the teststand
<group> is emt
<version> is the version tag you chose in the previous step.

These scripts live in $BFDIST/online_releases/<version>/Odf/tools/, but if just typing the name of the script doesn't work then you probably don't have your online environment set up right, and will run into other problems. If you just type the name of the script with no arguments it will tell you what arguments are needed.

You must reboot the rom in order to download the new libraries. A startup script (called startup) in the same directory as the links to the libraries, is run every time the rom boots. This script contains loads all the required libraries into the rom, and then may call some initialisation routines (eg starting the spy task). When you reboot the rom after a change, watch the output in the xyplex window to make sure that all is well and there are no problems with linking, or with missing libraries.

IMPORTANT: After doing any tests with non-production libraries, remember to change the links back and reboot the rom.
 

Permissions

In order to prevent just anyone from changing our libraries or links, only people on a named access control list have write access to the above directories.
To get a name added or removed from this list, contact the BaBar DAQ expert.


Setting up the links to use an online release

A typical set of links is the following (these are obviously from online release 3.0.0)

libBbrCalib.o -> ../../../cal/libBbrCalib.o.3.0.0
libCLHEP.o -> ../../../cal/libCLHEP.o.3.0.0
libCalFit.o -> ../../../cal/libCalFit.o.3.0.0
libCalMoments.o -> ../../../cal/libCalMoments.o.3.0.0
libCalOdf.o -> ../../../cal/libCalOdf.o.3.0.0
libCalOnline.o -> ../../../cal/libCalOnline.o.3.0.0
libL1EmtCalOdf.o -> ../../../emt/libL1EmtCalOdf.o.3.0.0
libL1EmtCalOnline.o -> ../../../emt/libL1EmtCalOnline.o.3.0.0
libL1EmtOdf.o -> ../../../emt/libL1EmtOdf.o.3.0.0
libL1EmtOnline.o -> ../../../emt/libL1EmtOnline.o.3.0.0
libL1EmtSpy.o -> ../../../emt/libL1EmtSpy.o.3.0.0
libOdfCompression.o -> ../../../cal/libOdfCompression.o.3.0.0
libOdfContainerTools.o -> ../../../cal/libOdfContainerTools.o.3.0.0
libOdfFileTransport.o -> ../../../cal/libOdfFileTransport.o.3.0.0
libOdfZLib.o -> ../../../cal/libOdfZLib.o.3.0.0
libPrmFit.o -> ../../../cal/libPrmFit.o.3.0.0
libProxyDict.o -> ../../../cal/libProxyDict.o.3.0.0
libRdfCommon.o -> ../../../rdflib/libRdfCommon.o.3.0.0
libRdfOdf.o -> ../../../rdflib/libRdfOdf.o.3.0.0
libRdfTools.o -> ../../../rdflib/libRdfTools.o.3.0.0
startup -> ../../../emt/startup.2.10.3*
startup.cal -> ../../../cal/startup.cal.2.9.12

L1EmtDiagnostics is not in the release and is just put in by hand.

TL 21 Oct 2003
This is no longer typical, the libraries are now combined into one library called libL1EmtApp.o
except for libL1EmtDiagnostics.o which should not normally be loaded into the ROM.
This is the current status of the links directory:

libL1EmtApp.o -> ../../../emt/libL1EmtApp.o.9.4.2-prefetch
libL1EmtApp.o.fastfex -> ../../../emt/libL1EmtApp.o.9.0.0-fastfex
libL1EmtApp.o.previous -> ../../../emt/libL1EmtApp.o.o8.15.3-Odf-D08-00-00
libL1EmtApp.o.previous2 -> ../../../emt/libL1EmtApp.o.8.15.3
libL1EmtDiagnostics.o -> ../../../emt/libL1EmtDiagnostics.o.V00-01-02


What machines to use for what task

In IR2

Run calibrations on bbr-farm06 (this machine is allocated to the EMT)
Make a xyplex connection from a bbr-dev machine, e.g. bbr-dev20 or bbr-dev100

For the teststand use dali or whistler for calibrations and xyplex connections.


Platform number and crate mask

For the IR2 system you should setenv ODF_PLATFORM 127
The crate mask is a hex number with bits set for each rom in the system. Ones you need to know are

EMT is 400
All the roms in the EMC are 3ff
Just the barrel EMC roms are ff (and so the endcap roms are 300)
GLT is 1000

So if for example you wanted to take a test run with just the EMT, EMC and GLT you would make a hex sum of
400,3ff and 1000, giving you a mask of 17ff.

For the teststand you should setenv ODF_PLATFORM 6 and use 0x2 as the cratemask.  Note that this number is determined by which set of fast control modules we have in our crate - at present we have set 6. The value of ODF_PLATFORM determines which FC modules and hence which crate you talk to, so if these get swapped you have to use the new value of ODF_PLATFORM. This number is displayed on the front panel of the FC modules.


A glossary of all the configurable parameters of the EMT

Algorithm Xilinx (AX)
 
Parameter Description Range Current value
jitterWindows[7] 0000000000000000
1111100000000000
1111100000000000
1111100000000000
1111100000000000
1111100000000000
0111100000000000
0011100000000000
timeAlignment 3
globalThresholds[5] 300
768
1920
256
2304
jitterThresholds[7] 0
80
96
112
128
256
384
3072
cfdProducts[14] 61680
61680
61680
61680
61680
61680
43690
0
0
0
0
0
0
0
bitmapThresholds[8] 128
128
128
128
128
128
128
128
cableMask
towerMask

Formatter Xilinx (FX)

 These parameters describe how much data is read out to the DAQ stream. Up to 16 CLK4 ticks of data can be read out for each DAQ line. Note that the lines are not all independent, eg Phi01 controls how much phi sum data is read out for AX's 0 and 1 - i.e. these have to be the same.
The range for all these parameters is 0-FFFF. HOWEVER there is not complete freedom in choosing these values, because at least one word of DAQ data has to be read out for each time slice. In practice this is best achieved by always reading out all the phi sum data.
 
 
Parameter Description Current value Map
Phi01 Input data summed over all towers in one phi strip ffff 1111111111111111
Phi23 ffff 1111111111111111
X01 Input data in the endcap tower of one phi strip ffff 1111111111111111
X23 ffff 1111111111111111
Y01 Input data in the rear 2 towers of one phi strip ffff 1111111111111111
Y23 ffff 1111111111111111
Bitmap01 Bitmap of which towers were over a certain threshold and which had most energy in a phi strip ffff 1111111111111111
Bitmap23 ffff 1111111111111111
Global0123 Output data (before ORing) to be sent to the global trigger for this phi strip ffff 1111111111111111

Fast Control Xilinx (FCX)
 
 
Parameter Description Range Current value
MapDelay 3
GlobalDelay 12
PhiDelay 1
XYDelay 1
ReadDelay 35
ReadPhase 6
SynchDelay 5
NSpyWords 256


Keeping the EMT running smoothly in IR2


What to do about a hot tower

What is a hot tower...

Occasionally one or more EMT towers will fire all the time (or very often).
This results in high occupancy in that tower and possible deadtime in the system.
The severity of dead time will also depend upon the amount of prescale for the level 1 lines affected.

Prerequisites

To make solving a hot tower problem easier do the following before being on call:- 
  1. Make sure you have the correct permissions to the configuration database.
    To verify this go to an online release, srtpath, and ir2boot. Then run the commands:-

    BdbAuthCmd lsmembers Configuration top
    BdbAuthCmd lsmembers Configuration emt

    The output of both commands should be of the form shown below. Check that your name is listed. 

    [bbr-farm06] 11:29 1622 ~/reldirs/6.2.4> BdbAuthCmd lsmembers Configuration top
    Initializing Objectivity use BdbApplication class
    ####################################################
    ######## BaBar Database Authorization Utility ######
    ####################################################
    Users in domain "Configuration" and group "top" :
    davidk ( , ) Feb 4 16:32 2000 David_Kirkby
    verkerke ( , ) Feb 4 16:33 2000 Wouter_Verkerke
    claudio ( , ) Feb 4 16:32 2000 claudio_campagnari
    rizzog ( , ) Feb 4 16:33 2000 Giuliana_Rizzo
    sciolla ( , ) Feb 4 16:32 2000 Gabriella_Sciolla
    varnes ( , ) Feb 4 16:32 2000 Erich_Varnes
    masahiro ( , ) Feb 4 16:32 2000 Masahiro_Morii
    raven ( , ) Feb 4 16:32 2000 Gerhard_Raven
    jan ( , ) Feb 4 16:32 2000 Jordan_A._Nash

  2. There should be a working version of the latest L1EmtTools package in the common use area.
    This area should also have the L1EmtConfigTools package built:

    make sure the program L1EmtChangeTowerMask is built correctly and executable.
    NOTE:- This application can change database information and produce locks.

Procedure to follow

  1. Is the L1 trigger rate so high that the experiment is running with significant deadtime? (normal deadtime is less than 1%)
    If yes, you need to do something about this fast.
    If not, you can take a little more time.


  2. Diagnose the location and characteristics of the hot tower:

    cd to your L1EmtTools dir and run QuickMon

    This will allow you to examine a select set of the latest fastmon plots.
    You can either list the most recent monitoring files and then pick the relevant one, or specify a time and date range.
    This will result in a file being written called QuickMonEmt.ps which you should view immediately.
    It can be compressed (~90KB) and copied to your home PC relatively quickly.

    Trouble shooting:-

    If QuickMon bails immediately:-

    • Check you have /usr/local/bin/perl.
    • Check you have a working version of PAW.
    • Check you don't have something strange in your .pawlogon file.

    If there are no JAS fastmon hbook files there are a few things you can do:-

    1. Look at JAS in ir2 or run it from your office (I do this on my linux machine).
      /nfs/bbr-srv02/bfdist/Production/bin/SunOS58/RemoteBabarJas
    2. Look at the L1 monitoring plots - the theta vs phi occupancy plots of all towers will show the culprit.
    3. You can also look at the level 3 event display, running in the control room (if you are there).

  3. Usually a hot tower is due to noise in the EMC electronics. However it is important to diagnose the problem correctly.

    First look at the QuickMonEmt.ps file:
    Page 1:- Tower occupancy (energy cut of 50MeV).
    Page 2:- Tower occupancy (energy cut of 100MeV).
    Page 3:- Emc crystal occupancy on input to Level 3.
    Page 4:- Emt energy versus time, energy spectrum, any energy above 32K ADC counts (~13 GeV).

    Identify from page 1 and page 2 the hot tower (x-axis = theta, y-axis = phi) then run the command:
    $BFROOT/detector/emc/bin/emt2emc theta[0-6] phi[0-39]
    This will give you necessary information about the EMC electronics in question.

    Go to page three of the QuickMonEmt.ps file and look at the area of crystals in question.
    Identify any hot (or dead) crystals (note: The numbers are slightly different and more complex for endcap).

    Single hot crystal EMC problem: noisy crystals Mask at Emc
    Group of 4 hot crystals eg. (endcap, barrel) EMC problem:- specific to CARE chip/UPC memory Mask at Emc
    Group of 12 hot crystals EMC problem:- specific to an ADB board Mask at Emc
    Group of 12 dead crystals (Example) EMC problem:- specific to an ADB board Mask at Emc
    Group of 24 hot crystals EMC/EMT problem:- specific to readout fibre/trigger summer Mask off in the Emt. Go to step 4)

    If the problem is EMC related, then page the EMC expert (or have the shifter do it). They may try to fix the problem, or mask out the noisy crystals. Since there are 24 crystals in a tower, it is better for the EMC to mask out individual crystals than for the EMT to mask out a whole tower. Level 3 looks at EMC data (not EMT data) and so will also need to mask out the problem, so it is easier all round if it is masked out in the EMC. EMC must be rebooted before any EMC masks are picked up.

    ****** If the EMC cannot fix the problem, for a short-term measure while they work on it, you may consider masking out the hot tower from the input to the EMT. Go to step 4). In this case only mask the hot tower if it is causing significant deadtime.

    Sometimes a hot tower will not affect the L1 rate because there is no zero-crossing eg. if the channel is approximately constant for each emt input tick. Since the tower is hot at the input to the L1 this is easily seen by DQM, but the M occupancy to the GLT will actually be _down_ in that bin (and in the neighboring bin too). However, if the origin is a hot crystal it may increase the L3 rate (by a lot!) because the crystal could have energy for every L1 accept. So always ask the shifters about both L1 and L3 rates when you talk to them. Don't assume they keep an eye on them or know what they should be. 

    It's useful to remember that L1 and L3 have a much higher crystal threshold than the EMC (data path) which means that even if a crystal is noisy, it can be low energy noise for us and we won't be affected at all. At least on one occasion they tried to be nice and masked off some crystals only for the trigger path and it turned out to be unnecessary (and bad since we lost those crystals completely when they were masked off). 

  4. To mask off the tower in EMT do the following:

    cd $EMTBUILDS/production/
    srtpath
    ir2boot

    Then run the command:

    L1EmtChangeTowerMask

    Press (1) to mask off a tower.
    Enter the theta coordinate.
    Enter the phi coordinate.

    Press (4) to list the towers masked off [check this].

    Press (9) to commit the change.

    This will create a new leaf in the EMT map. The new numeric key will be e-mailed to Hypernews.

  5. To update the alias tree and the run_type alias to point to the last change you now have to use the following script:

    L1EmtConfigTools/chgTowerMask.csh

    This updates the main run type aliases (PHYSICS, L1_PASS ..) - this is the what you should normally do.

    Should you want to run temporarily with the new configuration you can do:

    L1EmtConfigTools/chgHotTowerMask.csh

    which updates the run type PHYSICS_HOTTOWER.

  6. Ask the shifter to refresh the run type list at his/her next convenient moment.

  7. A hypernews will be automatically posted to the Trigger Operations HyperNews group.
    You should also post to Calorimeter Operations briefly describing what you have done, taking care to say exactly which tower(s) you had trouble with.


    Checking the alias tree


    Live fast monitoring

    The trigger fast monitoring code lives in the package L1TFMon, with the EMT-specific code in L1TFMonEmt. L1TFMon will make a binary, L1TFMonXtcApp, which you can run on an XTC file to produce an hbook file of histograms. You can control the level of detail the histograms cover (i.e. how many histograms) by setting the expertise flags in L1TFMonXtcApp.tcl.

    To run the monitoring on a TCL file do

    L1TFMonXtcApp -b 3000000 -n <# of events> -f XTCFILE.xtc L1TFMonXtcApp.tcl

    The same monitoring is run live in IR2 and is looked at by the shifter. Instead of running on an xtc file, the job runs via shared memory on a subset of data as they are taken (via a trickle stream) and the histograms are written to shared memory. They can be viewed by the JAS browser and update in real time. The histogram layout the shifter sees with the JAS browser is determined by an html page in the package L1TMonTools. The html for the EMT monitoring is L1TMonTools/FastMonHTML/trg-EMT.html.


    Location of spare boards 


    One spare TPB is kept at IR2. There is a double row of cabinets in the hall, near the roller doors, and our spare lives in the one marked 'Operational Spares'. This cabinet is kept locked, and the key lives in a key box in the control room, mounted on the wall next to the stationery supply cabinet, above the first aid kit.
    Additional spare TPBs (2) have been moved from the teststand to the Trigger cabinet, in the same IR2 hall.
    PreProduction TPBs and the spare TCB live in the teststand, which is in the dataflow lab (central lab, room G223). This room is often locked - if you need to get a spare at night call security to get them to open it for you.

    Last update: SR, Sept 13th 2002


    The TRB

    The TRB, mounted on the TCB, is the board with the optical fibre transmitters. It is the only piece of hardware in the EMT system that we have ever seen fail - it stopped emitting light, so the ROM could never see the link.  Replacing the TCB in IR2 with the spare allowed us to take data again.

    The TCB fitted with the faulty TRB was moved to the teststand and worked fine for several months before failing again, after which it would always work for the first couple of minutes after the crate was powered on, and then fail. The problem turned out to be a blown capacitor on the TRB, and was reparied.

    The TRB mounted in the TCB is almost the same as that used on the EMC. The differences are:

    1) An EMT TRB does not have direct cooling and so has large heatsinks mounted on it
    2) THE EMC TRBs have two jumpers on the top left-hand corner of the board - these should not be there on an EMT TRB
    3) There is a PROM to configure the xilinx - this is to read out the EMB. None have been put into the EMC TRBs, but there
         is one on the EMT TRB.

    If the EMT TRB fails and you have no spares, it is always possible to have someone mount some heatsinks onto an EMC TRB and use that instead.


    How the EMT configuration system works


    CalCycleTC files: how to read, make, and use them

    Last update: 4th February 2003 TL

    For a given run type, you need to define how many iterations are going to be performed at each level of the finite state machine,
    eg how many meta, macro, major, minor cycles etc.
    This is obviously important for calibration and test runs, but also necessary for normal running.
    In the latter case the CalCycleTC is rather trivial, with just one execution of each transition.

    As well as containing the number of cycles at each level of the finite state machine, our cycleTC files also select which actions
    are attached to the finite state machine, and sets which bits will be set in the CSER.
    So if, for example, we want to take a front-end playback run, with the spy set to start on a startPlayback command and stop when full,
    then we would need to attach the FEPB actions and set the relevant bits in the CSER. This is done by selecting

    L1EmtMetaCycle::L1EmtCalChoice metacal=L1EmtMetaCycle::fepb;
    L1EmtMetaCycle::L1EmtCserChoice metacser=L1EmtMetaCycle::fecc;

    in the code which makes the cycleTC.

    Read

    To read an xtc file containing the CalCycleTC object you must checkout the CalOnline package.

    addpkg CalOnline Vxx-xx-xx (where Vxx-xx-xx is the latest tag)
    gmake CalOnline.TestCalCycles

    You can then run:

    TestCalCycles xtcname.xtc

    Make

    There are a series of files in L1EmtCalOnline with names like emtFClashCycles.cc which you can build
    gmake L1EmtCalOnline.bin
    to produce executables, which when run will create a cycleTC.
    WARNING: As of Feb. 2003 only emtTowerCycles is known to function exactly as required.

    Use

    You then have to put this cycleTC into the database and attach it to a key, in order to use it.
    The stages are as follows (let us take fepb1 as an example):

    1) Make the cycleTC file:

    > emtFepbCycles1

    You will see the output:

    Meta myLevel = 3
    Meta identity = {IdQual: 1023751.0}
    topTC sublevel = 2
    topTC contains = {IdQual: 991237.0}
    Macro myLevel = 4
    Macro identity = {IdQual: 1023752.0}
    Meta subLevel = 4
    Meta contains = {IdQual: 1023752.0}
    Minor TC extent = 60 adr = 0x30cc8
    Minor Ncmds =
    Enter name of file to store cycle arena:

    Give it a sensible name, such as emt-fepb1.xtc.

    2) Copy this xtc file into the direcory /nfs/bbr-srv02/dataflow/rdf/Emt

    3) Tell the database about it:

    ir2boot

    createFileIdentifier -d "fepb1 cycletc" Emt EmtCycles emt-fepb1.xtc

    4) Make a new top key replacing the existing cycleTC with this new one using the database browser CfgExplorer.

    5) Create an xtc file in /nfs/bbr-srv02/dataflow/rdf containing pointers to all the experiment's xtc files for this new top key, by executing the command:

    createFileTable new_top_key_in_decimal

    The new top key can then be used by the CalControlProgram (see the section on the cable error calibration).


    How to interpret the flat files used to make our configuration objects (.ax, .fx, .fcx)

    The configuration TCs are made starting from flat files, and the configuration data objects (L1EmtAx, L1EmtFx, L1EmtFcx) all have methods called writeFile and readFile. You can always work out the structure of the flat files by looking at these methods, but here's a guide to save you the trouble.

    Algorithm Xilinx (.fx)
     
    0000 001f 001f 001f 001f 001f 001e 001c  8 jitter windows
    6000  time alignment (only the upper 3 bits are significant, see below)
    0900 0100 0780 0300 012c  global thresholds YXEGM
    0050 0060 0070 0080 0100 0180 0c00  7 jitter thresholds
    0001 0000 fffe 0000 0000 0000 0000 0000 fir constants (1,0,-2 : see below)
    0080 0080 0080 0080 0080 0080 0080 0080  bitmap thresholds
    077e  cable mask 

    Some notes on the above format

    The time alignment number is a 3 bit number, and only uses the upper 3 bits of the hex time alignment word in the file. So 6000 = 0110 0000 0000 0000 actually corresponds to a time alignment of 6000 >> 13  = 011 = 3.

    The fir constants are stored in the file as unsigned integers, hence -1 is given by ffff, -2 is fffe, -3 is fffd, and so on.

    Formatter Xilinx (.fx)

    ffff ffff ffff ffff ffff ffff ffff ffff ffff

    The above file corresponds to reading out the maximum amount of data for each data line, ie 16 ticks (ffff = 1111 1111 1111 1111). You can reduce the amount of data read in each line. Note however that for every tick there must be at least one bit set (this is a hardware requirement) so it makes sense to always read out the full 16 ticks of phi data.

    The 9 words in this file correspond to the following:
     
    Phi01
    Phi23
    X01
    X23
    Y01
    Y23
    Bitmap01
    Bitmap23
    Global0123

    Fast Control Xilinx (.fcx)

    3 c 1 1 23 6 5 100

    In the example above, the 8 words have the following meanings
     
    3 MapDelay
    c GlobalDelay
    1 PhiDelay
    1 XYDelay
    23 ReadDelay
    6 ReadPhase
    5 SynchDelay
    100 NSpyWords


    How to change the EMT  thresholds and/or jitter windows

    To Get the new constants into the database:

    1) Remake link aaaalink.ax to the new .ax file with the new thresholds in.

    2) In /nfs/bbr-srv02/dataflow/constants/emt  type source axchange
    This copies/unpacks the ax and mask files into individual ax source files.

    Here are the stages  to put things into the database: (<ID> is an identifier string you invent)

    3) bin/SunOS5-Objy5.2/axCreateConfig <ID>
        This make the L1EmtAxTc in /nfs/bbr-srv02/dataflow/rdf/Emt
    4) createFileIdentifier -d"ax configuration Run <ID>" Emt EmtAxConfig axConfig<ID>.xtc
        Assigns an EMT ax configuration key to this L1EmtAxTC
    5) Change to the latest online release and run srtpath and ir2boot. Type: 

                setenv PATH /nfs/bbr-srv02/bfdist/DBUtils:${PATH} 

                 L1EmtConfigTools/chgTowerMask 
     

        Makes a new top key which is the same as current_top_key except that the emt ax key is
        replaced by the last one made, i.e the one you made in step 2. This is done through the ALIAS TREE Config DB
        (Latest update: SR Sept 13th 2002)


    How to change the data volume we read out

    The readout of DAQ data from the EMT is controlled by the Formatter Xilinx, and the amount of data we read out is configured using the Fx configuration objects.

    Each TPB has 4 Axs, and hence 4 sets of phi, X, Y data. For simplicity the amount of data read out is not fully configurable, but fixed in pairs, ie whatever is read out for Ax0 is also read out for Ax1, and whatever is read out for Ax2 is also read out for Ax3. Hence the readout of phi data, for example, is controlled by two words, Phi01 and Phi23.

    There are 9 logical data lines,  where each line actually refers to a pair of lines:  0&1 or 2&3. The lines are:

    Phi01, Phi23, X01, X23, Y01, Y23, Bitmap01, Bitmap23, Global0123

    Each of these words can range from 0 to ffff, where ffff=1111 1111 1111 1111 means that we read out data for a full 16 clock 4 ticks. (The global data are read out for 32 clock 8 ticks, but are packed together into 16 words). To choose to read out just a particular range of data words, change this word so that bits are only set for the clock ticks you want.

    Note that the formatter Xilinx design requires that at least one word of data is read out for every clock tick.So in practice it is best to read out the full 16 ticks of phi data, which are the most useful, and to reduce the others if necessary. So the first two words of the fx configuration data should always be ffff ffff.


    The new EMT configuration system

    At present our configuration data are not directly stored in and loaded from the configuration database, instead there is a pointer (called a BdbConfigFileIdentifier) to a tagged container which is actually on disk. In addition, the tower mask information is just stored in a flat file on disk, pointed to by the link

    /nfs/bbr-srv02/dataflow/constants/emt/aaaalink.mask

    The methods which actually download the constants during the configure action are in the class L1EmtCalOdf/L1EmtBase. Other classes, in particular L1EmtCalConfig (the config action) inherit from these and so call these methods inherited from the base class.

    The configuration data are passed to the rom in tagged containers (L1EmtAxTC, L1EmtFxTC, L1EmtFcxTC). The method AllTCSet takes these and writes the configuration data to the boards. It first configures the Ax (AxTCSet) then overrides the default mask information in the L1EmtAxTC by reading in the flat mask file, using the method AxReadMaskFromFlatFile. Then the methods FxTCSet,FcxTCSet and CserSet are called.

    In the new system, this machinery  is not changed - what is changed is the 'behind the scenes' reverse dataflow which delivers the configuration TCs onto the ROM. The configuration data cannot be stored in the database as TCs, instead they are stored as persistent classes (L1EmtAxRawDataP,  L1EmtFxRawDataP, L1EmtFcxRawdataP - these classes are in the package L1EmtConfig). There is then a proxy class for each type, called L1EmtXXTCProxy, which will fill and return a TC via its fillXTC method. This is the 'standard' way to do things and is documented here.

    There is other useful information about the config database, including the  just-deployed alias trees, here.

    In addition, the package L1EmtConfig contains the classes L1EmtXXRecord. These are what are obtained when an offline (Beta) job extracts the configuration data from the database. Rainer Bartoldus is the best person to ask how to do this.
     
     

    Utilities

    I have written a package of utilities, L1EmtConfigTools. This contains the
    following (see the README file)

    L1EmtAxConfigWriteToDb                          Make an L1EmtAxTC and write it to the DB
    L1EmtFxConfigWriteToDb                          Make an L1EmtFxTC and write it to the DB
    L1EmtFcxConfigWriteToDb                         Make an L1EmtFcxTC and write it to the DB

    L1EmtAxConfigReadFromDb                     Read Ax info as a transient class
    L1EmtFxConfigReadFromDb                     Read Fx info as a transient class
    L1EmtFcxConfigReadFromDb                     Read Fcx info as a transient class

    L1EmtAxConfigReadFromDbToTC                   Read Ax info and create an xtc file in directory config
    L1EmtFxConfigReadFromDbToTC                   Read Fx info and create an xtc file in directory config
    L1EmtFcxConfigReadFromDbToTC                   Read Fcx info and create an xtc file in directory config

    L1EmtDecodeAxConfigTC                           Read in an Ax xtc file and print out the contents
    L1EmtDecodeFxConfigTC                           Read in an Fx xtc file and print out the contents
    L1EmtDecodeFcxConfigTC                           Read in an Fcx xtc file and print out the contents

    L1EmtAxReadTowerMaskFromDb          Print out the tower mask stored in the DB

    L1EmtChangeTowerMask                Command line application to modify the tower mask

    To use any of the above which access the Objy database, then ambientboot (or similar) must be run beforehand.

    [The following is obsolete. SR 13/09/2002]

    How to switch to the new configuration system

    1) Put the new objects into the database and add them to the EMT map. It is perfectly acceptable (though potentially confusing) for both the new persistent objects and the old BdbConfigFileIdentifiers to both be present in the map - which one is picked up will depend on the secondary key used to extract the TC (more below). As a first step it might be good to make a map with the configuration data duplicated in the two object types, allowing you to switch between the two systems easily. Later you could make a map which just contains the new objects.

    If you want to test things out before polluting the official database, you can always import a configuration snapshot into your own private database (see instructions in the package HOWTO), then SETBOOT to that. Then you can use all the database applications, including BdbConfigBrw, on your private database, and also configure the TestStand from your private DB.

    To make the new objects and add them to the database, use the applications L1EmtXXConfigWriteToDb in L1EmtConfigTools package. Obviously you should edit these to use the constants you want and recompile.

    To add these objects to the map (BdbConfigMap:Emt), you must use the right names - this is very important as it determines how these objects are found. You should use the following

    AxConfig
    FxConfig
    FcxConfig

    (Note that the old pointers to TCs are named 'Ax ConfigTC','Fx ConfigTC' and 'Fcx ConfigTC'. Do not use these names by mistake).

    Map 55 was used as a test - look at this for an example of how these  objects should be named and how the map should look.
     

    2) Change the code running on our libraries to adapt to this change

    Only two simple changes are required, one in

    L1EmtCalOdf/L1EmtBase.cc

    (to stop overwriting the tower mask with the flat file info) and one in

    L1EmtCalOdf/L1EmtCalConfig.cc

    (to change the key used to retrieve the object).

    The changes needed are in the code but commented out. Search for the string CONFIG_UPDATE in these two files to find what you need to do.

    Then rebuild the L1EmtCalOdf library and load it onto the rom.

    Note that this code has been fully tested and does work - in a test I successfully  configured the EMT in IR2 using the full machinery (run control).
     
     
     
     
     


    How to create an EMT run type alias

    SR : This  section is also obsolete - since the deployment of the ALIAS TREE you should use the new DB browser
                  i.e., CfgExplorer
    Using BdbConfigBrw, select (right-click) emt then BdbConfigAliasMap:Default. Click on the most recent version, and up wil pop a panel of aliases and their corresponding top keys. You can then change these or add new ones, and commit the change, creating a new version of the alias map. When you click commit, a hypernews is automatically posted to the Configuation DB history newsgroup.

    To pick up this emt map in run control you would start run control with runOrcemt instead of plain runOrc with no arguments.

    There is a corresponding default alias map that run control  normally uses - this defines what configuration key is used for PHYSICS, for example. Note that this is not top/BdbConfigAliasMap:Default (not sure what this is for) but actually orc/BdbConfigAliasMap:Default.


    The Spy


    The SPY: Overview

    The spy is a task which monitors the performance of the Algorirthm Xilinx. There are dedicated data lines on the TPB which allow for intermediate stages of the AX calculation to be stored in a fifo and read out under VME. The spy process takes these data and runs the EMT simulation, to cross-check every stage of the AX processing. If any errors are found the spy data can be dumped to a file, and error bits can be set in the L1EmtSlotTC - these are later copied into the L1EmtErrorDigi.

    The spy process runs as a separate VxWorks task on the EMT rom. It runs at very low priority, so as not to interfere with normal data-taking, and samples data about once per second. The code for this task may be found in L1EmtOdf/L1EmtBacgroundTask.cc. This process works in tandem with the checkSpy() function of the L1Accept action (L1EmtCalOdf/L1EmtFEXL1Accept).


    Configuring the filling of the SPY fifos on the TPB

    The filling of the spy fifos is configurable: options are

    Start running when a start playback command is received
    Always start

    Stop running when the spy fifo is full
    Run continuously

    These options are selected in the cycleTC associated with the configuration key. Functions to make these TCs live in the package L1EmtCalOnline - see more details here. These options are read during the configure action and are written into the CSER on the TPB. You can check them by typing VmeCserRead at the xyplex prompt.


    How to run the spy

    The spy task is started by the following line in the rom startup script:

    taskSpawn("spytask",127,0x0002,20*1024,L1EmtBackgroundTask)

    See the VxWorks documentation or online help for more details of this command. 127 is the priority.

    The spy is currently set up so that it is running but dormant. The following commands exist to control it (defined in L1EmtOdf/L1EmtBackgroundTask.cc)

    StartSpy                            activates the spy
    StopSpy                                puts the spy to sleep
    ShowSpyStatus               shows whether the spy is active or dormant
    ClearSpy                            clears any errors and reactivates the spy

    To start the spy by default on every run, the function StartSpy() should be called in the L1EmtFEXBeginRun action.

    Currently, if the spy finds an error it will dump out all the spy data to the file

    /nfs/bbr-srv02/dataflow/ir-2/emt/app/L1EmtSpyOutput.txt

    and will go to sleep. When the spy is running routinely this is not the ideal behavour - it can be changed in the function SpyDump() in L1EmtBacgroundTask.cc.


    How to interpret the output

    The if the spy finds errors, bits are set in the spy error word as follows (these are defined in L1EmtOdf/L1EmtBackgroundTask.cc)

    Bit 31 is speial. Since the spy is not run on every event, most events will have no error bits set. When the spy is run, bit 31 is set. So if only bit 31 is set this means that the spy ran but found no errors; if no error bits are set this is becasue the spy did not run at all.

    Bit 10  TPB failed to give SpyFull
    Bit 11  SpyIterator found frame in wrong word
    Bit 12  Frame was incorrect
    Bit 13  Serial Number was incorrect
    Bit 14  Delayed and original Raw Maps did not agree
    Bit 15  Delayed and original Jitter Bins did not agree
    Bit 16  Simulation comparison failed
    Bit 17  Simulation BeforeNN comparison failed
    Bit 18  Simulation FromNN comparison failed
    Bit 19  Simulation AfterNN comparison failed
    Bit 20  Simulation Theta Maps comparison failed
    Bit 21  Simulation FIR Output comparison failed
    Bit 22  Simulation ZXIN comparison failed
    Bit 23  Simulation Jitter Bin comparison failed
    Bit 24  Simulation Raw Map comparison failed
    Bit 25  Simulation Jitter Window comparison failed
    Bit 26  Simulation DaqG comparison failed
    Bit 27  Simulation Global Output comparison failed
    Bit 28  Spare
    Bit 29  Spare
    Bit 30  FrontPb run only; FrontPb and Spy did not agree
    Bit 31  Reserved; do not set
     


    How to take test runs


    How to select the run type

    If you are using the dataflow gui:

    Click on the word Configure on the gui, and a box will pop up.

    Enter the configuration key of the run type you want, either as a decimal number or as a hex number preceded by 0x, in the environment field.

    If you are using run control

    (this will not make much sense if you have never done DAQ shifts, so get the DAQ shifter to help you if necessary)

    You cannot just enter a configuration key number into the run control, because "that isn't in the design" (ahem). This might change one day, to make it easier for mere mortals to do test runs, but don't hold your breath. So if you make a new test key and want to take a run of that type using run control, you have to first make an alias for that top key in the EMT alias list in the configuration database (instructions here). You don't have permission to change the official alias list. Then you start run control with

    runOrc emt

    (as opposed to the usual runOrc with no arguments)

    Then when you select the run type, instead of seeing the usual list of run types (PHYSICS, COSMICS, etc) you see the list of runs in our alias list. Then you can take a run in the usual way.
     


    Current list of top keys

    This list becomes obsolete very easily, so you are advised to check which is the right key by firing up the browser and looking at the EMT alias table. Or you can use the utility L1EmtConfigListAliases in the L1EmtConfigTools package.
     
    Key (decimal) Run type Details
    640 BEPB
    641 FEPB1 Playback cycle once; Spy start on start playback command
    642 FEPB2 Playback cycle continously; Spy start on start playback command
    643 FEPB 3 Playback cycle continuously; Spy start always
    619 EMC-EMT test run
    620 Peak-zero cross test
    826 Test FEPB run with FIR weights 1,0,-4. Playback cycle once; Spy start on start playback command
    827 Test FEPB run with FIR weights 1,0,-4. Playback cycle continuously; Spy start always


    How to take a cable error run

    The current run has this cycle structure:
    16 Macros
    1 Major per macro
    5 Minors per major
    1 L1 Accept per minor.

    Ideally we probably want a few more minor cycles (say 10) which is a very easy change to make, but what we have will do for now.

    TL Sept 2003:
    This calibration tests for "AX Cable Errors".
    An AX Cable Error has 3 possible causes:

    1. Frame Clash
      A frame clash occurs when the frame bit on the cable arrives at the same clock tick as the EMT board frame.
      This could cause the data to become garbled since the EMT is reading from the dual-port RAM at the same time as the data is being written in.
    2. Frame Drift
      This is when the distance between the frame bits changes (they should be a constant 16 ticks apart).
      This indicates that some of the frame bits are missing on the cable or that the clock phase is wrong.
      See this document for further details.
    3. Loss of Cable Accident
      This occurs when the EMT cannot see the clock on the cable.
      It could indicate simply that the cable is unplugged or it could be a more complicated problem.

    Prerequisites for executing a cable error run:

    (last update TL October 2003)

    The EMT builds area should have the latest working tags of L1EmtOep and L1EmtTools.

    It should specifically have built L1EmtOep/L1EmtCalTCRecApp.

    Instructions to do a cable error run:

    (last update TL August 2003)

    NB The config key to use is 0x428

    • You should open 2 terminals: 1 on bbr-farm06 and 1 on bbr-dev20.
    • In the bbr-farm06 terminal go to the online release where you have L1EmtCalTCRecApp built:
                      
      • srtpath
      • setenv ODF_PLATFORM 127
      • showPartitions
    • If the result of this does not read "No partitions are allocated on platform 127" check that no one is using the EMT or EMC partitions before proceeding.
      (The EMT and EMC partitions are 0x400 and 0x3ff respectively. So if the last 3 digits of any of the crate masks are 800 or 000 you are OK.)

    • In the bbr-dev20 terminal:
      • xyplex -f odf-emt-1
    • On the bbr-farm06 terminal type:
      • rebootPartition -c 0x7ff
      The xyplex window should show activity, ending with an arrow prompt.

    • You should now run the script:
      • L1EmtTools/fcCalib
    • The xyplex and event level windows should show activity and the programs should terminate normally.
      (If it hangs just do ipcs (if there are any entries under your username do ipcCleanup), killPartition and rebootPartition and try again!)

    • To quit the xyplex window type:
                
      • Ctrl-]
      • quit

    Results of a cable error run:

    In the directory from which you ran there will be an hbook file called EmtFrameClash.hbook. You can easily look at the plots in this hbook file in PAW by running frameclash.kumac in the L1EmtOep package.

    exec L1EmtOep/frameclash.kumac

    Below is a brief explanation of the available plots:

    1. Standard set of cable error plots for the current synchDelay value.
    This is 10 pages (one for each TPB) of plots of the errors on individual cables.
    Some of the plots are colour coded with red or green borders. These are the split cables.
    Plots with the same colour border should be identical.

    2. Split Cables.
    This is a single plot which will show if any split cable error bits did not match for a given TPB. This plot should always be empty.
    If anything shows up, you can find the offending cable by checking the colour coded plots for that particular TPB from option 1 above.

    3. Safe frame offsets.
    This option was designed to compare two synchDelay values, however this has never been implemented.
    Instead it shows, for the current synchDelay, a plot of the cable error positions vs all cables so you can see the frameclash position for every cable in one plot - i.e. a summary plot.
    Good cables have filled yellow histogram bars and bad cables have filled red histogram bars.
    It is essential to remember that these are plots of frameclash positions so a safe frame for all UPCs will be at least one offset less than the height of the lowest yellow histogram bar. Note also that the current frame-offset value is 15.
    Good cables are defined as those which only give one frameclash position from the 16 possible frame offsets.
    A bad cable is anything else ie. a bad cable may have zero cable errors for all frame offsets, or may have cable errors at more than one position.
    To see the actual cause of a bad cable you have to consult the plots in option 1 above.
    The height of the red histogram bars is meaningless and has been set arbitrarily.


    An important subtlety in choosing the frame offset

    Notes by Paul Dauncey:

    We have two adjustments, the UPC frame offset and our synchDelay.
    Assume the synchDelay is fixed for now; the frame offset delays the UPC
    sending its data by the number of CLK60's specified in the offset. The
    EMT sees the data appear in the CLK4 which started _after_ the CLK4 (i.e.
    the frame) of the UPC. So, for example, with the offset set to 0, then
    say it looks like the below;

    UPC   ________|_______________|_______________|_______________|____
                     Data Word 1

    EMT   __|_______________|_______________|_______________|__________
                               Data Word 1

    The frame offset can be incremented from 0 to (in this case) 9 with
    no effect; with an offset 9 it looks like;

    UPC   _|_______________|_______________|_______________|___________
                              Data Word 1

    EMT   __|_______________|_______________|_______________|__________
                               Data Word 1

    However, setting it to 10 would cause a frameclash

    UPC   __|_______________|_______________|_______________|__________
                               Data Word 1

    EMT   __|_______________|_______________|_______________|__________
                                 Garbage

    and going to 11 would give

    UPC   ___|_______________|_______________|_______________|_________
                                Data Word 1

    EMT   __|_______________|_______________|_______________|__________
                                               Data Word 1

    i.e. the data in the EMT are delayed by a CLK4 which directly contributes
    to the latency. The conclusion is that the offset must always be on the low
    side of where the frameclashes appear (i.e. 0-9 here, not 11-15). Unless we
    cannot, because the frameclash appears at that value, offset=0 would seem
    like a good value.

    However, what happens if the synchDelay adjustment is taken into account also?
    The synchDelay value is defined by the requirement that the CLK8 edges align
    in the GLT. However, there are two such edges per CLK4 and so there are two
    possible values in the synchDelay 0-15 range which satisfy the requirement.
    These appear to be 4 and 12, from the measurements we made when FCX V5.2 was installed.
    (TL Sept 2003: the EMT syncDelay is actually set to 5 so this apparently changed at some point)
    These just shift the whole of the EMT timing (and hence output)
    by that many CLK60's. For instance, if the UPC's have frame offset = 0 set
    and the situation is as follows, then

    UPC   _|_______________|_______________|_______________|___________
              Data Word 1

    SynchDelay=4
    EMT   ____|_______________|_______________|_______________|________
                 Data Word 1                          TTTTTTTT

    SynchDelay=12
    EMT   ____________|_______________|_______________|_______________|
                         Data Word 1                          TTTTTTTT

    The trigger on a CLK8 (here shown by TTTTTTTT) comes a fixed number of
    EMT CLK8's after Data Word 1, so clearly, using synchDelay=4 cuts off
    a CLK8 of latency directly. However, if the UPC frame offset = 0 instead
    was like the following;

    UPC   _________|_______________|_______________|_______________|___
                      Data Word 1

    SynchDelay=4
    EMT   ____|_______________|_______________|_______________|________
                                 Data Word 1                          TTTTTTTT

    SynchDelay=12
    EMT   ____________|_______________|_______________|_______________|
                         Data Word 1                          TTTTTTTT

    then synchDelay=12 is clearly better. I think the only way to know which
    to use is to do a frameclash for synchDelay=4 and then also for 12. One will
    see the frameclashes at a smaller offset (presumably off by 8) from the other.
    Whichever seems frameclashes at the smaller offset is the one to use. The
    only expection is if frameclashes appear at offset=0 for one synchDelay
    value, in which case we use the other.

    One subtlety is that if we can _almost_ squeeze in to one synchDelay setting
    except a few UPC's in the tail give frameclashes at offset=0 for that one,
    we could probably get away with using synchDelay +/-1 on the values of 4
    or 12, as the settling time at the GLT is much better than a CLK8 period.


    How to take a UPC serial number run

    (last update TL October 2003)

    The run can be taken in either of two ways; from the central online run control or through a stand-alone release.

    For central online run control:

    • In the "BABAR Orc GUI" window, from the Control button, select PREPARE_FOR_CALIBRATION.
      The "Central Calibration GUI" window should appear.

    • WAIT_FOR_READY should appear below all buttons except the EMT button, which will show NOT_REQUESTED.
      Select SHUTDOWN on all the buttons other than the EMT and wait for all the red terminals to disappear from the screen to your right.
      Then from the EMT button, select REQUEST_FOR_CALIBRATION and wait for READY to appear below.

    • From the EMT button, select CALIBRATE and wait for FINISHED_OK to appear below.

    • To do another run, from the EMT button, select RESET and then repeat the previous step.

    • When finished, select SHUTDOWN from the EMT button and wait for the red terminal to disappear from the screen to your right.
      Then click DISMISS in top LH corner of the "Central Calibration GUI" window.

    For stand-alone:

    NB the config key to use is 0x866

    • You should open 2 terminals: 1 on bbr-farm06 and 1 on bbr-dev20.
    • In the bbr-farm06 terminal go to the EMT builds production release:
                      
      • srtpath
      • setenv ODF_PLATFORM 127
      • showPartitions
    • If the result of this does not read "No partitions are allocated on platform 127" check that no one is using the EMT or EMC partitions before proceeding.
      (The EMT and EMC partitions are 0x400 and 0x3ff respectively. So if the last 3 digits of any of the crate masks are 800 or 000 you are OK.)

    • In the bbr-dev20 terminal:
      • xyplex -f odf-emt-1
    • On the bbr-farm06 terminal type:
      • rebootPartition -c 0x7ff
      The xyplex window should show activity, ending with an arrow prompt.

    • You should now run the script:
      • L1EmtTools/snCalibFast
    • The xyplex and event level windows should show activity and the programs should terminate normally.
      (If it hangs just do ipcs (if there are any entries under your username do ipcCleanup), killPartition and rebootPartition and try again!)

    • To quit the xyplex window type:
                
      • Ctrl-]
      • quit

    Results of a serial number run:

    • The ouput goes to an xtc file in the directory /nfs/babar/calib/emt/

    • The post calibration validation should also run several jobs to produce a plot in postscript format as well as a detailed text file.
      These files are linked from the Trigger Operations webpage. Follow the "Data Quality / Fast Mon" button.

    • If you ran a stand-alone calibration or for some other reason the plot has not been created, you can do the following in any offline release greater than 12.5.0 or any online release greater than 8.15.4
                    
      • srtpath
      • EMT_VALIDATE
    • The colour coding of the plot is:
      • Blue:- Bit Pattern corruption only.
      • Pink:- Serial Number corruption only.
      • Red:- Both Serial Number and Bit Pattern corruption.
      Pink and Red are potential Hot Towers.

    • The driver files for the validation process are found in /nfs/bbr-nfs03/detector/trg/EMTCalibMon/
      and it is essential that they are kept up to date, particularly the UPC serial number list.

    • To get older calibration data which have been copied to tape and deleted from disk, see here.


    How to make a file of playback data and take a playback run.

    The CSER controls whether the TPBs read their input from the cable inputs or from the playback memories. This is set up during configuration, when the cycleTCs are read in - it is the cycleTCs which contain this information to be stored in the CSER. Note that there are several types of playback run, single shot, continuous, etc. See how to make and use a cycleTC. So to take a playback run you simply use a key containing the correct EMT cycleTC object.

    The playback data are read in from a flat file on disk, in the constants area /nfs/bbr-srv02/dataflow/constants/emt. The files (actually links) aaaalink0.fepb to aaaalink9.fepb contain the playback data for the 10 tpbs. These links are referenced in the code in L1EmtCalOdf/L1EmtBase::AllTCSet. So you simply make a .fepb file containing the data you want, change these links to point to it, and take the run.

    In L1EmtOnline there is a simple program called fepbCreateFile.cc, which takes a vector of energy values and writes these into a .fepb file, by making an  L1EmtFrontPb object and then using its writeFile method. You can build this by doing gmake L1EmtOnline.fepbCreateFile.


    How to take a special EMC test run where the EMC writes out the UPC trigger tower data

    There is a special type of test run in which the EMC writes out the data that it sends to the EMT, as well as its normal data. The key for this run type, which may be found in the list here, consists of a standard EMT key but a special EMC key. The EMC writes its data to a different TC, and so this sort of test run will fail if you attempt to process it in OPR, for example. You take a run as normal, but using this key, but make sure you label the run as not for OPR! You analyse this data using a special application in L1EmtOep, described here.

    The switch to tell the EMC software to write out the trigger tower data into modified TCs is in the EMC's CycleTC object.

    If/when the EMT configuration changes, you will want to make a new EMC-EMT test run key containing the new EMT configuration. You do this as follows (see the section on the configuration database for more details)

    1)Make a new top key based on the current EMT-EMC test run key
    2) Replace the EMT top map with the top map describing the new EMT configuration.

    If/when the EMC configuration changes , you will want to make a new EMC-EMT test run key reflecting the new EMC configuration. You do this as follows

    1) Make a new EMC top  map based on the new EMC map describing the new configuration
    2) Replace the EMC cycleTC object by the one used in the EMC map in the the current EMC-EMT test run key (ie pick up the new EMC config objects, but retain the special cycleTC which tells the EMC to write out the trigger data)
    3) Make a new top key, using this new EMC map you have just made, and update the EMT run-type alias list so that EMC-EMT test run points to this new top key.


    How to log data onto disk (into an xtc file)

    What happens to the data when you run a test with the dataflow gui (fcgui) depends on which event level process you are running. If you use eventtest or eventDecoder then the data are not saved. To store the data you need to run OepLoggingApp.
    The syntax is as follows:

    OepRecEventTest -t 90000 -b 1000000 -c 0xffffffff -D $BFROOT/dist/releases/current/bin/SunOS5/Xwrap OepLoggingApp $BFROOT/detector/trg/emt/tcl/oepLoggingData.tcl

    The -c argument is the crate mask in the partition. This must match the crate mask you are using at the event level. Some common choices are:

    0x400        EMT only
    0x7ff          EMT+EMC (i.e. 0x3ff = all crates of the EMC)
    0x17ff        EMT+GLT+EMC (i.e. 0x1000 is the GLT)

    The name and location of the data file are set in the tcl file  $BFROOT/detector/trg/emt/tcl/oepLoggingData.tcl
    This is set up so that the output goes to a file called

    /nfs/babar/calib/emt/babar-emt-data........xtc

    After taking your test run you should rename this file to something more sensible. This disk is shared by all the subsystems, so clean it up regularly, and move any important files somewhere else.

    The logging process uses shared memory, and if your run crashes or you have to abort without exiting cleanly, you may have to clean up the shared memory segments you leave behind. On the machine you ran the event logger, type ipcs. If it reports that
    there are memory segments belong to you, clean them up with ipcCleanup.

    The command OepRecEventTest... is not exactly easy to remember, so some aliases are set up in the file emtSetup. These are

    emtLogger, emtGltLogger, emtEmcLogger, emtEmcGltLogger, testStandLogger


    The teststand


    Using the Teststand

    Use the machine dali.
    This is used by many of the teststands, so please try to minimise the load on it,
    eg by building your code on another machine (eg bbr-farm06)

    Remember to setenv ODF_PLATFORM 6
    Use a cratemask of 0x2.

    To talk to the rom using the xyplex, log onto dali and then telnet roc32 2900

    Note that there is no fire protection system in the dataflow lab.
    It is forbidden to leave the teststand powered up when you are not using it.
    Please turn off the crate when you finish, and take care not to leave it on overnight.


    Running the EMC and EMT teststands together

    You can use a Fast Control Partition Router (FCPR) to make both the EMC and EMT teststands part of the same partition.
    To make them both work as platform 5 (the EMC teststand) do the following:

    • Remove the Fast Control Partition Master (FCPM) from the EMT crate.
    • Change the platform number on the Fast Control Distribution Module (FCDM) in the EMT crate from 6 to 5 (instructions here).
    • Insert an FCPR into slot 17 of the EMC crate.
      • The EMC FCPM talks to the FCPR across the backplane.
      • Connect the FCPR in the EMC crate to the FCDM in the EMC crate using a 9-pin Fast Control cable between the front panels.
        This cable should plug into the top slot on the FCPR.
      • Connect the FCPR in the EMC crate to the FCDM in the EMT crate using a 9-pin Fast Control cable between the front panels.
        This cable should plug into the second from top slot on the FCPR.
        Note that until you do this the EMT crate will not boot, because the system clock comes along this cable.
    • The directory /nfs/bbr-srv02/dataflow/05/17/app should be a link to /nfs/bbr-srv02/dataflow/06/17/app
      This means that the platform 6 detector 17 (emt slot 1) code is also available to platform 5 detector 17,
      i.e. that the same code is available to the EMT ROM whether it is in platform 5 or 6.
    • setenv ODF_PLATFORM 5 before you run the event-level and control-level applications (e.g. OepBasicReceiver + CalControlProgram)
    • You should use a crate mask of 0x3 (0x1 + 0x2) where 0x1 corresponds to the top slot on the FCPR and 0x2 to the next slot down.
      Using 1 or 2 then allows you to run the EMC or EMT test crate alone.

    You should also make sure that the EMC and EMT teststands are running the same version of dataflow, see below.


    How to update the dataflow libraries on the teststand

    It is a good idea to periodically change the dataflow release links for the teststand, so that it is running the same version as in IR2.
    The EMC and EMT teststands should also run identical versions. To change the links on the EMT teststand use the script in L1EmtTools:

    setOdfReleaseTeststand Paa-bb-cc

    where Paa-bb-cc is the version number.


    Looking at data offline


    How to run over an XTC file

    You can read in an xtc file using executables in the L1EmtOep packages. These are based on OepFramework/OepFSimpleShmReaderApp.cc (and have this file included at the end of the relevant AppUserBuild.cc file. Typically such an application uses a 'scanner' to find and extract a particular tagged container (TC) from an event - such a scanner is made by an OepFSimpleModScanMaker, templated against the TC it is looking for. Once the TC is 'in the event' you can then run over it.

    In L1EmtOep the base classes L1EmtTCModule already have methods to extract data from the EMT TCs, and so any new modules can inherit from them. Or you can run the TCtoDigi conversion module L1EmtTCToDigi and then run your analysis module on digis instead of tagged containers.

    How to run an L1EmtOep executable on an xtc file

     eg L1EmtGltCheckApp, which compares the EMT output to the GLT with the input data recorded by the GLT.

    L1EmtGltCheckApp -b 3000000 -n <# of events> -f run1234.xtc L1EmtOep/L1EmtGltCheckApp.tcl

     The -b argument is the buffer size; 3000000 seems to be a good value, but if you have problems (perhaps due to very large events) you can try increasing this. Omit the number of events if you want to run over the whole file.


    How to stage data (xtc files) from tape

    To stage e.g. run 9882, type

    tcstage 0009882-001 &

    The first part of the number is the run number, the second is a block number. It is useful to do this in the background as it otherwise locks the terminal. To find out what blocks are available, first run tcstage with just the run number and it will return a list of available blocks, eg

    tcstage 9882
    0009882-001

    If the above works you will get something like

    Fetching runs-0009500/babar-0009882-001.xtc from HPSS thru tcstage ...
    File /nfs/babar/tcfiles/babar-0009882-001.xtc staged from HPSS

     so your file will be in the directory /nfs/babar/tcfiles.

    Note, xtc files for very recent data can be found in the directory /nfs/bbr-nfs102/pubxtc/theData, which is visible from bbr-farm and bbr-dev machines.


    How to retrieve archived calibration data

    All subsystem directories {dch,dct,drc,emc,emt,glt,ifr,svt} under
    /nfs/babar/calib/ are archived daily onto tape with a seven day latency.
    The files are zip'd and tar'd and staged to tape with a command like

    stageout -V E02001 -q 558 -F F -L 32760 -b 32760 -g 9840  -s 1 -f emt20020318.tgz -K emt20020318.tgz

    where E02001 is the tape number, emt20020318.tgz is the file name for the
    emt data which was archived on March 18, 2002, and 558 is the file
    sequence identifier on that tape.  The same file can be staged to disk
    with the command

    stagein -V E02001 -q 558 -F F -L 32760 -b 32760 -g 9840  -s 1 -f emt20020318.tgz -K emt20020318.tgz
     

    NOTE: YOU NEED TO STAGE THE FILE CORRESPONDING TO SEVEN DAYS AFTER THE DATE YOU WANT, DUE TO THE WEEK-LONG LIFETIME OF THE FILES ON THE DISK

     In order to lookup the tape number and file sequence identifier for a
    given archived filename, you need to search the
    /nfs/babar/calib/OpsDataStage/*.list text files.  The format of these
    files looks like

    SEQ 1 drc20000417.tgz 1
    SEQ 2 drc20000418.tgz 1
    SEQ 3 drc20000419.tgz 1
    SEQ 4 emc20000215.tgz 1531
    SEQ 5 emc20000316.tgz 81

    where the second column is the file sequence id and the fourth column is
    the file size in megabytes.
     

      If you don't know the date of the archived file you want, you can try
    searching the list of filenames that went into the tar'd archive files in
    /nfs/babar/calib/tmp/*.dat.  For example,

    bbr-dev00> cat /nfs/babar/calib/tmp/drc_files19990713.dat
    /nfs/bbr-srv02/calib/drc/conditions/drc/Drc00_00106AB08D6AB995.xtc
    /nfs/bbr-srv02/calib/drc/conditions/drc/Drc00_00106ACAF7EA66B5.xtc
    gives the filenames of what can be found in the drc19990713.tgz archive.


    Diagnostic programs in L1EmtOep

    L1EmtOep contains the code run in Oep, in particular the TC to digi converters which take the online tagged container objects and write digis which can be used in the offline world. There is also a lot of diagnostic code, which is described here.

    This diagnostic code is often run directly on XTC files. This is usually done because the trigger data is only available in the raw level of the database, and so is not usually present. Some modules look directly at TCs, others look for digis, in which case it is necessary to run the TC to digi converter module L1EmtTCToDigi before the analysis module.

    In each case, the key code lives in the module L1EmtXXXModule. There is an AppUserBuild class, usually L1EmtXXXApp.cc, and a tcl file to be used to run the code L1EmtXXXApp.tcl. The following exist:

    L1EmtCalTCRecApp
    Application to study the output of a frameclash test run.

    L1EmtGltCheckApp
    Compares the data the EMT sends to the GLT (ie the L1EmtSlotTC) with what the GLT receives from the EMT and stores in its DAQ data.

    L1EmtTCCheckApp
    A simple program to check that the EMT TCs are produced correctly and without damage.

    L1EmtTestFakeData
    A simple program which makes test TCs, used to test the TCtoDigi and DigiToTG converters.

    L1EmtEmcCorruptionApp
    Runs on data from the special EMC-EMT test runs in which the EMC writes out the tower sums it sends to the EMT. Checks that what the EMT receives is consistent with what the EMC sends.

    L1EmtRingMaskApp
    Studies the effect of masking out the inner rings of the endcap

    L1EmtTestReceiverApp
    A test program used to verify the shipping of data from the ROM to the event level through shared memory

    L1EmtTestXTCMonitorApp
    Runs an early version of the EMT monitoring code. Now outdated - better to use the official trigger montioring code.

    L1EmtTowerCheckApp
    Used to check the output of an EMC serial number run

    L1EmtZeroCrossApp
    Used to study whether the timing offset from the fir zero-cross to the peak is correct.  Stores details of how long a pulse is above threshold, calculates the FIR output etc,  and puts these into an ntuple.


    How to interpret the bitmap daq data

    The emt writes out some limited information about the theta distribution of energy with a phi strip. It was planned that this would be used by L3, but this is not currently done. However, this information is useful for offline studes.

    The following theta bitmap data are available:

    8 discriminator bits. A bit is set if the energy in the corresponding tower exceeds a certain threshold. Note that this threshold, which is set in the Ax configuration data (and may be accessed via L1EmtOnline/L1EmtAx::bitmapThreshold) is completely independent of the M,G,E,X,Y thresholds. (There are 8 bits because the design allows for the presence of an 8th tower in the rear encap, though this is not actually present)

    5 comparator bits. These compare one tower to another. Note that the forward endcap (tower 0) has its energy read out separately, so it is not included in the comparator information. The bits are set as follows:

    bit 0:     if max(theta1,theta2) > max(theta3, theta4)
    bit 1:     if theta1 > theta2
    bit 2:     if theta3 > theta4
    bit 3:     if max(theta5,theta6) > theta7
    bit 4:     if theta5 > theta6

    The theta bitmap data may be accessed in the emt TC or digis via the following methods:

    From the TC:   L1EmtChannelTC::theta(unsigned time)
    This will return a word containing both types of data. Bits 0-7 are the threshold bits, bits 8-12 are the comparator bits.

    From the digi:

    L1EmtPhiDigi::thetaThreshold()
    L1EmtPhiDigi::thetaComparison()


    Some other handy bits and pieces


    Decoding the ODF time

    It can be very useful to decode the ODF time which appears in many places in the online, such as the calibration file names. From any online release, type:

    decodeOdfTime 002423a148807603

    which gives

    Sun Jun 2 17:36:41.254937000 2002 UTC
    Sun Jun 2 10:36:41.254937000 2002 PDT
    (time % 873) = 64 (ticks since last subfiducial) 


    Talking to the Rom using the xyplex connection

    It can be very useful to connect to the rom to see what it is doing. You can look at the output, issue vxworks commands, and call some diagnostic functions in the code.

    To look at the messages output from the rom in IR2

    The output from the rom in IR2 is captured and logged. So if you just want to look and see what the rom is doing, you can look at the end of this log file. The file, visible from any farm, con and srv03 through 06 machine is located at /static/logfiles/Odf/curr/odf-emt-1

    To connect to the rom in IR2 (eg if you want to type in commands)

    1) Log onto a bbr-devnn machine, eg bbr-dev22 (the trigger workstation)
    2) type xyplex -f odf-emt-1

    (odf-emt-1 is our slave rom, on which our code runs. Note that you can also talk to the master rom, using xyplex -f odf-emt-0) Note that xyplex -f takes control of the rom away from the logging process - without the -f the connection will be refused. Make sure your remember to release the xyplex connection when you've finished, so that the logging process can start again. It will restart automatically.

    You are now logged onto the rom... if datataking is going on be careful only to do passive things.

    To log off, type CTRL-] and then quit at the promt.
    If someone else has the xyplex connection then you will not be able to connect. If you need to, and can't find out who has it, then as a last resort you can forcibly take the connection from them by typing xyplex -d odf-emt-1 and then trying again.

    To connect to the rom in the teststand

    1) Log onto dali
    2) type telnet roc32 2900

    You log off in the same way. Make sure you remember to log off, or no-one else can use the xyplex connection (it's not possible to grab the connection in the same way as for the rom in IR2.)

    Some useful things you can type in the xyplex window

    CTRL-x                                                      reboots the rom
    ls, pwd etc                                                 as in unix
    cd "directory name in quotes"
    help                                                               gives you a list of vxworks commands

    There are several other EMT-specific commands which can be run from the xyplex window if the L1EmtDiagnostics library is loaded into the ROM. This is not done by default but must be done by hand before these commands can be used. To load the library, type
    ld 0,0,odfPath("app/libL1EmtDiagnostics.o", odfScratchBuffer)

    The following commands are then available
    AxSprint      to print out the configuration data stored in the ROM memory (the "singleton")
    AxSprint(<TPB[0-9]>,<AX[0-3]>)
    FxSprint
    FxSprint(<TPB[0-9]>)
    FcxSprint
    FcxSprint(<TPB[0-9]>)
    FrontPbSprint
    FrontPbSprint(<TPB[0-9]>)
    OffsetSprint
    OffsetSprint(<TPB[0-9]>)
    BackPbSprint
    BackPbSprint(<TPB[0-9]>)

    VmeCserRead      to read out the control, status and error register through VME of a single TPB
    VmeCserRead(<TPB[0-9]>)
    VmeCserReads to read out the control, status and error register through VME of all TPBs
    VmeSpyRead      to read out the spy through VME for a single TPB
    VmeCserRead(<TPB[0-9]>)
    VmeCserReads to read out the spy through VME of all TPBs


    Setting the platform/crate/sub-detector number using the dip switches on the FCDM

    At present our teststand is platform 6.
    If for example you want to run the EMT teststand in the same platform as the EMC teststand (platform 5)
    you must change the dip switches on the Fast Control Distribution Module (FCDM) in our crate so that the platform is set to 5 rather than 6.
    There are also dip switches to set the sub-detector and crate number (you should not need to change these).
    The layout of the dip switches is shown in the figure below.


    How to ask a UPC for its serial number (without pulling it out)

    To make sure that the results of the serial number check make sense, you sometimes need to be able to check the serial number of a UPC in a particular slot. (Sometimes UPCs get moved around without the records being updated.) Here's what to do

    From a bbr-dev machine, xyplex into the UPC you want to find out about:

            xyplex -f odf-emcX-Y                where X is the crate number starting from 0
                                                                            Y is the UPC number (called slot number in our table) in that crate starting from 1

    There are two ways to go; one is to load Jeff Olsen's test library

            -> ld<junk.o

    and then to get the serial number type

            -> upcrid

    from which you get the following output:

            Data is 0x17015555

        UPC Found
        Location is 0x5555
        Serial Number is 0x17 <<<<--- SERIAL NUMBER

        value = 24 = 0x18

    The other way is to look at the correct memory location directly; the magic address is 0xc5000000 and the value there has the serial number as the lowest 8 bits so type

            -> *0xc5000000 & 0xff

    from which you get the following output:

        value = 23 = 0x17 <<<<--- SERIAL NUMBER

    Whichever way you do this, remember to disconnect the xyplex connection when you have finished:

            -> CTRL-]
            telnet> quit


    How to skim selected events from an xtc file into a new xtc file

    Those clever level 3 guys have written a program to strip events out of xtc files. It is called L3TSkimApp and lives in the package L3Trigger. It is always built in the production area, so you don't even need to build it yourself, instead just make an online test release and set your bin directory to point to the production bin. Do the following:

    newrel -to online_version your_release_name
    addpkg L3Trigger
    rmdir bin
    ln -s /nfs/bbr-srv02/bfdist/Production/Level3/bin bin
    ir2boot

    edit L3Trigger/L3TSkimApp.tcl to control what to skim out

    If you want to select L1 passthroughs, you can do this by uncommenting (or adding)

    module talk TrgOepOutputLineFilter
     linesOn set L3OutL1Open
    exit

    You might also be interested in linesOn set L3OutCosmic

    You can do the same thing to select particular level 1 trigger lines, by talking to the module TrgFctLineFilter, eg

    module talk TrgFctLineFilter
      linesOn set 2E
      linesOn set D2*+
    exit

    This might be useful for example to get a sample of events triggered by the DCT to use for unbiased EMT efficiency studies.

    The names of the lines are exactly the strings you see in the trigger configuration, which you can obtain with getTrgConfig (see here)

    Then to run the job, type

    bin/SunOS5-Objy5.2-Optimize/L3TSkimApp -b 3000000 -f <parentXtcFile> L3Trigger/L3TSkimApp.tcl

    The job will create a (potentially large) number of xtc files. Most of these are very small, but one will be much larger than the others. This is the one you want, you can delete the rest.

    It is also possible to skim out particular individual events, by making a file containing a list of their timestamps and then doing

    setenv TIMESTAMPFILE your_filename

    to tell the L3TSkimApp to use this file.


    How to find out what trigger configuration was used for a particular run

    Look up the run in the online logbook and note what configuration key was used to take the data. This will be written as a hex number, so if you don't convert it to decimal then remember to type 0x first eg 0xabc or whatever. Then in an online release do ir2boot and then type

    getTrgConfig <config_key>

    You will get a printout of the configuration used for that run. To find out which L3 line corresponds to which bit in the trigger word, look at the ordering in the OepInputLines list.


    How to run the L3 event display on the trickle stream

    In the control room, the L3 event display runs on a trickle stream, to delay events as they come in from the detector. You can run this display from the comfort of your own office, which might be useful. for example to check that all is well after you have fixed a hot tower.

    cd to the production area

    cd /nfs/bbr-srv02/bfdist/Production

    and type

    runL3TDisplay -p 10070 to look at the output of L1
    runL3TDisplay -p 10071 to look at the output of L3

    Take care to run on your own machine (eg bbr-farm06) so that you don't block resources down in IR2.


    Some useful scripts

    In ~mcfall/bin you can find the scripts hexto, decto and binto... these convert hex, decimal or binary numbers respectively into the other formats. They take the number as a command line argument or ask you for it if you don't give an argument.

    Steve McMahon wrote a perl script to parse a .mask file and list the masked out channels. Type ~mcfall/bin/masked runXXXX.mask.

    Ivo Eschrich has written some scripts to interpret EMC numbers and to convert between the EMC and EMT numbering schemes. These live in $BFROOT/detector/emc/bin. In particular $BFROOT/detector/emc/bin/emt2emc tells you what EMC electronics supplies the data for a particular tower.


    Level 3 monitoring histograms

    In /nfs/bbr-srv02/u4/FastMon/Outputs/IR2LiveL3 you can find the hbook files of the level 3 monitoring histograms. These contain a histogram of the EMC crystal occupancy at the input to L3, ie the output from L1. So from this you can see if a crystal we think is hot also appears hot to L3. Just choose a recent file and open it up in paw.

    One of the most useful histograms is called 'L3EMonitor crystal Occupancy'. Note that you can rotate your view of a lego plot using lego <histoID> <theta><phi> eg

    paw> lego 3010 50 130


    CVS hints: how to commit code, make a tag, etc

    This is just a very brief introduction to the commonest commands. A fuller list can be found here.

    To checkout a package you do

    cvs co <packagename>

    To checkout a particular tag of a package you do

    cvs co <packagename> <tag>

    eg

    cvs co L1EmtOnline V01-02-03

    or

    cvs co L1EmtOnline HEAD

    To commit a change to the repository, you must take care not to undo or overwrite any changes to that code made by anyone else. Also you should be aware that if you have a particular tag and commit a change, that change will not go into the head of the release. First check to see the changes since you checked out your version

    cvs -n update -A <packagename>

    Any code which is newer than what you have will be updated (U). Any code which you have modified will be labelled as (M). If the code you have modified has also changed in the repository in the meantime cvs will tell you (C). Make a note of the files marked C as you will need to check them after the merge.

    Before commiting any code, you must ALWAYS update to the HEAD by doing

    cvs update -A <packagename>

    This will try to merge any changes. If this happens you should always check the code is okay before you commit the new version.

    To keep a record of changes, before you commit any code, it is useful to edit the History file by simply adding a carriage return or similar. Unfortunately, touch History is not sufficient. Editing this file means the comments entered during the commit are saved in the History file.

    To actually commit code, do

    cvs commit <packagename>

    from the directory containing the package or, for specific file(s),

    cvs commit <filename1> <filename1> ...

    from within the directory where the file(s) live. You will be asked to make a note about the change.

    Once you are happy with the code in a package you may tag it. This makes a frozen copy of the code in the release at the time.  First, find out the previous tag value by using

    head $CVSROOT/<packagename>/History,v

    or any other filename in the package. You will see a list of tags which look something like

    V00-01-18

    Tag the package using

    cvs tag <version> <packagename>

    e.g.

    cvs tag V01-02-03 L1EmtOnline