User Manual
ver .1 .1
30/10/2002
Input files
Output files
Gui
How
to run
Zero
Suppression
Class
organization
Module Test package is designed to test CMS
inner Tracker Silicon Strip detector modules before mounting them on
substructures like rods (barrel) or petals(endcups).
More
information about CMS Tracker can be found at CMS
Tracker links
Module Test Procedure
The detailed description of the tests
during module construction can be found in
Module Test
Working Group page.
The tests are carried out at
different production centers with two different test
setups:
CMS
tests setup
ARC
system
We expect to have a very close functionality of
these two systems and same data presentations.
Basic functionality tests during silicon module productions can be split into 5 steps:
1. Hybrid test after hybrid assembly and after bonding with pitch adapter at the Hybrid assembly centers.
2. Hybrid +pitch adapter test before assembly with the silicon modules in the Gantry centers and before bonding at the Bonding centers.
3. Functionality test of the complete module after bonding at hte Bonding center
4. Longterm (burning with thermocycling ) test of the module
(or set up to 10 modules) in the longterm test centers before
assembly on substructures.
(This step can be combined with the longterm
test of the substructures.)
5. Functionality test of the substructure at the Substructure assembly centers
The set of parameters which has to be measured is defined
for the reproduction period and will be probably revised.
All
results are stored in the Local Data Base and important part in
the Central
database .
The tested modules are graded according to defined
criteria as A-good, B-OK and C, D-others.
Good modules are
assembled on substructures (petals for endcups), tested
again and then substructures assembled on
final
structures(weels for endcups), tested and delivered to CERN for a
final check of whole system and installation.
Software
Software described here is designed for the CMS test setup.
It based on Linux (kernel version 2.4.9-31.1.cern )
written in C++ and uses Qt
as GUI and ROOT
as analyzing tools.
The configurations and settings are defined
in XML format
and allows to tune system to a particular test setup.The
output data are stored in the Root data file Local data
base. The Local Db information can be thoroughly analyzed
and results are stored in the XML
format recongnisible by the Central Db.
The basic
package can be used for all module tests with up to 10 modules
in setup.
Basic implemented functionality:
-APV readout tests: pedestal
run, calibration and calibration profile runs, pipeline cells
scan,
back plane pulsing run, external light source run, I2C tests
- DCU
Readout of the DCU values
-Sensors
test: IV run, I-t
tests
-Environment control: temperature, humidity,
currents, voltages measurements, Cooling steering
-Procedure:
automatic scenario running
-Output
data: Local Db
Root format and Central Db xml format
Hardware
The CMS test setup is based on PC with at least 3 PCI slots which are occupied by the FED, FEC and TSC boards. In addition or CIO card can be used for reading out environment parameters or TRHX system connected via serial port .
The CMS like test setup consists of three main component:
1. main PC with the APV readout and steering electronics
-FrontEndDriver (8 channels FADC , i.e
up to 16 apv's chips with multiplexer )
-FronEndControlled provides I2C steering via intermediate CCU board
. Six hybrids can be connected to each CCU.
-TriggerSteeringCard TSC
. Multipurpose board provides sequence and triggers for the APV and
FED.
The PC can be a standard Pentium3 ~1GHz with at least 3 PCI slots or PCI extender and at least 256 Mb RAM , serial port and ISA slot for CIO card if used.
2. Test box for one or cooling box for up to 10 modules equipped with the interface UTRI board. For the longterm test the box is produced in Wienn cold box .
3. Cooling system in case of the longterm test, based on Peltier elements and environment control system based on TRHX board or CIO card.
Detailed description of all components can be found in http://hep.uia.ac.be/cms/testing/hardware_links.html and http://beaumont.home.cern.ch/beaumont/setupitems.html
Download
The package is distributed under CVS.
Installation procedure is described in
http://hep.uia.ac.be/cms/testing/software/ltswinstalistalinstr.html
Package Structure
After installation you find few
folders in the Daq directory:
Drivers/
module drivers running
permanently in Linux kernel after initialization
Acquisition/ module
servers providing connections to the module drivers
These two packages are provided by the
basic DAQ
Others are provided by
Antwerp
Directories:
Config/
settings files and scripts to run
ClientTools/
classes using module servers and
configuration xml
ModuleTest/
main GUI, test procedure, data
analysis and presentation
DbLocal/
Local database data structure and
storage methods
DbParser/
Interface to the Central Db
XML format
These packages (except
Config) have fixed internal structure:
Makefile
compiles and makes static library out of the src/ and
include/ and put it in obj/
src/
*.cc *.ui.h *.ui
include/
*.h
obj/
doc/
test/
working area
Makefile compiles, links and makes executable in bin/
out of src/
src/
*.cc
bin/ executables
obj/
data/
data in/out files
In the src file you can also find .cxx files. In the include files you can find *dict.h and *.hpp files. These files are generated files during the make process and are not distributed by the package.
Installation
After download all packages
has to be compiled.
Installation procedure is
described in
http://hep.uia.ac.be/cms/testing/software/ltswinstalistalinstr.html
Here you find some basic information.
To run Makefile the environment
variables and paths should be correctly set as described in the
download
section. An example of
typical env settings is presented below:
PROJECTDIR="/home/cms/xdaq/TriDAS"
PWD="/home/cms/xdaq"
QTDIR="/home/cms/xdaq/qt-x11-free-3.0.5/"
QWTDIR="/home/cms/xdaq/qwt-0.4.1/"
ROOTSYS="/home/cms/xdaq/root"
SCRATCH="/home/cms/xdaq/scratch"
USER="xdaq"
XERCESCROOT="/home/cms/xdaq/xerces-c-src1_6_0"
DAQCMS="/home/cms/xdaq/Daq_Cms_Like/"
DAQHOME="/home/cms/xdaq/Lt"
DIMDIR="/home/cms/xdaq/dim/"
DIM_DNS_NODE="thismachine"
Basic packages such as : Root, Qt , XERCES has to be set
correctly.
To run Makefile type make all in
DbLocal,DbParser,ModuleTest,ClientTools which will create libs in
the obj/
make clean will cleans
the obj/.
You can run all Makefiles from the Config/
.
Note that for the ModuleTest Makefile not only
compiles but also produces some src and include files out of the Qt
designer templates. The produced files have extension *.cxx and
*.hpp.
To produce executables the Makefile in the
/test has to be run. For example make mainMonitor in
the ModuleTest/test
will produce main application
/bin/mainMonitor
To run it just type in bin/ >
./mainMonitor
Configuration
Configuration to the particular setup and test is provided by two
xml files: lt.xml and settings.xml
The xml parser
reads not only XML file but also corresponding *.dtd
file where some default values are defined.
Setup configuration
After download and compilation
the configuration Config/lt.xml file has to be modified.
Detailed information how to configure your setup can be
found in
http://hep.uia.ac.be/cms/testing/software/configfile.html
Here is some basic information.
Each component used in software which
provides or accepts some data is called
device .
Each device is described in xml
format in the field between <X> and </X>
where X can be any device as BenchPositionConnection,
FedConnection , TscCard, TemperatureProbe
etc.
Devices can contain each other:
<X1>
<X2>
....
</X2>
<X1>
Thus
the relations between devices and connectivity are defined.
There are two types of devices
in the configuration xml file
1. Devices related to the test setup :
TscCard, Cold box , TemperatureProbe, HumidityProbe ,InterLock
2. Devices related to the tested object (hybrid, silicon
module)
In case of multimodule setup
each slot is identified by the BenchPositionConnection
Inside there are basic devices
I2cConnection, FedConnection,TemperatureProbeNtc0
,BiasHvConnection,
BiasCurrentConnection etc.
There are usually 3 main attributes for each device
device=".."
is an Id and has different meaning for different
devices. For
example for the BenchPositionConnection
device="0" means that
the field below describes connectivity for an object at the
test setup slot 0.
name="..."
defines a particular device nick name . For ex. for
<ColdBox device="4" name="Antwerpen" >
simulation=".."
simulation tag . Useful thing if only part of hardware is used.
If ="y" a dummy channel is take which provides simulated
data instead connection to the real device servers. There also
a global tag <Simulation simulation="y">
activates all simulation tags.
In addition
to these attributes there are parameters particular to this device,
calibration, addresses etc.
An example lt.xml file is
presented below:
<?xml version="1.0"
encoding="ISO-8859-1" ?>
<!DOCTYPE
Lt SYSTEM "lt.dtd">
<!-- the main tag -->
<Lt
>
<!-- the tag that
indicates if the simulation mode is active-->
<Simulation simulation="n" />
<!-- the tag that indicates that
there is a tsc device -->
<TscCard device="0" name="Tsc"
simulation="n">
<!-- the tag that indicates which io channel is used to control
the back plane pulse control
put simulation to "y" if not used -->
<BackPlanePulseCtrl
simulation="n">
<DioChannel
boardnr="0"
channel="10"
mode = "output"
/>
</BackPlanePulseCtrl>
</TscCard>
<!--
general Setup Section Humidity probes, Temperature probes ,
cold box
in
this simple case only one temperature probe and one humidity probe
no coldbox -->
<SlowCtrlConfig
device ="1">
<!--
temperature probe section in this case with only one probe
the probe is connected to the
temperature channel 4 of the trhx system
and the trhx system is connecte to serial port 1 of the PC -->
<TemperatureProbe
device ="18" name ="ntc2" simulation="n"
>
<TemperatureTrhxNtc
gain="-0.050833"
caltemp ="23.5"
caladcvalue="47536"
>
<SerialChannel
port="1"
address="4"
/>
</TemperatureTrhxNtc>
</TemperatureProbe>
<!-- humidity
probe section in this case with only one probe -->
<!-- the probe
is connected to the humidity channel 1 of the trhx system
and the trhx system is connecte to
serial port 1 of the PC
each humidity channel should have an unique device number -->
<HumidityProbe
device ="11" name="box" simulation="n">
<HumidityTrhx
gain="-0.050833"
calhumidity ="05"
caladcvalue="06"
vrefgain= "0.7975"
>
<SerialChannel
port="1"
address="1"
/>
</HumidityTrhx >
</HumidityProbe>
</SlowCtrlConfig>
<!-- Connection from the Module to the setup -->
<BenchPositionConnection
device ="0">
<-- to which fec , which ccu channel (1-6) and which ccu addres
this module is connected to
-->
<I2cConnection
simulation="n"
fecboard="0"
ccuchannel ="5"
ccuaddress ="36"
/>
<FedConnection
>
<!-- the utri channel 0 ( looking to the analogue output
connectors the most lef one)
is connected to fed channel 0 of the FED with serial channel 16 -->
<UtriChannel
simulation="n"
utrichannel="0"
fedserialnr= "16"
fedchannel="0"
/>
<UtriChannel
simulation= "n"
utrichannel="1"
fedserialnr= "16"
fedchannel="2"
/>
<!-- take care middle VUTRI channel 1 is connected to channel 2
VUTRI channel 2 is connected to fed channel 1 -->
<UtriChannel simulation= "n"
utrichannel="2"
fedserialnr= "16"
fedchannel="1"
/>
</FedConnection>
<!-- the NTC of the kapton cable is connected to the channel 0 of
the power interface and control board -->
<TemperatureProbeNtc0 device ="1000" name
="Module0a" simulation= "n">
<TemperatureNTC gain="120000"
caltemp
="24.5"
caladcvalue="47536"
openadcvalue="0"
>
<AdcAd4717
devicenumber="7"
devicechannel ="7"
i2caddress="0"
channel="1"
/>
</TemperatureNTC>
<!-- the dual NTC of the
kapton cable is connected to the channel 2 of the power interface and
control board -->
</TemperatureProbeNtc0 >
<TemperatureProbeNtc1 device ="1001" name
="Module0b" simulation= "n" >
<TemperatureNTC
gain="120000"
caltemp ="23.5"
caladcvalue="4928"
openadcvalue="131070"
beta= "3380"
>
<AdcAd4717
devicenumber="7"
devicechannel ="7"
i2caddress="0"
channel="2"
/>
</TemperatureNTC>
</TemperatureProbeNtc1 >
<!-- the module
is connected to channel 1 of the Struck HV power supply
that is controlled by the serial port 0 of the computer -->
<BiasHvConnection
device= "1000" simulation= "n" >
<HvStruck gain="1"
calvoltage="0"
calvoltagesetting ="0"
zerovoltage = "0"
>
<SerialChannel
port="0"
address="1"
/>
</HvStruck>
</BiasHvConnection>
<!-- the HV bias current is measured by a electormeter of which
the measuring output is connected
to ADC channel 10 of the CIO board -->
<BiasCurrentConnection device= "1000"
simulation="n" >
<BiasCurrentAdcChannel>
<ElectroMeter
ElectroMeterType = "lyon"
ElectroMeterRange = "100uA"
ElectroMeterChannel= "0"
ElectroMeterOutputRange= "10"
/>
<CalValues
gain="10"
caladcvalue="25072"
calcurrent = "1"
/>
<AdcChannel
boardnr="0"
channel="10"
/>
</BiasCurrentAdcChannel>
</BiasCurrentConnection>
<!-- the current
probe of the 1.25V line is conneted to channel 3 of the power control
and interface board-->
<Current_1.25 device = "1001"
name="Lv1.25cur_mod0" simulation="n" >
<CurrentAdc>
<CalValues
gain="1"
caladcvalue="1"
calcurrent = "1"
/>
<AdcAd4717
devicenumber="7"
subdevicenumber="0"
devicetype ="tsci2c"
devicechannel ="7"
i2caddress="0"
channel="3"
/>
</CurrentAdc>
</Current_1.25>
<!-- the current probe of the 2.50V line is conneted to channel 0
of the power control and interface board-->
<Current_2.50 device = "1002"
name="Lv2.5cur_mod0" simulation="n" >
<CurrentAdc>
<CalValues
gain="1"
caladcvalue="1"
calcurrent = "1" />
<AdcAd4717
devicenumber="7"
devicechannel ="7"
i2caddress="0"
channel="0"
/>
</CurrentAdc>
</Current_2.50>
</BenchPositionConnection>
</Lt>
Test
configuration
The settings.xml together with settings.dtd
files consists of many descriptors.
I2CDescriptor
apv,pll,mux i2c settings for
different operation modes
CalProfRunDescriptor
parameters of the run (latency
range, number of events etc)
CalRunDescriptor
parameters of the run
BPlaneRunDescriptor
parameters of the run
LedRunDescriptor
parameters of the run
PedRunDescriptor
parameters of the run , zero
suppression algorithms
SensorDescriptor
maximum current, voltages, IV run
etc
DaqCtrlDescriptor
for settings
of the daq control signals
SetupDescriptor
ProcedureDescriptor
default file names for scenario and
output files
Each descriptor can have many entries distinguished by the name.
There a few entries for the I2CDescriptor
for different APV operation mode:
i2csettings
Apvmode
i2cpedpeak
15
i2cpedpeakinv
47
i2cpeddec
5
i2cpeddecinv
37
i2ccalpeak
11
i2ccalpeakinv
43
i2ccaldec
1
i2ccaldecinv
33
i2cinit
15
Most other descriptors have only one default.
The descriptors where the timing is
important like the CalRunDescriptor have also beside the default
descriptor ( when the apv mode is pedestal) a descriptor for the
convolution mode.
The Run descriptors have an additional
descriptor for a long term run.
The SensorDescriptor ( the default values are the values as defined in the setttings.dtd file. These can be changed in the settings.xml file so check this file )
name Required the name of the descriptor. Only the name default is recognized by the mainMonitor program.
vmax Default=500 The maximal voltage that can be set.
hvrumpup Default =10 V/s rampup voltage
hvrumpdwn Default =100 V/s rampdown voltage
imax Default =1000 nA maximal current. This value is used during the IV run. If the current comes above this value the IV run will be stopped.
vstartiv Default=0 V the start value for the IV run
vendiv Default=60 V the last value for the IV run
npointsiv Default=10 the number of points for the IV run.
dtvset Default=1 s time in [s] between to checks if the voltage is reached.
dtiv Default = 2 s time in [s] between two different settings in the IV run
dimax not in use.
npointsi number of times the voltage or current is asked and averaged.
dv default = 1 V . The tolerance that is accepted when setting the voltage
vtest1 CDATA "300" documentation pending
vtest2 CDATA "500" documentation pending
Present manual is mostly devoted to the high level
application located in the ModuleTest, DbLocal and
DbParser packages. The ClientTools descritpion can be found
elsewhere.
Here we discuss formats of input and output files,
how to run system and efficiently use its functionality, how to
analyze information and store it in the Db.
Input
files
There are few input
files are required to run programm:
Acquisition/bin/daq.xml
defines addresses, FED operation mode
and thresholds. Default it operates in the header finding mode. This
file is used in the startDAQ script to run
servers.
Config/lt.xml (lt.dtd)
defines all hardware configuration and connectivity. The file is
parsed by pressing InitSetup
button from Gui menu after starting up main program. This file
has to be modified according to a particular setup. From cvs a
simple example is available.
Config/settings.xml (settings.dtd)
defines all test conditions and analyzing
algorithms. mainMonitor
ModuleTest/test/bin/runN
If
it does not exist it is created automaticaly.
It
stores latest run number. The runN is increamented
by one after each new InitSetup action . This run N is used
further in the Db. You can modify this number if needed.
Scenario file
Test
procedure can be atomized by using scenario file where sequence of
all test in time is defined.
That is
an ASCII file in the format:
time
in sec(int) action
(char) actionparameter
(char)
time
defines time of the action. I
-If
time positive it
defines the absolute time when the next action should start. If
previous is not finished
the action
is skipped. Therefore before writing a scenario user should measure
typical time for each test (from logfile).
-If
time is negative it defines ithe time between the tests. In
this case the next action starts after the time indicated in front of
the next test.
Don't use negative and positive times in the same
scenario file.
The
action is a particular test.
The action may have a string parameter.
List of the available test actions and
theirs parameters are shown below
Action
Parameter
Start
tproceduredescriptor
PedRun i2csettings
CalRun
i2csettings
CalProfRun i2csettings
LatRun
i2csettings
BPlaneRun
i2csettings
LedRun
i2csettings
IVRun
i2csettings
ChangeCool Temp
[C ]
TempReached dummy
CheckEnv
dummy
ChangeHV HV
[ V ]
SaveRec
Flag(0 -default, or 1,2,3 used as a
tag for the Db)
SaveFile
filename (without extension)
SaveXml
populate current data into XML template defined in the settings
file(*)
ResetRec
dummy
Stop
0 (none)
*) SaveXml takes the latest root file used to save data,
extract information for xml file and produces N(number of modules)
xml files with extension
ModId_tempatename.xml
The Stop always stores current results in the
default results file defined in the settings.xml
You can
add your own i2csettings to the settings.xml file
and use it in you scenario file.
Make sure the i2csettings
defined in the parameters are present in the settings.xml file .
The
tag of the procedure descriptor. Make sure the descriptor is defined
in the settings.xml.
The TempReached action check if the
temperature given in the last ChangeCool is reached. If this is not
the scenario goes back to the action after the last ChangeCool
action. In this way a loop can be constructed during the time needed
to reach the temperature. The TempReached works only in the negative
time mode!
The CheckEnv force a readout of the environment
sensors. During the scenario the environment sensors are checked each
time interval as defined in the ProcedureDescriptor
(dtslowctrl).
ResetRec clear all the measurement results.
Finally
a typical Scenario file can look like:
1
Start
0
2
ChangeCool -20
5
ChangeHV 100
50
PedRun
i2cpedpeak
90
SaveRec
0
100
BPlaneRun i2cpedpeak
120
CalProfRun i2ccalpeakinv
160
SaveRec
1
165
SaveFile
myfile
170
ChangeHV 0
180
ChangeCool +20
220
Stop
0
The path to the default
scenario file is defined in the settings.xml. The scenario also can
be loaded from the Control menu of the mainMonitor application.
Instead of an absolute time it is also possible to use a relative time. This is indicated by putting a – sign before the time. For the moment it is not allowed to mix absolute time and relative time. In the example below after the action there is some comment added (behind the // characters) but in a scenario file there can NO comments be added. Normally also no blank lines are allowed.
1 Start longterm // start the scenario and use the longterm procedure descriptor
// the start always needs a positive time number
-20 ChangeHV 10 // wait 20 seconds and
set the hv to 10 V
-40 ChangeCool 20 // wait 40 seconds and give
the instruction to control the temperature
// to 20 ºC
-1 PedRun i2cpeak
// after 1 seconds start a ped run and use the i2c descriptor with
// tag i2cpeak
-2 BPlaneRun i2cpeak
-1 PedRun
i2cpeak
-2 LatRun i2cpeak
-2 CalRun i2cpeak
-2 IVRun i2cpeak // the i2c setting tag should be valid.
// for the moment the acquisition loop
has to be active
// during the IV loop
-2 CalProfRun i2cpeak
-1 SaveRec 0 // save the previous test results in the default root file.
-30 ChangeCool 1 // set the temperature to 1 ºC
-600 PedRun i2cpeak
-2 CalRun i2cpeak
-10 TempReached dummy // if the temperature of 1 ºC is reached go on with the next action.
// if the temperature is not reached do the action
// after the last ChangeCool (-600 PedRun i2cpeak )
-200 BPlaneRun i2cpeakinv
-100 PedRun i2cpeakinv
-200 LatRun i2cpeakinv
-200 CalRun i2cpeakinv
-200 IVRun i2cpeakinv
-200 CalProfRun i2cpeakinv
-1 SaveRec 1 // save the results in a new record and tag this record to be
// saved to the xml file
-30 ChangeCool -5
-10000 PedRun i2cpeak // don't wait until the temperature is reached. But
// assume 10000 seconds is enough to reach -5 ºC
-200 BPlaneRun i2cpeak
-100 PedRun i2cpeak
-200 LatRun i2cpeak
-200 CalRun i2cpeak
-200 IVRun i2cpeak
-200 CalProfRun i2cpeak
-1 SaveRec 3
-2 SaveFile qualifylong
-1 ChangeHV 0
-1 Stop 0
Output
files
All information obtained during tests is
stored into the Root file as a Root objects.
Each
module(hybrid) under test has its own root file with
modId in the name filename_M_modId.root
These files
can be reanalyzed and selected results can be stored in the XML
format of the Central Db.
This step can be done ofline, i.e
after all tests are accomplished, using standalone root
interactive session.
Or online, i.e. during test. In this
case predefined records will be parsed into XML files readable
by Central Db.
Output Root file
The
Root file is used as a local database storage. All data are stored in
the files directories tree.
Record#
#-record number
increamented with each SaveRec, SaveFile action
Header
Setup
Module
Many records can be stored in one file. All data inside are
presented as a Root objects
TH1F, TProfile, TNamed(for
character), TVector(for integer and float) and can be drawn or
inspected
from Root session.
Below islisting of all objecvts
stored in the root file.
TFile*
test_M_1.root CMS Si Module Test UIA
TDirectory*
Record0 Record0
TDirectory*
Header Header
KEY: TVector TVrun;1 Vector
class
KEY:
TVector TVev;1 Vector
class
KEY:
TVector TVmod;1 Vector
class
KEY:
TVector TVtime;1
Vector class
KEY:
TVector TVapvmode;1
Vector class
KEY:
TNamed TNsettings;1
KEY: TNamed TNstime;1
TDirectory*
Setup Setup
KEY: TVector
TVtemptag;1 Vector class
KEY: TVector
TVtempcold;1 Vector class
KEY: TVector
TVtempbox;1 Vector class
KEY: TVector
TVtempwarm;1 Vector class
KEY: TVector
TVtempext;1 Vector class
KEY: TVector
TVhumext;1 Vector class
KEY: TVector
TVhumbox;1 Vector class
KEY: TVector
TVtemps;1 Vector class
KEY: TVector
TVhums;1 Vector class
KEY: TGraph TGtemptag(t);1
TGtemptag(t)
KEY:
TGraph TGtempcold(t);1 TGtempcold(t)
KEY: TGraph TGtempwarm(t);1 TGtempwarm(t)
KEY: TGraph TGtempbox(t);1 TGtempbox(t)
KEY: TGraph TGtempext(t);1 TGtempext(t)
KEY: TGraph TGhumbox(t);1 TGhumbox(t)
KEY: TGraph TGhumext(t);1 TGhumext(t)
TDirectory*
Module Module
KEY: TVector
TVmodid;1 Vector class
KEY: TVector
TVnapvs;1 Vector class
KEY: TVector
TVnbench;1 Vector class
KEY: TVector
TVnapverrors;1 Vector class
KEY: TVector
TVtemphybdcu1;1 Vector class
KEY: TVector
TVtemphybdcu2;1 Vector class
KEY: TVector
TVtempsenntsc1;1 Vector
class
KEY:
TVector
TVtempsenntsc2;1 Vector
class
KEY:
TVector TVhvbias;1
Vector class
KEY:
TVector TVtileakdcu;1
Vector class
KEY:
TVector TVitest;1
Vector class
KEY:
TVector TVihyb25;1
Vector class
KEY:
TVector TVihyb125;1
Vector class
KEY:
TVector TVvhyb25;1
Vector class
KEY:
TVector TVvhyb125;1
Vector class
KEY:
TVector TVivv;1 Vector
class
KEY:
TVector TVivi;1 Vector
class
KEY:
TVector TVtimet;1
Vector class
KEY:
TVector TVit;1 Vector
class
KEY: TGraph
TGavrmst;1 TGavrmst
KEY: TGraph TGavcalat;1 TGavcalat
KEY: TGraph TGhbadcht;1
TGnbadcht
KEY:
TGraph TGtemphybdcu1t;1
TGtemphybdcu1t
KEY:
TGraph TGtemphybdcu2t;1
TGtemphybdcu2t
KEY:
TGraph TGtemphybdcu3t;1
TGtemphybdcu3t
KEY:
TGraph TGihyb125t;1 TGihyb125t
KEY: TGraph TGihyb25t;1 TGihyb25t
KEY: TGraph TGvt;1 TGvt
KEY: TGraph TGit;1 TGit
KEY: TGraph TGtempsen1t;1
TGtempsen1t
KEY:
TGraph TGtempsen2t;1 TGtempsen2t
KEY: TGraph TGiv;1 TGiv
KEY: TH1F THpedestal;1 pedestal
KEY: TH1F
THnoise;1 noise
KEY: TH1F THrawnoise;1 rawnoise
KEY: TH1F
THchflag;1 badChflag
KEY: TH1F THcala;1
calA
KEY: TH1F
THcalPApeak;1 calPApeak
KEY: TH1F THcalSbackpl;1 calSbackpl
KEY: TH1F THcalSled;1 calSled
KEY: TProfile
TPbp;1 calbp
KEY: TProfile TPled;1 called
KEY: TDirectory
cmn;1 cmn
KEY: TDirectory pipe;1 pipe
KEY: TDirectory
calprof;1 calprof
KEY: TDirectory latency;1
latency
Directories cmn, pipe contains histogramms related to each apv(up
to 6). Directories calprof, latency contains
histograms for each
channels (up to 768)
XML Db file
Central
Database requires data in XML format. The
results of each test has to be loaded into the Db
in special
format defined by the test. The format can be obtained from a
template which has to be populated
with results as described at
http://hep.uia.ac.be/cms/testing/software/database.html
There are a few defined:
for module test
MODVALIDATION - modvalidation.xml
MODLT
-modlt.xml
for hybrid test
HYBPAVALIDATION -hybpavalidation.xml
HYBVALIDATION
-hybvalidation.xml
An example of the MODVALIDATION.xml - main module
qualification test is below:
<?xml
version="1.0" encoding="UTF-8"?>
<DBFile
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="TrackerDB.xsd">
<unit>
<object id=""/>
<composite>
<!-- Module
Qualification test after bonding
Note
that not all elements can be filled
-->
<action_description input_id="542" name="MODVALIDATION"
object_name="MOD" version="1"/>
<action>
<action_description input_id="538" name="MODULBASIC"
object_name="MOD" version="1"/>
<result name="MODULBASIC_val" value=":0:" />
<result name="Tdate" value="" />
<result name="operator" value="ivanov" />
<result name="tool_id" value="1" />
<result name="status" value="0" />
<result name="ModuleType" value="0" />
<result name="ModuleGrade" value="0" />
<result name="NBadChan" value="" />
<result name="Settings" value="" />
<result name="TempSetup" value="" />
<result name="TempExt" value="" />
<result name="HumSetup" value="" />
<result name="HumExt" value="" />
<result name="TempHybDcu" value="" />
<result name="TempHybNtsc" value="" />
<result name="TempSenNtsc1" value="" />
<result name="TempSenNtsc2" value="" />
<result name="TempSenNtsc1Dcu" value="" />
<result name="Ihyb25" value="" />
<result name="Ihyb125" value="" />
<result name="Vhyb25" value="" />
<result name="Vhyb125" value="" />
<result name="HVbias" value="" />
<result name="IleakDcu" value="" />
<result name="Itest" value="" />
</action>
<action>
<action_description input_id="536" name="MAPVBASIC"
object_name="MOD" version="1"/>
<result name="MAPVBASIC_val" value=":0:" />
<result name="Tdate" value="" />
<result name="operator" value="0" />
<result name="tool_id" value="1" />
<result name="status" value="0" />
<result name="apvMode" value="" />
<result name="pedestal" value="" />
<result name="noise" value="" />
<result name="rawnoise" value="" />
<result name="calA" value="" />
<result name="chflag" value="" />
</action>
<action>
<action_description input_id="532" name="MAPVDEEP"
object_name="MOD" version="1"/>
<result name="MAPVDEEP_val" value=":0:" />
<result name="Tdate" value="" />
<result name="operator" value="0" />
<result name="tool_id" value="1" />
<result name="status" value="0" />
<result name="apvMode" value="" />
<result name="calPApeak" value="" />
<result name="calSbackplane" value="" />
<result name="calSled" value="" />
<result name="chflag" value="" />
</action>
<action>
<action_description input_id="540" name="SENSORBASIC"
object_name="MOD" version="1"/>
<result name="SENSORBASIC_val" value=":0:" />
<result name="Tdate" value="" />
<result name="operator" value="0" />
<result name="tool_id" value="1" />
<result name="status" value="0" />
<result name="voltageIV" value="" />
<result name="currentIV" value="" />
<result name="timeIt" value="" />
<result name="currentIt" value="" />
</action>
</composite>
</unit>
</DBFile>
More complicated MODLT.xml template is below
<?xml
version="1.0" encoding="UTF-8"?>
<unit
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="calibration.xsd">
<object id=""/>
<composite>
<action_description input_id="550"
name="MODLT" version="1" object_name="MOD"
/>
<composite>
<action_description input_id="544" name="MODLTFIRST"
object_name="MOD" version="1"/>
<action>
<action_description input_id="538" name="MODULBASIC"
object_name="MOD" version="1"/>
<result name="MODULBASIC_val" value=":0:" />
<result name="Tdate" value="" />
<result name="operator" value="0" />
<result name="tool_id" value="1" />
<result name="status" value="0" />
<result name="ModuleType" value="0" />
<result name="ModuleGrade" value="0" />
<result name="NBadChan" value="" />
<result name="Settings" value="" />
<result name="TempSetup" value="" />
<result name="TempExt" value="" />
<result name="HumSetup" value="" />
<result name="HumExt" value="" />
<result name="TempHybDcu" value="" />
<result name="TempHybNtsc" value="" />
<result name="TempSenNtsc1" value="" />
<result name="TempSenNtsc2" value="" />
<result name="TempSenNtsc1Dcu" value="" />
<result name="Ihyb25" value="" />
<result name="Ihyb125" value="" />
<result name="Vhyb25" value="" />
<result name="Vhyb125" value="" />
<result name="Iapv25" value="" />
<result name="Iapv125" value="" />
<result name="HVbias" value="" />
<result name="IleakDcu" value="" />
<result name="Itest" value="" />
</action>
<action>
<action_description input_id="534" name="MAPVLT"
object_name="MOD" version="1"/>
<result name="MAPVLT_val" value=":0:" />
<result name="Tdate" value="" />
<result name="operator" value="0" />
<result name="tool_id" value="1" />
<result name="status" value="0" />
<result name="apvMode" value="" />
<result name="pedestal" value="" />
<result name="noise" value="" />
<result name="rawnoise" value="" />
<result name="calPApeak" value="" />
<result name="calSbackplane" value="" />
<result name="chflag" value="" />
</action>
<action>
<action_description input_id="540" name="SENSORBASIC"
object_name="MOD" version="1"/>
<result name="SENSORBASIC_val" value=":0:" />
<result name="Tdate" value="" />
<result name="operator" value="0" />
<result name="tool_id" value="1" />
<result name="status" value="0" />
<result name="voltageIV" value="" />
<result name="currentIV" value="" />
<result name="timeIt" value="" />
<result name="currentIt" value="" />
</action>
</composite>
<composite>
<action_description input_id="546" name="MODLTCOLD"
object_name="MOD" version="1"/>
<action>
<action_description input_id="538" name="MODULEBASIC"
object_name="MOD" version="1"/>
<result name="MODULBASIC_val" value=":0:" />
<result name="Tdate" value="" />
<result name="operator" value="" />
<result name="tool_id" value="1" />
<result name="status" value="" />
<result name="ModuleType" value="" />
<result name="ModuleGrade" value="" />
<result name="NBadChan" value="" />
<result name="Settings" value="" />
<result name="TempSetup" value="" />
<result name="TempExt" value="" />
<result name="HumSetup" value="" />
<result name="HumExt" value="" />
<result name="TempHybDcu" value="" />
<result name="TempHybNtsc" value="" />
<result name="TempSenNtsc1" value="" />
<result name="TempSenNtsc2" value="" />
<result name="TempSenNtsc1Dcu" value="" />
<result name="Ihyb25" value="" />
<result name="Ihyb125" value="" />
<result name="Vhyb25" value="" />
<result name="Vhyb125" value="" />
<result name="Iapv25" value="" />
<result name="Iapv125" value="" />
<result name="HVbias" value="" />
<result name="IleakDcu" value="" />
<result name="Itest" value="" />
</action>
<action>
<action_description input_id="534" name="MAPVLT"
object_name="MOD" version="1"/>
<result name="MAPVLT_val" value=":0:" />
<result name="Tdate" value="" />
<result name="operator" value="0" />
<result name="tool_id" value="1" />
<result name="status" value="0" />
<result name="apvMode" value="" />
<result name="pedestal" value="" />
<result name="noise" value="" />
<result name="rawnoise" value="" />
<result name="calPApeak" value="" />
<result name="calSbackplane" value="" />
<result name="chflag" value="" />
</action>
<action>
<action_description input_id="540" name="SENSORBASIC"
object_name="MOD" version="1"/>
<result name="SENSORBASIC_val" value=":0:" />
<result name="Tdate" value="" />
<result name="operator" value="0" />
<result name="tool_id" value="1" />
<result name="status" value="0" />
<result name="Settings" value="" />
<result name="voltageIV" value="" />
<result name="currentIV" value="" />
<result name="timeIt" value="" />
<result name="currentIt" value="" />
</action>
</composite>
<composite>
<action_description input_id="548" name="MODLTLAST"
object_name="MOD" version="1"/>
<action>
<action_description input_id="538" name="MODULEBASIC"
object_name="MOD" version="1"/>
<result name="MODULBASIC_val" value=":0:" />
<result name="Tdate" value="" />
<result name="operator" value="0" />
<result name="tool_id" value="1" />
<result name="status" value="0" />
<result name="ModuleType" value="0" />
<result name="ModuleGrade" value="0" />
<result name="NBadChan" value="" />
<result name="Settings" value="" />
<result name="TempSetup" value="" />
<result name="TempExt" value="" />
<result name="HumSetup" value="" />
<result name="HumExt" value="" />
<result name="TempHybDcu" value="" />
<result name="TempHybNtsc" value="" />
<result name="TempSenNtsc1" value="" />
<result name="TempSenNtsc2" value="" />
<result name="TempSenNtsc1Dcu" value="" />
<result name="Ihyb25" value="" />
<result name="Ihyb125" value="" />
<result name="Vhyb25" value="" />
<result name="Vhyb125" value="" />
<result name="Iapv25" value="" />
<result name="Iapv125" value="" />
<result name="HVbias" value="" />
<result name="IleakDcu" value="" />
<result name="Itest" value="" />
</action>
<action>
<action_description input_id="534" name="MAPVLT"
object_name="MOD" version="1"/>
<result name="MAPVLT_val" value=":0:" />
<result name="Tdate" value="" />
<result name="operator" value="0" />
<result name="tool_id" value="1" />
<result name="status" value="0" />
<result name="apvMode" value="" />
<result name="pedestal" value="" />
<result name="noise" value="" />
<result name="rawnoise" value="" />
<result name="calPApeak" value="" />
<result name="calSbackplane" value="" />
<result name="chflag" value="" />
</action>
<action>
<action_description input_id="540" name="SENSORBASIC"
object_name="MOD" version="1"/>
<result name="SENSORBASIC_val" value=":0:" />
<result name="Tdate" value="" />
<result name="operator" value="0" />
<result name="tool_id" value="1" />
<result name="status" value="0" />
<result name="voltageIV" value="" />
<result name="currentIV" value="" />
<result name="timeIt" value="" />
<result name="currentIt" value="" />
</action>
</composite>
</composite>
</unit>
</DBFile>
All empty results fields has to be populated by the DbParser
from the mainMonitor application or from lthe ocal Db Root files.
The filled results, where value is defined won't be changed. This
items , like operator, tool_id can be changed and fixed .
Others like ModulGrade, *_val and status tags should be
filled by hand.
logfile
traces all action
of the mainMonitor
For example:
Tue Jul 30
23:51:03 2002 ==StartNewModuleTest==
Tue Jul
30 23:51:04 2002 SetI2C
Tue Jul 30 23:51:04
2002 SetI2C
Tue Jul 30 23:51:25 2002 Start
Test PedRun
Tue Jul 30 23:51:33 2002
Stop Test PedRun
Tue Jul 30 23:51:41 2002
Save results to /home/cms/daqdev/Lt/ModuleTest/test/bin/t3
Wed Jul 31 00:00:36 2002 ==StartNewModuleTest==
Wed Jul 31 00:00:37 2002 SetI2C
Wed
Jul 31 00:00:37 2002 SetI2C
Wed Jul 31
00:01:00 2002 Save results to
/home/cms/daqdev/Lt/ModuleTest/test/bin/t4
GUI
User interface of the mainMonitor is based on Qt
graphics and produced with Qt desig ner.
There
are few tab windows filled with widgets, button, textwindows and
plots.
Control
provides
initialization and steering of the scenario file.
InitSetup
initialize setup, reads lt.xml and settings.xml
InitModules
Initialize the modules. For this a valid module Id numbers
have to be given in the bench position the modules are located.
LoadScenarioFile
load scenario file from the poped menu
StartScenario
start loaded scenarion. by default scenario file from the
settings.xml is taken. The slowctrl check is done automaticaly each
dt sec defined in the settings.xml
StopScenario
stop current scenario
PauseScenario
pause scenario. Only actions of the scenario are paused.
Slowctrl check is continuing Not implemented
yes
ContinueScenario
release pause not implemented yet
there are also some information textwindows
Nspills
number of FED's spills. Each spill is ~100 events
Nbadch
number of bad channels for all tested modules
Nerrors
number of APV errors (error bit) during acquisition for all
modules
Temp
temperature (C) in the test box
Humidity
humidity (RH) in the test box
Steering
can be used to run each action without scenario, on demand
.
PedRun
pedestal run with TSC internal trigger. settings and zero
supression algorithms are defined in the settings.xml. Latency
is fixed and the reset is disabled by default (can
be enabled from settings menu)
CalProfRun
calprof run is a scan over latency range, cal ibration group and
skew. Reset is enabled. The pedestal run is redone after each
change of latency
CalRun
scan over calibration groups, reset is enabled. The exisiting
pedestal is uded to calculate signal.
LatencyScan
scan over defined latency range. Reset is enbled. Also apv pipe
adresses and errors are checked. It uses
existing pedestals.
BPlaneRun
external backplane pulsing from TSC card. Latency is fixed, no
reset. It uses existing pedestal s.
LedRun
basicaly same as backplane
IVRun
IV curve. Range, time delays between measurements , number
of points per meas are defined in settings
ChangeHV
change HV. The text is updated with current values each 5
sec.
ChangeTemp
change cooling. The text is updated with current values each 5
sec.
CheckSlowctrl
check all slowctrl parameters(temp, hum, nbadch, avrms, etc..)
ConnectivityCheck check if the
module connectetions defined in the xml are correct. This test is
only needed after a fresh installation of the
system.
Abort
abort current test
SaveRecord
select root file (!only basename without extension) and save data
in the root file for each module.
SaveToXml
select XML template from poped menu and populate it for
each module with data. Filee with extension modid_templatename.xml
will be produced in current directory. You can edit this files, fill
missing items and copy them to the
results directory
of the BigBrowser with the name modId.xml. These files vcan
stored in the Central Db by clicking read iconin the calibration
menu.
OnlineMonitor
initialize TCP/IP root socket to a remote root section
ReadSettings
reread settings.xml file
ResetRecord
reset all data and results to zero.
Settings
By default all settings is defined in the settings.xml
however some parameters can be changed from the widgets. There
are two groups of settings related to the APV operation (I2C,
resets) and to the run conditions and zero suppression
algorithms. The groups can be modified independantly. For apv
settings there is two resets button: enableReset activates
reset after each trigger which allows to syncronize pipelinecells,
hardReset produces full reset of the FEC if widget is
enabled and Apply is pressed. Don't use the hardReset
function if it is not necessary.
Monitor
Contains
few important plots. By default all plots are presented (-1)
but particular module can be selected from redraw.
The
plots updated each time you switched to the Monitor window or by
redraw.
Ped
2 plots: pedestal and raw frames (one after one for
each apv)
Noise
2plots: rms(red) and rawrms(blue) noise in one and
badchflags
Cal
2 plots: Calibration amplitude (Sig-Ped) from the CalRun
and peak amplitude from Calprofrun
CalProf
Calibration signals for each channel
It
Current and Voltage versus time
Xt
2 plots: Temperature (box, cooling sink, heat sink,
ambient) and humidity (box and ambient)
Lat
2 plots: signal versus latency for each channel and
pipeaddresses for each apv in the selected module.
Ext
2 plots: backplane and led signal-pedestal
How
to run
The package can run in 'real' or
'simulation' mode. In simulation the tag < Simulation
in the lt.xml should be enabledsimulation="y">
The simulation tag can be enabled individually for any
hardware device in the lt.xml. The simulation tag
enables dummy channels instead
servers. For APV a simple fram
ewith pedestal, noise and common mode is simulated. There are random
numbers for temperautres, humidity etc.
The i2s channlels have no
functionality in the simulation mode so it is not possible to
generate cal profile
In order to run in real mode one has to start
servers first. The servers provides connection to the device drivers
resident in the linux kernel.
To start servers type:
startDIM and startDAQ (in this order !)
in the Daq/Config. By default it creates xterm for each
server.
For example :
../clearshm
xterm -fn 6x12 -title CONTROL -e
./testControl &
xterm -fn 6x12
-iconic -title ComputerBoardADC -e /bin/csh -c
'./AdcServer daq.xml 0' &
xterm
-fn 6x12 -iconic -title ComputerBoardDIO -e ./Dioctrl
dio0 &
sleep 1
xterm
-fn 6x12 -iconic -title ComputerBoardDAC -e /bin/csh -c
'./DacServer daq.xml 0' &
sleep
1
xterm -fn 6x12 -iconic -title
NHQ201 -e /bin/csh -c './Nhq201Server daq.xml 0 '&
sleep 1
xterm -fn
6x12 -iconic -title TRHX -e /bin/csh -c
'./TrhxServer daq.xml 0' &
xterm
-fn 6x12 -iconic -title AD4717 -e /bin/csh -c './Ad4717Server
daq.xml 0' &
If all windows are created the
mainMonitor application can be started.
Running applications
to start mainMonitor just type ./mainMonitor .
After mainMonitor GUI has appeared the setup has to be
initialized by pressing InitSetup button.
The
initialization takes time in case of 'real ' mode. If this is
done the initModule button becomes active.
The moduleId's
has to be filled in in the corresponing bench positions. This can be
done by the keyboard or by a bar code readed that works as a key
board entry. After this is done the module can be intitialized by
pressing the initModule button an after a while 'Construct
setup' is appered in the text window and the control tab
appears.
Then a tests can be started either using scenario
file or interactively by activating particular tests.
In
scenario mode:
In order to use a predefined (in
settings.xml ) scenario just press StartScenario. To
use another own press LoadScenarioFile. Again you still can
use default one or select from the popped menu. When scenario started
the programm regularly reads environment parameters. The time
interval is defined in settings.xml or can be changed
from settings window. It continue to check environment even
with PausScenario which suspend untill ContinueScenario
only actions defined in the scenario file such as pedRun, SaveRec,
etc. The line in the Control window shows which line of
the scenario file is active. The testStatus in the Steering
window shows which action is
currently active. The
scenario can be interrupted by pressing StopScenario.
In
interactive mode:
All test can be activated from
the Steering menu. If scenario is running first
the scenario has to be stopped by pressing StopScenario
Database
Data produced by application can be stored into Root
file as described above
This
files contains more information then required by the Central Db. The
Central Db accepts XML files with predefined format . This format is
defined in templates available from above , more
info at
http://hep.uia.ac.be/cms/testing/software/database.html.
Data from any Record in the Root file can be populated into the
XML format. If there are many Records in the Root file it can
be selected after analyzing root files by Root and pass this number
in the standalone programm tDbParser/test/src/testDb.cpp.
For
MODLT test 3 Records are required; first, at cold and the
last. In this case vector of Record numbers has to be provided.
The
XML file can be populated directly from the mainMonitor
application. In this case Records to be taged for XML has to be
saved with SaveRec with parameter 1. For MODLT 3
Records are required and can be selected with numbers 1,2,3
consecutevly.
The output files with extension
modId_templatename.mod will be produced. To store data in the Central
database
the files can be copied to the appropriate directory of
the BigDrowser (results) with the name modId.res template
CHECK
Zero Suppression algorithms.
In order to get a signal from APV we need
to know pedestals, noise, badchannels. In the Apv_Analysis
class basic zero suppresion algorithms are implemented.
Discussion about zero supression algorithms
can be found at
http://hhipe.uia.ac.be/~vzhukov/Software/algorithms.htm
and
http://hepwww.rl.ac.uk/CMSTracker/b_tau/TestBeam/PSImay2002/Results/Welcome.html
The implemented algortihms are similar to the one implemented in
the ORCA and produce results close to the TT6 (Pisa) code. The
analysis is fixed in AnalyzePed methode but it can be
modified using methodes defined in the class.
There are a two basic algorithms: updating and accumulatiing.
They are both works in 2 steps. First
calculate the estimate for the pedestal and raw rms without common
mode subtraction, second estimate the rms noise with common mode
noise subtraction and refine pedestal.
Updating
uses a simple
statistical mean to update pedestal and rms of the pedestal for
each event for the first step. No cuts are applied.
In the second
step the pedestal and common mode are subtracted to calculate
intrinsic rms. Some channels are skipped
in the calculation. The
channel is skipped if amp(i)-ped(i)-cmn (i) >
Tskip*rms(i) or > Tskip*averagesignal.
Becaus eof the
cuts the rms valus can be underestimated in case of many noisy
channels.
Accumulating
accumulate
statistics in the histogramm and calculate median and rms of the
histogramm with update rate(default=20)
The rms calculated
by simple interpolation of 68% for 1 rms. No cuts are applied. The
rms value is not shifted but
accuracy is worser as compare
with updating algorithm.
Bad channels
Channels can
be tagged as "bad" if they are out of range of pedestal,
rms or if the rms is above Tbad*averagechiprms.
Also
channels is taged as noisy if it was skipped in pskip of
events
For each occurance the bit flag is set.
2- pedestal
out of range (0-500 default )
4- rms out of range
8-
rms >Tbad*avens
16-was skipped more then pskip
Common mode
There are 2
algorithms: mean and median. Mean calculates truncated
mean in few iterations, ncmniter. Channels with
amp-ped
.> Th*rms are skipped. Median takes median value.
The cmn calculates in groups defined by nstncmn
Cuts and settings
User can
select:
npedraw:
Nevents for the first step. Normally pedestal converge in first
100 events
nped:
Ntotal to calculate pedestal and rms. Only this statistics will be
used.
tskip:
Threshold (default=3) to skip channels for updating algortihm and for
common mode (both algorithms)
tbad:
Threshold (def=5) for the bad channels: if rms >Tbad*averagechiprms.
modped:
1-updating, 2-accumulating algorithm
modcmn:
1-mean,2-median
ncmniter:
n iteration for cmn. (for median can be 1)
nstcmn:
N channels in the cmn group(32 default)
rmsmax:
range for the rms (0-10 default)
rmsmin:
pskip:
% (0.3 default) of events where channels can be skipped without being
bad channel. (for non gaussian noise)
Algorithms and cuts an be selected in the settings.xml file.
PedestalRunDescriptor.
For
the good modules the updating algorithm can be used. For the module
with many abnormal channels
and big common mode accumulating
and median cmn is better. For very ununiform cmn the nstcmn can
be 16.
Class organisation can be found at
http://hep.uia.ac.be/cms/testing/software/longtermdoxy/index.html
In the ModuleTest/ :
ModuleTestSetup contains
all componetes of the test setup: vector of Module, Setup,
ApvRedoutCtrl.
Module is a main tested object and
includes ModuleHv and HybridI2C which provide an
access to the
high voltage and bias current and to the apv,
mux, pll and tsc i2c lines.
Setup contains cooling
steering implemented as a thread and temperature and humidity
channels.
ApvReadoutCtrl provides steering for all
FedChannels and TSC card, including APV reset and hard reset.
TestProcedure provides steering for all tests, scenario
and save data.
TestBase class provides an
interface to all Module Test Runs which allows easily to insert
another test in the menu.
Test Runs are PedestalRun,
CalRun, CalProfRun, BPlaneRun, LatRun, LedRun, IVRun.
The
status of the runs is defined in TestStatus.
Zero
suppression algorithms are located in the Apv_Analysis class.
which inherits from Spill_Analysis - an intermediate container
for one spill data,
reordering and pipelineaddress finder.
All
GUI related stuff can be found in Monitorimpl which
inherits from Monitor produced by Qt.
OnlineMonitor
enables root TCP/IP server for remote online monitoring.
In the DbLocal/
All data obtained during test are
dinamicaly stored in the Record class. It contains RecHeader
with general information related to a particular test,
RecSetup
with information related to the testsetup and vector of
RecModule where all information related to the tested objects
is stored.
The classes provides methodes to Save all data in the
Root files as root objects. All classes inherits from RecUtil with
useful conversion methodes.
In the DbParser/
There
are two basic classes RecordReader which reads data from
Root file and DbParser which reads Central Db xml template and
populates data into it.
Correspondance between xml templates and
Root file variables is provided by DbLut lookup table.
Please report all bugs to Antwerepn
vzhukov@uia.ua.ac.be
wim.beaumont@ua.ac.be
ltmodsup@uia.ua.ac.be