R. Michaels
update Oct 2, 2000
I. Overview
Here are a few notes about the trigger setup for
the Hall A spectometers. The main, so-called S-Ray
trigger (T1 on R-arm and T3 on L-arm) is formed
from a coincidence between two scintilator planes, S1
and S2. In each paddle of each plane, one first requires
that the left and right PMTs fired, then these coincidences
are fed into an MLU which is programmed to determine
if the paddles that fired belong to an allowed set.
Basically, this allowed set corresponds to tracks
which come at a 45 degree angle to the lab floor,
with some angular tolerance (+/- 1 paddle on each
of S1,S2), and allowing any additional hits to
accompany. Details of MLU programming are below.
There are 5 trigger types:
T1 = Right arm S-Ray
T2 = Right arm "junk" (exclusive of T1)
T3 = Left arm S-Ray
T4 = Left arm "junk" (exclusive of T3)
T5 = Coincidence between T1 and T3
The "junk" triggers allow 1 detector to be missing: 1 out
of [S1,S2,Cerenkov] on E-arm, 1 out of [S1,S2] on H-arm.
For e97111, the R-arm is H-arm and the L-arm is E-arm.
T2,T4 allow to measure efficiency, but they are mostly junk
and have to be cleaned up with tracking.
There should be no, or extremely few, "missing gate"
events, which had bothered us in the ancient past and
had made the frontend buffering unusable. Nevertheless
it is VERY IMPORTANT to verify good synchronization of
the DAQ, by checking correlations between various quantities,
like : (i) VDC track versus scintillator hit, (ii) ADC channel
versus TDC channel for scintillators, (iii) Target Y from
R-arm versus Y from L-arm, (iv) Scattering angles
of R-arm versus L-arm.
There is a possible mislabeling of CODA event types
due to timing overlap at trigger supervisor. There was
nothing I could do to avoid this ambiguity because of
tight timing of the delay spools. The consequence is
the eventy type 3 could be 5, etc. But the trigger
pattern is latched each event in a TDC, for e97111
this appears in roc1, slot3, channels 1-12 for triggers
after prescaling and channels 17-29 for triggers before
prescaling. The former 'event type 14' is now programmed
to be event 5 to make old software as happy as possible.
You may also see funny bumps in the ``TC'' spectra
(TC is the ESPACE name for the coincidence time measured
in a TDC 1875 with 0.1 nsec resolution on the R-arm.)
Some of these bumps come from inefficiency and
serve as a measure of the trigger inefficiency.
Some come from pileup effects or ``missing gates''.
I have some notes in my office about this. It is
highly recommended to understand it. However, if
you take T5 and demand a track, the strange
bumps disappear.
part II. Instructions to Download Trigger
On an HP-UX computer like adaqh2, from the ``adaq''
account, type ``trigsetup''.
Answer the obvious questions. There are currently ten
setup files to choose from. To select the one you
want, you have to answer the hadron arm momentum
at the prompt. This assumes the hadron is a PROTON
and the momentum is in GEV. The script will calculate
the delay and tell you which setup file it plans to
use, giving you a chance to reply if it is ok.
If you put in a wrong momentum (i.e. outside the
valid range 0.36 to 4.0 GeV), you get a second
chance -- you can choose from the ten setup files
which are listed by the script. You have to answer
which one you want, then XTrigMang is started and
you have to push the button 'download all'
Downloading takes about 2-3 minutes. At the
end, the XTrigMang window becomes alive, and
you can press the ``quit'' button.
If you get errors about "unable to connect", etc,
you might have to reboot the VME crate(s) which
serve CAMAC. This can be done remotely. In some
cases, you may need to reboot CAMAC, which cannot
be done remotely. When electrical power is lost
in Hall A, it is necessary to reload the trigger.
A typical session with trigsetup:
adaqh2> trigsetup
trigsetup will provide to XTrigMang a trigger settings file
corresponding to the hadron momentum which you enter below
The momentum must be for a PROTON, and must be in GEV.
(If you enter in invalid momentum, you will have a chance
to choose from the list of settings files.)
Enter proton momentum in GeV (between 0.36 and 4.00)
.88
Trigger file to download = proton_875-1170.settings
(Reminder: the file names contain the hadron name and
range of the hadron momentum where the settings will work)
Is this what you want ? (answer 'y' for yes)
y
Starting XTrigMang....
Press the button : download all
It is finished when the screen from which you launched
XTrigMang tells you.
--------------- end of section II ------------------------------
Part III. MLU files
This long, boring section explains the MLU files
and can be safely ignored by most users.
Concepts:
The 1st MLU is programmed the same for
each spectrometer. There are 12 inputs
from 12 scint. Also, on input 15 is the
pulser which is an "x" (don't care).
The Strobe comes from the OR of S2-OR
or S1-OR. The S2-OR signal comes ~15 nsec
before the S1-OR so it normally defines the
timing.
The outputs of MLU1 are
bit 1 and 4 (4 is a copy) "2-2" S-Ray
bit 2 and 5 S1-OR
bit 3 and 6 S2-OR
bit 7 Strobe (from S1 or S2)
The mlu file is mlu1_scint.data
The version which requires pulser on 15,
and doesn't care about the other 12 inputs
is mlu1_pulse.data.
The Strobe output goes to the re-timing
circuit. Bits 1,2,3 outputs go to the
2nd MLU inputs 1,2,3. On the electron
arm, the Cerenkov goes into input 4 of MLU2.
On the hadron arm nothing goes into bit 4.
For both spectrometers, if S-Ray is present
it puts out bit 1 = trigger 1 (called trigger
3 for L-arm). If S-Ray is absent, then
trigger 2 (resp 4 on L-arm) may be formed
as follows. On the which arm has electrons,
2 out of 3 hits are required from S1-OR, S2-OR,
and Cerenkov. This is a majority logic scheme.
On the hadron arm, the junk trigger is the
"OR" of S1,S2.
Triggers 1 and 2 are exclusive. Trigger 2
will not go to the coincidence circuit.
Similarly for triggers 3 and 4.
Typically the T0 (timing offsets) of the triggers
can be quite different, especially comparing the
S-ray to the "junk" triggers.
Technical details of MLU programming follow.
I. Files for 1st MLU: mlu1_scint.data
(version for pulser tests: mlu1_pulse.data)
This is used by both R-arm and L-arm.
The 2_2 S-Ray trigger is generated
with
XYmlu -f mlu_2_2_andbgr_generate.dat
and compressed with
mlu_compress
The result is renamed mlu_2_2.data
Note: S0 does not go into MLU1.
The L,R PMTs go into inputs 4,5 of MLU2.
The s1-or is generated with
XYmlu -f s1or_generate.dat
and s2-or with s2or_generate.dat;
both are compressed with mlu_compress.
The results are renamed mlu_s1or.data
and mlu_s2or.data
The 3 files are merged for bit-wise
or of the outputs. Two files can
be merged at a time using mlu_bitmerge.
mlu_bitmerge mlu_2_2.dat mlu_s1or.data
Call the result of this mlu_temp.dat;
then
mlu_bitmerge mlu_temp.dat mlu_s2or.data
The result is the MLU file for MLU1.
Renamed:
<<< mlu1_scint.data >>>
In the case of mlu1_pulse.data, the above
combinations are allowed, in addition the
pulser on input 15 is allowed to overlap
with the any combination of 12 inputs (else
the probability to overlap would be too small).
We do:
XYmlu -f mlu_2_2_pulse_generate.dat
Let result be mlu.data, then concatenate:
cat mlu.data mlu1_scint.data > mlu1_pulse.data
II. File for 2nd MLU on Electron arm
(For e97111, the Left arm is the Electron)
mlu2_electron.data
Generate with
XYmlu -f mlu2_electron_generate.dat
compress this, call it temp1.dat
Get the luminosity monitor file
XYmlu -f mlu2_lum_generate.dat
compress this, call it temp2.dat
Merge the above two files
mlu_bitmerge temp1.dat temp2.dat
Result:
<<< mlu2_electron.data >>>
III. File for 2nd MLU on hadron arm
is mlu2_hadron.data. The version used at
present does not use S0, instead it does
the "OR" of S1,S2 as prior to Nov 20, 1999.
Generate with
XYmlu -f mlu2_hadron_generate.dat
compress this, call it temp1.dat
Get the luminosity monitor file
XYmlu -f mlu2_lum_generate.dat
compress this, call it temp2.dat
Merge the above two files
mlu_bitmerge temp1.dat temp2.dat
Result:
<<< mlu2_hadron.data >>>
Appendix -- MLU utilities routines on adaq HP machines
Type the name of the utility without arguments and
it will introduce itself, and explain its usage.
XYmlu -- takes a pattern like 10xx01 and
generates all mlu entries. 1=bit must be true;
0=bit must be false; x=bit may be 0 or 1.
There is a Y option, but it is little used
and not too important.
btst -- Examines a pattern of bits
mlu_compress -- Takes an mlu file and
examines all pairs of line-entries. If the
two line entries are identical, one is kept,
the other discarded (this isn't really necessary
but speeds up the download). Also the bit-wise
OR of 2nd components is taken if first components
are identical.
mlu_compare -- Compares two mlu files
to see what is different. If no optional
argument is given, any difference in the
file are noted. If an argument is given
(any number), only the first entry of each
pair are compared.
mlu_bitmerge -- Merges two mlu files. For
each pair of line entries "X1 Y1" from file 1
and "X2 Y2" from file2, if X1=X2, then the
two entries are merged to form bit-wise OR
of Y1,Y2, i.e. we get "X3 Y3" where Y3 = Y1 | Y2.
This page maintained by rom@jlab.org