|
||||||
|
|
|
|
|
|||||||||||||||||||||||||
|
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). cd $EMTBUILDS/production/ Then run the command: L1EmtChangeTowerMask Press (1) to mask off a tower.
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. 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. 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.
|
| 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 |
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)
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.
/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).
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 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).
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.
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.
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
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.
| 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 |
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:
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.
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.
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.
The EMT builds area should have the latest working tags of L1EmtOep and L1EmtTools.
It should specifically have built L1EmtOep/L1EmtCalTCRecApp.
NB The config key to use is 0x428
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.
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.
The run can be taken in either of two ways; from the central online run control or through a stand-alone release.
NB the config key to use is 0x866
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.
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.
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
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.
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:
You should also make sure that the EMC and EMT teststands are running the same version of dataflow, see below.
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.
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.
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.
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.
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.
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()
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)
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
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.
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
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.
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.
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.
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.
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
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