Testbeam Extensions to SCTDAQ

Gareth Moorhead


Contents

Introduction

This page briefly describes the SCT testbeam DAQ software and hardware environment that runs as an extension of and companion to the standard SCTDAQ module testing package. This includes support for several additional VME modules to the Mustard, Slog and other standard SCTDAQ modules, as well as the beamtest specific software.


User Online Instructions

The run control environment is provided by the interactive user interface to a ROOT session. The main operations are all implemented as ROOT macros, at present executed from the command line. A graphical interface may be provided in the future.

Before starting a session, execute "RESMAN", the VME interface resource manager. Yo ushould do this anyway even if it doesn't appear to be necessary since the testbeam uses more than VME crate. To start a session, first start ROOT, eg, from a desktop icon. On the testbeam DAQ PC (pcatsct01) there is a ROOT icon labelled "TB" which starts the system. Otherwise, start ROOT, then start the sctdaq system: 


.X ST.cpp     [Loads and executes the basic SCTDAQ environment
               Creates the main sctdaq object "e"
               All SCTDAQ public variables and functions are now available,

Answer the "database" question with your 3-letter initials, and accept
with the "1".
 

*** Do an "ExecuteConfigs" from the main SCTDAQ menubar to initialise
  the SCT hardware.  Do "TriggerBurst" to check that all modules are
  responding, and "DCS->Log" to check temperatures and currents.


Do "HVRampUp" even if the HV is already ramped from a previous
session.  THis is give sctdaq the current settings.

.L TB.cpp     [Loads the testbeam macro TB.cpp]

TBStart()     [Initialises the hardware, books histograms etc.,
               and creates the main testbeam object "t"]

*** Do any further configuration here

TBRun()       [Starts a run]


or

TBBiasPoint(150,350)     [Sets detector biases to 150 (unirradiated) 
                          or 350 (irradiated), and does a threshold scan.]

or

TBSetBias(150,350)       [Sets biases)
TBSpecialSelect(10000)   [Restarts an interuppted threshold scan for
                          10000 events per point, prompting the user
                          for the setting to start from.]
Note that TBRun() automatically increments the run number, and prompts the user for some descriptive information. However, TBRun() does not change any conditions; the run conditions must be established by executing explicit commands between runs.

Also note that at present a run cannot be interrupted except by using Control-C to kill the ROOT session. This is harmless, but does mean that the full initialisation must be repeated to re-start data-taking.

All of the SCTDAQ standard variables and functions are available from the usual buttons or by invoking member functions of the object "e". As well, some testbeam variables may be modified between runs by invoking member functions of the object "t" including: 

   t->SetTriggerDelay(int new_delay);
   t->SetEventsRequested(int new_req);
   t->SetScanDescription(int new_typ, float new_val);
In addition to TBRun(), a number of scan macros have been developed which allow scans of multiple runs with programmed changes in scan variables. These include TBScan(type,start,stop,step) which performs a generic scan over any of the available SCTDAQ variable types (eg, 1 for threshold) from the [start] to [stop] in steps of [step]. TBSpecial() is another macro which implements a standard threshold scan with a tailored list of thresholds and numbers of events. These scan macros have significantly improved data taking efficiency since very little time is lost between runs

Monitoring Plots and Information.

Monitoring analysis is performed on all or some events by the DAQ processes. The resulting information is summarised as text in the ROOT main window, and also recorded to a run summary file "tbsummNNN.dat", where NNN is the current run number, located in the data directory (usually D:\sctvar\data).

Histograms are presented in various canvases including:

The efficiency information presented as text and in the summary files is: The bins in the efficiency graph correspond to these numbers.

Configuration

Configuration of SCT modules is done by the standard SCTDAQ functions. Default conditions are established from the standard SCTDAQ configuration files (st_system_config.dat and the detector .det files) when ST.cpp is executed or restarted.

Configuration of the testbeam extensions is done primarily by editing the run macros in the file TB.cpp, or by explicitly executing the member functions such as those listed above.


Software Installation

The online testbeam environment requires first the installation of the basic SCTDAQ, ROOT and NI-VXI software environments as described here . Then, the directories for the extra hardware, the low-level library (tblib) and the ROOT-interface (tbdll) must be copied into a companion directory, usually C:\tbdaq. These include

In addition, the basic run macro TB.cpp is in a directory in the ROOT search path, eg, C:\tbdaq\macros.

Each of the libraries should be built in turn, first the IRAM, V262, V550 and TDC, then tblib, then tbdll. The settings for MS Visual C++ etc. are much the same as for the main SCTDAQ.

Importantly, since installations of ROOT may vary, the source files tbdll\tbdll_cint.cpp and tbdll_cint.h should be regenerated before each new build by executing the batch file maketbdict,bat located in the tbdll directory.

On occasion it may be necessary to re-specify the ROOT static libraries. These should be located in the root/lib directory, e.g., C:\root\lib. First open the tbdll workspace file tbdll\tbdll.dsw in MS Visual C++. In the "FileView", left-click on "Library files". Delete all files with names commencing "Root_". Then right-click on "Library files", and open "Add Files to Folder". In the resulting dialog box, select all the root static library files, e.g., from C:\root\lib (you have to change the file extension type to ".lib"), and restore them to the project workspace file.


Offline Version
The "offline" version of tbdll an be built without requiring the full SCTDAQ installation or any of the hardware or NI-VXI libraries. It requires:

In the source file tbdll\TTB.cpp, undefine the "#define ONLINE" complier directive to prevent calls to stlib or tblib functions so that they are not required for compilation or linking.

To run the online monitor analysis code on events read from a data file, first initialise the system by executing at the ROOT prompt: 

TBStart()
then call 
TBOffline(NNN, num_events)
This will read and analyse [num_events] events from the data file for run NNN, tbrunNNN.dat where NNN is the integer run number, which should be in the default data directory, e.g., D:\sctvar\data.
Testbeam Hardware
The testbeam hardware consists of a scintillator trigger system including photomultiplier power supplies, discriminators and coincidence units, a trigger system which prepares the raw scintillator trigger and gates it with a busy made by combining the logical busies from a number of sources as explained below, a system for providing state monitoring and control between the executing software and the combinatorial logic, a TDC to measure the time delay between raw random triggers and clock-synchronised output triggers, a Telescope system to provide high-resolution tracking with silicon detectors read with Viking analogue electronics, and the standard array of SCTDAQ hardware for power, control and readout of SCT modules.

A number of NIM and VME modules in addition to those standard in the SCTDAQ package have been used in the testbeam version. These include:

A key hardware item for the testbeam version of SCTDAQ is the CLOAC clock and control module which is part of the standard SCTDAQ system. In the testbeam, this module receives the final externally generated trigger signal (which is random relative to the system 40MHz clock), synchronises this to the next clock transition, emits a prompt synchronised trigger (used to start the TDC and to trigger the Viking Telescope readout) and a delayed synchronised trigger, a trigger which has been delayed by the correct integer number of clock cycles such that the correct time-bucket is ready to be read from the SCT front-end electronics pipeline.

Another key set of hardware items is the CAEN V262 I/O unit coupled with a standard NIM dual-timing unit, e.g., a CAEN N93, with its output pulse length set to "Infinite" (i.e., stays active until it receives a Reset pulse). The V262 provides an interface between the software and the "real" world. It has several NIM input levels (used for monitoring various system states), several NIM output levels (used for controlling various system states), and several NIM output pulses ("SHP", shapes).

The controls used in SCTDAQ are:

The main event sequence is for an incoming trigger to cause the Dual Timer to become active, preventing any further triggers and causing a state-change at the V262 NIM IN 1. This is monitored by the executing software, which then performs all the necessary readout functions, filling the event buffers as quickly as possible before completing. As soon as event readout is completed, the software causes a pulse out from V262 NIM SHP OUT 1 which resets the prompt busy, releasing the system for further triggers.

Note that the software is also polling the other inputs and can take appropriate action. The HARDWARE BUSY is a logical OR (made by a NIM logic fan-in) of the hardware busy outputs of all the readout modules. The accelerator SPILL is the state of the beam cycle; it is used as another busy so that triggers are prevented out-of-spill. Once the software has detected the end of a spill, it drains all readout modules of unread events, and then performs all the necessary event formatting, recording of data to disk, monitoring analysis and update of histogram displays. All of this activity is deferred until the spill has ended so as to minimise deadtime during the spill.


Logical Schematic
Not yet available.

VME Addresses

In order to fit the required number of address ranges within the limit of 4 user windows under National Instruments VXI, the CLOAC A24 address range has been expanded to provide a general purpose A24 window for use by the various testbeam modules. CLOAC was chosen as it is most likely to be present but itself uses a small window (0x100 bytes), so the extra space will not interfere with normal non-testbeam SCTDAQ operation.

At present it is assumed that the four windows are mapped for CLOAC (512k A24), SLOG and Mustard (A32), SCTLV (A24, fixed location) and IRAM (A16). BiLED is not yet supported in tblib. The IRAM units require both A16 and A32 space, the A32 space being sited within the generic SLOG A32 window.

Module Name Space Range
CLOAC (A24) A24 0x880000 - 0x8fffff
TDC A24 0x8a0000 - 0x8affff
V262 A24 0x8b0000 - 0x8bffff
SLOG0 (A32) A32 0x1800000 - 0x181ffff
MUSTARD0 A32 0x1900000 - 0x19fffff
IRAM-A32 A32 0x1d00000 - 0x1efffff
IRAM-A16 A16 0x4000 - 0x8fff
SCTLV A24 0xff0000 - 0xffffff

suggestions/corrections