<!-- Title: 10:17:00  Mon Apr 21 2008 -->
<!-- Crewchief: SashaS (MPC, SPL) -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
Keep Silicon Safe and Running. Continue SAR debugging.




<!-- Date: Mon Apr 21 15:43:11 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12485&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12485  width='300' align='top'></a></td><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12486&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12486  width='368' align='top'></a></td><td>Store 6069: Init. Lumi 248 1/ub/s, Lostp jumped at the beginning from ~20 kHz up to 60 kHz. The MCR ajusted tunes and losses were brought to ~25 kHz. At this point I decided to put Silicon in. After about 8 min. MCR changed tunes again and lossed dropped to ~17 kHz. TevMon went into alarm due to Lostp RMS. Silicon was automatically turned to STBY. After TevMon cleared in few minutes, I re-included Silicon back ON. Inst. Lumi at this point was 218 1/ub/s</td></tr></table>
<!-- Author: SashaS -->


<!-- Date: Mon Apr 21 20:44:25 2008 -->
I have got page because of large number (7) pinkies in SVX bias current. It all happened right after pre-scale change in L1_TWO_TRK2_B_HAD_UPS trigger at the luminosity 110 1/ub/s. Told to SciCo to set the these cells to Ignore. I will re-adjust Imon limits when I will come to the control room.
<!-- Author: SashaS -->


<!-- Date: Mon Apr 21 21:39:15 2008 -->
I have got another page because of brief electron lens trip and TevMon went into warning state for a moment. Lens has been recovered quickly by MCR and TevMon cleared. CDF did not interrupt data taking on this occasion.
<!-- Author: SashaS -->
<!-- Comment: Mon Apr 21 21;42;16 comment by...SashaS -->
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2008&action=view&page=336&frame=2&anchor=21:19:21.801'>Here</a> is a plot of electron lens trip in the CDF e-log


<!-- Date: Tue Apr 22 06:38:35 2008 -->
Came for short setup. While doing <i>COLDSTART</i> I have got the following message: 
<pre> 
(MLW) b0fib00:Messenger:Apr 22, 2008 06:35:07 AM->Fib Slot 10 Corrupt MSRAM: (Calc minus Expect) =  0xffffff80(RC)   6:35:07 Config -> READY 
</pre> 
After <i>ABORT</i> and 2nd <i>CONFIG</i> everything is ok.
<!-- Author: SashaS -->


<!-- Date: Tue Apr 22 07:20:05 2008 -->
There were <i>PS-LOGGING</i> errors when Ace put Silicon to STBY at the end of the store 6069. Wedges 4 and 5 of L00 B1 had caenet_write errors in process of turning to STBY. It looks like these wedges (also LB1W0 - all 3 wedges are from PS crate 15) were not properly turned to STBY and SAR decided to recover them. SAR successfully turned these wedges OFF and then to STBY.
<!-- Author: SashaS -->


<!-- Date: Tue Apr 22 07:26:36 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12487&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12487  width='300' align='top'></a></td><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12488&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12488  width='368' align='top'></a></td><td>Store 6070: Init. lumi ~240 1/ub/s, Lostp increased from 3 kHz to 13 kHz at the beginning, then flattened and begun to decrease - a very classical behavior. Put Silicon in.</td></tr></table>
<!-- Author: SashaS -->


<!-- Date: Tue Apr 22 21:05:19 2008 -->
I have got page because Dvdd current in the SVX B5W2L0 ladder dropped to 0 in Imon. I asked CO to restart SVXmon and checked SVXmon/ADCmon plots for this ladder. Data look fine, so it is just a corrupted readout from power supply. I will hockerize CAEN create 10 in between stores.
<!-- Author: SashaS -->
<!-- Comment: Tue Apr 22 21;06;31 comment by...SashaS -->
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2008&action=view&page=339&frame=2&anchor=20:24:25.706'>Here</a> is the Imon plot posted in the CDF e-log.

<!-- Comment: Wed Apr 23 00;53;00 comment by...SashaS -->
I have hockerized CAEN crate 10. SAR recovered all SVX and ISL ladders successfully. Dvdd current in ladder SB5W2L0 is recovered back to nominal.


<!-- Date: Wed Apr 23 01:22:30 2008 -->
Store 6071 quenched in F11U house right after scraping completion. D0 lumi. was ~210 1/ub/s. Lostp looked fine, increasing from 4 kHz to 8 kHz following the usual trend. I have done COLDSTART and it came up just fine. Ace is about to post usual post-quench plots in main e-log.
<!-- Author: SashaS -->


<!-- Date: Wed Apr 23 08:33:22 2008 -->
There was an audio message "Silicon alarm" this  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2008&action=view&page=340&frame=2&anchor=05:10:56.947'>morning</a> 
 but ace did not found any problem in iFix/PSgui/SAR.
<!-- Author: SashaS -->


<!-- Date: Wed Apr 23 13:32:26 2008 -->
North Wall has been moved for access and SVX ladder B3W10L4 tripped on Dvdd ovc, as usual. I have silenced iFix alarms for SVX PS-CAEN-OFF and PS-TRIP. SAR disabled auto-recovery itself after few un-successfull attempts to recover tripping ladder.
<!-- Author: SashaS -->
<!-- Comment: Wed Apr 23 14;37;10 comment by...SashaS -->
SAR had a java exception while trying to connect to HWDB when DB was down this morning. I restarted SAR and it recovered SB3W10L4, after the north wall has been moved in place.


<!-- Date: Wed Apr 23 20:48:18 2008 -->
There was SVX B0W3L3 Dvdd pinky this <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2008&action=view&page=341&frame=2&anchor=14:25:11.306'>afternoon</a>. Since COLDSTART could not fix the problem, I have tried power-cycling ladder, wedge and then hockerized the CAEN crate 2. Hockerization fixed this pinky.
<!-- Author: SashaS -->

<!-- Date: Wed Apr 23 22:26:15 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W0L2 
<li>problem n: 2574 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Increasing Bias High Limit<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>28.8283</td><td>28.8283</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>100</td><td>120</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Apr 23 22:31:07 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W2L4 
<li>problem n: 2077 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Increasing Bias Limits<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>101</td><td>101</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>125</td><td>145</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W2&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Apr 23 22:35:10 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W10L1 
<li>problem n: 2127 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Increasing Bias Limits<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>100</td><td>100</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>125</td><td>150</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W10&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Apr 23 22:40:15 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W1L3 
<li>problem n: 2575 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Changing Bias Limits<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>21.0747</td><td>21.0747</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>100</td><td>120</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W1&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Apr 23 22:42:08 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W11L3 
<li>problem n: 2576 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Increasing Bias Limits<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>26.9971</td><td>26.9971</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>100</td><td>120</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W11&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Apr 23 22:44:42 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12489&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12489  width='368' align='top'></a></td><td>Store 6076: Init Lumi 127 1/ub/s; Lostp increased from 400 Hz to 800 Hz and flattened. Put Silicon in.</td></tr></table>
<!-- Author: SashaS -->
<!-- Comment: Thu Apr 24 00;13;20 comment by...SashaS -->
Quench in about midnight at D0Q5 & D0Q6
<!-- Date: Wed Apr 23 22:48:20 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W0L4 
<li>problem n: 1988 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Increasing Bias Limits<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>120.446</td><td>120.446</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>200</td><td>250</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Apr 23 22:51:48 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W2L0 
<li>problem n: 1870 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Increasing Bias Limits<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>125</td><td>125</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>170</td><td>200</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W2&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Apr 23 22:54:32 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W5L4 
<li>problem n: 2072 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Increasing Bias Limits<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>100</td><td>100</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>145</td><td>165</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Apr 23 22:56:20 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W1L1 
<li>problem n: 1762 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Increasing Bias Limits<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>80</td><td>80</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>200</td><td>240</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Apr 23 22:58:01 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W2L1 
<li>problem n: 1823 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Increasing Bias Limits<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>100</td><td>100</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>170</td><td>200</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Apr 23 23:02:09 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W8L4 
<li>problem n: 2577 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Increasing Bias Limits<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>38.5795</td><td>38.5795</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>100</td><td>120</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W8&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Apr 23 23:12:08 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W10L4 
<li>problem n: 2578 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Increasing Bias Limits<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>128.937</td><td>128.937</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>180</td><td>210</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W10&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Apr 23 23:16:06 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W6L3 
<li>problem n: 2579 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Increasing Bias Limits<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>34.5412</td><td>34.5412</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>100</td><td>120</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W6&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Apr 23 23:20:46 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W9L4 
<li>problem n: 2580 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Increasing Bias Limits<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>140</td><td>140</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>165</td><td>185</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W9&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Apr 23 23:24:54 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W10L1 
<li>problem n: 1943 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Increasing Bias Limits<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>120</td><td>120</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>150</td><td>180</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W10&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Apr 23 23:33:11 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W2L1 
<li>problem n: 2427 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Increasing Bias1 Limits<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>150</td><td>150</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>205</td><td>235</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Apr 23 23:35:15 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W0L3 
<li>problem n: 1855 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Increasing Bias1 Limits<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>125</td><td>125</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>150</td><td>180</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B0W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Thu Apr 24 10:35:13 2008 -->
<pre>Ran SVXDaq to diagnose f533 errors... see Mark's monitoring report from last week. The ladder returns data but also has bit errors for  many chips in the channel. Can be bad RX/TX or according to the history port card temperature changes. In principle we could do fiber swap to determine on which side is the problem... however even if its on DAQ side... maybe its better to save good RXs (we don't have so many) for more dramatic cases.</pre>
<!-- Author: Sergo -->


<!-- Date: Thu Apr 24 16:21:30 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12490&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12490  width='368' align='top'></a></td><td>Store 6080: Init. Lumi ~144 1/ub/s; Lostp ~1 kHz. Put Silicon in.</td></tr></table>
<!-- Author: SashaS -->


<!-- Date: Thu Apr 24 18:28:20 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12491&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12491  width='300' align='top'></a></td><td>Looks as if ISL CCE1 temperatures, which we had noticed were higher than the other cooling loop's temperatures, were high starting with the Fall 2007 shutdown.</td></tr></table>
<!-- Author: Tom -->


<!-- Date: Thu Apr 24 18:31:36 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12492&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12492  width='300' align='top'></a></td><td>And CCW2's temperature, which had caused us some concern of late, had gotten stuck in a non-cooling state after the fall shutdown, but had started cooling again after October 31's failure of the ISL chiller's thermocouple (we had switched to the spare and back, and re-establishing flows probably cleared that bubble out).</td></tr></table>
<!-- Author: Tom -->


<!-- Date: Thu Apr 24 18:32:46 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12493&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12493  width='300' align='top'></a></td><td>ISL CCW1's temperature has had a line steadily warm after the fall shutdown as well.</td></tr></table>
<!-- Author: Tom -->


<!-- Date: Thu Apr 24 22:51:31 2008 -->
I have got page because fib07 turned red in RC. As a sequence of the fib crate  problem, L00 and ISL ladders, corresponding to this crate turned pink in Imon on Avdd currents. Shang-Yuu did "manual" reboot and shepherd of the crate.  That fixed the problem.
<!-- Author: SashaS -->


<!-- Date: Fri Apr 25 08:56:17 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12494&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12494  width='368' align='top'></a></td><td>Store 6082: Init Lumi ~210 1/ub/s; Lostp increased from 3 kHz to ~10 kHz and flattened. Put Silicon in.</td></tr></table>
<!-- Author: SashaS -->


<!-- Date: Fri Apr 25 09:42:27 2008 -->
The was a block of red ladders in SVXmon Cell ID plot: all ladders in ISL B3W0 and B3W1 corresponding to fib board in fib05 slot 12 and vrb_59. Automatic HRR fixed the problem.
<!-- Author: SashaS -->


<!-- Date: Fri Apr 25 17:29:34 2008 -->
<h3>Ghost Silicon Alarm</h3> 
 
<p>iFIX just voiced "Silicon Alarm".  However no silicon alarm was observed.....<i>spooky</i></p>
<!-- Author: Ankush  -->


<!-- Date: Fri Apr 25 22:52:00 2008 -->
<h3><font color=pink>Pinky</font> for 2V DOIM for SB1W8</h3> 
 
<p>My first pinky of the shift.  No big deal. Just went over threshold.  Having said that, it is curious for a DOIM to give a pinky....I will investigate further.</p>
<!-- Author: Ankush -->
<!-- Comment: Fri Apr 25 23;21;25 comment by...Ankush  -->
<h3>IMON Java out of memory error and drooping DOIM</h3>

<p>While investigating the pinky and trying to save the plots, IMON gave an out of memory error.</p>


<p>As for investigating the DOIM lines for SB1W8 and SB1W9, the 2V and 5V DOIM lines have been drooping. This is odd as they should flat.  I'll post the plots in the elog once IMON has collected enough points for a decent history plot.</p>

<p>After consulting with Sasha, I have set the DOIMs for SB1W8 and SB1W9 to IGNORE to keep the owl SciCo happy.</p>


<!-- Date: Sat Apr 26 01:16:35 2008 -->
There was spontaneous switch-off of PS crate 1. SAR failed to recover. It looks like RC was not in HALT state but in ACTIVE with trigger inhibit set. Ace recovered manually, turning ON wedge by wedge, but did not send config to chips. There are some Avdd pinkies in the wedges corresponding to PS crate 1, because readout chips were not properly configured.
<!-- Author: SashaS -->
<!-- Comment: Sat Apr 26 01;38;59 comment by...SashaS -->
Yes, I have just checked SAR logfiles: SAR did not even try to recover because fib0 was not in IDLE, READY, or HALT state. I think that SAR would recover just fine had ace not forget to put RC to HALT. 


<!-- Date: Sat Apr 26 03:09:33 2008 -->
Store 6083 quenched with Diamond integrated dose alarm and Diamond abort alarm
<!-- Author: SashaS -->
<!-- Comment: Sat Apr 26 03;16;43 comment by...SashaS -->
In the rad. system display pannel status lights: BLM 1 is on, all Diamon and Flam. gas are off.


<!-- Comment: Sat Apr 26 03;56;04 comment by...SashaS -->
COLDSTART is fine
<!-- Comment: Sat Apr 26 08;02;44 comment by...SashaS -->
I have powered the whole Silicon detector ON. ISL B5W5L1 tripped and recovered by SAR. Everything is fine. Turning Silicon to STBY.
<!-- Date: Sat Apr 26 03:54:55 2008 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12495&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12495' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12496&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12496' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12497&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12497' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12498&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12498' width='300'></a></center>
<!-- Author: SashaS -->
<!-- Comment: Sat Apr 26 03;55;27 comment by...SashaS -->
Diamond plots for quench



<!-- Date: Sat Apr 26 04:00:49 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12499&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12499  width='300' align='top'></a></td><td>SVRAD plots for the quench</td></tr></table>
<!-- Author: SashaS -->




<!-- Date: Sat Apr 26 07:02:05 2008 -->
SVX iFix warning: TE-JV-BHW1 (BHW1 Vacuum Jacket Temp) is at low limit (15 C). The Alarm limit is at 13 C. I am trying to make history plot for this variable, but somehow iFix does not work properly at vnode2: it only allows to open SVX/ISL/L00 Alarms windows and all other windows are unavailable: clicking on any other buttons in Proc. Syst. Alarms window or clicking on the CDF logo does not open anything.
<!-- Author: Sasha -->
<!-- Comment: Sat Apr 26 07;48;58 comment by...SashaS -->
After talking to Tom and Jennifer: since there is no way to control this temperature, we will keep eye on it and will change iFix limit later (on Monday?)


<!-- Comment: Sat Apr 26 12;21;05 comment by...SashaS -->
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2008&action=view&page=350&frame=2&anchor=08:26:29.191'>Here</a> is the CDF hall temperatures since yesterday. They are changed quite a lot. This might be the reason for VJ temperature(s) dropped. TE-JV-BHW1 iFix warning cleared at 8:55 this morning after Steve from Cryo had restored HVAC settings at about 8:30.

<!-- Comment: Sat Apr 26 18;06;44 comment by...SashaS -->
Now as Collision Hall temperatures back to "nominal" values all West VJ temperatures are also back to ~20C. It looks like these VJ temperatures just trace Collision Hall temperatures.


<!-- Comment: Sun Apr 27 01;23;57 comment by...Ulrich -->
These are the temperature at the vacuum jackets around the cooling line when they go through the 30-degree crack. So unless the cooling line breaks and the vacuum jacket assumes the coolant temperature, you expect it to follow the ambient temperature. The last time they went into warning was also when people tried different HVAC settings for the shutdown.
<!-- Date: Sat Apr 26 18:35:32 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12500&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12500  width='368' align='top'></a></td><td>Store 6090: Init Lumi ~165 1/ub/s; Lostp increased from  
~150 Hz to ~700 Hz and flattened. Put Silicon in</td></tr></table>
<!-- Author: SashaS -->


<!-- Date: Sat Apr 26 19:14:52 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12502&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12502  width='300' align='top'></a></td><td>History plot for VJ temperatures</td></tr></table>
<!-- Author: SashaS -->
<!-- Comment: Sat Apr 26 19;20;48 comment by...SashaS -->
Compare to the Collision Hall temperatures, posted in the main CDF e-log <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2008&action=view&page=351&frame=2&anchor=17:36:54.106'>
here</a>: both sets of temperatures are well correlated: dropped on Friday at about 8am and started recovering on Saturday at 8:30am


<!-- Date: Sun Apr 27 00:06:27 2008 -->
<h2>SVX B5W2 PS problem</h2> 
 
We have problem with the SVX power supply SB5W2 in CAEN crate 10. Initially, there was software protection trip in Avdd current in layer 4 which SAR failed to recover, because varuois ladders in this PS continued to trip. I did few hockerization to crate 10 and then ask Cryo to power-cycle the NET rack, where the CAEN crate located. Nothing worked. PS continued tripping. At this point I realized that behavior of this PS even more weird: 1) when turning PS off from PSgui, random channels continued to switching from OFF to STBY and back to OFF by themselves and I needed to hockerize crate in order to stop this. 2) After hockerization, while all channels were OFF, PS continuosly generated random OVC trips in random channels (Avdd/Dvdd/Bias/Doim/Dterm) over and over again. 
<p>
Since I already spent too much time debugging this problem, I decided to exclude wedge SB5W2 from HWDB and resume taking data w/ Silicon. The odd thing is that PS continued to generate trips and set SVX trigger inhibits in iFix Silicon Status and set off SVX PS-TRIP alarms in iFix SVX ALARMS. I have modified IgnoredWedges.txt and re-started psmon.exe and alarms.exe on SVXIICON, but it did not help.
<p>
So it looks like the only way to take data with Silicon right now is to ignore SVX HV inhibit.
<!-- Author: SashaS -->
<p>
<!-- Comment: Sun Apr 27 01;10;36 comment by...SashaS -->
Ok, we are now taking data w/ Silicon and wedge SB5W2 excluded. SVX HV and SVX TRIP05 ignored.
<!-- Comment: Sun Apr 27 06;25;56 comment by...SashaS -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12503&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12503  width='368' align='top'></a></td><td>SVTspymon plot with missed wedge SB5W2</td></tr></table>

<p>
<!-- Comment: Sun Apr 27 07;42;00 comment by...SashaS -->
I have modified CaenVme library which is svxinter counterpart of PSgui. PSgui use this library to talk to CAEN crates. getSiliconInfo function of CaenVme library (located in caentalk.c file) reads status of all PS in all CAEN crates and broadcast SS "INFO" message. The modifications to getSiliconInfo function are the following: I have replaced line
<pre>
          gStatusW[ch+det_pointer(detector,ps_n)] =      GR_ps_info[cr_n][gr_ch].statusWord;
</pre>
with the the code
<pre>
          if ( cr_n == 10 && bd == 3 ) {
	    gStatusW[ch+det_pointer(detector,ps_n)] = 1; /* Channel Present */
	  } else {
	    gStatusW[ch+det_pointer(detector,ps_n)] =  GR_ps_info[cr_n][gr_ch].statusWord;
	  }
</pre>
This modification essentially tells PSgui to ignore status of board 3 in CAEN crate 10
<p>
I reloaded new version of library to svxinter:
<ul>
<li> in svxii account
<pre>
cd /cdf/onln/data/svxii/test
cp /cdf/onln/home/ais/projects/test/caencontrol_v5b/v5b/server/lib/VxWorks-5.3/ppc/CaenVme CaenVme
</pre>
<li> exit PSGui and Imon
<li> in svxinter
<pre>
unld("CaenVme")
ld < /cdf/onln/data/svxii/test/CaenVme
</pre>
<li> restarted PSgui and Imon
</ul>

Now iFix is all green: Silicon Inhibit Status and PS-TRIP in SVX ALARMS cleared. We finally stop getting "SVX ALARM!" voice message every minute! In DAQ trigger inhibit control SVX HV inhibit is enabled. SVX05 TRIP inhibit is still set and can not be enabled. I need to find the way how to fix this problem as well.
<!-- Comment: Sun Apr 27 09;20;06 comment by...SashaS -->
I had problem putting Silicon to STBY at the end of the store. Ace clicked Silicon to STBY button in iFix, but I did not see usual messages in svxinter, like:
<pre>
com_int = 2
detector = 0, status = 2
SUN APR 27 08:14:15 2008  setPSStatus, detector = 0, ps_n = 0, status = 2
SUN APR 27 08:14:16 2008  setPSStatus, detector = 0, ps_n = 1, status = 2
SUN APR 27 08:14:17 2008  setPSStatus, detector = 0, ps_n = 2, status = 2
SUN APR 27 08:14:18 2008  setPSStatus, detector = 0, ps_n = 3, status = 2
</pre>
etc
<p>
Since it was end of store and CLC turned off, Lumi dropped to 0 and TevMon went into Alarm state. But again, I did not see usual TevMon messages in svxinter. Thinking that it might be due to the changes in CaenVme library, I decided to revert back to default version, but PSgui became unresponsive and I could not exit and had to kill it. I rebooted svxinter (which loaded default CaenVme library) and started PSgui. PSgui failed to start with the message:
<pre>
RTserver denied access.
Message: Client name </_svxinter_14819960> is not unique.WARNING: Internal validation failed, file: closed connectioipcmsg.cn , line 1314127.0.0.1Message from RTlm: :Checking in <RTclient> license.
1026Cannot connect to the RTserver.
 on request
</pre>

So it looked like some RTserver problem. I asked ace to restart RTserver (just in case) and rebooted svxinter and restarted PSgui. 2nd time it worked. After PSgui started, I noticed that all L00 and SVX B0 and B1 were in STBY (like svxinter received the very first message Silicon to STBY from iFix and executed it for L00 and part of SVX), but the rest of the Silicon was still ON. I turned Silicon to STBY from PSgui.
<p>
After Silicon was turned to STBY and SiCo reported to MCR so they could end the store, I tried to send Silicon to STBY from iFix. This time it worked and all messages to svxinter went through just fine. Since it was default CaenVme library, we got back the original problem: continuous random trips from SB5W2 set off PS-TRIP alarm in iFix SVX ALARMS and SVX HV inhibit in Silicon Inhibit Status. I reloaded new CaenVme library, restarted PSgui and again sent Silicon to STBY from iFix: it worked this time. BeamPermit also works printing out its usual messages.
<p>
So it seems that it was RTserver failure that did not allow to put Silicon to STBY from iFix in the first place. I will leave new CaenVme code running in svxinter.
<p>
<!-- Comment: Sun Apr 27 09;34;06 comment by...SashaS -->
Yesterday I have put a request for 1.5 access to replace PS in SB5W2. I have set priority for this request to URGENT. But, since we are not marking data BAD just because of wedge SB5W2 problem (we marking data BAD only if we have more than 4 bad wedges in SVX) JJ the Ops Manager downrated priority of request to HIGH. That means that MRC will not grant the access in between stores during normal operation "until there is a naturally occurring opportunity" (from RCo e-log)
<!-- Comment: Sun Apr 27 14;25;53 comment by...Satyajit -->
Sasha, your effort to suppress the inhibit alarm in the middle 
of the night is really brave/impressive! However recompiling the
lib this way is the last thing we want to attempt. I think this
should be implemented via a parameter file, whose change is 
picked up at the next reload of CaenVme. If we don't have this 
already we can ask the Duke people or someone of us to do this. The file could contain, e.g.<p>

<pre>
StartMask
SB5W2
...
EndMask

StartSuppressReport
...
EndSuppressReport
</pre>

<!-- Comment: Sun Apr 27 14;44;59 comment by...Ulrich -->
I agree with Satyajit about the code changes. But consider not asking Duke if you want something before the end of Run II...
<!-- Comment: Sun Apr 27 14;54;22 comment by...Ricardo -->
A few comments:<br>
<b>A-</b> we agreed some time ago never to mark data bad regardless of the number of wedges that are not running, and only if the data is worthless.<br>
<b>B-</b> I think this particular problem is not best dealt with at the PS-gui level, but rather at the iFix level. That is we  probably don't need to do long term modifications in the PS-gui, but in other pieces of software.
<!-- Date: Sun Apr 27 02:08:42 2008 -->
Spontaneous switch-off of CAEN ctate 7. Recovered.
<!-- Author: SashaS -->


<!-- Date: Sun Apr 27 06:24:04 2008 -->
fib07 crate stuck at about 2:40. Ace logged in to the crate and rebooted. After that crate stopped to respond to ping. Shepherded. Recovered.
<!-- Author: SashaS -->







<!-- Date: Sun Apr 27 12:13:03 2008 -->
svxinter terminal stuck. svxinter itself is running fine. Closed terminal window, opened new one and reconnected to svxinter
<!-- Author: SashaS -->
<!-- Comment: Sun Apr 27 12;41;29 comment by...SashaS -->
Just when MCR called and asked to put CLC in, svxinter decided to reboot itself. It probably correlated with RTserver restart few minutes before that


<!-- Comment: Sun Apr 27 14;31;14 comment by...SashaS -->
I have few more svxinter "auto-reboots". It seems that the way I reloaded CaenVme library interfere with BeamPermit. I killed BP before reloading CaenVme and then spawned new BP. svxinter self-rebooted few moments later. I have modified startup script for svxinter (/cdf/onln/code/cdfprod/caencontrol/v5b/examples/startup_rtlm):
<pre>

# set priority for network sessions
#envThreadPrio=200

cdfInit()
nfsAuthUnixSet("b0spool",2064,5530,0,0);
nfsMount("b0spool", "/vol/data", "/cdf/onln/data");


# Change directory to caen stuff directory
#cd "/cdf/onln/code/cdfprod/caencontrol/v5b/server/lib/VxWorks-5.3/ppc"
cd "/cdf/onln/data/svxii/test"
ld < CaenVme
i
pwd
rdate


# Uncomment below to enable the beam-permit monitor (TevMon monitor)
taskSpawn("BeamPermit", 200, 0, 20000, BeamPermit_monitor);


# Load Silicon Auto Recovery code
ld < SARCaen
</pre>
Now, when rebooted svxinter loads modified version of CaenVme library. It also loads SARCaen library needed by SAR (I loaded it manually before). PSgui and SAR run fine now. We do not have PS-TRIP SVX ALARMS (accompanied by the very annoying "SVX ALARM!" voice message every 30s) and SVX is green in the iFix Silicon Inhibit Status window. We enable SVX HV inhibit in the DAQ inhibit control gui. SVX05 TRIP inhibit is still disabled.
<!-- Comment: Sun Apr 27 14;51;51 comment by...SashaS -->
I have reverted modification of getSiliconInfo functions (located in caencontrol.c) and changed group_info function from caengrps.c to which I added the following lines of code:
<pre>
  /* temp. fix for SVX B5W2 PS problem: cr_n == 10 && bd == 3 */
  /* mask off Overcurrent (bit 12) */
  if ( cr_n == 10 ) {
    for ( i = 0; i < groups[cr_n][gr_n].num_ch; i++ ) {
      if ( groups[cr_n][gr_n].ch[i].bd == 3 ) {
	GR_ps_info[cr_n][i].statusWord &= 0xefff;
      }
    }
  }
</pre>
This code does the same, essentially masks off overcurrent bits in the PS status word for problematic power supply.

<!-- Date: Sun Apr 27 13:53:02 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12504&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12504  width='368' align='top'></a></td><td>Store 6093: Init lumi ~195 1/ub/s, Lostp increased from 400 Hz to 2.8 kHz and flattened. Put Silicon in</td></tr></table>
<!-- Author: SashaS -->







<!-- Date: Mon Apr 28 02:05:23 2008 -->
<h3> ADC Monitering Summary (Run261162-261385) </h3> 
I have checked ADCMon plots during this week from run261162 to 261385. 
<br> 
I will report the ladders which have a issue and intersting work.  
The other ladders look fine. 
<ul> 
<li> e033 : Pipeline Out of Sync error reached 98% and  
            Stuck Cell Id error also reached 98%    
            between Run261162 and Run26362. 
</ul>
<!-- Author: Takayuki -->
<!-- Comment: Mon Apr 28 07;36;01 comment by...Ricardo -->
Probably meant ... between Run261162 and Run261362. 




<!-- Date: Mon Apr 28 08:42:00 2008 -->
<h2>Summary of the week</h2> 
 
<h3>Monday, April 21, 2008</h3> 
<ul> 
 <li> <b>Store 6069:</b> Init Lumi 248 1/ub/s, Weird behavior of losses 
  <ul> 
    <li> Pinkies in SVX Bias current after L1_TWO_TRK2_B_HAD_UPS prescale change at 110 1/ub/s 
    <li> Electron lens trip - quickly recovered by MCR 
    <li> PS-LOGGING Alarm when turning Silicon to STBY at EOS 
    <ul> 
      <li> <i>caenet_write</i> error for LB1W0,W4 and W5 - recovered by SAR 
    </ul> 
  </ul> 
</ul> 
 
<h3>Tuesday, April 22, 2008</h3> 
<ul> 
  <li> <b>Store 6070:</b> Init Lumi 240 1/ub/s; Lostp changed from 3 kHz to 13 kHz and flattened; put Silicon in 
  <ul>  
    <li> Corrupted readout of Dvdd current in SVX B5W2L0 
    <li> hockerized CAEN PS crate 10 between stores 
  </ul> 
</ul> 
 
<h3>Wednesday, April 23, 2008</h3> 
<ul> 
  <li> <b>Store 6071:</b> quenched after scrapping 
  <ul> 
    <li> COLDSTART was fine 
  </ul> 
  <li> Ghost Silicon Alarm ((C) Ankush) happened few times during the week 
  <li> Updates and patches installed to DBs 
  <ul> 
    <li> SAR crashed few times while trying to connect to HWDB 
  </ul> 
  <li> Access to fix Calorimeter ADMEMs 
  <ul> 
    <li> North Wall has been moved and SVX ladder B3W10L4 tripped on Dvdd ovc, as usual 
  </ul> 
  <li> SVX B0W3L3 Dvdd pinky 
  <ul> 
    <li> hockerization of CAEN PS crate 2 
  </ul> 
  <li> Adjusted Bias limits to a bunch of SVX ladders 
  <li> <b>Store 6076:</b> Init Lumi 127 1/ub/s; Lostp changed from 400 Hz to 800 Hz and flattened; put Silicon in 
  <ul> 
    <li> Quenched in D0Q5 & D0Q6 
  </ul> 
</ul> 
 
<h3>Thursday, April 24, 2008</h3> 
<ul> 
  <li> Sergo investigated f533 
  <li> <b>Store 6080:</b> Init Lumi 144 1/ub/s; Lostp about 1kHz; put Silicon in 
  <ul> 
    <li> fib07 turned red in RC - ace recovered 
  </ul> 
  <li> Tom investigated bahavior of problematic ISL cooling lines 
</ul> 
 
<h3>Friday, April 25, 2008</h3> 
<ul> 
  <li> <b>Store 6082:</b> Init Lumi 210 1/ub/s; Losses flattened at 10 kHz; put Silicon in 
  <ul> 
    <li> Block of red ladders in SVXmon Cell ID plot in ISL B3W0 and B3W1 - HRR recovered 
    <li> 2V and 5V DOIM pinkies in SVX B1W8 and B1W9 
    <li> Spontaneous switch-off of CAEN PS crate 1. SAR failed because ace did not put RC in HALT. Ace recovered manually 
  </ul> 
</ul> 
 
<h3>Saturday, April 26, 2008</h3> 
<ul> 
  <li> <b>Store 6071:</b> quenched with integrated dose alarm and abort alarm 
  <ul> 
    <li> COLDSTART was fine 
  </ul> 
  <li> SVX BHW1 Vacuum Jacked temperature at lower waring limit (15 C) 
  <ul> 
    <li> Correlated with change in CH temperatures 
  </ul> 
  <li> <b>Store 6090:</b> Init Lumi 165 1/ub/s; Losses flattened at 700 kHz; put Silicon in 
  <li> SVX B5W2 PS developed a very weird problem 
  <ul> 
    <li> tripped on software protection 
    <li> when attempted to recover it switches itself randomly between OFF and STBY in random channels 
    <li> when turned OFF it generates random OVC trips in random channels 
    <li> removed from HWDB (the whole wedge SB5W2) 
    <li> trigger inhibits disabled in SVX HV (sw) and SVX05 TRIP (hw) channels 
    <li> patched PSgui svxinter library to ignore software trips from this board - allows to re-enable SVX HV inhibit 
    <li> data are not marked bad 
    <li> requested 1.5 h access to replace PS 
  </ul> 
  <li> Spontaneous switch-off of CAEN ctate 7. Recovered manually 
</ul> 
 
<h3>Sunday, April 27, 2008</h3> 
<ul> 
  <li> <b>Store 6093:</b> Init Lumi 195 1/ub/s; Lostp flattened at 2.8 kHz; put Silicon in 
</ul> 
 
<h3>Monday, April 28, 2008</h3> 
<ul> 
  <li> Access to replace SVX PS B5W2 - successful 
</ul> 
  
<!-- Author: SashaS -->


<!-- Date: Mon Apr 28 08:58:52 2008 -->
<h3>SB5W2 supply #73 access summary</h3> 
 
We went in to replace the supply which was recently 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=402&frame=2&anchor=00:06:27'> 
behaving weirdly</a>. It was replaced with #65 and is doing well  
so far. In addition, we reverted the CaenVme lib on svxinter to  
its standard version and removed the wedge (SB5W2) from  
IgnoreWedges.txt on svxiicon.  
<!-- Author: Sasha, Satyajit and Ricardo -->