<!-- Title: 11:09:32  Mon Sep 18 2006 -->
<!-- Crewchief: Oscar (MPC) -->
<!-- Op1: Ankush (SPL) -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Goal of the week: take data... </pre>

<!-- Date: Mon Sep 18 11:13:56 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W1L3 
<li>problem n: 1519 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: <pre>Bumping up upper IMON Bias limit for this ladder.</pre><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>135</td><td>140</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>140</td><td>200</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W1&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Sep 18 14:11:59 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W5L3 
<li>problem n: 1760 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: <pre>Changing limits in IMON because value just above the limit cause a pinkie</pre><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>33</td><td>50</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=B3W5&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Sep 18 14:14:45 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W7L0 
<li>problem n: 1700 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Limits adjusted because they increased just above the current high end in IMON<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>67</td><td>70</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>150</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W7&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Sep 18 14:49:54 2006 -->
<h3> SVXMon patch </h3> 
 
It was found that one of the last patches 6.1.4v of SVXMon was behaving in a strange way (<a href=http://www-cdfonline.fnal.gov/cgi/internal/elog/elog.pl?nb=2006&action=copyentry&page=631&time=11:26:12.755>e-log</a>). After some debugging it seems that the problem comes from two files that have a non-initialized variables. Up to this is fixed, a working version can be obtained using the previous version of these files: 
<br> 
<pre> 
cvs co -r 1.37 TrackingObjects/src/TRYRun2SiStripSet_nndata.cc 
cvs co -r 1.25 TrackingObjects/TrackingObjects/Trybos/TRYRun2SiStripSet.hh 
</pre> 
<br>  
<!-- Author: Jose and Mark -->

<!-- Date: Mon Sep 18 17:00:39 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W1L0 
<li>problem n: 1761 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: This ladder is pinkie in BIAS0 with a value just above the limit. Changing limits in IMON.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>78</td><td>80</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>100</td><td>110</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W1&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Sep 18 17:25:54 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9904&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9905  width='300' align='top'></a></td><td>SB4W7L3 was reported during the day shift to have AVDD current equal to zero. Data seemed fine so we wait until the end of the datataking to hockerize the crate CAEN PS 13. Seems to be fine after that.</td></tr></table>
<!-- Author: Oscar/Ignacio -->


<!-- Date: Mon Sep 18 18:00:33 2006 -->
I have made a couple of changes to 
<a href='http://www-cdfonline.fnal.gov/cgi/internal/elog/det-system-elog.pl?nb=silicon&action=copyentry&page=318&time=18:31:08'>  MPCsetup</a>. </a> 
<li> There is an additional screenshot of the PSGUI window alone. Still one need a kerberos ticket. So if you need to refresh you have to issue ./makescreenshot.sh from the MPCsetup directory</li> 
<li> The B0AC++dump <a href='https://www-cdfonline.fnal.gov/internal/ops/svxii/dump_raw/dump_raw.html'>web page</a> has now a button to run the program (it takes a couple of minutes, be patient) and another to parse it.</li> 
The scripts are in the  directory b0sili01:/home/svxii/MPCsetup
<!-- Author: Ignacio -->


<!-- Date: Tue Sep 19 04:18:08 2006 -->
Due to the late work... I posted two entries in the previous e-log instead of the current one (I guess at 1am I am not that good with too many tabs in mozilla). I remade the entries here: 
  
<!-- Author: Oscar -->


<!-- Date: Tue Sep 19 04:19:15 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9908&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9909  width='300' align='top'></a></td><td>New store finally came in, it is number 4963 and it started with an initial lumi of 211E30. 
SVTSPYMon plot looks fine. Still a couple of yellows in SVXMon that I checked they provided data... just need some time to integrate events.</td></tr></table>
<!-- Author: Oscar -->
<!-- Comment: Tue Sep 19 04;19;59 comment by...Oscar -->
This happened at 01:01am, in fact :)


<!-- Date: Tue Sep 19 04:20:50 2006 -->
I was called on the phone because b0fib06 became red in the RC. The ace already tried the flow-chart procedure but it has failed. I was requesting to repeat the procedure step by step and seems to work. No idea why it failed the first time.<br> 
The ace told me that the first time he tried to vxlogin to the crate, connection was refused and he reset/shepherd the crate. 
He also indicated that a couple of warning/error message were given by the crate when rebooting. I asked to paste those in the e-log (he misunderstood me, since he posted the whole rebooting log...).<br> 
It seems they are running normally now. 
<!-- Author: Oscar -->


<!-- Date: Tue Sep 19 07:27:31 2006 -->
I was paged this morning because of several pinkies in BIAS. They are all just above the limits, so I will change the high end.<br> 
In addition, I set SB5W0L2 to IGNORE again. It is becoming pink all the night (I asked the aces to make a global unmark when they had a lot of pinkies when the troubles with b0fib06).
<!-- Author: Oscar -->

<!-- Date: Tue Sep 19 07:30:53 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W0L3 
<li>problem n: 1510 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: The current for BIAS1 went right above the limits. Raising the high end in IMON.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>145</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>160</td><td>170</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: Tue Sep 19 07:34:34 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W0L4 
<li>problem n: 809 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: The bias current of this ladders has a large increase with time. It just went above the limits. I redefine the IMON limits to avoid a pinkie, but keep the ladder in observation.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>111</td><td>111</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>150</td><td>175</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B2W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Sep 19 07:37:16 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W2L3 
<li>problem n: 1314 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Change high-end limit in IMON due to increase of the BIAS1 current, that went right above the limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>61</td><td>65</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>150</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B1W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Sep 19 07:58:29 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9910&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9911  width='300' align='top'></a></td><td>SB3W7L2 was still unstable during the night. HRR from RC tends to change the AVDD and DVDD values up and down.</td></tr></table>
<!-- Author: Oscar -->

<!-- Date: Tue Sep 19 08:28:30 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W1L1 
<li>problem n: 1762 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Changed IMON limits for BIAS to avoid a pinkie. Current value is just above the limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>63.8</td><td>63.8</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>100</td><td>120</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Sep 19 08:31:12 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W6L1 
<li>problem n: 1763 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Raise the high-end limit for BIAS in IMON to avoid the pinkie. Current value is just above the limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>64.4</td><td>64.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>100</td><td>120</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W6&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Sep 19 08:34:25 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W8L0 
<li>problem n: 1701 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Limits were reached again for BIAS. To avoid pinkie in IMON, I raise the limits.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>102</td><td>101</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>120</td><td>150</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W8&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Sep 19 08:36:47 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W1L2 
<li>problem n: 1218 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: New limits set in IMON to avoid a pinkie in BIAS. Current value just above the high-end.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>122</td><td>122</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>127</td><td>150</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Sep 19 11:53:29 2006 -->
<h3>TEL2 Commissioning</h3> 
Willis came to the silicon office this morning to inform us that the commissioning of the new Tevatron electron lens (TEL2) will be taken one step further. Tests are planned, in which the TEL2 is operated for half of the store. 
We met with Ron Moore to learn more about the tests and their impact on the Silicon. He explained that source of the quench, a power supply for the electron gun which sparked at 7 kV has been replaced with a new supply that does not deliver more than 5 kV. The test itself consists of TEL2-induced tne changes to single Tevatron bunches (#12, maybe also #11). For these bunches we expect slightly higher proton losses during the test.<p> 
So we decided to keep the Silicon in for the tests but asked the shift crew o page us when the tests commence. We will monitor the TEL2 current (T:L2COLI) and the losses in bunches #11 and #12 (C:B0PLOS[11], C:B0PLOS[12]) on the Fast Time Plotter for a while.  
<!-- Author: Ankush & Ulrich -->
<!-- Comment: Tue Sep 19 17;16;38 comment by...Ulrich -->
So the first test will be in the middle of the night:
<pre>
16:32:30-  We are considering two hours of TEL2 studies from 6am to 8am. TEL2 experts would like CDF and D0 to stay on if possible. We would then terminate the store at 8am. I will provide a more detailed collider plan later this evening. - B Drendel  
</pre>
<!-- Date: Tue Sep 19 13:02:32 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9912&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9912  width='300' align='top'></a></td><td>Event sizes at the EVBs from store 4960 courtesy of Conor.  The three largest are b0svx06-08 and are about what we expect.  Conor thinks they are fine for now. </td></tr></table>
<!-- Author: Mark -->


<!-- Date: Tue Sep 19 13:34:25 2006 -->
<h3>SB3W7 Power-cycled</h3> 
The AVDD current of SB3W7L2 has been dropping a couple of times again. During the last 1.5 hours it was stable though. We had some time during a plug power supply trip recovery, so I power-cycled the wedge anyway.
<!-- Author: Ulrich -->

<!-- Date: Tue Sep 19 13:37:46 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W1L0 
<li>problem n: 1605 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: Raising IMON limit for Bias1<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>130</td><td>150</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W1&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Sep 19 13:39:32 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9913&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9913  width='300' align='top'></a></td><td>Bias1 current for f310.</td></tr></table>
<!-- Author: Ulrich -->

<!-- Date: Tue Sep 19 14:05:55 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W7L1 
<li>problem n: 1764 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: Bumping up IMON limit for bias line of e271<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>57.0321</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>120.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W7&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Sep 19 14:09:03 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9914&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9914  width='300' align='top'></a></td><td>Bias current history for e271.</td></tr></table>
<!-- Author: Ulrich -->


<!-- Date: Tue Sep 19 19:24:57 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W0L0 
<li>problem n: 1715 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>Hit upper IMON liomits again.  Going to be more aggressive and use a much larger value.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>101.0</td><td>121.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>200.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B2W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Sep 19 19:28:06 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W0L3 
<li>problem n: 1688 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>Going for a preemptive upper IMON limit raise.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>127.0</td><td>170.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>170.0</td><td>200.0</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: Tue Sep 19 19:29:05 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W1L2 
<li>problem n: 1606 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>This is a premptive BIAS0 IMON limit raise.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>91.4538</td><td>115.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>115.0</td><td>200.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B2W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Sep 19 19:31:09 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W2L0 
<li>problem n: 1721 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>Going for a preemptive BIAS current raise.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>106.937</td><td>130.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>130.0</td><td>200.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W2&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Sep 19 23:30:25 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9915&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9916  width='300' align='top'></a></td><td><h3>FIB got wacked</h3> 
 
<p>Just got called by the SciCo for a bunch of yellow cells in SVXMon.  Looks like the usual FIB- SEU we have seen before.  I advised the ACE to start a new run. Hopefully that will fix it: cross your fingers !!</p></td></tr></table>
<!-- Author: Ankush -->
<!-- Comment: Tue Sep 19 23;59;09 comment by...Ankush -->
<p>bugger it looks much worse...I just check the raw data and there were lots of d0 for f323...the ladder which is currently yellow.  So the VRB was not dropping the GLINK fill characters for this ladder...weird!!</p>

<p>As one quickfix, I told them to stop the run again.  I then logged in to svx07 and rebooted it in the vain hope it may fix the VRB. Keep your fingers really crossed this time !!</p>


<!-- Comment: Wed Sep 20 00;16;47 comment by...Ankush -->
<h3>Wrong!!: The VRB went kaka</h3>

<p>So rebooting SVX07 did the trick.  This time it was the VRB which was went bad. In the raw data you could see none of the fill characters were being stripped.  There were lots of d0d0 and a long string c4c4.</p>

<p><em>
(Unfortunatly I ran siDumpNow before I cut-N-pasted the raw data
and erased the raw data dump with this in...sorry).
</em></p>

<p>The ISL ladder IB3W2L3 dumps its data into a VRB in SVX07.  So I gambled that a reboot would fix it and reinitialise the VRB.  It seemed to do the trick and now the yellows are gone.</p>

<p>At the end of the store, it may be prudent to swap out the offending VRB (VRB_60, slot 20, SVX07) since it may be going bad.  Also during last week&#39s BUSY_TO studies, there were VME bus errors from SVX07.  This VRB *may* have been the cause.</p>


<!-- Comment: Wed Sep 20 09;57;10 comment by...Ankush -->
<h3>FIB 2 VRB Test</h3>

<p>After the beam was dropped, Oscar and I did a FIB 2 VRB test.  After 100k events, there were no errors reported.  So we put this off to one of those rare VRB freak outs.</p>

<h4>Blond Wig Moment</h4>

<p>So after a night sleep, I had a rethink about what I did.<br> First point was it really necessary to end the run to reset the FIB?<br>
The answer is no.  The correct thing would have been to go to HALT.  Then take the bad FIB to ABORT and the CONFIG.  The CONFIG  would download the chip sequences.<br>
<br>
Did the <em>soft</em> reboot help ?<br>
No<br>
When I realised it was a VRB problem, the VRB has to be reinitialised.  A reboot from logging into the crate only resets the CPU.  It doesn&#39t do anything to the VRBs.  Today Oscar and I confirmed this.  Oscar rebooted the CPU and I watched the lights on the VRB.  The VRB lights did not show any VME activity. The correct way would have been to do a hard reset which is pressing the reset button on the crate CPU.  This asserts the VME reset on the VME bus, so this is a real hardware reset.  
<br>
An alternative would be to take the bad VRB crate through CONFIG.   This requires ending the run and then starting a new one.  No need to reboot the crate CPU.
</p>

<p><em>here endeth the lesson...I assume the blond one would approve.</em></p> 





<!-- Date: Wed Sep 20 05:18:14 2006 -->
Just for the records:<br> 
<br> 
- I was called before they called Ankush about the yellows in SVXMon. I told the ACE to reboot fib07, but it didn't help. I was not aware of restarting of the run for this situation.<br> 
<br> 
- They called me when they finished the XFT tests they were doing during the owl shift to check whether it was fine to include Silicon with a L1Accept rate of 29 KHz. I gave my OK since I remember someone told me below 35 KHz we are fine (is this number correct?). However, I told them to call me if any problem (I guess resonance error in RC) appear.<br>
<!-- Author: Oscar -->


<!-- Date: Wed Sep 20 08:38:16 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9918&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9918  width='300' align='top'></a></td><td><h3>Impact of TEL2 studies</h3> 
Oscar came in for the TEL2 studies and watched the losses in the bunches we expected to be affected (P11 and P12). He could see something in P11 but no change in P12. 
The TEL2 studiers documented their results in the  
<a href="http://www-bd.fnal.gov/cgi-mach/machlog.pl?nb=bbc&page=165&time=8:13:21">Beam-Beam Compensation e-log</a>. They actually worked on P10 and P11, not on P12. The plot on the left shows the proton losses for these bunches, which show a small but noticable increase during the studies. The losses are small enough not to represent a problem for the silicon.</td></tr></table>
<!-- Author: Ulrich -->
<!-- Comment: Wed Sep 20 08;53;21 comment by...Ulrich -->
Ok, maybe I should explain a little more. The TEL2 studies went on from 6:00 to 8:00. The plot covers 4:00 to 8:00. There is slightly more activity after 6:00. I have checked all other bunches, and they are all uniform over the entire period.



<!-- Comment: Wed Sep 20 14;58;22 comment by...ronmoore -->
Actually, they timed the flattop of the e-pulse in to P12, but the rising edge affected P10 and P11, too.
<!-- Date: Wed Sep 20 12:38:22 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9921&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9922  width='300' align='top'></a></td><td>New store, 4964 with initial CDF luminosity of 234E30. The SVT SPYMon plot looks fine. Waiting for the CO to bring the SVXMon plots up. </td></tr></table>
<!-- Author: Oscar/Ankush -->
<!-- Comment: Wed Sep 20 13;01;17 comment by...Oscar -->
SVXMon plots looks fine. Still one ISL yellow cell, the one that is always taking ages to get green. I checked the detailed plots from SVXMon and that there is data coming from this guy. It should be fine in a while.



<!-- Date: Wed Sep 20 15:19:51 2006 -->
<h3>Aggghhh: A FIB in b0FIB05 has gone bad!!</h3> 
 
<p>Oscar was paged as b0fib05 was red in run control and they were getting a lot of PINKYs.  Oscar helped them out by following the standard flow-chart.  They got to the point where they needed the shepard the crate.  However during the shepard they were a bunch of VME BUS errors.  At this point Oscar got hold of me.</p> 
 
<p>I came in and decided it was not good.  So they started a run without Silicon.  I looked at the crate and COLDSTART would not work...the crate would not pass PARTIION.  I then tried a reset_crate.  This did not help either.  I then aksed the Cryo tech to power cycle the rack...this did not help either.</p> 
 
<p>From the reboot, we could see the FIB in slot 9 was not responding.  So we excluded the card from the crate. However this still did not help as the crate could not pass PARTITION.  So the whole FIB crate cannot be used.</p> 
 
<p>For the time being, we have implemented this policy:<br> 
- ACES exclude FIB05 from any run with silicon<br> 
- Data for SVX is GOOD.  Data for ISL/L00 is BAD<br> 
</p> 
 
<h4>Things to remember</h4> 
 
<p>In diagnosing the problem we did the following changes: <br> 
<pre> 
- excluded FIB in slot 9 from the HWDB <br> 
      - changed ONLINE flag from 1 to 0 in cardEditor<br> 
- excluded f42* and f43* from the HWDB <br> 
- rewrote CAENVolt.dat: So wedges f42* and f43* are OFF <br> 
      - NB: f423 was already out  <br> 
      - NB: f431, f432, f433 was already out <br> 
</pre> 
</p> 
 
 
We then tried to exclude the FIB in 
  
<!-- Author: Ankush, Oscar, Ulrich, Jose & Marcel -->


<!-- Date: Wed Sep 20 16:25:42 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9923&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9924  width='300' align='top'></a></td><td><h3>Pinky for SB1W1L4</h3> 
 
<p>This ladder started giving a PINKY in AVDD.  This would normally be the indicator of a chip loss. I asked for an HRR and that has not helped.  The next step would be a power cycle but I just checked SVXMon.  There is no evidence of any chip losss: it looks fine.  As a futher check, I looked at the raw data amd this ladder looks fine.  So for the time being I will refrain from a power cycle.</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Wed Sep 20 18:46:59 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9925&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9925  width='300' align='top'></a></td><td><h3>Bias PINKY for LB1W1L3</h3> 
 
<p>The BIAS current for this ladder has just gone over its upper IMON limit.  However as this is a L00 ladder, I did some further investigation.  The current for ths ladder has an odd behaviour.  It seems to periodically rise and fall. But the overall 'DC' value appears to be increasing.</p> 
 
<p>For the time being I will raise the upper IMON limit by a small amount.  That should avoid the now-annoying BIAS pinky alerts.</p></td></tr></table>
<!-- Author: Ankush -->

<!-- Date: Wed Sep 20 18:49:24 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W1L3 
<li>problem n: 1310 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>I have bumped up the upper IMON limit for BIAS1 a bit.  A graph of the local BIAS history can be found in the <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=319&frame=2&anchor=18:46:59'> Silicon e-log</a>.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>60.4908</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>120.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B1W1&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Sep 20 18:53:05 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9926&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9927  width='300' align='top'></a></td><td><h3>Recent AVDD history for SB1W1L4</h3> 
 
<p>During this store, the AVDD current suddenly dropped but with no obvious change in the ladder performance. This graph shows the recent AVDD history where the current has crept back up. As the current is now out of the PINKY region I have unignored it.</p> 
 
<p>But I am unsure what caused the initial sudden drop.</p> 
 
 
</td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Wed Sep 20 19:11:07 2006 -->
<h3>Word up on the upcoming access</h3> 
 
<p>Those of you following the drama will know a FIB board in b0fib05 crate went bad.  Willis already told us our 1.5hr access was approved.  </p> 
 
<p>In the meantime, the MCR also have their own problems.  They have a wet engine at A4 which has an alleged He leak <em>(hmmm...sounds familiar)</em> from a frosted up the piston.  The pressure for the wet engine is at 9psi.  If it exceeds 11psi, the store will be lost/dumped very quickly.  For the moment they are going to try to ride through this to the end of store. When the store is dropped, they will need a 4 hours access to fix it (which is convenient for us :-) ).  </p>
<!-- Author: Ankush -->


<!-- Date: Wed Sep 20 21:19:52 2006 -->
<h3>Tev Quench !!!</h3> 
 
<p>Tev just quenched at F17L.  The <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=695&frame=2&anchor=21:08:05.571'> 
BLM plots</a> look fine and the detector went through COLDSTART with no problems.</p> 
 
<p>I have just primed all the troops for a possible access.  We are now waiting to hear back from MCR whether we are allowed to go in.</p>
<!-- Author: Ankush -->


<!-- Date: Wed Sep 20 23:45:43 2006 -->
<h3>FIB exchanged, does not initialize</h3> 
Here is what b0fib05 complains about during COLDSTART: 
<pre> 
	 **** 	 Not Using Broker 	 **** 
 
Slot 9 Hdi 0 Expected 394 Bytes Found 4096 Bytes 
Error Downloading HDI Slot 9  Chan 0 Addr 00 Err Code 0x01890000 
HDI Error ISL B4W2 
Sl 9 Ch 0  393 Errors initing hdi 0 
Slot 9 Hdi 1 Expected 394 Bytes Found 4096 Bytes 
Error Downloading HDI Slot 9  Chan 1 Addr 01 Err Code 0x01890000 
HDI Error ISL B4W2 
Sl 9 Ch 1  393 Errors initing hdi 1 
Slot 9 Hdi 2 Expected 394 Bytes Found 4096 Bytes 
Error Downloading HDI Slot 9  Chan 2 Addr 02 Err Code 0x01890000 
HDI Error ISL B4W2 
Sl 9 Ch 2  393 Errors initing hdi 2 
Slot 9 Hdi 4 Expected 394 Bytes Found 4096 Bytes 
Error Downloading HDI Slot 9  Chan 4 Addr 04 Err Code 0x01890000 
HDI Error ISL B4W2 
Sl 9 Ch 4  393 Errors initing hdi 3 
Slot 9 Hdi 5 Expected 394 Bytes Found 4096 Bytes 
Error Downloading HDI Slot 9  Chan 5 Addr 05 Err Code 0x01890000 
HDI Error ISL B4W3 
Sl 9 Ch 5  393 Errors initing hdi 4 
Slot 9 Hdi 9 Expected 394 Bytes Found 4096 Bytes 
Error Downloading HDI Slot 9  Chan 9 Addr 09 Err Code 0x01890000 
HDI Error ISL B4W3 
Sl 9 Ch 9  393 Errors initing hdi 5 
Failed to Initialize Fib: Error 0x003f0000 
Mess Error Type 3f0000 Num 273 
 
Error in Msg Initialization: 003f0000 
 
Exiting Loop because end of message 
Not Using Broker Right Now 
Publishing Init Config... 
Done Publishing 
Mess Error Type 3f0000 Num 279 
Crate Id         78 
Output->EVB/VRB  0/2 
Done mode        0 
NElements        2 
Verbosity:       Minimal 
  BankName        ISLD,0  Mini 6  Type 1 
  Max:1  BLT:0  IgnBC:0  ROL:0  Slots:0x008700 
  BankName        SIXD,0  Mini 1  Type 1 
  Max:1  BLT:0  IgnBC:0  ROL:0  Slots:0x002000 
 
Mess Error Type 3f0000 Num 281 
Processing Config Message FailedSent ack to Run Control: 3 READY ERROR  
Error Initializing HDI Slot 9 HDI 0: ISL B4W2 
Error Initializing HDI Slot 9 HDI 1: ISL B4W2 
Error Initializing HDI Slot 9 HDI 2: ISL B4W2 
Error Initializing HDI Slot 9 HDI 4: ISL B4W2 
Error Initializing HDI Slot 9 HDI 5: ISL B4W3 
Error Initializing HDI Slot 9 HDI 9: ISL B4W3 
Statechange failed  
</pre>
<!-- Author: Ulrich -->
<!-- Comment: Thu Sep 21 00;18;16 comment by...Ulrich -->
Swapped in the second spare FIB, and everything is fine now. We ran COLDSTART and SVXDAQ without problems. but <b>HOW COME WE HAVE A BAD SPARE FIB???</b>

<!-- Comment: Thu Sep 21 01;11;15 comment by...Ankush -->
<p>I agree with Ulrich&#39s statement.  We wasted about 40 minutes of access time and were unnecessarily worried.  Is this pointing to hole in our testing procedures ?</p>
<!-- Comment: Fri Sep 22 08;56;33 comment by...SCN -->
Hmm, how about <h3>Did you check the sequences in the Fib?</h3>
I'd give you about a 70% chance that the sequences were for DEMs not ladders.<br>
(once there was a checkout list to prevent these things, maybe there still is?)

<!-- Date: Thu Sep 21 00:42:39 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W2/3All 
<li>problem n: 1765 
<li>Status: needs_observation
<li>Type: Wedgewide_other
<li>Action: Swap_FIB
<li>entered by: amitra 
<li>description is: <p>During data taking the FIB for this wedge (fib05, slot 9) went bad.  During reboot it would issue VEM Bus Error.  Even when the FIB was masked from the HWDB, it would still give VME Bus Error.  This would prevent the whole crate going through PATITION in run control.</p><table border=1>
   <tr>
    <td>
     <b>IN:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?serial="></a>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?prep=145">145</a>
    </td>
   </tr>
   <tr>
    <td>
     <b>OUT:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?serial="></a>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?prep=122">122</a>
    </td>
   </tr>
  </table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W2/3&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Sep 21 01:02:44 2006 -->
<h3>A little more detail about the access</h3> 
 
<p>When we went into the collision, we had a good idea the FIB in FIB05, slot 9 went bad.  In the collision hall, we found the 5V LED for FIB05,slot 9 was off.  So it was a good chance the 5V line fuse for the board had blown.  This was FIB #122</p> 
 
<p>The first FIB we tried was FIB #150 which gave us the original trouble. It was marked as a good spare yet in the collision hall it gave us some very strange behaviour</p> 
 
<p>FIB 150 was swapped for FIB 145; the b0 test stand FIB.  We were forced to use that FIB as there were no other spare FIBs at CDF.</p> 
 
<p>As we now have zero FIBs, we will have to take the FIB from FCC.  In the meantime we have to chase up the FIB repairs from PREP.  They currently have 3 to repair and we will be giving them another two.</p> 
 
<p>To satisfy my paranoia, I did a FIB 2 VRB test and it ran error free after 100k events.</p> 
 
<p>One of the strage things with FIB 150 was the failed FIB 2 VRB test.  It would fail on random channels and the errors looked odd.</p>
<!-- Author: Ankush -->
<!-- Comment: Thu Sep 21 01;06;57 comment by...Ankush -->
<p>as futher paranoia satisfaction, I took the detector through COLDSTART and went to ACTIVATE.  Apart from the BUSY-TO problem, it ran fine.</p>


<!-- Comment: Thu Sep 21 01;20;12 comment by...Ulrich -->
Good, that's what we did before, when you guys were still in the collision hall. Double paranoia...


<!-- Date: Thu Sep 21 09:27:33 2006 -->
<h3>Just taken the last spare FIB!!</h3> 
 
<p>I just went to FCC and took our last spare FIB.  So both test stands have <b>NO</b> FIBs. I have spoken to Vince and told thme we need the 3 FIBs in PREP fixed ASAP.</p>
<!-- Author: Ankush -->


<!-- Date: Thu Sep 21 10:46:51 2006 -->
<h3>Just moved PS-GUI off b0dasvx03 to b0dsvx01</h3> 
 
<p>To allow some work on the PC upgrades, I have moved PS-GUI off b0dasvx03 to b0dasvx01.</p>
<!-- Author: Ankush -->

<!-- Date: Thu Sep 21 11:08:47 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W5L4 
<li>problem n: 1623 
<li>Status: uncooled
<li>Type: AVDD
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>I just looked at this ladder.  The current looks stable now.  In the bit reporter, there are no errors and the ADC sprectrum looks normal.  Declare this thread fixed.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Sep 21 11:32:28 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W10L3 
<li>problem n: 40 
<li>Status: fixed
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>In recent runs, this ladder has run error free and the ADC spectrum looks normal.  This ladder ran error after 10k events in RA in SVXDaq. But it did give some 00 sequence errors in NN mode.  However this was 62/10k = 0.62%.  This is a very small number.</p>  <p>So I am going to call this fixed.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W10&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Sep 21 11:56:17 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W2L4 
<li>problem n: 1423 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: amitra 
<li>description is: <p>In recent runs, the ladder has been running error free.  The ADC spectrum looks good.  So I'll give this back to the monitoring group.  If they see it running error free then call this thread fixed (again).</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W2&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Sep 21 12:33:43 2006 -->
<h3>FIB Testing</h3> 
This morning we tested the FIB 122, the one that <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=319&frame=2&anchor=15:19:51'> 
failed yesterday</a>, as well as FIB 150 which was swapped in for FIB 122, but <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=319&frame=2&anchor=23:45:43'> 
still gave errors.</a>  Summary of results are: 
<ul> 
<li> The first step was to check FIB 103 which was previously in the FCC teststand.  It has all the write firmware and sequences and passed the HighSpeed test, so it is our control.   
<li>For FIB 122 we measured the resistance of the 7 and 10 amp fuses and found that the 10 amp fuse had blown.  George gave us a replacement fuse and after putting that in we could put this fib in the teststand without hosing the VME bus.  We found that verification of firmware fails on the first chip which is the Micro-Sequencer command processor.  We also tried reading registers on all of the FPGAs and found that this was the only one that always returned ffff.... So the theory is that this FPGA got scrambled, went into a high current state and blew the fuse.  We will take it to prep and ask them to replace this chip. 
<li>For FIB 150, we verified that it has the proper firmware and sequences, which were fine.  When we ran the high speed test we saw errors where there is a c2c2 instead of a c1c1 at the end of the data stream for channel 2.  This error only shows up 0, 1 or 2 times at the very beginning of the HighSpeed test, so it could be missed.  Recall that this same type of error was <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=289&frame=2&anchor=19:45:30'> 
seen for FIBs 119 and 162</a>, and they are still at Prep.  For FIB 119 the same errors were seen on channels 0 and 2.  Prep replaced the delay chip for channel 0, but not channel 2 and the errors seemed to disappear from channel 0 only, so I took it back and asked them to do the same for channel 2.  We still do not have FIB 119 back. The plan is to see if we can reproduce the errors seen when FIB 150 was swapped in, by running it at the FCC teststand.  After that we hand it off to Prep. 
</ul>
<!-- Author: Jose, Ignacio, Tuula, Mark -->
<!-- Comment: Thu Sep 21 16;03;33 comment by...Jose, Ignacio & Mark -->
We submitted 122 to prep.  We tested 150 in the FCC teststand and initialization failed intermittently for channels 0-2 although they ran error free.  Tomorrow Jose and Ignacio will verify that this initialization failure is not seen with a good FIB.
<!-- Date: Thu Sep 21 14:08:05 2006 -->
<h3>b0dasvx03</h3> 
We are shutting down b0dasvx03 for a few minutes to test our new raid controller cards.
<!-- Author: Mark -->
<!-- Comment: Thu Sep 21 14;22;19 comment by...Mark -->
Back up.  The raid controller cards fit fine.


<!-- Date: Thu Sep 21 15:28:48 2006 -->
<h3>Morning Quiet Time Work</h3> 
 
<p>Here is a summary of the quiet time work done today: 
 
<ul> 
 
<li><b>f002</b> : Just for fun I tried this ladder again.  It still doesn&#39t return any data.  It also trip son DVDD Overcurrent.  But that could due to the bad supply we put in there as part of the ISL power-supply swap fest.</li> 
 
<li><b>e554</b> : This had a problem of a wandering AVDD current.  However the current looks stable now.  The BitReporter is clean for this ladder and the ADC spectrum looks normal.  So this PDB thread was closed.</li> 
 
<li><b>e4a3</b>: This ladder was reported to be giving errors. However it has run error free in recent runs.  The BitReporter is clean and the ADC spectrum is normal.  This ladder was tested in SVXDAQ and ran error free after 10k events in RA mode.  However the ladder started giving errors in NN mode.  It always gave errors of "00 sequence errors: 127, 94".  But the rate was 64/10k=0.62%.  This is very low.</li> 
 
<li><b>e053</b>: The <em>init readback</em> is still bad.</li> 
 
<li><b>e224</b>: There have been no errors in recent runs and ADC spectrum looks normal.</li> 
 
</ul> 
 
</p>
<!-- Author: Ankush -->



<!-- Date: Thu Sep 21 16:24:58 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9928&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9929  width='300' align='top'></a></td><td>New store, 4967 with initial luminosity of 161E30.<br> 
The MCR was having problems during the scraping: they retract the collimators twice and take very long to give us the OK for raising HV. Scico called them and they told him that something was not going fine. In fact they suggested us to wait in case store was lost.<br> 
Finally they called to give the OK and we start taking data. So far, no problem on our side.</td></tr></table>
<!-- Author: Oscar -->

<!-- Date: Thu Sep 21 16:27:20 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W1L3 
<li>problem n: 1519 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Rasing BIAS1 limit in IMON to avoid pinkie. Current went just above the limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>145</td><td>145</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>200</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W1&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Sep 21 19:05:13 2006 -->
<h3>IMON restarted</h3> 
 
<p>IMON was running <em>really</em> slow.  So I restarted it.  Recently IMON seems to be running more slowly.  This has been observed by mnay other people.  However the code has not been changed for many years.  So I guess some else is affecting it.</p> 
 
<h4>....and now for something completly different</h4> 
 
<p> I almost screwed up the elog by putting an entry to define the word <a href="http://www.chambersharrap.co.uk/chambers/features/chref/chref.py/main?query=wobbly&title=21st"> 
wobbly</a>.  However it pasting the link and adding the html hyperlink, I screwed up the elog.  Fortunatly advanced edit form the SciCo console fixed things up. However I did end up with a lot of egg on my face.</p>
<!-- Author: Ankush -->
<!-- Comment: Thu Sep 21 23;31;37 comment by...TTL -->
<pre>screw up sili e-log? that was precisely the idea (we discussed this at lunch).  to see how many people's live really depend on it...on site or off site... young or old... retired or new born ... please give it another try.</pre>

<!-- Comment: Fri Sep 22 08;23;15 comment by...Ankush -->
<p>..I should make a point of clarification: I was referring to the main shift elog rather than our precious silicon elog.</p>
<!-- Date: Fri Sep 22 08:10:06 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W1L2 
<li>problem n: 1766 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Raising the BIAS-0 limits in IMON because the value went just above the upper limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>74</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>100</td><td>150</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->





<!-- Date: Fri Sep 22 09:44:12 2006 -->
<h3>Tev lost the store!!</h3> 
 
<p>So the Tev lost the store again....something to do with a CAMAC linl.  The shift crew did the post-quench check out.  The <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=700&frame=2&anchor=09:23:04.437'> 
BLM plots</a> look fine for us.  Interestingly all the FIFO outputs are aligned.  Hopefully it will stay like that.  COLDSTART was also OK.</p> 
 
 
<p>While we have no beam, I powercycled SB3W7L2.  This is an attempt to stabilise the AVDD current for it.  We shall see in the next store if it does any good.</p> 
 
  
<!-- Author: Ankush -->

<!-- Date: Fri Sep 22 10:13:25 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W6L4 
<li>problem n: 345 
<li>Status: needs_access
<li>Type: Optical_other
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>This ladder has a BIT 7 stuck low problem.  It screws up the chips IDs but it is unlikely to have a large effect on the data.  Also this bit can be corrected offline.  One could try an RX which has a good BIT 7 sensitivity.</p>  <p>If a long access comes up and we have no other pressing problems, one could try to seap a new RX in.  But I doubt whether this will do any good.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W6&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Sep 22 11:08:27 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W0L0 
<li>problem n: 893 
<li>Status: fixed
<li>Type: Unknown
<li>Action: Init_RB_mask
<li>entered by: mhartz 
<li>description is: test 
<li>See <a href="http://b0sili02.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Sep 22 12:07:43 2006 -->
<h3>SRC Errors seen this morning</h3> 
 
<p>Earlier today, a bunch of SRC errors were seen noted by the DAQ ACE. See 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=700&frame=2&anchor=08:16:58.119'> 
here</a> in the elog.  Unfortunatly I did not have the logic analyser hooked up, so I am not able to investigate the cause.  My guess is a clock-glitch but there is no evidence.</p> 
 
<p>I have rearmed the logic analyser.</p>
<!-- Author: Ankush -->
<!-- Comment: Fri Sep 22 12;17;00 comment by...Ankush -->
<p>according to the error-logger these are the reported errors.</p>

<pre>
(MLE) b0control21.fnal.gov:Thread-27:Sep 22, 2006 08:11:35 AM->FrontEnd Crate Error Condition from:
VRB_SVX_02

(MLE) b0control21.fnal.gov:Thread-27:Sep 22, 2006 08:11:35 AM->FrontEnd Error: VRB_SVX_02 
(MLE) b0control21.fnal.gov:Thread-27:Sep 22, 2006 08:11:42 AM->  Silicon Level 1 Done Timeout Error from SVX, ISL or L00

(MLE) b0svx05:Messenger:Sep 22, 2006 08:11:48 AM->Silicon Resonator: Sl 12 Ch 7 -> e552: Bytes: 00114

(MLE) b0svx00:Messenger:Sep 22, 2006 08:11:48 AM->Silicon Resonator: Sl 16 Ch 9 -> e074: Bytes: 00166

(MLE) b0svx08:Messenger:Sep 22, 2006 08:11:48 AM->Silicon Resonator: Sl 18 Ch 3 -> f823: Bytes: 00780

(MLE) b0svx07:Messenger:Sep 22, 2006 08:11:48 AM->Silicon Resonator: Sl 16 Ch 3 -> fa03: Bytes: 00780

CT: 2006.09.22 08:11:48
11'48" b0svx02:Messenger:Sep 22, 2006 08:11:48 AM->SRC Fatal Error:Sl 6 Resonance Detected 
 -->  
 Additional Information: 

 Attention !!!. FERML_SRC_FATALITY ERROR !!! 
 
 SRC Fatal Error from b0svx02: Sl 6 Resonance Detected 
 
 - HALT the run                   
 - record any relevant information in e-log     
 - RECOVER - RUN     
[MLE]
CT: 2006.09.22 08:11:51
11'51" RXPT Error LOOP !!! Disabling AUTOMATIC HRRs.[EH Info]
(MLE) b0felix.fnal.gov:TEDCpp:Sep 22, 2006 08:11:51 AM->{ 8:11:51, 9/22/2006 }: L2-Pulsar-Linux: Halted while  waiting for SVT data
(RC)   8:11:52 Halt -> HALTED
</pre>

<p>So nothing special.  Just looks like the normal errors you see for a resonance.</p>

<p>But according to Daryl (DAQ ACE), this what he saw:</p>

<pre>
1.)Front end crate error for b0svx02 
2.)RXPT Error for crate/s: b0svx02   
3.)L1 Done Timeout 
4.)RXPT Error for crate/s: b0svx02   
5.)Attention !!!. FERML_SRC_FATALITY ERROR !!!   
   SRC Fatality Error for b0svx02: Sl 6 Resonance Detected  
6.)Attention!!!.   RXPT Errors LOOP!!
</pre>

<p>The two don&#39t seem to match...hmmm....</p>

<!-- Comment: Fri Sep 22 12;27;21 comment by...Ankush -->
<p>sorry, scratch what I just wrote...they do match.  But the question is why is "L1 DONE TIMEOUT" now being reported during a resonance. I believe this was not reported before the shutdown.  We did see this after the shutdown but that was during the L1 Burst phase. So we were never sure. Now we are seeing this for "normal" resonances, I believe something has changed....hmmmmm.</p>




<!-- Comment: Fri Sep 22 16;18;17 comment by...Mark -->
The L1 Dones show up as early as run 205075, which is 10/05/2005.  Of course we don't know if those were "real" resonances or not.
<!-- Date: Fri Sep 22 13:01:27 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9930&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9931  width='300' align='top'></a></td><td> </td></tr></table>
<!-- Author: Silicon Veterans For Truth -->
<!-- Comment: Fri Sep 22 15;51;29 comment by...Lady in Pink :-) -->
YAY!
<!-- Date: Fri Sep 22 15:47:50 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W0L1 
<li>problem n: 1560 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Raising the IMON limit for BIAS-0 to avoid a pinky. The current is just above the limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>86.5</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>160</td><td>200</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B2W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Fri Sep 22 15:54:59 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9934&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9935  width='300' align='top'></a></td><td>New store 4970, with a luminosity of 170E30. Everything looks fine. </td></tr></table>
<!-- Author: Oscar -->



<!-- Date: Fri Sep 22 17:47:21 2006 -->
<H1>TORNADO!!!!!!!!!!!!!!</H1> 
 
<P>TORNADO WENT OFF...WE ARE IN THE SHELTER NOW</P> 
 
<P>WE ARE O</P>
<!-- Author: THE SILIS -->
<!-- Comment: Fri Sep 22 18;51;37 comment by...The silis -->
<p>We survived...praise the maker</p>


<!-- Date: Fri Sep 22 19:00:47 2006 -->
<h3>Heads Up: Possible 12 hour access next week</h3> 
 
<p>I just heard from Willis that D0 have requested a 12 hour access to fix their silicon.  The very tentative plan is next Wednesday.  Start thinking about all those odd jobs you always wanted to do in the collision hall.</p>
<!-- Author: Ankush -->


<!-- Date: Fri Sep 22 19:02:56 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9936&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9936  width='300' align='top'></a></td><td><h3>Bias0 current for IB2W0L2 is going up</h3> 
 
<p>The Bias0 current for IB2W0L2 has just exceeded its upper IMON limit.  I will increase it for now.  But you can see from this history plot that it has started shooting up again.</p></td></tr></table>
<!-- Author: Ankush -->

<!-- Date: Fri Sep 22 19:05:02 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W0L2 
<li>problem n: 1601 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>Had to bump up upper IMON limits again for Bias0.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>76.717</td><td>161</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.0</td><td>200.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B2W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Sep 22 19:37:01 2006 -->
<h3>RF station tripped off</h3> 
 
<p>A RF station tripped off.  Shift crew immediatley put Silicon to STANDBY and paged Oscar.  Artur then came ot the silicon office to find me still in there.  So I took charge of the situation.</p> 
 
<p>I asked them to start a new run without silicon while I waited for the beam conditions to settle.  After ~10-15mins, everything looks fine. So we are now starting a run with Silicon.</p> 
 
<p>According to MCR, the RF trip may have been related to the recent thunderstorm/tornado.  Apparently it rained <b>a lot</b> while the Tornado passed over Fermilab.</p>
<!-- Author: Ankush -->


<!-- Date: Fri Sep 22 19:47:53 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9938&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9938  width='300' align='top'></a></td><td><h3>Losses during RF Trip</h3> 
 
<p>As soon as the RF station was lost, B0PAGC shoots up striaght away but then returns to safe value after 1 minutes.  AGIGI2 also shoots up but it takes ~2 minutes for it to recover.</p> 
 
<p>However the new run with Silicon was started at 19:38, 15 minutes after the RF station lost.  I guess I could have started the run earlier, or just stayed in HALT.  But you never know you these things pan out.</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Fri Sep 22 23:20:41 2006 -->
<h3>Temperature in CCE1.1 on the rise</h3> 
I just found in the 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=701&frame=2&anchor=22:52:05.975'> 
main e-log</a> that CCE1L6_1OUT has increased from around 20&deg;C to around 21&deg;C. According to the temperature log file, this happened between 22:10 and 22:30. Let's hope the temperature is stable there. Otherwise we will have to take out f401.
<!-- Author: Ulrich -->
<!-- Comment: Sat Sep 23 08;22;31 comment by...Ulrich -->
The owl shift monitoring ace realized that we forgot to update the IMON reference plot when we took out f403.
<!-- Date: Sat Sep 23 01:10:41 2006 -->
I was paged because iFix was setting a trigger inhibit from SB3W2L1. It was indicating a zero bias voltage. However, IMON and PSGUI did not indicate any sign of a trip or problem.<br> 
One of the ACEs, Martin, told me Ankush had the same situation last week and fixed the problem by hockerizing the crate for that ladder. Since there was not better option, we tried that, hockerized Crate 10, and after the ACEs recovered all the ladders that went off, data taking was resumed with no further problem.
<!-- Author: Oscar -->
<!-- Comment: Sat Sep 23 10;45;55 comment by...Ankush -->
<p>the details of what I did last week can be found <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=318&frame=2&anchor=07:49:18'>
here</a> is last week&#39s elog.</p>

<p>In case this repeats one should do the following:
<ol>
<li>Check the iFIX Silicon inhibits page.  Main iFIX page-->Misc-->Silicon inhibits.  I hear during Rainer&#39s reign, this page was always up.  It may be time to do this again.</li>
<li>Now you should know what is causing the inhibit.  Then the next step to put some of the pieces together.  So check IMON and the PS-GUI full status....then check the PS logging files if you need to.  The course of action needed will be determined by what you find.....ie: you have to think!!</li>
</ol>

So I looked at the latest PS log files. I first looked up the codes  (/cdf/onln/data/svxii/data1/datalog/ps/quickPSview.table) for SB3W2L1.
<pre>
 909 "SB3W2L1 DVDD"
 910 "SB3W2L1 AVDD"
 911 "SB3W2L1 VBIAS0"
</pre>
Looking at the PS log files (/cdf/onln/data/svxii/data1/datalog/ps), with a bit of grep-ing,
I figured out what happend.

<pre>
grep ' 911' 20060923.si_

 911  0 -32765    96.00    91.00
 911  0 -32765    96.10    91.00
 911  0 -32765    96.00    91.00
 911  0 -32765     0.00    91.00
 911  0 -32765     0.00    90.00
 911  0 -32765     0.00    89.00
 911  0 -32765     0.00    88.00
 911  0 -32765     0.00    87.00
 911 -1      0     0.00     0.00
 911  0 -16381    14.60    17.00
 911  0 -16381    30.90    32.00
 911  0 -16381    46.90    45.00
 911  0 -16381    63.40    54.00
 911  0 -16381    75.20    59.00
 911  0 -32765    88.90    64.00
 911  0 -32765    96.00    68.00
 911  0 -32765    96.00    69.00
 911  0 -32765    96.00    71.00
 911  0 -32765    96.00    72.00
 911  0 -32765    96.00    74.00
 911  0 -32765    96.00    75.00
 911  0 -32765    96.00    76.00
 911  0 -32765    96.00    77.00
 911  0 -32765    96.00    78.00
 911  0 -32765    96.00    80.00
 911  0 -32765    96.00    81.00
 911  0 -32765    96.00    82.00
 911  0 -32765    96.00    83.00
 911  0 -32765    96.00    84.00
 911  0 -32765    96.00    85.00
 911  0 -32765    96.00    86.00
 911  0 -32765    96.00    87.00
 911  0 -32765    96.00    88.00
 911  0 -32765    96.00    89.00
 911  0 -32765    96.00    90.00
 911  0 -32765    96.00    91.00
 911  0 -32765    96.00    90.00
 911  0 -32765    96.00    91.00
</pre>
So you see code 911 is the Bias reading for SB3W2L1.  The fourth column is the voltage and the last column is the current.  At one point the bias voltage goes to zero without affecting the bias current.  This is unusual.  If the bias voltage really went to zero, one would expect the current to be zero (Ohms law).  There could have been a short-ciruit which could return zero volts but the current would be much higher.</p>

<p>So if you get a strange reading and SVXMon looks fine, hockerise the crate !!</p>

<p><em>Here endeth the lesson</em></p>
<!-- Date: Sat Sep 23 09:49:48 2006 -->
The store will be dropped at 17:00. We will get our DMode calibration at some point after 14:00. I will also look into the ISL cooling after the store is dropped.
<!-- Author: Ulrich -->


<!-- Date: Sat Sep 23 11:05:22 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W1L0 
<li>problem n: 1605 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Limits for IMON changed because BIAS-0 went just above the upper limit. <table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>121</td><td>121</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>150</td><td>200</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W1&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Sep 23 11:09:02 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W2L1 
<li>problem n: 1691 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Raising the upper limit in IMON to avoid a persistent pinky for BIAS-1 going just above the limit. Since previous entry remarks that this ladder may have been raising quickier than expected, I keep it in observation.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>??</td><td>85</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>150</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Sep 23 11:12:22 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9939&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9940  width='300' align='top'></a></td><td>BIAS-1 current for IB4W1L2 (f412). It was just above the limit, but still shows some erratic behaviour.</td></tr></table>
<!-- Author: Oscar -->

<!-- Date: Sat Sep 23 11:13:21 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W1L2 
<li>problem n: 1767 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Raising upper limit in IMON to avoid a pinky in BIAS-1. However, this current was showing a strange behaviour during last hours. Keep in observation.<br> You may find the plot  <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=319&frame=2&anchor=11:12:22'> in this link</a>   <table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>55</td><td>55</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>100</td><td>120</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Sep 23 11:18:43 2006 -->
IMON hanged, so I had to kill it and restarted again (in b0dasvx02). Seems to be fine now.<br> 
I set SB5W0L2 (e502) to ignore.
<!-- Author: Oscar -->

<!-- Date: Sat Sep 23 14:21:05 2006 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 447
Calibration type  : standard
Run period tag    : Sep_2006
DPS-off run       : 223500
DPS-on run        : 223499
Requested by      : Bruno
Main process id   : 24417
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->
<!-- Comment: Mon Sep 25 16;18;56 comment by...Jason Nielsen -->
<pre>This calibration job was hanging for a while.  It turns out the temporary text files which are written to the database were corrupted.  I regenerated the text files and wrote the constants to the database.  This calibration is a success.

</pre>
<!-- Date: Sat Sep 23 17:03:20 2006 -->
<h3>Hockerization and quiet time work on cooling</h3> 
While the shift crew ramped down the silicon, crate #8 lost communication and had to be hockerized. We will have 1 hour of quiet time, so I will start now to massage the cooling lines, I don't know if that will work out, but it is worth a try.
<!-- Author: Ulrich -->
<!-- Comment: Sat Sep 23 17;06;42 comment by...Ulrich -->
From the SVXINTER log:
<pre>
SAT SEP 23 16:56:51 2006  setPSStatus, detector = 2, ps_n = 6, status = 2
 setVoltages: Caenet_Write Error number ffffffff received 

Errcode 20

 cr_n = 8, bd_n = 7, channel = 10set_channel_info: err = 20, detector = 2, ps_n = 6
SetChannelStatus, err = 20
SAT SEP 23 16:56:54 2006 SetPSStatus -- SetChannelStatus, err = 20, detector = 2, ps_n = 6
SAT SEP 23 16:56:54 2006  setPSStatus, detector = 2, ps_n = 7, status = 2
Module is busy, sending code = 16
Module is busy, sending code = 16
Module is busy, sending code = 16
Module is busy, sending code = 16
Module is busy, sending code = 16
Module is busy, sending code = 16
Module is busy, sending code = 16
Module is busy, sending code = 16
 setVoltages: Caenet_Write Error number ffffffff received 

Errcode 20

 cr_n = 8, bd_n = 3, channel = 15SAT SEP 23 16:56:57 2006 SetPSStatus -- SetChannelStatus, err = 20, detector = 2, ps_n = 7
...
SAT SEP 23 16:57:29 2006 setDetectorStatus,err = 1, detector = 2SAT SEP 23 16:57:29 2006 setStatus,err = 1SAT SEP 23 16:57:29 2006 ERROR: trying to change detector status via iFix
SAT SEP 23 16:57:30 2006  Caenet_write: Error number -251 ffffff05 received
group_info:cr_n = 8, response = -251
SAT SEP 23 16:57:39 2006  Caenet_write: Error number -251 ffffff05 received
group_info:cr_n = 8, response = -251
SAT SEP 23 16:57:49 2006  Caenet_write: Error number -251 ffffff05 received
group_info:cr_n = 8, response = -251
SAT SEP 23 16:57:57 2006  Caenet_write: Error number -251 ffffff05 received
group_info:cr_n = 8, response = -251
SAT SEP 23 16:58:07 2006  Caenet_write: Error number -251 ffffff05 received
group_info:cr_n = 8, response = -251
SAT SEP 23 16:58:16 2006  Caenet_write: Error number -251 ffffff05 received
group_info:cr_n = 8, response = -251
SAT SEP 23 16:58:25 2006  Caenet_write: Error number -251 ffffff05 received
group_info:cr_n = 8, response = -251
SAT SEP 23 16:58:34 2006  Caenet_write: Error number -251 ffffff05 received
group_info:cr_n = 8, response = -251
SAT SEP 23 16:58:43 2006  Caenet_write: Error number -251 ffffff05 received
group_info:cr_n = 8, response = -251
SAT SEP 23 16:58:54 2006  Caenet_write: Error number -1 ffffffff received
group_info:cr_n = 8, response = -1
SAT SEP 23 16:59:05 2006  Caenet_write: Error number -1 ffffffff received
group_info:cr_n = 8, response = -1
SAT SEP 23 16:59:13 2006  Caenet_buffer: Error number 7 7 received
group_info:cr_n = 8, response = 7
SAT SEP 23 17:04:09 2006  setPSStatus, detector = 2, ps_n = 0, status = 2
</pre>


<!-- Comment: Sat Sep 23 18;31;59 comment by...Ulrich -->
<h3>Massage did not work</h3>
So I tried again to massage the cooling lines, again without success. The temperatures even ended up a little higher than before, unfortunately also in CCE2.2. So I decided to play safe and take out f401. Now the temperatures are 18.27&deg;C (CCE1.1) and 18.70&deg;C (CCE2.2). Just as a precaution, I also restarted the PS-GUI, rebooted SVXINTER and took the system through a coldstart.

<!-- Date: Sat Sep 23 18:34:06 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L1 
<li>problem n: 1697 
<li>Status: needs_observation
<li>Type: PC_Temperature
<li>Action: Removed_hdwdb
<li>entered by: husemann 
<li>description is: f401 had to be taken out again due to the cooling problem. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Sep 23 21:24:41 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W0L3 
<li>problem n: 1503 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Changed the limits on IMON for BIAS-1 due to pinky. I keep the monitoring state due to the previous entry.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>148</td><td>148</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>158</td><td>200</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: Sat Sep 23 21:27:54 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W0L4 
<li>problem n: 1506 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Changed the limits on BIAS-1 for avoiding a pinky in IMON. Keeps the previous status for monitoring of the current behaviour.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>121.6</td><td>125</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>150</td><td>200</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Sep 23 21:29:27 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9941&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9942  width='300' align='top'></a></td><td>New store, 4972 with an intial instantaneous luminosity of 170E30. Everything looks fine... the SVT SpyMon plot is as usual these days.</td></tr></table>
<!-- Author: Oscar -->
<!-- Comment: Sun Sep 24 09;13;14 comment by...Ulrich -->
It took three hours and the owl shift crew to find out that dynamic prescaling was disabled in the trigger and they were running on very small rate.


<!-- Date: Sun Sep 24 09:18:26 2006 -->
<h3>Another simultaneous jump of bias currents</h3> 
During the <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=705&frame=2&anchor=02:49:32.386'> 
owl shift</a>, several SVX and ISL bias lines went pink simultaneously: 
e021, e200, e360, e572, f314 (Bias0), f420 (Bias1).
<!-- Author: Ulrich -->


<!-- Date: Sun Sep 24 10:51:00 2006 -->
I was paged because they got another trigger inhibit from iFix complaining about a trip but no sign of that in the PSGui and IMON. As we did the previous time(s), we hockerize the CRATE (in this case 15 since offending ladder was LB1W4L2). This fixed the problem. I came to the control room to help on the recovering of the trips from the hockerization (just a guess it was faster if I do it... who knows if this is true).
<!-- Author: Oscar -->

<!-- Date: Sun Sep 24 10:59:54 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W2L0 
<li>problem n: 1768 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Raising the upper limit in IMON to avoid persistent pinky. The current goes just above the limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>68.3</td><td>68.3</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>110</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W2&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sun Sep 24 13:24:37 2006 -->
<h3>Very, very late summary of last week&#39s MPC week</h3> 
 
<p>I have just written my summary of my pager week which can be found <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=318&frame=2&anchor=13:22:33'> 
here</a>.  Many apologies for being so late....please do not follow my example!!</p>
<!-- Author: Ankush -->

<!-- Date: Sun Sep 24 18:02:26 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W1L4 
<li>problem n: 1598 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Again, need to raise the IMON limits to avoid a pink cell. I keep the observation status because of the previous entry. Current value is right above the limit (130).<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>77.34</td><td>77.34</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>150</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W1&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sun Sep 24 19:10:00 2006 -->
<h3>Monthly SVXMon reference slide update</h3> 
 
<p>I have just updated the SVXMon (long run) reference slide.  I have used the current run as a reference.</p>
<!-- Author: Ankush -->

<!-- Date: Sun Sep 24 22:56:48 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W8L0 
<li>problem n: 1497 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: boveia 
<li>description is: Bit 5 low for the past ~1 month, occasionally as prevalent as 90% of events in a given run. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W8&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Sep 25 09:15:44 2006 -->
<h2>Summary of the week</h2> 
 
<ul> 
 
<li> We had several stores with medium initial instantaneuos 
luminosity (for the current standards). No problems related to losses or beam conditions. 
</li> 
 
<li>A couple of quench and RF statition trip. Detector unaffected. 
</li> 
 
<li> Data taking during the week was smooth. Need to hockertize a few crates, especially due to the problem when no voltage is read and current is fine. 
</li> 
 
<li> SB3W7L2 turns pinky in IMON during data taking in AVDD because current drops below the lower limit (exact value is usually around 650). It recovers with HRR. 
Uli and Ankush tried to get it stable by powercycling the wedge but it did not work. 
</li> 
 
<li> The problem in ISL cooling line forced Uli to take anothe ISL ladder, IB4W0L1 (f401), out of the datataking. 
</li> 
 
<li> On Tuesday FIB07 showed problems that Ankush found it was due to the VRB (fill characters were being stripped). The problem was fixed rebooting b0svx07 (soft reboot) 
</li> 
 
<li> On Wednesday night we went into an access to replace a board on FIB05 (slot 9) that went bad. We tried to use the last spare but it didn't work properly, so we finally used the board in the B0 test-stand. 
<br> 
Due to this problem, during some hours we were taken without including b0fib05, i.e. 1/4 of the ISL and 1/4 of the L00. 
</li> 
 
<li> During a couple of days they did some TEL2 studies. No influence on our data taking. 
</li> 
 
</ul> 
 
- Open and staying troubles: 
 
<ul> 
<li> Monitor sometimes complains about TevMon losing LOSTP signal. ACNET seems fine and TevMon does not complain. 
</li> 
 
<li> SB3W7L2 keeps the aces busy doing HRR. 
</li> 
 
<li> Lots of BIAS pinkies. SB5W0L2 (e502) is still unstable and it is set to ignore all the time. 
</li> 
 
<li> Cooling line in ISL still troublesome. ACEs are monitoring temperature. 
</li> 
 
</ul>  
<!-- Author: Oscar -->


<!-- Date: Mon Sep 25 10:24:36 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9943&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9944  width='300' align='top'></a></td><td>e280</td></tr></table>
<!-- Author: boveia -->
<!-- Comment: Mon Sep 25 10;25;34 comment by...boveia -->
<pre>bit 5 low for e280 during a recent run.  wow, that's really low resolution.</pre>


<!-- Date: Mon Sep 25 10:29:23 2006 -->
<b>Monitoring Summary</b> 
<p> 
Fairly quiet week.<br> 
<ul> 
<li>e280 - some runs have bit 5 low for most events. 
</ul>  
<!-- Author: boveia -->