<!-- Title: 06:41:55  Sat Mar 16 2002 -->
<!-- Crewchief: Steve -->
<!-- Op1: Jason -->
<!-- Op2: Gino -->
<!-- Op3: Chris -->
<!-- Op4: Lester -->
<!-- Op5: Andy -->
<!-- Op6: Saverio -->
<!-- Notes: -->
Just entered a new store.  Latest highlights are<ul> 
<li> <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=102&frame=2&anchor=19:11:07'>Improved Readout Times</a> 
<li>  <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=102&frame=2&anchor=20:22:24'>DVDD trips due to Clock Problems</a> 
<li> <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=102&frame=2&anchor=03:11:36'>A BIAS trip-happy ladder</a>  
 </ul> 
  

<!-- Date: Sat Mar 16 12:43:58 2002 -->
New incident report in Silicon database: SB0W0 L0 
incident n: 323
entered by: lmiller 
description is: <a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=102&frame=2&anchor=12:18:07'>
test of automatic elog incident report</a> 
<!-- Author: Problem DB -->


<!-- Date: Sat Mar 16 12:49:30 2002 -->
New incident report in Silicon database: <ul>
<li>Ladder: SB0W0 L0 
<li>incident n: 324 
<li>entered by: lmiller 
<li>description is: <a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=103&frame=2&anchor=12:43:58'>
testing prettier format </a>
 </ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Mar 16 12:51:36 2002 -->
New incident report in Silicon database: <ul>
<li>Ladder: SB3W6 L2 
<li>incident n: 330 
<li>entered by: nielsenj 
<li>description is: Software protection trip in SB3W6L2.
Current spiked from 150 to 775V in 5 read cycles.
Turned it back on, and it looks stable now.
 </ul>
<!-- Author: Problem DB -->
<!-- Comment: Sat Mar 16 16;27;32 comment by...Gino -->
<pre>I hope you mean 775 mA and not 775V.
The full wedge (all 5 layers) was doing the same but not SB3W7 (the other half of the FIB). </pre>

<!-- Date: Sat Mar 16 18:47:21 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 108
Calibration type  : standard
Run period tag    : Mar_2002
DPS-off run       : 141051
DPS-on run        : 141049
Requested by      : muge
Main process id   : 3165949
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Sat Mar 16 18:50:55 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 108 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 141051
DPS-on run       : 141049
Requested by     : muge
Submitted        : 2002-03-16 16:47:19
Completed        : 2002-03-16 16:49:57
Status           : FAILURE

Last processing stage reported : checking silicon configuration
Failure diagnostics :
error {missing close-bracket}
Exiting.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Sat Mar 16 20:28:26 2002 -->
<p> 
<b>SB3W0L2 BC mismatches</b> 
<p> 
I've been going through the list of SVXII wedges that SVT is currently not making very good use of, to see if we can improve 
our acceptance. 
<p> 
I tried 
<a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=225&frame=2&anchor=17:37:27'> 
earlier today</a>  
to unmask a few ladders in SVT.  One ladder I am still not able 
to unmask is <b>SB3W0L2</b>, because it generates BC mismatches  
in SVT every few seconds. 
Luckily, the problem is easily seen in SIXD.  For instance, in 
run 141044, file br0226f4.0001phys (in look area), here are the 
first few mismatches I see: 
<p> 
event 3489: E302 82FC (should be 4DFC)<br> 
event 4235: E302 1BFC (should be 09FC)<br> 
event 4672: E302 47FC (should be 18FC)<br> 
event 6131: E302 38FC (should be 1BFE)<br> 
event 7023: E302 50FC (should be 03FC)<br> 
<p> 
The 4th one is interesting, in that the BE state is wrong 
in addition to the BC number. 
We used to have a similar problem on SB2WAL2, which was 
cured by a  
<a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=96&frame=2&anchor=11:37:22'> 
FIB swap</a>  
on Feb 8.  Would it be possible to swap the FIB that handles 
SB3W[01] next access?  (Need a buddy, Steve?) 
<p>
<!-- Author: Bill Ashmanskas -->
<!-- Comment: Sun Mar 17 15;01;01 comment by...Bill -->
I also see <b>BC mismatches</b> in E204 (<b>SB2W0L4</b>) in the same run:
<p>
event 17843: E204 89FC (should be 88FC)<br>
event 24330: E204 71FC (should be 70FC)<br>
event 24590: E204 39FC (should be 38FC)<br>
event 31277: E204 77FE (should be 76FE)<br>
<p>
This is a different FIB, of course, and looks like a different
symptom (bit error).  I would want to look and see if SVT sees
the same error before blaming the FIB.

<!-- Date: Sun Mar 17 00:05:14 2002 -->
<pre>SB1W3L4 could not be turned on from standby (bias current 
overcurrent). 
 
Ace and I tried to ramp up the bias voltage slowly. 
We saw the following bias voltages and currents. 
2.0V =&gt; 2uA 
2.5V    6uA 
3V      9uA 
4V     17uA 
5V     24uA 
7V     38uA 
9V     57uA 
11V    89uA 
13V   125uA 
 
At this point, we stopped and decided to leave this ladder in 
standby for now, since these bias currents are much higher than 
those of the other layers. 
 
SB1W3L4 is in STANDBY for now. 
</pre>
<!-- Author: Jason -->

<!-- Date: Sun Mar 17 00:05:43 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 109
Calibration type  : standard
Run period tag    : Mar_2002
DPS-off run       : 141051
DPS-on run        : 141049
Requested by      : Igor
Main process id   : 3669789
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Sun Mar 17 00:07:53 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 109 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 141051
DPS-on run       : 141049
Requested by     : Igor
Submitted        : 2002-03-16 22:05:30
Completed        : 2002-03-16 22:07:43
Status           : FAILURE

Last processing stage reported : checking silicon configuration
Failure diagnostics :
error {Invalid request status "" for run 141051 from http://nglas05.fnal.gov/svx/bias_run_txt_cgi.pl?run_number=141051}
Exiting.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->


<!-- Date: Sun Mar 17 00:17:44 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 110
Calibration type  : standard
Run period tag    : Mar_2002
DPS-off run       : 141082
DPS-on run        : 141081
Requested by      : mario martinez
Main process id   : 3661444
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Sun Mar 17 00:18:09 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 111
Calibration type  : standard
Run period tag    : Mar_2002
DPS-off run       : 141083
DPS-on run        : 141081
Requested by      : mario martinez
Main process id   : 3696794
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Sun Mar 17 00:19:50 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 110 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 141082
DPS-on run       : 141081
Requested by     : mario martinez
Submitted        : 2002-03-16 22:17:13
Completed        : 2002-03-16 22:19:33
Status           : FAILURE

Last processing stage reported : checking silicon configuration
Failure diagnostics :
error {Invalid request status "" for run 141082 from http://nglas05.fnal.gov/svx/bias_run_txt_cgi.pl?run_number=141082}
Exiting.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Sun Mar 17 02:51:09 2002 -->
I realized that this wedge SB1W3 was the same one that Steve 
had problems with last night.  He had promised to remove it from 
the hdwdb if it tripped again.  I came in to remove it from the  
hdwdb (b0fib00, slot 13 bottom). 
<p> 
We made a new CAENvolts_031702.dat and pointed the link CAENvolts.dat to this file, then loaded it to the GUI.  
<!-- Author: Jason -->


<!-- Date: Sun Mar 17 09:06:53 2002 -->
Shift crew noticed b0fib03 was red in the VxWorks monitor, and 
ace could not login.  PSMon also reported that this power supply 
had failed.  Steve removed this crate from the hardware database 
until an access could be made to replace the supply.  We tried 
just turning the crate offline in the HDWDB, then generating CAENvolts.dat, but for some reason this did not generate the file correctly.  So we then went to turning all the FIBs offline, and 
this worked (although there may have been some protection issues 
on the CAENvolts_hdwdb.dat file in ~svxii which confused the issue.) 
<P> 
After that, LB0W3 tripped with bias overcurrent.  Steve noticed 
that the Vbias (hdi3) and Vbias1 (hdi4) were swapped around.  They are now set to 135V and 120V, respectively. 
<P> 
<B>It seems that simply reloading CAENvolts.dat while bias was ON 
does not change the bias set voltage.  Maybe it only picks up the 
change when a Standby->On transition is made?</B> 
<P> 
In the meantime, there were heartbeat alarms for L00, SVX, ISL, 
so we restarted the GUI and the alarms went away.
<!-- Author: Jason & SCN -->
<!-- Comment: Mon Mar 18 09;26;19 comment by...Andrew -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>The GUI sets bias voltage to a ladder during -&gt;On transition only.</pre></td></tr></td></table>
<!-- Date: Sun Mar 17 09:58:11 2002 -->
Since we lost a Fib crate, and the Luminosity sucks, starting with run 141090 I changed the Readout length parameter from 
4095 to 1024, limiting the maximum HDI readout length to 1 1KB, 
as a test (<a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=102&frame=2&anchor=19:11:07'>Details</a>).  Ideally this would be followed by trigger studies where we jack up the trigger rates and see what breaks at what level, but  
the necessary people are not around, so this is just a test of  
the fact that we can change this parameter and it still works. 
The READBUSY time at the VRB is now 30 uS, which is about 
right-it should be about 10 uS for digitize, and 1024 * 20 uS for 
readout.  We want to leave it this way for this store, then change it back when the Fib crate is  
recovered.<P> 
  The crucial question for deciding this parameter is<BR> 
at what point do we lose useful information by truncating  
the event early? <BR> Presumably someone could take the "No truncate data" of the last 6 months and (similar to David's study) artificially truncate the data at various points and compare  various figures of merit (like clusters on tracks for high multiplicity events).  These runs would serve as a crosscheck of this for truncating after 1024 bytes.  
<!-- Author: SCN -->
<!-- Comment: Sun Mar 17 10;27;25 comment by...SCN -->
<h4>To Change Back</h4>
Go to the Ace Run Control and<ul>
<li> Under Parameters Choose Edit or View Run Settings
<li> Under Browse choose Browse SvxSet
<li> Under the cdf tree choose SVX_NO_PEDS, then Select
<li> Find the ReadoutLength parameter in the list,
change it from 1024 to 4095, hit return
<li> Under File, Choose Save, and acknowledge the "Are you sure" inquisition
<li> Close everything in the proper sequence
</ul>
<h4>To Check</h4>
Parameter should be updated after next Warm/Cold start.  Issue
command:<pre>
setup fer;
java si_ss.monChecker "/partition-*/status/svx/fib/00" | grep readoutLength
</pre>
In something like 10 second intervals, you'll see <pre>
readoutLength: 2048:0x800
readoutLength: 2048:0x800
readoutLength: 2048:0x800
readoutLength: 2048:0x800
readoutLength: 2048:0x800
readoutLength: 2048:0x800
readoutLength: 2048:0x800
readoutLength: 2048:0x800
readoutLength: 2048:0x800
</pre>
This 2048 is the grey coded value.  To convert, you can
do <pre>
setup fer; setup jfc -k
java CDF.CdfConverter
</pre>
A little window will pop up.  In the text field on the left,
marked Grey, type in 2048, and in the furthest right one,
you'll get the decimal value (of 4095).  Some usful values for
quick reference<table>
<tr> <th> Decimal <th> Hex <th> Grey <th> Comment </tr>
<tr> <td> 32 <td> 20 <td> 48 <td> Value set to Fib after END RUN </tr>
<tr> <td> 1024 <td> 400 <td> 1536 <td> Current Value </tr>
<tr> <td> 4095 <td> fff <td> 2048 <td> Default Value </tr>
</table>


<!-- Date: Sun Mar 17 13:02:19 2002 -->
New incident report in Silicon database: <ul>
<li>Ladder: SB3W6 L2 
<li>incident n: 330 
<li>entered by: nahn 
<li>description is: Same thing, this time L2 and L3 claimed Software Protection Trip,
at March 17, 11:46.  Went back to Standby, then on, been stable since
(last 2 hours).  Suggest looking at timing signals in an access 
or getting more work done on PARST timing.  Log entry
<a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=103&frame=2&anchor=12:51:36'>here</a> 
 </ul>
<!-- Author: Problem DB -->
<!-- Comment: Sun Mar 17 13;04;18 comment by...The guy who hates entering the same info twice -->
Nice Job Lester!



<!-- Date: Sun Mar 17 17:03:25 2002 -->
<pre>Phantom DAQ page at 4:56-Control Room denies culpability.</pre>
<!-- Author: SCN -->

<!-- Date: Sun Mar 17 17:05:52 2002 -->
test
<!-- Author: email client -->


<!-- Date: Sun Mar 17 18:01:27 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 112
Calibration type  : nonstandard
Run period tag    : Mar_2002
DPS-off run       : 141103
DPS-on run        : 141102
Requested by      : Henri
Main process id   : 7134974
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Sun Mar 17 18:03:45 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 112 FAILED.

Job info
--------
Calibration type : nonstandard
DPS-off run      : 141103
DPS-on run       : 141102
Requested by     : Henri
Submitted        : 2002-03-17 16:00:03
Completed        : 2002-03-17 16:03:06
Status           : FAILURE

Last processing stage reported : checking silicon configuration
Failure diagnostics :
error {{} {The Power Supply configuration at start time is not available, comparison with DAQ list is not possible &lt;/b&gt;} {&lt;br&gt;&lt;br&gt;&lt;b&gt;Check the GUI spy file ! ! &lt;/b&gt;&lt;/font&gt;} Success}
Exiting.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Sun Mar 17 18:08:44 2002 -->
<pre>Monitoring for incident report N. 330 
 
Sun Mar 17 11:46:19 CST 2002 Software protection trip: High DVDD Current SVX B3 W6 L2  
Sun Mar 17 11:46:21 CST 2002 Software protection trip: High DVDD Current SVX B3 W6 L3  
Prompt recovery. 
This happened during run 141092 that has no HRR recorded. 
 
DEM report is not available yet. 
 
SVXMon: 
SB3W6L2 
        C2 Termination This error was present in  293 events out of  947 
        Duplicate Chan (nn) This error was present in  293 events out of  947 
        Unknown Channel This error was present in  449 events out of  947 
SB3W6L3C0 
   Pipeline cell out of sync in  780 events out of  842 
SB3W6L2C0 
   Pipeline cell out of sync in  767 events out of  842 
 
Generally all this wedge has pipeline out of synch errors. 
Are there the same errors in the other wedge of the same FIB ? 
apparenlty not: these are the only errors for this wedge. 
 
SB3W7L4 
        Bit Error (not 0/1) | 11 | This error was present in  11 events out of  947 
        C2 Termination | 2 | This error was present in  2 events out of  947 
        Unknown Channel | 19 | This error was present in  19 events out of  947 
        ff or 7f Error | 6 | This error was present in  6 events out of  947 
 
What else has pipeline out of synch ? 
IB0W2L4,IB0W3L4, IB4W1L0,IB4W1L2, IB4W1L4, LB1W4L0, 
SB0W2L1,SB0W2L2, SB0W2L3,  
SB0W8L4,  
SB2W4L4 
SB1W5L4, SB2W0L4,  
SB2W4L1, SB2W4L2,  
SB2W5L0, 
SB2W7L1, 
SB3W2L0, SB3W2L1, SB3W2L3,  
SB3W6L0, SB3W6L1, SB3W6L2,SB3W6L3,SB3W6L4,  
SB4W1L0, SB4W1L1, SB4W1L2, SB4W1L3, SB4W1L4,  
SB4W6L3,  
SB5W9L2. 
 
 
SB1W2L2C1 Pipeline cell id is stuck at 84 
</pre>
<!-- Author: Saverio -->


<!-- Date: Sun Mar 17 18:57:07 2002 -->
<h3> <I>Lazarus</I> crate arises again</h3> 
Rob tells me b0fib03 has been nailed by the beam more than 
any other-but they went in and fixed it again.  All Fib firmware 
is intact, and all former ladder are on, and I briefly ran them with Run Control and saw no errors at least at the reformatter level.  Contraary to <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=103&frame=2&anchor=09:06:53'>this entry</a> 
I did have to turn the crate back online before the ladders 
became un-x'ed in CAENvolts.dat, so perhaps turning the crate 
off was sufficient, but we had other filesystem problems this morning. 
<h3>BUT</h3>   
I couldn't even generate a CAENvolts.dat becuase the svxii user has quota trouble.  I think it is not a size issue, but a toital 
number of files problem.  Clean up your crap or I will-and I don't know what is crap and what is not, and frankly, I don't care.
<!-- Author: SCN -->


<!-- Date: Sun Mar 17 18:59:29 2002 -->
I changed the readout length back to 4095, thereby undoing 
<a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=103&frame=2&anchor=09:58:11'> 
this action</a>.  Run number now is 141114.   
<!-- Author: SCN -->

<!-- Date: Sun Mar 17 19:08:18 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 113
Calibration type  : nonstandard
Run period tag    : Mar_2002
DPS-off run       : 141103
DPS-on run        : 141102
Requested by      : Igor
Main process id   : 7275630
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Mon Mar 18 05:43:36 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 113 finished successfully.

Job info
--------
Calibration type : nonstandard
DPS-off run      : 141103
DPS-on run       : 141102
Requested by     : Igor
Submitted        : 2002-03-17 17:08:09
Completed        : 2002-03-18 03:43:23
Status           : SUCCESS
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->


<!-- Date: Mon Mar 18 08:33:08 2002 -->
New incident report in Silicon database: <ul>
<li>Ladder: SB3W6 L2 
<li>incident n: 330 
<li>entered by: nahn 
<li>description is: Software Protection Trip for L2 again.  Happens once a day.
Has not yet hit my threshold for turnign off the wedge yet (I assume L2 
goes first but others would follow soon, but that could be confirmed by 
the diagnostic shift) </ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Mar 18 09:09:10 2002 -->
<pre>MONITORING report for incident #330 
Ladder: SB3W6 L2  
The event occurred during run 141144 Physics Beam data. 
It is associated with pipeline out of synch,  
but this error is also present in the previous run  
for this wedge, at about the same level. 
Unable to plot the currents (but data are there). 
 
 
</pre>
<!-- Author: Saverio -->



<!-- Date: Mon Mar 18 10:47:24 2002 -->
D-mode calibration was done at the end of store 1091, but the 
files did not appear in the look area.  Probably has something 
to do with 
<a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=230&frame=2&anchor=10:16:27'> 
this.</a>  I'll go ahead and submit the web form anyway...   
<!-- Author: Andy H. -->
<!-- Comment: Mon Mar 18 14;42;38 comment by...Andy H. -->
Files started showing up around noon.
<!-- Date: Mon Mar 18 10:49:21 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 114
Calibration type  : standard
Run period tag    : Mar_2002
DPS-off run       : 141156
DPS-on run        : 141152
Requested by      : Andy H.
Main process id   : 9052064
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->



<!-- Date: Mon Mar 18 15:28:33 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 115
Calibration type  : standard
Run period tag    : Mar_2002
DPS-off run       : 141015
DPS-on run        : 141019
Requested by      : Igor
Main process id   : 9917049
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Mon Mar 18 15:28:33 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 115
Calibration type  : standard
Run period tag    : Mar_2002
DPS-off run       : 141015
DPS-on run        : 141019
Requested by      : Igor
Main process id   : 9917049
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Mon Mar 18 15:30:38 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 115 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 141015
DPS-on run       : 141019
Requested by     : Igor
Submitted        : 2002-03-18 13:27:48
Completed        : 2002-03-18 13:30:29
Status           : FAILURE

Last processing stage reported : checking silicon configuration
Failure diagnostics :
ERROR: some ladders appear in one calibration run only. This is the list:
{west east 3 5 phi}
{west east 3 5 z}
Exiting. If you really want to proceed beyond this point, change the parameter "abort_on_ladderset_mismatch" in the run_calib_analysis.tcl script to 0 and restart.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->


<!-- Date: Mon Mar 18 15:30:38 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 115 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 141015
DPS-on run       : 141019
Requested by     : Igor
Submitted        : 2002-03-18 13:27:48
Completed        : 2002-03-18 13:30:29
Status           : FAILURE

Last processing stage reported : checking silicon configuration
Failure diagnostics :
ERROR: some ladders appear in one calibration run only. This is the list:
{west east 3 5 phi}
{west east 3 5 z}
Exiting. If you really want to proceed beyond this point, change the parameter "abort_on_ladderset_mismatch" in the run_calib_analysis.tcl script to 0 and restart.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Mon Mar 18 16:25:25 2002 -->
<B>SB4W9L4 AVDD overcurrent</B>. 
<P> 
 The currents available from the 
spy show a 
maximum current of 1155uA, so any spike must have been on a shorter time 
period than this. The 
currents were constant before the trip. I tried to turn the ladder from 
Off to Standby twice but failed. 
Finally I had to remove this ladder from the hardware database. 
 
P.S.  The entry form for the hardware database encountered server errors.  
<!-- Author: Jason -->

<!-- Date: Mon Mar 18 17:53:50 2002 -->
New incident report in Silicon database: <ul>
<li>Ladder: SB4W9 L4 
<li>incident n: 331 
<li>entered by: lmiller 
<li>description is: SB4W9L4 AVDD overcurrent. The currents available from the
spy show a
maximum current of 1155uA, so any spike must have been on a shorter time
period than this. The
currents were constant before the trip. I tried to turn the ladder from
Off to Standby twice but failed.
Finally I had to remove this ladder from the hardware database.
 </ul>
<!-- Author: Problem DB -->
<!-- Comment: Tue Mar 19 06;44;06 comment by...SCN -->
I'm thinking lmiller == jneilsen here...
<!-- Comment: Tue Mar 19 09;51;20 comment by...Jason -->
<pre>True, except I encountered an error submitting the form, so LM did it for me.</pre>
<!-- Date: Mon Mar 18 20:08:13 2002 -->
<pre>New improved version of cratematch is now in operation. 
- direct access to database 
- it will include the crate on-line flag check (not there yet). 
</pre>
<!-- Author: Saverio -->
<!-- Comment: Tue Mar 19 14;27;56 comment by...Saverio -->
Now the check on the CRATE on-line flag is active in cratematch (thanks to Bill B)
<!-- Date: Mon Mar 18 23:21:57 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 114 finished successfully.

Job info
--------
Calibration type : standard
DPS-off run      : 141156
DPS-on run       : 141152
Requested by     : Andy H.
Submitted        : 2002-03-18 08:49:11
Completed        : 2002-03-18 21:21:50
Status           : SUCCESS
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Tue Mar 19 06:59:56 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 116
Calibration type  : standard
Run period tag    : Mar_2002
DPS-off run       : 141221
DPS-on run        : 141219
Requested by      : muge
Main process id   : 13471646
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->




<!-- Date: Tue Mar 19 10:59:26 2002 -->
<pre>The powersupply and temperature spies do not appear to be updating for the last couple hours. One of the historic causes for this is that the broadcasting programs on the iFix computer on the 1st floor get hung. I restarted them, but the problem remains.  
</pre>
<!-- Author: David -->
<!-- Comment: Tue Mar 19 11;10;36 comment by...Andy H. -->
The problem is that b0dap30 is down.  Noon is the current
estimate for its return.


<!-- Date: Tue Mar 19 11:15:19 2002 -->
CDF clock work trips off SB4W1, SB4W2, and SB5W0 (DVDD 
overcurrent software protection trips -- GUI window reports 
them on layer 3).
<!-- Author: Andy H. -->
<!-- Comment: Tue Mar 19 13;14;19 comment by...Gino -->
<pre>Brought them back to STDBY at 1:00 pm.
No problem.
No worth to fill an incident report because it is clearly 
correlated with the CDF CLOCK work (This is probably a 
questionable decision).

</pre>
<!-- Date: Tue Mar 19 11:31:13 2002 -->
New incident report in Silicon database: <ul>
<li>Ladder: IB5W5 L4 
<li>incident n: 333 
<li>entered by: chill 
<li>description is: After removal and reinsertion of FTM to fix RX on a different channel, this channel went to just c2c2. It looks like the OBDV bit is bad. Reseating the RX may fix it.
 </ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Mar 19 12:54:58 2002 -->
b0dap30 is back.  GUI, IMON, Saverio-spies all running.
<!-- Author: Andy H. -->



<!-- Date: Tue Mar 19 13:32:11 2002 -->
<h3>Sequence Check</h3> 
All fibs ok except b0fib07 Slot 12, which serves f320 IB3W2 i.e. 
ISL East Central, which is not in use due to cooling. 
It had a byte count 2 bits wrong, downloading from the  
EEprom fixed it.
<!-- Author: SCN -->


<!-- Date: Tue Mar 19 13:40:48 2002 -->
<a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=233&frame=2&anchor=11:00:11'>Clock work</a> caused some 
ladders to trip and really confused all the Vrbs, one so much so that it will not donwload its flashram successfully.  So I swapped out the Vrb in b0svx08 Slot 11 IB1W4/5.  In SN 152 PREP 551026  Out 107 550280.
<!-- Author: SCN -->

<!-- Date: Tue Mar 19 13:49:28 2002 -->
New incident report in Silicon database: <ul>
<li>Ladder: IB1W4/5 All 
<li>incident n: 334 
<li>entered by: nahn 
<li>description is: <a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=103&frame=2&anchor=13:40:48'>Clock work</a> 
caused this Vrb to refuse to download its Flashram.  It will be sent to FCC for reprogramming.
<table><tr><th>Vrb<th>SN<th>PREP<tr><td>Out<td>107<td>550280<tr><td>In<td>152<td>551026</table> </ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Mar 19 15:16:11 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 116 finished successfully.

Job info
--------
Calibration type : standard
DPS-off run      : 141221
DPS-on run       : 141219
Requested by     : muge
Submitted        : 2002-03-19 04:58:24
Completed        : 2002-03-19 13:15:53
Status           : SUCCESS
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Tue Mar 19 16:32:06 2002 -->
<h3> Recovering in HALT</h3> 
I used b0fib01 and tested some code which should allow us 
to power up Silicon in the HALT state, so that we can recover 
from trips without needing a COLD start.  In this case, 
the GUI tells the Fib CPU what it wants to turn on, and  
the CPU initializes each ladder one at a time with 
the correct bitstream.  In principle, if the GUI is only 
turning on one ladder, even outside of the halt state this ladder 
will be initialized with the "right" bitstream (whatever is in the hdwdb).  However, there is no readback for the single ladder 
init.  I tested the code a bit and it seemed to work but there were a multitude of smartsockets problems clouding the issue, so 
more testing is required.<p> 
Also, the next step is to initialize all running Silicon with 
the correct bitstream on every RECOVER (i.e. HRR) to prevent 
pinkies and ensure the above HALT init did not fail.  In some time 
we will also readback the shift register the first time to see 
if it is getting corrupted.  I will return this evening sometime 
to try and get this done.
<!-- Author: SCN -->


<!-- Date: Tue Mar 19 18:29:44 2002 -->
<pre>We changed the FIB sequences system wide from: 
CPC_021102.seq 
to  
CPC_030902_PNEW_CNEW.seq. 
 
This implies a single sequence for PARST  
(not anymore a PARST-START and a PARST-STOP)  
with MASK-INTER during it and  
the same MASK-INTER is implemented in CHIP_RESET as well. 
This are the only changes left in the system. 
 
Furthermore we tried another sequence: 
CPC_030902_PNEWd_CNEW.seq. 
were the PARST falling edge is delayed by 19 nsec on: 
SB3W6-7 successfully and we left it there. 
SB4W4-5 NOT-SUCCESFULLY and we moved back to  
	CPC_030902_PNEW_CNEW.seq 
	Because Layer SB4W5L4 (only) was tripping on DVDD). 
 
This is the first time we are running with mixed sequences in the system. To recap: 
CPC_030902_PNEW_CNEW.seq 	EVERYWHERE but SB3W6-7 
CPC_030902_PNEWd_CNEW.seq 	ONLY in SB3W6-7 
 
The evaluation of the behavior of SB3W6-7 is left to the long term. So far no-problem were spotted. 
 
 
 
</pre>
<!-- Author: LEster and Gino -->
<!-- Comment: Tue Mar 19 19;06;46 comment by...Gino -->
<pre>The evalution of the behavior of the global change is left to the long term as well.
It is supposed to make more robust our HRR procedures.</pre>


<!-- Date: Tue Mar 19 21:18:33 2002 -->
<pre>I changed some internal configuration of IMON. Nobody is upposed to notice the change, since its internal. 
Permanent fix in the following days. 
 
</pre>
<!-- Author: R. Eusebi -->


<!-- Date: Wed Mar 20 00:35:12 2002 -->
<h3> More Code work </h3> 
For a trial period or a day or two, we are booting the Fib VME crates of new code which <ul> 
<li> Allows one to turn on a ladder or wedge while Run Control is 
in the HALT state, where the handshake initializes the ladders 
with the real bitstream, allowing the Run to continue after a trip 
<li> Re-Initializes all HDIs being read out upon the Recover transition, after which they get synched by a CHIP RESET from 
the TS/SRC.  The extra time involved is not significant-failed 
init's will only get noticed by Sav's spy monitor (for now). 
<li> Has a bug fix for a bug we haven't hit yet involving the 
order of downloaded pedestals 
<li> In principle ignores any pedestals downloaded for L00 
</ul> 
The plan is to test Fib Peds tomorrow and decide on Thursday if we like this new code enough to make it default
<!-- Author: SCN -->


<!-- Date: Wed Mar 20 13:53:24 2002 -->
<h3>Pedestal Downloading Work</h3> 
After a bit of boneheadedness, we got the downloading procedure 
to function both when the global "Cold Start" is clicked, and 
when an individual crate is told to Cold Start (i.e. after 
a failed init of that crate only).  We sent two <B>UNBIASED COSMIC RUNS</b> to the look area, where the pedestals used were 
from <a href = 'http://cdfdbb.fnal.gov:8520/cdfr2/databases?cpn=FIB_PHYSICS_SVX&cjs=121488&crun=&ctbl=&calbk=PUBLIC&vsorder=-cjn&skip=&limit=125&rc=n&email=&type=cal-vs&do=r&nsrc=np&fsrc=fp&gsrc=fp&dcbk=FILECATALOG&calbk=PUBLIC'>Valid Set 121488</a> and the runs were 141317 (0x22805) and 141318 (0x22806) in the itestr directory. 
<P> 
What we need now is someone to take DBANA and overlay the 
average pulseheight distributions per chip from these runs with  
the corresponding pedestals to see if dead channels end up dead etc.  Someone also ought to check L00 as well (By the way, 
the inability to use a pedestal table for L00 also means we have no way of killing L00 channels in the online) to see that nothing 
was subtracted, if possible (at least that nothing was killed). 
Also, someone could check the thresholds as well (note: they are not yet all set to 7 in these runs, which is probably good). 
<P> 
So, someone would be....
<!-- Author: SCN -->


<!-- Date: Wed Mar 20 20:05:00 2002 -->
<h3>Reformatter error debug enhanced</h3> 
We got our desired RF error debug into L3.  Here's an example: 
<pre>RAWREF Error - BNK-SI-DUPL - with code 37 -- START 
 Line -  976 in: src/library/rr_refevt.c 
 Buffer position: -1 
 Error count: 1 of 1 
 Reject rate: 25.000 percent 
 
 Duplicate FIB ids:  0xe44003fc  0xe44103fc  0xe44203fc  0xe44303fc  0xe44403fc  0xe45003fc  0xe45103fc  0xe45203fc  0xe45303fc  0xe44003fc 
 
 Error location code: 0x05004290 
 
 
 Crate Id?: 0x00000050 
 
 Error during scanning MINI structure! 
 Last Unit prob. worked on (all counts from 0): 
  SCPU: 4 
  VRB : 2 
  LINK: 9 
  MINI: 0 
 
 
 NOTE: Event rejected! 
 
RAWREF Error - BNK-SI-DUPL - with code 37 -- FINISHED: L<  600 
</pre> 
For each channel (0-9) the top 16 bits are the fib id, the next 
8 is the BXING, the last 8 are the BE state.  
Here the fib ID e440 is repeated twice, once for e440, 
once for e454 (the imposter!).  The 03 is the BXing, the fc is the BE state, and they are all the same for all channels.  Before the change, instead of the Dupilcate Fib Ids, you would have seen 
<pre> 
Bank Name    Bank Instance  Mini Instance 
0x53495844    0x00000119    0x00000119 
</pre> which is not nearly so informative but says e440 was seen twice.  Now once can look at an errorfile log and grep for the ladders causing the majority of the RF errors.  Thanks Christoph and Ilya!  
<!-- Author: SCN -->

<!-- Date: Wed Mar 20 23:42:15 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W0/1 All 
<li>problem n: 335 
<li>Action: Swap_FIB
<li>entered by: nahn 
<li>description is: Swap Fib to fix <a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=103&frame=2&anchor=20:28:26'>BXING problem</a> 
Out: SN 166 PREP 565364 IN: SN 165 PREP 562365 </ul>
<!-- Author: Problem DB -->
<!-- Comment: Mon May  6 13;55;04 comment by...Petra -->
<pre>It's FIB 562364 that had the BXING error! </pre>
<!-- Date: Wed Mar 20 23:47:50 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W0/1 All 
<li>problem n: 335 
<li>Action: Swap_FIB
<li>entered by: nahn 
<li>description is: BXING error was on Channel 2. </ul>
<!-- Author: Problem DB -->
<!-- Comment: Mon Mar 25 16;25;19 comment by...Bill Ashmanskas -->
I just looked in some offline data from run 141434, and I do
not see any BC mismatches on ladder E302, i.e. the swap was a
success.

<!-- Date: Thu Mar 21 00:58:04 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W7 L4 
<li>problem n: 336 
<li>Action: Action_request
<li>entered by: bolla 
<li>description is: Vbias changed from 30V to 35 V.
I want the OFFLINE monitoring to check 
changes in efficiency. </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Mar 21 01:16:51 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W0 L2 
<li>problem n: 337 
<li>Action: Action_request
<li>entered by: bolla 
<li>description is: I changed the bias voltage from 50 to 55V.
Reason: the opposite half ladder needs 57 V and 
is reported to be touching this one so they 
should have the same bias voltage and I decided 
to apply 55 to both.
I want the OFFLINE monitoring to check the performances
(signal, occupancy, efficiency etc...) </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Mar 21 01:20:35 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W0 L2 
<li>problem n: 338 
<li>Action: Action_request
<li>entered by: bolla 
<li>description is: I changed the bias voltage from 20 to 55V. 
Reason: this half ladder needs 57 V and is reported to be
       touching the other half (SB2W0L2). So far it has 
	been kept at 20 V for unknown reasons.
	I decided to apply 55 to both of them. </ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Mar 21 01:45:03 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Thu_Mar_21_2002_014453.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-408  align='top'></td><td>Noise and Dnoise for biased and  Unbiased conditions for SB3W0L4</a></td></tr></table>
<!-- Author: gino -->
<!-- Comment: Thu Mar 21 01;48;34 comment by...Gino -->
<pre>During the access Steve and I measured the resistance between 
HV+ and HV- for SB3W0L4.
This ladder was reported by Mat herndon (tracking/alignement) as 
inefficient. 
The current reading on the bias line is usually 0 uA and so there 
were some doubts if the bias was actually making it to the 
sensors.
Both resistance measurements and the noise measurements seems 
to confirm the fact that the ladder is properly biased.</pre>

<!-- Date: Thu Mar 21 12:33:04 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W3 L3 
<li>problem n: 107 
<li>Action: Diagnosis
<li>entered by: nielsenj 
<li>description is: Another Bias1 overcurrent trip.
We removed this channel from the hardware database per
the new procedure for trips.
 </ul>
<!-- Author: Problem DB -->
<!-- Comment: Thu Mar 21 12;35;00 comment by...Jason -->
I should mention that IB4W5 also tripped, but we were able to turn it back on.

<!-- Date: Thu Mar 21 13:31:12 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W3 L3 
<li>problem n: 339 
<li>Action: Monitoring
<li>entered by: lmiller 
<li>description is: DRO/00f3 at chip 85 <1% </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Mar 21 14:02:25 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W4 L4 
<li>problem n: 340 
<li>Action: Incident
<li>entered by: lmiller 
<li>description is: 00f3 immediate and z side capids out of whack variable up to 50%
 </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Mar 21 14:06:34 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W5 L3 
<li>problem n: 341 
<li>Action: Monitoring
<li>entered by: lmiller 
<li>description is: bit 4 high 1% </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Mar 21 15:01:41 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W11 All 
<li>problem n: 342 
<li>Action: Incident
<li>entered by: lmiller 
<li>description is: Wedgewide capid and other problems. Need to see currents, need
command cables looked at.
 </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Mar 21 15:15:05 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W11 L2 
<li>problem n: 343 
<li>Action: Monitoring
<li>entered by: lmiller 
<li>description is: bit 5 high 2% Needs light investigation </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Mar 21 15:17:30 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W1 L1 
<li>problem n: 344 
<li>Action: Monitoring
<li>entered by: lmiller 
<li>description is: DRO 100% no single chip since 0x22569 </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Mar 21 15:19:34 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W6 L4 
<li>problem n: 345 
<li>Action: Monitoring
<li>entered by: lmiller 
<li>description is: Chip ID 89 bit errors few % varying </ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Mar 21 15:40:22 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W0 L4 
<li>problem n: 346 
<li>Action: PS_work
<li>entered by: lmiller 
<li>description is: <a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=103&frame=2&anchor=01:45:03'>
BIAS cable probed fine</a>, was reported by Herndon as inefficient 
 </ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Mar 21 15:55:17 2002 -->
<pre>DIAGNOSTIC SHIFT report to incident # 332 
reformatter errors SB2W2 & SB2W3 in run 140826. 
 
This run has 9 HRR, the first in response of BTO. after 20 min of data taking. 
The incriminated ladders are not giving errors at any reasonable level 
(&lt;1%) during this run: 
SB2W2L2 Drop Readout (d0 ch) This error was present in  1 events out of  1815 
This wedge was left unbiased during this run. No GUI activity was recorder. iFix connection went down twice. 
 
SB2W2L4C4 Inst occup Out of Li Chip inst occup was out of range in  8 events out of  1815 
No entry at all for SB2W3 
</pre>
<!-- Author: Saverio -->
<!-- Comment: Thu Mar 21 16;25;44 comment by...Saverio -->
<pre>The whole silicon was unbiased during this run.</pre>


<!-- Date: Thu Mar 21 18:04:54 2002 -->
<pre>Diagnostics for incident report #309 
IB5W1L2 fails init.03/10/02 03:41:41 
History: Jan 11 re included in HDWdb 
Feb 24 Pink in IMON AVdd low: IB5W1L2 595/1045 
AVdd was low when it did not init. 
03-10-2002 02:30:10 CST : 1015749010 Init Fib f512 hdi 7 ERRORS: 
read:   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
03-10-2002 02:32:08 CST : 1015749128 Init Fib f512 hdi 7 ERRORS: 
  read:   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff ff ff    ff ff ff ff ff ff ff ff 
03-10-2002 02:37:00 CST : 1015749420 Init Fib f512 hdi 7 ERRORS: 
03-10-2002 02:39:01 CST : 1015749541 Init Fib f512 hdi 7 ERRORS 
03-10-2002 02:42:25 CST : 1015749745 Init Fib f512 hdi 7 ERRORS 
 read:   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff ff ff    ff ff ff ff ff ff ff ff 
AVdd Currents are low for the whole wedge (see next plot).</pre>
<!-- Author: Saverio -->
<!-- Comment: Thu Mar 21 18;28;10 comment by...Saverio -->
<pre>Addendum:
Pipeline out of synch starting run 140695 (increasing rate)
ending run 140712 (few hours before we had to exclude it). 
 It need studies from detector group and may be try reintegrate under supervision.
Also needed: a history of currents vs time on a large time scale.
The other HDI with the same fib has regular currents.
</pre>
<!-- Comment: Thu Mar 21 19;06;15 comment by...Saverio -->
<pre>Addendum:
Type of error: immediate dropped readout:
Event Number: 1966007 Run Number 140315
10500d0b 04104100 00000000 00000000 00000000 00000000 08160816 00000000 
f51279fc 800f800f 800f800f 800f800f 800f800f 800f800f 800f800f 800f800f 40ns
800f800f c2c20000

and in read-all:
incriminated chips b4 b5 b7 cap ID problems. 
Otherwise the event is there, occasionally with a leading c2c2</pre>
<!-- Date: Thu Mar 21 18:20:04 2002 -->
<a href="http://nglas05.fnal.gov/svx/ib_noinit.jpeg">the plot for IB5W1 AVdd currents is here.</a> I could not include the file in the log.
<!-- Author: Saverio -->
<!-- Comment: Thu Mar 21 19;16;21 comment by...Saverio -->
<a href="http://nglas05.fnal.gov/svx/f512_errors.gif">Plot of errors vs run number</a> from the David's error monitor

<!-- Comment: Fri Mar 22 11;58;23 comment by...The Uploader -->
Plots are captured below, so need to clutter up Glasgow with them
<!-- Comment: Fri Mar 22 11;59;04 comment by...The Typomaker -->
That should say, "no need"
<!-- Date: Fri Mar 22 01:19:34 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W7 L4 
<li>problem n: 347 
<li>Action: Incident
<li>entered by: nielsenj 
<li>description is: SB3W7L4 software trip on DVDD current.  Tried to turn it back on,
and it tripped again.  Put this ladder offline in the hdwdb.
Currents are indeed high at trip time, >800.
 </ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Mar 22 01:27:55 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 117
Calibration type  : standard
Run period tag    : Mar_2002
DPS-off run       : 141468
DPS-on run        : 141466
Requested by      : Anne-Sylvie Nicollerat
Main process id   : 24669579
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->



<!-- Date: Fri Mar 22 08:40:52 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-409&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-410  width='300' align='top'></td><td>for Saverio D'Auria</a></td></tr></table>
<!-- Author: R. Vidal -->


<!-- Date: Fri Mar 22 09:09:56 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-411&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-412  width='300' align='top'></td><td>IB5W1L2 currents Avdd on a longer time scale</a></td></tr></table>
<!-- Author: Saverio -->

<!-- Date: Fri Mar 22 11:06:56 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W0/1 All 
<li>problem n: 348 
<li>Action: Removed_hdwdb
<li>entered by: chill 
<li>description is: Ladders de-integrated pending FIB/FTM investigation.
This FTM/FIB system produces 100% digital errors (c2c2).
On access, perform standard set of FIB/FTM de-bugging and probing. </ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Mar 22 11:45:22 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 117 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 141468
DPS-on run       : 141466
Requested by     : Anne-Sylvie Nicollerat
Submitted        : 2002-03-21 23:26:55
Completed        : 2002-03-22 09:44:30
Status           : FAILURE

Last processing stage reported : comparing to the reference calibration
Failure diagnostics :
The calibration failed the following reference comparison criteria:

             Cut Name    Sensor Set   Cut Value   Data Value
---------------------    ----------   ---------   ----------
  dps_off_ped abs max    SVX_PHI      0.5         0.906374  
  dps_off_ped abs max    SVX_Z        0.5         0.857865  
   dps_on_ped abs max    SVX_PHI      0.2         0.8153    
   dps_on_ped abs max    SVX_Z        0.2         0.790554  
   dps_on_ped abs max    ISL_PHI      0.25        0.878346  
   dps_on_ped abs max    ISL_Z        0.25        0.953837  
dps_off_noise rel max    SVX_PHI      0.025       0.112062  
dps_off_noise rel max    SVX_Z        0.025       0.119043  
dps_off_noise rel max    ISL_PHI      0.05        0.127958  
dps_off_noise rel max    ISL_Z        0.05        0.131514  
 dps_on_noise rel max    SVX_PHI      0.02        0.114495  
 dps_on_noise rel max    SVX_Z        0.025       0.115311  
 dps_on_noise rel max    ISL_PHI      0.05        0.115929  
 dps_on_noise rel max    ISL_Z        0.05        0.118175  
     bad_chan rel max    SVX_PHI      0.25        0.86092   
     bad_chan rel max    SVX_Z        0.25        0.884931  
     bad_chan rel max    ISL_PHI      0.25        0.577347  
     bad_chan rel max    ISL_Z        0.25        0.574854  
 bad_fraction abs max    SVX_PHI      0.02        0.150017  
 bad_fraction abs max    SVX_Z        0.025       0.175636  
 bad_fraction abs max    ISL_PHI      0.1         0.18277   
 bad_fraction abs max    ISL_Z        0.1         0.187977  

Reference calibration runs are 140856 (DPS off) and 140855 (DPS on)
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->


<!-- Date: Fri Mar 22 11:56:16 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W5 L4 
<li>problem n: 349 
<li>Action: Incident
<li>entered by: nielsenj 
<li>description is: Reformatter errors where e454 mimics e440.
For these runs, this e454 represented 100% of reformatter
errors, causing >1% instantaneous error rate.
I took this ladder offline in the hardware database.
 </ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Mar 22 11:56:21 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-413&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-413  width='300' align='top'></td><td>Sav's DEM plot for IB5W1</a></td></tr></table>
<!-- Author: Andy H. -->




<!-- Date: Fri Mar 22 12:48:03 2002 -->
<pre>UPDATES MADE TO CREATION OF CAENvolts.dat, etc: 
 
1) No need to link CAENvolts_hdwdb.dat to CAENvolts.dat anymore. 
Linking and placing the file in the $CAENCONTROL_DIR directory  
is now done automatically.  Old versions of this file will now  
be located in $CAENCONTROL_DIR/caenvoltsfiles. 
2) Each time a new CAENvolts.dat file is created a powerset.dat  
file will also be created.  Older versions of powerset.dat will 
be in the directyr $CAENCONTROL_DIR/powersetfiles. 
3) One can now make CAENcurrents.dat from the hdwdb.  It is an  
option in the SVX menu of the cardEditor and part of traceSilicon. 
The newly linked CAENcurrents.dat file will be in  
$CAENCONTROL_DIR and old files in the subdirectory caencurrentfiles. 
 
 
Please let me know if there are any problems! 
</pre>
<!-- Author: Eva -->
<!-- Comment: Fri Mar 22 13;36;43 comment by...Jason -->
<pre>I just had to use that today.  It works as advertised.
</pre>
<!-- Date: Fri Mar 22 13:01:00 2002 -->
<h3> Pedestal/threshold Downloading </h3> 
So, we attempted to download peds/thresholds, but found that 
some Chips were getting thresholds of 0, although most were correctly set at 7 (5 for L00) The imcomplete list 
of ladders is<ul> 
 
<li> SB0WB L4 Z Side only  
<li> SB0W3 L2 All 
<li> SB1W2 L2 All 
<li> SB2W0 L2 Z Side only 
<li> IB0W2 L2 Phi side for 2nd ladder, All Z 
</ul> 
 
I had thought I traced this down to a problem in the table, but 
a typo fooled me-there are thresholds for these chips in the 
table, so I do not know what they don't get to the front end. 
I believe that I do get 0s, because if I didn't get a pedestal for a chip, whatever is in the hdwdb would end up as the pedestal 
(but I think we would also fail cold start).  I guess this 
will have to wait until I get back.  
<!-- Author: SCN -->

<!-- Date: Fri Mar 22 13:13:13 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W3 L2 
<li>problem n: 350 
<li>Action: Removed_hdwdb
<li>entered by: nielsenj 
<li>description is: Reformatter errors on SB0W3L2.  Took this ladder offline in 
hardware database.
 </ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Mar 22 13:20:47 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 118
Calibration type  : standard
Run period tag    : Mar_2002
DPS-off run       : 141468
DPS-on run        : 141466
Requested by      : Igor
Main process id   : 30339322
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->




<!-- Date: Fri Mar 22 17:41:44 2002 -->
<pre>DIAGNOSTIC REPORT for incident #350 
03/22/02 13:12  Reformatter errors on SB0W3L2. OFF in the hardware database.  
 
This HDI started having problems at run x21664 
Event Number: 1137 
10500d0b 04104100 00000000 00000000 00000000 00000000 08160816 00000000  
e03253fc c2c20000  1447243056ns 
 
Now run x22880 is slightly different: 
Event Number: 70 
10500d0b 04104100 00000000 00000000 00000000 00000000 08160816 00000000  
e03247fc 89d0d0c2 c2c40000      20ns 
 
A known problem, there is action request standing. 
Is it related with reformatter errors ? to be continued</pre>
<!-- Author: Saverio -->
<!-- Comment: Fri Mar 22 18;03;48 comment by...Saverio -->
<pre>Layer-2 was drawing 200 mA on DVdd. Since when ? ...to be continued.</pre>

<!-- Comment: Fri Mar 22 18;48;41 comment by...Saverio -->
<pre>Run141501 
FIB ids found:
  0xe34056fd  0xe34156fd  0xe34256fd  0xe34356fd  0xe34456fd  0xe35056fd  0xc1c40000  0xe35256fd  0xe35356fd  0xe35456fd
Duplicate FIB ids:  
  0xe44038fc  0xe44138fc  0xe44238fc  0xe44338fc  0xe44438fc  0xe45038fc  0xe45138fc  0xe45238fc  0xe44038fc  0xe45438fc

Apparently errors were generated by SB3W5L1

</pre>


<!-- Comment: Mon Mar 25 12;22;21 comment by...Saverio -->
<pre>This ladder is drawing 200 mA on DVdd since march 7th
A clear step is visible in the daily average.
See John's plots.</pre>
<!-- Date: Fri Mar 22 19:01:05 2002 -->
<pre>DIAGNOSTIC REPORT ON incident #347 SB3W7L4 DVDD trip.  
This happened during a Silicon calibration run 141463  
 
GUI logfile: 
Fri Mar 22 00:25:01 CST 2002 Software protection trip: High DVDD Current SVX B3 W7 L4  
Fri Mar 22 00:33:22 CST 2002 success: Power Supply SVX B3 W7 ON  
Fri Mar 22 00:36:00 CST 2002 success: Resetting trips  
Fri Mar 22 00:39:42 CST 2002 Software protection trip: High DVDD Current SVX B3 W7 L4  
</pre>
<!-- Author: Saverio -->
<!-- Comment: Fri Mar 22 19;12;55 comment by...Sav -->
<pre>Digital current is changing a lot minutes before the incident.</pre>
<!-- Comment: Fri Mar 22 19;20;22 comment by...Saverio -->
<pre>Pipeline out of synch starting from run 141374 (99%) 2002.03.20 19:26:23
Chips: 87 88 89</pre>
<!-- Date: Fri Mar 22 19:11:13 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-414&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-415  width='300' align='top'></td><td>DVdd currents for SB3W7L4 at the trip time.</a></td></tr></table>
<!-- Author: Saverio -->




<!-- Date: Fri Mar 22 19:27:42 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-416&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-417  width='300' align='top'></td><td>Same currents, in the 24h scale, yesterday</a></td></tr></table>
<!-- Author: Saverio -->

<!-- Date: Fri Mar 22 20:30:05 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 118 finished successfully.

Job info
--------
Calibration type : standard
DPS-off run      : 141468
DPS-on run       : 141466
Requested by     : Igor
Submitted        : 2002-03-22 11:20:07
Completed        : 2002-03-22 18:28:37
Status           : SUCCESS
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->


<!-- Date: Fri Mar 22 22:55:59 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 119
Calibration type  : standard
Run period tag    : Mar_2002
DPS-off run       : 141533
DPS-on run        : 141529
Requested by      : diego/Kai
Main process id   : 32279786
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->



<!-- Date: Sat Mar 23 13:03:26 2002 -->
<B>GUI Problems</B><P> 
DAQ ace called to report the confused state of the GUI, described <a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=245&frame=2&anchor=12:57:57'> 
here</a>. 
<P> 
No response from GUI pager.  While I was on my way in to look at the GUI, ace paged Chris and they rebooted svxinter. 
<P> 
I'm not sure how/if to put this in the problem database.  Needless to say, there was an incident, and there is a question: Why was the GUI in that funny state?
<!-- Author: Jason -->
<!-- Comment: Sat Mar 23 19;35;25 comment by...CH -->
<pre>In addition to rebooting svxinter, a fib needed to be re-booted
(b0fib00)because of a handshake error (no response from fib).

So there appear to have been two incidents, one DAQ and one 
PS/GUI, although it is possible that one caused the other. 

I will make entries in the problem DB if they are not
there already.



 </pre>
<!-- Date: Sat Mar 23 18:17:32 2002 -->
<pre>The incident happened during run 141541 
and was probably caused by a comunication error: 
Sat Mar 23 11:21:33 CST 2002     Illegal condition: Portcard OFF, Ladder ON; turning OFF   L00 B1 W5</pre> 
The portcard was reported ON at 11:22:02, when the gui turned off 
the L00 wedge. 
<a href="/svx-data1/datalog/PSGUI/log/20020323.log"> GUI logfile</a><pre> 
Also SB0W1, SB2W1, SB2W10 etc.. were turned off by the GUI. 
The trip that is reported happens after they tried to restart 
Sat Mar 23 11:45:46 CST 2002     TRIP: SVX  B0  W11 5VDOIM OverVoltage</pre> 
How long was the GUI "off ?" 
not much !: 3 min at the time. 
New time 40922 Sat Mar 23 11:22:02 2002 
New time 41113 Sat Mar 23 11:25:13 2002 
New time 41322 Sat Mar 23 11:28:42 2002 
Can't plot currents yet.  
<!-- Author: Saverio -->
<!-- Comment: Sat Mar 23 18;25;41 comment by...Saverio -->
<pre>consecutive entries in the spy file:
New time 40922 Sat Mar 23 11:22:02 2002 
New time 41113 Sat Mar 23 11:25:13 2002 
New time 41322 Sat Mar 23 11:28:42 2002</pre>


<!-- Date: Sat Mar 23 19:59:09 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SFIB00 All 
<li>problem n: 351 
<li>Action: Incident
<li>entered by: chill 
<li>description is: Rebooted, necessary to recover from 10 wedge sponateous shutoff,
w/o trip messages in GUI/IFIX.  Need to find out if PS or DAQ 
problem or both.  Details by ACE in <a href=
'/cgi/elog/elog.pl?nb=2002&action=view&page=245&frame=2&anchor=12:57:57'>
e-log</a> </ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Mar 23 20:36:05 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 120
Calibration type  : standard
Run period tag    : Mar_2002
DPS-off run       : 141533
DPS-on run        : 141529
Requested by      : Igor
Main process id   : 606705
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Sat Mar 23 20:36:05 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 121
Calibration type  : standard
Run period tag    : Mar_2002
DPS-off run       : 141548
DPS-on run        : 141547
Requested by      : kai yi
Main process id   : 610239
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Sat Mar 23 20:38:11 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 121 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 141548
DPS-on run       : 141547
Requested by     : kai yi
Submitted        : 2002-03-23 18:35:37
Completed        : 2002-03-23 18:37:46
Status           : FAILURE

Last processing stage reported : checking silicon configuration
Failure diagnostics :
error {{} {The Power Supply configuration at start time is not available, comparison with DAQ list is not possible &lt;/b&gt;} {&lt;br&gt;&lt;br&gt;&lt;b&gt;Check the GUI spy file ! ! &lt;/b&gt;&lt;/font&gt;} Success}
Exiting.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Sat Mar 23 21:35:28 2002 -->
<pre>The problem with turning Silicon to STANDBy was caused by the 
corrupted input files. Powerset.dat was almost empty (had  only 
SB0W3 in it), thats why global buttons were not working. 
Eventually it turned out, that CAENvolts.dat was generated with 
wrong format ( didn't have third column for DVDD current).  
Therefore the GUI was crashing during the restart. 
 
In addition to this , b0dap42 was very overloaded and it took 
long time to open xterms and etc. The java was very slow too, I 
had to kill root ( IMON?) to make things working.</pre>
<!-- Author: Andrew -->
<!-- Comment: Sat Mar 23 22;16;16 comment by...Eva -->
<pre>Well, there is a little more to the story.  The ace has more
details in the &lt;a href=
'/cgi/elog/elog.pl?nb=2002&action=view&page=246&frame=2&anchor=21:50:32'&gt; general elog.&lt;/a&gt;
&lt;br&gt;
&lt;br&gt;
The bottom line is that there were many things going wrong at 
the same time.  The GUI PC was hanging due to the two 
root.exe processes that were running 
(plus svxinter needed to be restarted by Andrew).  
Perhaps this caused the cardEditor (which is java based) to spit out files with 
missing pieces.  For the record, the initial CAENvolts.dat 
file was fine.  The powerset.dat file was practically empty. 
I belive this file was created by Jason yesterday and I 
believe he used the traceSilicon function.  
This shouldn't make a difference, in principle.
Then upon creating a new  powerset.dat file the 
CAENvolts.dat file was missing the third DVDD currents 
column but poweset.dat was fine.  Hmmm....
The third time was a charm.
I really don't have a good explanation for all of this.  
I will look into it further.  Good thing I was here! </pre>

<!-- Comment: Sat Mar 23 22;18;39 comment by...Eva -->
Sorry. Here is the entry from the <a href='/cgi/elog/elog.pl?nb=2002&action=copyentry&page=246&time=21:50:32'> ace. </a>.

<!-- Comment: Sat Mar 23 22;25;19 comment by...Eva -->
Just to be clear, the reason CAENvolts.dat was regenerated along
with powerset.dat is that they both get generated by the same
script at the same time.  This is how it is done now using 
hdwdb (cardEditor or traceSilicon).  Just wanted to make sure
that this was clear.

<!-- Comment: Sat Mar 23 23;15;04 comment by...Eva -->
<pre>I did an ls -l on the caenvoltfiles directory
(/cdf/code-common/cdfonline/caencontrol/devel/caenvoltsfiles/)
and the bad CAENvolts.dat file is listed like this:
-rw-r--r--   1 bishai   cdf          7567 Apr  4  2001 CAENvolts_03232002_0852PM.dat

It was created today at 8:52pm and yet shows up as being 
created April 4 2001 by Mary!  Also, there is a lot more missing 
from this file than just the 3rd column of the DVDD currents.


</pre>

<!-- Date: Sun Mar 24 03:30:39 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 120 finished successfully.

Job info
--------
Calibration type : standard
DPS-off run      : 141533
DPS-on run       : 141529
Requested by     : Igor
Submitted        : 2002-03-23 18:34:53
Completed        : 2002-03-24 01:30:00
Status           : SUCCESS
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Sun Mar 24 05:39:58 2002 -->
<pre>Called about 4:00 am. 
Reason: b0fib02 and b0fib04 are not responding to any ACE's  
request (ping etc...) 
According to the ACEs they tried to reboot/reset these 2 crates  
without any success. 
 
I called Lester and he told me to do : 
reste_crate b0fib02/4 
It worked. 
The reason why it DID NOT work for the ACEs is that they were  
doing it from b0dau... machines. 
From there it does NOT work while from any b0dap... it works OK. 
Problem solved they are now taking data. 
 A little more than 1 hour was wasted for this reason. 
I'm not entering a incident report because the title should be  
something like "BAD ACE". 
 
Have a nice w-e.</pre>
<!-- Author: Gino -->


<!-- Date: Sun Mar 24 05:45:27 2002 -->
<pre>IB3W0L4 is reported OFF and has DVDD bigger than 2/5 V. 
 
This problem has been already well documented in the past. 
 (Wed Mar 13 13:59:03)  
This power supply is not yet connected to the detector. 
It should be swapped in the next access. 
 
I told the ACES to ignore it. 
 
If they call the expert for this reason the expert should  
feel free to ignore the message. 
</pre>
<!-- Author: Gino -->

<!-- Date: Sun Mar 24 11:38:14 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 122
Calibration type  : standard
Run period tag    : Mar_2002
DPS-off run       : 141580
DPS-on run        : 141579
Requested by      : Dmitri,Henri
Main process id   : 3194870
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Sun Mar 24 15:58:57 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W4 All 
<li>problem n: 352 
<li>Action: Incident
<li>entered by: bolla 
<li>description is: When turning SIlicon from STDBY to ON
this wedge (SB1W4) stayed at STDBY.
Powerset.dat and CAENvolts.dat seems fine to me.
 </ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Mar 24 18:11:26 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 122 finished successfully.

Job info
--------
Calibration type : standard
DPS-off run      : 141580
DPS-on run       : 141579
Requested by     : Dmitri,Henri
Submitted        : 2002-03-24 09:37:49
Completed        : 2002-03-24 16:10:38
Status           : SUCCESS
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->


<!-- Date: Mon Mar 25 03:25:30 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 123
Calibration type  : standard
Run period tag    : Mar_2002
DPS-off run       : 141600
DPS-on run        : 141599
Requested by      : Dmitry Litvintsev
Main process id   : 5148742
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->



<!-- Date: Mon Mar 25 07:28:58 2002 -->
There was some <a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=250&frame=2&anchor=07:18:10'> 
serious FIB/run control weirdness</a> at the beginning of store 
1126.  What makes FIBs fail the "ACTIVATE" transition?
<!-- Author: Andy H. -->