<BaBar Prototype II Drift Chamber
Software Installation Instructions
Last modified: 12 March 2002, M. Kelsey
The Prototype II drift chamber (Proto
II) is a full-scale mockup of the BaBar Drift Chamber,
covering a narrow angular region (1/8, 45°) of the first four
superlayers. It is installed at SLAC in Central Lab Annex B273.
This document describes the original process of setting up the software,
directories, and database configuration files to operate Proto II using the
standard BaBar
IR-2 operations system. Having completed this process once, these
instructions may be used for reference or as guides to further
modifications.
- Creating the release area
- Configuring your shell
- Modifying the source code
- Building the libraries and executables
- Installing the libraries
- Accessing the database
- Creating configuration keys
- Modifying the channel maps
Commands to be entered at the Unix prompt are shown in typewriter
font below. They should be entered exactly as shown, unless you know
better.
A BaBar test release based on Online Release 6.2.2 (the current version used
for IR-2 operations) $BFROOT/detector/dch/DchProto2/. In this
directory, add the packages of DCH operations scripts,
addpkg DchTestStand
addpkg DchCalScripts
and additional packages as required. See the
current configuration for an up to date list of packages and tags.
Get the other packages needed for building and running executables.
DchTestStand/setup-release.csh
Every time you log on, you must configure your environment for Proto II
operations.
source DchTestStand/setup.csh
Answer the prompt with "p" or "9" to select the Prototype II configuration.
The drift chamber ROM software includes some hardwired parameters to
define which front-end elements are connected to each ROM, and which
quadrant each ROM is reading. This shouldn't be the case (the mapping
object ought to be stored in and retrieved from the configuration database),
but it is.
The function DchT0Config::createBrowser(), in
DchCalOdf/DchT0Config.cc builds the mapping object needed by
DataFlow from hardwired parameters. For Proto II, the section inside the
if-block
if (odfRom::platform()==DchRead::ProtoII) {
cout << " **** Proto II setup *** " << endl;
mapX[0+16*romID] = romID; // Match ROM ID with quadrant
mapX[1+16*romID] = romID; // .. first two FEA-1's
mapX[4+16*romID] = romID;
mapX[5+16*romID] = romID;
} else
[...]
should be modified to reflect the actual cabling selected. The FEE index
numbers (0, 1, 4, and 5 in the code above), must correspond to the "Active
front-end mask" specified in the configuration key,
and to the DIOM connectors
selected for the front-end elements. The romID is set via
DIP switches on the readout
module, and must correspond to the quadrant jumper installed on the
DIOM.
If the code above has been modified, the DataFlow libraries should be
rebuilt.
NOTE: You must be logged on to a machine running Solaris 2.6,
such as falco, tersk-26, or
bbr-dev20old in order to compile and link the source code for
Prototype II. To use versions of the software on Prototype II which
are different from the versions in the base Online Release, the checked out
packages need to be compiled and linked consistently. The script
DchTestStand/build-release.csh |& tee build-release.log
handles this, including checking out appropriate versions of additional
packages needed for consistency.
The pipe (... |& ...) creates a log file for the process, as
well as displaying all the messages on your terminal.
DchTestStand/installDchOdf.csh
If you have a set of locally-built DCH libraries for the ROM, this script
copies them to the ROM download area with a special "tag" suffix to
distinguish different versions.
DchTestStand/linkAllOdf.csh
This script will run three other scripts
DchTestStand/linkDchOdf.csh
DchTestStand/linkCalibOdf.csh
DchTestStand/linkCoreOdf.csh
You have to give the same answers to all of them. You must explicitly
tell the first two that you want to install for Prototype II. When asked
for a "tag", press [Return] the first time to get a list.
There should be a tag "6.2.2" corresponding to the IR-2 production release.
If so, use it. For linkDchOdf.csh, you will generally use the
same tag you assigned initially with installDchOdf.csh above.
If you get "permission denied" or "file already exists" error messages,
this means that your account does not have access to the DataFlow
directories. Contact Michael Kelsey <kelsey@slac.stanford.edu> for
assistance.
More detailed descriptions of these
procedures are also available.
For testing, we will use a private Objectivity Federation, to avoid
disrupting IR-2 detector operations. In the production area
($BFROOT/detector/dch/DchProto2/) the .bbobjy file
has been set up to configure this correctly.
setboot
If you are working in a personal development area, you can either copy
the production .bbobjy file,
cp $BFROOT/detector/dch/DchProto2/.bbobjy .
setboot
or
setenv OO_FD_BOOT /nfs/objyserv7/objy/databases/user2/kelsey/10512/BaBar.BOOT
Add Configuration Keys for Proto II
NOTE: You must be logged on to an IR-2 subnet machine, such as
bbr-dev20 in order to work with the configuration
database. From a workstation console, open a separate terminal
connection
xterm -T "Proto II" -e ssh bbr-dev20
Once the logon is complete, set up your shell environment as above.
Create calibration and data-taking keys for Proto II in the
IR2BOOT database, using the current
IR-2 keys as a starting point.
modifyDchConfig -k 988 # This is the calibration key
modifyDchConfig -k 989 # Calibration with debugging
modifyDchConfig -a PHYSICS # This is the data-taking key
The key number and alias shown are the operational keys as of 19 July 2001.
The current configuration includes an up to
date list of both data-taking and calibration keys for Proto II.
In both cases, you'll get an EMACS window. There are two things to
change in the configuration section at the top of the file (as Erich
explained in his e-mail):
Wafer 4 DCAC mask: Quad 0: 0 Quad 1: 0 Quad 2: 0 Quad 3: 0
^---------^---------^---------^
and
Active front-end elements:
Quad 0: 0000
Quad 1: 0033
(*) ^^^^
Quad 2: 0000
Quad 3: 0000
^^^^---- do this for the other three quadrants
In addition, for the two calibration keys, the input source for
calibration pulses must be changed for all five calibrations. Do a global
search and replace, changing Bussed 2 to Gate 3
everywhere.
(*) NOTE: The active quadrant must match both the "quadrant ID" connector on the
Proto II DIOM (connector J12), and the ROM ID set with DIP switches. Make
sure you specify the active FEEs for the quadrant matching the connector.
If no connector is attached, the DIOM identifies as Quad 3.
The front-end elements specified in the mask must correspond to the FEA connectors used on the DIOM.
Save the temporary file, and answer y to write the "cycle
TC" file to the DataFlow NFS download area and to create a new database key.
It will prompt you for a filename for the new file.
- For the calibration keys, use
CalibrationProtoII.dat and
CalibrationProtoII-debug.dat.
- For the data-taking ("PHYSICS") key, use
DataTaking-ProtoII.dat.
In both cases, provide a short description, basically expanding the file
name into plain English.
Write down the key numbers that the program gives you at the end.
For data-taking, we will need to modify the DchMaps/dch_proto.map file.
addpkg DchMaps
We are running Prototype II with a single ROM and a single DIOM, so the
two FEAs belong to the same "quadrant" in the DCH geometry. As noted in the
configuraiton key section, the quadrant number
specified with a jumper on the DIOM must match the ROM ID set with DIP
switches on the back of the ROM. The FEEs are numbered uniquely from 0 to
63 (0x3f) around the full DCH, with 16 in each quadrant.
Edit the dch_map.awk file, specifically the section
function proto_maps(). At the top of the function, you'll find
five lines
ROMS = 1;
ROM0 = 0;
nWEDGE = 2;
WEDGE0 = 3;
dSECTION = 36; # Proto II generates FEA ID #s at 270 deg.
Make the following changes to convert from IR-2 to Proto II structure:
- Change
ROM0 to the DIOM/ROM quadrant setting.
- Change
dSECTION to 0.
An early design for the DCH tagged container structure allowed the ROM
number (odfdAdr::Module) to be independent of the FEE
(odfdAdr::Section). Now, the high bits of the FEE are used to
determine the Module field of the TC address.
Generate new maps.
gmake DchMaps.maps
|
