<!-- Title: 11:18:02  Mon Jul 18 2005 -->
<!-- Crewchief: Marcel (MPC) -->
<!-- Op1: Sebastian (SPL) -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
it' s time to play the music, it' time to light the lights, it's time to get things started on the Muppet Show tonight


<!-- Date: Mon Jul 18 11:18:21 2005 -->
restarted the gUI as a precaution
<!-- Author: Grumpy -->


<!-- Date: Mon Jul 18 13:13:57 2005 -->
<h4> Problems with b0sili02 </h4> 
B0sili02 developped a problem with the X and needed a reboot. 
While doing that, I also found a problem with /dev/hda, which needs to be replaced. I've already backup everything on /data01 and /home 
<!-- Author: Marcel -->


<!-- Date: Mon Jul 18 15:38:40 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7043&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7044  width='300' align='top'></a></td><td>SVT SPYMON 4280 , everything looks good</td></tr></table>
<!-- Author: Marcel -->


<!-- Date: Mon Jul 18 15:41:42 2005 -->
We hade some problems with the losses at the beginning, Silicon was in STANDBY, MCR had to retune things. Now losses are stable
<!-- Author: Marcel -->


<!-- Date: Tue Jul 19 07:57:08 2005 -->
store 4280 lost clean, Claim from MCR is Anode trip.  
<!-- Author: Marcel -->
<!-- Comment: Tue Jul 19 07;57;59 comment by...Marcel -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2005&action=view&page=-12335&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2005&action=view&page=-12335 width='300' align='top'></a></td><td>BLM summary plot.</td></tr></table>




<!-- Date: Tue Jul 19 10:35:25 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W5L2 
<li>problem n: 1494 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Incident
<li>entered by: marcel 
<li>description is: Had a high error rate the last few runs, needs to be studied 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jul 19 10:36:06 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W5L2 
<li>problem n: 1494 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: marcel 
<li>description is: We ran this guy in quiet time and have seen no problem at all. Keep an eye on it, if the error reoccurs 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Jul 19 13:00:06 2005 -->
<h3>Silicon Access</h3> 
 
<p>There was an access this morning. Marcel and I went in and did a light level measurement on SB0W0L1 (e001).  This had been giving some bit errors.</p> 
 
<p>We first checked the ladder in SVXDAQ but this gave no errors in RA and NN mode.  But nevertheless, we still went in.</p> 
 
<p>The light from all the fibres were good; each one was ~700uW.  Only Bit 3 was low; it gave 328uW.  However this shouldn't cause any problems.</p> 
 
<p>This ladder is now behaving fine but we should just an eye on it.</p>
<!-- Author: Ankush and Marcel -->


<!-- Date: Tue Jul 19 13:04:46 2005 -->
<h3>Silicon Quiet Time Studies</h3> 
 
<p>After the access, Sasha and I did some quiet time studes.  We finally chopped SB1W2L2 (e122).  So the last chip to be read out is 86 and we set the ISEL bits for 85 to zero.</p> 
 
<p>Sasha and I had a look at some other ladders.  The details will follow in the problem DB e-log entries.</p> 
 
<p>As usual, I did a cold-start at the end to check I didn't break the detector :-)</p>
<!-- Author: Ankush & Sasha  -->

<!-- Date: Tue Jul 19 13:11:33 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W0L1 
<li>problem n: 1382 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Light_investigated
<li>entered by: amitra 
<li>description is: <p>During an access we did a light-level measurement. The light from all the fibres is good.  The ladder runs error-free in NN and RA mode.</p>  <p>Light-Level Measurement Results</p>  <table border=1> <tr><td>Bit 0</td><td>680 uW</td></tr> <tr><td>Bit 1</td><td>680 uW</td></tr> <tr><td>Bit 2</td><td>800 uW</td></tr> <tr><td>Bit 3</td><td>328 uW</td></tr> <tr><td>Bit 4</td><td>752 uW</td></tr> <tr><td>Bit 5</td><td>760 uW</td></tr> <tr><td>Bit 6</td><td>832 uW</td></tr> <tr><td>Bit 7</td><td>736 uW</td></tr> <tr><td>OBDV </td><td>792 uW</td></tr> </table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jul 19 13:20:56 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W2L2 
<li>problem n: 1479 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Change_last_chip
<li>entered by: amitra 
<li>description is: <p>This ladder has had lots of errors with the last chip. During quiet time, we systematically chopped a chip from the end until the errors reduced.</p>  <p>If the last chip is set to be x86 and chips 85->a0 have their ISEL bits set to zero, the ladder can be read out; albeit CAP-ID errors with chips 89 and 88.</p>  <p>So in the hardware database the last chip is now set to 86 and the ISEL bits for chip 85 are set to zero.</p>  <p>This should be checked in a week to see how the chip chop performs.</p>  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W2&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jul 19 13:22:04 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W2L3 
<li>problem n: 1462 
<li>Status: needs_work
<li>Type: DVDD
<li>Action: PS_work
<li>entered by: amitra 
<li>description is: <p>During quiet time, I put this ladder back in to see if it could be powered.  But no success; the ladder kept tripping on DVDD.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jul 19 13:26:12 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W2L4 
<li>problem n: 1243 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>During quiet time we ran this ladder. It can be read out error-free in Read-All mode.  But in Nearest-Neighbour, the read out is garbled for almost all chips.</p>  <p>Tried chopping the Z side but that had no effect.  The next thing to try is to sparse out the phi side.</p>  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W2&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jul 19 13:28:45 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W2L3 
<li>problem n: 436 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: amitra 
<li>description is: <p>I just ran this ladder with SVXDAQ in RA and NN mode.  No errors were found.  Also this ladder has been running error free for recent runs.  Check on this ladder in a week or so and see if it stays healthy.</p>  <p>If it is still error-free, then declare this thread fixed.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Jul 19 13:41:47 2005 -->
<h3>Strange error message from PS-GIU</h3> 
 
<p>During quiet time studies, SB0W4L4 (e044) tripped. After recovering the trip, PS-GUI reported this error:</p> 
 
<pre> 
TRIP: SVX  B0  W4 AVDD4 OverCurrent 
Tue Jul 19 12:28:40 CDT 2005     success: Resetting trips 
Tue Jul 19 12:28:59 CDT 2005     ERROR: Channel4 SVX B0 W4 Handshake - No response from FIB after power turned ON 
</pre> 
 
<p>The error from SVXINTER was:</p> 
 
<pre> 
Sending Request for e044 
Module is busy, sending code = 24 
Timeout 
ERROR: not all Fibs are initialized 
ERROR: chip initialization, ps_n = 4SetChannelStatus, err = -4 
</pre> 
 
<p>This ladder is connected to FIB02.  So I checked fib02 was ping-able and it was.  I was a bit confused, so I took the system through a cold-start and ran for 5,000 events. It ran error-free.</p> 
 
<p>I tried to reproduce the problem by turning SB0W4L4 off and back on.  PS-GIU ran fine and no errors were reported.....weird!!!</p> 
<!-- Author: Ankush  -->


<!-- Date: Tue Jul 19 18:56:41 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7045&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7045  width='300' align='top'></a></td><td>The DVDD current for SB5W5L0 (e560) has held steady since the  PS swap </td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Tue Jul 19 18:58:17 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7046&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7046  width='300' align='top'></a></td><td>The DVDD current for SB5W6L1 (e561) has held steady since the PS swap</td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Tue Jul 19 18:59:27 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7047&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7047  width='300' align='top'></a></td><td>The 5V DOIM current for wedge SB5W6 has held steady since the PS swap</td></tr></table>
<!-- Author: Ankush -->

<!-- Date: Tue Jul 19 19:02:45 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W6L0 
<li>problem n: 1481 
<li>Status: fixed
<li>Type: DVDD
<li>Action: Currents_investigated
<li>entered by: amitra 
<li>description is: <p>Since the PS swap the DVDD current has held steady.  The plot can be found <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=258&frame=2&anchor=18:56:41'> here</a>.</p>    
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W6&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jul 19 19:04:07 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W6L1 
<li>problem n: 1482 
<li>Status: fixed
<li>Type: DVDD
<li>Action: Currents_investigated
<li>entered by: amitra 
<li>description is: <p>Since the PS swap the DVDD current has held steady. The plot can be found <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=258&frame=2&anchor=18:58:17'> here</a>.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W6&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Jul 19 19:09:06 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7048&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7048  width='300' align='top'></a></td><td>The 2V DOIM current has held steady since the PS swap</td></tr></table>
<!-- Author: Ankush -->

<!-- Date: Tue Jul 19 19:11:10 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W6All 
<li>problem n: 1483 
<li>Status: fixed
<li>Type: VDOIM
<li>Action: Currents_investigated
<li>entered by: amitra 
<li>description is: <p>Since the PS swap, the currents for the 2V and 5V DOIM lines have held steady.  The plots can be found <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=258&frame=2&anchor=19:09:06'> here</a> and <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=258&frame=2&anchor=18:59:27'> here</a>.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W6&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Jul 19 19:17:37 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7050&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7050  width='300' align='top'></a></td><td><p>I've been watching this ladder as the bias seemed to be drifting up and down. Now looking at more recent data, it is behaving the same as before.  (Although I'm  not sure why there's no much structure in the first place).</p> </td></tr></table>
<!-- Author: Ankush -->

<!-- Date: Tue Jul 19 19:20:40 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W2L1 
<li>problem n: 1359 
<li>Status: fixed
<li>Type: BIAS
<li>Action: Currents_investigated
<li>entered by: amitra 
<li>description is: <p>Looking at more recent data this ladder is behaving as it did before. So the current excursions observed before are part of its characteristics.  The plot can be found <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=258&frame=2&anchor=19:17:37'> here</a>.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jul 19 19:28:57 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W2All 
<li>problem n: 1485 
<li>Status: fixed
<li>Type: VDOIM
<li>Action: PS_work
<li>entered by: amitra 
<li>description is: <p>Since the PS swap, the DOIM have not tripped for a month.  Closing this thread.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W2&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Jul 20 00:12:34 2005 -->
CAEN crate 5 spontaneously turned off 
<pre> 
com_int = 0 
detector = 0, status = 0 
detector = 2, status = 0 
 Caenet_write: Error number -1 ffffffff received 
group_info:cr_n = 5, response = -1 
 Caenet_write: Error number -1 ffffffff received 
group_info:cr_n = 5, response = -1 
 Caenet_write: Error number -1 ffffffff received 
group_info:cr_n = 5, response = -1 
Crate #: 1 
Group Name: "GROUP00" 
Crate #: 2 
Group Name: "GROUP00" 
</pre> 
interesting enough, there was a short phase of incommunicado ...
<!-- Author: Marcel -->


<!-- Date: Wed Jul 20 00:13:32 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7051&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7051  width='300' align='top'></a></td><td>you see the AVDD going blue and then black</td></tr></table>
<!-- Author: Marcel -->


<!-- Date: Wed Jul 20 00:26:04 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7052&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7053  width='300' align='top'></a></td><td>SVT SPYMON 4285 everything looks ok</td></tr></table>
<!-- Author: Marcel -->

<!-- Date: Wed Jul 20 11:16:31 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W0L2 
<li>problem n: 1490 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis
<li>entered by: amitra 
<li>description is: <p>This ladder continues to have chip a3 read as a2. The error rate is low, but it should still be investigated.  May need to boost the RDriver value.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Jul 20 13:52:56 2005 -->
crate 2 (NW Top Bot) needed its weekly hockerization ...
<!-- Author: Marcel -->


<!-- Date: Wed Jul 20 14:07:27 2005 -->
<h3> New Imon limits </h3> 
Dean made new Imon limits, results can be found <a href='http://www-cdf.fnal.gov/~dhidas/internal/ImonLimits/'>here</a> 
Since changes are really minor, I think we should use the new table  
soon  
<!-- Author: Marcel for Dean -->


<!-- Date: Wed Jul 20 16:22:06 2005 -->
<h4> Trigger Table tests</h4> 
did some trigger table tests with Veronica ... everything went smooth, this was test trigger, which actually had some legacy triggers re moved.
<!-- Author: Marcel -->


<!-- Date: Wed Jul 20 16:30:26 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7054&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7055' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7060&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7061' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7056&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7057' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7058&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7059' ></a></center>
<!-- Author: Marcel -->
<!-- Comment: Wed Jul 20 16;31;19 comment by...Marcel -->
SVT test, wedge 0 is now using AM++ and AMSRW.
No big difference seen up to now ... stay tuned


<!-- Date: Thu Jul 21 09:34:45 2005 -->
<h3> Store 4287 aborted </h3> 
First the electron lense was off, so I told to go without the silicon. After they brought the lense back up, I was just about to ramp the Silicon, wehn they aborted.
<!-- Author: MArcel -->


<!-- Date: Thu Jul 21 10:52:43 2005 -->
<h3>Silicon Cooling Work</h3> 
 
<p>The cryo techs told us one of the filters for the cooling needed to be cleaned.  Apparently there was 60 lbs differential pressure due to <em>crap</em> in the filter. Cleaning the filter involved shutting off the chiller..so I turned the detector off.</p> 
 
(<em>That was cool, it was the first time I hit the all-detector off button :-></em>).</p> 
 
<p>While shutting down,  SB1W6L4 (e164), SB0W10L2 (e0a2), SB5W0L2 (e502) all tripped. Also the portcard for SB4W8 was reading a voltage even though it was off....ie: a read-back problem.  So I hockerized PS 13.</p> 
<!-- Author: Ankush -->
<!-- Comment: Thu Jul 21 11;10;55 comment by...Ankush,Jen :-), Ulrich -->
<p>and the cooling dudes took the opportunity to reboot the iFix PC down in the counting room.</p>

<!-- Comment: Thu Jul 21 11;11;54 comment by...Fish Face -->
<p>Ok...it was Jennifer :-) not Jen...in case you were confused</p> 

<!-- Comment: Thu Jul 21 12;27;13 comment by...Jennifer & Ulrich -->
Jennifer reestablished flows to the SVX (the ISL flows did not trip), and we are waiting for the chiller go back to its operation point. 
<p>
The filter which Jim Loskot exchanged was in the chilled water supply to the SVX chiller. We hope to regain more flow to the chiller now. Currently, the temperatures are rather on the high side, so we decided together with Marcel to watch the system for an hour before we switch on the power supplies again.

<!-- Comment: Thu Jul 21 13;53;04 comment by...Ankush, Jennifer, Marcel and Ulrich -->
<h3>...Never goto lunch</h3>

<p>The cooling flows looked good and the temperatures were going down nicely.  So we decided to goto lunch.</p>

<p>We drive to the restaurant, step out of the car and then the damn pager goes off !! The ISL flow have dropped to zero....bugger!!</p>


<!-- Comment: Thu Jul 21 19;48;48 comment by...Ulrich H. -->
<h3>Cooling aftermath</h3>
The flow trip was in the SVX chiller rather than in the ISL
chiller. The SVX flows tripped on an over-pressure at the COT face for L00E, with a value of 13.8 psi. Other pressures were also approaching this hard limit.
<p>
The deeper reason for the trip lies in the reduced temperatures of the SVX chiller. At the same supply valves settings, the flows to the SVX decrease, and the pressures increase with decreasing temperature. Temporarily, the temperatures went back to the nominal -10C.
<p>
The intermediate solution is to close the affected valves by about 5%. At this time, the only non-default value is BHW2 with 75% instead of 80%. Currently, we are watching the time evolution of the temperatures (seem to go up again) and pressures.
<!-- Comment: Fri Jul 22 12;02;58 comment by...Jennifer, Ulrich -->
<h3>Cooling aftermath II - The next morning</h3>
We checked out temperatures and pressures again today. The temperatures ended up at about the same point as before yesterday's work on the system (-8.7 C). It seems that some limitation in the chiller system is governing this setpoint. Since we ended up with the same temperature after two inprovements in the chilled water circuit, I (Ulrich) doubt that chilled water flow is the only issue. We discussed several options with Bill Noe (note: he is on vacation next week), including calling in a RAM technician and switching to the spare chiller, but this needs further discussion.

<p>
In addition we realized that both automatic chiller bypass valves, SVX_CHBY and ISL_CHBY, were opened up to 100%, i.e. not regulating anything any more. With the help of Rob Roser (thanks!), we regulated the manual bypass valves by tiny amounts, such that the automatic valves do not run into their limits any more.
<!-- Date: Thu Jul 21 17:31:47 2005 -->
<h3>Silicon back up</h3> 
 
<p>The Silicon cooling is back up and ,after a few panic attacks, the Si detector is back on line.</p> 
 
<p>The Silicon cooling pressures and temperatues are looking good.</p>
<!-- Author: Ankush, Ulirch, Marcel -->
<!-- Comment: Thu Jul 21 19;22;37 comment by...Marcel -->
as a safety precaution, I have restarted the PSGUI



<!-- Date: Thu Jul 21 22:20:43 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7062&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7063  width='300' align='top'></a></td><td>Store 4291 came in with 59E30, not really great. Everything looks ok.</td></tr></table>
<!-- Author: Marcel -->


<!-- Date: Fri Jul 22 07:44:25 2005 -->
<h4> The Quenchatron did it again</h4> 
The store was aborted after a quench at E11.  
Abort was clear, Postquench checkout was ok  
<!-- Author: Marcel -->
<!-- Comment: Fri Jul 22 07;45;11 comment by...Quenchmeister -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2005&action=view&page=-12480&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2005&action=view&page=-12480 width='300' align='top'></a></td><td>BLM Rad Summary</td></tr></table>

<!-- Date: Fri Jul 22 09:48:05 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W6L4 
<li>problem n: 856 
<li>Status: needs_work
<li>Type: DVDD
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>During the quiet time yesterday we managed to power up this ladder without it tripping.  Then tried to get data out of it with SVVXDAQ.  The last chip never returned any data.  From time to time, the z side chips would also disapear.</p>  <p>During the next quiet time, we should see how long this ladder can stay powered.  Then see if any chip settings can be adjusted to reduce the errors while running SVXDAQ.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W6&layer=L4">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Fri Jul 22 15:18:16 2005 -->
<h3>Dead BERT Chiller</h3> 
 
<p>I went over to FCC today to see if the BERT chiller can be fixed.  The simple answer: it can't.  Its dead, Jim.</p> 
 
<p>We now have two options: we can replace it for ~$500...or...we can sneak into SiDet and <em>borrow</em> the other Run IIb chiller.</p> 
 
<p>Before I forget, the Run IIb chiller in SiDet can be found by: 
<ol> 
<li>Entering through the main enterance</li> 
<li>Turn left into the Glass-Room</li> 
<li>Inside the Glass-room, turn right and the BERT chiller should be somewhere round there.</li> 
</ol> 
  
<p>Any volunteers for breaking into SiDet?</p> 
 
<p>On the BitBooster front, there's nothing to be said.  The prototype board should be ready next week.</p>  
<!-- Author: Ankush -->
<!-- Comment: Fri Jul 22 17;19;19 comment by...Marcel & Sebastian -->
We have decided to buy a new chiller and have already a ok from Willis


<!-- Date: Fri Jul 22 19:07:47 2005 -->
<h3> Board Swap </h3> 
In order to track down some problems in svx03, Markus and I swapped the VRB in slot 20 (e3a/e3b) in is 184, out is 172. Worked well in Cosmics, just in case if this is causing Problems.<br> 
172 did  not cause the problems, however, it was the SCPU in 21
<!-- Author: Markus & Marcel -->


<!-- Date: Fri Jul 22 19:27:14 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7064&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7065  width='300' align='top'></a></td><td>Store 4293 Things look ok</td></tr></table>
<!-- Author: Marcel -->
<!-- Comment: Fri Jul 22 19;37;20 comment by...Marcel -->
<h3> e071 took some time off </h3>
I spotted the Z side yellow in SVXMON, I asked the Ace to issue an HRR. That fixed it !


<!-- Date: Fri Jul 22 22:18:39 2005 -->
<center><a href='/elog/notebooks/silicon/Fri_Jul_22_2005_221812.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7067' ></a><a href='/elog/notebooks/silicon/Fri_Jul_22_2005_221820.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7069' ></a></center>
<!-- Author: Sebastian -->
<!-- Comment: Fri Jul 22 22;28;02 comment by...Sebastian -->
<pre>Closer look at times betwen L1A. Distributions taken at 60E30 and L1 rate of 19kHz. CLK set at 5.5MHz, so that period/2 is smaller
than 132ns but also larger than 264ns since the histo trigger looks for L1A 1 to L1A 1 (I don't know how to set a better trigger in this mode!). Verified that we don't get L1A delta(t) smaller than 396ns(!). But it happens very often that the L1A come in a row (see trace below), the shape of the distribution at low delta(t) is kind of flat due to the 4 buffer limit (if we were to take all the events we would have a larger peak at 396ns).</pre>


<!-- Date: Fri Jul 22 22:28:50 2005 -->
<table><tr><td><a href=/elog/notebooks/silicon/Fri_Jul_22_2005_222847.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7073  align='top'></a></td><td>See entry above.</td></tr></table>
<!-- Author: Sebastian -->


<!-- Date: Sat Jul 23 14:45:50 2005 -->
Caen crate 5 hockerized by aces
<!-- Author: Marcel -->


<!-- Date: Sat Jul 23 23:32:43 2005 -->
<h3> f032 died </h3> 
Kindly enough, it waited after I have finished my dinner. Anyway I tried the ususal stuff (wedgewide, Layerwise, hockerized the CAEN) nothing worked. Since also the RTServer had problems,  I also tried to reboot svxinter and fib01, just to make sure. Nothing worked. <br> 
Since it cannot be operated safely, I took it out of the hardware database, nothing we can do right now. 
During the next quiet time we should try to turn it back on, if that does not work, go in and try swapping cables, etc.   
<!-- Author: Marcel -->
<!-- Comment: Sun Jul 24 01;06;43 comment by...Marcel -->
<h2> The Plan </h2>
On access go in and swap Power Supply LV and Fib Command cables and see if that fixes it.

<!-- Comment: Sun Jul 24 01;16;43 comment by...MArcel -->
<h4> addendum </h4>
<pre>
 TRIP: ISL  B0  W3 External Trip
Sat Jul 23 22:39:14 CDT 2005     success: Resetting trips
Sat Jul 23 22:40:05 CDT 2005     success: Power Supply ISL B0 W3 OFF
Sat Jul 23 22:40:25 CDT 2005     ERROR: Power Supply ISL B0 W3 Handshake - Could not turn on power - check
ed 10 times
Sat Jul 23 22:40:33 CDT 2005     TRIP: ISL  B0  W3 AVDD2 OverCurrent
Sat Jul 23 22:47:13 CDT 2005     Lost communication with iFix
Sat Jul 23 22:47:23 CDT 2005     Established communication with iFix
Sat Jul 23 22:47:23 CDT 2005     Interlock is enabled
Sat Jul 23 22:48:55 CDT 2005     ERROR: Power Supply ISL B0 W3 Handshake - Could not turn on power - check
ed 10 times
Sat Jul 23 22:49:03 CDT 2005     TRIP: ISL  B0  W3 AVDD2 OverCurrent
Sat Jul 23 23:05:43 CDT 2005     success: Resetting trips
Sat Jul 23 23:06:26 CDT 2005     ERROR: Power Supply ISL B0 W3 Handshake - Could not turn on power - check
ed 10 times
Sat Jul 23 23:06:34 CDT 2005     TRIP: ISL  B0  W3 AVDD2 OverCurrent
</pre>
I do not really understand the external Trip message here ....
<!-- Date: Sat Jul 23 23:33:45 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W3L2 
<li>problem n: 1495 
<li>Status: needs_work
<li>Type: AVDD
<li>Action: Incident
<li>entered by: marcel 
<li>description is: this guy kept tripping on AVDD. Study it during the next quiet time and see from there.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W3&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sun Jul 24 00:17:35 2005 -->
Store 4295 came in, initla Lumi was 106E30
<!-- Author: Marcel -->


<!-- Date: Sun Jul 24 00:20:38 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7074&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7075  width='300' align='top'></a></td><td>SVT is happy</td></tr></table>
<!-- Author: Marcel -->
<!-- Comment: Sun Jul 24 01;19;52 comment by...Marcel -->
or not so happy ... B1W3 is acting again 
<pre>
rate_B0    89   87   64   65   92   81   50*  87   55*  82  100   63 
rate_B1    70   90   40*  31*  86   44*  66    0*  80   94   75  100 
rate_B2    87   94   93   90   89   78   63   68   83   79   84  100 
rate_B3    63   97   64   82   94  100   94   93   85   76   63   94 
rate_B4    61   84   58* 100   91   93   29*  82    0*  88   82   93 
rate_B5    98  100   95   96    0*  95   83   89   95  100   95   98 
</pre>
needs to be bitboosted

<!-- Date: Sun Jul 24 17:32:39 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W5L2 
<li>problem n: 1100 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: rahaman 
<li>description is: Since then (run 200752) data looks fine! 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B1W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sun Jul 24 19:19:28 2005 -->
<h4> IB4W0L1 made some excursions </h4> 
This ladder also started tripping on AVDD, this time OverVoltage. Weird enough. I was able to turn things back on. But after checking the Full status after things are stabilized, it shows 9 Volts on AVDD instead of 7.5 V. This is kind of interesting. and way above spec. Unfortunately, we do not monitor the voltages in IMON. 
 
  
<!-- Author: Marcel -->
<!-- Comment: Sun Jul 24 19;23;59 comment by...MArcel -->
but Ben's ntuples do and the Voltage was rocksolid at 7.5 Volts.



<!-- Date: Sun Jul 24 19:36:38 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7076&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7077  width='300' align='top'></a></td><td>This is the Full status for this suplly, I also checked several other supplies, the spread for low voltage is very small, so I consider this real. Hockerization did not help either. so on the next opportunity go down and probe the supply.</td></tr></table>
<!-- Author: Marcel -->
<!-- Comment: Sun Jul 24 19;37;57 comment by...Marcel -->
since I consider it unsafe to operate this ladder, I took it out of the Hardware database. This weekend already grilled two ladders, however symptoms are different, they other guy would not turn on at all.

<!-- Comment: Sun Jul 24 19;46;51 comment by...Marcel -->
so our set voltage is 7.5 Volts, the maximum AVDD voltage the Manual claims is 10 Volts. Looks like a CAEN failure to me, but maybe Jen can comment



<!-- Date: Mon Jul 25 06:51:20 2005 -->
<h4> f032 is back </h4> 
looks like at least ... let us see how it is behaving 
<!-- Author: Marcel -->
<!-- Comment: Mon Jul 25 08;27;00 comment by...Marcel -->
tripped once more but came back gracefully, could also be due to the fact, that we had al kind of other troubles


<!-- Date: Mon Jul 25 08:58:56 2005 -->
<h2> Weekly Summary </h2> 
 
<ul> 
<li><b>Monday</b>: Problems at the beginning of the store due to high proton losses, MCR had to retune</li> 
<li><b>Tuesday</b>: Tevatron aborted, we wen into access and had a look at e001. Chopped the chipChain of 122 at 86. Ankush and Sasha did some quiet time studies</li> 
<li><b>Wednesday</b>: Crate 5 spontaneous transition, hockerized crate 2. Dean made new IMON limits, a trigger table test and the first time we are running with one wedge of the new SVT.</li> 
<li><b>Thursday</b>: Troubles with the elctron lense at the beginning of the store, after they fixed the lense, they lost the store, Tevatron now known as Quenchatron.<br> 
Turned the Silicon off to allow some work on the cooling to increase the flow, seemd to work at first, but temperatures at the end went back to -8.9 C</li> 
<li><b>Friday</b>: Another Quench at E11 in the Quenchatron, was clean for us. Markus and I did work on the EVB2B, still some VME issues, but otherways fine <br> With the new store e071 z side took some time off, an HRR fixed it. In this case it paid off, that I stayed for the shot 
</li> 
<li><b>Saturday</b>: Hockerized crate 5.Another EVB2B test things look pretty ok, we are ready for an end of store test Then f032 died... while in Standby. </li> 
<li><b>Sunday</b>: Store came in without major problems, in the evening f401 died, smeel like CAEN failure</li> 

<li><b>Monday morning</b> f032 is back, i was able to revive it, let's see if it is stable</li>
</ul>
<!-- Author: Marcel -->


<!-- Date: Mon Jul 25 09:00:18 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7078&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7079  width='300' align='top'></a></td><td>Store 4296 is in, after one hour struggeling with the Network we are also taking data </td></tr></table>
<!-- Author: Marcel -->