<!-- Title: 10:33:13  Mon May  8 2006 -->
<!-- Crewchief: The Silis !!! -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Week 11 of the shutdown 
 
Santa Barbara, here we come !!!</pre>


<!-- Date: Mon May 8 10:33:31 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>CAEN 5V Enables ON</pre></td></tr></td></table>
<!-- Author: Ankush & Jen -->
<!-- Comment: Mon May  8 10;41;35 comment by...Ankush & Jen -->
<h3>Trying to reproduce VBias Undervoltage trip of f502</h3>

<p>During Friday&#39s COMSICs test, f50w tripped again on VBias undervoltage when going from OFF to STANDBY.  Jen and I tried to reproduce this by first turning ON f502...no problems there. Then we turned ON e30 which is their neighbouring CAEN PS...no problems there.  Then we turned on ISL Bulhead 5 (& ISL BH4 by accident)....no problems there...</p>

<p>So we failed to reproduce the trip...overalll very wierd.</p>

<p>After Santa Barbara I intend to do more COSMICs.  If in turning on the detector f502 trips again, we&#39ll go in for an immediate access to debug this sucker.</p>

<!-- Comment: Mon May  8 10;48;08 comment by...Ankush & Jen -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>CAEN 5V Enables OFF</pre></td></tr></td></table>


<!-- Date: Mon May 8 10:51:40 2006 -->
<a href="http://dictionary.reference.com/search?q=rota"> 
<h3>Rota</h3> 
</a> 
 
 
<pre> 
   1. Chiefly British. A roll call or roster of names. 
   2. Chiefly British. A round or rotation of duties. 
   3. Rota Roman Catholic Church. A tribunal of prelates that serves as an ecclesiastical court. 
</pre> 
 
<p>Apologies to the North Americans...I didn&#39t realised it was an <em>English</em> word.</p>  
<!-- Author: Ankush -->
<!-- Comment: Tue May  9 15;31;23 comment by...Jennifer :-) -->
<pre>Very nice.</pre>
<!-- Date: Mon May 8 11:57:58 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W0L0 
<li>problem n: 1019 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Bit3 low error re-appeared again in recent cosmics runs after detector being OFF and warm for during past two months. The error rate though is lower than before shutdown. What is also weird is that this bit3 problem only happens with channels 2b (->23) & 6b (->63) only. Need to try SVXDAQ again followed by fiber swap etc. (if error is reproducible).  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon May 8 12:31:33 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W1L2 
<li>problem n: 1586 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Classic bit4 low problem is back in recent cosmics runs. We need to try SVXDAQ and fiber swaps again. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon May 8 12:44:17 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W2L0 
<li>problem n: 1548 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Bit0 low 100% in recent cosmic runs. Need SVXDAQ study followed by fiber swap and light level measurement. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B2W2&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon May 8 13:00:29 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W1L2 
<li>problem n: 1635 
<li>Status: needs_observation
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: No CAP_ID problems with chip 85 in cosmics and D-mode. I change it to need_observation. We have to look on this ladder in SVXDAQ again when detector is in normal state and check on it during first week of data taking before declaring it fixed.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon May 8 13:04:38 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W1L2 
<li>problem n: 2 
<li>Status: needs_work
<li>Type: AVDD2
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: No data after chip a4 in recent d-mode and cosmics runs. So it looks like AVDD2 is back again. We need to check settings in HWDB and test this ladder in SVXDAQ. It's possible we'll need to chop chip chain again. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon May 8 13:11:15 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W11L2 
<li>problem n: 1588 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: This ladder continued to give d0 drop read out in recent cosmics runs with ~100% rate. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W11&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon May 8 14:03:12 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W10L4 
<li>problem n: 603 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: According to recent cosmic runs, it's not only chip88 which gives wrong CAP_ID, but also first chip ID and CAP_ID are incorrect (e.i, chip 8d is read as 8f). CAP_ID for first chips seems to be always 3f. This ladder needs quiet time studies.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W10&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon May 8 14:13:33 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W8L0 
<li>problem n: 1642 
<li>Status: needs_observation
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: No CAP_ID errors in recent cosmic runs. Need to continue observations for about one week after we resume data taking before declaring it fixed. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W8&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon May 8 14:15:13 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W8L0 
<li>problem n: 1497 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Bit1 low is back in recent cosmic runs with rate ~30%. Need to continue observations and run it with SVXDAQ. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W8&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon May 8 14:19:55 2006 -->
<br> 
FCC test stand is working again. The fndaut server's 
partitions have been reorganized, both MVME cpus should boot fine. Let me know if you find any problems.
<!-- Author: Sebastian -->

<!-- Date: Mon May 8 14:21:05 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W8L2 
<li>problem n: 1394 
<li>Status: needs_observation
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: No CAP_ID problems since beginning of shutdown. Need to continue observations after we resume data taking.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W8&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon May 8 14:27:37 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W1L4 
<li>problem n: 1521 
<li>Status: unfixable
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: CAP_ID problem didn't show up in recent cosmic runs. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W1&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon May 8 14:32:11 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W11L4 
<li>problem n: 1381 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Wrong CAP_ID from chip a3 is back in recent cosmics.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W11&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon May 8 14:38:23 2006 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 435
Calibration type  : standard
Run period tag    : May_2006
DPS-off run       : 215519
DPS-on run        : 215520
Requested by      : Jason Nielsen
Main process id   : 22160
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->


<!-- Date: Mon May 8 19:00:10 2006 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 436
Calibration type  : standard
Run period tag    : May_2006
DPS-off run       : 215519
DPS-on run        : 215520
Requested by      : Jason Nielsen
Main process id   : 7048
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->


<!-- Date: Tue May 9 08:31:16 2006 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 437
Calibration type  : standard
Run period tag    : May_2006
DPS-off run       : 215519
DPS-on run        : 215520
Requested by      : Jason Nielsen
Main process id   : 31237
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->


<!-- Date: Tue May 9 08:34:05 2006 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 438
Calibration type  : standard
Run period tag    : May_2006
DPS-off run       : 215519
DPS-on run        : 215520
Requested by      : Jason Nielsen
Main process id   : 1952
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->
<!-- Comment: Tue May  9 08;37;41 comment by...Jason -->
There was some flawed logic: the scripts tried to include the beam status in the e-log error message before that beam status was set.  I have fixed that, and now you would see a message like this:
<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 438 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 215519
DPS-on run       : 215520
Requested by     : Jason Nielsen
Submitted        : 2006-05-09 08:33:59
Completed        : 2006-05-09 08:34:26
Status           : FAILURE

Last processing stage reported : checking silicon configuration
Failure diagnostics :
Inconsistent dps mode for run 215519. Check your argument order.
Exiting.
</pre>


<!-- Date: Tue May 9 08:38:29 2006 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 439
Calibration type  : standard
Run period tag    : May_2006
DPS-off run       : 215520
DPS-on run        : 215519
Requested by      : Jason Nielsen
Main process id   : 5337
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->



<!-- Date: Tue May 9 09:42:57 2006 -->
<h4>Silicon Cafe cleaned up </h4> 
<p> 
Since we are all going for Santa Barbara, we gave the machine and the cups a good scrub. Since we want to share this knowledge, we'll have special Espresso machine cleaning training after the workshop. 
</p>
<!-- Author: The baristas -->

<!-- Date: Tue May 9 13:28:05 2006 -->
<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 439 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 215520
DPS-on run       : 215519
Requested by     : Jason Nielsen
Submitted        : 2006-05-09 08:38:23
Completed        : 2006-05-09 13:27:36
Status           : FAILURE

Last processing stage reported : updating ped tables with fibkill channels
Failure diagnostics :
child process exited abnormally
</pre>
<!-- Author: D-mode script  -->



<!-- Date: Tue May 9 13:32:47 2006 -->
<h4>Update on chiller calibrations</h4> 
I have spoken with Bill Noe about the recent problems we observed with the <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=299&frame=2&anchor=13:09:43'> 
calibration of the chiller temperature sensors</a>. He essentially said that miscalibrations of one or the other reading are quite common in control systems. As long as the system delivers what it is expected to deliver (in our case: the chiller can reach the temperature we want) and we have something to calibrate against (in our case: the redundant system of all the other temperature sensors), we should just adjust the calibration. This is exactly what we did so far.
<!-- Author: Ulrich -->


<!-- Date: Tue May 9 14:42:37 2006 -->
<h3>Silicon PLC back on UPS Power</h3> 
Last Wednesday, the UPS batteries were <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=299&frame=2&anchor=10:07:39'> 
disconnected in order to drain and replace them</a>. This transition was smooth for all silicon systems on UPS power. The "only" problem was that we were not backed up by a UPS in case of a power glitch. While the batteries were drained, one of them exploded. Therefore it took almost a week to get the new batteries up and running. <p> 
Today, the new batteries were connected, and the system is back on UPS power now. Again, the transition was smooth for us. Just to be sure, I compared the running PLC program to the official version on harddisk, and they are identical. Good.
<!-- Author: Ulrich -->



<!-- Date: Wed May 10 08:19:44 2006 -->
<h3>Fire Alarm?</h3> 
 
<p>When I arrived this morning, everyone was standing in the parking lot and the Fermi Fire Trucks were outside.  A fire alarm on the first floor counting room had gone off but there was no sign of any fire/smoke.  So this could have been a false alarm.  The Fire Techs will look over the alarm today.</p> 
 
<p><em>were Level 3 boys running their burn-in tests ;-)</em></p> 
<!-- Author: Ankush -->


<!-- Date: Sun May 14 22:09:43 2006 -->
<h3>We are back</h3> 
 
<p>The crew have returned from Santa Barbara....it was a nice place</p>
<!-- Author: The Silis -->


<!-- Date: Mon May 15 11:47:58 2006 -->
<h3>Summary of Week 11</h3> 
 
<h4>Trying to investigate VBias undervoltage trip on f502</h4> 
 
<p>The last 2 times the detector was turned on, f502 tripped on VBias 
undervoltage. However when the wedge, bulkeads or neighbouring PS are turned on, 
f502 is fine.   This will need more investigating.</p> 
 
<h4>DMode calibrations</h4> 
 
<p>Jason did some work to get the DMode calibrations started and they all 
completed.</p> 
 
<h4>Chiller Calibrations</h4> 
 
<p>There is an offset between the measured detector temperature and the chiller 
temperature.  The chiller temperature will be corrrected when the detector is 
cooled.</p> 
 
 
<h4>Review of problem ladders from last week&#39s COSMICS</h4> 
 
<p>Sasha reviewed the Bit-Reporter to find problem ladders from the COSMIS 
running.</p> 
 
<b>Problem Ladders</b> <br> 
<ul> 
<li>f000: bit 3 problem returned but only appears for channels 2b (-->23) and 6b 
(-->63) </li> 
<li>f012: "Classic" bit 4 low problem has returned.</li> 
<li>f220: Bit 0 low.</li> 
<li>e012: No data after chip a4. May need to re-chop chip chain.</li> 
<li>e0b2: Continues to give d0 drop read out.</li> 
<li>e1a4: Chip 88 gives CAP-ID. Also first chip gives incorrect chip ID and 
CAP-ID.</li> 
<li>e280: Bit 1 low at 30% rate.</li> 
<li>e4b3: Wrong CAP-ID from chip a3.</li> 
</ul> 
 
<b>"Fixed" Ladders</b> <br> 
<ul> 
<li>e012: CAP-ID problems for chip 85 has gone.</li> 
<li>e280: No CAP-ID errors.</li> 
<li>e282: No CAP-ID errors.</li> 
<li>e414: No CAP-ID errors.</li> 
</ul> 
 
<h4>Misc</h4> 
 
<p>Silicon PLX was put back onto UPS power.</p> 
 
<p>The Santa Barbara workshop took place this week !!!<p>
<!-- Author: Ankush -->