<!-- Title: 09:45:46  Mon Feb 18 2008 -->
<!-- Crewchief: Oscar (MPC) -->
<!-- Op1: Sasha (SPL on call) -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Starting with a Noise-to-bias scan... and hoping for the best (expecting the worst, of course).</pre>


<!-- Date: Mon Feb 18 11:28:57 2008 -->
<h3>Noise-to-bias scan</h3>  
 
 
<BR> 
The CAEN volts file is  
/cdf/onln/data/svxii/caencontrol/PSfiles/caenvoltsfiles/CAENvolts_02122008_1141AM.dat 
 
Run number: <a href="http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN=258335">258335</a> 
<BR> 
Date and starting hour: 18 feb 2008, 08:15am 
 
<BR> 
<pre> 
        
        VOLTAGE         EVENT RANGE   START TIME  
         -130                0-1041  
        -110              1042-2010 
        -90               2011-3007 
        -70               3008-4019 
        -50               4020-5018 
        -30               5019-6005 
        -10               6006-6997 
          0               6998-8009 
 
        -120              8010-9003 
        -100              9004-10025 
        -95              10026-11027 
        -90              11028-12001 
        -85              12002-13005 
        -80              13006-14004 
        -75              14005-15031 
        -65              15032-16092 
        -60              16093-17570 
        -55              17571-18061 
        -45              18062-19028 
        -40              19029-20009 
        -35              20010-21004 
        -25              21005-22005 
        -20              22006-23083 
        -15              23084-24023 
        -7               24024-24758 
        -5               24759-26001 
        -3               26002-27066 
         0               27067-28162 
 
</pre>
<!-- Author: Oscar/Roberto -->


<!-- Date: Mon Feb 18 14:51:51 2008 -->
<h3>L00 PS crowbar access</h3> 
We went in to replace the 8 remaining old crowbars with the new ones. The new ones have a zener voltage limit of 450 V. The  
replaced ones are 
<b>LB0W5</b>, <b>LB0W0</b>, <b>LB0W4</b>, <b>LB0W1</b>, 
<b>LB0W3</b>, <b>LB0W2</b>, <b>LB1W3</b> and <b>LB1W1</b>. 
The replacement were successful.  
<!-- Author: Satyajit, Mark -->
<!-- Comment: Mon Feb 18 15;37;54 comment by...  -->
And Sasha and Ricardo that were driving from upstairs.


<!-- Comment: Wed Feb 20 11;00;08 comment by...Satyajit -->
Oops! Sorry for the omission!!
<!-- Date: Mon Feb 18 22:44:29 2008 -->
Coming for the Shot Setup, I realized that this morning we forgot to restart the BeamPermit on svxinter... I have started it now.
<!-- Author: Oscar -->


<!-- Date: Mon Feb 18 23:23:19 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12335&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12336  width='300' align='top'></a></td><td>New store 5919 came in nicely (losses are below 10 KHz) with an initial instantaneous luminosity of 217E30. So far, everything looks fine.</td></tr></table>
<!-- Author: Oscar -->
<!-- Comment: Mon Feb 18 23;39;21 comment by...Oscar -->
f142 has a part of chips yellow in SVXMon (or taking ages to become green). I decided to ignore it since it does not seem to be fixed by HRRs. 


<!-- Date: Wed Feb 20 09:31:43 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12339&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12340  width='300' align='top'></a></td><td><h3>Order has returned to the Universe</h3> 
<p> 
<i>Have you had that feeling that something was missing ? <br> 
Something you once had but was no longer there ? 
</i> 
</p> 
 
<p>Now you're prayers have been answered !!<br> 
The new coffee machine has arrived!!<br> 
Like the Phoenix rising from the ashes, the new coffee machine has been forged from the ashes of the old to give birth to  this new messiah.  
</p> 
 
<p>It also makes a damn fine cup of coffee!</p> 
 
 
</td></tr></table>
<!-- Author: Ankush on behalf of the CDF Coffee Collaboration -->


<!-- Date: Wed Feb 20 12:58:25 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W0L3 
<li>problem n: 2465 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Swap_RX
<li>entered by: sasha 
<li>description is: Replaced old RX to fix 'no data' problem. Everything looks OK after a swap. Still need to observe for 1 week with data before declaring fixed.<table border=1>
   <tr>
    <td>
     <b>IN:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0523">0523</a>
    </td>
   </tr>
   <tr>
    <td>
     <b>OUT:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0752">0752</a>
    </td>
   </tr>
  </table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Feb 20 13:00:03 2008 -->
<h4>Access to swap RX for f303</h4> 
 
Sergo and I went into a controlled access to swap RX for f303 (no data problem). An RX swap fixed the problem.
<!-- Author: sasha,sergo -->


<!-- Date: Fri Feb 22 07:07:41 2008 -->
Here for a new shot setup. I noticed that the BeamPermit was not running on svxinter, so I started it. Since there is no entry in the e-log to jusfity that it was not there, I assume we just forgot to restarted after the shutdown.
<!-- Author: Oscar -->
<!-- Comment: Fri Feb 22 07;33;49 comment by...SashaS -->
Yes, I forgot to start it after Wednesday access. Thanks, Oscar


<!-- Comment: Fri Feb 22 07;49;43 comment by...Ricardo -->
Shall we put something to monitor this ? 
<!-- Date: Fri Feb 22 07:39:12 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12341&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12341  width='300' align='top'></a></td><td>Integrated dose alarm shortly after the squeeze in store #5924. Note the unusual feature that the radiation level keeps rising after scraping. We will need to figure out with MCR why this happened.</td></tr></table>
<!-- Author: Ulrich -->
<!-- Comment: Fri Feb 22 07;50;49 comment by...Ricardo -->
I figure you mean that it was not resetted after scraping.
<!-- Date: Fri Feb 22 07:41:57 2008 -->
Right in the middle of the scraping we had an auto-hockerization of PS number 10. We ask the ace to free the crates and we recover the ladders ourselves with a COLDSTART. Everything seems fine and we give the crates back to the ace.
<!-- Author: Ulrich, Oscar -->




<!-- Date: Fri Feb 22 07:58:59 2008 -->
We had a very curious situation when ramping the HV on for the datataking. At some point, PS-GUI and iFix reported a trip of 3 L00 wedges but sfter PS GUI came back everything was up. 
<br> 
However, the ace made a mistake that could explain part of this: she click on "go to Stand-by" and I realized right away and we click on "go to ON"... so probably the 3 L00 did trip but the on command switched them off. We did a Recover anyway, so everything should be fine. I have requested an HRR just to be completely sure.
<!-- Author: Oscar -->

<!-- Date: Fri Feb 22 08:22:35 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W0L3 
<li>problem n: 2282 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Changing limits to avoid a pinkie. Just a bit above the limit, but stable.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>200</td><td>200</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>280</td><td>310</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B2W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Feb 22 08:23:56 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12342&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12342  width='300' align='top'></a></td><td>This is the plot of the shot setup with an overlaid of the V:TSCRAP variable.</td></tr></table>
<!-- Author: Ricardo -->


<!-- Date: Fri Feb 22 08:24:56 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12343&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12344  width='300' align='top'></a></td><td>New store 5924 with an initial instantaneous luminosity of 146E30. Everything looks fine now after the reported HV issues during the scraping and turning on and problems with the EVB.</td></tr></table>
<!-- Author: Oscar -->


<!-- Date: Sat Feb 23 03:59:16 2008 -->
<pre>They paged me at the end of scraping because b0fib00 became red in Run Control. The Ace (Betta) rebooted it and everything seems to be fine. She just got confussed because it was still red in RC. Resetting and going through partition makes it green and happy.&lt;br&gt; 
She told me there was a trip from one ISL ladder. From the PS-GUI log I see that it was at 3:44 and f014. </pre>
<!-- Author: Oscar. -->
<!-- Comment: Sat Feb 23 04;06;47 comment by...Oscar -->
I got paged about the trip (the automatic call) at 4:04. 20 minutes delay does not seem very useful... I will keep an eye on this delays.


<!-- Date: Sat Feb 23 04:10:25 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12345&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12346  width='300' align='top'></a></td><td>New store 5925 came in with an initial instantaneous luminosity of 241E30. Watched from home, it seems eveyrthing looks fine.</td></tr></table>
<!-- Author: Oscar -->

<!-- Date: Sat Feb 23 11:32:20 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W2L0 
<li>problem n: 2204 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Changing limits in IMON to avoid having the cell ignored. Current look stable and right above the high-end limit.<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>180</td><td>210</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W2&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Feb 23 11:34:24 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W1L1 
<li>problem n: 2328 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Changing limits in BIAS0 to avoit a pinky cell in IMON due the value just above the current high-end limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>95</td><td>95</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>155</td><td>190</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Feb 23 11:36:28 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W0L1 
<li>problem n: 2407 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Changing the IMON limits for BIAS0 to avoid a pinky due to the value is right above the current high-end limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>110</td><td>110</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>160</td><td>190</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Feb 23 11:41:21 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W0L3 
<li>problem n: 2290 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Raising the IMON limits to avoid a pinky. The current value is right above the high-end limit.<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>220</td><td>250</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Feb 23 11:41:21 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W2L3 
<li>problem n: 2260 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Raising the limits in IMON to avoid a pinky cell. The value ir right above the current high-end limit and stable.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>170</td><td>170</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>230</td><td>260</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Feb 23 11:42:41 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W1L1 
<li>problem n: 2191 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Changing the IMON limit for BIAS1 to avoid a pinky cell. Value is stable and right above the current limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>130</td><td>130</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>230</td><td>260</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Feb 23 11:53:21 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W2L1 
<li>problem n: 2235 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Changing the IMON limits for BIAS1 to avoid a pinky cell right above the limit (and stable).<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>160</td><td>160</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>220</td><td>250</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Feb 23 11:55:25 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W5L3 
<li>problem n: 2458 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Changing the IMON limits for BIAS1 to avoid a pinky cell from a stable value right above the high-end limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>38.5</td><td>38.5</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>130</td><td>160</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W5&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Feb 23 11:57:10 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W1L1 
<li>problem n: 2298 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Changing limits for BIAS1 to avoid a pinky cell.<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>200</td><td>230</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B2W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Feb 23 11:59:58 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W0L3 
<li>problem n: 2212 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Changing limits to avoid a pinky in BIAS1. Current is not complete stable, but having it ignored is not justified with the 2-unit fluctuations we are seeing.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>200</td><td>200</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>260</td><td>290</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Feb 23 12:01:39 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W0L4 
<li>problem n: 2218 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Changing limits to avoid a pinky in BIAS1. Current is not complete stable, but having it ignored is not justified with the 2-unit fluctuations we are seeing.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>56.4</td><td>56.4</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>155</td><td>190</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Feb 23 12:04:16 2008 -->
Here to change a few limits in IMON for BIAS for cells that are ignored. I have left 5 ignored cells in SVX (BIAS) because the currents do not look completely stable. I will try to look at them before my shift ends.<br> 
Apart from these we still have 2 ignored cells in DOIM for e09x and 1 in DVDD for cell e390.
<!-- Author: Oscar -->


<!-- Date: Sat Feb 23 15:51:50 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12347&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12348  width='300' align='top'></a></td><td>Strange current behaviour. Value seems to be below the high-end limit in IMON, but I keep this ignored to avoid being called in the middle of the night. I would recommend to keep an eye on this channel during the next days.<br> 
</td></tr></table>
<!-- Author: Oscar -->

<!-- Date: Sat Feb 23 15:53:40 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W0L2 
<li>problem n: 2305 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Changing limits to avoid a pinky in BIAS1. Current is not complete stable, but having it ignored is not justified with the 2-unit fluctuations we are seeing.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>190</td><td>190</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>240</td><td>270</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Feb 23 20:52:33 2008 -->
The shiftcrew contacted me because there is a new yellow chip (not even a whole ladder). The most interesting thing is that the page got lost so I realized when checking the e-log that they were trying to contact me.;br: 
Regarding the ladder, I am not at FNAL, so I decide to ignore it. Restarting the run may help, but the lost will be much larger (and I am not sure it would make anything). HRR did not fix the problem. If in the next run is still yellow, I will take some action. I will keep an eye on the control room actions.;br: 
Ladder seems to be e500, Z side (the Phi side is red)
<!-- Author: Oscar -->


<!-- Date: Sun Feb 24 03:41:00 2008 -->
Losses in the new store are pretty high and TevMon is in ALARM state. I instructed the shiftcrew to strat without silicon and see how it evolves.
<!-- Author: Oscar -->
<!-- Comment: Sun Feb 24 04;14;52 comment by...Oscar -->
After losses went fine, one autohockerization leads us to a state where L00 B0 W4 was hard to recover. After a manual hockerization and a lot ot tries it was able to hold on STAND-BY. We cleared the permit and we plan to put silicon in.


<!-- Date: Sun Feb 24 04:38:38 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12349&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12349  width='300' align='top'></a></td><td>Store 5927 came in with an initial instantaneous luminosity of  269.5E30. However, losses were high and MCR needed to adjust the tunes. After they did that and silicon issues were recover, we included silicon in the datataking that is proceeding smoothly.<br> 
Luminosity at that moment was 212E30.</td></tr></table>
<!-- Author: Oscar -->

<!-- Date: Sun Feb 24 11:05:03 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W3L1 
<li>problem n: 2436 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Changing limits in IMON for BIAS0 since the value reached the upper limit in its steady increase.<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>155</td><td>185</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W3&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sun Feb 24 11:07:38 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12350&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12350  width='300' align='top'></a></td><td>This plot shows how losses were at the beginning of the store (5927). We did not take data with silicon for a while due to the high losses and due to problems with L00 W4 tripping on overcurrent.</td></tr></table>
<!-- Author: Oscar -->


<!-- Date: Sun Feb 24 11:11:00 2008 -->
In the new store, ladder that was having some chips yellow in SVX B5 is back to green. It is unclear if it was fixed by restarting the run or due to the time it was at stand-by. In any case, everything seems normal for the silicon and CDF is taking data smoothly.<br> 
As always, one ladder in ISL is yellow in SVXMon. It is f452 and only part of the chips seems affected.
<!-- Author: Oscar -->

<!-- Date: Sun Feb 24 14:06:53 2008 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W3L3 
<li>problem n: 2474 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: oscar 
<li>description is: It seems that since run 258558 the bit-2 error has become 100% persistent. In previous runs it looked more intermitent.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W3&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Feb 25 02:39:24 2008 -->
The ace has told me that the last D-mode calibration was taken 2 weeks ago. I instructed him to take another at the end of the store that is going to come tonight. As far as I remember, we decided these calibrations should be taken with beam.
<!-- Author: Oscar -->
<!-- Comment: Mon Feb 25 02;54;42 comment by...Oscar -->
Tevatron quench when initiated collision... it seems that this calibration will have to wait.


<!-- Date: Mon Feb 25 06:57:48 2008 -->
<h3>Monitoring Shift Report</h3> 
 
I have checked the runs from 258365 (0x3f13d) to 258611 (0x3f233). The only troubles I found is that since run 258558 ladders f452 and f533 has persistent bit errors. They were already known as problems appearing from time to time. However, they seem to be systematic now.
<!-- Author: Oscar -->


<!-- Date: Mon Feb 25 07:23:42 2008 -->
<h3>Summary of the week</h3> 
 
Smooth week with very little problems. In general silicon was fine and the data-taking did not have much issues. Here is the day-by-day summary: 
 
<ul> 
<li><b>Monday</b> 
<pre> 
   - We started the week with a smooth noise-to-bias scan. 
   - Access around noon to swap a few L00 PS crowbars. The 8   
     remaining old crowbars were successfully replaced. 
   - Store 5919 came in at the end of the evening shift. Inst  
     Lumi was 217E30 and losses below 10 KHz. 
</pre> 
</li> 
<li><b>Tuesday</b> 
<pre> 
   - No entries... data taking was smooth and store longer than         
     usual due to problems in Recycler. 
</pre> 
</li> 
<li><b>Wednesday</b> 
<pre> 
   - New Expresso Machine arrived... order returned to the   
     Universe and everybody stop sending e-mails about the  
     topic :) 
   - Sasha and Sergo made use of an access to fix the problem in  
     f303 with an RX swap. 
   - Data seems fine after that change for f303. 
</pre> 
</li> 
<li><b>Thursday</b> 
<pre> 
   - No entries: still waiting for the Recycler to come back.    
     Stack record for Fermilab. 
</pre> 
</li> 
<li><b>Friday</b> 
<pre> 
   - Integrated dose alarm during scraping in store 5924. 
   - Autohockerization of crate number 10 during scraping in  
     store 5924. Also a "fake" trip reported by PS-GUI (unclear  
     what actually happened). 
   - Store 5924 came in with Inst Lumi of 146E30. Everything was  
     fine. 
</pre> 
</li> 
<li><b>Saturday</b> 
<pre> 
   - b0fib00 became unresponsive (several times during the week).  
     Usually fixed by rebooting. Aces took that responsability. 
   - Trip in f014. Automatic page came 20 min later. 
   - New store 5925 came with initial inst Lumi of 241E30.  
     Everything was fine. 
   - I changed limits on BIAS pinkies that were set to ignore. 
   - Strange behaviour in the BIAS current for e561. I would  
     recommend to keep an eye on it. 
</pre> 
</li> 
<li><b>Sunday</b> 
<pre> 
   - New store 5927 came with very high losses. When they manage     
     to have them under control, an autohockerization took place  
     and then L00 B0W4 took some time to recover (luckily we did    
     not cause downtime, just data with no silicon). After 
     recovering, silicon was included in the data-taking. 
</pre> 
</li> 
<li><b>Monday</b> 
<pre> 
   - A store was lost during squeezing due to a quench. 
</pre> 
</li> 
</ul>  
<!-- Author: Oscar -->