<!-- Title: 11:19:07  Mon Feb 12 2007 -->
<!-- Crewchief: Ulrich (MPC) -->
<!-- Op1: Roberto (Observer) -->
<!-- Op2: Ignacio (SPL) -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
One more week...


<!-- Date: Mon Feb 12 11:22:38 2007 -->
<h3>TevMon Documentation</h3> 
Ron Moore created a <a href="http://home.fnal.gov/~ronmoore/tevmon_sili_summary.htm">web page</a> for the new TevMon. Please have a look at it. I will collect comments and send them to Ron.
<!-- Author: Ulrich -->
<!-- Comment: Mon Feb 12 14;24;44 comment by...ronmoore -->
Try this <a 
href=http://home.fnal.gov/~ronmoore/tevmon/tevmon_sili_summary.htm>link</a> instead...
<!-- Comment: Mon Feb 12 21;58;09 comment by...Ulrich -->
Ron suggested that the Silicon group hosts his web page once it is finalized. In a pre-emptive strike, I have merged his page with my previous TWiki page:
<a href="http://b0sili01.fnal.gov/cgi-bin/TWiki/bin/view/Silicon/NewTevMon">http://b0sili01.fnal.gov/cgi-bin/TWiki/bin/view/Silicon/NewTevMon</a>
<!-- Date: Mon Feb 12 12:04:20 2007 -->
<h3>Access tomorrow?</h3> 
It is likely that we will get the 2-hour access to fix the power supply problems for e364 and swap the control unit on the ISL CCE1 supply valve tomorrow. The spare control units arrived today. Given that the store came in around 8:30, this could be around the same time tomorrow. Be prepared.
<!-- Author: Ulrich -->
<!-- Comment: Mon Feb 12 13;42;06 comment by...Ulrich -->
Here is Drendel's very preliminary plan:
<pre>
The hope is to spin the current store until at least 7am, and then let CDF and D0 in on access.</pre>


<!-- Comment: Mon Feb 12 15;04;17 comment by...Ulrich -->
Peter Wilson just came to inform us that the current store will be terminated by 8:00. This may be preceded by Tevatron studies, for the crystal collimator and maybe also for TEL1. Stay tuned.


<!-- Comment: Mon Feb 12 15;22;47 comment by...Ulrich -->
Now it is official:
<pre>
We have collision hall accesses to schedule as well as Tevatron end of store studies.   We have personnel scheduling issues to worry about, as well as potential bad weather tomorrow.  As a result, assuming the store survives, I am setting the end of store time now.  We'll do the end of store studies from 6am to 8am and terminate the store at 8am.   Upon store termination, both CDF and D0 get a two hour access.   If we happen to be low on pbars, Tevatron experts have a list of studies available.  If not, we'll go straight into shot setup.  I will provide a more formal and detailed collider plan later this evening. Of course, if the store fall out early, all of this changes.
</pre>


<!-- Comment: Mon Feb 12 22;33;06 comment by...Ulrich -->
Word from the Drendel:
<pre>
We set an an end of store time sooner than I normally would due to personnel availability.   One of the experiments had to arrange for an expert from outside of the lab to be present for their access. 
</pre>
What does this guy think? That everybody is living on site? Next time Jen will be mentioned by name...
<!-- Date: Mon Feb 12 16:36:24 2007 -->
<pre>Just cranked up the valve for CCE1 a little more, from 62% to 65%. The flow is now back to 2.0 lpm, at a pressure just above 13 psi. This should be sufficient until the access tomorrow morning.</pre>
<!-- Author: Ulrich -->

<!-- Date: Mon Feb 12 19:17:13 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W4L1 
<li>problem n: 1925 
<li>Status: fixed
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: Bumping up Bias0 current limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>51.2482</td><td>100.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>100.0</td><td>125.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W4&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Feb 12 19:18:16 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W2L0 
<li>problem n: 1768 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: Bias0 current needs to be bumped up once more.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>78.0239</td><td>115.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>115.0</td><td>150.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W2&layer=L0">report</a></ul>
<!-- Author: Problem DB -->





<!-- Date: Tue Feb 13 05:14:29 2007 -->
Got paged apparently because of one of the spurious "Silicon Alarms". On top of that, the shift crew got confused by:  
<ul> 
<li>The standard ignored alarms in iFix for ISL<li> 
<li>Black areas in IMON/PS GUI which correspond to the printed reference above</li> 
</ul> 
 Why do people worry about these things only in the middle of the night?
<!-- Author: Ulrich -->


<!-- Date: Tue Feb 13 07:11:50 2007 -->
<h3>Preparation for the Access</h3> 
In preparation for the access at 8:00, I have switched off the Silicon. I'll change the SVX temperature set point to -6°C and adjust the trip limits now.
<!-- Author: Ulrich -->


<!-- Date: Tue Feb 13 10:01:24 2007 -->
<h3>e364 Power Supply Access Summary</h3> 
Last <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=339&frame=2&anchor=10:36:51'>Sunday</a>, e364 started tripping on DVDD overvoltage and had to be taken out.  Today we swapped out the power supply (we assumed it was the power supply, we didn't have time to try swapping cables to confirm it).  The new supply loadbox tested fine.  We have now powered e36 to standby and bias several times, and e364 has not tripped again.  Some limits might need adjusted.  I'll test the power supply we pulled out before sending it to Prep, to make sure it still trips on the teststand.  But it looks like e364 is back in business!<br> 
 
  
<!-- Author: Jen, Satyajit, Jose, Ignacio -->

<!-- Date: Tue Feb 13 10:03:31 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W6L4 
<li>problem n: 1924 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: PS_work
<li>entered by: jpursley 
<li>description is: Swapped out the power supply, and this ladder is no longer tripping.  Keep an eye on it for a couple weeks to make sure we don't see the trips again.  See <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=340&frame=2&anchor=10:01:24'>elog</a>.    
<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: Tue Feb 13 11:57:53 2007 -->
<h3>Access for ISL CCE1 e-valve control unit</h3> 
In parallel to the power supply work, we (Warren Bowman, Jim Loskot, Ulrich) made a controlled access to exchange the control unit for the electric valve on the ISL supply line CCE1. During an <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=339&frame=2&anchor=20:34:21'> 
access last week</a>, we had tried to trouble-shoot the valve and concluded that most probably the control unit was bad and had to be replaced. The spare control units arrived yesterday. The hope was that we swap in the new unit and be good again. Unfortunately, this didn't quite work out. 
<p> 
First we closed all e-valves in East ISL. For the work on the valve, we also closed the manual supply valve of CCE1. We configured the new control unit like the old one (dip switch positions: on-on-off-on, for 4-20 mA controls and no ramp) and connected the new unit to the system. First we couldn't get any flow to the cooling circuit, so we took the system apart, checked and improved the mechanical and electric connections and measured the voltages for 24VDC power and valve control. We tried again to get flow — no success. Even the good old "smack it with a wrench" method was unsuccessful (sorry, Roser!). When we opened the valve to 100%, we got at least some flow, so we adjusted the potentiometer (P3) such that we would get enough flow at valve settings below 100%, just as last week. 
<p> 
These findings point to the following conjecture: 
<ul> 
<li>It is the valve itself: the valve is somehow stuck or sluggish and needs more power to be opened. In this case we would expect the flow to continue dropping.</li> 
<li>It is the valve and the control unit: in addition to the sluggish valve, the old control unit got weak. In this case the situation is stable now. We will know the trend in a couple of hours.</li> 
</ul> 
We should look into replacing the valve in any case. The estimated delivery is in about 3 weeks from now. Warren estimates that the valve can be replaced within an hour or so. The valve is connected to 5/8-inch polyflow tubes with compression fittings on both sides.  We have to pre-mount the valve on the bench, isolate and drain the cooling line, swap in the new part and be done with it.  If we have even more time, we may want to have a look at the rest of the supply line as well (flow orifice, flow meter, etc.).
<!-- Author: Ulrich -->
<!-- Comment: Tue Feb 13 16;09;07 comment by...Ulrich -->
While we were sticking to our schedule (ok, we were about 15 minutes late), D0 took until 15:00, or in the words of the MCR shift summary:
<pre>
15:53:10-  Shift Summary: Started shift with the wind howling and the snow blowing around. CDF and D0 started what was supposed to be a 2 hour access (as opposed to a three hour tour) - CDF held to this, but the D0 access turned into the Energizer Bunny TM of accesses, continuing until ~1500. 
</pre>
<!-- Comment: Tue Feb 13 21;05;35 comment by...Ulrich -->
When I left around 20:00, the CCE1 flow was more or less the same as in the morning, between 1.95 and 2.0 lpm. Let's wait until tomorrow morning for a longer-term trend.
<!-- Date: Tue Feb 13 15:09:53 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10751&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10751' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10752&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10752' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10753&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10753' width='300'></a></center>
<!-- Author: Ignacio -->
<!-- Comment: Tue Feb 13 15;15;26 comment by...Ignacio/Jose -->
We have increased the bias voltage in the 3 L00 ladders fa10, fa11 and fa12 from 85 V to 135 V. These ladders 
had the hardware voltage limit increased to 160 V. The signal vs. bias plots from Roberto & Oscar show that at 85 V they were undepleted. The plots above show the result of increasing the voltage step by step. Afterwards we changed the hardware database using the cardEditor/traceSilicon.



<!-- Date: Tue Feb 13 18:26:04 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10754&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10755  width='300' align='top'></a></td><td><h3>Store 5226</h3> 
Store 5226 came in with an initial luminosity of 280e30, new record! SVXMon and SVTSpyMon look good.</td></tr></table>
<!-- Author: Roberto & Ulrich -->

<!-- Date: Tue Feb 13 18:33:13 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W6L3 
<li>problem n: 1926 
<li>Status: fixed
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: ballarin 
<li>description is: changing limits after power supply swap.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>860.273</td><td>920.0</td></tr>
<tr><td><b>Lower</b></td><td>855.0</td><td>910.0</td></tr>
<tr><td><b>Upper</b></td><td>875.0</td><td>930.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W6&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Feb 13 18:37:22 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W6L0 
<li>problem n: 1927 
<li>Status: fixed
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: ballarin 
<li>description is: changing limits after power supply swap<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>81.6701</td><td>58</td></tr>
<tr><td><b>Lower</b></td><td>70.0</td><td>40.0</td></tr>
<tr><td><b>Upper</b></td><td>100.0</td><td>70.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W6&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Feb 13 19:03:17 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W6L4 
<li>problem n: 1924 
<li>Status: fixed
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: ballarin 
<li>description is: changing limits after power supply swap<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>147.548</td><td>240.0</td></tr>
<tr><td><b>Lower</b></td><td>100.0</td><td>160.0</td></tr>
<tr><td><b>Upper</b></td><td>185.0</td><td>260.0</td></tr></table> 
<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: Tue Feb 13 19:12:12 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W6L0 
<li>problem n: 1928 
<li>Status: fixed
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: ballarin 
<li>description is: changing nominal voltage for avoiding pinkie alarms<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>348.803</td><td>340.0</td></tr>
<tr><td><b>Lower</b></td><td>340.0</td><td>330.0</td></tr>
<tr><td><b>Upper</b></td><td>360.0</td><td>350.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W6&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Feb 13 19:19:20 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W6L1 
<li>problem n: 1929 
<li>Status: fixed
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: ballarin 
<li>description is: shifting limits for avoid pinkie alarms<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>74.4661</td><td>74.4661</td></tr>
<tr><td><b>Lower</b></td><td>60.0</td><td>70.0</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=B3W6&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Feb 13 19:35:18 2007 -->
Entered in Incident database: <ul>
<li>Submitted by: ballarin
<li>Description of Problem: We had a massive trip of almost all Layer 0 and Layer 1 ladders in b0fib06, mostly on DVDD overcurrent. Luckily, we were in the control room and could recover things with only 11 minutes of downtime. We rebooted b0fib06 and brought it to CONFIG. Then we recovered the trips one by one. Some ladders tripped again almost immediately, so we asked the Ace to CONFIG b0fib06 a couple of times. Here is a list of the trips from the PS GUI log:
<pre>
Tue Feb 13 18:40:29 CST 2007                        TRIP: SVX  B3  W4 DVDD0 OverCurrent
Tue Feb 13 18:40:29 CST 2007                        TRIP: SVX  B3  W5 DVDD0 OverCurrent
Tue Feb 13 18:40:29 CST 2007                        TRIP: SVX  B3  W6 DVDD0 OverCurrent
Tue Feb 13 18:40:29 CST 2007                        TRIP: SVX  B3  W7 DVDD0 OverCurrent
Tue Feb 13 18:40:29 CST 2007                        TRIP: SVX  B3  W8 AVDD0 OverCurrent
Tue Feb 13 18:40:29 CST 2007                        TRIP: SVX  B3  W9 DVDD0 OverCurrent
Tue Feb 13 18:40:29 CST 2007                        TRIP: SVX  B4  W4 DVDD0 OverCurrent
Tue Feb 13 18:40:29 CST 2007                        TRIP: SVX  B4  W5 DVDD0 OverCurrent
Tue Feb 13 18:40:29 CST 2007                        TRIP: SVX  B4  W6 DVDD0 OverCurrent
Tue Feb 13 18:40:29 CST 2007                        TRIP: SVX  B4  W7 DVDD0 OverCurrent
Tue Feb 13 18:40:29 CST 2007                        TRIP: SVX  B4  W9 DVDD0 OverCurrent
Tue Feb 13 18:40:29 CST 2007                        TRIP: SVX  B5  W5 AVDD0 OverCurrent
Tue Feb 13 18:40:29 CST 2007                        TRIP: SVX  B5  W7 DVDD0 OverCurrent
Tue Feb 13 18:40:38 CST 2007                        TRIP: SVX  B3  W6 DVDD1 OverCurrent
Tue Feb 13 18:40:38 CST 2007                        TRIP: SVX  B4  W9 DVDD1 OverCurrent
Tue Feb 13 18:41:05 CST 2007                        Software protection trip: High DVDD Current  SVX B4 W8 L0 current 210.0 softLimit 150.0
Tue Feb 13 18:41:06 CST 2007                        Software protection trip: High DVDD Current  SVX B5 W6 L0 current 210.0 softLimit 150.0
Tue Feb 13 18:41:08 CST 2007                        Software protection trip: High DVDD Current  SVX B5 W9 L0 current 237.0 softLimit 150.0
Tue Feb 13 18:41:18 CST 2007                        TRIP: SVX  B4  W8 DVDD0 OverCurrent
Tue Feb 13 18:41:18 CST 2007                        TRIP: SVX  B5  W6 DVDD0 OverCurrent
Tue Feb 13 18:41:18 CST 2007                        TRIP: SVX  B5  W9 DVDD0 OverCurrent
</pre>
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/idb/DBentry.pl?incident_number=138">Incident Report</a></ul>
<!-- Author: Incident DB -->



<!-- Date: Tue Feb 13 21:03:26 2007 -->
<table border=0><td><tr><td bgcolor=#e0e030>The Silicon Cooling pager is currently switched off because of spurious pages. Please use the Silicon Main pager (218-8227) instead.</td></tr></td></table>
<!-- Author: Ulrich -->
<!-- Comment: Wed Feb 14 08;00;08 comment by...Ulrich -->
I have switched on the Cooling pager an hour later, and it was quiet.
<!-- Date: Tue Feb 13 21:50:17 2007 -->
Got paged because SciCo could not close warning windows after a pinkie. The cause was the pop-up window which tells you where a history plot is stored. Only after that window is closed, the rest of the GUI becomes responsive again.
<!-- Author: Ulrich -->


<!-- Date: Wed Feb 14 07:50:32 2007 -->
Got paged around 5:30 for a DVDD pinkie in ISL B4L0W0. This was just a late consequence of a problem that happened earlier: at around 3:20, IMON had stopped updating with <pre>Excpetion in thread "Thread-1" java.lang.OutOfMemoryError: Java heap space</pre> 
 When the Ace restarted IMON, the 4 channels that are currently ignored (Bias for e294 and e424, AVDD for e550, DVDD for f400) got unignored. The Ace looked up three of them, the fourth got me the page. Two things left to do for me: 
<ol> 
<li>Revisit the channels and see if we can change their limits for good.</li> 
<li>Put up a current list of ignored channels and add instructions to ignore them when you have to restart IMON.</li> 
</ol>
<!-- Author: Ulrich -->


<!-- Date: Wed Feb 14 07:59:32 2007 -->
The record store didn't have a very long lifetime. Due to a wet engine problem in A1, the Silicon and 15 minutes later also the rest of the detector were switched to "end of store". After an hour, MCR decided to keep the store in and declared the situation stable, so we started running again. Around 4:20, the wet engine ran out of helium and induced a Tevatron abort, which was <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2007&action=view&page=133&frame=2&anchor=04:44:15.803'> 
clean</a> for us.
<!-- Author: Ulrich -->



<!-- Date: Wed Feb 14 08:28:54 2007 -->
<h3>ISL e-valve problems not solved</h3> 
This morning, the flow in CCE1 was down to 1.85 lpm, starting from 2.0 lpm yesterday morning. So it is decreasing at about the same rate as before, maybe a little slower. I have opened up the valve from 50% to 52% to compensate.
<!-- Author: Ulrich -->
<!-- Comment: Wed Feb 14 09;21;12 comment by...Jose/Ulrich/Ignacio -->
The preassure on the COT face started fluctuating and going above the 13.3 warning limit for first time  at 08:27:4, and above 13.5 
(alarm) at 09:12. We closed the valve by 1%. Pressure is 12.8 psia now. Flow 1.9 lpm.
<!-- Date: Wed Feb 14 08:52:54 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W2L4 
<li>problem n: 1423 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: husemann 
<li>description is: The ladder ran error-free for the last 3 days, however, the problem may return any time soon. Also the efficiency reporter shows smaller inefficiency. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W2&layer=L4">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Wed Feb 14 10:54:16 2007 -->
Regular reboot of SVXIICON, no problems.
<!-- Author: Ulrich -->


<!-- Date: Wed Feb 14 11:10:49 2007 -->
<p>Unsuccessful test with the development DB. We asked for a refresh of the development HWDB to retake the threshold studies. Using the quiet time provided by the D0 "half hour" access, we tried to get one run done with using rc pointing to development DB and specifying the run number (smaller than 1000). Nothing worked...  
 
<p>We tried to use the "old procedure": booking with the standard run control and then using the same partition in the development DB to repartition again. The rc looking at the development DB complained about the crates being already booked and did not go to partition.  
 
<p>Then we tried with rc on production DB to set a run number smaller than 1000 and it did not work. 
 
<p>It seems that some modifications must be done again in this new development DB version.  
<!-- Author: Ignacio/Jose -->


<!-- Date: Wed Feb 14 14:53:08 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10757&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10757  width='300' align='top'></a></td><td>Shot setup  
store: 5228 
luminosity: 228e30 
Soon after the shot setup, LOSTP plot was unstable (went up to 12 kHz) and we turned the silicon to standby.</td></tr></table>
<!-- Author: ballarin -->
<!-- Comment: Wed Feb 14 14;59;37 comment by...ballarin -->
<pre>MCR is tuning the beam in order to stabilize it. 
Run stopped.</pre>

<!-- Comment: Wed Feb 14 15;23;17 comment by...Roberto -->
<pre>Run restarted at 15:20 after stabilization of LOSTP</pre>


<!-- Comment: Wed Feb 14 17;58;04 comment by...Ulrich -->
Our first guess for the reason for high proton losses was a misplaced collimator, and we were right! See Ron Moore's summary in the Tevatron e-log:
<pre>
-- Wed Feb 14 16:26:47 comment by...rm, bh, ja, das --  Yikes! What happened here?
Store 5228 came in with initial lumi ~230 with proton halo somewhat higher than normal. (CDF normally < 1 kHz was up around 6 kHz.) Since we had made considerable tune changes between stores, the tunes were thought to have landed badly, so the proton vertical tune was raised. Unfortunately, the tune was raised too much and the proton emittances blew up as the tune neared 3/5 (see T:SLPSH[13] in left plot). That's when the luminosity lifetime went to hell. We recovered the lumi lifetime by putting the tunes back near to where they were at the start of HEP. (Note the 1.7 GHz Schottky detector proton VSA had no signal, so we were lacking an important diagnostic.) In the midst of the hubbub, we realized that the E03V collimator was out 300 mils farther than normal...that was probably the reason for the higher proton halo in the first place. Dean nudged it in after we had recovered the lifetime (right side of left plot). Since the proton emittances had blown up, we needed to push up the pbar tunes to counteract the reduced beam-beam tune shift (right plot)...pbar lifetimes increased to that expected from luminosity burn-up. Whew! 
</pre>
<!-- Date: Wed Feb 14 15:50:36 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10758&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10758  width='300' align='top'></a></td><td>an AVDD pink cell</td></tr></table>
<!-- Author: ballarin -->



<!-- Date: Wed Feb 14 20:07:39 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10759&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10759  width='300' align='top'></a></td><td><h3>e294: Bias Current Gone Wild</h3> 
We just encountered two trips on bias current in e294. The current had been erratic for a while, but now it hit the trip limit of 1000 μA. We bumped up the trip limit to 1500 μA and try to investigate more tomorrow.</td></tr></table>
<!-- Author: Ulrich -->
<!-- Comment: Wed Feb 14 20;28;32 comment by...Ulrich -->
I have also changed the limit in the hardware database and re-created the <tt>CAENcurrent.dat</tt> file. The symbolic link from the current file to the sub-directory <tt>caencurrentfiles</tt> was <b>missing</b> both in <tt>PSfiles</tt> and <tt>PSfilesNew</tt>! The last time this happened was after a crash button incident in the summer of 2005 when it took 6 people and 5 hours to figure out what's going on.

<!-- Date: Wed Feb 14 20:10:32 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W9L4 
<li>problem n: 1785 
<li>Status: needs_work
<li>Type: BIAS
<li>Action: Incident
<li>entered by: husemann 
<li>description is: The ladder reached the limit of 1000 ?A, so we bumped it up to 1500 ?A. The data from the ladder seems to be fine. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W9&layer=L4">report</a></ul>
<!-- Author: Problem DB -->






<!-- Date: Wed Feb 14 22:00:48 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10762&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10762  width='300' align='top'></a></td><td>Just like last Tuesday, chip 8a in e114 dropped out, causing a pinkie. Instructed the shift crew to ignore the channel for now. Maybe we can learn something in quiet time. </td></tr></table>
<!-- Author: Ulrich -->

<!-- Date: Wed Feb 14 22:06:42 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W1L4 
<li>problem n: 1921 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: Diagnosis_update
<li>entered by: husemann 
<li>description is: The chip was fine for a week, but today it dropped out again. Let's see if it comes back again. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W1&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Feb 15 12:34:07 2007 -->
 <h3>ISL Cooling trip I: the recovery</h3> 
<p> 
The ISL cooling was tripped this morning just before 8:00 while adjusting the gradully closing e-valve. To efforts to recover the ISL cooling (with a couple of hall racks trips involved) will be desribed in another entry.<br> 
</p> 
<p> 
During the recovery PS #15 would not respond although we hockerized it 4 times. We had to recycle svxinter (reboot was tried before also). Also the RTserver had to be restarted. The RTserver expert said that the reason was a large data transfer from b0svx02 (IMON). 
</p> 
<p> 
Finally we recovered the detector to standby, and we put switch it on and took data as soon as we could in orther to see that everything was in one piece. SVXmon plots looked OK. However, we had several bias pinkies in SVX because of the coolant temperature was still falling.   
</p> 
<pre> 
Thu Feb 15 11:14:40 CST 2007                        TRIP: SVX  B3  W0 External Trip 
Thu Feb 15 11:14:40 CST 2007                        TRIP: SVX  B3  W0 External Trip 
Thu Feb 15 11:14:40 CST 2007                        TRIP: SVX  B3  W0 External Trip 
Thu Feb 15 11:14:40 CST 2007                        TRIP: SVX  B3  W0 External Trip 
Thu Feb 15 11:14:40 CST 2007                        TRIP: SVX  B3  W0 External Trip 
Thu Feb 15 11:19:34 CST 2007                        success: Resetting trips 
</pre> 
<p> 
SB3W0 tripped on external trip (and nothing else) as the RC was issuing an END Run. As we were out of the run configuration (because no-silicon trigger test) we went to standby and  recovered the wedge. It tripped again (same reason), so we hockerized PS #10, and it did hold.</p> 
  
<!-- Author: Ulrich/Jose/Ignacio -->
<!-- Comment: Thu Feb 15 13;11;57 comment by...Ulrich/Jose/Ignacio/Jen -->
Ups, SB3W0 tripped again at 13:00, without any messages on the PSGui. Full status revealed that the trip have been on 5 V DOIM.
We sent it to stnadby and holds. After asking Jen   we are thinking on swaping the PS assonas we can.
<!-- Date: Thu Feb 15 12:36:23 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10763&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10763  width='300' align='top'></a></td><td>This maps the ladders that went above the bias limit when the detector was a bit warm. </td></tr></table>
<!-- Author: Ulrich/Jose/Ignacio -->



<!-- Date: Thu Feb 15 17:20:58 2007 -->
<h3> Store 5229 has one extra SVT hole.</h3> 
Since the DOIM kept tripping the wedge SB3W0 we decided to take it out of the hwdb datebase even though it meant a fourth SVT hole. The plan is to swap the PS as soon as an access is granted (Jen has one ready spare), probably at the end of this store.</p> 
<p>  We excluded the 5 ladders with traceSilicon. However we were confused by IFIX  still giving a PS # 10 switched off ALARM (PS 10 correspond to SB3W0). Ulrich patched the IFIX code so this ALARM disappeared. We were suspecting we had to do something about the PC in the hwdb, so we asked emeritus SPLs (thanks Ankush and David) to make ourselves sure. We further convinced ourselves that there would not be an inhibit by sending a global standby from IFIX: the Portcard did not change state.  
Now we are taking data smoothly: backgrounds were fine. SVXMOn  
only feature is the missing wedge. 
<p>
<!-- Author: Ulrich/Jose/ignacio -->
<!-- Comment: Thu Feb 15 18;31;24 comment by...Ulrich -->
As it turns out, I had the two other SVX wedges that are completely out hard-coded in <tt>PSMon.exe</tt>. Now I treat e30x on the same footing (hopefully only temporarily), which suppresses the "PS_SMTH_OFF" alarm in iFix.
<!-- Date: Thu Feb 15 17:23:16 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10764&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10764  width='300' align='top'></a></td><td>Note the hole.</td></tr></table>
<!-- Author: Ignacio -->

<!-- Date: Thu Feb 15 17:29:11 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W0All 
<li>problem n: 1930 
<li>Status: needs_work
<li>Type: Wedgewide_other
<li>Action: Removed_hdwdb
<li>entered by: ignacio 
<li>description is: After all the action this morning with ISL cooling trips and the collision hall racks being switched off this morning twice(see <a href='http://www-cdfonline.fnal.gov/cgi/internal/elog/det-system-elog.pl?nb=silicon&action=copyentry&page=340&time=12:34:07'> elog</a>), the 5V DOIM tripped in undercurrent after 5-30 minutes, taking the whole wedge with it. So we exclude it from the hardware  DB until we can swap the PS. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W0&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Feb 15 17:37:28 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10765&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10765  width='300' align='top'></a></td><td>This Micron is flipping between two states.</td></tr></table>
<!-- Author: Ignacio -->


<!-- Date: Thu Feb 15 18:00:52 2007 -->
<h3> Blinking IMON </h3> 
When the cooling seemed to be stable and the problem with the wedge SB3W0 was still being investigated we had a new experience. IMON started to change state every update, going from all blue (but one green wedge) to all green (of course with some yellows). This situation came with the Silicon Inhibits page appearing and disappearing with the same rhythm.  
<p>Our first thought went to the RTServer. Bill said that RTServer was fine and that maybe a reboot of the applications would help. Thus everything was rebooted (IMON, PSGUI and svxinter), nothing changed.  
<p>Then, Ulrich remembered that Dean was working in the PS test-stand. When we went there we saw an open PSGUI with the exact configuration that was flashing on IMON. The problem was solved by closing the instance of PSGUI in the test-stand.
<!-- Author: Ulrich/Ignacio/Jose -->


<!-- Date: Thu Feb 15 18:47:40 2007 -->
Entered in Incident database: <ul>
<li>Submitted by: ignacio
<li>Description of Problem: The recovery from the cooling trip involved several <a href='http://www-cdfonline.fnal.gov/cgi/internal/elog/det-system-elog.pl?nb=silicon&action=copyentry&page=340&time=12:34:07' >problems</a>.
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/idb/DBentry.pl?incident_number=139">Incident Report</a></ul>
<!-- Author: Incident DB -->



<!-- Date: Thu Feb 15 18:55:33 2007 -->
<h3>ISL Cooling Trip II: Cooling System Issues</h3> 
 
The whole problem started with the decreasing flow rate in the supply line of ISL CCE1. The flow had dropped to around 1.7 lpm, so we tried to open the valve a little to compensate. Everything was fine until 1.9 lpm and 12.5 psi (at 53% valve opening). At 54% all of East ISL and L00 tripped. As a consequence, the entire Silicon tripped on an ISL temperature übertrip. 
<p> 
We had a very hard time bringing the flow back on for East ISL. In the end, it took us 3 hours! The system was more touchy than ever. We tried to equalize pressures as well as we could, but still the system kept tripping. with the slightest inequality. Here is a (probably incomplete) list of what we tried: 
<ul> 
<li>Bringing up CCE1 first to avoid glitches: The hope was that if the valve is stuck and moves in jumps we could do that before it caused pressure inequalities somewhere else. This strategy had limited success, as everything was tripping at a flow of below 1.0.</li> 
<li>Opening the manual bypass: The idea was to bring down the input pressure to the entire ISL to mitigate the high-pressure trips. We are not sure if this worked, as the automatic chiller bypass regulates away some of the effect. In the end we brought the system ouf of the range for the PID loop. It could be that this helped to reduce pressure fluctuations in the system. After everything was up again, we closed the manual bypass again, such that the supply pressure is around 27 psi.</li> 
<li>What helped in the end was to increase all the valves extremely slowly, mostly in 1% steps, starting from around 40%. We stopped when everybody had enough flow to clear the interlock.</li> 
</ul> 
<p> 
During the recovery we triggered two rack trips. As usual, the QuadLog did not tell us what went wrong. We do need a "First Fault" mechanism for the Silicon trips. In an attempt to understand the correlations between the pressures we brought up the QuadLog page with the ISL pressure logic and an FTTrend plotter for the PLC. So far we didn't learn too much from either, but they may come in handy next time. 
<p> 
We have also changed the iFix warning and alarm limits for the supply pressure in ISL CCE1 from (1.7,1.5) lpm to (1.5,1.4) lpm. The PLC trip limit had been reduced last week from 1.5 to 1.3 lpm. 
<p> 
The statistics for these kinds of incidents are as follows: out of 8-10 attempts to adjust the flow "on the fly", we tripped on 2. We will certainly not touch the system during stores any more, but given the difficulties of today, we may have a hard time recovering from a trip between stores in time. 
<p> 
The spare valves are supposed to be delivered on February 27. Let's hope we can swap the bad valve out and be done with the case! The representative of the valve manufacturer thinks it is wear and tear, so we may have the problem in all valves soon. But we should also examine the valve that is swapped out. Maybe we find some sort of contamination.  
<!-- Author: Jose, Ignacio, Ulrich -->




<!-- Date: Thu Feb 15 18:57:01 2007 -->
Entered in Incident database: <ul>
<li>Submitted by: ignacio
<li>Description of Problem: We tripped ISL cooling while adjusting the closing ISL valve.Here is a detailed <a href='http://www-cdfonline.fnal.gov/cgi/internal/elog/det-system-elog.pl?nb=silicon&action=copyentry&page=340&time=18:55:33' > description</a>.
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/idb/DBentry.pl?incident_number=141">Incident Report</a></ul>
<!-- Author: Incident DB -->


<!-- Date: Fri Feb 16 00:27:49 2007 -->
Entered in Incident database: <ul>
<li>Submitted by: husemann
<li>Description of Problem: Spontaneous switch-off of crate #4. Recovered in 3 minutes without my intervention.
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/idb/DBentry.pl?incident_number=142">Incident Report</a></ul>
<!-- Author: Incident DB -->


<!-- Date: Fri Feb 16 00:35:47 2007 -->
Entered in Incident database: <ul>
<li>Submitted by: husemann
<li>Description of Problem: Got trigger inhibit due to zero bias voltage on ISL B5W3L4. Shift crew got confused by pinkie on voltage rather than current (the current was constant) but figured out the zero bias from the PS GUI (former Silicon PS experts...). I called in at the time they were going to page me anyway and advised them to Hockerize CAEN crate #11, which fixed the corrupted readback from that channel. When they powered up the ladders in that crate (with the new PS GUI function), ISL B4W2L0 tripped on DVDD overcurrent. I called in again and reminded them that they had to go to HALT first. After that, they recovered fine. The downtime is a little longer that it had to be because of a simultaneous corrupted heap in a PCAL crate.
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/idb/DBentry.pl?incident_number=143">Incident Report</a></ul>
<!-- Author: Incident DB -->



<!-- Date: Fri Feb 16 01:12:11 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10766&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10767  width='300' align='top'></a></td><td>Less than 10uA current jump</td></tr></table>
<!-- Author: herndon -->


<!-- Date: Fri Feb 16 02:22:45 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10768&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10769  width='300' align='top'></a></td><td>Less than 10um jump in B1W0L0 Bias1] 
Set to ignore</td></tr></table>
<!-- Author: herndon -->


<!-- Date: Fri Feb 16 02:30:58 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10770&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10771  width='300' align='top'></a></td><td>Yet another small current jump.  B4W1L2 Vbias</td></tr></table>
<!-- Author: herndon -->


<!-- Date: Fri Feb 16 03:13:43 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10772&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10773  width='300' align='top'></a></td><td>Yet another small current jump 
The silicon group should think about not setting the the 
limits so close to the oporating values</td></tr></table>
<!-- Author: herndon -->


<!-- Date: Fri Feb 16 08:31:26 2007 -->
<h3>Store Lost — Access NOW</h3> 
The Tevatron had problems with a quadrupole magnet last night, so the Silicon went to STANDBY for about 10 minutes twice, around 2:00 and around 4:00. The store quenched around 5:30, shortly after they notified us of problems. The silicon was just going to STANDBY. The abort was 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2007&action=view&page=139&frame=2&anchor=05:39:28.727'> 
clean</a> for the Silicon. Here are more details from the AD RC log: 
<pre> 
 An LCW leak developed in the correction element chassis shortly before 2am.  This would turn out to be the demise of the store. 
 
    * The first indication of a problem was that the corrector SQA0 tripped off around 01:46, taking a bit out of luminosity.   The supply was reset and knobbed back up. 
    * SQA0 tripped a second time at 03:54, taking another bit out of luminosity.   The supply was reset and turned on again. 
    * T:VA12 then tripped on ground fault.   Experts and ops were able three bump out VA12 without loss of luminosity. 
    * Local investigation showed an LCW leak on the T:HA13.  The regulator was spraying LCW on the other chassis. 
    * While trying to three bump away HA13, we quenched the Tevatron at around 05:30. 
 
# Experts will need to access the correction element/LCW leak situation. 
# Quench was at F48U and F48L.  The frig has recovered. 
</pre>  
<!-- Author: Roberto & Ulrich -->
<!-- Comment: Fri Feb 16 08;36;06 comment by...Roberto & Ulrich -->
Got paged around 6:20 for the access and called in Jen and Satyajit. They arrived around 8:00 and are now in the collision hall to swap the supply. Before that we verified that the wedge still trips on 5V DOIM undervoltage.


<!-- Date: Fri Feb 16 09:19:44 2007 -->
With all the cooling shenanigans I completely forgot to re-launch the logic analyzer software on ndf205 after Rich Krull applied the latest security patches. Up and running again. Just as a side remark: we have way fewer resonances than before, the last one on February 9. Are we sure that the trigger still works?
<!-- Author: Ulrich -->


<!-- Date: Fri Feb 16 09:54:04 2007 -->
<h3>Power supply access for SB3W0</h3> 
We used the access to swap the supply for SB3W0, which started tripping on 5V DOIM undervoltage yesterday.  The supply we swapped in used to be in for SB4W6, but we pulled it about 6 months ago due to a droopy 5V DOIM voltage.  The 5V DOIM voltage has been constant on the teststand for the last 6 months, so given that we have no other spare SVX right now, we decided to swap it in.  At the worst, the 5V DOIM will start drooping again and we'll have to replace it in a few months - at least we won't have an SVT hole anymore.<br> 
The swap was quick and without problems.  The DOIMs have been powered and holding for ~30 minutes with no trips so far.  The rest of the wedge is also powered up and looks good.  Time will tell if the problem is really solved, but so far so good.<br>
<!-- Author: Jen, Satyajit, Ulrich, Jose, Roberto -->
<!-- Comment: Fri Feb 16 10;49;16 comment by...Ulrich -->
The DOIMs for e30x are still holding. I have rolled back to the default version of <tt>PSMon.exe</tt> (i.e. not ignoring channels that are off in e30x) and re-enabled the AutoHocker.
<!-- Comment: Fri Feb 16 12;27;34 comment by...Jen -->
P.S.  Credit for this access also goes to Ignacio in the control room, and Roberto Davila down in the collision hall for showing us how to make the lift work even though the battery was mostly dead!
<!-- Date: Fri Feb 16 09:56:21 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W0All 
<li>problem n: 1930 
<li>Status: needs_observation
<li>Type: Wedgewide_other
<li>Action: PS_work
<li>entered by: jpursley 
<li>description is: Swapped in a new supply, and so far no DOIM trips have been seen (note: this was actually 5V DOIM undervoltage, not undercurrent, tripping).  The new supply might have a problem with 5V DOIM drooping, so we should watch the 5V DOIM voltage over time.  See <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=340&frame=2&anchor=09:54:04'>elog</a>.    
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W0&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Feb 16 10:26:58 2007 -->
During the access, Roberto Davila had a look at the power supply for the SE Top Silicon rack in the collision hall. The PS was masked in the PSM system because of spurious alarms. They didn't find any problems with the crate and have unmasked the PS. Let's see if the PSM alarms come back.
<!-- Author: Ulrich -->


<!-- Date: Fri Feb 16 10:40:57 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10774&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10774  width='300' align='top'></a></td><td>We have bumped up the e-valve for CCE1 from 51% to 54% (in three 1% steps) to compensate for the loss in flow on that line. While doing that we watched the FTTrend plot of the ISL East COT face pressures closely. The plot displays the readings (units: psia) directly from the PLC, at an update rate of 0.1 seconds. It shows some interesting features: 
<ul> 
<li>There is a common-mode fluctuation seen in all lines, including the portcard line.</li> 
<li>The reaction to the change in valve settings for CCE1 (black line) is quite different for the three changes. The first one shows a downward fluctuation, the second one an upward fluctuation, and the third one just a step up.</li> 
</ul></td></tr></table>
<!-- Author: Ulrich -->



<!-- Date: Fri Feb 16 14:54:24 2007 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 459
Calibration type  : standard
Run period tag    : Feb_2007
DPS-off run       : 233845
DPS-on run        : 233844
Requested by      : Timo Aaltonen
Main process id   : 29018
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->


<!-- Date: Fri Feb 16 15:06:51 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W0L0 
<li>problem n: 1931 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: Adjusting Bias1 current limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>62.5795</td><td>100.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>100.0</td><td>125.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Feb 16 15:08:17 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W1L4 
<li>problem n: 1598 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: Bumping up Bias1 limit as well<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>125.0</td><td>145.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>145.0</td><td>180.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W1&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Feb 16 15:10:59 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W1L2 
<li>problem n: 1767 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: Bias0 current limit needs another adjustment<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>55.4467</td><td>120.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>120.0</td><td>160.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Feb 16 15:14:22 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W1L4 
<li>problem n: 1769 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: Also Bias0 current limit needs to be bumped up.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>94.982</td><td>115.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>150.0</td><td>150.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W1&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Feb 16 15:18:40 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W3L1 
<li>problem n: 1857 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: Also Bias0 needs an adjustment.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>55.5049</td><td>100.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>100.0</td><td>125.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W3&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Feb 16 15:31:41 2007 -->
Entered in Incident database: <ul>
<li>Submitted by: husemann
<li>Description of Problem: Bumped up bias current limits for a couple of ladders which all show the expected increase with luminosity: f100 (Bias1), f314 (Bias1), f412 (Bias0), f414 (Bias0), f531 (Bias0).
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/idb/DBentry.pl?incident_number=144">Incident Report</a></ul>
<!-- Author: Incident DB -->



<!-- Date: Fri Feb 16 16:16:40 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10777&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10778  width='300' align='top'></a></td><td><h3>Store 5231</h3> 
Store 5231 came in with an initial luminosity of 245e30. The losses were all fine (<1 kHz) and Silicon went in from the beginning. SVTSpyMon and SVXMon are fine, and the SVT hole is gone.</td></tr></table>
<!-- Author: Ulrich -->
<!-- Comment: Fri Feb 16 17;20;53 comment by...Ignacio -->
Come on Ulrich, I think you could  use larger letters.
<h3> We have one SVT hole less!</h3> The fact that we made it ourselves yesterday should not spoil the celebration (and since it's  friday...)  
<!-- Date: Fri Feb 16 17:14:28 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W0L1 
<li>problem n: 1389 
<li>Status: fixed
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: ballarin 
<li>description is: shifting limits because of a PS swap<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>113.775</td><td>60.0</td></tr>
<tr><td><b>Lower</b></td><td>90.0</td><td>40.0</td></tr>
<tr><td><b>Upper</b></td><td>140.0</td><td>80.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Feb 16 17:17:45 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W0L3 
<li>problem n: 1932 
<li>Status: fixed
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: ballarin 
<li>description is: shifting limits because of a PS swap<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>146.833</td><td>70.0</td></tr>
<tr><td><b>Lower</b></td><td>115.0</td><td>50.0</td></tr>
<tr><td><b>Upper</b></td><td>180.0</td><td>95.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Feb 16 17:59:48 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W0L1 
<li>problem n: 1741 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: Bumping up Bias1 current limit a little more.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>101.0</td><td>130.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>130.0</td><td>170.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Feb 16 21:08:12 2007 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 459 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 233845
DPS-on run       : 233844
Requested by     : Timo Aaltonen
Submitted        : 2007-02-16 14:54:02
Completed        : 2007-02-16 21:07:59
Status           : FAILURE

Last processing stage reported : updating ped tables with fibkill channels
Failure diagnostics :
child process exited abnormally
</pre>
<!-- Author: D-mode script  -->



<!-- Date: Sat Feb 17 02:19:04 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10779&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10780  width='300' align='top'></a></td><td>1st pinky.  B5W2L3 bias, less than 10uA current jump</td></tr></table>
<!-- Author: herndon -->

<!-- Date: Sat Feb 17 10:47:48 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W3L0 
<li>problem n: 631 
<li>Status: needs_observation
<li>Type: RX
<li>Action: Monitoring
<li>entered by: husemann 
<li>description is: Bit 1 low appears again in runs 234290, 234302, 234313, 234314, 234339, 234389. Seems to have vanished after that. All of these runs were rather short, below 1.5 hours. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B1W3&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Feb 17 10:57:52 2007 -->
Entered in Incident database: <ul>
<li>Submitted by: husemann
<li>Description of Problem: Resonance detected around 10:47. When I re-armed the logic analyzer, I got an immediate second trigger. The reason was that the shift crew was confused (or worried) as to what to do and was waiting in HALT for about 3 minutes, no clearing the  SRCERR flag. We had very few resonances in the last days, so the new Aces haven't seen so many.
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/idb/DBentry.pl?incident_number=145">Incident Report</a></ul>
<!-- Author: Incident DB -->



<!-- Date: Sat Feb 17 11:55:24 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10781&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10781  width='300' align='top'></a></td><td>e033 shows erratic bias currents. It has a history of doing this. The strip plots and ADCMon look fine. I will check the trip limit later today.</td></tr></table>
<!-- Author: Ulrich -->
<!-- Comment: Sat Feb 17 17;03;56 comment by...Ulrich -->
The bias current is far away from the trip limit of 5000 &mu;A. I have biased the ladder in quiet time, and it draws around 350 &mu;A. The IMON limit is at 450 &mu;A.
<!-- Date: Sat Feb 17 12:00:39 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W2L1 
<li>problem n: 784 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: husemann 
<li>description is: The bit 0 high error is back, at a rate of 5-30%. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Feb 17 12:05:10 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W8L4 
<li>problem n: 1801 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: husemann 
<li>description is: This ladder goes in and out of 100% pipeline out of sync errors. This seems to be related to the z side somethings coming and going (which is usually fixed by the next HRR). 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W8&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Feb 17 12:08:31 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W2L4 
<li>problem n: 1423 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: husemann 
<li>description is: And the error is back, at the 30% level. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W2&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Feb 17 14:31:28 2007 -->
At about 12:40 Tev quenched.  MCR sez: 
<pre> 
2:41:09-   TeV quench. - DJC 
-- Sat Feb 17 12:42:01 comment by...DJC --  B1 and all B0 low betas show a quench. 
-- Sat Feb 17 12:58:41 comment by...DJC --  B2 PS shows a dump failure. 
-- Sat Feb 17 13:12:55 comment by...DJC --   
BBD2 shows an odd trend several line cycles prior to the quench. 
-- Sat Feb 17 13:17:01 comment by...DJC --  T67 FIFO shows B0 QPM pulled the abort first. 
</pre> 
Quench was clean for silicon, see <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2007&action=view&page=143&frame=2&anchor=12:57:14.542'>radiation plot</a> in main elog.<br>
<!-- Author: Jen (who always happens to be around when things go wrong) & Ulrich -->


<!-- Date: Sat Feb 17 14:35:42 2007 -->
<h3>Flow Adjustments</h3> 
Very nervously, I have adjusted the flows on ISL CCE. As a precaution, I switched off ISL and L00 and silenced the cooling sono-alarms. Then I brought up the FTTrend plotter of the pressures and tried to adjust flows only on the trailing edge of the pressure variation. That worked out fine, and now we are at 1.9 lpm again. Also PCE was on the low side, so I bumped it up as well. The current settings are: 
<ul> 
<li>CCE1: 58%</li> 
<li>CCE2: 65%</li> 
<li>CCE3: 75%</li> 
<li>CCE4: 75%</li> 
<li>PCE: 82%</li> 
</ul>
<!-- Author: Ulrich -->

<!-- Date: Sat Feb 17 16:51:42 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W0L3 
<li>problem n: 1739 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: The Bias0 current needs another adjustment as well.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>101.0</td><td>120.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>120.0</td><td>160.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Feb 17 17:02:53 2007 -->
<h3>Tevatron Quench and Quiet Time</h3> 
There is a lot of quiet time after the Tevatron quenched earlier today (around 12:40). Although the quench happened close to B0, it was <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2007&action=view&page=143&frame=2&anchor=12:57:14.542'> 
clean for the Silicon</a>. Here is Brian Drendel's account of the quench: 
<pre> 
Store 5231 ended at 12:40 with a quench at B1 and the B0 low βs.  It appears that C:B0Q6  (house BD) was first to go.   The QPM shows that the BD current going down 5 line cycles before t0, but power supply experts think the QPM sent a command to the supply to turn it off.    In short, it is not clear if this is a power supply, QPM or controls problem yet.  The Tevatron on-call and Tevatron machine coordinator are in on what is going on and power supply experts are investigating the B0Q6.  The crew chief is contacting low-β QPM controls experts for further assistance.   Once this problem is resolved, we will follow the Tevatron Machine Coordinator's instructions for returning the Tevatron to operations and then follow our earlier shot setup guidelines when the Tevatron is ready to put another store in. 
</pre> 
There is no estimate yet for the next shot. In the moment one of the event builder PCs is broken, with no estimate as to how and when it can be fixed. 
 
<p>I have used the time to adjust the flows in East ISL (see above) and for some quiet time studies. I looked at these ladders: 
<ul> 
<li><b>e021</b>: showed a small but increasing rate of bit errors (bit 0 high, C2 termination). This effect could be reproduced in SVXDAQ, albeit at a very low level (0.3% in NN mode, no errors in 10k events in RA mode).</li> 
<li><b>e224</b>: This ladder shows a lot of bit errors in SVXDAQ,  37% C2 termination, 70% OO sequence, and 10% illegal channel. Not sure what to do with it.</li> 
<li><b>e184</b>: CAP ID errors in almost all events. 
</ul> 
I have also biased L00, just to make sure that we see bias currents after the quench.
<!-- Author: Ulrich -->
<!-- Comment: Sun Feb 18 20;21;57 comment by...Roberto and Oscar -->
In ADCMon plots for run 234389 taken before the quench, e224 was not retrieving data due to a lot of errors. This ladder seems to have a long history of becoming a 100%-error from time to time and recovering by itself (?).
<!-- Date: Sat Feb 17 17:05:54 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W2L1 
<li>problem n: 784 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: husemann 
<li>description is: C2 termination error confirmed in SVXDAQ, at a very small rate (0.3% in NN, unmeasurable in RA). 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Feb 17 17:08:18 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W2L4 
<li>problem n: 1423 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: husemann 
<li>description is: Looked at the ladder in quiet time. In SVXDAQ it shows A LOT of errors: c2c2, OO sequence, and illegal channel. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W2&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sun Feb 18 03:43:58 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10782&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10783  width='300' align='top'></a></td><td><h3>Store 5234</h3> 
Store 5234 came in with an initial luminosity of 283e30, new record! The losses were below 1 kHz, so Silicon went in from the beginning. The Ace had to reboot b0fib00, which would not go through PARTITION. The initial deadtime was around 35% (at 17 kHz L1A rate and 700 Hz L2A rate). SVXMon and SVTSpyMon look good. </td></tr></table>
<!-- Author: Ulrich -->
<!-- Comment: Sun Feb 18 03;50;28 comment by...Ulrich -->
As we were waiting for this store for quite a while, my adjustment of the ISL CCE1 flow is already 12 hours old. During this time the flow dropped from 1.9 to 1.75 lpm. We may have to adjust it during the store if it drops that fast.

<!-- Date: Sun Feb 18 03:52:11 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W2L3 
<li>problem n: 1805 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: Bumping up Bias0 current limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>78.9841</td><td>115.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>115.0</td><td>150.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sun Feb 18 12:09:16 2007 -->
Another resonance condition around 11:15, logic analyzer re-armed.
<!-- Author: Ulrich -->


<!-- Date: Sun Feb 18 12:12:53 2007 -->
Shift crew called because of several AVDD pinkies in e372. I advised live with it and HRR it away, unless it happens every hour or so. In that case I would try and power-cycle the wedge. Also e184 had one pinkie this morning.
<!-- Author: Ulrich -->
<!-- Comment: Mon Feb 19 09;34;45 comment by...Ignacio -->
I have just power cycle these two wedges.
<!-- Date: Sun Feb 18 22:41:16 2007 -->
Entered in Incident database: <ul>
<li>Submitted by: husemann
<li>Description of Problem: Spontaneous switch-off of CAEN crate #7. The Ace recovered quickly, but two ladders in f00x tripped on DVDD overcurrent during the turn-on. Also this was recovered swiftly without my intervention. Somehow in the course of this, the ISL conductivity alarm got unignored, and the shift crew paged me, just to make sure.
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/idb/DBentry.pl?incident_number=146">Incident Report</a></ul>
<!-- Author: Incident DB -->



<!-- Date: Mon Feb 19 07:53:39 2007 -->
<h3>Another flow adjustment</h3> 
We are in end-of-store now for Tevatron studies, so I took the opportunity to adjust the ISL CCE1 flow. The e-valve is now at 65% (from 59%), and the flow is back to 2.0 lpm (at 12.7 psi pressure). It is interesting to note that the flow does not seem to drop linearly. The last adjustment was Saturday, aroudn 14:00. Until Sunday 16:00 it was down from 1.95 lpm to 1.65 lpm, and now, 16 hours later, it was at 1.58 or so. Again I followed the procedure of switching off ISL and L00 before touching the cooling. I have also applied Keynsian (i.e. anti-cyclic) valve adjustments.
<!-- Author: Ulrich -->


<!-- Date: Mon Feb 19 09:28:20 2007 -->
<pre>ADCmon checkout during the week. Runs: from 233864 to 234389. 
 
No problems found except for ladder SB2W2L4 (e224) for run 234389, which did not give any data due to large error rate. This ladder worked fine for the other runs and its history shows that for time to time behaves strangely, having a lot of errors. 
</pre>
<!-- Author: Roberto -->



<!-- Date: Mon Feb 19 09:38:45 2007 -->
<h3>Summary of the Week</h3> 
 
<b>Monday, February 12, 2007</b> 
<ul> 
  <li>Opened up valve for ISL CCE1 from 62% to 65%</li> 
  <li>Preparing for access to swap e-valve controller for ISL CCE1</li> 
</ul> 
 
<b>Tuesday, February 13, 2007</b> 
<ul> 
  <li><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=340&frame=2&anchor=10:01:24'>Access</a> to swap out power supply for SVX B3W6 (had started to trip on DVDD4 overvoltage on Sunday).</li> 
  <li>In parallel: <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=340&frame=2&anchor=11:57:53'>Access</a> to swap the controller unit for the e-valve in ISL CCE1. The potentiometer had to be adjusted to get flow to the valve, and the flow <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=340&frame=2&anchor=08:28:54'>continued to drop</a> - it must be the solenoid valve itself.</li> 
  <li>D0 made a 2-hour access 7 hours long...</li> 
  <li><a href= 
  'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=340&frame=2&anchor=18:26:04'>Store 5226</a>: initial luminosity 280e30 - new record.</li> 
  <li><a href= 
  'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=340&frame=2&anchor=19:35:18'>Trip</a> of almost all Layer 0/1 ladders in b0fib06, probably related to single-event upset.</li> 
  <li>Spurious pages on the Cooling pager. Luckily, I had some redundancy on my belt...</li> 
  <li>SciCo had problems closing warning windows, because pop-up window with path to snapshot was not closed</li> 
</ul> 
 
<b>Wednesday, February 14, 2007</b> 
<ul> 
  <li><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=340&frame=2&anchor=19:35:18'>IMON crashed</a>. After re-start all currently ignored alarms were unignored. Added hand-written list of these channels to terminal.</li> 
  <li>Store was aborted due to problem with A1 wet engine, clean for the Silicon.</li> 
  <li>Rebooted SVXIICON.</li> 
  <li><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=340&frame=2&anchor=11:10:49'>Test with development database</a> for ISL threshold study: unsuccessful for now></li> 
  <li><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=340&frame=2&anchor=14:53:08'>Store 5228</a>: initial luminosity 228e30, C:LOSTP went up to 12 kHz (collimator in wrong position)</li> 
<li>Frequent AVDD pinkies in e184</li> 
<li>e292<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=340&frame=2&anchor=20:07:39'>bias current gone wild</a>, increased trip limit from 1000 &mu;A to 1500 &mu;A. Noticed that the link to <tt>CAENcurrent.dat</tt> was missing for the PS GUI.</li> 
<li>e114: chip 8a temporarily <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=340&frame=2&anchor=22:00:48'>stops returning data</a>, causing a pinkie</li> 
</ul> 
 
<b>Thursday, February 15, 2007</b> 
<ul> 
  <li>Another attempt to increase flow to CCE1 ends in <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=340&frame=2&anchor=12:34:07'>massive cooling trip</a> (cooling summary <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=340&frame=2&anchor=18:00:52'>here</a>). It took 3 hours to bring the Silicon back up (including 2 rack trips).</li> 
  <li>One power supply got damaged during the cooling trip. It started tripping on 5V DOIM undervoltage, so we took the entire wedge (e30x) out, creating an SVT hole.</li> 
 
  <li>Tests of changes to PS GUI on the test stand caused <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=340&frame=2&anchor=18:00:52'>blinking IMON</a> (received SmartSockets messages from two sources).</li> 
  <li><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=340&frame=2&anchor=17:23:16'>Store 5228</a>: initial luminosity 247e30, new SVT hole, everything else fine.</li> 
  <li>Spontaneous switch-off of CAEN crate #4.</li> 
  <li>Corrupted readback for CAEN crate #11: f534 was reading back zero voltage, causing a trigger inhibit.</li> 
</ul> 
 
<b>Friday, February 16, 2007</b> 
<ul> 
  <li>Tevatron quenched around 5:30, access opportunity to swap power supply for e30x.</li> 
  <li><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=340&frame=2&anchor=18:00:52'>Access</a>: power supply swapped - 5V DOIM problem fixed.</li> 
<li>Access was also used to investigate spurious PSM alarms in SVX SE Top crate. Roberto reseated monitoring cards, but problem is still there.</li> 
  <li><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=340&frame=2&anchor=10:40:57'>Opened up e-valve</a> from 51% to 54%. Learned about pressure oscillation.</li> 
  <li>Bumped up a bunch of bias current limits.</li> 
  <li><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=340&frame=2&anchor=16:16:40'>Store 5231</a>: initial luminosity 245e30, SVT hole gone.</li> 
<li>Still problems with DMode calibration</li> 
</ul> 
 
<b>Saturday, February 17, 2007</b> 
<ul> 
  <li>e033: erratic bias currents, but way below trip limit of 5000 &mu;A.</li> 
  <li><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=340&frame=2&anchor=14:31:28'>Tevatron quench</a> on B0 low betas.</li> 
  <li>Another <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=340&frame=2&anchor=14:35:42'>flow adjustment</a>: CCE1 to 58%.</li> 
  <li><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=340&frame=2&anchor=17:02:53'>Quiet time studies</a></li> 
</ul> 
 
<b>Sunday, February 18, 2007</b> 
<ul> 
  <li><a href= 
  'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=340&frame=2&anchor=03:43:58'>Store 5234</a>: initial luminosity 283e30 - new record.</li> 
  <li>Rather frequent AVDD pinkies on e372 and e184.</li> 
  <li>Spontaneous switch-off of CAEN crate #7. ISL conductivity alarm gets unsilenced somehow.</li> 
</ul> 
 
<b>Monday, February 19, 2007</b> 
<ul> 
  <li>Another <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=340&frame=2&anchor=07:53:39'>flow adjustment</a></li> 
  <li>Power-cycled e184 and e372 in the hope to fix AVDD pinkies.</li> 
</ul> 
... and we are out.
<!-- Author: Ulrich -->