<!-- Title: 18:42:15  Wed Oct 30 2002 -->
<!-- Crewchief: Michele -->
<!-- Op1: Mary -->
<!-- Op2: Koji -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>starting new page...</pre>


<!-- Date: Wed Oct 30 18:53:29 2002 -->
Diffractive trigger timing test:<br> 
<p> 
Trigger timing study was done again in new hardware configuration with higher BSC trigger threshold. The trigger threshold was increased from nominal 120 counts (note this is not ADC count!) to 4000 counts just for this test purpose to kill out-of-time signal in adjacent buckets. These new thresholds were coded in the front-end code and reloaded into the CLC_00 crate by using the vxreload command. Then, the CLC-luminosity was dropped to zero, which was most likely due to that some necessary process(es) for luminosity measurements were accidentally killed and were not restarted properly. The problem was finally fixed by rebooting the crate.<br> 
<p> 
In the test we could take several myron mode runs with different trigger timings. Changes were mostly on fine tuning parameters (fine_b0_offset and fred_fine_delay). The results looked much better than before, and we were almost confident about a new timing (though it may not be perfect). So, we decided to leave the system as in new setting with new timing. I am now waiting for a next store to see what we observe in trigger rates...
<!-- Author: Koji -->
<!-- Comment: Thu Oct 31 12;29;44 comment by...Koji -->
<pre>The L1 diffractive trigger rates in new configuration were 
checked at the beginning of store #1924, which started with
fairly low luminosity. Checked was run 153556 which was the first
run after L2 problem was fixed and was taken at AvgLum=7.1E30.
The rates were compared with run 153091 taken at AvgLum=7.2E30 in
default (old) setting.


----------------------------------------------------------- 
                               153091        153556 
L1Bit                          R(Hz) X-sec   R(Hz) X-sec
#32   L1_GAP_EAST_&_JET5       87    12ub    88    11.1ub 
#34   L1_GAP_EAST_&_JET5_&_RP  0.7   96nb    0.97  123nb    
#35   L1_GAP_WEST_&_JET5       83    12ub    85    10.8ub
#38   L1_RP_&_JET5             19    2.7ub   25    3.2ub
#42   L1_TWO_GAP_&_JET5        13    1.8ub   14    1.8ub 
#53   L1_RP_PS150K             0.05  8nb     0.08  9.5nb   
-----------------------------------------------------------

It looks the GAP+Jet trigger cross sections are basically
unchanged (within 10% or so), and the RP+Jet trigger cross
sections are about 20% higher than before, which sounds not too 
bad. We will have to look into data to understand what caused 
changes in cross section. </pre>


<!-- Comment: Fri Mar 14 20;50;03 comment by...Koji -->
<pre>This higher cross section of RP+Jet5 and RP inclusive triggers 
was attributed to that the RP-3 was not in requirement of 3-fold
coincidences due to a bad trigger panel. So, during run 153556-
154006 the RP trigger was 2-fold (RP-1 and 2) coincidence. </pre>
<!-- Date: Wed Dec 4 17:52:03 2002 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=mini_plug&action=view&page=-57&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=mini_plug&action=view&page=-57' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=mini_plug&action=view&page=-58&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=mini_plug&action=view&page=-58' width='300'></a></center>
<!-- Author: Koji -->
<!-- Comment: Wed Dec  4 18;03;19 comment by...Koji -->
<pre>Noticed in looking through recent calibration plots in DBANA that one East MP-SumTower channel (#14) has shown much lower pedestal value than before. These two plots in DBANA show raw pedestal values for the SumTowers in the 2 runs 154599 (left) and 154636 (right) which were taken on Nov. 24 (8:54pm) and Nov. 25 (9:21pm) respectively. However, this behaviour looks disappeared somewhere between run 154803 taken on Dec. 1st and run 154928 taken on Dec. 3rd because the pedestal in the run 154803 looks still bad but that in the run 154928 looks pretty normal.</pre>


<!-- Date: Sun Dec 15 10:49:19 2002 -->
Reported by shift crew that the FCAL_00 couldn't pass coldstart due to successive done-timeouts. They rebooted and reset the crate several times but they didn't help. We asked Arnd to take a look at the crate, and he founds that the Tracer in slot 2 was not communicating well with RC. He suggested powercycling the crate afterwards, and we did that from Cryo room. Finally the Tracer communication was back after powercycling, so we have asked shift crew to put the crate back in data taking in the first opportunity.<br> 
<p> 
In attempt of disgnosing the problem, I went through e-log entries since 11/1/02 until today (12/15/02). Apparently there is a rising trend of frequency of problem appearance from FCAL crates. It is not only from FCAL_00 but also from FCAL_01, as well. Many of the problems are done-timeouts due to "bunch counter mismatch" thing (though it may not be true). There are at least 10 DTO errors from FCAL_01 reported by shift crew during that period. Also, there are a couple of "VxMon in Red" type error for FCAL_00 (Tracer problem?). One error due to "Heap Corrupted" was there too.<br> 
<p>  
Another finding which I didn't know is that the power supply of FCAL_00 was replaced with spare on 11/22 access. There was a beam quench before that (11/22, 2:50pm), which caused high radidation affecting the AC module of PS (according to Roberto's entry). After the PS replaces, there were about 5 DTOs which could be related to the PS or Tracer in the crate until now. Maybe good to investigate more on PS or Tracer during upcoming access planned on Tuesday (12/17)
<!-- Author: Koji -->


<!-- Date: Tue Dec 17 15:49:50 2002 -->
Accessed alcove crates during access on 12/17 to do the following two things;<br> 
<p> 
1) Replaced the TRACER in FCAL_00 with the spare (SN 096) which was one of the spares in 3rd floor spool. The problem we had on Sunday (12/15) was due to lost communication with the TRACER, and it indicated that the TRACER may not be working well. We replaced the TRACER anyway to see if this could kill or reduce the problems that we have had.<br> 
<p> 
2) Checked the voltages to the crate from the power supply. We could not check them on the FCAL_00 because of conflict with other people working on the shielding. Roberto measured the voltages at the FCAL_01 using multimeter, and found 3 of 5 channel voltages were off from nominal voltages;<br> 
<p> 
  +5V digital -> +4.59V (~0.4V off)<br> 
  -5.2V       -> -4.70V (~0.5V off)<br> 
  +5V analog  -> +4.71V (~0.3V off)<br> 
<p> 
Other 2 voltages (+15V and -15V) were OK. He therefore adjusted those voltages to the nominal values. This off-voltage (maybe due to that the PS was not well calibrated when it was installed) could have affected the data which we took so far. Good to check e.g, LED data before/after the voltage adjustment.<br> 
<p> 
Also, checked the volatages in PS monitoring in control room. Now they are as follows;<br> 
<p> 
FCALW_1: 4.96(5V) -14.88(-15V) 14.93(+15V) 4.97(+5V) -5.19(-5.2V)<br> 
FCALE_1: 4.84(5V) -14.99(-15V) 14.76(+15V) 4.93(+5V) -5.09(-5.2V)<br> 
<p> 
where the number in parentheses is nominal voltage.
<!-- Author: Koji -->


<!-- Date: Thu Dec 19 16:20:29 2002 -->
Mike Mulhearn (TOF group) and I looked at the L1 trigger signal at the PreFRED board with beam. The purpose was to check each trigger signal (BSC, RP, MP and TOF) with respect to B0 at the input to PreFRED in order for them to be timed in. The figure (see next entry) was what Mike made from the results. In summary, the BSC-ADMEM-1, MP-ADMEM-1 and 2 were at 14 CDF_CLKs with respect to B0, while the BSC-ADMEM-2 was at 17. The TOF signal was confirmed to be 5 CDF_CLKs later than the BSC-ADMEM-2. Only question is why the BSC-ADMEM-2 is 3 CDF_CLKs later than BSC-ADMEM-1 instead of 2 which we thought it to be. See <a href='http://fcdfhome.fnal.gov/usr/mulhearn/log/index.html'> 
his web page</a> for the numbers measured.
<!-- Author: Koji -->


<!-- Date: Thu Dec 19 16:22:01 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=mini_plug&action=view&page=-59&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=mini_plug&action=view&page=-59  width='300' align='top'></td><td>L1 trigger signal timing with respect to B0 at the input to BSCTOF PreFRED board</a></td></tr></table>
<!-- Author: Koji -->


<!-- Date: Wed Jan 8 12:03:06 2003 -->
<pre>Carla, Mike and I worked together again to test trigger timing at 
L1 trigger. Using Mike's script which sends charge to the ADMEM 
QIEs by faking B0/BC signal in diagnostic FIFOs, we could check 
trigger signal that comes from ADMEM trigger outputs for BSC and 
Miniplug ADMEMs with respect to B0/BC. The PreFRED chip was 
replaced with the latest version (= RP-3 bit 9 instead of 5, 
internal delay of 5 cdf_clks of BSC and MP signals to get them 
timed in with TOF timing). The BSC-ADMEM 1 and MP-ADMEM timings 
are delayed by 2 cdf_clks internally. What was observed in 
PreFRED and FRED indicated that the following timings looked best 
for all of them (except BSC-ADMEM-2); 
 
B0_OFFSET = 21 
FINE_B0_OFFSET = 4 (88 ns) 
FRED_COARSE_DELAY = 3 
FRED_FINE_DELAY = 0 
 
Actually 3, 4 or 5 of FINE_B0_OFFSET looked all fine.  
The trigger sinal from BSC-ADMEM-2 was looked at before PreFRED. 
And found that some channels had positive pulses while others had 
negative pulses, and RP coincidence was not made unfortunately.  
Maybe this can be due to that only ADMEM-2 is configured as the 
plug type, and the FIFOs may not be working well. 
 
Anyway, we decided to keep the system for next shot with new  
timing to see how the data looks. </pre>
<!-- Author: Koji -->


<!-- Date: Mon Jan 13 18:06:14 2003 -->
3 week shutdown started from January 13:<br> 
<p> 
With request by Rob and Stefano, all the signal and HV cables for west MP were disconnected at the detector. This was necessary to remove the beam pipe which was needed to replace the PMTs for west CLC. West BSC-1 counters were also removed.<br> 
<p> 
Steve notified that the MNP was turned into 'light blue' in iFix global alarm window. Just reset the PC and restarted the HV control program on CLC-1 PC, then the problem went away. Probably it was due to disconnecting the HV cables caused some effect in HV which iFix could not understand.
<!-- Author: Koji -->


<!-- Date: Sat Jan 25 00:36:39 2003 -->
Summary of access works done by Jan 24 (Friday):<br> 
<p> 
Cabling of west miniplug was done. In attempt of turning on the HV, noticed that the west PMT#3 (HV #15) and PMT#14(HV #22) showed overvolatages. These two PMTs were connected to BSC-1 spare cables (BC1 W 05SP and 06SP respectively). We swapped the HV cables between the PMT#3 and PMT#9 (which was a good one) at the detector side, then the overvoltage channel moved to PMT#9, which indicates a problem could be on the PMT. Therefore, we tried to replace the PMT#3 (SN: 2KC283) with the spare 1Mohm PMT (SN: 2KC286). Then the problem went away on that PMT. We also tried to replace another PMT (#14) but we couldn't find any spares for 4Mohm PMT. We almost tried to replace it with spare 1Mohm PMT, but suddenly the problem on PMT#14 disappeared. It could indicate the problem may be in connection but we decided to leave it as it is (until we encounter problem again). Michele will bring the replaced PMT (2KC283) to Rockefeller for testing.<br> 
<p> 
BSC-1 counters are not yet back. The rods used to connect the beam pipe at flange (to which the BSC-1 is attached) were too long. Asked Rob to contact beams people to cut them off.<br> 
<p> 
Replaced all MP transition boards with the new version (Rev-E2). Pedestals on the ADMEMs look all reasonable. Still need to check all channels with LED. Zipper tubing on the east side is almost done but Lou will finish it soon. 
<!-- Author: Koji, Michele -->
<!-- Comment: Sat Jan 25 00;44;10 comment by...Koji -->
<pre>SN for new Rev-E2 TB:

Slot#     6    8  10  12  14  16
---------------------------------
FCAL_00  050 040 048 047 046 040
FCAL_01  051 045 042 043 044 049
---------------------------------</pre>


<!-- Date: Wed Jan 29 10:51:00 2003 -->
Summary of access works by 1/28/03:<br> 
<p> 
Checked LED data taken last Friday (1/24) and noticed that 4 out of 5 tower channels which belong to the west miniplug PMT #3 (that we replaced) didn't show any signals. The Sum-Tower signal for the PMT looked OK. During access on 1/27 and 1/28, we finally figured out the connection of PMT connector at the PC board was not good and the problem went away by reconnecting it. Now all MP channels look working OK.<br> 
<p> 
East alcove PS (FCAL_01) died when they were working on drilling on the east wall. Probably the dust caused that. After they finished drilling on Tuesday morning, they cleanup the dust then recovered the PS.<br> 
<p> 
Zipper tubing of east MP was done on Monday morning. Attached a grounding cable to the zipper tube and the crate.<br> 
<p> 
The west BSC-1 counters were also mounted Monday morning after they cut off those long rods. We had to move the MP a little to make a room for mounting the BSC-1. After installing, the MP was moved back to original position. 
<!-- Author: Koji -->


<!-- Date: Wed Jan 29 19:37:48 2003 -->
Did some sort of final checks for MP electronics. Didn't find any problems in pedestal and QIE calibration for MP ADMEMs. The LED data was also taken again with final T.B. configuration and they looked good (as we saw yesterday). So, the new calibration constants (run 157642) were loaded into the ADMEMs. No errors were reported during this process.
<!-- Author: Koji -->


<!-- Date: Tue Mar 11 16:47:06 2003 -->
<pre>After the Jan, 03 shutdown, we have decided to lower the HV for 
MP PMTs to extend the linearlity of MP energy measurements up to 
5-6E31 luminosity. The new HV settings for all PMTs are as 
follows; 
 
|===========================================================|  
| Nominal HV setting for MP MCPMTs:                         |    
|  Period:  3/11/03 - ?/??/??  (Run 160067-???)             |  
|===========================================================|  
|           | West MP (HVslot# 8)   | East MP (HVslot# 9)   |  
|Sum-Tower# | HV ch#    HV(V) Diff  | HV ch#    HV(V) Diff  |  
|-----------------------------------------------------------|  
|    0      |   0       625     0   |   0       625     0   |   
|    1      |   1       650     0   |   1       645     0   |   
|    2      |   2       600     0   |   2       630     0   |   
|    3      |  15       640     0   |   3       645     0   |  
|    4      |   4       700     0   |   4       670     0   |  
|    5      |   5       685     0   |   5       660     0   |  
|           |                       |                       |  
|    6      |   6       635     0   |   6       675     0   |  
|    7      |   8       695   -20   |   8       670   -20   |  
|    8      |   9       685   -20   |   9       615   -20   |     
|    9      |  10       590   -20   |  10       705   -20   |  
|   10      |  11       620     0   |  11       665     0   |  
|   11      |  12       675   -20   |  12       655   -20   |  
|           |                       |                       |  
|   12      |  13       620     0   |  13       640   -20   |  
|   13      |  14       640   -20   |  14       625     0   |   
|   14      |  22       675   -20   |  16       625   -20   |   
|   15      |  17       675   -20   |  17       655   -20   |  
|   16      |  18       610   -20   |  18       625   -20   |  
|   17      |  19       705     0   |  19       650   -20   |  
|-----------------------------------------------------------|  
 
The PMTs with lower HV by 20V are ones which currently show the  
saturation in ADC slope at about Lum=3E31. We will evaluate later 
how much it extends the linearlity, then decide if we will need 
to lower them again or not.</pre>
<!-- Author: Koji -->
<!-- Comment: Fri Mar 21 11;44;27 comment by...Koji -->
This setting was effective until run 160468. In summary, this setting provided the linearlity up to around 4E31. It was 3E31 before these changes. Lowered HVs of some PMTs again (see below for new setting) to achieve 5E31. 
<!-- Date: Thu Mar 13 03:45:22 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=mini_plug&action=view&page=-60&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=mini_plug&action=view&page=-60  width='300' align='top'></td><td>Run#160150: we have a few dead channels in the MP!</a></td></tr></table>
<!-- Author: Michele -->



<!-- Date: Fri Mar 21 11:29:22 2003 -->
<pre>Replaced 3 transition boards with the spares in access on 4/21. 
The bad channels were as follows; 
- FCAL_00, Slot 10, QIE #7 (W tower #25) 
- FCAL_00, Slot 12, QIE #6 (W tower #42) 
- FCAL_01, Slot  8, QIE #2 (E tower # 2) 
 
The swapped and spare TBs are as follows; 
- FCAL_00, Slot 10: SN 048 --&gt; 032 
- FCAL_00, Slot 12: SN 047 --&gt; 031 
- FCAL_01, Slot  8: SN 045 --&gt; 022 
 
Yesterday (3/20) the FCAL_00 crate lost communication to DAQ. 
Powercycling the crate didn't help. In the access we saw that the 
power supply failed. After we swapped the boards, Roberto and a 
guy (sorry, I forgot his name) replaced the power supply with a 
spare (same VICOR PS), then everything looks OK. </pre>
<!-- Author: K. Terashi -->
<!-- Comment: Tue Mar 25 14;36;13 comment by...Koji -->
Checked new data after the access. Now above 3 channels look OK in ADC counts. All channels should be OK now.
<!-- Date: Fri Mar 21 11:40:52 2003 -->
<pre>After the access, I changed the MP-HV to the 2nd version of 
default HV settings.  
 
|===========================================================| 
| Nominal HV setting for MP MCPMTs:                         |   
|  Period:  3/21/03 - NOW  (Run 160468-???)                 | 
|===========================================================| 
|           | West MP (HVslot# 8)   | East MP (HVslot# 9)   | 
|Sum-Tower# | HV ch#  HV(V) Diff(V) | HV ch#  HV(V) Diff(V) | 
|-----------------------------------------------------------| 
|    0      |   0     625     0     |   0     625     0     |  
|    1      |   1     650     0     |   1     645     0     |  
|    2      |   2     600     0     |   2     630     0     |  
|    3      |  15     640     0     |   3     645     0     | 
|    4      |   4     700     0     |   4     670     0     | 
|    5      |   5     685     0     |   5     660     0     | 
|           |                       |                       | 
|    6      |   6     630    -5     |   6     655   -20     | 
|    7      |   8     685   -10     |   8     660   -10     | 
|    8      |   9     665   -20     |   9     615     0     |    
|    9      |  10     590     0     |  10     705     0     | 
|   10      |  11     600   -20     |  11     645   -20     | 
|   11      |  12     675     0     |  12     650    -5     | 
|           |                       |                       | 
|   12      |  13     605   -15     |  13     640     0     | 
|   13      |  14     640     0     |  14     605   -20     |  
|   14      |  22     665   -10     |  16     625     0     |  
|   15      |  17     675     0     |  17     655     0     | 
|   16      |  18     610     0     |  18     625     0     | 
|   17      |  19     695   -10     |  19     640   -10     | 
|-----------------------------------------------------------| 
 
This is effective from run 160468. Stay tune...</pre>
<!-- Author: Koji -->
<!-- Comment: Wed May  7 09;57;38 comment by...Koji -->
This setting was effective until run 162528 (May 6th).
<!-- Date: Mon Apr 28 14:07:29 2003 -->
<pre>Late entry... 
Shift crew noticed error messages in RC that complained about the  
ID PROM failure for the ADMEM slot 10 in FCAL_01 crate on April  
14, like below; 
 
------------------------------ 
FCAL error during cold start for l2 torture test (did not flag 
error in SM though, only errlogger):  
b0fcal01:Messenger:9:51:12 AM-&gt;ID PROM check failure in slot 10 (ASCII blank) 
------------------------------ 
 
This happened repeatedly during cold start. We then tried to  
reseat the ADMEM in the crate according to Rick's suggestion  
during access on April 16. Then the error disappeared. The bad 
runs due to this problem are 161441-161555. 
 
</pre>
<!-- Author: Koji -->


<!-- Date: Wed Apr 30 20:50:12 2003 -->
<pre>Data from west MP sum-towers (ADMEM slot 6, FCAL_00) were all 
ZERO since 4/26/03. Symptom first appeared in BSC-QIE calibration 
in form of following error messages; 
 
---------------------------------------------- 
(MLE) b0fcal00:Messenger:8:42:01 PM-&gt;QIE calibration failed 
(MLE) b0fcal00:Readout_Calib:8:42:01 PM-&gt;ADMEM=6 QIE=0 Fail 25: Self Calib Fail     (0.0) (0) (0) 
(b0fcal00) QIE calib: slot 06, qie 00:Fail 25: Self Calib Fail    , val 00.0000, cap 0, rng0. 
(b0fcal00) QIE calib: slot 06, qie 01:Fail 25: Self Calib Fail    , val 00.0000, cap 0, rng0. 
(b0fcal00) QIE calib: slot 06, qie 02:Fail 25: Self Calib Fail    , val 00.0000, cap 0, rng0. 
(b0fcal00) QIE calib: slot 06, qie 03:Fail 25: Self Calib Fail    , val 00.0000, cap 0, rng0. 
(b0fcal00) QIE calib: slot 06, qie 04:Fail 25: Self Calib Fail    , val 00.0000, cap 0, rng0. 
(b0fcal00) QIE calib: slot 06, qie 05:Fail 25: Self Calib Fail    , val 00.0000, cap 0, rng0. 
(b0fcal00) QIE calib: slot 06, qie 06:Fail 25: Self Calib Fail    , val 00.0000, cap 0, rng0. 
(b0fcal00) QIE calib: slot 06, qie 07:Fail 25: Self Calib Fail    , val 00.0000, cap 0, rng0. 
(b0fcal00) QIE calib: slot 06, qie 08:Fail 25: Self Calib Fail    , val 00.0000, cap 0, rng0. 
(b0fcal00) QIE calib: slot 06, qie 09:Fail 25: Self Calib Fail    , val 00.0000, cap 0, rng0. 
(b0fcal00) QIE calib: slot 06, qie 10:Fail 25: Self Calib Fail    , val 00.0000, cap 0, rng0. 
(b0fcal00) QIE calib: slot 06, qie 11:Fail 25: Self Calib Fail    , val 00.0000, cap 0, rng0. 
(b0fcal00) QIE calib: slot 06, qie 12:Fail 25: Self Calib Fail    , val 00.0000, cap 0, rng0. 
(b0fcal00) QIE calib: slot 06, qie 13:Fail 25: Self Calib Fail    , val 00.0000, cap 0, rng0. 
(b0fcal00) QIE calib: slot 06, qie 14:Fail 25: Self Calib Fail    , val 00.0000, cap 0, rng0. 
(b0fcal00) QIE calib: slot 06, qie 15:Fail 25: Self Calib Fail    , val 00.0000, cap 0, rng0. 
(b0fcal00) QIE calib: slot 06, qie 16:Fail 25: Self Calib Fail    , val 00.0000, cap 0, rng0. 
(b0fcal00) QIE calib: slot 06, qie 17:Fail 25: Self Calib Fail    , val 00.0000, cap 0, rng0. 
(b0fcal00) QIE calib: slot 06, qie 18:Fail 25: Self Calib Fail    , val 00.0000, cap 0, rng0. 
(b0fcal00) QIE calib: slot 06, qie 19:Fail 25: Self Calib Fail    , val 00.0000, cap 0, rng0. 
--------------------------------------------------- 
 
Checked the ADMEM with qietest and found a behaviour expected in  
a case of blown fuse; 
 
 *********************   Test  Menu   *************************** 
 *         OPTIONS                     Current Setting 
 *  1.  Select QIE                            0-19 
 *  2.  CAFE data input(0=DCcal,1=Ext,          1 
 *             3=DCcal+SMON,4=Ext+DCcal) 
 *  3.  Number of events                        1000 
 *  4.  DAC range                             0-0 
 *  5.  Step of DAC changing                    0 
 *  6.  Number of events per dumping            1000 
 *  7.  FRAM mode(0=lookup,1=passthrough)       1 
 *  8.  Run  
 *  9.  Print the events  
 * 10.  Statistics (to screen)  
 * 11.  Statistics (to file)    
 * 12.  Save the events (Max. 1000events)  
 * 13.  Tracer L1 Accept delay.                 84 
 * 14.  Events delay(unit=20ms)                 0 
 * 15.  Quality check. 
 *  Q.  Back  
 option -&gt; 8 
 
 crate_wait delay resolution:  20 ns 
No CALOK from DAC:  value, slot: 0xffffff00, 6.  
----------------------------------------------------------- 
 
This error is same as what we saw when the BSC-ADMEM (slot 17)  
had a blown fuse in Jan 2002.  
 
We will need access to fix this...  
</pre>
<!-- Author: Koji -->


<!-- Date: Thu May 1 16:41:56 2003 -->
Accessed to fix the ADMEM problem (see above) on 5/1/03. A LED of -15V on the front panel of the ADMEM was not on. Checked 2A fuses (6 green ones) and found one of them, labeled F6, showed inifinite resistance. Replaced it with a new fuse but the fuse immediately blew again when the ADMEM was returned to the crate. Decided to swap the ADMEM (SN249) with a spare ADMEM (SN390).<br> 
<p> 
We then tested QIE calibration and data taking upstairs. Everything looked OK. Checked RP-SMQIE calib as well, since the power was cycled and there was a little concern that it could cause more bad channels. The DBANA of RP also looked OK (that means new bad channels were not produced).<br> 
<p> 
The ADMEM was configured as a miniplug type with qietest. Also, the trigger FRAMs were initialized with the new E_T thresholds, i.e, 5000*8=40K counts for outer ring trigger outputs (FRAM 20-22), 12500*8=100K counts for inner ring trigger outputs (FRAM 23-24).
<!-- Author: Koji, Mary -->
<!-- Comment: Thu May  1 16;43;11 comment by...Koji -->
Downloaded new calibration constants (QIE calib run 162371) to all ADMEMs in two FCAL crates.


<!-- Date: Wed May 7 09:56:21 2003 -->
<pre>The HV for MP was changed for a couple of channels which showed 
saturation at luminosity around 4.7E31. 
 
|===========================================================| 
| Nominal HV setting for MP MCPMTs:                         |   
|  Period:  5/6/03 - NOW  (Run 162529-???)                  | 
|===========================================================| 
|           | West MP (HVslot# 8)   | East MP (HVslot# 9)   | 
|Sum-Tower# | HV ch#  HV(V) Diff(V) | HV ch#  HV(V) Diff(V) | 
|-----------------------------------------------------------| 
|    0      |   0     625     0     |   0     625     0     |  
|    1      |   1     650     0     |   1     645     0     |  
|    2      |   2     600     0     |   2     630     0     |  
|    3      |  15     640     0     |   3     645     0     | 
|    4      |   4     700     0     |   4     670     0     | 
|    5      |   5     685     0     |   5     660     0     | 
|           |                       |                       | 
|    6      |   6     630     0     |   6     655     0     | 
|    7      |   8     685     0     |   8     660     0     | 
|    8      |   9     665     0     |   9     615     0     |    
|    9      |  10     590     0     |  10     695   -10     | 
|   10      |  11     600     0     |  11     645     0     | 
|   11      |  12     675     0     |  12     650     0     | 
|           |                       |                       | 
|   12      |  13     605     0     |  13     640     0     | 
|   13      |  14     640     0     |  14     605     0     |  
|   14      |  22     665     0     |  16     625     0     |  
|   15      |  17     670    -5     |  17     645   -10     | 
|   16      |  18     610     0     |  18     615   -10     | 
|   17      |  19     695     0     |  19     640     0     | 
|-----------------------------------------------------------| 
  
This is effective since run 162529.</pre>
<!-- Author: Koji -->



<!-- Date: Wed May 14 14:58:38 2003 -->
Koji and I have worked for a while on the CLC1 pc trying to 
recompile the HV program with the new VC++ 6. We got few errors 
and we couldn't compile it. The problem needs more 
investigation. Anyway the working version of the program is 
operational as usual.  - Andrea Bocci 
<!-- Author: Koji -->


<!-- Date: Wed May 21 16:50:33 2003 -->
Miniplug status report:<br> 
<p> 
In checking recent data and QIE calibration results, we noticed that the ADMEM slot 10 of FCAL_01 failed QIE calibration in all channels since run 162851 (5/12). Symptom looked pretty similar to what we saw with a blown fuse on the ADMEM slot 6 of FCAL_00 (see above entry). But, on the data side, bad channels in ADMEM slot 10 were only few (QIE# 19, 20 and 26) out of 20 and the other channles looked good. During an access of 5/21, we swapped the ADMEM slot 10 (SN385) of FCAL_01 with a spare (SN390), but any of 6 fuses on the board was not blown. The power supply didn't turn back on after swapping. Rob Roser swapped a relay (24V) and the power was back. After the access, the crate was checked with QIE calibration (163281). All bad channles which had been failing calibration were gone, so the new constants were loaded to all 12 ADMEMs.  
<!-- Author: Koji, Mary -->
<!-- Comment: Thu May 22 17;41;52 comment by...Koji -->
The spare ADMEM which is now in slot 10 of FCAL_01 is SN386. The SN390 is in slot 6 of FCAL_00. 
<!-- Date: Wed May 21 17:03:39 2003 -->
<pre>Several bad or problematic channels were seen in checking recent 
data (noted above). For record, they are summarized here; 
 
FCAL_01, slot 10, all QIEs 
-------------------------- 
 QIE Calib   Date           Status  
 ~162828     5/11, 22:59    OK 
 162851~     5/12, 22:35    BAD: "Self Calib Fail" 
 
 Data 
 ~162836                    OK  
 162837~                    BAD for QIE #19,20,26 (no data) 
 ** these errors look correlated *** 
 
FCAL_00, Slot 12, QIE #2 
------------------------- 
 QIE calib   Date           Status 
 ~162637     5/8, 9:14      OK 
 162669~     5/9, 0:03      BAD (slope/slope_err high) 
 
FCAL_01, Slot 14, QIE #19 
------------------------- 
 QIE calib   Date           Status 
 ~162828     5/11, 22:59    OK 
 162851~     5/12, 22:35    BAD (slope low) 
 
FCAL_01, Slot 16, QIE #8 
------------------------- 
 QIE calib   Date           Status 
 ~162484     5/5, 11:02     OK 
 162502~     5/6,  6:29     BAD (sigma(off) big) 
 
 
These calibration failures were all gone after powercycling the 
crates in access of 5/21. It looks (to me) something funny is  
going on the power(?).  
</pre>
<!-- Author: Koji -->



<!-- Date: Thu May 22 17:46:43 2003 -->
<pre>For record, the list of miniplug ADMEMs  
(total 14 including 2 spares) is as follows; 
 
*** As of 5/22/03 *** 
 
Slot#  FCAL_00  FCAL_01 
----------------------- 
  6      390       63 
  8      191      307 
 10      393      386 
 12      392      394 
 14      388      391 
 16      389      387 
----------------------- 
spare: 385 (office) 
       249 (being fixed) 
 
</pre>
<!-- Author: Koji -->
<!-- Comment: Tue Sep 16 11;39;06 comment by...Koji -->
<pre>During access of 9/15/03 (Summer shutdown), the ADMEM #386 in slot
10 of FCAL_01 was replaced with a spare #385. The ADMEM #385 has a 
10A blown fuse, which will need to be replaced. 

Therefore, as of 9/15/03, the miniplug ADMEM configuration is as
follows;

Slot#  FCAL_00  FCAL_01 
----------------------- 
  6      390       63 
  8      191      307 
 10      393      385 
 12      392      394 
 14      388      391 
 16      389      387 
----------------------- 
spare: 386 (to be fixed) 
       249 (being fixed) 
 
</pre>
<!-- Comment: Tue Oct  7 17;50;03 comment by...Koji, Mary -->
<pre>The ADMEM #388 (slot 14, FCAL_00) lost communication on 9/27/03
during QIE calibration. No blown fuse was found on the board. 
Tried to swap the boards between slots 14 and 16. The same board 
(#388) still didn't work in slot 16, while the other board (#389)
looked OK in slot 14. We gave the board #388 to Patrick for 
repair, and he sent it to Lee (14th fl). Instead, we tried to put
ADMEM #386 (fixed with a new 10A fuse) in the slot 14, but the 
board showed the same symptom. Again no blown fuse on the board. 
We gave the board #386 to Patrick as well. We wait for what Lee 
finds on the previous board #388.

As of 10/7/03, the miniplug ADMEMs are as follows;

Slot#  FCAL_00  FCAL_01 
----------------------- 
  6      390       63 
  8      191      307 
 10      393      385 
 12      392      394 
 14      empty    391 
 16      389      387 
----------------------- 
spare: 388 (at Lee 14th fl)
       386 (at Patrick 3rd fl) 
       249 (see below) 
 
The ADMEM #249 was finally located by Bill. It was modified by
Lee (probably after repair) to look at ADMEM BC mismatch problem.</pre>
<!-- Comment: Wed Oct  8 15;46;59 comment by...Koji, Mary -->
<pre>Lee returned the board #388 with repair. He said that the Xilinx
FPGA chips were not downloaded for some confusion in the board. 
I don't think I understand what he meant but I guess he initialized
the chips in his test stand.

We installed the board in the empty slot 14 and it looked OK. 
Checked with QIE calibration. No problem was seen, so downloaded
new calibration constants in the whole boards. Also, took LED data.

As of 10/7/03, the miniplug ADMEMs are as follows;

Slot#  FCAL_00  FCAL_01 
----------------------- 
  6      390       63 
  8      191      307 
 10      393      385 
 12      392      394 
 14      388      391 
 16      389      387 
----------------------- 
spare: 386 (in our office) 
       249 (to be replaced with new spare ADMEM) 
 </pre>
<!-- Date: Wed May 28 12:23:04 2003 -->
Studying MP_ET triggered events from a test run 162824, about a half of MP_ET events were still triggered on inner ring sum-towers. The trigger threshold of inner rings were therefore increased from 12500*8=100K to 20000*8=160K counts (FRAM 23-24 in 
ADMEM slot 6 of FCAL crates). The outer ring ET thresholds were unchanged from 5000*8=40K. Also, the GAP trigger thresholds are same as before (128*8=1000) for all sum-towers.  
<!-- Author: Koji -->


<!-- Date: Fri Aug 15 10:47:26 2003 -->
Just a note on some channels with calibration problems that I was keeping an eye on while Koji was away: 
<BR> 
In calibrations taken June 22, 23 and 24, west trigger channel 4 (fcal00 
sl 6 ch 17) had pedestal ~40, rms ~1 and slope=0 I think.  Since then it 
seems fine. 
<BR> 
Also on June 24 and 26, east channels 46 and 48 (fcal01 sl 12 ch 9,11) 
had low pedestals (~20, ~60) and low rms (<10).  Channels 45 and 47 
(fcal01 sl 12 ch 8,10) had high rms (~30) but pedestals look ok.  All 
four channels had large slope_error/slope.  They all look fine since then too.  
<!-- Author: convery -->




<!-- Date: Tue Oct 7 17:53:17 2003 -->
<pre>Just for reference: 
 
Miniplug ADMEM type A: standard board/standard CAFE card 
  63 
 191 
 249 
 307 
 
Miniplug ADMEM type B: standard board/special "taped" CAFE card 
 385 
 386 
 387 
 388 
 389 
 390 
 391 
 392 
 393 
 394</pre>
<!-- Author: Koji -->



<!-- Date: Fri Nov 7 14:03:33 2003 -->
The PS of FCAL crates were replaced to PEI. The FCAL_01 was OK but the FCAL_00 was unstable since then. The +5VD and +15VDC failed several times, and reset sometimes helped but +15VDC kept faulting. Roberto replaced the PS to a spare, but the ADMEM pedestals of west MP were so low. This morning he checked the voltages and found several voltages a little bit lower than the spec. He adjusted them. I took QIE calibration and the all MP channels looked OK. Loaded new calibration constatns. 
<!-- Author: Koji -->


<!-- Date: Fri Jan 9 10:26:37 2004 -->
Miniplug/Roman Pot access:<br> 
An ADMEM (#388) in slot 14 of FCAL00 showed hardware failure (vision read/write error). The board was marked offline. During access of 1/9/04, the board was replaced with a spare #386 but the spare showed same problem (green "ready" light off). Swapped the spare with a board in slot 16 and it showed the spare is really bad. It looks symptom is same as what we saw before for these two cards. Dervin took the two cards and will ask Lee to fix them. Now the slot 16 of FCAL00 is empty.<br> 
A good news is that powercycling the crate fixed problem in SMXR which caused many bad channels in SMQIE calibration. The board is marked online again.
<!-- Author: K. Terashi -->
<!-- Comment: Fri Jan  9 10;27;53 comment by...K. Terashi -->
<pre>As of 1/9/04, the miniplug ADMEMs are as follows;
Slot#  FCAL_00  FCAL_01 
----------------------- 
  6      390       63 
  8      191      307 
 10      393      385 
 12      392      394 
 14      389      391 
 16      empty    387 
----------------------- 
spare: 386 & 388 (to be fixed) 
       249 (to be replaced with new spare ADMEM) 
 </pre>


<!-- Comment: Wed Aug  4 12;28;25 comment by...Koji -->
The problem on the ADMEM in slot 14 of FCAL00 started in the middle of run 177417. The board was marked offline in run 177418. The problem was finally fixed as in the next entry.
<!-- Date: Wed Jan 14 12:03:15 2004 -->
Miniplug access (1/14/03):<br> 
Installed the ADMEM #388 fixed by Lee with downloaded flash RAM in slot 16 of FCAL_00. Checked QIE calibration and tested DAQ run with both FCAL crates. They all look OK. New calibration constants were downloaded to all ADMEMs.
<!-- Author: K. Terashi -->
<!-- Comment: Wed Jan 14 12;04;32 comment by...Koji -->
<pre>As of 1/14/04, the miniplug ADMEMs are as follows;

Slot#  FCAL_00  FCAL_01 
----------------------- 
  6      390       63 
  8      191      307 
 10      393      385 
 12      392      394 
 14      389      391 
 16      388      387 
----------------------- 
spare: 386 (to be fixed, at Lee 14th fl) 
       249 (to be replaced with new spare ADMEM) </pre>


<!-- Comment: Wed Aug  4 12;29;02 comment by...Koji -->
<table border=0><td><tr><td bgcolor=#e0e030>BAD runs due to this ADMEM problem were 177417-177835.</td></tr></td></table>
<!-- Date: Mon Feb 9 12:02:46 2004 -->
Camille (Day shift SciCo) called to say that West MNP HV tripped during run 178881. They turned off and on the HV then the iFix alarm went away. 
<!-- Author: Koji -->
<!-- Comment: Wed Aug  4 12;31;00 comment by...Koji -->
<table border=0><td><tr><td bgcolor=#e0e030>Run 178881 is BAD</td></tr></td></table>
<!-- Date: Tue Mar 30 13:06:35 2004 -->
<p><font color="red">Recovery procedure for ADMEM memory being overwritten (vision read/write failure)</font>: 
<ul> 
<li> vxlogin b0fcal00</li> 
<li> cd "/cdf/code-common/cdfonline/fer/v3_29b/VxWorks-5.3/PPC"</li> 
<li> ld &lt qietest</li> 
<li> qietest </li> 
<ul> 
<li> 9) Map crate</li> 
 <ul> 
 <li>cafe IDs should be ~6000 -- ADMEM which needs to be reconfigured (say slot 16) may have bad ID, eg 32768 </li> 
 </ul>  
<li> 1) Select ADMEM</li> 
 <ul> 
 <li>number=1</li> 
 <li>slot=16 (or where ever the problem is)</li> 
 </ul> 
<li>11) L1 Trigger</li> 
 <ul> 
 <li>1) Select type =8 for miniplug (both fcal00 and fcal01) 
 <li>7) Pedestal =200 
 <li>3) Configure (FPGA) 
 <li>4) Download Et lookup table 
 <li>Q) back 
 </ul> 
<li>9) Map crate (make sure everything looks ok) 
</ul> 
</ul> 
<p> 
After doing this, we tested it in run control using Run Type DAQTest, Fcal, DAQTEST_MP_LED<p>
<!-- Author: terashi, convery -->
<!-- Comment: Tue Mar 30 13;08;05 comment by...terashi, convery -->
Note that when we first did this, we did not do 4) Download Et lookup table.  Then we got errors in run control "Table (suffix) L1PEDS3 (MPA) not loaded".


<!-- Comment: Wed Aug  4 12;39;53 comment by...Koji -->
<table border=0><td><tr><td bgcolor=#e0e030>The problem was an erased FRAM in the ADMEM slot 16 of FCAL00. The FCAL00 crate was out in run 181071. It was put back in from run 181073. Run 180171 is BAD.</td></tr></td></table>
<!-- Comment: Tue Sep 21 11;57;17 comment by...Koji -->
<pre>This problem happened on a BSC-ADMEM (slot 16 of clc00) on Sep.
21, 2004. Recovery procedure for BSC ADMEMs is slightly different
from MP case. 

qietest:
11) L1 trigger
  1) Select type=6 for BSC-ADMEM slot 16, type=7 for BSC-ADMEM slot 17
  7) Pedestal = 150</pre>
<!-- Date: Mon Apr 12 10:48:28 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=mini_plug&action=view&page=-61&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=mini_plug&action=view&page=-61' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=mini_plug&action=view&page=-62&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=mini_plug&action=view&page=-62' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=mini_plug&action=view&page=-63&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=mini_plug&action=view&page=-63' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=mini_plug&action=view&page=-64&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=mini_plug&action=view&page=-64' width='300'></a></center>
<!-- Author: convery -->
<!-- Comment: Mon Apr 12 10;50;27 comment by...convery -->
<pre>There were failures in the MP calibration last night:
(MLE) b0fcal00:Messenger:10:57:06 PM-&gt;QIE calibration failed
(MLE) b0fcal00:Readout_Calib:10:57:06 PM-&gt;ADMEM=12 QIE=18 Fail 14: Sigma(off) big (1.8126811) (3) (0)
(b0fcal00) QIE calib: slot 12, qie 18:Fail 14: Sigma(off) big , val 01.8127, cap 3, rng0.
(b0fcal00) QIE calib: slot 06, qie 12:Fail 13: Slope low , val 00.0000, cap 0, rng0.
(b0fcal00) QIE calib: slot 06, qie 13:Fail 13: Slope low , val -00.0000, cap 0, rng0.
(b0fcal00) QIE calib: slot 06, qie 14:Fail 10: No fitting , val 00.0000, cap 0, rng0.
(b0fcal00) QIE calib: slot 06, qie 15:Fail 13: Slope low , val -00.0000, cap 0, rng0.

Today I asked cyro to powercycle fcal00 and now everything looks good. (Note that run 181530 did not include the east crate fcal01.)</pre>


<!-- Comment: Wed Aug  4 13;24;42 comment by...Koji -->
No bad runs from this problem...
<!-- Date: Fri May 7 11:16:47 2004 -->
<pre>ADMEM slot 8 of FCAL00 was gone all of sudden during run 182456. Checked the crate with qietest but the board was not visible. It doesn't look like due to erased FRAM problem. Marked the board offline and the FCAL crates were back in run from 182462. </pre>
<!-- Author: Koji -->


<!-- Date: Fri May 7 17:57:52 2004 -->
<pre>In access of 5/7, we found a blown 10A fuse in F2 on the ADMEM in 
slot 8 of FCAL00. Swapped the fuse with a spare 10A fuse but the 
fuse blew again when the board was put back in the crate and the 
power was back on. Replaced the board with a spare ADMEM #386.   
 
As of 5/7/04, the miniplug ADMEMs are as follows; 
 
Slot#  FCAL_00  FCAL_01  
-----------------------  
  6      390       63  
  8      386      307  
 10      393      385  
 12      392      394  
 14      389      391  
 16      388      387  
-----------------------  
spare: 191 (to be fixed, given to Dervin)  
       249 (to be replaced with new spare ADMEM) </pre>
<!-- Author: Koji -->
<!-- Comment: Mon May 10 13;39;13 comment by...Koji -->
<pre>In the morning of 5/10 (Mon), Mary took Run Control QIE calibration (182534) of MP with all ADMEMs to download new calib constants. A bunch of "FRAM not be erased" errors appeared from most ADMEMs (in all slots of FCAL00 and slots 10-16 of FCAL01). Powercycled the crates but it didn't help. Sofrware changes were suspected so Bil Badgett was contacted. MP data has been bad from run 182457.</pre>


<!-- Date: Wed May 12 15:41:21 2004 -->
<pre>Bill fixed a bug introduced sometime January, that would probably be preventing us from downloading the calibration in FCAL crates. The new QIE calibration run 182580 was taken successfully and the constants were downloaded in the ADMEMs. The MP data will be good from run 182580.</pre>
<!-- Author: Koji -->
<!-- Comment: Wed Aug  4 13;33;40 comment by...Koji -->
<table border=0><td><tr><td bgcolor=#e0e030>BAD runs are 182457-182579.</td></tr></td></table>
<!-- Date: Wed Jun 2 11:51:54 2004 -->
<pre>The east miniplug had one channel which was failing calibration due to slope.  Somehow this really concerned the shift crew because error messages said calibration failed.  I powercycled fcal01 and it seems ok now.  (Note I did not see any holes in the YMon occupancy distribution due to the calibration failure.) 
&lt;p&gt;error log: 
&lt;pre&gt;(MLE) b0fcal01:Messenger:10:54:46 PM-&gt;QIE calibration failed 
(MLE) b0fcal01:Readout_Calib:10:54:46 PM-&gt;ADMEM=8 QIE=18 Fail 13: Slope low (0.036025237) (0) (0) 
(b0fcal01) QIE calib: slot 08, qie 18:Fail 13: Slope low          , val 00.0360, cap 0, rng0.  
&lt;/pre&gt;</pre>
<!-- Author: convery -->


<!-- Date: Wed Jun 23 11:40:07 2004 -->
<pre>QIE calibration failed in slot 16 of FCAL00, showing "Self Calib Fail" for all channels in the slot. Brown fuse was suspected from the past (see &lt;a href="http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=mini_plug&action=copyentry&page=4&time=20:50:12"&gt;here&lt;/a&gt; and &lt;a href="http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=beam_counters&action=copyentry&page=3&time=20:05:49"&gt;here&lt;/a&gt;) but no such fuses were found on the board. Finally it appears that powercycling the crate fixed the problem.</pre>
<!-- Author: Koji -->


<!-- Date: Wed Jun 30 10:42:52 2004 -->
Calibration failures (slope low due to large pedestal RMS) for East MP tower #61, 65 and 66 had occured in QIE calibrations since run 184427 (June 25, 10pm). Mary powercycled FCAL01 crate on June 29 after run 184525, that fixed the calibration problem.
<!-- Author: Koji -->


<!-- Date: Mon Jul 19 09:40:52 2004 -->
CO notified a calibration problem (red towers #57 and #59 of east MP in MPAQIE2) in run 185265. Checked DBANA and see that they are red since 185813 (July 14th). The FCAL_01 should be powercycled at next opportunity. 
<!-- Author: Koji -->
<!-- Comment: Tue Jul 20 10;29;22 comment by...Koji -->
Powercycled FCAL_01 crate during shot stup of store 3663. No calibration was taken afterwards, as the beam was in the machine. The east MP will be (hopefully) fine from run 185328.

<!-- Comment: Sat Jul 24 12;45;32 comment by...Koji -->
The calibration was taken in run 185354 after the store was dumped. It was indeed good.


<!-- Date: Fri Jul 30 16:19:05 2004 -->
<pre>I have found that the HV settings of MiniPlug are totally 
different from what we had been using until September 2003 
shutdown!!!!!!!!!!!!! 
 
Below is what I found in the default HV configuration file 
(C:\HV_NEW\hvdev\CLC_Forward_Crate.txt) on CLC1 PC; 
|===========================================================|  
|           | West MP (HVslot# 8)   | East MP (HVslot# 9)   |  
|Sum-Tower# | HV ch#  HV(V)         | HV ch#  HV(V)         |  
|-----------------------------------------------------------|  
|    0      |   0     640           |   0     640           |   
|    1      |   1     660           |   1     655           |   
|    2      |   2     610           |   2     640           |   
|    3      |  15     655           |   3     655           |  
|    4      |   4     705           |   4     680           |  
|    5      |   5     695           |   5     675           |  
|           |                       |                       |  
|    6      |   6     670           |   6     725           |  
|    7      |   8     765           |   8     740           |  
|    8      |   9     755           |   9     685           |     
|    9      |  10     660           |  10     795           |  
|   10      |  11     665           |  11     710           |  
|   11      |  12     745           |  12     720           |  
|           |                       |                       |  
|   12      |  13     650           |  13     710           |  
|   13      |  14     710           |  14     675           |   
|   14      |  22     745           |  16     685           |   
|   15      |  17     745           |  17     715           |  
|   16      |  18     680           |  18     685           |  
|   17      |  19     740           |  19     705           |  
|-----------------------------------------------------------|  
 
I found the exactly same configuration in  
C:\HV_NEW\CLC_Forward_Crate_mpDef_May14-Sep3.txt (last modified:  
9/4/2002). I guess this file was accidentally set to the default  
file probably while we worked on upgrading the HV program, etc  
during the shutdown.  
 
I set the HV settings which we had been using before the shutdown 
in the default configuration file and loaded them in the HV  
crate. The setting is as follows: 
|===========================================================|  
|           | West MP (HVslot# 8)   | East MP (HVslot# 9)   |  
|Sum-Tower# | HV ch#  HV(V)         | HV ch#  HV(V)         |  
|-----------------------------------------------------------|  
|    0      |   0     625           |   0     625           |   
|    1      |   1     650           |   1     645           |   
|    2      |   2     600           |   2     630           |   
|    3      |  15     640           |   3     645           |  
|    4      |   4     700           |   4     670           |  
|    5      |   5     685           |   5     660           |  
|           |                       |                       |  
|    6      |   6     630           |   6     655           |  
|    7      |   8     685           |   8     660           |  
|    8      |   9     665           |   9     615           |     
|    9      |  10     590           |  10     695           |  
|   10      |  11     600           |  11     645           |  
|   11      |  12     675           |  12     650           |  
|           |                       |                       |  
|   12      |  13     605           |  13     640           |  
|   13      |  14     640           |  14     605           |   
|   14      |  22     665           |  16     625           |   
|   15      |  17     670           |  17     645           |  
|   16      |  18     610           |  18     615           |  
|   17      |  19     695           |  19     640           |  
|-----------------------------------------------------------|  
This is effective from run 185750.</pre>
<!-- Author: Koji -->
<!-- Comment: Mon Aug  2 11;29;03 comment by...Koji -->
These wrong settings were effective between runs 175066 (or whatever the fisrt run after Sep. 2003 shutdown) and 185749.








<!-- Comment: Wed Aug 11 16;34;22 comment by...Koji -->
Actually it seems 174996 is the first good physics run after the shutdown.
<!-- Date: Wed Aug 4 13:44:47 2004 -->
<pre>Very late entry...&lt;br&gt; 
On Jan 26 2004, FCAL00 gave repeated done-timeouts in run 178448 due to the SMXR which was not responding. The crate was removed in a next run 178450. The SMXR was marked offline after run 178450, when the beam was lost. BAD run is only 178450.</pre>
<!-- Author: Koji -->
<!-- Comment: Wed Dec  7 18;40;00 comment by...Koji -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Bad run is 178450.</pre></td></tr></td></table>
<!-- Date: Thu Aug 12 17:05:05 2004 -->
<table border=0><td><tr><td bgcolor=#e0e030>Run 186186 is BAD for MiniPlug, as West MP HV tripped due to a loose HV connector. Two screws on the connector are both broken, so the connector was only pushed in. Should fix this during shutdown. </td></tr></td></table>
<!-- Author: Koji -->



<!-- Date: Tue Sep 21 14:36:31 2004 -->
MP-ADMEM (slot 6 of FCAL01) had "Self Calib Fail" errors for all channels in QIE calibration. Checked the board with qietest and it said "No CALOK from DAC: value, slot: 0xffffff00, 6." when pedestal was taken. Checked the board and found a 2A fuse in slot F6 was blown. It was sapped with a new fuse but the new one blew immediately. We finally swapped the board with a spare ADMEM (SN 169). The replaced bad board (SN 63) will be returned for fix.
<!-- Author: Koji -->
<!-- Comment: Tue Sep 21 14;55;17 comment by...Koji -->
<pre>As of 9/21/04, the miniplug ADMEMs are as follows; 

Slot#  FCAL_00  FCAL_01  
-----------------------  
  6      390      169  
  8      386      307  
 10      393      385  
 12      392      394  
 14      389      391  
 16      388      387  
-----------------------  
spare: 191 (fixed)  
        63 (to be fixed,will be given to Dervin) </pre>


<!-- Comment: Wed Apr  6 13;09;06 comment by...Koji -->
The ADMEM #63 was fixed and put in the cabinet in the 3rd floor. I got it.
<!-- Date: Wed Jan 12 11:33:33 2005 -->
<table border=0><td><tr><td bgcolor=#e0e030>New forward detector YMon codes have been used since run 191099 (where 6.0.0int3i version of online consumers were set to the default).</td></tr></td></table>
<!-- Author: Koji -->


<!-- Date: Wed Mar 2 13:15:17 2005 -->
<table border=0><td><tr><td bgcolor=#e0e030>The FCAL00 crate was out in run 194152, due to repeated done timeouts from the SMXR board in slot 4. The crate was back in DAQ from next physics run. Only run 194152 is BAD for miniplug.</td></tr></td></table>
<!-- Author: Koji -->


<!-- Date: Sat Apr 2 10:25:37 2005 -->
ADMEM slot 10 of fcal01 stopped responding after store 4073 was in. The board was taken out from data taking since run 196079. Will need access to fix it.
<!-- Author: Koji -->
<!-- Comment: Fri Apr  8 12;05;22 comment by...Koji -->
At the same time when the slot 10 stopped working, the slot 6 ADMEM started to give bunch counter mismatch errors from another ADMEM in the crate. The mismatch was not 3 consecutive counts in a row, which stops the run, so it didn't prevent data taking but gave "DataSyncErrors". 

<!-- Comment: Fri Apr  8 12;10;25 comment by...Koji -->
<pre>The two ADMEM boards were swapped out in an access of April 8th, 
2005. The calibration and DAQ runs looked ok (no data sync errors 
from fcal01). I will check the replaced boards later and they will 
be likely sent to Lee for fix. 

As of April 8th, 2005, the miniplug ADMEM mapping is as follows:

Slot#  FCAL_00  FCAL_01  
-----------------------  
  6      390      191  
  8      386      307  
 10      393       63  
 12      392      394  
 14      389      391  
 16      388      387  
-----------------------  
spare: 169 (to be fixed, will be given to Dervin)  
       385 (to be fixed, will be given to Dervin) </pre>

<!-- Comment: Thu Apr 14 11;38;55 comment by...Koji -->
<table border=0><td><tr><td bgcolor=#e0e030>The BAD runs for miniplug due to this ADMEM slot 10 problem in fcal01 is 196079-196276. The data from ADMEM slot 6 in fcal01 seems  to be ok.</td></tr></td></table>


<!-- Comment: Thu Jul 14 14;28;26 comment by...Koji -->
<pre>The two spare ADMEMs (169 and 385) are both fixed.</pre>
<!-- Date: Thu Jul 14 14:27:20 2005 -->
<pre>Miniplug ET trigger threshold was set again in slot 6 ADMEMs of  
fcal crates. The thresholds are set to be consistent with cuts 
used in trigger studies for low luminosity run proposals and the 
previous beam test results. Below is a summary of thresholds; 
 
Trigger  Trigger  PMT#         FRAM Threshold    ADC Threshold           
FRAM#    output#               address (hex) 
--------------------------------------------------------------- 
20       0 (OUT)  6,7,12,13     1250 (0x4e2)      10000 counts 
21       1 (OUT)  8,9,14,15     1250 (0x4e2)      10000 counts 
22       2 (OUT)  10,11,16,17   1250 (0x4e2)      10000 counts 
23       3 (IN)   0,1,2        25000 (0x61a8)    200000 counts 
24       4 (IN)   3,4,5        25000 (0x61a8)    200000 counts 
---------------------------------------------------------------</pre>
<!-- Author: Koji -->



<!-- Date: Tue Aug 2 13:20:26 2005 -->
<pre>MiniPlug calibrations for May - July 2005 data (runs 198380 - 201349) have been obtained and put into the database. Here is the procedure: 
 
0. Good Run selection 
In RunSummary web page, 
- Run Range: 198380 - 201349 
- Minimum Lum: 10 nb-1 
- Data Type: 1 
- Run Type: 1 
- Trigger Table: PHYSICS_3% 
- GoodRun (core, RunControl) 
- Run Checked 
- Online Bit: CLC, L1/2/3 Trg, Cal, CCal, PCal, COT, MNP 
--&gt; Get preliminary good run list 
 
1. MiniPlug bad run check 
Check bad runs in MiniPlug E-log. No bad runs were found between 198380 - 201349. 
 
2. Run Andrew's stntuple analysis code 
Follow instrunctions in his &lt;a href="http://csr.phys.ualberta.ca/~cdf/physics/weblog/mp_calibrations/index.html"&gt;web page&lt;/a&gt; 
 
For runs 198380 - 201349, the following towers did not have enough statistics in several luminosity bins for pass 2 calibrations. Pass 1 calibrations of those towers looked OK. Therefore, the pass 2 calibrations of different towers whose pass 1 calibrations have similar luminosity dependence to those towers were substituted to those towers.  
 
West MP   East MP 
------------------ 
 26(25)    7( 6) 
 35(34)   23(24) 
 39(38)   38(39) 
 40(38)   40(41)  
 47(48)   47(22) 
 63(62)   49(21) 
 67(66)   50(22) 
          54(36) 
          55(51) 
          62( 7) 
          67(64) 
          75(26) 
          76(49) 
          77(21) 
 
The number in parentheses is the tower that was substituted.</pre>
<!-- Author: Koji -->


<!-- Date: Mon Aug 8 20:24:00 2005 -->
<pre>During run 202397 (August 7th, 2005) we had repeated done timeouts from fcal00. Shepherding, resetting and rebooting the crate did not work. Problem seemed to be on slot 12 ADMEM; 
 
(MLE) b0fcal00:Messenger:Aug 7, 2005 8:38:01 PM-&gt;ID PROM check failure in slot 12 (ASCII blank) 
(MLE) b0fcal00:Messenger:Aug 7, 2005 8:38:01 PM-&gt;VISIONread/write failed in slot 12 
(MLE) b0fcal00:Messenger:Aug 7, 2005 8:38:01 PM-&gt;Resetting card in slot 12 failed 
 
The board was removed from daq, but the fcal00 gave continuous done timeouts. At that point whole fcal00 crate was removed from daq. Checked the crate later in another partition, and confirmed that slot 12 ADMEM was definitely bad. Funny thing was that other 3 boards in slots 6, 8 and 10 also gave bunch counter mismatch when any two of them were included in daq run. Powercycling the crate from conrol room did not help. 
 
In access of August 8, 2005, we swapped out the board in slot 12 with a spare. We took calibrations and daq test runs after that, and they all looked fine. It seemed like a manual reset of power supply did some magic to those three boards. 
 
As of August 8th, 2005, the miniplug ADMEM mapping is as follows; 
 
Slot#  FCAL_00  FCAL_01   
-----------------------   
  6      390      191   
  8      386      307   
 10      393       63   
 12      385      394   
 14      389      391   
 16      388      387   
-----------------------   
spare: 392 (to be fixed, will be given to Dervin)   
       169 (fixed, in our office)  </pre>
<!-- Author: Koji -->
<!-- Comment: Mon Aug  8 20;26;44 comment by...Koji -->
<table border=0><td><tr><td bgcolor=#e0e030>The BAD runs for the miniplug due to this ADMEM slot 12 problem is 202399-202465.</td></tr></td></table>


<!-- Comment: Fri Sep  9 11;18;15 comment by...Koji -->
ADMEM #392 was fixed and returned.
<!-- Date: Wed Aug 31 10:46:11 2005 -->
<pre>Problem reported on b0fcal01, when the crate is being configured  
(after clicking Config in RC). The error message was the following; 
 
(MLE) b0fcal01:Messenger:Aug 31, 2005 10:36:59 AM-&gt;ID PROM check failure in slot 2 (ASCII blank) 
(MLE) b0fcal01:Messenger:Aug 31, 2005 10:36:59 AM-&gt;No connection to tracer 
(MLE) b0fcal01:Messenger:Aug 31, 2005 10:36:59 AM-&gt;Statechange failed 
 
The crate was powercycled and the problem went away. Try powercycling, it will help you!!</pre>
<!-- Author: Koji -->



<!-- Date: Tue Sep 27 23:08:32 2005 -->
DTO from FCAL_01 due to a bad ADMEM board in slot 16. The board was swapped out in access on Sep 27, 2005. It turned out that a 10A fuse on F2 was blown. The fuse was swapped and the board was returned to Lee for check. Runs 204642-204778 were taken without FCAL_01.<p> 
FCAL_00 crate also got stucked in a run and was out of synch from the rest of system on Sep 24, 2005. The problem was finally fixed by powercycling the crate done on Sep 26. Runs 204695-204722 were taken without both FCAL_00 and 01 crates.
<!-- Author: Koji -->
<!-- Comment: Tue Sep 27 23;09;16 comment by...Koji -->
<table border=0><td><tr><td bgcolor=#e0e030>The BAD runs for miniplug due to the FCAL_01 problem is 204642-204778.</td></tr></td></table>

<!-- Comment: Tue Sep 27 23;26;21 comment by...Koji -->
<pre>As of September 27th, 2005, the miniplug ADMEM mapping is as follows; 

Slot#  FCAL_00  FCAL_01   
-----------------------   
  6      390      191   
  8      386      307   
 10      393       63   
 12      385      394   
 14      389      391   
 16      388      169   
-----------------------   
spare: 387 (to be fixed, returned to Dervin)   
       392 (fixed, in our office)  </pre>

<!-- Comment: Fri Sep 30 23;30;30 comment by...Koji -->
ADMEM #387 is fixed and returned.



<!-- Date: Wed Dec 14 21:01:14 2005 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Several additional bad runs for MP: 
155680: fcal00 out due to bunch counter errors. Silicon was also bad. 
179054: fcal00 out. 
182829: fcal00 out due to bunch counter errors. COT was also bad. 
</pre></td></tr></td></table>
<!-- Author: Koji -->


<!-- Date: Wed Dec 14 21:06:06 2005 -->
Run 195451 is marked bad for MNP and RPS but it should be ok. It is  a run with high lum trigger table.
<!-- Author: Koji -->


<!-- Date: Fri Jan 6 12:11:15 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030>Run 209764 is bad for miniplug since the fcal00 crate was removed due to bunch counter error, that was fixed by poweecycling the crate.</td></tr></td></table>
<!-- Author: Koji -->


<!-- Date: Fri Jan 13 21:04:55 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030>The TRACER of b0fcal01 crate went bad all of sudden and the crate had to be removed from daq. The bad TRACER was replaced with a spare (#145) in access on Jan. 13th. The BAD runs due to this problem are 209920-210012.</td></tr></td></table>
<!-- Author: Koji -->


<!-- Date: Mon Feb 27 14:43:26 2006 -->
<pre>Done TO from ADMEM slot 8 in b0fcal01 in run 212010. The bad board 
(#307) was replaced with a spare (#392) during access on Feb 22nd.  
The bad board has apparently a blown 10A fuse in F2 slot. The board  
will be sent for check-out. 
 
As of Feb. 27th, 2006, the miniplug ADMEM mapping is as follows; 
  
Slot#  FCAL_00  FCAL_01    
-----------------------    
  6      390      191    
  8      386      392    
 10      393       63    
 12      385      394    
 14      389      391    
 16      388      169    
-----------------------    
spare: 307 (to be fixed, returned to Dervin)    
       387 (fixed, in our office)  </pre>
<!-- Author: Koji -->
<!-- Comment: Mon Feb 27 14;48;23 comment by...Koji -->
<table border=0><td><tr><td bgcolor=#e0e030>Miniplug bad runs due to this problem are 212011-212110.</td></tr></td></table>


<!-- Comment: Thu Sep  7 15;42;24 comment by...Koji -->
ADMEM #307 has been fixed and returned.
<!-- Date: Wed Aug 23 18:31:17 2006 -->
Since the beginning of FY06 data taking (June 2006), the west miniplug had 3 zero occupancy towers (#79, #80 and #81) which belong to a PMT #17. The problem was due to a loose connection of the PMT signal cable to the PC board. It was fixed by reseating the cable in access of July 25, 2006.
<!-- Author: Koji -->
<!-- Comment: Wed Aug 23 18;34;59 comment by...Koji -->
<table border=0><td><tr><td bgcolor=#e0e030>The bad runs due to this problem are 217994(or whatever the first run after the shutdown) - 220499.</td></tr></td></table>



<!-- Date: Wed Sep 13 10:43:52 2006 -->
<pre>Repeated DTO from fcal00 occured in the middle of run 222530 with the follwoing errors; 
 
39'4" 1 crate/s: b0fcal00(26),  Done TO. [RXPT] 
(MLE) b0fcal00:Messenger:Sep 2, 2006 05:42:35 AM-&gt;ID PROM check failure in slot 8 (ASCII blank) 
(MLE) b0fcal00:Messenger:Sep 2, 2006 05:42:35 AM-&gt;ADMEM_config:VME bus  error slot=8 writing pipe length register [2] 
(MLE) b0fcal00:Messenger:Sep 2, 2006 05:42:35 AM-&gt;Resetting card in slot 8 failed 
(MLE) b0fcal00:Messenger:Sep 2, 2006 05:42:35 AM-&gt;Statechange failed 
  
which indicated a hardware problem in slot 8 ADMEM (#386). The entire fcal00 crate was removed from daq. 
 
In access of Sept 7th, Mary replaced the ADMEM #386 with a spare board #387. Found a blown 10A fuse in slot F2 (as usual) on the board #386. The board was sent to high-rise for check and it is now returned. The fcal00 crate has been back to daq since run 222717.</pre>
<!-- Author: Koji -->
<!-- Comment: Wed Sep 13 10;45;40 comment by...Koji -->
<pre>As of Sep 7th, 2006, the miniplug ADMEM mapping is as follows; 

Slot#  FCAL_00  FCAL_01    
-----------------------    
  6      390      191    
  8      387      392    
 10      393       63    
 12      385      394    
 14      389      391    
 16      388      169    
-----------------------    
spare: 307 (fixed, in our office)    
       386 (fixed, in our office)</pre>

<!-- Comment: Wed Sep 13 10;47;50 comment by...Koji -->
<table border=0><td><tr><td bgcolor=#e0e030>The bad runs due to this problem is 222532-222655.</td></tr></td></table>


<!-- Date: Thu Sep 14 17:14:22 2006 -->
<pre>MiniPlug calibrations for June - Sept 2006 data (runs 211790 - 222426) have been obtained and put into the database. Here is the procedures; 
 
0. Good Run selection  
Note: MP data is bad between 217990-220499 due to 3 dead towers (#79, 80 and 81) in west MP. Therefore, runs 220508-222426 are used to get calibrations and the calibration is checked for 217990-220499 by comparing energies between the two run ranges. 
 
In RunSummary web page,  
- Run Range: 220508 - 222426  
- Minimum Lum: 10 nb-1  
- Data Type: 1  
- Run Type: 1  
- GoodRun (core, RunControl)  
- Run Checked  
- Online Bit: CLC, L1/2/3 Trg, Cal, COT, MNP  
--&gt; Get preliminary good run list  
 
1. MiniPlug bad run check  
MP bad runs (217990-220499) are already removed. 
 
2. Run Andrew's stntuple analysis code  
Note: Due to saturation at high inst luminosity, the fit was performed only data taken at lum=20-60E30. For the following towers, slightly different lum thresholds were used for better fits: 
- W47, W78 and E22 --&gt; lum=25-55E30  
- E24 --&gt; lum=25-45E30  
To increase statistics for pass 2 calibration, no single vertex cut was used. 
 
3. Check calibration 
Reconstructed MP energies using calibrations obtained from 220508-222426.  
Used codes: 
/home/terashi/cdf2/ana_6.1.4/TMpCalibValidation.cc 
/home/terashi/cdf2/ana_6.1.4/TMpCalibValidation.hh 
/home/terashi/cdf2/ana_6.1.4/runMpCalibValidation.C 
 
Checked hit multiplicity, sumET, sumE (linear and log scales) using /home/terashi/cdf2/ana_6.1.4/checkMpCalibValidation.C for 220508-222426 and 217990-220499. They are consistent with each other. Also, checked previous runs 211130-212133 before the shutdown. Minimum bias data (gmbsbi) was used. The results are more or less consistent with above later runs after the shutdown.</pre>
<!-- Author: Koji -->


<!-- Date: Tue Sep 26 10:52:37 2006 -->
<pre>Late entry: 
Repeated DTO from fcal01 stopped daq. The problem board was slot 10 ADMEM (#63). The crate was removed from daq. In access of Sept. 13, the board was replaced with a spare board #307. It turned out that the bad board #63 had a 10A fuse and a XILINX blown! The board is fixed and returned. 
 
As of Sept 26th, 2006, the miniplug ADMEM mapping is as follows;  
 
Slot#  FCAL_00  FCAL_01     
-----------------------     
  6      390      191     
  8      387      392     
 10      393      307     
 12      385      394     
 14      389      391     
 16      388      169     
-----------------------     
spare:  63 (fixed, in our office)     
       386 (fixed, in our office)</pre>
<!-- Author: Koji -->
<!-- Comment: Tue Sep 26 10;55;27 comment by...Koji -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>The BAD runs due to this problem are 222886-222957.</pre></td></tr></td></table>


<!-- Date: Tue Sep 26 11:08:22 2006 -->
<pre>In Sept 25 evening shift, the fcal01 crate did not reach activate in runs 223624-223630. The error-log gave the following message on the crate: 
 
(MLE) b0fcal01:Messenger:Sep 25, 2006 09:03:00 PM-&gt;ADMEM_setCafeDelay geo32:/slot=16 VME bus error: old/target/new 0xff/0x5a/ff [4] 
... 
(MLE) b0fcal01:Messenger:Sep 25, 2006 09:04:13 PM-&gt;Runtime Error 1, Event 1: Bunch counter mismatch, mismatch count = 1 
(MLE) b0fcal01:Messenger:Sep 25, 2006 09:04:14 PM-&gt;Event 2: Bunchcounters in slot 8 (BC=56) and slot 16 (BC=255) disagree (L2B=1)  
(MLE) b0fcal01:Messenger:Sep 25, 2006 09:04:14 PM-&gt;Runtime Error 2, Event 2: Bunch counter mismatch, mismatch count = 1 
(MLE) b0fcal01:Messenger:Sep 25, 2006 09:04:14 PM-&gt;Event 3: Bunchcounters in slot 8 (BC=6) and slot 16 (BC=255) disagree (L2B=2)  
... 
 
Suspected corrupted software on the ADMEM slot 16. Checked the board with qietest and found all the CAFE ID of the board was 32768, which is a certain indication of the corruption. Followed the &lt;a href="http://www-cdfonline.fnal.gov/cgi/internal/elog/det-system-elog.pl?nb=mini_plug&action=copyentry&page=4&time=13:06:35"&gt;instructions&lt;/a&gt; and the problem was fixed.</pre>
<!-- Author: Koji -->
<!-- Comment: Tue Sep 26 11;10;15 comment by...Koji -->
<table border=0><td><tr><td bgcolor=#e0e030>The BAD runs due to this problem are 223631-223642.</td></tr></td></table>


<!-- Date: Tue Dec 12 14:20:06 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030>Late entry:<br> 
Miniplug should be marked bad for 223116-223122 due to a zero occupancy of east MP tower #26-#29, which was finally fixed by powercycling the FCAL01 cate.</td></tr></td></table>
<!-- Author: Koji -->


<!-- Date: Tue Dec 12 14:29:47 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030>Miniplug should be bad for 228405-228429 due to a (rare) non-sequential event number failure on the FCAL01 crate, which led to the removal of the crate. The problem was fixed by powercycling.</td></tr></td></table>
<!-- Author: Koji -->


<!-- Date: Mon Jan 15 14:21:05 2007 -->
<pre>Repeated DTO from fcal01 stopped daq. The problem board was slot 6 ADMEM (#191). Shepherded, rebooted and reset the crate, but it didn't pass config with message; 
 
*** VME bus error reading ID Prom, slot 6, address 0x00100010 *** 
*** ADMEM_config:VME bus  error slot=6 writing pipe length register [2] *** 
 
The crate was removed from daq. In access of Jan 8th, the board was replaced with a spare board #63. The bad board #191 has been returned to Dervin for fix. 
 
As of Jan 8th, 2007, the miniplug ADMEM mapping is as follows;   
 
Slot#  FCAL_00  FCAL_01      
-----------------------      
  6      390       63      
  8      387      392      
 10      393      307      
 12      385      394      
 14      389      391      
 16      388      169      
-----------------------      
spare: 386 (fixed, in our office) 
       191 (to be fixed) 
</pre>
<!-- Author: Koji -->
<!-- Comment: Mon Jan 15 14;24;21 comment by...Koji -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>The BAD runs for the miniplug due to this problem are 231454-231514.</pre></td></tr></td></table>


<!-- Date: Tue Jan 16 16:48:29 2007 -->
<pre>Repeated DTO from fcal01 stopped daq. The problem board was slot 10 ADMEM (#307). 
 
(MLE) b0fcal01:Messenger:Jan 13, 2007 08:22:33 AM-&gt;VME bus error reading ID Prom, slot 10, address 0x00100010 
(MLE) b0fcal01:Messenger:Jan 13, 2007 08:22:33 AM-&gt;ADMEM_config:VME bus error slot=10 writing pipe length register [2] 
 
The crate was removed from daq. In access of Jan 15h, the board was replaced with a spare board #386. The bad board #307 is now stored in a cabinet at B0 as it is hot. 
 
As of Jan 16th, 2007, the miniplug ADMEM mapping is as follows;    
 
Slot#  FCAL_00  FCAL_01       
-----------------------       
  6      390       63       
  8      387      392       
 10      393      386       
 12      385      394       
 14      389      391       
 16      388      169       
-----------------------       
spare: 307 (to be fixed, in the B0 cabinet)  
       191 (to be fixed, returned to Dervin) </pre>
<!-- Author: Koji -->
<!-- Comment: Tue Jan 16 16;51;03 comment by...Koji -->
<table border=0><td><tr><td bgcolor=#e0e030>The BAD runs for the miniplug due to this problem are 232028-232098.</td></tr></td></table>