<!-- Title: 10:34:58  Mon Nov 21 2005 -->
<!-- Crewchief: Ulrich (MPC) -->
<!-- Op1: Sebastian (SPL) -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<i>Fortiter in re, suaviter in modo</i><br> 
(Claudio Acquaviva)


<!-- Date: Mon Nov 21 13:34:08 2005 -->
<h3>Marcel called...</h3> 
... to check if the silicon is still alive, and that 
<ul> 
<li>he's at the beach at 28C</li> 
<li>he bought a Hawaiian shirt and is working on his mustache</li> 
<li>he rather wants to stay where he is</li> 
<li>he says hi to everybody</li> 
</ul>
<!-- Author: Ulrich and Ankush -->
<!-- Comment: Mon Nov 21 19;25;38 comment by...yuri -->
<pre>extra sensory perception...</pre>
<!-- Date: Mon Nov 21 16:17:45 2005 -->
<h3>BIG QUENCH!!!!!</h3> 
 
<p>You could hear it from the silicon office.</p> 
<p>RAD alarm tripped...but no trips or pinkies in IMON</p>
<!-- Author: Ankush/Ulrich -->
<!-- Comment: Mon Nov 21 16;20;31 comment by...Ankush et al -->
<p>B11-H Separator Spark.  The same one from last week!!</p>

<!-- Comment: Mon Nov 21 16;36;26 comment by...ucsb -->
<pre>We heard it over in trailer 327 also.</pre>


<!-- Comment: Mon Nov 21 16;40;09 comment by...sparky the sparker -->
<h1>BOOOOOOM!!!!</h1>
<!-- Comment: Mon Nov 21 16;42;16 comment by...Ankush -->
<p>We got ~160 Rad/s in all 4 BLMs.  We did a COLDSTART...no problems....we biased the detector and it looks like we blew all the L00 crowbars (except LB0W5L3...goo old chap !!)</p>
<!-- Comment: Mon Nov 21 17;04;39 comment by...R -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2005&action=view&page=-21295&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2005&action=view&page=-21295 width='300' align='top'></a></td><td> </td></tr></table>
A plot here is must.
<!-- Comment: Mon Nov 21 17;13;44 comment by...Ankush -->
<pre>Thanks R...you beat us by a nano-second. </pre>
<!-- Comment: Mon Nov 21 17;17;10 comment by...Ulrich -->
<br>
The quench was big, but not too big: all four BLMs were above the abort limit, but none of them was saturated. The dose from the quench was between 120 and 140 rads.
<!-- Date: Mon Nov 21 16:38:07 2005 -->
<pre>David Stuart's current checker indicates possible crowbar failure: 
 
LB1W1 L3bias1 has V=2 and I=0</pre>
<!-- Author: boveia -->
<!-- Comment: Mon Nov 21 16;43;12 comment by...Ankush & Jen -->
<pre>...err...no...

actual crowbar blown to smithereens....darn it!!</pre>



<!-- Comment: Mon Nov 21 20;09;40 comment by...boveia -->
<pre>For completeness:

LB0W0 L3bias1 has V=135 and I=0
LB0W1 L3bias1 has V=120 and I=0
LB0W3 L3bias1 has V=119 and I=0
LB0W4 L3bias1 has V=138 and I=0
LB1W0 L3bias1 has V=134 and I=0
LB1W1 L3bias1 has V=135 and I=0
LB1W2 L3bias1 has V=135 and I=0
LB1W4 L3bias1 has V=120 and I=0
LB1W5 L3bias1 has V=135 and I=0
</pre>
<!-- Date: Mon Nov 21 17:10:21 2005 -->
<h2>L00 Crowbar List</h2> 
Two L00 Crowbars appear to have survived intact: LB0W2 and LB0W5 (this one is cabled to an SVX supply instead of L00 supply; coincidence?).  Every other crowbar has definitely blown L3 VBIAS1. 
<ul> 
<li> LB0W0: L3 VBIAS1, L0 possible (always 0 current) 
<li> LB0W1: L3 VBIAS1 
<li> LB0W2: all ok 
<li> LB0W3: L3 VBIAS1 
<li> LB0W4: L3 VBIAS1 
<li> LB0W5: all ok 
<li> LB1W0: L3 VBIAS1 
<li> LB1W1: L3 VBIAS1 
<li> LB1W2: L3 VBIAS1 
<li> LB1W3: L3 VBIAS1, L3 possible (always 0 current) 
<li> LB1W4: L3 VBIAS1 
<li> LB1W5: L3 VBIAS1 
</ul> 
 
There are a couple L3 ladders showing some funny behavior (LB0W2L3 and LB1W0L4, plots to follow).  They have current, but the current is slowly ramping up to the value it should be at.<br> 
Made an access request for the crowbars; I'll go check that we have enough spares...<br>
<!-- Author: Jen -->
<!-- Comment: Mon Nov 21 20;08;42 comment by...boveia -->
Just to be clear:  you've checked L0-L2, and L3 bias0, and found no blown crowbars?
<!-- Comment: Mon Nov 21 20;12;27 comment by...boveia -->
If that is the case, why all (almost all) bias1 and no bias0?

<!-- Date: Mon Nov 21 17:15:47 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7929&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7930' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7931&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7932' ></a></center>
<!-- Author: Jen -->
<!-- Comment: Mon Nov 21 17;16;57 comment by...Jen -->
<pre>To the left: clear indication of a blown crowbar.  To the right: funny behavior of the IB0W2L3 current.</pre>


<!-- Comment: Mon Nov 21 18;05;31 comment by...Jen -->
<pre>Whoops, that's LB0W2L3, not I.  I checked the crowbars: of the 11 
spares, 3 of them were blown in July and never were turned in to 
fix.  I'll take those by FCC tomorrow before 8am; we'll replace the
other 8 crowbars first thing tomorrow morning.</pre>


<!-- Date: Mon Nov 21 18:08:45 2005 -->
<br> 
Some entries from the AD run coordinator e-log: 
<pre> 
The store was lost due to a severe beam-induced quench, possibly due to a B11H separator spark. The B1 house was hit extremely hard and cryostat vacuum appears to have been completely lost. Early indications are that B1 is broken and would require a lengthy (two week) repair. Vacuum experts are coming in to make a tunnel access and make the diagnosis. - J. Morgan 
</pre> 
<pre> 
The report from the tunnel confirms that B1 is broken, there is super-insulation sticking out of the B17-1A spool and B17-1B bypass (a bad thing). Cryo and vacuum experts will be beginning the warm-up process in the next few hours, it will probably be early evening on Thanksgiving before the house is warmed up. - J. Morgan 
</pre> 
Here is also the MCR e-log: 
<pre> 
 The quenched houses are A4, B1, B3, C4, D1, E1, F4, all of the low beta houses with the exception of DC. - Elisa 
-- Mon Nov 21 16:33:13 comment by...Elisa --  All have been archived with title, "Store 4515 LB Quench." 
</pre> 
<pre> 
The word from the tunnel: There is superinsulation sticking out the blowoff plates on the B17 spool piece and at the downstream end of the 40' B17 bypass. We have asked Jerry Makara to begin the warmup of B1. Dave Augustine will call back with serial numbers so people can begin looking for spares. 
</pre> 
So it was a severe 7-house quench. They have to warm up B1 for the repair, causing some significant downtime.
<!-- Author: Ulrich H. -->
<!-- Comment: Mon Nov 21 19;30;12 comment by...zero counter -->
<pre>Also, from the CDF e-log:
"Fire trucks responded to D0 but cause may be a dump of a lot of helium and not smoke."</pre>
<!-- Date: Mon Nov 21 18:52:06 2005 -->
To run cosmics with silicon: run configuration: cosmics_silicon_tape (check that  trigger table is COSMICS[15,730,598]).
<!-- Author: Sebastian -->


<!-- Date: Mon Nov 21 19:07:37 2005 -->
<h4>The Silicon Plan</h4> 
 
<p>This is the plan for tomorrow to check out the detector:</p> 
 
<em><p>0: A preliminary overnight Cosmics silicon run.  A quick check which may highlight any problem ladders</p> 
<p> -----> This is only tentative</p></em> 
 
<ol> 
<li><p>Replace the L00 crowbars</p></li> 
<li><p>Bias SVX+ISL : Go through the history plots in IMON for every ladder to check they are drawing current.(We already did L00)</p> 
<li><p>Wedge-by-Wedge check out with SVXDAQ of every ladder in L00+ISL+SVX.</p></li>    
<li><p>Cosmics Silicon run: Look at SVXMON + ADCMON : checks chips are reading out and ladders are biased.</p></li> 
</ol> 
  
NB:- If we discover problems along the way, the plan will change.  
<!-- Author: Ankush -->




<!-- Date: Mon Nov 21 19:40:25 2005 -->
<h4>Part 2 of The Plan completed</h4> 
 
<p>A heroic effort by Ulrich & Sahsa.  They checked every ladder was drawing current while biased.  All of the SVX ladders drew bias currents.  Some ISL ladders were drawing zero current BUT they are known problem ladders.</p> 
 
<p>So it appears ISL + SVX bias lines are OK.</p>
<!-- Author: Ankush for Sasha and Ulrich -->





<!-- Date: Mon Nov 21 21:47:34 2005 -->
<b>Silicon cosmics run 207553</b>. Using run confg COSMICS_SILICON_TAPE (COT set to ignore inhibit, with permission). Consumers were running.
<!-- Author: Sebastian -->


<!-- Date: Mon Nov 21 22:12:31 2005 -->
<br> 
I quickly checked over all L00 ladders in the online ADCMon for bias problems.  The picture is complicated by 1) the lower occupancy in cosmics data somewhat mimics loss of bias 2) the online ADCMon doesn't apply the Chebychev pedestal subtraction that offline ADCMon applies.  Still, my quick check verified that there are many L00 ladders unbiased. Many if not all of the ladders that are drawing zero bias current also show no physics tail.  There are also several others that look to be unbiased, but because of 1) and 2) I want to wait until the data is processed by offline ADCMon to be sure.  In the meantime, it's always been a good idea to check all crowbars in the next access.
<!-- Author: boveia -->


<!-- Date: Mon Nov 21 22:17:12 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7933&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7933' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7934&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7934' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7935&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7935' width='300'></a></center>
<!-- Author: boveia -->
<!-- Comment: Mon Nov 21 22;20;34 comment by...boveia -->
<pre>Online ADCMon example - e803, chips 0-2.  Ignore the blue reference, which has the wrong normalization with so few events accumulated.</pre>

<!-- Comment: Mon Nov 21 22;21;02 comment by...boveia -->
<pre>err.. f803</pre>


<!-- Date: Mon Nov 21 22:23:43 2005 -->
Some work on these two: 
<ul> 
<li> <b>CCC:</b> with the AMP cables ready (still two missing) the 
first test of the CCC were done today/ Bill found problems 
in his firmware inmediatelly, but does not look that bad... 
Expect to try again this week. 
<li> <b>GB:</b> Taka added a register of the RDBS length, but upon 
testing something was wrong  - the pointer register, 0xc0 (for 
chip 0) kept increasing even  when in halt. Probably related to  
high signal in GBIN for channels were there is no FFO connected... 
</ul>  
<!-- Author: Sebastian -->


<!-- Date: Mon Nov 21 22:23:57 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7936&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7936' width='300'></a></center>
<!-- Author: boveia -->
<!-- Comment: Mon Nov 21 22;25;21 comment by...boveia -->
<pre>comparison with a "good" ladder - one chip from f823, reported above as drawing bias current.</pre>

<!-- Date: Tue Nov 22 08:42:51 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W11L2 
<li>problem n: 1573 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Incident
<li>entered by: amitra 
<li>description is: <p>After the Mega-Quench.  This ladder is now giving 00 sequence errors and CAP-ID.  Needs to be studied further.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W11&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Nov 22 08:48:44 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W2L2 
<li>problem n: 1575 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Incident
<li>entered by: amitra 
<li>description is: <p>After the mega-quench, this ladder gives c2c2 for the first 2 events in SVXDAQ.  Not sure if this is significant.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W2&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Nov 22 08:48:44 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W2L2 
<li>problem n: 1574 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Incident
<li>entered by: amitra 
<li>description is: <p>After the mega-quench, this ladder gives c2c2 for the first 2 events in SVXDAQ.  Not sure if this is significant.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W2&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Nov 22 09:20:10 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W6L3 
<li>problem n: 1576 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Incident
<li>entered by: amitra 
<li>description is: <p>After mega-quench, this ladder now has 00 sequence, truncate, and illegal channel errors in SVXDAQ> </p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W6&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Nov 22 09:52:12 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W0L1 
<li>problem n: 1577 
<li>Status: needs_work
<li>Type: Unknown
<li>Action: Incident
<li>entered by: amitra 
<li>description is: <p>After Mega-qunech this ladder is now giving 00 Sequence, CAP-ID and trancate errors.</p> 
<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: Tue Nov 22 11:20:42 2005 -->
<h3>SVX Wedge-by-Wedge Checkout complete</h3> 
 
<p>Ulrich and I have completed the wedge-by-wedge checkout of SVX with SVXDAQ.  There are 4 ladders which appear to have new problems.</p> 
 
<ul> 
<li>e0b2: 00 Sequence, CAP-ID errors</li> 
<li>e022: c2c2 for the first two events</li> 
<li>e063: 00 sequence errors, illegal channels and truncate errors.</li> 
<li>e301: 00 sequence errors, CAP-ID and truncate.</li> 
</ul> 
 
<p>I'm not entirely sure these were all induced by the quench.  But we should watch the progress of these ones with interest.</p>
<!-- Author: Ankush & Ulrich -->
<!-- Comment: Tue Nov 22 16;20;43 comment by...Antonio, Sasha -->
<h3>ISL/L00 Wedge-by-Wedge Checkout complete</h3>
Sasha and I checked out ISL and L00 with SVXDAQ.  There are two ladders in L00 which continue to trip on DVDD:
<ul>
<li>f823</li>
<li>f843</li>
</ul>
We spotted no other problems.
<!-- Comment: Wed Nov 23 14;10;43 comment by...Ankush & Ulrich -->
We have double-checked the problems with the SVX ladders today. They are reproducible. More details on the problems:
<ul>
<li>e0b2: The sequence errors come from all possible chips. We tried a VRB fiber swap, but something was wrong in the DAQ, so we postponed the test.</li>
<li>e063: 00 sequence error comes from chip 8. We have tried to change the Rdriver value from 2 to 4, without success.</li>
<li>e301: 00 sequence error comes from chip 0 or 1.</li>
</ul>
We will have more quiet time to study these problems next week.
<!-- Date: Tue Nov 22 11:46:45 2005 -->
<h2>L00 Crowbars Replaced</h2> 
 
<p>A monumentous effort by Ulrich and Jen.  They went in and replaced all L00 crowbars in just over an hour!!!!!!!!</p> 
 
<p>L00 is currently biased. No pinkies or yellows in IMON.  Looking at the history of all ladders, they are now all drawing current.  So it looks good for L00 :-)</p>
<!-- Author: Ankush for Jen & Ulrich -->
<!-- Comment: Tue Nov 22 12;15;51 comment by...Jen et al -->
For the crowbars:  all 10 of the ones listed <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=276&frame=2&anchor=17:10:21'>here</a>
were indeed blown on L3 VBIAS1.  All other channels were fine.  We also checked the 2 crowbars that should up ok, just to make sure, and they were indeed fine.<br>
<!-- Date: Tue Nov 22 11:48:21 2005 -->
<h3>Power shutdown next week</h3> 
 
Starting next Tuesday (Nov 29th) the power to the coll hall and the fisrt floor racks will be cut off for two days. Also all of B0 will be powered down for about an hour Tuesday starting at 8am. The plan is to finish the check out, check the L00 ladders with new crowbars (Jen and Ulrich are replacing crowbars now) and possible take cosmics again. There will be no access during the long weekend period (unless urgent matter) .Early Tuesday we should bring everything down. 
Also Stefano proposed to swap chillers while everything is off.<br>
<!-- Author: Sebastian -->
<!-- Comment: Tue Nov 22 14;52;56 comment by...Ankush -->
<p>This will be one complete thermal cycle (-10C -> Room Temperature -> -10C). Previous experience has shown this can be troublesome. As a precaution we should do another detector checkout.</p>


<ul>
<li>Do COLDSTART...checks Chips are OK</li>
<li>Bias the detector and check sensors draw current ....checks sensors can be biased</li>
<li>Do a COSMICS silicon run....check the whole system is working</li>
</ul>
<!-- Comment: Tue Nov 22 15;49;03 comment by...sebastian -->
Latest from Willis:
<pre>
Tuesday: 29Nov05 *****Note the power outages******

  We will have power outage starting at 8:00am in B0 to install a breaker
  circuit for generator power for 3rd floor UPS: this will last about 1
  hour. Stephan Lammel will also do power reconfiguration of the 3rd floor
  systems to hook into the new UPS and other computer rack relocations.

  We will also have some power off to portions of the 3rd floor to install
  four 30amp breakers for Level-3 racks.

  Electricians will start work on 1st floor to power Level-3 rack. There
  will be no power in the 1st floor (Tuesday only) when the electricians
  are working on the power panel/circuit breaker.

</pre>
<!-- Date: Tue Nov 22 13:56:10 2005 -->
<h4>Movement of South Wall and South CMX Arches</h4> 
 
<p>The XFT people will be moving the South Wall and South CMX arches tomorrow (Wednesday).  I said it was OK as we had done our crow bar replacments.</p> 
 
<p>...and as a furher heads-up, the XFT will be moving all arches next week.</p>
<!-- Author: Ankush -->


<!-- Date: Tue Nov 22 14:11:42 2005 -->
I got paged because of a trip of SVX B3W10L4 (DVDD overcurrent). The ace tried to recover the ladder, in the course of which he accidentally switched off the full bulkhead. Also, because the silicon was not included in the DAQ partition, and he was not aware of the silicon coldstart option, the chips did not get configured. When Ankush and I arrived, Sebastian had already taken over. He switched the bulkhead back on, but SVX B3W10L4 started tripping on AVDD overcurrent.  
<p> 
Sebastian remembered that this ladder requires some rest and the right temperature to be switched on again. Earlier silicon e-log entries can be found on <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=260&frame=2&anchor=08:21:17'> 
August 4, 2005</a>, and on <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=264&frame=2&anchor=06:36:42'> 
September 1, 2005</a> and the following days.
<!-- Author: Ankush, Sebastian, and Ulrich -->
<!-- Comment: Fri Nov 25 19;32;51 comment by...sebastian -->
This is how things happened:
<pre>
Tue Nov 22 11:55:14 CST 2005     success: Channel0 SVX B4 W3 to STANDBY
Tue Nov 22 11:55:21 CST 2005     TRIP: SVX  B4  W3 DVDD0 OverCurrent
Tue Nov 22 11:56:05 CST 2005     success: Power Supply SVX B4 W3 OFF
Tue Nov 22 11:56:08 CST 2005     TRIP: SVX  B4  W3 DVDD1 OverCurrent
Tue Nov 22 11:56:17 CST 2005     success: Power Supply SVX B4 W3 to STANDBY
Tue Nov 22 13:01:46 CST 2005     TRIP: SVX  B3  W10 DVDD4 OverCurrent
Tue Nov 22 13:12:51 CST 2005     success: Resetting trips
Tue Nov 22 13:14:56 CST 2005     success: Power Supply SVX B3 W10 OFF
Tue Nov 22 13:15:21 CST 2005     ERROR: Power Supply SVX B3 W10 Handshake - Could not turn on power - checked 10 times
Tue Nov 22 13:15:28 CST 2005     TRIP: SVX  B3  W10 AVDD4 OverCurrent
Tue Nov 22 13:16:29 CST 2005     success: SVX Bulkhead 3 OFF
</pre>
So the ladder did trip before the ace turned off the bulkhead
(by mistake). Looking at the logs (to try to understand why it tripped in the first place), it looks like nobody was playing with this ladder at the moment (there seems to be no init request to this hdi and no psgui entry). The ps logs do not help. The imon plot (though not saved) did not show the trip either.<br> We may consider swapping PS supplies (but no urgency). 
<!-- Date: Tue Nov 22 16:03:17 2005 -->
<h4>CAEN Schematics Page</h4> 
 
<p>Are you wondering how the wonderful CAEN supplies work ?</p> 
<p>Do you stay up all night thinking how they could have designed such a piece of beauty.</p> 
 
<p>Well you prayers have been answered...and just one click away. Visit <a href="http://www-cdf.fnal.gov/internal/silicon/CAEN_schematics/CAENSchematics.html"> 
http://www-cdf.fnal.gov/internal/silicon/CAEN_schematics/CAENSchematics.html</a> </p>
<!-- Author: Ankush -->



<!-- Date: Tue Nov 22 16:35:10 2005 -->
<table><tr><td><a href=/elog/notebooks/silicon/Tue_Nov_22_2005_163507.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7938  align='top'></a></td><td>Delta(t) register tests.</td></tr></table>
<!-- Author: Sebastian -->
<!-- Comment: Tue Nov 22 16;45;44 comment by...Sebastian -->
With Taka we tested the modifications to the GB: now an internal circular register keeps the information of the last 64 delta(t) that the GB computes. For more instruction see Taka's web page
<a href="http://hepsg3.px.tsukuba.ac.jp/~maruyama/resonance/">here</a>.
<br>
The trace above shows the SRC (via TS emulator) sending L1A spaced by 15.3us and reducing the separation by 1.2us each time (the D(DT)
was increased in the GB). So we pull error after 10 counts. The pointer register (200000cc) showed 0x3F, so the delta(t) were:
<pre>
fc 1a3 
f8 198
f4 18b
f0 193
ec 194
e8 197
e4 19b
e0 1a0
dc 1a3
</pre>
So, this does not seem to be correct.<br>


<!-- Comment: Tue Nov 22 18;48;07 comment by...Sebastian -->
With Taka and his student we looked closer at this and it turns out that the firmware is correct, the above result was due to RBDS pushing the GBIN signal to longer values.
<!-- Comment: Wed Nov 23 11;13;17 comment by...Sebastian -->
<a href='/elog/notebooks/silicon/Wed_Nov_23_2005_102852.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7940' ></a><br>
This plot shows a similar trace as above, but the time between L1A
is always larger than the RDBS signal, so in this case the delta(t)
registers of the GB should be increasing (the pointer first points to the latest delta(t)). The results measured by the GB were:
<pre>
GB reg            LA measurement
0x539 = 44.1us    44.4
0x540 = 44.3us    44.8
0x549 = 44.6us    45.2
0x550 = 44.9us    45.4
0x559 = 45.1us    45.6
0x577 = 46.1us    46.6
0x580 = 46.5us    47.0
0x588 = 46.7us    47.4
</pre>
So, the "big" increase of 1us is real. The GB seems to be doing the measurement right.
<!-- Date: Tue Nov 22 17:23:27 2005 -->
We finished checking Silicon with SVXDAQ.  
The last ladders we tested were f823 & f843, 
those which constantly tripping on DVDD  
over-current. These ladders are OK.  
 
We've made an interesting observation. These  
ladders (as well as rest of L00) have R-driver  
values set to 7. But we found that it's easier  
to recover a trip if we set R-driver values to  
4. But if we later change R-driver values back  
to 7 the ladders still hold. This is weird.
<!-- Author: Sasha & Ankush -->


<!-- Date: Tue Nov 22 17:50:41 2005 -->
<h4>Detector Check Out Complete(....almost)</h4> 
 
<p>The detector check-out is (almost) complete. Today we have done:</p> 
 
<ul> 
<li>Replacement of broken L00 crowbars</li> 
<li>Biased the detector.  According to IMON history plots, all ladders are drawing current</li> 
<li>Wedge-by-Wedge checkout with SVXDAQ of SVX+ISL+L00.  3 ladders in SVX seem to have problems.  But will need further investigation.</li> 
</ul> 
 
<p>We have requested another Silicon COSMICS run.  Checkout out the sensors are really biased and we are reading back something.</p>
<!-- Author: Ankush/Sebastian/Ulrich/Antonio/Sasha/Jen  -->



<!-- Date: Tue Nov 22 22:04:39 2005 -->
<b>Another cosmics run...</b> Run number 207613. <b>Took e3a4 out of the DB for now</b>. SiliMon and SVXMon were running though I could not start the display for SiliMon (no CO around!). Put the COT back off. Silicon is in STBY. Thanks to Veronica and Alexei for the help.
<!-- Author: Sebastian -->
<!-- Comment: Wed Nov 23 13;20;41 comment by...Sebastian -->
Turns out that silimon was running with the runSiliMonSTANDBY.tcl file which does nothing (all histograms are empty). So Guilia made a tcl file to be ran with cosmics ($CDFSOFTB0_DIR/Consumer/SiliMon/runSiliMonCOSMICS.tcl) and, together with her changed to extract the ladder status from the PDB, requested the changes to be released. In the mean time Charles changed the tcl runSiliMonSTANDBY.tcl to PHYSICS, so that if we run before Guilia's changes are released we should get something anyhow. See <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=980&frame=2&anchor=12:57:48.518'>
this</a> entry.



<!-- Date: Wed Nov 23 15:15:02 2005 -->
<h3>Power Cut Confusion</h3> 
During the last days, some confusion was created by the planned power outage next Tuesday. There was talk about a thermocycle of the detector, no silicon DAQ, bringing down the interlock, swapping chillers, etc. The situation shortly before everybody leaves to Thanksgiving is the following: 
<ul> 
<li>The global power outage will be very short (<1 hour), starting from Tuesday, 8:00.</li> 
<li>The cryo area will be kept alive by Diesel generators. We do not know which part of the interlock is connected to those.</li> 
<li>The PLC and svxiicon are connected to a UPS which should run through the power outage.</li> 
<li>The chillers may be affected by the power outage, but after that, they will run again.</li> 
<li>We will exercise the overhauled ISL chiller. 
</ul> 
 
The details will be discussed in a meeting with Bill Noe and company on Monday. I will definitely be at that meeting. 
<p> 
Hope this does not add to the confusion... 
  
<!-- Author: Ulrich -->
<!-- Comment: Wed Nov 23 16;52;16 comment by...Sebastian -->
Still stands that there will be no power to the first floor racks for one day (initially was two). The meeting on Monday should clarify what is going to be done.
<!-- Date: Wed Nov 23 15:25:43 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7941&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7942' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7943&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7944' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7945&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7946' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7947&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7948' ></a></center>
<!-- Author: rainer -->
<!-- Comment: Wed Nov 23 15;28;52 comment by...rainer,ulrich -->
possible positions for one or two more diamonds for beam monitoring. two left pictures show west BLM positions - we think we could probably glue one on the carbon support structure and have cables routed like the BLM cables. The other location is the two right most pictures - there seem to be Rick Tesarek counters close by. This would be ideal for pure losses monitoring and using the scintillators for cross check measurements.


<!-- Date: Wed Nov 23 16:41:48 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7949&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7950  width='300' align='top'></a></td><td><h3>Pinkie in DVDD of e414</h3> 
We had a pinkie in the DVDD line of e414. A config brought it back to normal values.</td></tr></table>
<!-- Author: Ulrich H. -->



<!-- Date: Fri Nov 25 08:39:19 2005 -->
<h3>Tevatron Group: Analysis of Quench</h3> 
Here is a summary of what the Tevatron group knew about the quench last Wednesday: 
<p> 
<font color='#005500'> 
Below is a list of some things we know or at least 
conjecture about this quench.  We will add to this list as we 
investigate further.  We will also point out which of these statements 
prove to be false.  The evidence for these statements should be in this 
logbook page, but this note is just left as list. 
<ul>  
  <li>Quench was definitely caused by a spark of the B11 Horizontal separator.</li>  
  <li>Pbars were likely all dumped on the F49/F48 collimators in one turn.</li>  
  <li>Protons probably lasted a little longer (maybe up to 4 msec).</li>  
  <li>B17 quench was slower than at the locations with collimators.  Kicked   
  and scattered beam was probably lost here in a more diffuse manner than beam   
  lost on the collimators.</li>  
  <li>The failure was a mechanical failure caused by the pressure rise from the   
  quench (not direct beam damage).<ul>  
    <li>Since 2001 there have been 7 quenches in the B17 area (6 of those were   
    high current quenches)</li>  
    <li>There were 53 total quenches recorded in all of B1 since 2001.</li>  
    <li>There does not appear to be any electrical damage in the B17 area.</li>  
    <li>This area probably contained a weak component whose number was up.</li>  
    <li>The last time we worked (warm) in B1 was in Dec. 2003 for the   
    replacement of the spool at B14.  During that startup we experienced   
    several training quenches.</li>  
  </ul>  
  </li>  
  <li>Instrumentation that would help us know more about this quench:<ul>  
    <li>Vic Scarpine TBT buffer - scope was recently removed to be used for   
    something else.</li>  
    <li>C4 scintillator - bad HV cable in the tunnel at C46 - will be repaired   
    this week.</li>  
    <li>Tesarek abort diagnostic system - needs tunnel time that we have not   
    been able to get (need Rick and AD help simultaneously).  Rick is gone   
    for two weeks starting today.</li>  
  </ul>  
  </li>  
  <li>This is the first time that we have seen a bad multihouse quench since the   
  Fast QPM abort was installed.<ul>  
    <li>The quench at F48 was actually so fast this time that the fast QPM abort   
    was not pulled by this cell!!!  </li>  
    <li>The fast abort was detected in F48U 2 msec later.  </li>  
    <li>The BLMs could have maybe saved 2 msec in this case (because of the   
    missed fast abort).</li>  
  </ul>  
  </li>  
</ul> 
</font>
<!-- Author: Ulrich -->
<!-- Comment: Fri Nov 25 08;45;19 comment by...Ulrich -->
<p>
In other news, work has started at B1. From the MCR e-log:
<pre>
01:35:47-   Cryo personnel have arrived to start the "Tevatron Magnet Isolation for the Magnet Repair" procedure. They report that they will need to access the tunnel to disconnect C-seals in about an hour. 

08:18:03- [...] B1 warm up underway. Cryo personnel prepared B1 for the magnet changout and were ready by 0600. Mechanical support personnel were in the tunnel by 0700.

08:33:59-   Addendum to start of shift notes: Tev in access for the B17 spool replacement. Preliminary assessment from the tunnel indicates that the cryo bypass will also need to be replaced.
</pre>

Let&#039;s see how much downtime we&#039;ll get...


<!-- Comment: Fri Nov 25 16;11;19 comment by...Sebastian -->
<pre>Date: Fri, 25 Nov 2005 15:34:46 -0600
From: David McGinnis &lt;mcginnis@fnal.gov&gt;
Subject: RE: Meeting to discuss December Study period
 
The extent of the damage to B17 is still unknown. Definite news won't be
available until; late tonight or tomorrow. Because of this and with a large
number of people out of town until Monday, we will hold a meeting on Monday
November, 28 after the 9am meeting to plan the next couple of weeks.

</pre>
<!-- Comment: Fri Nov 25 16;12;36 comment by...s -->
<pre>entry above was mail from willis.</pre>
<!-- Date: Fri Nov 25 09:13:15 2005 -->
The new main pager (I mean the device, not the carrier) is strange: 
The alert not really loud enough, the vibrational alert is not strong enough, the display contrast is bad, and there is no audio alarm for low battery (What I thought would be the battery status display is actually the low battery warning...). Furthermore, the handling is not exactly intuitive. For those of you eager to read the manual, <a href="http://www.usamobility.com/bus_solutions/wireless_messaging/products_services/userguides/Br500-501flexusermanual.pdf">here it is</a>.
<!-- Author: Ulrich -->


<!-- Date: Fri Nov 25 12:34:08 2005 -->
Tried to bring e3a4 to STBY but failed. I'm beginning to worry about this ladder.. There is already a a dead one in this wedge.
<!-- Author: Sebastian -->




<!-- Date: Fri Nov 25 19:01:38 2005 -->
<h3>Fileserver move</h3> 
The VRB package now compiles in the new fileserver (with SL) using 
the default version of java (1.4.2),  
you get these libraries when doing a "source /cdf/cdf.cshrc".  
Three more packages to go. Thanks to Bill W and Stephan  
for the help. Let me know if 
you find any problems with any part of our software  
(svxdaq, java, etc).<br>  
<!-- Author: Sebastian -->
<!-- Comment: Sun Nov 27 13;12;18 comment by...s -->
it compiles, yes, but this does not work yet...
<!-- Date: Sat Nov 26 18:30:52 2005 -->
<h3>Tevatron update: verdict expected tomorrow evening</h3> 
<pre> 
Sat Nov 26 17:06:10-  Tevatron update: Helium backgrounds have been very high as a consequence of the way the components failed during the quench, so leak checking has been slowed. The determination of whether or not the B17 cryo bypass will need to be replaced or not should take place late Sunday. If the bypass is OK, the Tevatron would be cold on roughly December 8. If the bypass has to be replaced, the Tevatron would be ready (cold, separator baked out and conditioned) on roughly December 20. - J. Morgan 
</pre>
<!-- Author: Ulrich -->
<!-- Comment: Sun Nov 27 22;01;17 comment by...Ankush -->
<h3>Tevatron Update: Verdict in</h3>

<pre>
Sun Nov 27 21:27:34-   Tevatron update: Good news from the tunnel. The B-17 cryo bypass has passed both the vacuum test and borescope inspection and has been declared OK. This means we'll avoid the difficult replacement of the bypass and related separator work (removal, reinstallation, bake-out and conditioning). This puts us on the shorter schedule for Tevatron repairs, with the work completed and Tevatron cold around December 8. - J. Morgan  
</pre>

<p>So the judgment is good.  We should be up and running by Dec 8..but this is still another 11 days away.</p>


<!-- Date: Mon Nov 28 07:53:25 2005 -->
<h3>Summary of the week</h3> 
 
Monday, November 21: 
<ul> 
<li>Smooth running until...</li> 
<li><b>Big quench</b> around 16:00: 120-140 rad in each of the four BLMs, no trips, no pinkies, but 10 out of 12 L00 crowbars broken</li> 
<li>Quench analysis: separator spark in B11 caused 7-house quench, pbars dumped in F49/F48 collimators, Fast QPM not pulled (quench too fast?), damage in B17</li> 
<li>Post-quench checkout, part 1: bias SVX and ISL, check IMON history ladder by ladder  &rarr; all ladders are drawing current</li> 
<li>Cosmics run with silicon to check if we read back data and to debug SiliMon.</li> 
</ul> 
 
Tuesday, November 22: 
<ul> 
<li>Post-quench checkout, part 2: wedge-by-wedge checkout with SVXDAQ &rarr; four SVX ladders and two ISL ladders with problems</li> 
<li>L00 crowbars replaced, no problem to bias L00</li> 
<li>Trip of SVX B3W10L4 (DVDD overcurrent), could not bring this back so far</li> 
<li>Another cosmics run with silicon</li> 
</ul> 
 
Wednesday, November 23: 
<ul> 
<li>Pinkie in e414 (DVDD)</li> 
</ul> 
 
Thursday, November 24: 
<ul> 
<li>Happy Thanksgiving</li> 
</ul> 
 
Friday, November 25: 
<ul> 
<li>Another try to bring back e3a4, no success</li> 
</ul> 
 
Saturday, November 26: 
<ul> 
<li>Nothing to report</li> 
</ul> 
 
Sunday, November 27: 
<ul> 
<li>Nothing to report</li> 
</ul> 
 
  
<!-- Author: Ulrich -->

<!-- Date: Mon Nov 28 09:10:02 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W1L4 
<li>problem n: 1578 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Incident
<li>entered by: alscott 
<li>description is: Spontaneous overvoltage, documented <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=275&frame=2&anchor=03:34:11'> here</a>. 
<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: Mon Nov 28 09:14:44 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W1L4 
<li>problem n: 1578 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: alscott 
<li>description is: All ADCmon plots look normal in run 207513.  Note that this ladder has an unfixable bit 6 error documented in thread 1089, so 'normal' is a relative term here.  Ladder appears to have survived. 
<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: Mon Nov 28 09:22:46 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7951&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7951' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7952&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7952' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7953&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7953' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7954&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7954' width='300'></a></center>
<!-- Author: Adam Scott -->
<!-- Comment: Mon Nov 28 09;27;00 comment by...Adam Scott -->
<br>
Plot 1: f314 bias 1 voltage vs. time around the time of the spontaneous overvoltage.<br>
Plot 2: f314 bias 1 current vs. time around the time of the spontaneous overvoltage.<br>
Plot 3: f314 bias 1 voltage vs. time since DS day 500<br>
Plot 4: f314 bias 1 current vs. time since DS day 500<br>
<br>
The DS power supply ntuples also see an overvoltage.  The bias 0 line had no overvoltage.


<!-- Date: Mon Nov 28 09:30:48 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W1L4 
<li>problem n: 1578 
<li>Status: needs_longterm_monitoring
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: alscott 
<li>description is: PS ntuples confirm overvoltage.  Plots <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=276&frame=2&anchor=09:22:46'> here</a>.  After about a month, check for any more overvoltages in the PS ntuples. 
<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: Mon Nov 28 09:32:19 2005 -->
<pre>Monitoring summary: 
 
f314 - PS ntuples confirm spontaneous overvoltage on bias 1. 
 
Other than that, there was no data to monitor.</pre>
<!-- Author: Adam Scott -->