<!-- Title: 11:03:53  Mon Apr 30 2007 -->
<!-- Crewchief: Ignacio (MPC) -->
<!-- Op1: Miguel (observing) -->
<!-- Op2: Jose (SPL) -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
One more week full of joy...


<!-- Date: Mon Apr 30 11:25:26 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11235&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11235' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11236&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11236' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11237&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11237' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11238&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11238' width='300'></a></center>
<!-- Author: Ulrich -->
<!-- Comment: Mon Apr 30 11;31;06 comment by...Ulrich -->
Just a follow-up on the integrated dose alarms last week:
<ul>
<li>Store 5374 (237e30): SVRAD2 20-22 rad/min</li>
<li>Store 5376 (269e30): SVRAD0 20 rad/min, SVRAD2 30 (!) rad/min</li>
<li>Store 5379 (154e30): SVRAD2 20 rad/min</li>
<li>Stores 5382 (190e30) and 5383 (188e30): no alarms, SVRAD2 approx 10 rad/min</li>
<li>Store 5384 (237e30): SVRAD2 22 rad/min</li>
</ul>
The bottom line: four out of six stores triggered the alarm. Mostly, SVXRAD2 (East inner BLM) was just over the limit. The exception is the high-lumi store 5376, where two out of the four BLMs were above the limit of 19 rad/min. The question is: why has the radiation been a factor of two lower in  5382 and 5383, where the lumi was not much smaller than before?


<!-- Comment: Tue May  1 08;47;21 comment by...Ignacio -->
Another integrated radiation alarm for store 5401 (<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2007&action=view&page=361&frame=2&anchor=07:22:44.125'>
plot</a>).



<!-- Comment: Wed May  2 11;33;58 comment by...Ignacio -->
Another integrated radiation alarm for store 5402 during squeezing.
<!-- Date: Mon Apr 30 17:22:28 2007 -->
<h3> Cooling work</h3> 
<p> 
The cryo people has prepared a test stand to check  the ability of the resin to reduce the conductivity/pH of the ISL coolant that was taken last Monday. We measured the pH (2.92) and conductivity (720) beforehand. We checked with an old sample that the calibration of the pH meter was  in fact +0.1 off since the meter  was also measuring 2.92 for the old sample, while it gave 2.82 before.</p> 
<p> 
 We let the coolant flow at 15-20 gallons per hour during half an hour and were moving things around to maximize the level of water  
in the resin bottle. So the coolant went between 1 and 2 times through the resin-bed.</p> 
 
<h3>When we measured the conductivity was down at 9.2 muS and the  pH was 4.63.</h3> 
<p> 
So we took the oportunity of the Tevatron down time to get another 5 gallon sample (to check the effect of regenerated resin) and exchanged the ISL resin (in hope to see an effect). </p> 
 
<b>Many thanks to KC, Dean and Del.</b>  
<!-- Author: Jose/Hugo/Ulrich/Ignacio -->


<!-- Date: Mon Apr 30 20:44:05 2007 -->
Spontaneous switch off crate 13 recovered by shift crew.
<!-- Author: Ignacio -->


<!-- Date: Tue May 1 06:53:44 2007 -->
Another radiation alarm by squeezing...
<!-- Author: Ignacio -->


<!-- Date: Tue May 1 07:29:33 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11239&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11239  width='300' align='top'></a></td><td>Store 5401 with lumi 207.0 E30. SVTSpymon and SVXMOn look OK. There was an autohockerization (crate 14) just 5 minutes into data taking. Ace recovered allright. Several micron ladders bias (5 layer 2, 4 layer 4, 2 ISL) were pinnk as soon as we switched on the HV.  They are discharging as we have been off for some time. They are coming down...</td></tr></table>
<!-- Author: Ignacio -->


<!-- Date: Tue May 1 07:50:15 2007 -->
The current plotter not working as expected,...uhmmm, did Jose said yesterday he wanted to play with the scripts?
<!-- Author: Ignacio -->
<!-- Comment: Tue May  1 08;19;21 comment by...Jose -->
uups... try now, it should be back to normal...


<!-- Comment: Tue May  1 08;48;06 comment by...Ignacio -->
Indeed...thanks.
<!-- Date: Tue May 1 08:41:57 2007 -->
IMON refuses to write file to e-log. IMON OK after being restarted by shift crew.
<!-- Author: Ignacio -->




<!-- Date: Tue May 1 09:00:40 2007 -->
A few things just a bit warmer today:<br> 
<pre> 
SVX det supply temperature -10.2 => -9.8 
SVX chiller return temperature -11.60 => 11.3 
ISL CCE2.2 14.5 => 15.3 
</pre> 
The latter is probably linked to f304 and f303 being pink (just on the limit). Let's see how the SVX chiller temperature evolves.
<!-- Author: Ignacio -->
<!-- Comment: Tue May  1 09;05;01 comment by...Ulrich -->
No way! The return temperature cannot be smaller than the supply! You've probably read some internal chiller temperature. Chiller return (SVX_TE_CHRET)  was -8.51°C yesterday.
<!-- Comment: Tue May  1 09;15;13 comment by...Ignacio -->
Yes, sorry. Of the four temperatures in the "Alcove" plot two remain completely unchanged, two  have increased by a bit: the ones labeled "detector supply temperature element" and "SVX Chiller evaporator temperature". The return temperature is completely constant.
<!-- Comment: Tue May  1 09;19;10 comment by...Ulrich -->
And we usually start worrying about temperature changes when they are either occuring fast or translate to the return temperature.
<!-- Comment: Tue May  1 09;26;42 comment by...Ignacio -->
Sure, I was just keeping an eye on the chiller since the cooling expert says the strange chiller  noises are "different" strange compared to what they were before. 
<!-- Comment: Wed May  2 18;42;24 comment by...Ignacio -->
<pre>ISL CCE2.2 is  16 C now. </pre>
<!-- Comment: Thu May  3 10;45;30 comment by...Ignacio -->
It was 16.5 this morning.
<!-- Date: Tue May 1 09:05:01 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W0L3 
<li>problem n: 1503 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: ignacio 
<li>description is: Increase limit for bias 1.<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>200.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>200.0</td><td>250.0</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: Tue May 1 09:17:19 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W0L4 
<li>problem n: 1506 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: ignacio 
<li>description is: Increase 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>125.</td><td>200.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>200.0</td><td>250.0</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: Tue May 1 13:52:19 2007 -->
PT_COTCCE2 has gone down bellow the warning limit of 13.0. Now it is  fluctuating 12.7-12.9 (during the 10 minutes I have watched it). I have unsilenced the alarm for the moment.  I can silence it back if it causes too many e-mails.
<!-- Author: Ignacio -->
<!-- Comment: Tue May  1 19;36;01 comment by...Ignacio -->
I retract myself. Back to ignored.
<!-- Date: Tue May 1 15:41:07 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W9L3 
<li>problem n: 1410 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: ignacio 
<li>description is: This ladder continues giving multiple bit errors, unknown channel, bit1, not bit0/1. This  causes downtime through automatic HRRs. I have checked that the Rdirver is 4 for all chips. We could play with the Rdriver 4-7  during quiet time. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W9&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed May 2 05:20:10 2007 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 466
Calibration type  : standard
Run period tag    : May_2007
DPS-off run       : 240616
DPS-on run        : 240615
Requested by      : Shih-Chieh Hsu
Main process id   : 822
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->



<!-- Date: Wed May 2 08:39:11 2007 -->
ISL and L00 are off for resin exchange.
<!-- Author: Ignacio -->
<!-- Comment: Wed May  2 08;47;01 comment by...Ignacio -->
ISL PS interlock trip as expected. 


<!-- Date: Wed May 2 09:37:25 2007 -->
<h3>Cooling Work</h3> 
As part of the investigation of the effectiveness of the resin bed to bring down conductivity and pH, Dean has exchanged the resin once more. After that we changed the iFix warning limits for the ISL COT face pressures. They are now 13.3 psi across the board (some were already at 13.3 psi, some were at 13.0 psi before). All alarm limits are still at 13.5 psi. Finally we have done the routine reboot of SVXIICON. Everything is up and running again.
<!-- Author: Jose, Ignacio, Ulrich -->
<!-- Comment: Wed May  2 10;08;08 comment by...Jose,Ignacio,Ulrich -->
Mention that we recovered ISL and L00 (by FIB) while running BeamPermit on svxinter.


<!-- Date: Wed May 2 10:37:17 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11242&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11243  width='300' align='top'></a></td><td>Store 5402  with decent luminosity of 245 E30 and low backgrounds. Deadtime is >25 % from the beginnig of the run, 
probably due to one of the parasitic L2 crates. There was an integrated dose alarm during squeezing this time again. SVXMon  and SVTSpyMon looks fine.</td></tr></table>
<!-- Author: Miguel/Ignacio -->
<!-- Comment: Wed May  2 10;44;28 comment by...Ignacio -->
Deadtime back to 8 % after all L2 test crates were excluded.


<!-- Date: Wed May 2 13:26:20 2007 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 466 finished successfully.

Job info
--------
Calibration type : standard
DPS-off run      : 240616
DPS-on run       : 240615
Requested by     : Shih-Chieh Hsu
Submitted        : 2007-05-02 05:19:38
Completed        : 2007-05-02 13:26:14
Status           : SUCCESS
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Wed May 2 15:04:08 2007 -->
 Ron showed us yesterday the new java  <a href='http://www-bd.fnal.gov/appix/start?p=60000374&n=55000712'>  program </a> to renew the permit. 
 
It only works from the run control terminals where ACNET runs.
<!-- Author: Jose/Ignacio -->


<!-- Date: Wed May 2 18:29:56 2007 -->
We started runnig the BeamPermit proccess while data taking. Rebooting svxinter will not restart the proccess. The proccess 
can be killed by doing: 
<pre> td BeamPermit 
</pre>
<!-- Author: Jose/Ignacio -->


<!-- Date: Wed May 2 18:37:47 2007 -->
Several pinkies due to a prescale change at 90 E30 that produces a jump of 11 KHz. Now it seems the big jump has moved from 110 to 90 E30.
<!-- Author: Ignacio -->



<!-- Date: Wed May 2 19:32:04 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11244&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11244  width='300' align='top'></a></td><td>The L1A jump is delayed from 110 to 95..</td></tr></table>
<!-- Author: Jose/Ignacio -->

<!-- Date: Wed May 2 20:22:42 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W5L3 
<li>problem n: 2028 
<li>Status: fixed
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: ignacio 
<li>description is: The monotonic rise hit the limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>47</td><td>100</td></tr>
<tr><td><b>Lower</b></td><td>??</td><td>??</td></tr>
<tr><td><b>Upper</b></td><td>??</td><td>??</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W5&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed May 2 20:27:11 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W4L3 
<li>problem n: 2029 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: ignacio 
<li>description is: The monotonic rise hit the limit.<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>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>150.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W4&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed May 2 20:30:10 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W9L3 
<li>problem n: 2031 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: ignacio 
<li>description is: The monotonic rise hit the limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>37</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>150.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W9&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed May 2 20:34:18 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W3L2 
<li>problem n: 2032 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: ignacio 
<li>description is: The monotonic rise hit the 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>100</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>100.0</td><td>150</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W3&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed May 2 20:48:49 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W3L4 
<li>problem n: 2033 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: ignacio 
<li>description is: The monotonic rise hit the limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>43</td><td>100</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>100</td><td>150</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W3&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed May 2 20:50:53 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W7L4 
<li>problem n: 2034 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: ignacio 
<li>description is: The monotonic rise hit the limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>69</td><td>100</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>100.0</td><td>150.</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W7&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu May 3 08:35:28 2007 -->
We have performed a silicon-bias scan for L00 and all SVX-L0 at the end of store 5402. Due to 
some problems with b0svx02 (and b0svt08), data were taken in two runs: 
<a href="http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN=240681">240681</a> and 
<a href="http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN=240687">240687</a>. 
 
The first pass of the scan was done changing only L00. The second one, that we finished in a rush, 
was taken for L00 and SVX-L0. 
<br><br> 
The CAENvolts we use as a reference was /cdf/onln/data/svxii/caencontrol/PSfiles/caenvoltsfiles/CAENvolts_04282007_0310AM.dat 
<br><br> 
The table of events is as follows: 
<ul><pre> 
         VOLTAGE      EVENT RANGE    START TIME 
            0            0-21076        5:15am  RUN 240681 
         -130        21077-50067        ---- 
         -110        50068-76176        5:28 
          -90        76177-103022       5:32 
          -70       103023-127163       5:38 
          -50       127164-151298       5:43 
          -30       151299-175700       5:49 
          -10       175701-200138       5:53 
For the previous points, we only changed the L00 voltages, not L0. For the 
rest, we changed both of them. 
            0       200139-227605       5:58 
         -120       227606-251620       6:05 
         -100       251621-275323       6:14 
          -95       275324-300414       6:18 
          -85       300415-325296       6:24 
          -80       325297-350519       6:35 
          -75       350520-380103       6:40 
          -65       380104-410002       6:46 
          -60       410003-440135       6:52 
          -55       440136-470308       6:55 
          -45       470309-491892       7:03 
          -35            0-25827        7:28  START RUN 240687 
          -25        25828-51355        7:35 
          -15        51356-76702        7:40 
            0        76703-108819       7:45 
</pre></ul>  
<!-- Author: Roberto and Oscar -->


<!-- Date: Thu May 3 09:18:38 2007 -->
Since BeamPermit was running we sent silicon to standby by  setting the TeVmon permiot OFF. It worked fine. Features to be aware off: 
<li> The command takes sligthly longer to broadcast than the standard standby from iFix: 2:30 min vs 2 min.</li> 
<li>For this period there is no refresh from the PSGui, nor IMON, so you can get some alarms (at least from procmon). 
</li>
<!-- Author: Ignacio -->
<!-- Comment: Thu May  3 09;22;38 comment by...Ignacio -->
We leave BeamPermit running. I would say that we after testing  it succesfully during shot setup (hopefully today), we can declare it official.


<!-- Date: Thu May 3 09:33:31 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11246&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11246' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11245&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11245' width='300'></a></center>
<!-- Author: Ignacio -->
<!-- Comment: Thu May  3 09;34;36 comment by...Ignacio -->
It seems the SciCo catched the birth of an erratic bias current. 

<!-- Date: Thu May 3 09:36:31 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W6L4 
<li>problem n: 2035 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: Currents_investigated
<li>entered by: ignacio 
<li>description is: The bias current has suddenly increaseed and turned erratic. Let's watch it to see how evolves. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W6&layer=L4">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Thu May 3 11:58:50 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11248&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11249  width='300' align='top'></a></td><td>The first two resin exchanges can be seen as small bumps in the flow of CC1.</td></tr></table>
<!-- Author: Jose/Miguel/Ignacio -->


<!-- Date: Thu May 3 14:12:24 2007 -->
<h3>Power supply access report</h3> 
We went in today to check the 5V DOIM of SB3W9.  We recently swapped in a new supply, which was reading back only 5.1V (nominal is 5.38V), and this coincided with an increased incidence of bit errors for e394.  So we pulled the supply out and bumped the 5V DOIM up to nominal.  Now it reads back 5.33V (although on the teststand it was reading out 5.39V).  We ran it in SVXDaq, but it's hard to tell if the bit errors for e394 have decreased.<br> 
While we were working in SE, we also reseated the bias cable for LB1W2.  During bias scans, L2 of this wedge shows strange current behavior.  We already tried reseating the cables once and it didn't help.  This time I took everything off and put it back together again, checked the bias jumpers were solidly connected, etc.  We'll see if that helps.<br>
<!-- Author: Jen, Satyajit, Ignacio, Miguel, Jose -->
<!-- Comment: Thu May  3 15;48;27 comment by...Miguel/Ignacio -->
The charasteristic curve has not changed for fa22 after the reseating ecercise.
<!-- Date: Thu May 3 14:22:41 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W9L3 
<li>problem n: 2036 
<li>Status: fixed
<li>Type: VDOIM
<li>Action: IMON_limits
<li>entered by: mondragon 
<li>description is: The current to the DOIMs has changed after the VDOIM 5V was adjusted from 5.1 to 5.31. <table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1690</td><td>1870</td></tr>
<tr><td><b>Lower</b></td><td>1650</td><td>1830</td></tr>
<tr><td><b>Upper</b></td><td>1710</td><td>1900</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W9&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu May 3 14:25:59 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W9L3 
<li>problem n: 2036 
<li>Status: fixed
<li>Type: VDOIM
<li>Action: IMON_limits
<li>entered by: ignacio 
<li>description is: As a result of the same change the 2 V current also increased (but not the voltage).<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>870</td><td>1020</td></tr>
<tr><td><b>Lower</b></td><td>830</td><td>980</td></tr>
<tr><td><b>Upper</b></td><td>885</td><td>1035</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W9&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu May 3 15:33:04 2007 -->
 <h3>ISL resin exchanges </h3> 
We are taking the opportunity of the downtime/access this morning to exchange the ISL resin 4 times. We have switched off ISL and L00 in advance since we know that this procedure triggers a ISL cooling trip (LED goes OFF for ISL) that trips the PS (not the cooling flow). The first time the PS interlock tripped. We have goen for a second resin exchange at 10:15, 
after more than an hour of flow thorugh the bed. The second resin started receiving flow at 10:40. This time the interlock did not 
trip, (Go Dean!). Third exchange  finished at 12:30 and the resin has been working until 15:30 when we askde Dean for a final resin exchange. 
  
<!-- Author: Jose/Miguel/Ignacio -->
<!-- Comment: Thu May  3 19;13;33 comment by...Jose -->
Only one out of four resin exchanges tripped ISL PS!!!! Dean is getting really good with the resin exchange.
<!-- Date: Thu May 3 15:35:46 2007 -->
We have reincluded f153 back in the database since it was holding OK for 20 minutes. f544 was  tripping on DVDD overcurrent so 
it is still outside.
<!-- Author: Miguel/Ignacio -->




<!-- Date: Thu May 3 20:26:07 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11252&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11253' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11250&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11251' ></a></center>
<!-- Author: Ignacio and Jose -->
<!-- Comment: Thu May  3 20;27;34 comment by...Ignacio and Jose -->
<h3>High Energy Physics Lab?!?!?</h3>


<!-- Date: Thu May 3 21:00:54 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11255&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11256  width='300' align='top'></a></td><td><b> Store 5409</b> with luminosity 160 E30 and no integrated dose alarm! (but note the los lumi). They have left something in reserve in the recycler in case something went wrong. SVTSpyMon and SVXMOn looks OK.</td></tr></table>
<!-- Author: Miguel/Ignacio -->
<!-- Comment: Thu May  3 21;15;15 comment by...Miguel/Ignacio -->
BeamPermit was running. It gave no problem.
<!-- Date: Thu May 3 21:02:21 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11257&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11257' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11258&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11258' width='300'></a></center>
<!-- Author: Miguel/ignacio -->
<!-- Comment: Thu May  3 21;04;09 comment by...Miguel/Ignacio -->
It looks e393 looks much healthier than before after increasing the  DOIM voltage to 5.33, back to the old situation. Let's hope this stops also the out of sync errors.



<!-- Comment: Sat May  5 01;32;58 comment by...Ignacio -->
It did not, there was just another automatic HRR.
<!-- Comment: Sat May  5 17;46;25 comment by...Ignacio -->
The bit reporter shows that the errors (60 % frequecy) in e392 have disappear.  e393 still has "unknown cahnnel" and "other bit"  but bit 1  error has disappear and out of sync has lower rate. VDoim5 ended being a little bit on the low side 5.33 (vs. 5.38 standard value). BTW before it was 5.1 . We may consider increasing it a lttle bit more.
<!-- Date: Fri May 4 07:54:21 2007 -->
<b>Some trips this morning:</b> 
LB0W0 tripped after an autohockerization, so I was paged. I tried to guide the Ace on the phone to recover the wedge once but since it tripped I asked to put the silicon standy and run without silicon while I drove in. This recovered the wedge but also  crate 10 was autohockerized. I recovered the wedges but LB0W4 was not reading back any current nor voltage (putting and inhibit) so I hockerized crate 15. Then there were DAQ problems, with several run restarts. The second of them was on my request since SVX bank was corrupted as showed by SVXMon  
<!-- Author: Ignacio -->


<!-- Date: Fri May 4 11:29:19 2007 -->
<h3>Test Stand Moved</h3> 
This morning we have moved the Silicon Interlock test stand from the first floor to the second floor. It is now situated at the north wall of the  second electronics room on the second floor, all hooked up and ready to go. We have also moved the boxes with the spares to a shelf in the first electronics room. 
<p> 
Thanks a lot to Wayne, George, and Dervin for their help.
<!-- Author: Ulrich -->


<!-- Date: Fri May 4 13:34:29 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11259&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11260' ></a></center>
<!-- Author: boveia -->
<!-- Comment: Fri May  4 14;20;34 comment by...boveia -->
<pre>e4b4 has a history of problems with chip a3.  Looking back through archived ADCMon plots, this ladder has read out an excess of high charge strips for the past month or two.  

To investigate this, one used to plot chip by chip distributions with daqana.  Are the necessary ADCMon .svx files somewhere nearby?  
</pre>

<!-- Date: Fri May 4 14:27:08 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W11L4 
<li>problem n: 2037 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: More 'physics' in new tail at high charge; see <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=351&frame=2&anchor=13:34:29'> here</a>.  Figure out what this is and what to do about it (if anything.) 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W11&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri May 4 15:12:14 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W0L0 
<li>problem n: 1802 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: mondragon 
<li>description is: Increasing IMon limits.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>110</td><td>130</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>135</td><td>160</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri May 4 15:15:53 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W8L2 
<li>problem n: 1854 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: mondragon 
<li>description is: Increasing IMON limits.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>100</td><td>120</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>125</td><td>150</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W8&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri May 4 15:20:44 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W3L1 
<li>problem n: 1868 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: mondragon 
<li>description is: Increasing limits for BIAS0<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>51.8958</td><td>120</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>120</td><td>145</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W3&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri May 4 15:27:58 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W2L2 
<li>problem n: 2038 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: mondragon 
<li>description is: Increasing BIAS0 limits.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>58</td><td>100</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>100</td><td>125</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W2&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri May 4 15:33:21 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W3L1 
<li>problem n: 1597 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: mondragon 
<li>description is: Increasing IMON limits for BIAS0.<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>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>150</td><td>175</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W3&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri May 4 16:02:39 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W5L3 
<li>problem n: 1603 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: mondragon 
<li>description is: Increasing IMON limits of BIAS0.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>70</td><td>120</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>120</td><td>145</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W5&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri May 4 16:07:18 2007 -->
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: mondragon 
<li>description is: Increasing IMON limits for BIAS0.<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>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>200</td><td>225</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: Fri May 4 16:09:22 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W2L1 
<li>problem n: 1691 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: mondragon 
<li>description is: Increasing IMON limits for BIAS0<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>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>225</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: Fri May 4 17:14:01 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11265&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11266  width='300' align='top'></a></td><td><h3> Two known problems in a row</h3> 
The new store came in with an initial luminosity of 187 10<sup>30</sup>. Losses and abort gap were low, but we had problems to get a good run... 
<br>Our favourite wedge went bad again (just one ISL ladder). This means that the VRB swap did nothing. We could  try to change the slot (again...) but we should look carefully to the backplane of this crate, at least two of them could be bad. 
<br> After restarting the run we got a corrupted SVX data bank. We reseted one of the VRBs on the SVX crates to get some reformatter errors, this should give us some information more. The run with the reformatter errors is <a href=http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=240832>240832</a>. 
</td></tr></table>
<!-- Author: Miguel and Jose -->


<!-- Date: Fri May 4 19:09:15 2007 -->
<h3> Reformatter events </h3> 
We have been looking to the events from the reformatter errors (<b>thanks to Conor!!</b>). It is really interesting! We have 5 events and they show the same pattern. It is always a pleasure to look at raw data...  
 
<pre> 
003d630 23f3 fc3b 0d8f f300 0336 0937 0338 0841 
003d640 1042 1843 0644 0d8e 0d8d 0831 2a32 0833 
003d650 f33c 113d 583e 7c3f 1f40 0f41 f342 0d8c 
003d660 0d9b 043a 0b3b 043c 0d9a 011c 131d f31e 
003d670 4e1f 0320 0d99 0d98 0641 0b42 0643 3644 
003d680 0745 0465 0e66 1167 0368 0db7 f32c 1e2d 
003d690 0c2e 032f f33f 0c40 2641 0c42 0543 0db6 
003d6a0 0db5 0322 0a23 f324 0db4 0da3 0da2 0845 
003d6b0 1846 7d47 6c48 1049 064a 034e 0f4f 2b50 
003d6c0 0351 0da1 0da0 030a 0c0b f30c 4b0d 070e 
003d6d0 0556 2257 0658 0360 f061 f362 f37f c1c1 
003d6e0 0000 0101 0202 0303 0404 0505 0606 0707 
003d6f0 0808 0909 0a0a 0b0b 0c0c 0d0d 0e0e 0f0f 
003d700 1010 1111 1212 1313 1414 1515 1616 1717 
003d710 1818 1919 1a1a 1b1b 1c1c 1d1d 1e1e 1f1f 
..... 
003d7b0 6868 6969 6a6a 6b6b 6c6c 6d6d 6e6e 6f6f 
003d7c0 7070 7171 7272 7373 7474 7575 7676 7777 
003d7d0 7878 7979 7a7a 7b7b 7c7c 7d7d 7e7e 7f7f 
003d7e0 0000 0101 0202 0303 0404 0505 0606 0707 
..... 
003d8c0 7070 7171 7272 7373 7474 7575 7676 7777 
003d8d0 7878 7979 7a7a 7b7b 7c7c 7d7d 7e7e 7f7f 
003d8e0 0000 8837 0000 28f7 0010 28f7 0000 3ba3 
003d8f0 3401 cc73 0800 0200 2a2a 2a2a 5320 6174 
003d900 7472 6f20 2066 6353 6e61 656e 2072 5043 
003d910 2055 7665 6e65 2074 7266 6761 656d 746e 
003d920 2a20 2a2a 002a 0000 0000 0000 0000 0100 
003d930 5808 0841 4110 1004 0110 0004 d200 c200 
003d940 3601 e400 3201 ea00 0000 a601 a200 0000 
003d950 00f1 fc3b 0d8f 0300 0d8e 0d8d 0d8c f376 
003d960 1e77 0f78 f379 0b7a 207b f37c 0d9b f304 
003d970 0c05 f306 0d9a 0d99 f337 0b38 0d39 0b3a 
003d980 f33b f33d 0c3e f33f 0d98 061c 091d f31e 
003d990 f35c 0a5d 015e 0db7 f320 1a21 f322 f359 
003d9a0 1c5a f35b 0db6 0741 0a42 0143 0b44 0745 
</pre> 
 
After the last ladder of our friend f32 we have the bunch of #@&! that is messing up the L3. It is always after the wedge f32. The wedge after the VRB of f32 is not always the same (in two cases f10/f11 and one case f02/f03). 
<br> It seems that maybe we can solve two problems at the same time...  
<p> For those readers that want more information the reformatter events are on: 
<pre> 
/cdf/onln/home/svxii/reformatter 
</pre> 
 
  
<!-- Author: Miguel and Jose -->

<!-- Date: Fri May 4 19:37:53 2007 -->
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: mondragon 
<li>description is: Increasing IMON limits of BIAS1<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>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>205</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: Fri May 4 19:40:48 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W3L3 
<li>problem n: 1804 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: mondragon 
<li>description is: Increasing IMON limits of BIAS0.<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>120</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>120</td><td>145</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W3&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri May 4 19:40:48 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W3L3 
<li>problem n: 1804 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: mondragon 
<li>description is: Increasing IMON limits of BIAS0.<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>120</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>120</td><td>145</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W3&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri May 4 19:50:20 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11267&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11267  width='300' align='top'></a></td><td>Ladder IB2W0L4 shows a peak on BIAS1. We should keep an eye on this one. </td></tr></table>
<!-- Author: Miguel M. -->

<!-- Date: Fri May 4 19:54:40 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W2L1 
<li>problem n: 1750 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: mondragon 
<li>description is: Increasing IMON limits for BIAS1.<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>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>150</td><td>175</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri May 4 19:59:26 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W9L4 
<li>problem n: 1881 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: mondragon 
<li>description is: Increasing IMON limits.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>110</td><td>120</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>130</td><td>145</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W9&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri May 4 19:59:26 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W9L4 
<li>problem n: 1881 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: mondragon 
<li>description is: Increasing IMON limits.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>110</td><td>120</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>130</td><td>145</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W9&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri May 4 20:02:05 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W10L4 
<li>problem n: 2039 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: mondragon 
<li>description is: Increasing IMON limits<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>48</td><td>100</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>100</td><td>125</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W10&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri May 4 20:11:37 2007 -->
Thanks to Bill, TevMon mails are back. TevMon will be sending pages to the alphanumeric pager and the lucky main pager carrier will be the first one to notice that TevMon went to ALARM...
<!-- Author: Jose -->
<!-- Comment: Fri May  4 21;16;54 comment by...Ignacio -->
lucky me!
<!-- Date: Fri May 4 20:32:15 2007 -->
MCR called because AGIGI2 was really low and they wanted to re-calibrate it. I noticed at the beginning of the store the same thing (after the mess I forgot) but on Rick counters.  
<br>They have just called us back saying that it seems that everything looks fine and the abort gap is really clean... They are suprised they can do so well <a href=http://www-bd.fnal.gov/cgi-mach/machlog.pl?nb=tev07&action=xe&page=164&time=19:34:31>Tevatron e-log</a>
<!-- Author: Jose -->




<!-- Date: Sat May 5 12:35:29 2007 -->
Yesterday evening Tevatron was having problems with E0  compressors. We decided to stay in since MCR adviced us they would abort the beam in control manner (and the abort gap was very clean). 
<!-- Author: Ignacio -->


<!-- Date: Sat May 5 12:40:24 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11270&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11271  width='300' align='top'></a></td><td>Strage spike this morning. COoling Line 2.2 is a bit cooler: 15.4 C.</td></tr></table>
<!-- Author: Ignacio -->
<!-- Comment: Sat May  5 14;31;39 comment by...Ignacio -->
I continued watching the cooling during the trigger table test. There was a dip in all ISL cooling related temperatures of 1.5-2 C
at 1:45-1:50, cominp back at previous level at 1:55. The ony thing that happend during this time is stopping the run to change trigger tables. Is it coming from the L1A rate (SVX heating more or less ISL, 30 KHz=>0=>30 KHz), L2A (550 Hz=>0=> 550 Hz) or just a coincidence? 
<!-- Comment: Sat May  5 17;26;47 comment by...Ignacio -->
Cooling Line 2.2: 18.5 C.
<!-- Date: Sat May 5 14:26:37 2007 -->
<b>Trigger table test:</b> I came here to continue the trigger test  
table from Friday. Then, ther were some problems related to  ScalerMon. We started directly running with silicon (since the no silicon test  has been already done). There were a few bias pinkies becuase all the lumi eneables relax at the same time and since we were below 40 E30 that measn a jump from 4 KHz to 30 KHz. No problem otherwise. 
<!-- Author: Ignacio -->



<!-- Date: Sat May 5 15:35:43 2007 -->
<b>Conductivity update:</b> I took a sample form ISL today at 14:30. Conductivity  is down  at 600 muS from 630 muS yesterday, pH 2.94 from 2.92 yesterday. I think the resin is completely saturated. SVX conductivity has been slowly increasing for the last 5 days. The valve has been opened for the last 6 days. We should ask for resin exchange for both systems on Monday.
<!-- Author: Ignacio -->



<!-- Date: Sat May 5 17:54:45 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W6L4 
<li>problem n: 74 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Monitoring
<li>entered by: ignacio 
<li>description is: CAP_ID erros from chip a5, which is sparsed out, are back. Not a concern. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W6&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat May 5 19:19:46 2007 -->
I have installed in the TWiki the pluging <i>ChartPlugin</i> that creates graphs from data on tables on TWiki pages, updating the graph when the table is changed.
<!-- Author: Jose -->


<!-- Date: Sat May 5 19:24:41 2007 -->
The summary of the studies performed on the effect of the resin on pH and Conductivity can be found on the TWiki page <a href=http://b0sili01.fnal.gov/cgi-bin/TWiki/bin/view/Silicon/ResinSolution>Resin Studies</a>. The actual situation of the ISL coolant is on the TWiki page <a href=http://b0sili01.fnal.gov/cgi-bin/TWiki/bin/view/Silicon/PHandConductivity>ISL coolant now</a>.  
<!-- Author: Ignacio and Jose -->


<!-- Date: Sat May 5 22:04:48 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11272&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11273  width='300' align='top'></a></td><td>Sasha kindly took store  5411 home. L = 188.5 E30. SvtSpyMon and SVXMON looked allright.</td></tr></table>
<!-- Author: Sasha/Ignacio -->


<!-- Date: Sun May 6 06:06:55 2007 -->
I was paged for a AVDD pinky (note to me and MPCs in general: Make sure you point  the flow charge to every SciCo). Afterwards there was a resonance that looks like L2R triggered. The L2 deadtime had a spike at the same time.
<!-- Author: Ignacio -->


<!-- Date: Sun May 6 08:45:27 2007 -->
CCE2.2 weather report: temperatures are still on the rise, now between 19.5 and 20 °C: 
<pre> 
$ ssh b0gateway.fnal.gov "~husemann/bin/extract_temp.pl" 
... 
08:36:41: ISL_TE_CCE2L6_2OUT =  19.38  
08:37:11: ISL_TE_CCE2L6_2OUT =  20.07  
08:37:41: ISL_TE_CCE2L6_2OUT =  19.48  
08:39:41: ISL_TE_CCE2L6_2OUT =  19.38  
08:40:11: ISL_TE_CCE2L6_2OUT =  19.48  
08:40:41: ISL_TE_CCE2L6_2OUT =  19.58  
08:41:11: ISL_TE_CCE2L6_2OUT =  19.48  
08:43:41: ISL_TE_CCE2L6_2OUT =  19.58  
 
average since midnight: 19.261 
average last hour     : 19.534 
</pre> 
If the bubble isn't flushed out this morning, I guess we have to take out ladders.
<!-- Author: Ulrich -->


<!-- Date: Sun May 6 20:51:17 2007 -->
<center><a href='/elog/notebooks/silicon/Sun_May__6_2007_205017.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11275' ></a><a href='/elog/notebooks/silicon/Sun_May__6_2007_205050.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11277' ></a></center>
<!-- Author: Ignacio -->
<!-- Comment: Sun May  6 20;52;38 comment by...Ignacio -->
I do not understand why this hot tower is not masked.


<!-- Date: Sun May 6 21:09:47 2007 -->
The error log during the resonances. 
<pre>  
(MLE) b0felix.fnal.gov:TEDCpp:May 6, 2007 04:55:39 AM->{ 4:55:39, 5/6/2007 }: L2-Pulsar-Linux: Halted while  waiting for ClusterFinder data 
(MLE) b0felix.fnal.gov:TEDCpp:May 6, 2007 04:55:41 AM->{ 4:55:41, 5/6/2007 }: L2-Pulsar-Linux: Halted while  processing happily 
(RC)   4:55:41 Halt -> HALTED 
(RC)   4:55:46 Recover -> RECOVERED 
(RC)   4:55:57 Run -> ACTIVE 
(MLE) b0server03.fnal.gov:ConsumerErrorRe:May 6, 2007 05:00:54 AM->CalibrationReady: Count 1 Event 15526336 Run 240871 Stage0  
(MLE) b0wcal05:Messenger:May 6, 2007 05:02:21 AM->Event 15593660: Bunchcounters in slot 16 (BC=136) and slot 9 (BC=59) disagree (L2B=1)  
(MLE) b0wcal05:Messenger:May 6, 2007 05:02:21 AM->Runtime Error 11, Event 15593660: Bunch counter mismatch, mismatch count = 1 
(MLE) b0control21.fnal.gov:Thread-25:May 6, 2007 05:06:04 AM->SVXMon not connected since 2007-05-06 05:05:56.0 
(MLE) b0wcal04:Messenger:May 6, 2007 05:06:30 AM->Event 15730817: Bunchcounters in slot 16 (BC=12) and slot 9 (BC=62) disagree (L2B=1)  
(MLE) b0wcal04:Messenger:May 6, 2007 05:06:30 AM->Runtime Error 3, Event 15730817: Bunch counter mismatch, mismatch count = 1 
(MLW) b0control21.fnal.gov:Thread-25:May 6, 2007 05:07:48 AM->Inhibit flag SET  
(MLE) b0felix.fnal.gov:TEDCpp:May 6, 2007 05:08:08 AM->{ 5:8:8, 5/6/2007 }: L2-Pulsar-Linux: Halted while  waiting for ClusterFinder data 
(MLE) b0felix.fnal.gov:TEDCpp:May 6, 2007 05:08:10 AM->{ 5:8:10, 5/6/2007 }: L2-Pulsar-Linux: Halted while  processing happily 
(RC)   5:08:11 Halt -> HALTED 
(RC)   5:08:20 Recover -> RECOVERED 
(MLW) b0control21.fnal.gov:Thread-25:May 6, 2007 05:08:21 AM->Inhibit flag CLEAR  
(RC)   5:08:29 Run -> ACTIVE 
(MLE) b0control21.fnal.gov:Thread-25:May 6, 2007 05:10:58 AM->FrontEnd Error: VRB_SVX_02  
CT: 2007.05.06 05:11:02 
11'2" 1 crate/s: b0svx02(112),  in error. [RXPT] 
(MLE) b0felix.fnal.gov:TEDCpp:May 6, 2007 05:11:25 AM->{ 5:11:25, 5/6/2007 }: L2-Pulsar-Linux: Halted while  processing happily 
(MLE) b0felix.fnal.gov:TEDCpp:May 6, 2007 05:11:25 AM->{ 5:11:25, 5/6/2007 }: L2-Pulsar-Linux: Halted while  waiting for SVT data 
CT: 2007.05.06 05:11:25 
11'25" b0svx02:Messenger:May 6, 2007 05:11:26 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: 2007.05.06 05:11:27 
11'27" 1 crate/s: b0svx02(112),  in error. [RXPT] 
(RC)   5:11:29 Halt -> HALTED 
(RC)   5:11:37 Recover -> RECOVERED 
(RC)   5:11:40 Run -> ACTIVE 
(MLE) b0control21.fnal.gov:Thread-25:May 6, 2007 05:11:50 AM->  Level 2 Decision Timeout 
 
(MLE) b0felix.fnal.gov:TEDCpp:May 6, 2007 05:11:57 AM->{ 5:11:57, 5/6/2007 }: L2-Pulsar-Linux: Halted while  waiting for ClusterFinder data 
(MLE) b0felix.fnal.gov:TEDCpp:May 6, 2007 05:11:59 AM->{ 5:11:59, 5/6/2007 }: L2-Pulsar-Linux: Halted while  processing happily 
(RC)   5:11:59 Halt -> HALTED 
(RC)   5:13:30 Recover -> RECOVERED 
(RC)   5:13:32 Run -> ACTIVE 
(MLE) b0control21.fnal.gov:Thread-25:May 6, 2007 05:13:50 AM->FrontEnd Error: VRB_SVX_02  
CT: 2007.05.06 05:13:59 
13'59" b0svx02:Messenger:May 6, 2007 05:14:00 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] 
(MLE) b0felix.fnal.gov:TEDCpp:May 6, 2007 05:14:01 AM->{ 5:14:1, 5/6/2007 }: L2-Pulsar-Linux: Halted while  waiting for SVT data 
CT: 2007.05.06 05:14:02 
14'2" 1 crate/s: b0svx02(112),  in error. [RXPT] 
(MLE) b0felix.fnal.gov:TEDCpp:May 6, 2007 05:14:03 AM->{ 5:14:3, 5/6/2007 }: L2-Pulsar-Linux: Halted while  processing happily 
(RC)   5:14:03 Halt -> HALTED 
(RC)   5:17:05 Recover -> RECOVERED 
(RC)   5:17:07 Run -> ACTIVE 
(MLE) b0felix.fnal.gov:TEDCpp:May 6, 2007 05:17:19 AM->{ 5:17:19, 5/6/2007 }: L2-Pulsar-Linux: Halted while  waiting for ClusterFinder data 
(MLE) b0felix.fnal.gov:TEDCpp:May 6, 2007 05:17:21 AM->{ 5:17:21, 5/6/2007 }: L2-Pulsar-Linux: Halted while  processing happily 
(RC)   5:17:21 Halt -> HALTED 
(RC)   5:17:30 Recover -> RECOVERED 
(RC)   5:17:32 Run -> ACTIVE 
</pre>
<!-- Author: Ignacio -->


<!-- Date: Mon May 7 00:21:48 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11278&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11278  width='300' align='top'></a></td><td>Evolution of the CCE2L6_2OUT during the last months. </td></tr></table>
<!-- Author: Jose -->


<!-- Date: Mon May 7 03:45:11 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11279&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11279  width='300' align='top'></a></td><td>Saturday night's resonance.</td></tr></table>
<!-- Author: Ignacio -->


<!-- Date: Mon May 7 04:55:50 2007 -->
I took out f304. The temperature has gone down by ~2 C, now is 17.5  C.
<!-- Author: Ignacio -->


<!-- Date: Mon May 7 04:59:12 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11282&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11282  width='300' align='top'></a></td><td>A better screenshot of the same resonance.</td></tr></table>
<!-- Author: Ignacio -->


<!-- Date: Mon May 7 05:55:03 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11284&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11285  width='300' align='top'></a></td><td>Store 5412 with low lumi of 144 E30, 15 KHz with 3.5 % deadtime.  SVTSpyMon &SVXMon OK.</td></tr></table>
<!-- Author: Ignacio -->


<!-- Date: Mon May 7 08:34:22 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11286&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11286  width='300' align='top'></a></td><td>L2 spike duringh resonance.</td></tr></table>
<!-- Author: Ignacio -->


<!-- Date: Mon May 7 08:47:12 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11291&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11291' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11288&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11288' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11289&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11289' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11290&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11290' width='300'></a></center>
<!-- Author: Jose/Ignacio -->
<!-- Comment: Mon May  7 08;56;43 comment by...Jose/Ignacio -->
So for CCE1.1 the OUT went up around 200 days before IN. We may expect that if the CC2.2 IN gets blocked now the OUT will be bclocked around 2500.  

<!-- Comment: Mon May  7 09;07;57 comment by...Ulrich -->
What kind of voodoo science is this? The IN and OUT are on the same cooling pipe, at the elbow at the inlet and at the elbow at the outlet. The prism is stuck around that elbow, and the input and output temperature depend on where exactly the orifice is located.


<!-- Comment: Mon May  7 18;03;52 comment by...Ignacio -->
Sorry, I meant: "if the CC2.2 OUT gets blocked now, the  IN will be blocked around 2500. (November 07)".
<!-- Date: Mon May 7 09:30:30 2007 -->
<h3>Summary of the Week</h3> 
 
Major themes during the week: 
<li> Accelerator performance. Integrated luminosity alarms</li> 
<li>BeamPermit running since Wendsday. Java application to reset the permit working.</li> 
<li>Bias Scan on Thursday.</li> 
<li> 1 h access to fix 5V DOIM voltage for e39. Bit errors from e392 disappear, e393 is back to "normal."</li> 
<li> Cooling. "Chemistry lab". 6 Resin exchanges gets us from 750 muS to 600 muS (expect 450 muS), pH 2.94 from 2.82 (expect 3.15). CCE2.2_OUT warming up, one ladde5r out.</li> 
<li> DAQ: Resonances. VRB problem linked to corrupted SVX bank?</li>
<!-- Author: Ignacio -->
<!-- Comment: Mon May  7 14;24;39 comment by...boveia -->
<b>Monitoring summary</b>
No (substantial) new problems.
<p>
<pre>b0sili02:/data02/stuart/svx</pre>
now contains some recent .svx files for use in daqana.