<!-- Title: 10:19:22  Mon Jun  4 2007 -->
<!-- Crewchief: Sebastian Carron (MPC) -->
<!-- Op1: Ignacio (SPL) -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Beginning of new Weekly shift</pre>


<!-- Date: Mon Jun 4 10:52:16 2007 -->
<pre>OK, learning to use this automatic pager. I got an alarm from ISL power supply being off whilke it was supposed to be on, but that is because people are working on it, so it is not a concern</pre>
<!-- Author: Sebastian -->


<!-- Date: Mon Jun 4 13:56:09 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11520&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11521  width='300' align='top'></a></td><td>Cooling activity in the hall.</td></tr></table>
<!-- Author: Ignacio -->


<!-- Date: Mon Jun 4 14:11:13 2007 -->
<h3>Summary of ISL Cooling Access</h3> 
 
Today's ISL access served two purposes. We have installed a nitrogen 
purge system for the leaky ISL PCE line. A dry environment is a 
pre-requisite for any leak repair. We also tried to trouble-shoot the 
blockage in CCE4. 
 
<ul> 
<li>11:07: Supply valves for ISL CCE1-4 closed.</li> 
<li>11:10: Vacuum pump connected to ISL PCE return and supply side. Rate-of-rise (RoR) test is worse on the supply than on the return side, compatible with the leak being on the supply side. While opening the DPT line (for pressure monitoring), the liquid that came out smelled strongly like glycol, so it has been stale between the T junction at the COT face and the manifold for a while.</li> 
<li>11:14: Return valves for ISL CCE1-4 closed and RoR performed. The RoR shows the expected increase in pressure on CCE1-3, but CCE4 appears to be completely decoupled from the rest.</li> 
<li>11:30: Flushed nitrogen through PCE line. We establish about 10 SCF, and the exhaust pressure is fluctuation up and down. The flow can now be regulated from upstairs.</li> 
<li>11:50: Opened main CCE4 supply line to trouble-shoot the line. A lot of liquid comes out, but everything looks clean. The COT face pressure goes atmospheric as expected.</li> 
<li>11:50: Opened supply to CCE4 DPT line to drain it, but no liquid came out.</li> 
<li>12:05: Pulled vacuum on on CCE4 supply line. Only the COT face pressure of CCE4 reacts. Tried again after 10 minutes, to about 6 psia, still no reaction. The line is almost perfectly sealed. We perform a RoR just on the evacuated part of the line, the vacuum holds perfectly.</li> 
<li>12:25: Opened return valves for CCE1-4. Vacuum returns to CCE1-3, but still no reaction on CCE4.</li> 
<li>12:30: Over-pressurize CCE4 supply line to 16 psi. None of the other lines reacts.</li> 
<li>12:37: Open DCCE4 PT on return side and see suction. This is expected, because we pull vacuum on the return side. Unfortunately the supply side is not accessible without cutting the line, so we give up on it.</li> 
<li>13:00: Unsuccessful attempt to calibrate DPT for PCE, still reads around -1 psid</li> 
<li>13:10: Nitrogen flow is re-established to PCE.</li> 
<li>13:15: We replace the e-valve guts for ISL CCE4. The guts look unsuspicious, but the nut is rusty (we have seen that before for other valves).</li> 
<li>13:20: The final configuration of CCE4 will be: the supply line is re-connected and the manual supply valve is closed and tagged out. This way we make sure that nobody opens the supply by accident and at the same time just need a 10 minute access to open up the line, should the blockage clear itself magically. 
</ul> 
The bottom line: the nitrogen purge for ISL PCE has been installed successfully, and the supply of CCE4 shows a really tight seal that we were not able to remove during the access. 
<p> 
Thanks a lot to Warren Bowman, Del Allspach, and Peter Wilson.  
<!-- Author: Jose, Ignacio, Ulrich -->

<!-- Date: Mon Jun 4 17:04:07 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W5L0 
<li>problem n: 2070 
<li>Status: fixed
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Changed IMON Limits after access<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>157</td><td>188</td></tr>
<tr><td><b>Lower</b></td><td>??</td><td>175</td></tr>
<tr><td><b>Upper</b></td><td>??</td><td>200</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B0W5&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Jun 4 17:08:23 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W5L2 
<li>problem n: 2073 
<li>Status: fixed
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Changed AVDD imon limits after access<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>207.5</td><td>190.0</td></tr>
<tr><td><b>Lower</b></td><td>200.0</td><td>183.0</td></tr>
<tr><td><b>Upper</b></td><td>210.0</td><td>193.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B0W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Jun 4 17:09:57 2007 -->
<pre>Protons are starting to be loaded for new store</pre>
<!-- Author: Sebastian -->

<!-- Date: Mon Jun 4 17:13:46 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W5L3 
<li>problem n: 2074 
<li>Status: fixed
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Changed AVDD imon limits after the access<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>262.5</td><td>205.0</td></tr>
<tr><td><b>Lower</b></td><td>260.0</td><td>202.0</td></tr>
<tr><td><b>Upper</b></td><td>270.0</td><td>212.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B0W5&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Jun 4 17:21:04 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W5All 
<li>problem n: 2075 
<li>Status: fixed
<li>Type: VDOIM
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Changed VDOIM imon limits after the access (2V)<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>676.9</td><td>645.0</td></tr>
<tr><td><b>Lower</b></td><td>670.0</td><td>638.0</td></tr>
<tr><td><b>Upper</b></td><td>715.0</td><td>653.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B0W5&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Jun 4 17:26:03 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W5All 
<li>problem n: 2076 
<li>Status: fixed
<li>Type: VDOIM
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Changed VDOIM imon limits after the access (5V)<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1350.6</td><td>1325.0</td></tr>
<tr><td><b>Lower</b></td><td>1330.0</td><td>1305.0</td></tr>
<tr><td><b>Upper</b></td><td>1390.0</td><td>1365.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B0W5&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Jun 4 17:40:57 2007 -->
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: carron 
<li>description is: Increased BIAS limits after access<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>79.3</td><td>101.0</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.0</td><td>125</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: Mon Jun 4 17:41:40 2007 -->
<h3>Power supply access summary</h3> 
We went in to swap the supply for the LB0W5 wedge located in  
the PS crate #7 (NW Bot Top). This was one of our primary 
candidates for swap due to severely drooping AVDD, as shown  
in <a  
href="http://www-cdf.fnal.gov/~jpursley/droopingLV.html">this  
list</a>. Note that this is the only L00 wedge powered by an  
SVX module.<p> 
 
We changed the bias settings on one of our SVX spares (#72) to  
prepare it for the swap, prior to the access. After swapping the 
module I (Satyajit) hooked up the HV cable to the supply through 
the crowbar by mistake. This blew the poor thing when the supply 
was turned ON. After replacing the crowbar we powered the wedge 
up from the control room to realize that the LV settings on the 
supply are still at their SVX values. Taking advantage of the 
lingering cooling access we decided to bring the supply up again 
to change the settings.<p> 
 
After changing the settings I (Satyajit) powered up the channels  
to ensure the enable functionality. They turned back off due to 
lack of CONFIG. On powering them ON again from the control room 
we realized that one of the channels of the crowbar is blown 
(again)!<p> 
 
Using our second replacement crowbar we could power up the  
module from upstairs and get it through the enable test, just 
in time to exit the collision hall along with the cooling 
access folks!  
<!-- Author: Satyajit, Jose, Jen (expert at the controls) and Ignacio -->

<!-- Date: Mon Jun 4 17:44:40 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W6L4 
<li>problem n: 2078 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Increased BIAS limits after access<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>20.0</td><td>107.0-</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.0</td><td>125.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W6&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Jun 4 17:48:11 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W8L3 
<li>problem n: 2079 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Increased BIAS limits after access<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>43.2</td><td>101.0</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.0</td><td>125.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W8&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Jun 4 17:51:02 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W0L0 
<li>problem n: 1822 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Increased BIAS limits after access<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>100.0</td><td>126.0</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.0</td><td>150.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Jun 4 17:55:01 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W10L1 
<li>problem n: 2044 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Increased BIAS limits after access<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>90</td><td>122.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>120.0</td><td>130.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W10&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Jun 4 17:58:32 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W11L3 
<li>problem n: 2080 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Increased BIAS limits after access<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>43.4</td><td>101.0</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.0</td><td>125.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W11&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Jun 4 18:37:47 2007 -->
<pre>Protons are loaded and Antiprotons are well underway to being loaded. The Control Room paged me to follow the shot setup.</pre>
<!-- Author: Sebatian -->


<!-- Date: Mon Jun 4 19:24:53 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11522&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11522  width='300' align='top'></a></td><td>The Store 5473 is in, initial luminosity is 270 E30. The losses are low (below 500), there where no issues at the begining of the store, and now we are taking data with the Silicon turned on. The SVXMON was OK. Here is the usual (now 
colored) spymon plot</td></tr></table>
<!-- Author: Sebastian -->
<!-- Comment: Mon Jun  4 19;25;44 comment by...Sebastian -->
<pre>Sorry, TYPO, the initial luminosity was 227 E30, not 270...</pre>


<!-- Date: Mon Jun 4 19:30:39 2007 -->
<pre>BIAS pinkie in SVX B3W8L2. Relatively large jump, will follow to see how it behaves next</pre>
<!-- Author: Sebastian -->

<!-- Date: Mon Jun 4 19:38:41 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W5L1 
<li>problem n: 2081 
<li>Status: fixed
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Changed limits now taht we can monitor with data<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>62.3</td><td>43</td></tr>
<tr><td><b>Lower</b></td><td>60.0</td><td>38</td></tr>
<tr><td><b>Upper</b></td><td>75.0</td><td>53</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B0W5&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Jun 4 19:46:47 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W5L3 
<li>problem n: 2082 
<li>Status: fixed
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Changed DVDD IMON limits now that we have data<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>71.9</td><td>35.0</td></tr>
<tr><td><b>Lower</b></td><td>70.0</td><td>28.0</td></tr>
<tr><td><b>Upper</b></td><td>115.0</td><td>60.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B0W5&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Jun 4 19:53:01 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W5All 
<li>problem n: 2075 
<li>Status: fixed
<li>Type: VDOIM
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Now redefining that we are testing new limits on data<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>645.0</td><td>645.0</td></tr>
<tr><td><b>Lower</b></td><td>638.0</td><td>638.0</td></tr>
<tr><td><b>Upper</b></td><td>665.0</td><td>690.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B0W5&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Jun 4 20:57:34 2007 -->
<pre>Currently SVT tests are underway, they started at luminosity 
of about 190E30, still going now (Luminosity 171), we are not 
sure if the runs are going to be marked good or bad while the SVT is being tested. Ignacio is here to go over the tests with the SVT expert</pre>
<!-- Author: Sebastian -->
<!-- Comment: Mon Jun  4 20;59;10 comment by...Sebastian -->
<pre>No resonances yet, including during the SVT test</pre>


<!-- Comment: Mon Jun  4 21;47;12 comment by...Ignacio (watching Stefano work) -->
SVT tests are done and we are back to normal. The number of fits did not affect the SVT processing time when the maximum number of rods was kept at 63. However when the maximum number of rods was increased to 159, we saw a tail of high number of rods and high proccessing time (up to 300 mus). These events would come in spikes  that were presumably correlated with L2 decision timeouts that did not allow for smooth running.
<!-- Date: Mon Jun 4 21:03:27 2007 -->
Since the SB3W8L2 gave a pinky with a big jump, it has plateaued and the current looks stable, I am inclined to re-define the IMON limits and unmark it.  None of the L00 currents whose IMON limits I  redefined before the store have pinkied yet, the same goes for the number of SVX ladders whose BIAS IMON current limits where re-defined a few hours ago.
<!-- Author: Sebastian -->

<!-- Date: Mon Jun 4 21:15:54 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W8L2 
<li>problem n: 1773 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Increasing IMON BIAS limit to avoid frequent pinkies. The current looks relatively stable<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>110.0</td><td>110.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>140</td><td>160</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W8&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Jun 5 02:48:31 2007 -->
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: carron 
<li>description is: Increased BIAS limit because of Pinkie, Current is stable at 126 which is just above the 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>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>125</td><td>140</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: Tue Jun 5 02:52:33 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W8L1 
<li>problem n: 1886 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Increased LImit to 125 like some of the other ladders<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>90</td><td>90</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>120</td><td>125</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W8&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jun 5 02:57:50 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W3L1 
<li>problem n: 1865 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Increased IMON BIAS limits. These lemits where changed in this ladder recently and probably have to increase a little bit more <table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>100.0</td><td>100.0</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.0</td><td>135.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W3&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Jun 5 03:12:00 2007 -->
<pre>The Control Room paged me about a bunch of Pinkies, these coincided with the prescale change at 110, in all cases but one the currents where relatively stable, and the IMON limits had been changed recently, so I increased the BIAS limit slightly, which should be fine. In one case, there was an AVDD pinky however in SB3W7L2 with a drastic change in current that does look strange. I might have to remove that from the database.</pre>
<!-- Author: Sebastian -->


<!-- Date: Tue Jun 5 03:26:52 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11523&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11524  width='300' align='top'></a></td><td>This is the large jump in AVDD current. Should I take this out of the database?</td></tr></table>
<!-- Author: Sebastian -->
<!-- Comment: Tue Jun  5 03;33;53 comment by...Sebastian -->
<pre>A HRR helped. Will continue monitoring this ladder</pre>

<!-- Comment: Tue Jun  5 08;23;21 comment by...Sebastian -->
<pre>Later in the night there was an auto-Hockerization. The ladder had other 2 drops in current that where again fixed with an HRR. If it continues happening then we will try to power cycle the wedge.</pre>


<!-- Date: Tue Jun 5 08:38:33 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11525&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11525' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11526&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11526' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11527&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11527' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11528&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11528' width='300'></a></center>
<!-- Author: Ignacio -->
<!-- Comment: Tue Jun  5 09;06;53 comment by...Ignacio -->
Stefano reports a SVT drop in efficiency of 1 % last week. It coincides with e0a4 starting to give bit errors. As you can see the efficiency from this ladder has decreased a lot due to this bit errors. It was in the list for RX investigations along with e2b2 yesterday but we did not have time to do it. It should move up in our priority list.

<!-- Date: Tue Jun 5 11:11:21 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W10L4 
<li>problem n: 2064 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Bit 5 stuck high for >80% of events since run 242650. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W10&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Jun 5 15:57:27 2007 -->
<pre>So far it has been a very easy day, not even a pinky, no  
problem at all. Since there is not anything else to do I  
am working on code development in the Logic Analyzer</pre>
<!-- Author: Sebastian -->
<!-- Comment: Tue Jun  5 21;03;55 comment by...Sebastian -->
<pre>Now I see how I jinxed myself, we had 2 TevMon alarms, a
case of a wrong run configuration, and an unfixable pink
loving ladder since then. Now repeat after me, do not claim 
it is an easy day again, do not claim it is.....</pre>
<!-- Date: Tue Jun 5 16:35:01 2007 -->
<pre>The PS gui was experiencing some problems with memory, more specifically when pressing the buttom "to elog" in the history of  
a ladder, there was an error message indicating there was no 
memory. Ignacio re-started the ps-gui and now it seems to be ok</pre>
<!-- Author: Sebastian -->
<!-- Comment: Tue Jun  5 17;33;02 comment by...Ignacio -->
IMON
<!-- Date: Tue Jun 5 16:38:19 2007 -->
<pre>There was an avdd pinky in SVX B3W7L2. An HRR fixed it.</pre>
<!-- Author: Sebastian -->



<!-- Date: Tue Jun 5 19:33:02 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11529&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11529  width='300' align='top'></a></td><td>There was a TevMon alarm because of a lost RF station. The silicon went automatically to standby. Then after the losses were ok and the tevatron seemed stable, and after we were  told by the MCR that the beam should be stable we powered on the silicon again. Then 10 minutes later the abort gap began to fill rapidly and we went to TevMon Warning promptly followed by a TevMon alarm. In this plot we see that the aboirt gap went well above the limits. The losses did not spike though and we did not get a significant dose in the detector. We are waiting for the MCR to assure us this time that the tevatron is indeed stable before ramping up the silicon again</td></tr></table>
<!-- Author: Sebastian/Jose/Ignacio -->
<!-- Comment: Tue Jun  5 19;38;21 comment by...Sebastian / Ignacio -->
<pre>After we called the MCR, they indeed said that there was a tunning done a few minutes before the big spike in the abhort gap but they could not identify any tweak done at the same time as the spike. We are now apparently stable. We have now ramped up and are ready to take data again.</pre>


<!-- Comment: Tue Jun  5 21;38;57 comment by...ronmoore -->
Remember the TEL(s) work only on DC protons, not pbars.  The later spike in the pbar abort gap losses are the DC pbars that eventually spiral into a collimator.
<!-- Date: Tue Jun 5 19:41:05 2007 -->
<pre>While we where down we power cycled all of B3W7. We had a  
problematic ladder that was giving frequent pinkies and this  
perhaps will fix that problem</pre>
<!-- Author: Sebastian/ Ignacio -->


<!-- Date: Tue Jun 5 19:56:39 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11530&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11530  width='300' align='top'></a></td><td>And no, the power cycle of wedge 7 b3 did not help, we got another pinkie from B3W7L2. An HRR recovered the AVDD pinky, 
but there must be something wrong with this ladder</td></tr></table>
<!-- Author: Sebastian -->


<!-- Date: Tue Jun 5 20:05:23 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11531&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11531  width='300' align='top'></a></td><td>A year of history for b3w7l2. This does look to have a historu of low current...Now what?, could it be a power supply?</td></tr></table>
<!-- Author: Sebastian -->
<!-- Comment: Tue Jun  5 20;20;21 comment by...Sebastian -->
<pre>Last posibility is to try a Hockerization on the crate...</pre>

<!-- Comment: Tue Jun  5 20;47;19 comment by...Sebastian -->
<pre>OK I just hockerized Crate 14 that corresponds to this ladder. If this does not fix it we will just ignore it</pre>


<!-- Date: Tue Jun 5 20:59:55 2007 -->
<pre>The extremely stubborn SB3W7L2 just decided that it really likes going pink, after we tried about everything to fix it we are now just going to have to IGNORE it. Perhaps at some point a power supply swapp can halp...</pre>
<!-- Author: Sebastian -->
<!-- Comment: Wed Jun  6 07;09;35 comment by...Jen -->
SB3W7 is already on the top of our list of power supplies to swap because of several very badly drooping low voltages.
<!-- Date: Wed Jun 6 03:14:53 2007 -->
I was paged because pbars were being loaded. I arrived at the Control Roomm just as the last trains were being loaded, everything was looking normal until the tevatron QUENCHED. The shot setup 
was not finished yet, the quenched happened while ramping, the Silicon was in standby at the moment. The dose monitor showed a  
dose increase of 0.3 Rads/s. So we recieved some radiation but 
nothing we can do about it, the Silicon was on standby at least. Now the next shot setup is going to take place not before 3 or 4 more hours.
<!-- Author: Sebastian -->
<!-- Comment: Wed Jun  6 03;18;28 comment by...Sebastian -->
<pre>Sorry the radiation dose differential was about 0.03 rads, not
0.3 rads...not too large. </pre>


<!-- Date: Wed Jun 6 03:45:05 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11532&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11532  width='300' align='top'></a></td><td>This is the loss monitor graph. The abhort gap was not clean during the quench since it happened during shot setup.</td></tr></table>
<!-- Author: Sebastian  -->


<!-- Date: Wed Jun 6 03:54:39 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11533&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11533  width='300' align='top'></a></td><td>A new theory for the reason quenches happen...ninja rats...Yes it is 4 in the morning and I had nothing better to do, couldn't help throwing some Banksy wisdom at the situation</td></tr></table>
<!-- Author: Sebastian  -->
<!-- Comment: Wed Jun  6 10;22;36 comment by...Sebastian -->
<pre>This explains the holes in the cooling also</pre>
<!-- Date: Wed Jun 6 09:14:17 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11534&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11534  width='300' align='top'></a></td><td>The VAVDD for SB3W7L2 shows a mild drop in the voltage, which supports the theory of a bad power supply as Jen mentions above. Also strange spikes.</td></tr></table>
<!-- Author: Ignacio/Sebastian -->


<!-- Date: Wed Jun 6 09:26:30 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11537&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11537  width='300' align='top'></a></td><td>Efficiency for the phi side of ladder e2a4. No change of behavior is seen during the last days. Phi side seems to be returning good data. </td></tr></table>
<!-- Author: Jose -->

<!-- Date: Wed Jun 6 09:28:13 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W5L2 
<li>problem n: 1829 
<li>Status: needs_observation
<li>Type: DRO_00F3
<li>Action: Diagnosis_update
<li>entered by: carron 
<li>description is: Occasional no first chip errors have reappeared lately. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 6 09:30:17 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W10L4 
<li>problem n: 1284 
<li>Status: needs_observation
<li>Type: Other
<li>Action: Monitoring
<li>entered by: jgarcian 
<li>description is: Phi side seems to be still efficient (<a href=http://www-cdfonline.fnal.gov/cgi/internal/elog/det-system-elog.pl?nb=silicon&action=copyentry&page=356&time=09:26:30> e-log</a>). 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W10&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 6 10:19:20 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W0L2 
<li>problem n: 1490 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: carron 
<li>description is: We had recent bit errors with Pipeline out of Sync and Stuck Cell ID errors. We saw this happened a few times earlier. We tried to reproduce the errors in a quiet time DAQ study, but were unable to get the same errors. However in looking at the data we saw that the  chip ID for a2 was being replaced with a3, this is the same problem that was seen a few years ago for this ladder and entered into the problem database. Also some CAP ID's are out of order. This ladder need some work and observation then. 
<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 Jun 6 12:20:49 2007 -->
<p>We were studying the <b>temperatures of ISL east without  cooling  flow</b>. We had the impression that there were two bunch of lines one at a higher temperatures (9-12 C) and one at a lower temperatures (16-20 C). There is no correlation with return or supply, layer, nor out or in side of the line. 
</p><p> 
However, it turns out that the low temperature ones correspond to the sensors located on the bottom half of the detector, the higher temperatures on the top half. The lowest temperature (9C) corresponds to 4L6_1OUT and 4L6_3IN. These are located at 6 o'clock closest to the E4 return and supply manifolds. According to Doug the SVX cooling lines are routed around this area. So this could be an indication in favour of freezing on E4 supply. We will have to look again to these temperatures when we move the SVX set point to -6 C.</p>
<!-- Author: Jose/Ignacio -->
<!-- Comment: Wed Jun  6 14;18;50 comment by...Jose & Ulrich -->
The SVX setpoint has been moved from -10°C to -6°C while the detector is still on (faster this way). We have silenced the chiller evaporator alarms and moved the interlock high-temperature trip from for the SVX BH and L00 from 2°C to 10°C. The next step will be to switch off the detector and warm up to -3°C.


<!-- Date: Wed Jun 6 16:27:23 2007 -->
After Ignacio/Ulrich/Jose et al did work for melting the ice the whole silicon tripped, all ISL east and west temperatures are oscilating. Conductivity is jumping up and down, etc. It is total chaos. I am just observing what these guys are doing and trying to stand back. 
<!-- Author: Sebastian -->
<!-- Comment: Wed Jun  6 18;43;49 comment by...Ulrich -->
Youngling, you haven't seen total chaos yet...
<!-- Comment: Wed Jun  6 19;19;57 comment by...Sebastian -->
<pre>Yes master Jedi</pre>
<!-- Comment: Wed Jun  6 22;15;57 comment by...Shimmering blue one -->
<p><em>Ulrich...master Jedi(!?!?!?!?)</em>....there are some who have ascended to higher forms and wield far greater power....some who are veterans of the wire-bond campaign...the kicker prefire wars...and many other horrors....the horror...the horror</p>
<!-- Comment: Wed Jun  6 23;04;44 comment by...Kilgore -->
Wrong movie, Colonel Kurtz.
<!-- Comment: Thu Jun  7 02;40;59 comment by...Master Grumpy  -->
You may be on this council, but we will not grant you the rank of master !
<!-- Date: Wed Jun 6 17:37:01 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11540&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11541  width='300' align='top'></a></td><td><h3> The Melt Down </h3> 
Real time plotter during the warming up. The orange line is the return temperature in the SVX chiller and the red line the pressure in the block cooling line CCE4. The temperature was changed from -10 to -6 C with the detector on and no effect was observed. At that point we switched off the silicon and changed the set point to -3 C.  
<br> Before reaching -3 C, the pressure of the line CCE4 dropped suddenly. This is the point in which the supply and return line get connected again and the ice block is melted down. </td></tr></table>
<!-- Author: Ulrich/Sebastian/Ignacio/Jose -->




<!-- Date: Wed Jun 6 19:22:19 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11542&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11543  width='300' align='top'></a></td><td><b> A colorful view of what happened today. </b></td></tr></table>
<!-- Author: Jose -->


<!-- Date: Wed Jun 6 19:24:56 2007 -->
<pre>After much work by Ignacio/Jose/Ulrich/.... the flows where re-established, and the SVX and half the ISL and L00 are back in standby. Yes I mean half the ISL, now the ISL b2 is back in standby!. </pre>
<!-- Author: Sebastian -->
<!-- Comment: Wed Jun  6 20;56;41 comment by...Ignacio/Jose/Sebastian -->
We re-includede ISL  Bulkhead 2. Coldstart runs OK. We also run succesfully  coldstart with hardware event builder and CSL  without HV ON.


<!-- Date: Wed Jun 6 21:00:35 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11545&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11545  width='300' align='top'></a></td><td>After some dificutlty trying to take a cosmic ray run, here is the SvxMon plot that shows that data from ISL B2 is being read. The recovered B2 is ready to take data</td></tr></table>
<!-- Author: Sebastian/Jose/Ignacio -->


<!-- Date: Wed Jun 6 21:11:54 2007 -->
The cool down increased PT_COTBHW1 to above 13.3. We have closed it to 76 % in 1 % steps. Now is 12.8 psi with a flow of 2.6 lpm.
<!-- Author: Jose/Ignacio -->




<!-- Date: Wed Jun 6 23:34:57 2007 -->
The new store came with an integrated dose alarm (just above 19 rad/min), see the <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2007&action=view&page=471&frame=2&anchor=23:24:47.290'> 
main e-log</a>. What's the deal, L of T?
<!-- Author: Ulrich -->
<!-- Comment: Wed Jun  6 23;41;41 comment by...Sebastian  -->
<pre>Yes, there was an integrated dose alarm during squeezing. Now the beam looks stable and the silicon is on already. Tom has let MCR know that we got a high radiation dose. Anything else we need to do?.</pre>

<!-- Comment: Wed Jun  6 23;46;55 comment by...Sebastian  -->
Ignacio is here also, he wanted to supervise the begining of this store because of the ISL B2 now in and new flow conditions.


<!-- Comment: Thu Jun  7 08;38;23 comment by...Ulrich -->
The owl shift crew told me that they followed up on the dose alarm during the last store. Marty from MCR did some investigation and found that the number of protons they started from was different than before. The thing is mentioned in the MCR e-log as well.
<!-- Comment: Thu Jun  7 10;23;38 comment by...ronmoore -->
There were more protons because there were 1/2 the number of pbars.  There were likely tune differences because of that fact.  I still need to get caught up on the progress of adding orbit bumps through CDF during the squeeze.
<!-- Date: Thu Jun 7 00:41:12 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11546&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11546  width='300' align='top'></a></td><td>The new store 5479 is in. It started with 137 E30 luminosity, however at the begining of the store we lost quite a bit of time to start taking data because of a CPR and CLC problem. The silicon was turned on after all of the tevatron conditions were satisfied. Here is the usual spymon plot. </td></tr></table>
<!-- Author: Sebastian/Ignacio -->
<!-- Comment: Thu Jun  7 00;47;06 comment by...Sebastian/Ignacio -->
<pre>The initial SVXMON plots where a little worrying with a yellow spot in SB0W5L2, that now thankfully have turned to green. Also SB1W5L2 initially and still shows Red. Ignacio suggests that we look tomorrow at the bit errors for it. </pre>


<!-- Date: Thu Jun 7 00:50:11 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11547&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11548  width='300' align='top'></a></td><td>Worrying Pinky, geting close to the trip limit (500 microA) 
SB0W6L4</td></tr></table>
<!-- Author: Sebastian/Ignacio -->
<!-- Comment: Thu Jun  7 00;53;12 comment by...Sebastian/Ignacio -->
It is a known erratic current case

<!-- Comment: Thu Jun  7 01;15;22 comment by...Sebastian/Ignacio -->
We have increased the trip limit from 500 microA to 1000 microA for this ladder, to avoid a trip, for doing this we had to halt the run for about 2 minutes. Tomorrow when we have the bit reporter information we can look to see if we have any corrupted data.
<!-- Date: Thu Jun 7 01:07:31 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W6L4 
<li>problem n: 2035 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: Currents_investigated
<li>entered by: ignacio 
<li>description is: The current was getting too close to the trip limit of 500. I have increased the trip limit to 1000 muA preemptively. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W6&layer=L4">report</a></ul>
<!-- Author: Problem DB -->





<!-- Date: Thu Jun 7 04:17:44 2007 -->
I was paged by the cotron room and by the automatic pager almost at the same time. The L00 had a trip, specifically all of the ladders in L00 B0W0 had a low AVDD pinky followed by  a trip. ON the phone with the ACE I recomended that he hockerize the PS Crate 7 and try to power up the tripped L00 again but it imediately tripped again. At that point I decided to drive to the Control room and instructed the ace to take data in the meantime without silicon. While in the control room I tried hockerizing Crate 7 again and powering up the wedges corresponding to Crate 7 individually, by going slowly I was able to restore power to all of the fallen wedges. Imediately after powering up I got AVDD high pinkies for all layers in L00 B0W0, B0W5, ISL B0W4, B0W5 and B1W2. After starting a run the AVDD voltages came back to normal. Now we are taking data with silicon again. The question remains what caused the trip, my impresion right now is that something sent the PS Crate 7 into a bad state not sure what yet.
<!-- Author: Sebastian -->


<!-- Date: Thu Jun 7 04:23:24 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11552&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11552' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11550&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11550' width='300'></a></center>
<!-- Author: Sebastian -->
<!-- Comment: Thu Jun  7 04;24;49 comment by...Sebastiann -->
<pre>An example of the behavior of the ladders during the trip, ramping up, pinky and start of the run again. All cases looked like one of these two examples</pre>


<!-- Date: Thu Jun 7 04:28:54 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11554&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11554  width='300' align='top'></a></td><td>Looking more into depth at the histories of the ladders, found this DVDD trip.</td></tr></table>
<!-- Author: Sebastian -->


<!-- Date: Thu Jun 7 04:37:41 2007 -->
<pre>Now all ladders are back to normal operating conditions, all of the pinkies are unmarked. The data in SVXMON is looking OK, still not completely sure what caused the problem, seems to have originated in the PS Crate 7.</pre>
<!-- Author: Sebastian -->
<!-- Comment: Thu Jun  7 04;52;02 comment by...Sebatian -->
<pre>We lost with the whole ordeal about 25 minutes of data. Will have to find out how to do this faster next time.</pre>



<!-- Date: Thu Jun 7 08:53:55 2007 -->
The SVXMon slides are updated to match the current configuration with ISL B2 included in data taking.
<!-- Author: Jose -->


<!-- Date: Thu Jun 7 09:46:26 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11558&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11558  width='300' align='top'></a></td><td>There are indications  that <b>ISL PCW</b> is the next in line to give problems. It has shown a steady build up in pressure at the COT face over the last 3 months (DPT follows closely PT). Lately the pressure has increase its fluctuations. Because of the pressure increase  we had to adjust to lower flows in this line. Yesterday we compromised on 1.42 lpm (down from 1.47 lpm). This causes the PCW temperatures to be 0.5 C higher but stable. Looking at the flow it does not look like the e-valve is closing itself, the drops sseem to be due to readjustments. (It could be opening a bit, though). There is also evidence that the e-valve is not in the best shape, it seems to open a lot with a 1 % increase around 55 %. This  has caused a couple of trips lately.  The e-valve has not been cleaned,  nor exchanged, so I think this is a logical thing to do. On the other hand  it could very well be that a leak is slowly developing as it did in ISL PCE, so we  have to be extra-careful with this line, I would not do  RoR/massaging. </td></tr></table>
<!-- Author: Ignacio -->


<!-- Date: Thu Jun 7 09:50:21 2007 -->
There was a resonance but LA was not running. Left it armed.
<!-- Author: Ignacio -->



<!-- Date: Thu Jun 7 13:30:49 2007 -->
Sudden jump on DVDD globally in the SVX/ISL/L00. The jumps in the current can be observed in the whole detector, but some of them show much more clear than others the effect.  
When it happened, we were going through Config and b0svx05 failed config. The ACE aborted the run several pinkies appeared. 
<pre> 
27  L00   B0    W1    L1   0    0    0 MARKED by IMON 12:03 
45  L00   B0    W2    L1   0    0    0 MARKED by IMON 12:03 
42  L00   B0    W2    L2   0    0    0 MARKED by IMON 12:03 
63  L00   B0    W3    L1   0    0    0 MARKED by IMON 12:03 
81  L00   B0    W4    L1   0    0    0 MARKED by IMON 12:03 
96  L00   B0    W5    L2   0    0    0 MARKED by IMON 12:03 
99  L00   B0    W5    L1   0    0    0 MARKED by IMON 12:03 
1796  ISL   B2    W0    L2   0    0    0 MARKED by IMON 12:03 
</pre> 
See the plots in the CDF <a href=http://www-cdfonline.fnal.gov/cgi/internal/elog/elog.pl?nb=2007&action=xe&page=473&time=12:37:34.830>e-log</a> 
  
<!-- Author: Ignacio/Jose -->
<!-- Comment: Thu Jun  7 13;47;05 comment by...Jose -->
This behaviour was observed some previously <a href=http://www-cdfonline.fnal.gov/cgi/internal/elog/det-system-elog.pl?nb=silicon&action=copyentry&page=232&time=10:55:48>e-log</a> in that case was b0svx07 that had problems together with the TSI.


<!-- Date: Thu Jun 7 15:18:24 2007 -->
<pre>We are starting shot setup now, the stack is at 227 so it should be  a good store. Protons are begining to be loaded</pre>
<!-- Author: Sebastian -->


<!-- Date: Thu Jun 7 15:41:54 2007 -->
<pre>This is the condition of the beam-permit program, should it have the errors it shows? 
 
BeamPermit BeamPermit_m   daa980 200 PEND+T       27a5f8   daa8d8  3d0004  4526</pre>
<!-- Author: Sebastian -->
<!-- Comment: Thu Jun  7 18;28;13 comment by...Ignacio -->
I think it is OK. We get  "errors" everytime the permit is dropped (i.e. between stores) while BeamPermit checks every 2 minutes if anything is ON. 
<!-- Date: Thu Jun 7 17:34:24 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11559&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11559  width='300' align='top'></a></td><td>The new store, #5480 is in, the losses are low, below 400, SVXMon plots look ok, here is the usual spymon plot. Thankfully there was a low integrated dose to the detector during shot setup. The Initial luminosity was 162 E30, the initial L1 accept rate was 14,677 HZ and initial L2 accept rate is 534.5 Hz </td></tr></table>
<!-- Author: Sebastian -->

<!-- Date: Thu Jun 7 17:38:21 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W0L2 
<li>problem n: 2083 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Increased 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>57</td><td>57</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.0</td><td>125</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Jun 7 17:41:42 2007 -->
There was one BIAS svx pinki where the current went slightly over the limit, I changed the limits as shown in the entry before this one. Also I was hoping that ladder SB0W6L4 which we changed the trip limit yesterday would behave better, but is has a BIAS current well above its IMON limit still. This one is slated for a power supply swap according to Jen, so I am still ignoring it
<!-- Author: Sebatian -->



<!-- Date: Thu Jun 7 18:36:34 2007 -->
We should power cycle e152 the next time we get an opportunity. 
<!-- Author: Ignacio -->
<!-- Comment: Thu Jun  7 18;47;43 comment by...Sebstian -->
<pre>Why?....</pre>


<!-- Comment: Thu Jun  7 23;24;29 comment by...Jose -->
That was the red ladder in SVXMon. 
<!-- Comment: Fri Jun  8 13;41;39 comment by...Ignacio -->
I powercycle this wedge. Let's see.
<!-- Date: Thu Jun 7 19:52:30 2007 -->
Crate 13 spontaneously switched off. I recieved an automatic message on the beeper and called the control room. The Ace hockerized crate 13 while the run was halted and recovered.  
Then she powered by crate the affected ladders. Now everything is up and running, not too much time lost, less than 10 minutes. I am not sure why the spontaneous swithch off of crate 13 happened. This was not caused by any trip in any of the ladders.
<!-- Author: Sebatian -->



<!-- Date: Thu Jun 7 23:33:58 2007 -->
There was a resonance today at 18:20. Standard looking, no weird long RBSY. LA rearmed.
<!-- Author: Ignacio -->


<!-- Date: Fri Jun 8 08:37:11 2007 -->
The temperature of CCE2L6_2OUT  shows a step up from 6.6 C to 8 C and down to 7 C again after half an hour. This is the  line from which we were taking out ladders lately following the path of CCE1.1 but it does not have any ladders attached now since it is in the east. CCE2L6_2IN goes from 5.2 C to 5.6 C and does not come down. CCE3L7_4IN from 4.8 C to 5.2 C. The rest of the temperatures and pressures are flat. Bubble? 
<!-- Author: Ignacio -->


<!-- Date: Fri Jun 8 08:48:44 2007 -->
Ulrich reports that ISL PCW is already fluctuating close to the warining limit of 1.3 lpm.  
<pre> 
                  PCW1 PCW2 PCW3 PCW4
Ref temperature   8.80 7.80 8.60 7.00 
Temperature now   9.18 8.20 8.88 7.47 
</pre>  
<!-- Author: Ignacio -->


<!-- Date: Fri Jun 8 10:10:25 2007 -->
<pre>There was a pinky DVDD pinky in SB0W5L2 while run control was taking d-mode calibrations. Ignacio says this is normal during calibrations and now we are back to normal. The dmode calibrations are finished and we are going back to a physics run.</pre>
<!-- Author: Sebastian -->


<!-- Date: Fri Jun 8 10:26:15 2007 -->
b0sili01 has stopped mounting /home/cdfsoft. We tried several  combinations of stop and start of nfs, autofs and mounting by hand that did not work.   /home/cdfsoft became visible after rebooting b0sili01. <b>nfs does not start automatically in b0sili01, you have to restarte it by hand.</b>  
<!-- Author: Jose/Ankush the pirate/Ignacio -->
<!-- Comment: Sun Jun 10 00;20;03 comment by...Satyajit -->
If you have root/suid access to ncdf209, then the fool-proof 
method is to:
/etc/init.d/autofs restart ; /etc/init.d/nfs restart
first on the server (ncdf209) followed by the same on the client
(b0sili01) computer.
<!-- Comment: Sun Jun 10 00;25;37 comment by...Satyajit -->
The <i>nfs</i> is not auto-starting on b0sili01 is because:
<br>% /sbin/chkconfig --list nfs
<br>nfs    0:off   1:off   2:off   3:off   4:off   5:off   6:off
<p>All you need to do is (or ask a sysadmin to)
<br>/sbin/chkconfig [--level 5] nfs on

<!-- Date: Fri Jun 8 12:48:24 2007 -->
The store is finished, the HV is down to standby and we are waiting for the new store. Nothing to report
<!-- Author: Sebastian  -->


<!-- Date: Fri Jun 8 13:30:44 2007 -->
Tevatron is loading protons, the prediction is to have the store before 3pm.
<!-- Author: Sebastian  -->

<!-- Date: Fri Jun 8 13:33:29 2007 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 468
Calibration type  : standard
Run period tag    : Jun_2007
DPS-off run       : 243116
DPS-on run        : 243115
Requested by      : Petteri Meht�l�
Main process id   : 4277
Comment           : mount problems now fixed
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->




<!-- Date: Fri Jun 8 14:40:23 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11560&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11560  width='300' align='top'></a></td><td>New store # 5481 is in, the SVXMon plots look good. The loses are low, Silicon is ramped on without problem. The initial instantaneous luminosity is 201 E30. The initial L2 accept rate is 579 Hz. Here is the usual ocupancy plot</td></tr></table>
<!-- Author: Sebastian -->


<!-- Date: Fri Jun 8 17:33:42 2007 -->
I have lowerer the iFix warning/alarm limits for the flow ISL PCW. They were at 1.3/1.2 lpm, they are now at 1.0/1.1 lpm. Watch the temperatures...
<!-- Author: Ulrich -->
<!-- Comment: Fri Jun  8 18;21;06 comment by...Ignacio -->
<pre>
 ssh svxii@b0gateway.fnal.gov "/cdf/onln/home/svxii/MPCsetup/extract_temp.pl ISL_TE_PCW1_IN"
</pre>
I modified Ulrich script to pass the label of the temperature sensor as an argument. The temperature readings  we are  interested  are   ISL_TE_PCW1_IN,ISL_TE_PCW1_OUT,ISL_TE_PCW2_IN and ISL_TE_PCW2_OUT.
Now let us  get paranoid (for a change).

<!-- Date: Fri Jun 8 18:26:12 2007 -->
<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 468 finished successfully.

Job info
--------
Calibration type : standard
DPS-off run      : 243116
DPS-on run       : 243115
Requested by     : Petteri Meht�l�
Submitted        : 2007-06-08 13:33:01
Completed        : 2007-06-08 18:26:01
Status           : SUCCESS
Comment          : mount problems now fixed
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->


<!-- Date: Fri Jun 8 18:59:45 2007 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 469
Calibration type  : standard
Run period tag    : Jun_2007
DPS-off run       : 242058
DPS-on run        : 242056
Requested by      : Petteri Meht�l�
Main process id   : 31412
Comment           : test for many times failed
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->


<!-- Date: Fri Jun 8 20:12:44 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W10L0 
<li>problem n: 2084 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Changed IMON limits, after going ping in a 110 E30 luminosity pre-scale change<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>48.9</td><td>48.9</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>125</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W10&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Jun 8 20:18:06 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W1L0 
<li>problem n: 1891 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Further increased limit to avoid pinly at pre-scale change<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>90.0</td><td>100.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>120.0</td><td>130.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W1&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Jun 8 20:18:56 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W1L0 
<li>problem n: 1891 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Made a further increase in the limit<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>100.0</td><td>100.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>120</td><td>130</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W1&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Jun 8 20:20:11 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W9L0 
<li>problem n: 1884 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Increased limits after a pre-scale change<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>120.0</td><td>120.0</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.0</td><td>150.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W9&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Jun 8 20:23:05 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W4L0 
<li>problem n: 1747 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Increased limits slightly after a pre-scale change pinky<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>101.1</td><td>101.1</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.0</td><td>160.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W4&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Jun 8 20:27:15 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W11L0 
<li>problem n: 2085 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Increased limits slightly after a pre-scale change pinky<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>37.5</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>100.0</td><td>125.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W11&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Jun 8 20:29:19 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W1L4 
<li>problem n: 2086 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Increased limits slightly after a pre-scale change pinky<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>54.5</td><td>100.0</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.0</td><td>125.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W1&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Jun 8 20:32:41 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W9L0 
<li>problem n: 1884 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Increased limits slightly after a pre-scale change pinky<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>120.0</td><td>120.0</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.0</td><td>160.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W9&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Jun 8 20:34:45 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W6L1 
<li>problem n: 2087 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Increased limits slightly after a pre-scale change pinky<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>44.45</td><td>100.0</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.0</td><td>125.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W6&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Jun 8 20:37:36 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W1L0 
<li>problem n: 1863 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: carron 
<li>description is: Increased limits slightly after a pre-scale change pinky<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>100.0</td><td>100.0</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.0</td><td>130.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W1&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Jun 8 20:39:39 2007 -->
<pre>I have slightly changed the BIAS IMON limits for a bunch of ladders that went pink after the 110 E30 prescale change. All of the changes can be seen in the entries above </pre>
<!-- Author: Sebastian -->


<!-- Date: Sat Jun 9 02:09:55 2007 -->
<pre>I had lots of problems now. I was paged by the control room to deal with a series of tripped wedges. I arrived and it seemed it was necessary to hockerize crate 7, then the same happened for crate 2 and I fumbled a bit on making a coldstart, taking more time that I should have. then a few individual layers continued to trip and after Jose called me we tried powering on by wedge, and doing the coldstart of the fib crate (instead of powering by layer as I was trying before he called me), this worked better, it seems powering by wedge behaves better. Then after releasing the partition, the run control tried to restart a run and that failed because svx05 was failing to config. Jose called me again at that point and we tried config with a coldstart configuration for the whole silicon system. That worked and after releasing the partition the main run control was finally able to start a new run. This could have been solve a little faster had I been more expedient and experienced</pre>
<!-- Author: Sebastian -->
<!-- Comment: Sat Jun  9 02;19;53 comment by...Sebastian -->
<pre>Also IMON had to be restarted, it had frozen during this whole ordeal</pre>


<!-- Comment: Sat Jun  9 12;22;39 comment by...Ignacio -->
Looking at the PS log it seems that the 16 wedges that tripped initially all belong to b0fib02 (only 2 out of 18 did not trip).
<!-- Date: Sat Jun 9 08:17:28 2007 -->
<pre>The store has been dumped, The silicon is in standby</pre>
<!-- Author: Sebastian -->


<!-- Date: Sat Jun 9 08:20:01 2007 -->
D0 will have a 1 hour access, cant we use the hour to also change our rx's and power supplies that needed changing?
<!-- Author: Sebastian -->
<!-- Comment: Sat Jun  9 13;04;08 comment by...Sebastian -->
<pre>Well, we didn't do it.</pre>
<!-- Date: Sat Jun 9 13:03:29 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11561&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11561  width='300' align='top'></a></td><td>The new store #5483 is in, the initial luminosity was 160 E30, there was a low integrated radiation dose and the beam looks stable. THe silicon is on, with no problems ramping up. There are initial problems with L2 it appears and we were only able to take data briefly. The SVXMon plots looked ok.</td></tr></table>
<!-- Author: Sebastian -->


<!-- Date: Sat Jun 9 19:00:55 2007 -->
<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 469 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 242058
DPS-on run       : 242056
Requested by     : Petteri Meht�l�
Submitted        : 2007-06-08 18:59:37
Completed        : 2007-06-09 19:00:42
Status           : FAILURE
Comment          : test for many times failed

Last processing stage reported : waiting for data files
Failure diagnostics :
Data file not found for run 242058.
ls: No match.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Sat Jun 9 23:11:55 2007 -->
Normal looking resonance. LA rearmed.
<!-- Author: Ignacio -->


<!-- Date: Sat Jun 9 23:30:16 2007 -->
The control room called me with an apparent trip in SB0W0, I  
arrived a few minutes later and hockerized the PS crate 7, when 
trying to partition in coldstart fib00 failed to partition, I  
connected to fib00 which was pingable and seemed to be running ok, rebooted it anyway and then the partition on it was successful, followed to recover the powered off wedges and do another coldstart. After that all was ok and I released my partition so that the ace could start a new run. The whole process took about 15 minutes. Both Jose and Ignacio realized from their homes by looking at the elog of the situation and called me at the control room while I was recovering the trip. 
<!-- Author: Sebastian -->
<!-- Comment: Sun Jun 10 10;52;36 comment by...Sebastian -->
<pre>This is actually LB0W0, sorry for the confusion</pre>
<!-- Date: Sun Jun 10 09:41:13 2007 -->
Shot setup again, now the stack is around 350 so it should be a high luminosity store. I was paged by the control room and now am waiting for final aantiprotons to be loaded
<!-- Author: Sebastian -->


<!-- Date: Sun Jun 10 10:43:11 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11562&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11562  width='300' align='top'></a></td><td>The new store 5484 is in. The initial luminosdity was 220 E30. Initial L2 accept rate of 420 Hz, No problems during shot setup, no significant radiation loss, no problems turining on the silicon. In looking at the SVXMON, we see the S1W5L5 as red, this is the same we saw red a few days ago, looking at the bit reported with the CO, which was an old silicon expert, we found that some of the bits are high. In the problem database there are somneentry about this ladder which talk about high bits too. Perhaps it could be possible to fiddle with the chip settings during quiet time to try to fix it, or otherwise try an RX swap in an access. Appart from that everything is ok. Here is the usual occupancy plot.</td></tr></table>
<!-- Author: Sebastian -->
<!-- Comment: Sun Jun 10 11;00;58 comment by...Sebastian -->
<pre>Again  The yellow ladder is S1W5L2, not S1W5l5</pre>


<!-- Comment: Sun Jun 10 11;07;13 comment by...Sebastian -->
<pre>Meant red ladder, this ladder is red, the yellow ladder is an ISL problem</pre>
<!-- Date: Sun Jun 10 11:02:57 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11563&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11563  width='300' align='top'></a></td><td>This is the yellow ladder we are seeing in the SVXMon </td></tr></table>
<!-- Author: Sebastian -->
<!-- Comment: Sun Jun 10 11;06;31 comment by...Sebastian -->
<pre>We also have this yellow IB0W2L1</pre>


<!-- Comment: Sun Jun 10 11;34;55 comment by...Sebastian -->
<pre>Now the ladder has turned green, after an HRR. no problem anymore</pre>


<!-- Date: Sun Jun 10 19:58:36 2007 -->
<pre>Two things that did not go in the elog before, one was that there was a warning i nthe ISL cooling, but it was because of the conductivity, so I set it to be ignored. And the other was that  
b0fib0-5 was unresponsive, but this is used for the currently unused half of ISL, so it is not a problem. ignacio pointed out that this fib should not be in the run configuration at all, and  
rebooted it anyway. He pointed also that the RT server would have 
to be rebooted, but only after the store is done, and I expect that to be sometime tomorrow morning.</pre>
<!-- Author: Sebastian -->


<!-- Date: Sun Jun 10 22:39:53 2007 -->
The control room crew reports a trip and a auto0-hockerization in crate 9. The auto hockerization recovered the HV's nicely
<!-- Author: Sebatian -->


<!-- Date: Mon Jun 11 05:26:50 2007 -->
After a pre-scale change the control room called me about too many resonance errors, in fact since the pre-scale change we have had 5 resonance errors. We are running now at a L1 trigger rate of 25 kHz that seems a little high. Looking at the Logic analyzer it looks like a normal resonance. I am rearming the LA. I am not sure what could be causing the higher than usual L1 accept rate, the only difference seems to be that one of the reference plots for the IMU trigger canvas is red which could point to a hotter than usual L1 trigger. 
<!-- Author: Sebastian -->


<!-- Date: Mon Jun 11 05:28:33 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11564&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11564  width='300' align='top'></a></td><td>Here are the instances of resonance errors </td></tr></table>
<!-- Author: Sebastian -->


<!-- Date: Mon Jun 11 05:35:46 2007 -->
Now  it seems the L1 trigger has cooled down  a little and we are not getting resonaces anymore, if we get into the same condition as before I will take out the silicon
<!-- Author: Sebastian -->


<!-- Date: Mon Jun 11 09:33:10 2007 -->
Week Shift summary: 
 <ul>
   <li>Monday: There was an access to have nitrogen flowing through the ISL east cooling pipes, also there where a bunch of tests on the ISL CCE.  The results where that the nitrogen purge of ISL PCE was successful and the supply of CCE$ shows a tight seal. On monday there was also a swap of the power supply for LB0W5 to fix a severely dropping AVDD.  
 
   <li>Tuesday: The main story of the day was that after shot setup there was a large jump in the number of particles in the abhort gap, once things looked ok we put in the silicon but the abhort gap shor up again even though the MCR said they were done with modifications to the beam. There were a few worrying pinkies, specifically one with a large jump in AVDD current in SB3W7L2, which was fixed by HRR's, however it kept oscilating, looking at the history we found out that Jen had the power supply corresponding to this ladder marked for swapping. 
 
    <li>Wednesday: This day there was a quench of a very long store, the radiation dose was low.  We saw ladder L0W0L2 give some CAP ID out of order errors. This ladder still needs observation. But the big story of the day was the meting down of the ice blockage in the ISL west. This was successful but there were a few scares with the chiller compressor tripping, but it was all recovered nicely at the end. The West side od the ISL is included after this and looks good!!. 
 
    <li>Thursday: Ladder SB0W6L4 had a very big jump in bias current, very close to the tripping limit, this prompted us to change the trip limits for it (we doubled it), all of the remainder of the week the current looked high, we have not re-set the bias trip limit to the original value for this ladder yet. There was also a trip in L00 that required a hockerization, but it was recovered after some tribulation. There was a  
new store 5480 that started without problems.  
 
    <li>Friday: Not much to report except problems with mounting b0sili01, and the end of te store and a new store 5481, I changed a few IMON limits to avoid pinkies at pre-scale changes 
 
    <li>Saturday; I had a problematic tripp, was  little confused and hokerized more crates than necessary, eventually we got the silicon back up. End of the store 5481 
 
    <li>Sunday: New store 5483. There was a trip in fib00, another hockerization, it was recovered at the end, another store was in 5484 and there was a problem with 5 resonances.  
 
      <br>Thats the week. 
 
  
</ul>
 
<!-- Author: Sebastian  -->


<!-- Date: Mon Jun 11 10:19:34 2007 -->
<h3> ADC Monitering Summary (Run242764-243253) </h3> 
I have checked ADCMon plots during this week from run242764 to 243253.  
<br>  
I will report the ladders which have a issue and intersting work.   
The other ladders look fine.  
<br> 
<li> SB0W10L4 : shows unstable behavior, fluctuating 0-90% errors.  
<li> SB2W5L0  : suddenly appears 100% error in several runs. 
<li> SB4W3L3  : shows unstable behavior, fluctuating 20-60% errors. 
<li> IB2W0-2 : These ladders have been working since run243033, look like ok.  
<!-- Author: takayuki -->

<!-- Date: Mon Jun 11 10:37:04 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W0L2 
<li>problem n: 1490 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: This ladder is largely error free. The incident with CAP_ID errors happened on 06/05/07 during a few short runs. Let's keep an eye on this ladder for some time before declaring fixed. 
<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: Mon Jun 11 10:39:48 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W11L2 
<li>problem n: 1993 
<li>Status: needs_access
<li>Type: RX
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Bit error is reproduced during quiet time. Needs an access to do a fiber swap to check if it's an RX problem. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W11&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Jun 11 10:49:05 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W2L0 
<li>problem n: 868 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: The error rate is <10%. Errors are intermitent. It appears that errors only show up at chip 82 (chip 83 is OK). Moreover, chip ID is immediately followed by d0d0 indicating that it might be a VRB problem. We need to check VRB. It's also worth mentioning that this ladder was affected by kicker pre-fire and z-side is lost.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W2&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Jun 11 10:54:57 2007 -->
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: Same problem as in the previous entry. Chip a3 is useless and needs to be sparsed out. 
<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 -->