<!-- Title: 10:39:20  Mon Nov 12 2007 -->
<!-- Crewchief: Ignacio (MPC) -->
<!-- Op1: SashaS (Shadow) -->
<!-- Op2: Ricardo SPL -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
My last MPC week!


<!-- Date: Mon Nov 12 10:52:20 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11983&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11983  width='300' align='top'></a></td><td>The SVX air separator level has been dropping at almost the same rate as it had before.  The reduced sampling may be responsible for the change in rate, but we seem to lose coolant for other reasons too.</td></tr></table>
<!-- Author: Tom -->


<!-- Date: Mon Nov 12 10:55:43 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11984&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11984  width='300' align='top'></a></td><td>ISL loses coolant more slowly.</td></tr></table>
<!-- Author: Tom -->


<!-- Date: Mon Nov 12 14:06:05 2007 -->
The Proccess System people have finished installing the DI flowmeter. We should chcek tomorrow for iceballs.
<!-- Author: Ignacio -->


<!-- Date: Mon Nov 12 14:22:21 2007 -->
<h3> The draught is over!</h3> 
<ul>  
 <li> No more good-sleep nights </li> 
 <li> No more withdrawal syntoms </li> 
 <li> No more excuses </li> 
</ul> 
<h2>The coffee machine is back!!</h2> 
 
Fixing it costed two round trips to chicago, about 100 curses to fellow car drivers in rush-hour, and $132.12 including taxes.<br> 
Enjoy! 
 
 
  
<!-- Author: Ricardo -->
<!-- Comment: Mon Nov 12 18;03;14 comment by...Ankush -->
<p>Thank the maker !!! Owl shift will go by much, much more easily.</p>
<!-- Comment: Wed Nov 14 13;34;40 comment by...Marcel -->
<pre>you are a hero !</pre>
<!-- Date: Mon Nov 12 15:00:34 2007 -->
FTM board 0002 has been taken to PREP. This board was a cause of bit7 low for f311. We should expect it back in ~2 weeks.
<!-- Author: SashaP -->


<!-- Date: Mon Nov 12 15:04:41 2007 -->
They have lost half of the luminosity 10 minutes after declaring scrapping is done.  
<pre> 
--  Separator spark at B11 vertical lost 50% of luminosity.  
</pre> 
This one killed the store during the weekend. The other suspect is C49V.  
 
Good we were out.
<!-- Author: Ignacio -->


<!-- Date: Mon Nov 12 17:59:49 2007 -->
I asked the CO to restart SVXMON as they were looking at the past run. Also noticed that fa33 shows a flat occupancy varying between 10% and 70%. It looks as if only some percentage of the events are being read out. 
<!-- Author: Ricardo -->


<!-- Date: Mon Nov 12 18:00:03 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11987&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11988  width='300' align='top'></a></td><td>Store # 5716: we turned on Silicon ~2h after beginning of the store. Lumi ~35 at this point, Losses were ok, though LOSTPB had spikes. Ladder e124 tripped at AVDD/DVDD ovc. We powecycle this ladder and the the whole wedge. It did not help, so we decided to take it out in hwDB. SvxMon and SvtSpyMon plots look Ok</td></tr></table>
<!-- Author: Ignacio/SashaS -->


<!-- Date: Mon Nov 12 18:19:28 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W2L4 
<li>problem n: 1243 
<li>Status: needs_work
<li>Type: AVDD
<li>Action: Removed_hdwdb
<li>entered by: sukhanov 
<li>description is: We found  a  bent pin in the LV connector during an acces last Tuesday, so we gave it another try. However, it tripped again around 2 minutes after the start data taking.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W2&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Nov 12 18:29:55 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W2L3 
<li>problem n: 1958 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: Monitoring
<li>entered by: sukhanov 
<li>description is: We reseated the PS cables during the access last Tuesday. The bias current is still ~10 times higher than before the shutdown. There is an indication of a pin-hole in C8 of the Z side. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Nov 12 18:32:58 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W5All 
<li>problem n: 2460 
<li>Status: fixed
<li>Type: Wedgewide_other
<li>Action: PS_work
<li>entered by: ignacio 
<li>description is: The original PS of this wedge was put back on 11/06/07. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W5&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Nov 12 18:41:56 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L4 
<li>problem n: 2173 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: Monitoring
<li>entered by: ignacio 
<li>description is: ADCMon distribution indicates some physics.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Nov 12 18:53:08 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W0L4 
<li>problem n: 467 
<li>Status: needs_observation
<li>Type: RX
<li>Action: Monitoring
<li>entered by: sukhanov 
<li>description is: This ladder returns data after the RX swap last Tuesday. The ADCMon distributions look fine. Tomorrow we  will check the bit reporter. The raw data looks also error-free. 
<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: Mon Nov 12 18:56:32 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W1L3 
<li>problem n: 2180 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: ignacio 
<li>description is: Increase bias limit after shutdown.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>82.5</td><td>210</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>205.</td><td>250.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W1&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Nov 12 19:07:59 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W2L1 
<li>problem n: 1507 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Changing limits after shutdown<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>200</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>230</td><td>250</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Nov 12 19:10:49 2007 -->
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: sukhanov 
<li>description is: Changing limits after shutdown<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>151</td><td>200</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>230</td><td>250</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: Mon Nov 12 19:15:03 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W0L1 
<li>problem n: 2310 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Changing limits after shutdown<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>140</td><td>200</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>210</td><td>250</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Nov 12 19:17:51 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W1L3 
<li>problem n: 2324 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Changing limits after shutdown<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>200</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>155</td><td>185</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W1&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Nov 12 19:24:30 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W2L2 
<li>problem n: 2365 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Changing limits after shutdown<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>115</td><td>200</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>180</td><td>230</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W2&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Nov 12 19:26:48 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W3L0 
<li>problem n: 2377 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Changing limits after shutdown<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>40.1139</td><td>200</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>130</td><td>160</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W3&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Nov 12 19:32:44 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W0L3 
<li>problem n: 2212 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Changing limits after shutdown<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>180</td><td>200</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>230</td><td>260</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: Mon Nov 12 19:34:25 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W0L3 
<li>problem n: 2282 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Changing limits after shutdown<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>190</td><td>200</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>250</td><td>280</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: Mon Nov 12 19:44:00 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W0L3 
<li>problem n: 2402 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: ignacio 
<li>description is: Increase after the shutdown.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>120.</td><td>180</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>180.</td><td>220.</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Nov 12 19:46:04 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W3L1 
<li>problem n: 2438 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: ignacio 
<li>description is: Increase limit after shutdown.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>120</td><td>160</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>155</td><td>200</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W3&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Nov 12 19:54:28 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W1L1 
<li>problem n: 2417 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: ignacio 
<li>description is: Increase the limit after the shutdown.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>150.0</td><td>210.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>210.0</td><td>250.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Nov 12 20:34:53 2007 -->
Since Allison is going to include stero finding from XFT I have checked that the Logic Analyzer was running; it was not. For the record you just have to connect to ncdf205 as svxii (usual password) using remote desktop. Then you open one of the resonanace_*.ala files and ckick the green arrow buttom. I am also checking e494 AVDD current from IMON.
<!-- Author: Ignacio -->


<!-- Date: Mon Nov 12 21:32:00 2007 -->
I have switched OFF L00 for the separator studies.
<!-- Author: Ignacio -->
<!-- Comment: Tue Nov 13 01;27;18 comment by...Ankush -->
<pre>
Mon Nov 12 22:21:31 CST 2007     Interlock L00 EAST is enabled
Mon Nov 12 22:21:31 CST 2007     Interlock L00 WEST is enabled
Mon Nov 12 22:21:31 CST 2007     IFix -  success: Silicon ON
</pre>

<p>L00 was power back up at 22.21.</p>


<!-- Date: Tue Nov 13 01:31:54 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11989&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11990  width='300' align='top'></a></td><td><h3>Odd drop in bias for SB0W3L3</h3> 
 
<p>The Silicon PINKY alarm fired and so I did my pedestrian SciCo duty.  But with my ex-silicon hat, I was surprised to see the apparent fall and rise of the bais current around 1AM.  At first, one may presume this is Silicon going from ON to STANDBY and back again.  But this did not occur. To me this smells of some CAEN communication problem. </p> 
 
<p>The bias current rise seems smalls; looks like the monotonic increase of bias current with radiation.  So I'll bump up the IMON limit after double checking with the PDB.</p></td></tr></table>
<!-- Author: Ankush -->
<!-- Comment: Tue Nov 13 03;38;53 comment by...Ignacio -->
We will probably give it a hockerization to the crate tomorrow between stores.
<!-- Date: Tue Nov 13 01:45:36 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11991&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11991  width='300' align='top'></a></td><td><h3>Bias History for SB0W3L3</h3> 
 
<p>Here is the bias history fot SB0W3L3. Increasing the IMON limit by 20 should be OK.</p></td></tr></table>
<!-- Author: Ankush -->

<!-- Date: Tue Nov 13 01:49:17 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W3L3 
<li>problem n: 1556 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>Bumping up BIAS limit post-shutdown.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>600.0</td><td>750.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>750.0</td><td>770.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W3&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Nov 13 02:00:22 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11993&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11993' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11992&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11992' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Tue Nov 13 02;03;29 comment by...Ankush -->
<h3>Pinky for ISL IB1W2L0</h3>

<p>This ladeder just gave a PINKY for BIAS0.  Looking at the BIAS history, it look like the usual increase in bias current with radiation.  I just checked the PDB and it seems bumping the IMON bias limit should be fine.</p>


<!-- Date: Tue Nov 13 02:05:40 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W2L0 
<li>problem n: 2248 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>Another increase in the BIAS0 IMON limit, post-shutdown.</p><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>180.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>180.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 Nov 13 02:10:55 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11994&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11994' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Tue Nov 13 02;12;42 comment by...Ankush -->
<h3>Resonance</h3>

<p>Around 1:54AM, there was a resonance.  The screen capture above is the LA trace.  This looks like a normal resonance to me.  After capturing and saving the trace, the LA was re-armed.</p>


<!-- Comment: Tue Nov 13 02;32;11 comment by...Ankush  -->
<p>I also checked ScalarMon to see if the resonance was in coincidence with a Prescale change: it wasn't.</p>
<!-- Date: Tue Nov 13 02:15:05 2007 -->
<h3>Web page for producing PS-Ntuple plots</h3> 
 
<p>It appears the web-page for generating the plots from the PS-ntuples is not working.....or this could easily be a case of Ankush's leaky brain.</p>
<!-- Author: Ankush -->



<!-- Date: Tue Nov 13 02:59:25 2007 -->
<h3>Something wierd with the trigger ?</h3> 
 
<p>We just got a 3 consecutive resonance errors.  This is not right. Plots to follow.</p>
<!-- Author: Ankush -->


<!-- Date: Tue Nov 13 03:02:46 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11995&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11995  width='300' align='top'></a></td><td><p>Last resonance....notice the sudden increase</p></td></tr></table>
<!-- Author: Ankush -->
<!-- Comment: Tue Nov 13 03;20;35 comment by...Ankush -->
<h4>Read Busy Lengths</h4>

<p>At Ignacio's request the RBSY times are:
<ul>
<li>ISL: 25 μs</li>
<li>SVX: 35 μs</li>
</ul>
</p>

<p>So the SVX RBSY time is certainly large.</p>


<!-- Date: Tue Nov 13 03:35:03 2007 -->
I would like to understand tomorrow why it took so long for the last bunch of DPS triggers to kick in. 
<pre> 
3	L2_DPS_L1_CMUP6_PT4 [4]	2	2007.11.12 22:38:07	 
47	L1_TWO_TRK2_DPHI90_&_CMX1.5_PT2_DPS [2]	1 2007.11.13 00:18:41	 
1	L1_TWO_TRK2_DPHI90_&_CMU1.5_PT1.5_DPS [2]	1	2007.11.13 00:18:41	 
5	L1_CEM4_PT4_&_TRK2_DPHI100_NCLC64_DPS [2]	1	2007.11.13 00:18:41	 
7	L1_CEM4_PT4_&_TRK2_DPHI100_DPS [4]	1	2007.11.13 00:18:41	 
60	L1_TWO_TRK2_B_HAD_UPS [1]	1	2007.11.13 00:19:41	 
</pre>
<!-- Author: Ignacio -->


<!-- Date: Tue Nov 13 03:53:59 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W3L3 
<li>problem n: 1556 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>770 was not large enough for IMON upper limit.  Now going up to 790.0</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>750.0</td><td>750.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>770.0</td><td>790.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W3&layer=L3">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Tue Nov 13 03;54;49 comment by...Ankush -->
<p>Had to bumnp it up again.  Hopefully it wont disturb my slumber.</p>


<!-- Date: Tue Nov 13 05:35:37 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11996&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11996  width='300' align='top'></a></td><td><h3>Remarkable: Electron Lens trip and almost no effect on losses or AGIGI2</h3> 
 
<p>The ACNET plot shows the Electron Lens 1 (T:L1COLI) trip off.  There is a small increase in T:AGIGI2 and B0PAGC goes flat. </p> 
 
<p>For me, this is remarkable.  <em>In the old days</em>, an electron lens trip would force us to immediately put Silicon to STANDBY while the AGIGI2 shot up.  But for this case the effect is minor.</p> 
 
<p>I guess this is due to 2 electron lenses rather than the one lens I am used too.</p></td></tr></table>
<!-- Author: Ankush -->
<!-- Comment: Tue Nov 13 16;35;15 comment by...ronmoore -->
We still only use 1 TEL to clean the abort gaps.  B0PAGC usually goes flat right after a TEL trip because nothing is driving DC protons out and causing losses from the abort gap.  B0PAGC would have become spiky after 15-20 min without TEL due to DC beam losing energy from synchrotron radiation and spiraling into a collimator.
<!-- Date: Tue Nov 13 08:35:50 2007 -->
Dervin is getting a 2 hour access in an hour to fix NET (FIB04) fan problem. We will switch off the ladders readout by this crate.They quench as they were terminating the store. MCR e-log: 
<pre> 
 Quench at D1 before scheduled store termination. 
</pre>
<!-- Author: SashaS/Ignacio -->


<!-- Date: Tue Nov 13 08:58:06 2007 -->
Following up this <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=379&frame=2&anchor=01:31:54'> 
entry </a> on a dip in SB0W3L3 Bias current, we have hockerized PS crate 2. PS GUI hung during hockereization, we had to restart it  
<!-- Author: Ignacio/SashaS -->


<!-- Date: Tue Nov 13 09:13:37 2007 -->
<pre>We switched off Silicon in FIB04 for the work on fixing fan in this crate</pre>
<!-- Author: Ignacio/SashaS -->
<!-- Comment: Tue Nov 13 09;28;23 comment by...Ignacio/SashaS -->
<pre>SVX PCE1B-1 temperature decreases to 2.6C. We are keeping eye on that</pre>


<!-- Comment: Tue Nov 13 09;59;24 comment by...Ignacio/SashaS -->
<pre>Switched back to Standby Silicon in FIB04</pre>
<!-- Date: Tue Nov 13 09:28:59 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11997&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11998' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12001&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12002' ></a></center>
<!-- Author: Ignacio -->



<!-- Date: Tue Nov 13 13:41:49 2007 -->
<pre>Couple ADCMon plots were a little out of whack during my check: 
 
http://stuart.physics.ucsb.edu/~stuart/adcmon/ar037e26.0001_ar03df16.0001/ 
 
SB0W2L2 
SB0W2L1 
SB0W5L2 
SB2W2L3 
 
The shapes of the plots seem to be normal, they just turned up as yellow when they weren't before</pre>
<!-- Author: Mark -->


<!-- Date: Tue Nov 13 15:10:43 2007 -->
There were two DVDD pinkies. See 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2007&action=view&page=884&frame=2&anchor=11:23:09.194'> 
(Main e-log) </a>. It turned out that all SVX was high. It went away with a Coldstart. Really strange... 
 
  
<!-- Author: Jose/Ignacio -->


<!-- Date: Tue Nov 13 15:12:32 2007 -->
Run Coordinator e-log: 
<pre> 
2:26:47-   It looks like we may be able to get started with separator conditioning around 1600hrs. It may be a little sooner or later. - S.Chaurize 
-- Tue Nov 13 12:36:59 comment by...S.Chaurize --  The earliest we would be in a position to go into HEP shot setup would be mid to late owl shift. 
</pre> 
We will go in access to investigate fa33.
<!-- Author: Ignacio -->


<!-- Date: Tue Nov 13 18:04:42 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W3L3 
<li>problem n: 2163 
<li>Status: needs_observation
<li>Type: Optical_other
<li>Action: Light_investigated
<li>entered by: sukhanov 
<li>description is: Checked light output from PC 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B1W3&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Nov 13 18:15:32 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W3L3 
<li>problem n: 2163 
<li>Status: needs_observation
<li>Type: Optical_other
<li>Action: Light_investigated
<li>entered by: sukhanov 
<li>description is: bit0 = 480 uW<br> bit1 = 504 uW<br> bit2 = 496 uW<br> bit3 = 392 uW<br> bit4 = 400 uW<br> bit5 = 488 uW<br> bit6 = 432 uW<br> bit7 = 344 uW<br> OBDV = 544 uW; Duty Cycle = 18ns/37ns<br> bit3 and OBDV were measured w/ grey Octopus cable, w/ possible loose connection to the probe 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B1W3&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Nov 13 18:58:34 2007 -->
We went into access to check the light levels of fa33, just to see if anything strange was going on with the signal. Although all the levels seemed to be in the proper range, we saw something weird: when triggering the scope with bit 5 or 7, we see many cases in which we do not see a corresponding OBDV. I don't think this should happen. 
<!-- Author: Sasha S. & Ricardo -->


<!-- Date: Wed Nov 14 03:42:17 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12003&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12004  width='300' align='top'></a></td><td><h3>Awoken from my slumber</h3> 
 
<p>In the control room with no beam, I was in my chair thinking of far off lands.  Only to be rudely disturbed by the Silicon PINKY</p> 
 
<p>DVDD for SVX B4W1L4 jumped up.  Running COLDSTART reinitialised the chip-chain and the current returned to normal.</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Wed Nov 14 10:34:13 2007 -->
<pre>Rebooted svxiicon</pre>
<!-- Author: Tom -->


<!-- Date: Wed Nov 14 10:48:51 2007 -->
<p>We were trying to do light output level measurement on SB2W6L2 using <a href=http://b0sili01.fnal.gov/cgi-bin/TWiki/bin/view/Silicon/PermanentLightLevelMeasurement> 
Permanent Light Measurement</a> test setup. We trigger scope on OBDV. We did not see any light coming out of fibers. We need to check that fiber bundle is still connected in the CH next time we will have access (this is low priority) 
<br>
<!-- Author: Ignacio/SashaS -->



<!-- Date: Wed Nov 14 13:38:43 2007 -->
Phil just told the CDF electrical feeder will be changed today at 2pm. The change should be transparent. The schedule to change to the original feeder will be determined later.  
<!-- Author: Ricardo -->


<!-- Date: Wed Nov 14 14:34:56 2007 -->
I checked the behavior of the conductivity meter outputs using the old meter, SVX output.  The output scale and the display scale are independently settable on the controller.  The output scale does not change when you change the display format (we had previously though there was a mode in which it did, but some experimentation showed it stays the same).  At the moment, 0 uS/cm corresponds to 4 mA, 16 uS/cm corresponds to 20 mA.  If the max output range for the electrical output exceeds the display format, it says ++.++ but retains the original number. 
 
The SVX conductivity history from this morning has a few steps in it -- it's back to normal. 
 
On the to-do list:  figure out how to change the transformation for mA -> uS/cm on the PLC, and also adjust the range in the regulating valve loop (the setpoint is adjustable, but the range is 0.25 uS/cm, Ignacio prefers 0.1).
<!-- Author: Tom -->
<!-- Comment: Wed Nov 14 16;19;55 comment by...Ignacio -->
Well, 0.1 is the range we agreed yesterday in the meeting to accomodate the request of not going too low in conductivity.


<!-- Date: Wed Nov 14 20:01:01 2007 -->
<b> MPCsetup rebumped</b> 
<p> 
You (present and would-be MPC ) can download the last version of MPCsetup from  
</p> 
<pre> 
b0sili01:/home/svxii/MPCsetup.sh 
</pre>. 
Changes are basically to mantain functionality. The screenshots in the second tab allow to spy most of the control room terminal which  I find usefull. 
 Thanks to SasahS that gave a hand with the sql scripts that looks now at the last  runnumber and Jose who figured out how to run B0AC++dump in the new web server.  
<!-- Author: Ignacio -->


<!-- Date: Wed Nov 14 20:05:41 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12005&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12005  width='300' align='top'></a></td><td>SvtSpyMon plot. Looks very similar to ref. plot</td></tr></table>
<!-- Author: Ignacio/SashaS -->
<!-- Comment: Wed Nov 14 20;09;52 comment by...Ignacio/Sasha -->
<pre>Initial lumiminosity at the beginning of the store 5722 was 107. There was separator spark while MCR was waiting for CDF ramp up CLC. D0 saw it, CDF missed. We waited for ~30min after beginniing of the store. Losses were ~6k and did not have any spikes. Vertex is ok. We decided to turn Silicon on. Luminosity at this point was 97.</pre>


<!-- Date: Wed Nov 14 21:39:58 2007 -->
ISL SRC has pulled an error: 
<pre> 
Nov 14, 2007 09:07:25 PM->SRC Fatal Error:Sl 6 L2A w/o L1A  
</pre>
<!-- Author: Ignacio -->
<!-- Comment: Wed Nov 14 21;52;31 comment by...Ignacio -->
I have restarted the LA. 


<!-- Date: Thu Nov 15 00:27:44 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12010&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12011' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12006&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12007' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12008&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12009' ></a></center>
<!-- Author: Ankush -->
<!-- Comment: Thu Nov 15 00;33;33 comment by...Ankush  -->
<h3>Some Interesting PINKYS</h3>

<p>I was awoken by the PINKY alarm for bias on SB3W9L2.  You can see a step in the BIAS current.  I randomly looked at the BIAS for SB1W1L2 and SB3W6L2.  All show the same step. I thought this was related to a trigger PRESCALE change.  But according to the ELOG, the last prescale change was at ~22:00.  So we have a jump in bias current across SVX but not related to the trigger.  I also had a look at an ISL ladder and they were flat.</p>

<p>Another curious observation was the bias current for SB3W6L2.  This shares the step in bias current common to the SVX laders.  However the is also a slower increase in the bias current.  This is a MICRON ladder; so that me a good enough reason.</p>

<p>For the moment I have just unmarked SB3W9L2 and not bothered to change the bias current.</p> 


<!-- Comment: Thu Nov 15 01;22;09 comment by...Ignacio -->
Ankush, I think the step is related to this prescale change:
<pre>
34	L1_TWO_TRK10_DPHI20_LUMI_0_60 [2]	1	2007.11.15 00:25:27
</pre>
ON the other issue, we have a few short-term increasing Micron ladders in ISL. We are looking at them but it is fair to say that we have been not been ON for the last few days.
<!-- Comment: Thu Nov 15 01;23;36 comment by...Ankus -->
<p>Around 00:32, the same bump was seen again.  The height was about half the size of the previous one.</p>

<p>I also noticed the upper IMON limit for SB3W9L2 was 100.0 which is now the default current.  So I bumnped up the upper IMON limit</p>
<!-- Date: Thu Nov 15 00:45:35 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12013&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12014' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12012&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12012' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Thu Nov 15 00;47;46 comment by...Ankush  -->
<h3>Another PINIY</h3>

<p>This time, a pinky on BIAS for IB1W1L0. This one looks like our monotonic increase in the BIAS current.  Next to it is the BIAS current history with my <em>mickey-mouse</em> straight line fit.</p>

<p>I will bump up the IMON limit to give enough headroom for 30 days.</p>




<!-- Date: Thu Nov 15 00:50:41 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W1L0 
<li>problem n: 2276 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>Bumping up upper IMON limit.</p><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>155.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>155.0</td><td>180.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W1&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Nov 15 00:53:44 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W9L2 
<li>problem n: 2461 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>Bumping up default upper IMON limit</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>41.9247</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>110.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W9&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Nov 15 01:14:05 2007 -->
Wedes e30 and e31 tripped. I rebooted the fib crate CPU and the shift crew recovered the wedges. It went fine.
<!-- Author: Ignacio -->
<!-- Comment: Thu Nov 15 02;00;41 comment by...Ankush -->
<p>Sorry if I had my brain in gear this would have been much faster.   I forgot about taking FIB04 through ACTIVATE before issuing HALT.</p>
<!-- Date: Thu Nov 15 01:27:26 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12015&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12016  width='300' align='top'></a></td><td><h3>PINKY for SB2W0L2</h3> 
 
<p>A sudden jump in BIAS current for SB2W0L2.  Then promptly dropped and then back to its default value.  A simple UNMARK was done.</p></td></tr></table>
<!-- Author: Ankush -->



<!-- Date: Thu Nov 15 02:23:01 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12018&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12019' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12017&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12017' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Thu Nov 15 02;25;09 comment by...Ankush -->
<h3>Another PINKY: IB5W0L2</h3>

<p>Another PINKY of the night: Bias 0 for IB5W0L2.  The two graphs are the IMON and the PS-Ntuples with my <em>mickey-mouse</em> fit. The bias current has just hit its upper IMON limit.  This seems another montonic BIAS current increase.</p>

<p>Will bump up the upper IMON limit after consulting with PDB.</p>

<!-- Date: Thu Nov 15 02:27:14 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W0L2 
<li>problem n: 2404 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>Pushing upper IMON limit on BIAS 0.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>64.9009</td><td>130.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.0</td></tr>
<tr><td><b>Upper</b></td><td>130.0</td><td>150.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Nov 15 08:50:29 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12020&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12020  width='300' align='top'></a></td><td>This is the LA trace from the ISL SRC error yesterday at 21:07. The LA confirms the presence of a L2A in the ISL line after the corresponding L1A had had a L2R. There is not a L2A seen in the SVX SRC line.</td></tr></table>
<!-- Author: Anksuh/SashaS/Ignacio -->


<!-- Date: Thu Nov 15 09:38:47 2007 -->
<center>
<a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12021&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12021' width='300'></a>
<a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12022&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12022' width='300'></a>
<br>
<a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12023&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12023' width='300'></a>
<a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12024&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12024' width='300'></a></center>
<!-- Author: SashaS -->
<!-- Comment: Thu Nov 15 09;42;57 comment by...SashaS -->
<p>
Comparison of vertex position for the stores 5705 and 5722


<!-- Comment: Thu Nov 15 11;39;17 comment by...SashaS -->
<pre>Here are the parameters of the fit:

5705/253639:

Mean z from COT            5.03822
Fitted x from COT          -0.112407+-0.00115709 cm vs.  -0.1160 cm (Nominal x SVX Center)
Fitted y from COT           0.0947224+-0.00112815 cm vs.   0.1436 cm (Nominal y SVX Center)
Fitted dxdz slope from COT    227.05+-97.4564 urad vs.    417 urad (Nominal dxdz slope)
Fitted dydz slope from COT    -105.676+-111.278 urad vs.   -190 urad (Nominal dydz slope)
Required shifts
 DeltaX    = -0.0359 +- 0.0116 mm
 DeltaY    = 0.4888 +- 0.0113 mm
 DeltaDXDZ = 190.0 +-  97.5 urad
 DeltaDYDZ = -84.3 +- 111.3 urad

5722/253810:

Mean z from COT            -1.15338
Fitted x from COT          -0.109226+-0.00045779 cm vs.  -0.1160 cm (Nominal x SVX Center)
Fitted y from COT           0.099179+-0.000436572 cm vs.   0.1436 cm (Nominal y SVX Center)
Fitted dxdz slope from COT    449.429+-36.0652 urad vs.    417 urad (Nominal dxdz slope)
Fitted dydz slope from COT    3.1008+-35.2086 urad vs.   -190 urad (Nominal dydz slope)
Required shifts
 DeltaX    = -0.0677 +- 0.0046 mm
 DeltaY    = 0.4442 +- 0.0044 mm
 DeltaDXDZ = -32.4 +-  36.1 urad
 DeltaDYDZ = -193.1 +-  35.2 urad
</pre>
<!-- Comment: Thu Nov 15 16;20;59 comment by...Ignacio -->
Appart from the increase in the slope dxdz, now very close to the desired value one can observe the "fattening" of the Z vertex distribution. The RMS goes from 17 to 23 cm. 
<pre>
Mean z from COT            5.03822
                          A       Zmin    SigmaZ  Beta*   Zo
Fit Parameters           155.464 3.78433 25.7157 17.8678 6.14043
Fit Parameter Errors     5.09853 1.58009 1.5482 1.31471 0.907418
Mean z from COT            -1.15338
                         A       Zmin    SigmaZ  Beta*   Zo
Fit Parameters           657.479 -3.61096 36.4537 26.9652 0.898498
Fit Parameter Errors     9.2153 1.1229 1.30692 1.02136 0.650555
</pre>
<!-- Comment: Thu Nov 15 17;37;34 comment by...Ignacio -->
I checked one run from August 2006 (245865). It as "fat" as we are now, so I guess it is not a problem.
<pre>
Mean z from COT            0.645719 RMS 25 CM
                           A       Zmin    SigmaZ  Beta*   Zo
Fit Parameters           1787.89 -2.83571 39.2245 27.2554 3.10049
Fit Parameter Errors     15.209 0.74758 0.872571 0.594567 0.394526
</pre>
<!-- Date: Thu Nov 15 10:15:48 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12025&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12025' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12026&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12026' width='300'></a></center>
<!-- Author: SashaS -->
<!-- Comment: Thu Nov 15 10;19;12 comment by...Ignacio/SashaS -->
<p>Store 5724 init. lumi ~110. Lostp ~7kHz. MCR were working on reducing losses and able to lower them to ~5.8kHz.


<!-- Date: Thu Nov 15 10:26:02 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12027&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12027  width='300' align='top'></a></td><td>After MCR were done with improving lostp we decided to put Silicon in. Lumi at this point was 84, lostp ~5.5kHz. </td></tr></table>
<!-- Author: Ignacio/SashaS -->
<!-- Comment: Thu Nov 15 10;33;28 comment by...SashaS/Ignacio -->
<p>
In the processe of transition from STBY to ON, there was some strange failure of communication between svxinter and PS Gui. PS Gui froze. Restarting PS did not help, it did not startup. We hadto re-boot svxinter.
<p>
The other probelem during ramping Silicon up: SB0W1L2 did not hold Bias voltage: 20V (40V set). Putting this ladder to STBY and back to ON worked. In meanwhile, we also Hockerized PS crate 2
 - just wanted to Hockerize SB0W1L2, but did it for wrong crate.




<!-- Date: Thu Nov 15 11:29:53 2007 -->
<center><a href='/elog/notebooks/silicon/Thu_Nov_15_2007_112935.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12031' ></a><a href='/elog/notebooks/silicon/Thu_Nov_15_2007_112439.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12029' ></a></center>
<!-- Author: Jose -->
<!-- Comment: Thu Nov 15 11;31;16 comment by...Jose -->
<pre>PS for the two last SRC errors.</pre>



<!-- Date: Thu Nov 15 13:59:39 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12032&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12032  width='300' align='top'></a></td><td><h3>Another SRC Error</h3> 
<pre> 
(MLE) b0control21.fnal.gov:Thread-25:Nov 15, 2007 01:06:40 PM->FrontEnd Crate Error Condition from: 
VRB_SVX_02 
 
(MLE) b0control21.fnal.gov:Thread-25:Nov 15, 2007 01:06:40 PM->FrontEnd Error: VRB_SVX_02  
(MLW) b0control21.fnal.gov:Thread-25:Nov 15, 2007 01:06:44 PM->Inhibit flag SET  
CT: 2007.11.15 13:06:45 
6'45" 1 crate/s: b0svx02(112),  in error. [RXPT] 
(MLE) b0control21.fnal.gov:Thread-25:Nov 15, 2007 01:06:53 PM->  Silicon Level 1 Done Timeout Error from SVX, ISL or L00 
 
CT: 2007.11.15 13:06:57 
6'57" L1 Done Timeout.[RXPT] 
6'57" 1 crate/s: b0svx02(112),  in error. [RXPT] 
CT: 2007.11.15 13:07:00 
7'0" b0svx02:Messenger:Nov 15, 2007 01:07:00 PM->SRC Fatal Error:Sl 6 Too Many L1A 2 L1A to Buff  
 -->   
 Additional Information:  
 
 Attention !!!. FERML_SRC_FATALITY ERROR !!!  
  
 SRC Fatal Error from b0svx02: Sl 6 Too Many L1A 2 L1A to Buff  
  
 - HALT the run                    
 - record any relevant information in e-log      
 - RECOVER - RUN      
[MLE] 
CT: 2007.11.15 13:07:01 
7'1" 1 crate/s: b0svx02(112),  in error. [RXPT] 
(MLE) b0felix.fnal.gov:TEDCpp:Nov 15, 2007 01:07:25 PM->{ 13:7:25, 11/15/2007 }: L2-Pulsar-Linux: Halted while  processing happily 
(RC)   13:07:06 Halt -> HALTED 
(RC)   13:07:22 Recover -> RECOVERED 
(RC)   13:07:26 Run -> ACTIVE 
(TS)   13:08:47  InhibitSet for >=  2.0 minutes !!!  
</pre></td></tr></table>
<!-- Author: Jose -->


<!-- Date: Thu Nov 15 15:59:06 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12033&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12034  width='300' align='top'></a></td><td>Note the 1 muS long  L1A signal (normal ones are 130 ns). At the fith L1 accept the SRC will pull the "too many L1A" error.  Also the glitch in the SVX clock. The ISL clock also has a glitch, but less messy.</td></tr></table>
<!-- Author: Jose/Ricardo/Ignacio -->



<!-- Date: Thu Nov 15 17:21:18 2007 -->
Bill Badgett has changed the range of the maximum depletion voltage  for L00 in the hardware data base. Previously it was [0,140] now it is [0,250]. I have increased the value  in the hardware database from 137 to 143 volts. The parameter VMAX is in crate SVX_INTER_00 
board L00PS_07. I have tried the maximum value of the depletion voltage for a given L00 ladder. I could increase it up to 175 V. At 176 it gave a java exception. I left the original value in place.
<!-- Author: Ignacio -->



<!-- Date: Thu Nov 15 18:54:40 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12036&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12036' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12037&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12037' width='300'></a></center>
<!-- Author: Ignacio/SashaS -->
<!-- Comment: Thu Nov 15 18;57;11 comment by...Ignacio/SashaS -->
<pre>Pinkies in IB5W1L4 and IB5W2L2: IBias0 is just above limits. We set these to IGNORE and will keep eye on them.</pre>


<!-- Date: Thu Nov 15 19:16:07 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12038&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12038  width='300' align='top'></a></td><td>Another view of the SRC error that happened at 1:06 pm. Here it can be clearly seen that while the SVX B0 clock shows a glitch, the ISL does not. But both, the SVX and ISL SRC's show the BX clock with a glitch, at the same time of the B0 glitch is the SVX SRC.  This makes me  believe that this is not an SRC problem, and probably related to the clock signals. 
</td></tr></table>
<!-- Author: ricardo -->


<!-- Date: Thu Nov 15 20:00:07 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12039&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12039  width='300' align='top'></a></td><td>We had another SVX SRC error at 7:24pm. L2A without L1A. 
Look at how the clock is missing.</td></tr></table>
<!-- Author: Ricardo -->


<!-- Date: Thu Nov 15 20:56:57 2007 -->
<pre>Since we have few more SRC errors today, in order to debug problem, we need more data. We have instructed ace if there will be more SRC errors during the shift, to save LA data to file and re-arm the LA.</pre>
<!-- Author: Ricardo/SashaS -->


<!-- Date: Fri Nov 16 06:18:09 2007 -->
Ace Francesco recovered hockerization rate # 1.  
<!-- Author: Ignacio -->


<!-- Date: Fri Nov 16 06:21:43 2007 -->
RC inform us at 3:35 AM: 
<pre>We will keep Store 5724 colliding until 0800 or longer depending on state of Pbars in the Recycler after transfers 
</pre>
<!-- Author: Ignacio -->

<!-- Date: Fri Nov 16 08:22:44 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W0L4 
<li>problem n: 1988 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Increasing limits after shutdown<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>143</td><td>200</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>165</td><td>200</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Nov 16 08:33:18 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W1L2 
<li>problem n: 2412 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Increase limits after shutdown<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>127</td><td>200</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>180</td><td>200</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Nov 16 08:37:19 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W1L4 
<li>problem n: 2419 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Increase limits after shutdown<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>150</td><td>200</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>220</td><td>250</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W1&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Nov 16 08:38:59 2007 -->
I have asked Bill to decrease the set point of the DI loops from  1 to 0.6 muSi/cm. Next Monday pH measurement will tell us is if this is the correct setting. The range  is still 0.25 muSi/cm. According to Tom, this value is encoded in the PLC. 
<!-- Author: Ignacio -->

<!-- Date: Fri Nov 16 08:40:18 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W2L0 
<li>problem n: 2428 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Increase limits after shutdown<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>200</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>155</td><td>180</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W2&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Nov 16 08:42:38 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W2L2 
<li>problem n: 2424 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Increase limits after shutdown<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>200</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>155</td><td>180</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W2&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Nov 16 08:47:27 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W0L4 
<li>problem n: 809 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: Changing limits after shutdown<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>175</td><td>200</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>230</td><td>290</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: Fri Nov 16 08:49:35 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W2L2 
<li>problem n: 2426 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: sukhanov 
<li>description is: changing limits after shutdown<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>120</td><td>200</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>180</td><td>260</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W2&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Nov 16 09:39:31 2007 -->
<pre>About 9:08am Greg Feild swapped GL2 board in TS crate. Power in the crate was off which caused glitch in lumi. measurement (lumi dropped by ~25% from 20 to 15). Tevmon sent Si to STBY. 
Put Si back to ON</pre>
<!-- Author: sashaS -->


<!-- Date: Fri Nov 16 11:05:08 2007 -->
The O2 reading in ISL has stepped up to 21 % at 10:55.
<!-- Author: Ignacio -->
<!-- Comment: Fri Nov 16 11;17;47 comment by...Ignacio -->
Flows are flat. I went down and  the reading was 21 % indeed. I measure the flow (a bit below 7) with my thumb and the O2 reading came down to 17.  

<!-- Comment: Fri Nov 16 11;25;44 comment by...Ignacio -->
Bill Noe tells me that this is a known feature that they are working to solve.


<!-- Date: Fri Nov 16 11:55:14 2007 -->
Warren has installed a connector in the SVX chiller retuen temperature cable to the PLC so it can be swapped to the spare chiller. They are  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=cryo-gas&action=view&page=2480&frame=2&anchor=11:52:31'> 
done. </a>  Nothing was noticed from the control room.  
<!-- Author: Ignacio -->


<!-- Date: Fri Nov 16 13:39:23 2007 -->
Roberto Davila  recrimped the connectors on the clock cable that goes from the clock fanout in the first floor to the SRC of the test stand. Recrimping the connector on the first floor was enough to make the cable work again. With the real clock signal we then hooked the teststand CCC to the clock to monitor if the clock glitches. Let's see what happen with the clock when the next SRC-error appear.
<!-- Author: Ricardo -->


<!-- Date: Fri Nov 16 13:43:10 2007 -->
I am switching off L00 since they will perform crystal collimator studies.
<!-- Author: Ignacio -->
<!-- Comment: Fri Nov 16 17;36;19 comment by...Ignacio -->
L00 is back to standby.


<!-- Date: Fri Nov 16 17:37:10 2007 -->
The LA was not running again.
<!-- Author: Ignacio -->


<!-- Date: Fri Nov 16 18:51:12 2007 -->
<h3> L00 bias voltage increase </h3> 
Following bias scan results we have incresaed the bias voltage of L00 by 7-10 V in the HWDB and in CAENvolts.dat. The wides are now 95 or lower, the narrows 142 V or lower. Larger increases have been made for: 
<pre> 
f831 bias0  90 => 120 V 
f833 bias1 120 => 142 V 
fa22 bias0 110 => 142 V 
</pre> 
The detector has been biased at this voltages for ~half an hour This resulted in small bias current increases, less than 5 muA.
<!-- Author: Joise/Ricardo/Ignacio -->
<!-- Comment: Fri Nov 16 19;42;26 comment by...Ignacio -->
Found out that 3 bias lines (2 crow bars) were blown last week. We are requesting an access.
<!-- Comment: Fri Nov 16 20;46;23 comment by...SashaS/Ignacio/Jose -->
Went into access and replaced the two blown crow bars LB1W0 and LB1W5. They were blown since last Friday.
<!-- Comment: Fri Nov 16 20;54;42 comment by...Ignacio -->
The blown crowbar channels were rolled back to their original bias voltages.
<!-- Comment: Sat Nov 17 11;11;39 comment by...SashaS/Ignacio -->
We have given a look to the Ben Ntuples to determine exactly when the crowbars had blown:
<pre>
                             Voltage change
fa03 bias0  11/09/07 10:33    140=>145         Replaced 11/16
fa03 bias1  11/09/07 10:33    140=>145         Replaced 11/16
fa53 bias1  11/09/07 10:33    140=>145         Replaced 11/16
fa23 bias1  11/09/07 10:33    140=>145         Replaced 11/09
f033 bias0  11/09/07 11:00    135=>155         Replaced 11/09

</pre>
One additional crowbar was blown during the 11/09 access.
It total we have blown 5 crowbars and 6 fuses.





<!-- Comment: Sat Nov 17 13;27;36 comment by...Ignacio -->
Checked the ADCMon distribution from the consumers. There seems to be a physics tail in all L00 ladders.
<!-- Comment: Tue Dec 18 09;25;06 comment by...Ignacio -->
I made a typo in the last line:
<pre>  Voltage change 
f833 bias0 11/09/07 11:00 135=>155 Replaced 11/09 </pre>

<!-- Date: Fri Nov 16 19:06:11 2007 -->
<h2>Clock to SRC</h2> 
<p>Today we continue dinvestigation of the recent SRC errors. We wanted to exclude clock as the source of the problems. After talking to Steve&Steve we picked up the RF signal from clock fanout board in the crate on the 1st floor and hooked it to the scope next to the crate. Steve the Clock Guy setup trigger on the scope to fire on the missing RF cycles within 30 ns. That would allow us to catch RF related glitches. We left scope running and will check how many triggers it will have. 
<p>We also plugged in clock/RF cables to CCC in tstsvx1 crate. We were able to talk to the card, read back status register and reset it. Here is an instruction: 
 
<pre> 
>setup fer 
>vxcom tstsvx1 
tstsvx1> ccc 
     base address 0x7000 
     your pick 0x2 
</pre> 
 
Clock errors will be latched in the CCC status register. The command above prints which clock line had problem. Status of the RF is either <i>CCC is locked to RF</i> or <i>Running on the internal clock</i>
<!-- Author: Ricardo/SashaS -->





<!-- Date: Sat Nov 17 10:11:19 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12041&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12041  width='300' align='top'></a></td><td>Store 4729 with initial luminosity 135. Lostp/Lostpb were 6600 and 5000 Hz. 2 minutes after the squeeze we had an autohockerization of crate 2, also b0fib00 had to be rebooted (both in NW top). 
We recovered it in time for going in from the beginning of the store. 2 SRC errors (ISL/SVX) appeared just as the Ace had hitted active. ISL came first SVX 1 mus afterwards. The clocks in the trace (see below) show clock glitches. The CCC  (runnig in the teststand since yesterday) has recorded 3 errors: BX err, SY err and Master Clock Error. The scope downstairs, which monitor RF, seems to be frozen. We went into halt and recover (we had 2 DVDD pinkies), waited the time to save the trace and rearm the LA and run without further problems. SVXMon looks good. </td></tr></table>
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12042&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12043  width='300' align='top'></a></td><td>
<pre>
MLE) b0control21.fnal.gov:Thread-26:Nov 17, 2007 09:42:10 AM->FrontEnd Error: VRB_ISL_06 VRB_SVX_02 


(RC)   9:42:12 Activate -> ACTIVE 
b0svx06:Messenger:Nov 17, 2007 09:42:27 AM->SRC Fatal Error:Sl 6 Too Many L1A L2A w/o L1A 2 L1A to
Buff  

 -->   
 Additional Information:  

 Attention !!!. FERML_SRC_FATALITY ERROR !!!  

 SRC Fatal Error from b0svx06: Sl 6 Too Many L1A L2A w/o L1A 2 L1A to Buff  

 - HALT the run                    
 - record any relevant information in e-log      
 - RECOVER - RUN      
[MLE] 
b0svx02:Messenger:Nov 17, 2007 09:42:27 AM->SRC Fatal Error:Sl 6 L2A w/o L1A
</pre>
</td></tr></table>
<!-- Author: SashaS/Ignacio -->
<!-- Comment: Sat Nov 17 10;15;15 comment by...Ignacio/SashaS -->
<p>Here is the output of CCC running in the test stand:
<pre>
Your pick? 0x2
Status: 0, Read: 3c
BX error
SY error
GP error
Master clk error
CCC is locked to RF
</pre>
<p>I have cleared error status. CCC is ready to record any new errors




<!-- Comment: Sat Nov 17 11;33;24 comment by...Ignacio/SashaS -->
<p>We had just found another error in ccc
<pre>
Your pick? 0x2
Status: 0, Read: 24
BX error
Master clk error
CCC is locked to RF
</pre>
Cleared error status and will keep eye on that



<!-- Date: Sat Nov 17 14:12:00 2007 -->
Both SRCs complained again: 
<pre> 
SRC Fatal Error from b0svx06: Sl 6 L2A w/o L1A  
  
 - HALT the run                    
 - record any relevant information in e-log      
 - RECOVER - RUN      
[MLE] 
54'7" b0svx02:Messenger:Nov 17, 2007 01:54:07 PM->SRC Fatal Error:Sl 6 L2A w/o L1A  
 -->   
 Additional Information:  
 
 Attention !!!. FERML_SRC_FATALITY ERROR !!!  
  
 SRC Fatal Error from b0svx02: Sl 6 L2A w/o L1A  
</pre> 
Several DVDD pinkies appeared as the Ace was saving the trace ans starting the LA. I asked him to go to recover first then do the LA thing. The ccc shows: 
<pre> 
Status: 0, Read: 2c 
BX error 
SY error 
Master clk error 
CCC is locked to RF 
</pre> 
The ccc is cleared again.
<!-- Author: Ignacio -->


<!-- Date: Sat Nov 17 14:40:53 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12044&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12044  width='300' align='top'></a></td><td>SRC error: glitch in beam structure, ISL SRC pulls error and SVX SRC follows</td></tr></table>
<!-- Author: SashaS -->
<!-- Comment: Sat Nov 17 14;46;27 comment by...Ignacio -->
There seems to be a glitch in the RF also in this one.

<!-- Comment: Sat Nov 17 14;51;31 comment by...sashas -->
<pre>I have checked scope on the first floor, it did not catch any RF error: same status of 0 swps, as we left it about 11am</pre>


<!-- Date: Sat Nov 17 16:10:12 2007 -->
Another error triggerd the ccc. Resetted. 
<pre> 
BX error 
Master clk error 
</pre>
<!-- Author: Ignacio -->


<!-- Date: Sat Nov 17 16:50:01 2007 -->
Another SRC error. This time only SVX  
<pre> 
34'34" b0svx02:Messenger:Nov 17, 2007 04:34:35 PM->SRC Fatal Error:Sl 6 2 L1A to Buff  
 
CCC saw this: 
Status: 0, Read: 2c 
BX error 
SY error 
Master clk error 
CCC is locked to RF 
</pre>

<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12045&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12046  width='300' align='top'></a></td><td>Now the SVX BX clock line remains high.</td></tr></table>

<!-- Author: Ignacio -->


<!-- Date: Sat Nov 17 19:03:52 2007 -->
The fanout crate that feeds both SRCs and the teststand is located in 1RR15E.  The outputs are: 
<pre>                               
                                                 Goes to 
Slot  8  FNT58 Fanout A Cable type D   16215     SVX SRC 
Slot  8  FNT58 Fanout B Cable type D   16395     ISL SRC 
Slot  9  FNT56 Fanout A Cable type D   16398     ccc PCLK 
Slot  9  FNT56 Fanout B Cable empty 
Slot 10  FNT33 Fanout A Cable type D   16397     ccc BS 
Slot 10  FNT33 Fanout B Cable type D   16320     would like to know???? 
Slot 14  FNT06 Fanout A Cable type D53 16216      SVX SRC 
Slot 14  FNT06 Fanout B Cable type D53 16396      ISL SRC 
</pre>
<!-- Author: Ignacio -->


<!-- Date: Sat Nov 17 19:57:12 2007 -->
There was a resonance. The ccc has not seen any glitch. I have asked the Ace to save the trace and restart the LA.
<!-- Author: Ignacio -->
<!-- Comment: Sun Nov 18 01;52;39 comment by...Ignacio -->
Had a look to the LA trace saved by the Ace. It is looks a normal resonance. The remote desktop in VNODE2 was closed when I arrived.
<table border=0><td><tr><td bgcolor=#e0e030>Please do not log to ncdf205 from outside since the Aces are taking care of saving the traces. </td></tr></td></table>
<!-- Date: Sun Nov 18 01:44:59 2007 -->
Historical 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=cryo-gas&action=view&page=2481&frame=2&anchor=09:17:02'> 
 data</a> was not working. That is why the setpoint change last Friday from 1 muSi/cm to 0.6 did not appear in the plot. The historical plots have  a glitch at 8AM today. After that the set poit reads 0.6.
<!-- Author: Ignacio -->



<!-- Date: Sun Nov 18 02:38:42 2007 -->
Same thing as at the begining of the store. ccc: 
<pre> 
Status: 0, Read: 24 
BX error 
Master clk error 
CCC is locked to RF 
</pre> The LA trace follows:

<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12047&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12047  width='300' align='top'></a></td><td>a</td></tr></table>

Note the small spike in one of the SVX clocks. The ISL clock has a larger gap after the error (not shown in the plot) 
<!-- Author: Ignacio -->



<!-- Date: Sun Nov 18 02:58:15 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12049&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12049  width='300' align='top'></a></td><td>Store 5730 started with an SRC error. We recover fine after waiting a bit in recovered but  that screwed L3 so we had to restart the run. The initial luminosity was 130E30,  we had to remind MCR to turn on the electron lense. I do not like how the losses look like but I guess they are still safe. The proton losses are high (8000) and not terribly flat, but they are coming down. The antiproton abort gap losses are already spiky. SVXMOn looked fine.  
</td></tr></table>
<!-- Author: Ignacio  -->
<!-- Comment: Sun Nov 18 03;49;48 comment by...Ignacio -->
<pre> Lostpb jumped close to 10 K while tune changes. The ace sent silcion to standby. BTW the inital L1A was 27 KHz.</pre>


<!-- Date: Sun Nov 18 06:41:16 2007 -->
Alphanumeric bips. The sequence this time  was: 
<li>Autohockerization of crate 5</li> 
<li>b0fib02 has to be rebooted since the wedges connected to this fib do not respond</li> 
<li>SRC fatality error as we were coming out from the recovered state. 
This time it was a sequence of L1 Done Timeout.[RXPT].</li> 
The trace has been saed by the ace. 
No clock glitch this time in the ccc.
<!-- Author: Ignacio -->
<!-- Comment: Sun Nov 18 06;50;49 comment by...Ignacio -->
At the same time they were chaning the tunes with spikes in the losses.


<!-- Date: Sun Nov 18 13:09:55 2007 -->
<h3>Efficiency</h3> 
<p> 
The <a href ='http://b0sili01.fnal.gov/monitoring_wg/sihitana/index.html '> offline effiency</a>  plots are being generated again. They are available  from run  253862(0x3dfa6). I have compared to before the shutdown and we look pretty good. Appart from the small detail that we have double the efficiency of ISL and L00, the pattern of scars has not changed. Only 1 SVX ladder (in) and  3 ISL ladders ( 2 in -1 out).  
</p> 
 
 Thanks to Ben and Jose for fixing it. Now the monitoring shifter can look  to something else than the exciting ADCMon distributions.
<!-- Author: Ignacio -->


<!-- Date: Sun Nov 18 17:35:43 2007 -->
Another ccc trigger: 
<pre> 
BX error 
Master clk error 
</pre>
<!-- Author: Ignacio -->


<!-- Date: Sun Nov 18 20:31:07 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12050&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12050  width='300' align='top'></a></td><td>a</td></tr></table>
<!-- Author: a -->


<!-- Date: Sun Nov 18 20:36:26 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12051&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12051  width='300' align='top'></a></td><td>Store 5731: Stash was 240, injected np/npb ~7700/2500. Initial luminosity ~140. Lostp: 18kHz at the beginning of the store. We asked MCR to reduce losses. They were trying but apparently could not. When losses (almost naturally) dropped to about 10kHz and MCR stopped changing tunes, we decided to put Silicon in. At the beginning of the 1st run with Silicon (253971) we almost immediately had our friend SRC error. LA traces showed ISL BX/Clock glitch.</td></tr></table>
<!-- Author: Ignacio/SashaS -->


<!-- Date: Sun Nov 18 21:56:27 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12052&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12052' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12053&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12053' width='300'></a></center>
<!-- Author: Ignacio -->
<!-- Comment: Sun Nov 18 22;21;45 comment by...Ignacio -->
I am trying to understand if, or how much, we care about the halo level since the attemp to reduce it today was not very succesful in terms of integrated luminosity (and can only get worse).  I believe we have a  larger value of  halo becasue of the hockeriations+fib SEU we are experiencing at the beginnig of the run but this should not affect the safety of the silicon itself.  The left plot shows a previous store with proton losses around a factor of 2 lower than today.  I am also plotting 6 of the diamonds. For a given luminosity,  any diamond reading correspond one to one between both stores regardless of the losses being a factor of two higher (should make a correlation plot). This is consistent with the previous measurement of the dose being dominated by collisions early in RUN II  (Tesarek et.al.).  Now the question is: If 10 KHz is not large enought a limit, how high should we go? While we get a good answer  I think we should keep the TeVMon alarm limits. There are two options we should discuss tomorrow in the silicon meeting:
 <li> Allow to run the silicon with TevMon in warning at the beginning of the store with the presence of the MPC</li>
 <li> Wait until losses come down before the silicon is included. </li>


<!-- Date: Mon Nov 19 09:28:44 2007 -->
 
<h3>Summary of the Week</h3> 
 
 <b>Monday, November 12, 2007</b> <ul> 
 
 <li>Coffe machine repaired! We all should praise Ricardo <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=379&frame=2&anchor=14:22:21'>here</a> </li> 
 <li> Store 5716. B11 sparks at the beginnig. Sparator helix changes. Vertex <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=379&frame=2&anchor=09:38:47'> changes.</a>  </li> 
 
 
</ul> <b>Tuesday, November 13, 2007</b> <ul> 
 
 
</ul> <b>Tuesday, November 13, 2007</b> <ul> 
 
 
 <li> First resonance. First SRC error: Several <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=379&frame=2&anchor=03:03:46'> L1DONE</a> from SVXSRC</li> 
 <li> Electron lense trip. 
 <li> Separator conditioning until Wendsday evening.</li> 
 <li> Dervin & crew fix  NE Top (FIB04) fan</li> 
 <li> ISL taks force decided to change conductivity set point to 0.6 (done in Friday). Range  change (from 0.25 to 0.1) will require PLC code change.</li> 
 
</ul> <b>Wednesday, November 14, 2007</b> <ul> 
 
<li> Electrical feeder change. No visible effects.</li> 
<li> </li> 
<li> Store 5722 (107E30). Waited for ~30min out of separator spark angst (D0 had one).</li> 
<li> ISL SRC error (Sl 6 L2A w/o L1A)  </li> 
 
 
 
 </ul> <b>Thursday, November 15, 2007</b> <ul> 
 
 <li>Store 5724. Lostp ~7kHz. </li> 
 <li> SVX SRC error 1:06 PM (Sl 6 Too Many L1A 2 L1A to Buff ). Clock glitch seen in the LA trace.  </li> 
 <li> SVX SRC error 7:24pm.. Clock glitch seen in the LA trace.  </li> 
 </ul> 
 
<b>Friday, November 16, 2007</b> <ul> 
 
 <li> Greg swapped GL2 board since it was suspected of (some of) the SRC errors (L1DONE type).</li> 
 <li> Warren enabled the swap of the return temperature from the SVX chiller in case of need.</li> 
 <li>L00 bias <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=379&frame=2&anchor=18:51:12'>increase.</a> Previosuly some HWDB changes by Bill were required. Realized about last week blunder. Access to swap 2 crowbars.</li> 
  <li> CCC working in teststand</li> 
 
</ul> <b>Saturday, November 17, 2007</b> <ul> 
 
 <li>Store 5729. Autockerization+fib reboot. 2 SRC (SVX/ISL) errors linked to clock glitch. CCC triggers. </li> 
 <li> Similar errors at 14:00 and at 16:50. A resonance at ~20:00</li> 
 
 </ul> <b>Sunday, November 18, 2007</b> <ul> 
 
  <li> Store 5730. SRC errors at start up.  </li> 
  <li>Interesting sequence of <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=379&frame=2&anchor=06:41:16'>errors</a></li> 
  <li> Store 5731. Loses 18 KHz.  <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=379&frame=2&anchor=20:31:07'>Link</a>. Clock glitch at startup. </li> 
 
  
<!-- Author: Ignacio -->


<!-- Date: Mon Nov 19 14:56:55 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12054&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12054  width='300' align='top'></a></td><td>For Sebastian</td></tr></table>
<!-- Author: Ignacio -->