<!-- Title: 11:01:24  Mon Mar 13 2006 -->
<!-- Crewchief: Everyone !! -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Shutdown Week 3 
 
- Continue with Problem DB Review 
- Prepare for Saturday's 8 hour power cut </pre>


<!-- Date: Mon Mar 13 11:02:03 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>CAEN 5V Enables are ON</pre></td></tr></td></table>
<!-- Author: Ankush -->


<!-- Date: Mon Mar 13 11:03:52 2006 -->
<h3>ISL Conductivity</h3> 
 
<p>Dean will change the ISL resin at 1pm today to fix the ISL Conductivity rise</p>
<!-- Author: Ankush -->
<!-- Comment: Mon Mar 13 13;14;11 comment by...Jennifer :-) & Ankush -->
<pre>ISl conductivity work has commenced!!</pre>
<!-- Comment: Mon Mar 13 14;29;46 comment by...Jennifer :-) & Ankush -->
<pre>I'm rotten. The cooling work finsihed about 25 minutes ago :-(</pre>
<!-- Date: Mon Mar 13 13:13:17 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>CAEN 5V Enables OFF</pre></td></tr></td></table>
<!-- Author: Ankush & Jose -->
<!-- Comment: Mon Mar 13 14;35;56 comment by...Ankush & Jose -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>CAEN 5V Enables ON</pre></td></tr></td></table>


<!-- Date: Mon Mar 13 18:10:38 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8455&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8455  width='300' align='top'></a></td><td>Another entry for the ISL conductivity: on the rise!! I'd like the techs to look at this first thing in the morning.</td></tr></table>
<!-- Author: Jennifer :-) -->
<!-- Comment: Tue Mar 14 06;20;21 comment by...Ulrich -->
The conductivity is at 12 now, Bill Noe is on the case, see the
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=cryo-gas&action=view&page=1863&frame=2&anchor=06:03:20'>
cryo e-log</a>.
<!-- Comment: Tue Mar 14 09;38;22 comment by...Jennifer :-) and Ulrich -->
The ISL conductivity is going down since about 8:00 this morning. The cryo crew found the problem and fixed it. During the work on the resin yesterday afternoon (resin was leaking), a part of the piping was exchanged. However, a protective plastic cap was not removed, so that effectively, the deionizer was blocked.
<!-- Date: Mon Mar 13 18:42:53 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>CAEN 5V Enables OFF</pre></td></tr></td></table>
<!-- Author: Jose & Ankush -->


<!-- Date: Mon Mar 13 19:02:50 2006 -->
<center><a href='/elog/notebooks/silicon/Mon_Mar_13_2006_190238.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8459' ></a><a href='/elog/notebooks/silicon/Mon_Mar_13_2006_190223.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8457' ></a></center>
<!-- Author: Ankush -->
<!-- Comment: Mon Mar 13 19;07;23 comment by...Jose & Ankush -->
<h3>Running SB0W6L0</h3>

<p>This ladder had been taken out of the Hardware database but goes to STANDBY and passes "SET DEFAULTS" in SVXDAQ with no problems.  We then ran the ladder and you can see the typical SVXDAQ histograms while running in ReadAll (left) and Nearest Neighbour Mode (right). </p>

<p>This ladder has rather low small readout. In NN mode the threshold was lowered to 1.  However it does read out.  So we should consider putting this ladder back into data taking with a lower threshold and then measure its efficiency. I expect it to be low but it's hopefully bigger than 0.</p>


<!-- Date: Mon Mar 13 19:37:48 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W6L0 
<li>problem n: 1636 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>This ladder was taken out of the HWDB but it turns on fine and passes 'SET DEFAULTS' in SVXDAQ.  The SVXDAQ histograms can be found in the <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=292&frame=2&anchor=19:02:50'> Silicon e-log</a>.  The thresholds had to be lowered to 1.0 while running in NN mode but it did readout.</p>  <p>Before proceeding further we should do the usual fibre-swap, Light-level measurement, etc. The problem may lie elsewhere.</p>  <p>In any case this is a ladder we should consider bringing back.</p>   
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W6&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Mar 13 19:42:27 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L1 
<li>problem n: 1637 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>During the problem DB review this ladder started giving occassional 'OO Sequence errors'.  However the reported errors always seemed to be of the form 31->28 and 15->12.</p>  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Mar 13 19:46:35 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L4 
<li>problem n: 1638 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>During the problem DB review this ladder was turned on to STANDBY with no problems.  It also intialises with 'SET DEFAULTS' in SVXDAQ with no errors.  The ladder was then ran error free for 10,000 events in NN and RA mode.</p>  <p>The Hardware DB should be updated and this ladder should be put back in.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Mar 13 19:48:39 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W9L1 
<li>problem n: 1639 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Incident
<li>entered by: amitra 
<li>description is: <p>During the problem DB review, this ladder started giving a low rate of OO sequence errors in NN mode; the ladder ran error-free in RA mode.  However this ladder has no history of errors at all.  Needs to be reinvestigated to see if this error dissapears once we return to normal runnning conditions.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W9&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Mar 13 19:49:34 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W9L4 
<li>problem n: 1640 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Diagnosis
<li>entered by: amitra 
<li>description is: <p>During the problem DB review, this ladder started giving 00 Sequence errors in NN mode; the ladder ran error-free in RA mode.  Need to re-exaimine this ladder to see if the errors dissapear when we return to normal running conditions.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W9&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Mar 13 19:52:39 2006 -->
<table><tr><td><a href=/elog/notebooks/silicon/Mon_Mar_13_2006_195229.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8463  align='top'></a></td><td><h3>Running SB0W8L4</h3> 
 
<p>This ladder was taken out of the Hardware Database. As part of the problem DB review this ladder was put to STANDBY with no problems and passed "SET DEFAULTS" in SVXDAQ with no errors.  The ladder was then ran error-free after 10,000 events in RA and NN mode.</p> 
 
<p>This ladder should be put back in for data taking.</p></td></tr></table>
<!-- Author:  Ankush & Jose -->


<!-- Date: Mon Mar 13 20:13:03 2006 -->
<h3>Problem DB Review: SB0W6, SB0W7, SB0W8, SB0W9</h3> 
 
<p>We wanted to review SB0W4 and SB0W5 but I (Ankush) took the FTM out to have the BE kludge realigned.  So both these wedges will need to be examined once the FTM is returned.</p> 
 
<p>Today Jose and I managed to look at the following wedges: SB0W6, SB0W7, SB0W8 and SB0W9. The following is a list of ladders which did not follow their problem DB entries: 
<ul> 
<li>SB0W6L0 : This ladder was out of the Hardware Database but turned on and initialised with no problems.  In was ran in RA and NN mode.  In NN mode, the threshold had to be lowered.  This ladder needs to be investigated further and should be considered to be put back in for data taking.  Further details can be found   
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=292&frame=2&anchor=19:02:50'> 
here</a>.</li> 
<li>SB0W8L1 : Now seeing low rate of 00 Sequence errors.  Needs to be reinvestigated to see if the errors return after returning to normal running conditions. One interesting point are the errors seem to be similar.  They are either 31->28 or 15->12. Looks like bits 0 and 1 are stuck low.</li> 
<li>SB0W8L4 : This ladder was taken out of the Hardware DB.  But it now goes to STANDBY with no problems and passes SET DEFAULTS in SVXDAQ with no errors. This ladder runs error-free after 10,000 events in NN and RA mode.  This ladder should be put back in to the Hardware DB. Further details can be found <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=292&frame=2&anchor=19:52:39'> 
here</a>.</li> 
<li>SB0W9L1 & SB0W9L4 : These ladders have started giving 00 sequence errors (SB0W9L1 is at a lower rate) but has neither ladder has any history of errors during data taking.  Needs to be re-examined when we return to normal operating conditions.</li> 
</ul>  
</p> 
 
<p>We should check the Hardware Database entries for SB0W6L0 and SB0W8L4 to make sure they are suitable for running.</p> 
 
<p>So it will be good if these two ladders have returned.  Also the first bulkhead is almost complete.  But we have a long way to go!!</p> 
 
<p>The record of 4 wedges has been set...I dare you to break it :-)</p>
<!-- Author: Ankush & Jose -->



<!-- Date: Tue Mar 14 08:53:44 2006 -->
<h4>Don't forget....</h4> 
 
<p>If you're continuing the problem DB review, don't forget that SB0W4,SB0W5,SB1W4,SB1W5, SB3W2, SB3W3 are not available as the FTM is missing. I took them out last wek to have the BE Kludge fixed.</p> 
 
<p>Also we are running a bit warmer than usual, only power one wedge at a time to be safe.</p>
<!-- Author: Ankush -->



<!-- Date: Tue Mar 14 10:00:58 2006 -->
We recieved a new spare FFO (SN 101, PN 550303) from Marcel.  It ran the highspeed test for 32345000 loops, with no errors.  Also, the readout-return (which is used by the ghostbuster board via the SRCTM for resonance condition detection) works fine.  This board does not seem to display the glink problems that our current testand FFO (SN 105, PN 550313) has been having.  For now I will leave the new board in the teststand so I can take the old one over to prep.
<!-- Author: Mark&Marcel  -->


<!-- Date: Tue Mar 14 10:36:06 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030>Is somebody working on the silicon? I have received pages about SVX power supply trips on the alpha-numeric pager over the last 15 minutes, but I do not see anything in the e-log. Before you start working on the silicon during the shutdown, remember to 
<ol> 
<li>Note in the e-log that you switched the 5V enables</li> 
<li>Silence the trip alarms in iFix</li> 
</ol></td></tr></td></table>
<!-- Author: Ulrich -->


<!-- Date: Tue Mar 14 12:25:53 2006 -->
We stopped the Problem DB review for lunch break. During this time trip alarm is set to "enable" and CAEN 5V Enable for SVX is OFF. We will resume the work after lunch.
<!-- Author: Tuula and Oscar -->
<!-- Comment: Tue Mar 14 14;44;37 comment by...Oscar -->
I am back and going on with the review. Alarm is silent.

<!-- Date: Tue Mar 14 15:59:10 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W11L4 
<li>problem n: 101 
<li>Status: unfixable
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: oscar 
<li>description is: We tried to fix the bit problem in chip 8a. Nothing we tried worked, so it seems it is an unfixable problem. <br> We tried to change R-driver for the chip from 4 to 7, and for all chips. <br> We change the ISEL values to 1 for the chip (and for all the chips) and it did not help. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W11&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Mar 14 16:10:29 2006 -->
<table><tr><td><a href=/elog/notebooks/silicon/Tue_Mar_14_2006_161022.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8465  align='top'></a></td><td>Ladder SB0W11L1 (e0b1) seems behaving fine in SVXDaq (no error). This ladder was taken out of the HW database because it is not biased properly.<br> 
We are trying to reintegrate it and check whether we can get  anything out of it.</td></tr></table>
<!-- Author: Oscar/Ankush -->

<!-- Date: Tue Mar 14 16:36:32 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W11L1 
<li>problem n: 1641 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: Diagnosis_update
<li>entered by: oscar 
<li>description is: Ankush and I decided to put this ladder back online. The reason for having it offline was that it is not got biased. Some monitoring may help us to diagnose this again.<br> <b>If this does not see physics (cosmics?), should be taken offf the HW DB</b>  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W11&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Mar 14 16:42:44 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W3L0 
<li>problem n: 78 
<li>Status: needs_bore_access
<li>Type: BIAS
<li>Action: Diagnosis_update
<li>entered by: oscar 
<li>description is: Ankush and I decided to integrate this ladder online so we may monitoring whether it is still blind to physics. However, we expect some work will be done soon since it has been waiting for more than 1 year for boroscope check. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W3&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Mar 14 16:44:52 2006 -->
<h3>Problem DB Review: SB0W10 SB0W11 SB1W0 SB1W1 SB1W2 SB1W3</h3> 
<br> 
We checked those ladders. The differences with the problem database was checked and entries were updated, as needed.  
<br> 
This is the general summary (for wrong or modified entries): 
<ul> 
<li> SB0W10L1 was out of the HW DB. It powered up fine and seems fine in the readout. The claim was that it is not biased. We will keep it in for future monitoring/work. 
</li> 
<li> SB0W10L4 is unfixable. We tried to fix it but it was not possible. PDB entry was updates accordingly. 
</li> 
<li> SB1W3L0 was taken out of the HW DB since it does not see physics. It has been waiting for more than 1 year for checking. We take it online again and waiting for work and monitoring. 
</li> 
</ul> 
The rest is essentially fine (well, we may need to take a deeper look on them to be sure due to our lack of expertise. We will do this ourselves).  
<!-- Author: Tuula/Oscar/Ankush -->


<!-- Date: Tue Mar 14 16:46:15 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030>After work is done, CAEN 5V Enables OFF and alarms are back to enable.</td></tr></td></table>
<!-- Author: Oscar -->


<!-- Date: Tue Mar 14 19:20:24 2006 -->
<h3>Silicon Bias Checker</h3> 
 
<p>Tuula's Bias checker script has been upgraded by Marcel to publish the results on a web page.   
 
Check it out for yourself at: 
<a href="http://www-cdfonline.fnal.gov/cgi/internal/ops/svxii/svxbiascheck.pl"> 
http://www-cdfonline.fnal.gov/~svxii/cgi-bin/svxbiascheck.pl</a>.</p>
<!-- Author: Marcel, Tuula & Ankush -->
<!-- Comment: Wed Mar 15 09;55;21 comment by...Marcel -->
yupp, Scico Shifts can be boring, especially if the Quenchatron quenches all the time ...
<!-- Date: Wed Mar 15 08:25:54 2006 -->
<h3>Plan to install 3.3V to SRC racks today</h3> 
 
<p>The CCC needs 3.3V which will have to be added to our Silicon Racks.  Dervin plans to do this work today...I'll around while he does this.</p>
<!-- Author: Ankush -->
<!-- Comment: Wed Mar 15 09;52;12 comment by...Ankush -->
<p>
The work has started.  It just so happens the Fan Pack for SVX06 rack was bad.  So the rack was turned off while George extracted the Fan Pack and is fixing it now.  Roberto is in the process of making the cables for SVX06. </p>

<p>For the moment let's put off any work involving the DAQ system until lunch time....but that doesn't stop anyone looking at the bit reproter, etc :-)</p>  


<!-- Comment: Wed Mar 15 10;35;54 comment by...Ankush -->
<table border=0><td><tr><td bgcolor=#e0e030><p>Both SRC racks are OFF while Roberto adds the 3.3V lines.</p></td></tr></td></table>


<!-- Comment: Wed Mar 15 16;51;33 comment by...Ankush -->
<pre>forgot to mention Roberto completed adding the 3.3V lines just after lunch.</pre>
<!-- Date: Wed Mar 15 11:41:10 2006 -->
<h1>Tevatron ABORT!</h1> 
<p> 
This one is for you, Ankush... Jennifer the RDCO pager carrier was <b>PAGED for a radiation abort</b>. 
<p> 
Seems like they are doing C0 & D0 house maintenence this morning. We were unable to read anything out of ACNET (oops, ACNET isn't running now), and we assume the power cycle caused the alarm. 
<p> 
In your face, Ankush. I get NO respect around here... :-)
<!-- Author: Jennifer :-) & Ulrich -->
<!-- Comment: Wed Mar 15 11;41;54 comment by...Jennifer :-) -->
<pre>ch 13 has now changed "D0" to "B0" above. Sneaky.</pre>


<!-- Date: Wed Mar 15 14:05:33 2006 -->
We are turning on the 5V enable for SVX and silencing the SVX trip alarm, so we can look at some wedges in svxdaq.
<!-- Author: Mark&Shulamit -->


<!-- Date: Wed Mar 15 14:15:03 2006 -->
<h4>Chiller Maintenence</h4> 
I spoke with Bill Noe about his further plans for chiller maintenence. The only two things he has planned are: 
<ul> 
<li>Replacement of the flaky flow meter on the ISL chiller. The spare part has been ordered. We will decide about the actual procedure to change the flow meter after the spare part will have arrived. It could mean that we have to switch to the backup chiller for a while.</li> 
<li>Exchange of the air filter for the new air dryer module. This module makes sure that the air for the pneumatic valves is dry. Since a bypass air pipe has been installed together with the module, my guess is that this job will not interfere with anything else.</li> 
</ul>
<!-- Author: Ulrich -->

<!-- Date: Wed Mar 15 16:11:34 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W6L4 
<li>problem n: 856 
<li>Status: unfixable
<li>Type: DVDD
<li>Action: Diagnosis_update
<li>entered by: mhartz 
<li>description is: Checked in on this ladder.  It is still tripping on AVDD or DVDD. 
<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: Wed Mar 15 16:14:42 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W8L2 
<li>problem n: 4 
<li>Status: needs_study_time
<li>Type: AVDD2
<li>Action: Diagnosis_update
<li>entered by: shulamit 
<li>description is: The AVDD current for this ladder has been steady at ~835 uA for the past 200 days.  We looked at the z side chips in svxdaq in RA mode and they seemed to work fine.  After things have settled down after the shutdown we should try including the z side again. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W8&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Mar 15 16:19:02 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W10L4 
<li>problem n: 603 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: mhartz 
<li>description is: This ladder is currently only giving capid errors for chip 88 which is sparsed out.  The thresholds were raised to 15 for chips 8a, 89, a3 and a2 to try to decrease the readout times.  It looks like this may have helped a very small amount.  Readouts are now 3.8-4.2 microseconds depending on the run.  We should check how the raised thresholds affect offline tracking once we have the necessary code for such studies.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W10&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Mar 15 16:38:47 2006 -->
I will power cycle b0svx06 to test the CCC.
<!-- Author: Sebastian -->
<!-- Comment: Wed Mar 15 17;28;38 comment by...Sebastian -->
<br>
<a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8466&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8466' width='300'></a><br>
<b>I have changed the CLKFO delay of ISL to match SVX (and the teststand). </b> The above trace is the one I get now for ISL, which is the same as the 
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=290&frame=2&anchor=19:00:14'>
svx one</a>. The ISL CCC works fine and now reports BX error (as in SVX and tstsvx1 - need firmware fix to fix this). Hopefully we will have a working CCC for all systems later this week.<br>
This is the setting I modified: FNT058 1B is now 5 (was 8).<br>



<!-- Date: Wed Mar 15 16:42:25 2006 -->
<h3>Problem DB Review: e16, e18, e19, e1a</h3> 
We continued the review of SVX wedges.  We were not able to look at e14 or e15 because their FTMs are out for backend kludge adjustments.  The ladders of interest among these wedges are: 
<ul> 
<li>e164 - This ladder has been out due to persistent AVDD and DVDD trips.  We put it back in to take a look at it and it continually tripped as expected. 
<li>e182 - This ladder is one of two with dps off and raised thresholds, so its ADCMon plots don't look normal.  The SVXMon occupancy plots look ok, however.  This is a good canditate if we ever get some offline tracking efficiency tools.  This ladder also has its z side chopped.  The AVDD current, however, has been back to its initial value of ~835 uA for the past 200 days.  We included the z side in svxdaq and it ran fine.  After the shutdown is over, we should include it for data taking. 
<li>e1a4 - This ladder is now only giving capid errors for chip 88 which is sparsed out.  The current problem with this ladder is its long readout time, which is usually 3.8-4.2 microseconds averaged over a run.  Sasha had raised the thresholds to 15 for chips 8a, 89, a3 and a2 to combat this, but readout times are still large. 
</ul> 
All the other ladders in these wedges are A-OK.
<!-- Author: Shulamit & Mark -->



<!-- Date: Wed Mar 15 16:53:10 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030>5 V enables are off.  Trip alarms are enabled.</td></tr></td></table>
<!-- Author: Mark -->



<!-- Date: Wed Mar 15 17:29:19 2006 -->
I am leaving the CCC in ISL in for now.
<!-- Author: Sebastian -->


<!-- Date: Wed Mar 15 18:09:22 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>CAEN 5V Enables ON</pre></td></tr></td></table>
<!-- Author: Ankush & Marcel  -->


<!-- Date: Wed Mar 15 18:11:02 2006 -->
<h3>Checking e0b1</h3> 
 
<p>As we have nothing better to do we are looking at e0b1.  This was labelled as a guinea pig sometime ago...so out of curiousity we are checking it out.</p> 
 
<p>ie:- Ulrich...sorry about the page</p>
<!-- Author: Ankush & Marcel  -->
<!-- Comment: Wed Mar 15 18;34;46 comment by...Ankush & Marcel  -->
<p>while debugging we were getting SRC errors from SV06 (ISL SRC).  It just so happens the clock delays for the ISL were adjusted to match the SVX clock.</p>

<!-- Comment: Wed Mar 15 19;20;23 comment by...Ankush & Marcel  -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>5V Enables are OFF and iFIX alarms unsilenced</pre></td></tr></td></table>

<!-- Comment: Wed Mar 15 19;31;16 comment by...Ankush & Marcel  -->
<p>e0b1 still looks like the bias line is still gone.  It failed to return any bias current when the ladder was biased.</p>

<!-- Comment: Wed Mar 15 21;53;51 comment by...sebastian -->
what SRC errors? doing what? I just checked it with svxdaq and it is fine... 

<!-- Comment: Wed Mar 15 23;26;17 comment by...Sebastian -->
I'm looking at the problems in the ISL crates (I power cycled the crates).

<!-- Comment: Wed Mar 15 23;51;42 comment by...Sebastian -->
<h3>Shit</h3>
If this "expert" would just remember to connect the damn cables again... I left the TS cable out. Not the best of nights. Everything is ok now.



<!-- Comment: Thu Mar 16 00;41;33 comment by...Sebastian -->
Ok, the vme bus errors are gone (coming from the VRBs) *but* there is something wrong with the CCC when running with RC (in our <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=290&frame=2&anchor=19:00:14'>
previous</a> test we only ran the system with svxdaq...). Note that right now the output from the CCC is different from SVX/ISL (it is what it was in tstsvx1). 


<!-- Date: Thu Mar 16 10:40:30 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8467&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8467  width='300' align='top'></a></td><td>This is a scatterplot of the southwest BLM instantaneous dose compared to the diamond current reading during a store.  The x-axis is in R/s and demonstrates the granularity of the BLM readout.  The y-axis is in counts.  We can (and will) use this to get a calibration for the VME electronics.</td></tr></table>
<!-- Author: Peter Dong -->


<!-- Date: Thu Mar 16 12:04:45 2006 -->
<h3>Scope to Clock Fan Out Disconnected</h3> 
 
<p>As part of the SRC Checkout tutorial and the GhostBuster acting a little strange I had to disconnect the CRO connected to the Clock Fan out to get to the Logic Analyzer (sorry Sebastian).</p> 
 
<p>The CRO + differential probes are in the Silicon office.</p>
<!-- Author: Ankush -->


<!-- Date: Thu Mar 16 15:32:27 2006 -->
<b>Status of FCC teststand:</b> we seated the VRB (and changed one of the board connectors) and the FFO. After that the system works. The PS module was also not all the way in. Now we can see the supply, but the ladders trip on Ovv as soon as we try turnning them on (and they draw no current). something may be wrong with this PS.
<!-- Author: Sasha/Sebastian -->


<!-- Date: Thu Mar 16 16:44:18 2006 -->
<pre>5V enables are ON</pre>
<!-- Author: sasha -->


<!-- Date: Thu Mar 16 17:37:34 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>5V enables are OFF</pre></td></tr></td></table>
<!-- Author: Jeannine -->


<!-- Date: Thu Mar 16 17:41:04 2006 -->
<pre>We checked SB0W11, SB2W0 and half of SB2W1: 
SB0W11 and SB2W0 are ok., SB2W1 is ok. except of e213. 
Tomorrow morning we will investigate this further.</pre>
<!-- Author: Jeannine, Sasha -->


<!-- Date: Thu Mar 16 18:27:43 2006 -->
we are messing with the CCC, will power cycle crates...
<!-- Author: sh/s -->


<!-- Date: Thu Mar 16 20:08:27 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8468&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8468' width='300'></a></center>
<!-- Author: Shulamit/Sebastian -->
<!-- Comment: Thu Mar 16 20;17;33 comment by...s/sh -->
The top trace is the clk signals in the CCC at b0svx02, the CCC delay register is set to 1 (march 7th firmware). In this case the SRC/TS are out of sync and we get SRC/timeouts from SVX.
The second trace is the same but the delay in the CCC is now 0 (note that the output signals are to the left). In this case we ran with RC with no errors.
The last trace shows the CCC in ISL, again with a delay of 0 and no  errors.<br>
Note that the incoming signals to the two SRCs are different (<b>we changed back the delay in the ISL CLKFO</b>). We now have to test the CCC again with ladders. 


<!-- Date: Fri Mar 17 08:39:42 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>5V enables are ON</pre></td></tr></td></table>
<!-- Author: Jeannine -->


<!-- Date: Fri Mar 17 09:51:21 2006 -->
<center><a href='/elog/notebooks/silicon/Fri_Mar_17_2006_095014.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8470' ></a><a href='/elog/notebooks/silicon/Fri_Mar_17_2006_095046.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8472' ></a></center>
<!-- Author: Sasha, Jeannine -->
<!-- Comment: Fri Mar 17 10;01;59 comment by...Sasha, Jeannine -->
<pre>We found in svxdaq (consistent with PDB), that chip a3 of e213 gives illegal channel errors (bit 5 low) in the NN mode (not in RA mode).

We tried to get rid of these errors by increasing the threshold to PED+9 in the RA mode, while all other chips were running in NN mode.

The PED for a3 was determind from the two above plots to be 62, leading to a threshold valueu of 71.

This try was successfull and we did not get any errors after these modifications.
e213 a3 is a candidate for running in dps off mode with threshold raised to 71 during regular data taking.</pre>

<!-- Comment: Fri Mar 17 10;21;07 comment by...sasha -->
<pre>oops... I guess we screwed up in this test. We forgot to put a3 in NN mode while running with increased threshold and DPS off. It turns out that the errors are still there if we do it properly.</pre>
<!-- Date: Fri Mar 17 10:08:12 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W1L3 
<li>problem n: 65 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: 'Bit5 low' problem is intermitent. It only occurs on chip a3 with very low rate of errors (<1%). It's very likely to have no connection to light levels at all. The other interesting fact is that the errors are only present in NN mode but not in RA. So, if we raise the threshold on a3 to 71=62+9 and run this chip in RA, then we don't see any errors  <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=292&frame=2&anchor=09:51:21'> see e-log</a>. This is a candidate for DPS off running.    
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W1&layer=L3">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Fri Mar 17 11:43:33 2006 -->
<h3>Saturday's Power Outage: The Plan</h3> 
 
 
<h4>Friday 17 March</h4> 
 
<table border="1">  
<tr> 
<td>13:00</td>  
<td>Cool down SVX to -10C<br> 
    Warm up ISL to +13C<br> 
</td>    
<td>Jennifer + Ulrich</td> 
</tr> 
 
<tr> 
<td>17:00</td> 
<td>Shut down Silicon PC in Control Room & Silicon office<br> 
    Shut down Silicon DAQ Racks on second floor</td> 
<td>Ankush </td> 
</tr> 
 
</table> 
 
<h4>Saturday 18 March</h4> 
 
<table border="1"> 
 
<tr> 
<td>06:30</td> 
<td>Shutdown Coffee machine :-)</td> 
<td>Ulrich</td> 
</tr> 
 
<tr> 
<td>07:00 or whenever power outage starts</td> 
<td>Check backup pump, vacuum pumps<br> 
    re-establish flows</td> 
<td>Ulrich</td> 
</tr> 
 
<tr> 
<td>During the power-outage</td> 
<td>regular checks of temperature, flows, pressure<br> 
    Ulrich,Ankush and Mark should be paged 30 mins before power  
    is returned</td> 
<td>Ulrich + Jennifer</td> 
</tr> 
 
<tr > 
<td rowspan="2">Power returns</td> 
<td>(manually) switch back to normal</br> 
    Cool SVX to -6C and ISL to +10C</td> 
<td>Ulrich + Jennifer</td> 
</tr> 
 
<tr> 
<td>Power up Silicon PCs & Silicon DAQ racks</td> 
<td>Ankush + Mark</td> 
</tr> 
 
<tr> 
<td>Once Silicon detector is cold</td> 
<td>Power up some ladders and check they run</td> 
<td>Ankush + Mark</td> 
<tr> 
 
</table> 
 
  
<!-- Author: Ankush -->


<!-- Date: Fri Mar 17 11:47:15 2006 -->
<pre>PDB review summary for Thursday and Friday. 
 
For wedges SB0W11, SB2W0, SB2W1, SB2W2, all entries in PDB look reasonable. No new problems were found. Tried to re-include chips a0 & a1 for e224--- no success.</pre>
<!-- Author: Sasha, Jeannine -->


<!-- Date: Fri Mar 17 11:47:53 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>5V enables are Off.</pre></td></tr></td></table>
<!-- Author: sasha -->


<!-- Date: Fri Mar 17 15:07:36 2006 -->
<h3>Summary of St. Paddy's Day Cooling Work</h3> 
<b>The short version:</b> 
<ul><li>ISL setpoint moved to +13.0 deg C</li> 
<li>SVX setpoing moved to -10.0 deg C</li> 
<li>All problematic alarms have had their limits adjusted, and should be happy non-alarming alarms.</li></ul> 
<b>The long version:</b> 
<ul><li>ISL setpoint to +13.0 deg C: 
<ul><li>Problematic alarms include Chiller Inlet/Outlet and Chiller Evaporator temperatures. All these alarms were immediately silenced before changing the setpoing, and then we got to work. After changing the setpoint, we revisited the high warnings and alarms for these three troublemakers. *Note*: when traveling into the Silicon alarms summary page, those with just 1 low and 1 high alarm are backed up by the quadlogs. These can be changed by simply logging into iFix, clicking on the Silicon box on the right, and resetting it to whatever you want. Those with two on each side of the curent reading (low-low, low-high, high-low, high-high) must be changed through the iFix database.</li></ul></ul> 
So, alarms which were changed (via quadlog or iFix) are: 
<ul><li>ISL Chiller Outlet Temperature high alarm changed from 12 deg C to 15 deg C. (quadlog) </li> 
<li>ISL Chiller Inlet Temperature low-high alarm changed from 11 deg C to 14 deg C, high-high alarm changed from 12 deg C to 15 deg C. (iFIx)</li> 
<li>ISL Chiller Evaporator Temperature high alarm changed from 13 deg C to 16 deg C (quadlog)</li> 
<li>SVX BHE1 flow was altered, since the pressure on the bulkheads was getting a bit high as we cooled the SVX down. So, this limit changed from 75%→70%. Ulrich has just informed me that some other flows and pressures were a bit unhappy; we will keep an eye on these. There will be an addendum following our next check-up.</li></ul> 

<!-- Author: Jennifer :-) & Ulrich -->
<!-- Comment: Fri Mar 17 16;18;37 comment by...Jennifer :-) & Ulrich -->
<p><h3>Addendum to SVX Flows</h3>
<p>
<ul><li>BHE1: changed from 70%&rarr;68%</li>
<li>BHE2: changed from 70%&rarr;65%</li>
<li>L00E: changed from 37%&rarr;33%</li>
<li>BHW1: changed from 80%&rarr;75%</li>
</ul>
So far, everything seems to be relatively happy with these changes; all flows and pressures are within the set limits.

<!-- Comment: Fri Mar 17 17;40;18 comment by...Jennifer :-) -->
<pre>BH1E changed to 74%, as pressures are behaving themselves to give more flow.</pre>
<!-- Comment: Fri Mar 31 09;24;15 comment by...Ulrich -->
Note that the above mentioning of the Quadlog interlock system is not correct. Whereever we wrote "Quadlog", we mean readings which go to the cryo alarm summary page.
<!-- Date: Fri Mar 17 15:12:27 2006 -->
<table border=0><td><tr><td bgcolor=#ff9999><h3>NO ladder work until after the Saturday Power Outage.</h3></td></tr></td></table>
<!-- Author: Jennifer :-), Ulrich, & Ankush -->


<!-- Date: Fri Mar 17 15:47:37 2006 -->
<table border=0><td><tr><td bgcolor=#ff0000> 
<font  color=#FFFF03 > 
<h1> Keep in mind </h1> 
<b> 
<ul> 
<li>b0sili01/02 will be turned off at 16:45. This means no web pages, no bitreporter, no Problem Database, no other useful toys </li> 
<li>b0dasvx01-03 will be turned off as well, no PSGUI, no IMON, also no logging by the DS tools and a lot of warning emails.</li> 
</ul> 
Hopefully everyone survives the next 24 hours without those machines. 
</b> 
</font> 
</td></tr></td></table>
<!-- Author: An oldtimer -->
<!-- Comment: Fri Mar 17 16;13;11 comment by...Lady in Pink :-) -->
<pre>Ok, Marcel. We get the idea.</pre>



<!-- Date: Fri Mar 17 16:24:26 2006 -->
<h3>Super Good News!</h3> 
20 adorable pt100 temperature sensors have arrived! Yippee! Still waiting for the relative humidity sensors, but given that these arrived 2 whole weeks BEFORE we planned, this is excellent. 
<p> 
<b>"Awesome".</b>
<!-- Author: Jennifer :-) -->



<!-- Date: Fri Mar 17 18:09:42 2006 -->
<h3>All Silicon OFF (except cooling)</h3> 
 
<p>In preparation for the 8 hour power outage all the Silicon DAQ racks on the first floor have been turned OFF and all the Silicon PCs are now OFF.</p> 
 
<p>The FIB racks in the collision hall are still on, I&#39ll let them just trip off.</p> 
 
<p>So the only thing operating in Silicon land is the cooling.</p>  
<!-- Author: Ankush -->
<!-- Comment: Fri Mar 17 18;15;41 comment by...Ankush, Mark & Marcel -->
<h4>....and we did some DAQ work with the crates off</h4>

<p>for the CDF-DAQ upgrades we removed all the RESET cards from all the SVX** crates.  Then Bill Badget (with Marcel, Mark and I as witnesses) removed the 6U->9U adapter cards from SVX00, SVX01, SVX02, SVX03, SVX05 and SVX07. ie: all the crates except the SRC crates and SVX08.  The removed transition cards were swapped with  "normal" adaptor cards. Our adaptor cards had a kludge to allow a crate reset. The remaining adaptor cards will be removed after the power outage....assuming we survive the power outage....</p>


<!-- Date: Sat Mar 18 15:29:27 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><h3>Power has returned</h3></td></tr></td></table>
<!-- Author: Ankush et al -->


<!-- Date: Sat Mar 18 17:40:07 2006 -->
<h2>Cooling during the power outage</h2> 
6:15 
<ul> 
  <li>PLC program copied to SVXIICON desktop</li> 
  <li>Found <tt>alarms.exe</tt> crashed on "http exception". My guess: 
      it could not send mail via <tt>b0sili01</tt>, and I did not catch the 
      exception properly (e.g. by sending a mail like "process died"). 
      So we were flying blind on the alpha-numeric pager. 
      The auto-dialer was of course still active.</li> 
  <li>The process <tt>PSMon.exe</tt> could not subscribe to the RT server</li> 
</ul> 
 
<p> 
6:30 
<ul> 
  <li>Coffee maker hooked up to backup power (thanks to Thomas Becher from the 
  Fermilab theory group for making that suggestion!)</li> 
  <li>To avoid spurious trips during the warmup: raised &uuml;bertrip limits for 
  SVX bulkheads (2C&rarr;12C) and L00 silicon & hybrids (1C&rarr;11C). 
      The procedure: change settable limit &mdash; download &mdash; set A/W limits. 
  </li> 
</ul> 
 
<p> 
10:20 
<p> 
Another empirical proof of Murphy's law: 
<ul> 
  <li>The main power went off around 7:10. 
      After a couple of seconds, the generators kicked 
      in again. At that time, I lost all iFix readings. After 30 minutes flying blind, 
      I realized that the little network switch for the PLC intercrate communication 
      was not hooked up on a circuit which was on backup power. I plugged it into 
      a circuit which is on generator power. 
      It will stay there for the future.</li> 
  <li>The ISL backup pump kicked in automatically, but the ISL flow was 0. 
      Dean and I found that the manual valve in the backup pump loop was 
      closed and the pump was cavitating. We opened the valve, and the ISL 
      flow was re-established. The flow was a bit on the low side. This is expected 
      because the capacity of the backup pump is smaller than the main pump's. 
      Note that I closed the manual bypass valves on both the SVX and ISL chiller 
      to direct maximum flow to the detector. 
  </li> 
  <li>The ISL vacuum pumps tripped. Recovered by clicking "Request Vacuum"</li> 
  <li>The control box of the secondary SVX vacuum pump started to act funny. 
      It would switch the pump and a pneumatic valve on the chiller on and off 
      regularly. I found the pump running on "manual" in iFix. I switched it back to 
      "auto", and everything was fine.</li> 
  <li>The main problem of the day: the SVX backup pump kicked in, ran for 5 minutes 
      and tripped. It took 10 minutes to recover (overheated?). We tried to switch to the 
      backup pump of the spare chiller, which showed the same problem. Note: nobody 
      around here was able to do the chiller swap, and the documentation was incomplete. 
      We have to improve on documentation and training! When we switched back to 
      the regular SVX chiller, Dean noticed that actually both pumps were working at the 
      same time. Apparently, the control box switches a couple of power outlets, 
      to which the pumps are connected. Both the SVX and the spare chiller were 
      connected to the same circuit, and the control box could not handle both 
      at the same time. I unplugged the spare chiller pump, and we are good for now! 
      </li> 
    </ul> 
<p> 
15:10 
    <ul> 
      <li><b>Let there be light!</b> ISL came back up from its backup pump automatically; 
      our infamous "Hit me, Baby" ISL flow meter needed another good wacking after a short 
      power glitch when switching back from generator power (Yes, this *will* 
      be fixed). SVX, however, was still on "manual" mode, and needed to be 
      switched (<i>manually</i>) back to automatic. This is done by switching the 
      power box back to the automatic setting.</li> 
      <li> 
      At the end of the power outage, there were 10 minutes, during which there was no 
      power at all (the electricians checked the transfer switch between the regular power 
      and the generator power. During this time, we 
      switched the fan pack of the PLC to a power outlet which was backed up on UPS. 
      This was just a precautionary measure.</li> 
    </ul> 
<p> 
16:00 
<p> 
    <ul> 
      <li>Power came back on rather gracefully from the Cooling's point of view. 
      SVX, L00, ISL all showed trips, and we had to reestablish flow. After acknowledging 
      the trips, flow to ISL came back easily. SVX and L00 seemed to have lost communication, and 
      were showing weird "????"s in the SVX "Flow Monitor" page. This was troublesome, and we 
      checked the network cabling behind the svxiicon PC. It was not giving the "I'm working!" 
      blink, and so we reset it (by unplugging and plugging back in) and the mysterious 
      SVX "????"s went away. Ulrich mentioned that this was a similar problem as he had 
      seen earlier in the day, when the switch was hooked up to a circuit which was not on 
      generator power.</li> 
      <li>Pressures then seemed a bit low as ISL settled down; Ulrich 
      went downstairs and opened up the ISL manual supply valve a bit more. Flows and pressures 
      seem to be good for the moment.</li> 
      <li>One last thing to accomplish is making sure that all of our limits were the same as 
      before we shut down power. It seems like SVX PCs are a bit cold at the moment, and this 
      is our current cooling project &mdash; 
      Eureka! On the "Trip Limits" page in iFix, when setting 
      the trip limits (by clicking the "Set A/W limtis"), it's 
      important to know that these lower limits are derived from the remote setpoint 
      of the ISL chiller. This is true for the PCs which seemed to be on the low side of their 
      defined temperature limits (limits defined on the wrong ISL setpoint of 10&deg;). 
      Well, when you're messing around with the chiller, expect 
      to get the corresponding limits! To solve this problem, set the remote setpoint for the 
      chiller as per normal running conditions (-6&deg;C), <i>then</i> download the limits, 
      and then reset the setpoint for the chiller. Good to know. Cooling work and iFix 
      debugging concludes at about 17:00.</li> 
</ul> 
Thanks to everybody who helped us out today: Steve and Rick, Bill, Dean, Jim, and Steve, Ankush, ...
<!-- Author: Jennifer :-) & Ulrich -->


<!-- Date: Sat Mar 18 18:04:40 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8473&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8473' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8475&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8475' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8476&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8476' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8477&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8477' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8478&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8478' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8479&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8479' width='300'></a></center>
<!-- Author: Jennifer :-) & Ulrich -->
<!-- Comment: Sat Mar 18 18;06;57 comment by...Jennifer :-) & Ulrich -->
A selection of SVX temperatures during the power outage.
<!-- Date: Sat Mar 18 18:06:14 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8480&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8480' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8481&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8481' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8482&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8482' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8483&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8483' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8484&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8484' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8485&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8485' width='300'></a></center>
<!-- Author: Jennifer :-) & Ulrich -->
<!-- Comment: Sat Mar 18 18;07;31 comment by...Jennifer :-) & Ulrich -->
A selection of ISL temperatures during the power outage.


<!-- Date: Sat Mar 18 20:16:27 2006 -->
<h3>Silicon Power Outage Recovery</h3> 
 
<p>The FIB, VRB & SRC are up along with CAEN Crates and cooling.  However we have come across some unforeseen software problems. 
 
<ul> 
<li>cratematch.pl has some problems.  It doesn&#39t start the spy process automatically. We had to start them manually.</li> 
<li>The PS-GUI claims the interlocks are not enabled. This was traced to a problem with the smartsockets from svxinter to the PS-GUI.  For some reason the SVXINTER is not interpretting the smartsokets correctly.</li> 
</ul> 
</p> 
 
<p>One important thing to remember about recovering the DAQ racks after a power cycle.  You intialise all the boards.  This is done from SVXDAQ by doing the following: 
 
<pre> 
File 
  | 
   -> Preferences | 
                   -> check the box of init boards 
</pre>
<!-- Author: Ankush, Mark & Marcel -->
<!-- Comment: Sat Mar 18 20;18;08 comment by...Ankush, Mark & Marcel -->
<table border=0><td><tr><td bgcolor=#e0e030>Until further notice do NOT use Silicon system until the above mentioned software problems have been fixed.</td></tr></td></table>

<!-- Comment: Sun Mar 19 10;02;57 comment by...Sebastian -->
I am taking a look. The connection through smartso looks fine now (I think related with authentication problems last night). Ulrich, if you got a page that was me, sorry.

<!-- Comment: Sun Mar 19 10;31;13 comment by...s -->
I can not get the handshake to work. 


<!-- Date: Mon Mar 20 00:05:41 2006 -->
<h3>Week 3 Shutdown Summary</h3> 
 
<h4>Problem Database Review</h4> 
 
<p>Wedges Studied: SB0W6 to SB0W11, SB1W1 - SB1W3, SB1W6-SB1W10, SB0W11-SB2W2</p> 
 
<p>SB0W6L0 and SB0W8L4 were put back in.  Should be investigated more closely to see if we really want these ladders back.</p> 
 
<p>SB0W10L1 was put back in. Need to check if it can be biased.</p> 
 
<p>SB0W11L1 was put back in to see if it could be biased.  Turned the ladder on and it drew no current. Should double-check with by powering off a neighbouring supply that this is not a read back problem.</p> 
 
<p>SB1W3L0 was put back in.  Claims was it did not see physics.  Need to recheck this is true.</p> 
 
<p>SB1W8L2 : Z side was included in SVXDAQ.  Consider putting in for data-taking.</p> 
 
<h4>TEV ABORT!!</h4> 
 
<p>To my surprise the SVX Rad Abort fired this week. The problem was traced to unannounced power cut of the B0 house. But it turns out they are being advertised on the Tev Beam Status Page (Channel 13(?)).</p> 
 
<h4>CCC Work</h4> 
 
<p>CCC installed into SVX06 (ISL SRC Crate).</p> 
 
<p>CLock Fan out delays were all adjusted to match the SVX clock timings.</p> 
 
<p><b>Always remember to plug in the TS cable for the SRC.</b></p> 
 
<h4>FCC Teststand</h4> 
 
<p>The FCC teststand is not completely working.  The DAQ problems were resolved by reseating the VRB and FFO cards.  But the ladders/hybrids cannot be powered. Need to check power supply and its connections.</p> 
 
 
<h4>Power Outage</h4> 
 
<p>The day before ISL was warmed upto +13C and SVX was cooled to -10C.  All the Silicon PCs and Silicon DAQ racks were switched off.</p> 
 
<p>When the power was turned off the backup pump could only run for 10 minutes and trip off.  It was later shown that the backup pumps for SVX & the Backup chiller were connected to the same circuit.  The backup chiller pump was disconnected.</p> 
 
<p>When power retuned, the chiller came back and ISL & SVX were cooled back to their shutdown temperatures.</p> 
 
<p>The Silicon PCs came back.  b0dasvx01,02,03 had problems coming up. All the NFS mounted directories had to be remounted manually for all 3 machines.  The DAQ crates came back once we learnt the important lesson: enable <b>init boards</b> whenever an SRC is powercycled. The DAQ could be partitioned in 
RUN-CONTROL and was forced through CONFIG.  Other DAQ checks suggest it&#39s OK.</p> 
 
<p>However we still had two problems.  cratematch.pl would not start the spy-processes automatically.  They were restarted manually.  Also SVXINTER seems to be having a smartsockets problem.  The result is PS-GUI claims the interlocks are not enabled and ladders cannot be turned on as they fail the FIB 
handshake.  Both need to be resolved.</p> 
 
<h4>Misc</h4> 
 
<p>Diamonds passed their internal readiness review!!</p> 
 
<p>ISL Conductivity was changed to fix the rise in conductivity.  But after the resin exchange the conductivity started rising faster. Eventually this was traced to a cap which hadn&#39t been removed.</p> 
 
<p>New spare FF0 from Yale arrived and tested OK.</p> 
 
<p>The bias-checker script is availabe from the web at: 
<a href=" http://www-cdfonline.fnal.gov/cgi/internal/ops/svxii/svxbiascheck.pl"> 
http://www-cdfonline.fnal.gov/~svxii/cgi-bin/svxbiascheck.pl</a></p> 
 
<p>3.3V added to SRC crates.  This is needed for the new CCC.</p> 
 
<p>pt100 sensors have arrived.</p> 
 
<p>The special 6U-9U adapter cards for all the Silicon racks except SVX04, SVX06 & SVX08 were swapped with ordinary ones.  Eventually all will have to be replaced as 
they are required for the CDF VRB upgrade.</p> 
 
<p>We have all the speakers for the Silicon Workshop :-)</p> 
 
<h4>Things for next week</h4> 
 
<p>Fix residual problems from power-outage: SmartSockets problem</p> 
 
<p>Continue with the Problem DB review</p> 
 
<p>Get Test Stand Running.</p> 
 
<p>Get BE Kludge Fixed</p> 
 
<p>Chiller Maintenence: Replacement of ISL Flow Meter & air filter.</p> 
 
<p>Have hardcopies of <b>all</b> emergency procedures in the Silicon Office.</p> 
 
<p>VRB Load Balancing??</p> 
 
<p>Prepare for the <em>Month of Bore</em></p>  
<!-- Author: Ankush -->