<!-- Title: 10:04:12  Mon Jan 30 2006 -->
<!-- Crewchief: Sebastian -->
<!-- Op1: Oscar -->
<!-- Op2: etc -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
La gran tarea es justificarse - Pavese


<!-- Date: Mon Jan 30 10:17:19 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8238&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8238  width='300' align='top'></a></td><td>Steve H was working on the CLK  
(<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=89&frame=2&anchor=09:51:37.963'> 
found</a> that the MCLK delay was changed), but while fixing the problem reset the CLK and we started tripping.</td></tr></table>
<!-- Author: all of us... -->
<!-- Comment: Mon Jan 30 10;18;27 comment by...Sebastain -->
Steve let us know pretty quickly and we did not trip many ladders (a quick config is the way to go). Oscar recovered the ladders.


<!-- Date: Mon Jan 30 11:11:23 2006 -->
<pre>We went downstairs in a controlled access to check and recover IB0W0L2 (f002). We swapped the fiber in f002 and f001 and the error moved to f001. Since it seems that the problem is in the ladder, we swapped the fibers back and did not try anything else. 
</pre>
<!-- Author: Ankush/Sebastian/Oscar -->
<!-- Comment: Mon Jan 30 12;28;44 comment by...s -->
This is not a complete surprise, since as noted <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=285&frame=2&anchor=03:12:19'>
here</a> the AVDD current dropped by 50%. A PS cable swap will make things clearrer I think.
<!-- Date: Mon Jan 30 11:57:29 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W0L2 
<li>problem n: 1622 
<li>Status: needs_access
<li>Type: Unknown
<li>Action: Incident
<li>entered by: amitra 
<li>description is: <p>The fibre swap showed the problem was internal.  So we did not bother with the FIB/RX swap.  Needs much more work to understand why this ladder is not giving any data.</p>   
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Mon Jan 30 14:05:48 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8241&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8242' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8243&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8244' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8239&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8240' ></a></center>
<!-- Author: Mark/Oscar -->
<!-- Comment: Mon Jan 30 14;15;08 comment by...Ankus/Oscar/Sebastian/Mark -->
<h3> Another Access for f002 </h3>
Sebastian and Ankush made an access to further study f002.  Our first test was to swap power supply cables between f00 and f10.  The first two plots above show this attempt at ~13:12.  The problem stayed with the ladder, so it is not a power supply problem.  Next after a suggestion from Marcel we decided to do a timing cable swap  between f000/1 and f100/1.  Here we saw some strange behavior.  The ladders in f00 all started powering up to normal levels, but around the time we tried to initialize AVDD for these ladders dropped down to about 1/2 the nominal value, while the initialization failed.  This can be seen for f002 and f001 in the left and right plots above at about 13:35. This failure mode (seen by all ladders in f00 after the swap) looks very similar to the original f002 failure mode.  We are currently thinking about this.

<!-- Comment: Mon Jan 30 14;20;56 comment by...Mark -->
Never mind the comments about the timing cable swap.  It turns out that Sebastian, Ankush and myself (Mark) did not communicate properly about which timing cables were swapped.


<!-- Comment: Mon Jan 30 15;41;51 comment by...Sebastian -->
my confusion... 01 vs 10.
<!-- Date: Mon Jan 30 15:30:24 2006 -->
Vince came with a new PROM for the A509 which combines the bad one and other working PROMs (see history of problem <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=284&frame=2&anchor=16:33:00'> 
here</a>). This time got a "wrong firmware checksum" error from the mainframe. This is progress! (Jen knows it is at least...). Vince will keep looking into it, the CAEN people promised to send Vince the mapping of the bit file.
<!-- Author: Sebastian -->


<!-- Date: Mon Jan 30 15:35:02 2006 -->
<h3>Further investigation of f002</h3> 
 
<p>We tried setting all the ISEL bits to 1 and the RDriver values to 7 to see if we could induce any changed in the AVDD & DVDD currents.  Alas, no cnahge at all.  AVDD stayed constant at 635 and DVDD stayed at 300.</p> 
 
<p>Much, much more investigation needed.</p>  
<!-- Author: Ankush & Mark -->
<!-- Comment: Mon Jan 30 15;36;56 comment by...Ankush & Mark -->
another thing to check is the junction card...


<!-- Date: Mon Jan 30 15:39:24 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8246&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8246  width='300' align='top'></a></td><td>We took a detailed look at the AVDD current for f002 to see exactly when it started drawing ~650 uA (as opposed to the nominal 1158 uA).  The plot shows the current dropping at 2:30 on 1/28.  Having looked at the ps logs we found that the current was fine during the first run with silicon after the mini-shutdown, which lasted until 2:12 on 1/28, even though f002 was not returning data.  Then the ladder was power-cycled after this run, and that was when it first reported the low current.</td></tr></table>
<!-- Author: Mark/Ankush -->
<!-- Comment: Mon Jan 30 15;44;24 comment by...s -->
Yes, see <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=285&frame=2&anchor=03:12:19'>
here</a>.


<!-- Date: Mon Jan 30 21:11:01 2006 -->
<br><b>Yet more trouble with the CCC:</b> 
the problems form <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=285&frame=2&anchor=11:29:16'> 
yesterday</a> were traced to not having the SYSCLK (vme) on the backplane, adding this clk gets the CCC going at the B0 teststand. However the card can not lock the BS signals, it gives 0x2C error, even after a reset of the board (and though 0x4 toggles the clk mode, 0x8 does not clear the error register). I suspected that the CCC expected the BS signals in the wrong pins (or polarity) but checking this at FCC showed that it is doing the right thing. I think I know what to try next...  
in any case will talk to Bill H.
<!-- Author: Sebastian -->
<!-- Comment: Mon Jan 30 21;49;34 comment by...Sebastian -->
Tried two CCCs, one in internal mode, running the other one. This worked in both cases (A driving B and vice versa - with the CCCs with base add 3000 and 7000).


<!-- Comment: Tue Jan 31 16;52;27 comment by...Shulamit/Sebastian -->
Today we tried again the two CCC boards at B0. We found three problems:
<ul>
<li> CCC3 (e3 is the base address) would sync to RF, but will not
clear all the errors after writing 0x8 to 0x30 (it would still report 0x2C in 0x32). Bill H will look into this.
<li> CCC7 would not sync to RF. But it would sync to the "fake" RF coming from another CCC. With Bill H we suspected that the fact that the real RF amplitute is 600mV, while the CCC RF putput is 1.3V, could be the reason for this. May be something is wrong in CCC7 RF logic but a larger amplitute overcomes the problem.
<li> We think that one of the 6U to 9U adaptors is bad. However the adaptor card does not have anything active, so we are not 100% sure if there is a problem yet.
</ul>

<!-- Date: Tue Jan 31 00:38:46 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8247&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8247  width='300' align='top'></a></td><td><b>History of AGIGI2 when the store was aborted. All included entries have been safe for the Silicon detector.</b></td></tr></table>
<!-- Author: Sebastian -->
<!-- Comment: Tue Jan 31 01;01;56 comment by...Ankush -->
<pre>OK I'm going to make a comment which will upset everyone.....

...does this include all the cases when the beam was aborted and the Silicon detector was biased. For example, what was the state of CDF when the beam was aborted during the last store...were we taking data all the way to the point when when the beam was aborted or was all of CDF already at their end-of-store mode ie:- All HV for Silicon, COT, Muons, etc was off?

I know I tend to be over cautious but we should remember we intend to use this detector beyond its "sell-by" data.  ie:- >2fb-1.  So I believe a little extra caution is warrented.

However you are all allowed to disagree with me.</pre>

<!-- Comment: Tue Jan 31 09;27;08 comment by...Sebastian -->
The plot above is for aborts where the silicon SVRAD variables stayed at zero. I believe the configuration of the detector does not matter.

<!-- Comment: Tue Jan 31 09;30;44 comment by...Sebastian -->
BTW <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=273&frame=2&anchor=19:32:12'>
this</a> is the previous plot.


<!-- Comment: Thu Feb  9 13;52;54 comment by...Sebastian -->
I looked at AGIGI2 during quenches where we did get a detectable dose in the BLMs, unfortunatelly (?) there is only one quench (store 4301) which latched the SVRADs (~140), AGIGI2 was 0.3. 
<!-- Date: Tue Jan 31 10:43:25 2006 -->
<h3>Remember CV5?</h3> 
I just found  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=92&frame=2&anchor=09:47:44.030'>this entry by Steve Hahn in the main e-log</a>. CV5 was the valve we had to regulate to 30% in the summer to get enough chilled water flow to the SVX chiller. Apparently, the recent change in CV5 did not affect us.
<!-- Author: Ulrich -->

<!-- Date: Tue Jan 31 10:53:27 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W6L3 
<li>problem n: 1619 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>The bias for this ladder jumped up again after the 2nd mini-shutdown.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1284.0</td><td>1300</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>1286.0</td><td>1495.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W6&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Jan 31 12:05:11 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8248&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8248  width='300' align='top'></a></td><td><p>Just noticed the AVDD current for f002 has gone up.  It jumped up when the run was stopped.  It may be interesting.</p></td></tr></table>
<!-- Author: Ankush -->
<!-- Comment: Tue Jan 31 12;08;16 comment by...Ankush -->
<p>Just noticed we did a CONFIG and the current didn't jump down....</p>

<p>and I just realised IMON spat out a java.lang.OutOfMemory error when I hit the 'to e-log' button.  Going to restart it now.</p>

<!-- Comment: Tue Jan 31 12;37;40 comment by...Mark -->
According to <a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=286&frame=2&anchor=15:39:24'>
this plot</a> we made yesterday, the current has been jumping around in the 600s.


<!-- Date: Tue Jan 31 13:08:39 2006 -->
Just to note that there is something wrong with the si_daq logs (will look at it later).
<!-- Author: Sebastian -->


<!-- Date: Tue Jan 31 14:06:57 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8249&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8250  width='300' align='top'></a></td><td> </td></tr></table>
<!-- Author:   -->
<!-- Comment: Tue Jan 31 14;07;24 comment by...Ankush -->
<pre>for the curious: AVDD for f002 just jumped down....</pre>


<!-- Comment: Wed Feb  1 07;51;05 comment by...Oscar -->
Hi, it went up again at 5:10am. The value since then has been 660, very similar to the one before.


<!-- Date: Wed Feb 1 11:19:30 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8251&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8251  width='300' align='top'></a></td><td>Store 4618, initial lumi: 120E30. Everything fine in IMON, except for a pinky (right on the low end).</td></tr></table>
<!-- Author: Oscar/Sebastian -->


<!-- Date: Wed Feb 1 11:23:28 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8252&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8252  width='300' align='top'></a></td><td>This is the pinky ladder. SVXMon shows no problem with this ladder. Current value is 1110 (low end is 1115).</td></tr></table>
<!-- Author: Oscar/Sebastian -->


<!-- Date: Wed Feb 1 11:40:09 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8254&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8254' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8255&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8255' width='300'></a></center>
<!-- Author: Oscar/Sebastian -->
<!-- Comment: Wed Feb  1 11;40;37 comment by...Oscar/Sebastian -->
We checked that ladder e554 (SB5W5L4) was giving data. In the meanwhile, the current come back to normal. We unmarked it and now is back to green and stable.

<!-- Comment: Wed Feb  1 12;33;12 comment by...s -->
It's pink again, but we are getting data.


<!-- Date: Wed Feb 1 15:36:51 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8256&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8256  width='300' align='top'></a></td><td>The LA at work. Now we can look at what the SRCs are doing from the CR (in fact, from anywhere, even outside the lab).</td></tr></table>
<!-- Author: Sebastian -->


<!-- Date: Wed Feb 1 15:44:15 2006 -->
<h3>Silicon Integrated Dose Alarm during the Squeeze</h3> 
 
<p>During today's shot we had an integrated dose alaram during the squeeze.  Here are copies of the details from the shift e-log.</p> 
 
<pre> 
Wed Feb 1 10:33:35  Silicon rad alarm. Called MCR. - Eva H. 
-- Wed Feb 1 10:36:38 comment by...Eva H. --  Also called Silicon rad mon and silicon people are here to investigate. Wed Feb 1 10:33:54 Silicon radiation >19 rad alarmed during ramping.  - ai 
 
Wed Feb 1 10:38:41 MCR called to let us know that they had problems during pbar injection (injected some pbars in wrong bucket). This means we will have a larger than usual halo but scraping should fix this (and our silicon rad alarm). We will have a 36x32 store. - Eva H. 
</pre>
<!-- Author: Ankush -->
<!-- Comment: Wed Feb  1 18;32;34 comment by...Ulrich -->
We wrote to Ron Moore to ask him about the incident. Here is his answer:
<pre>
	The rad alarm occurred during the squeeze, but the loss patterns are different than the previous events.  The pbars in the wrong buckets are the source of the losses, because they wreak havoc on the protons with which they have parasitic crossings.
</pre>
So the pbar problems really seem to be the culprit. Thanks to Ron for the quick answer!
<!-- Date: Wed Feb 1 17:02:57 2006 -->
<h3>Michael Flatley strikes again!!</h3> 
 
<p>Ankush went into the counting room do have a look at the Silicon DAQ crates.  Ankush only believes real electronics is analgoue; digital electronics is for sissys.</p> 
 
<p>So Ankush opened the door to the back of B0SVX06 to look at the VTMs and then heads to the Control Room.  In the Control Room, Sebastian reports a clock gitch. Ankush sheepishly confeses he was in the counting room at the time....rediscovery of the old problem.</p> 
 
<p>I now expect all the golden-oldies to make smart-alec comments under various pseudonyms.</p>
<!-- Author: Ankush -->


<!-- Date: Wed Feb 1 17:06:17 2006 -->
<h3>On SRC Errors...</h3> 
 
I had the new LA set up to capture ISL or SVX errors, and a bad SRC error came from the ISL one: 
<pre> 
b0svx06:Messenger:Feb 1, 2006 4:33:14 PM->SRC Fatal Error:Sl 6 Too Many L1A 2 L1A to Buff Gap Error  
</pre> 
The LA caught the error which showed that we lost the BS for 55us. 
This would normally cause a strange SRC error like the one above. It turns out that Ankush was checking b0svx07 in the first floor for the load balancing plan. When he came up and we talked about it became apparent what happened. We went downstairs again and as a demostration caused another SRC error by banging the b0svx07 rack (not too strongly). Sure enogh, the SRC BS glitched again and we got: 
<pre> 
b0svx06:Messenger:Feb 1, 2006 4:41:21 PM->SRC Fatal Error:Sl 6 Gap Error  
</pre> 
This is not knew, it is a known feature of the first floor rack room.  
<br><br> 
<td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8257&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8257 width='300' align='top'></a></td> 
This is the first glitch. 
<br>
<!-- Author: Ankush/Sebastian -->
<!-- Comment: Wed Feb  1 17;08;37 comment by...s -->
Also, note that though the SRC reported an error (correclty) it also recovered from it. A bigger glitch is needed for tripping the detector... but I guess one could manage to do it...



<!-- Comment: Thu Feb  2 14;52;17 comment by...sebastian -->
Today (Thursday), got another clk glitch in the ISL SRC, the trace is similar to the one above, the error log shows:
<pre>
Feb 2, 2006 2:38:10 PM->SRC Fatal Error:Sl 6 Too Many L1A 2 L1A to Buff
</pre>
in run 211188.
<!-- Date: Wed Feb 1 23:34:47 2006 -->
<h3>Bye-bye beam...</h3> 
Beam was lost... no info from MCR yet. Just a quick note that we received *no* radiation, and silicon stays happy. See e-log entries in the main e-log beginning <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=96&frame=2&anchor=23:23:01.221'> 
here</a>.
<!-- Author: Jennifer :-) -->


<!-- Date: Thu Feb 2 08:55:41 2006 -->
<h3>Plans for the shutdown</h3> 
In yesterdays meeting it was decided that: 
<ul> 
<li> The silicon baggy will not be opened. 
<li> The detector is going to be kept cold (at or below 0C) 
through the shutdown (when no power to B0, use motor generator). 
</ul> 
The decision whether to pull the plugs (COT needs access to both 
ends for about 2 weeks) will be taken by Ops after considering the 
case of the XFT (for COT noise reduction).<br>
<!-- Author: Present: Ankush/Marcel/Ulrich/Ricardo/Sebastian -->


<!-- Date: Thu Feb 2 09:38:08 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8258&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8258' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8259&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8259' width='300'></a></center>
<!-- Author: Oscar/Sebastian -->
<!-- Comment: Thu Feb  2 10;09;08 comment by...Oscar/Sebastian -->
<h3>CLK Trip</h3>

Oscar was in the CR when the silicon started tripping.
The problem was that MCR rebooted the TeV low level RF
rack:
<pre>
09:13:55-   TeVLLRF has been rebooted , also.  - dln
</pre>
We had the LA set to trigger on either SRC error. The trace is shown above, one can see that some signals are missing, and also SY is affected (though one can not see it in this trace). The result is that the SRC freezes and we do not send keepalives. 
However it looks like the ISL SRC was not affected by the glitch (or al least not as much, since some ladders in L00 did trip). It is known that the ISL SRC is more robust to glitches, but this is not understood, since from the firmware point of view both are the same (however the ISL one runs in tracer mode...). The plot below compares the clk signals in both SRCs.
<p>
<a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8260&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8260 width='300' align='top'></a>
</p>
The trace in red is the SVX SRC. Steve H requested that MCR let us know the next time they reset these racks (however this is not expected to happen often!). The problem is how we will proceed.




<!-- Comment: Thu Feb  2 10;57;59 comment by...s -->
There was no CLK (in the SVX SRC) for at least 1.3ms (I'm guessing much more).
<!-- Comment: Thu Feb  2 11;34;39 comment by...Sebastian -->
See also <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=98&frame=2&anchor=09:51:04.481'>
this</a> entry in the main elog.
<!-- Date: Thu Feb 2 10:34:02 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W0L0 
<li>problem n: 1019 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Since last entry (01/13/06), the bit3 low problem has occured only once during calibration and cosmics runs (210,523; 210,601) with error rate 99%. Otherwise, it's been error free. Analysing runs,  one can see that bit3 is low only for chips 9b->b4 while other chips are unaffected. This ladder needs more observations and quiet time studies. If error is reproducable, we can try a fiber swap.    
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Feb 2 11:04:04 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W8L1 
<li>problem n: 1620 
<li>Status: fixed
<li>Type: RX
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: No errors after one week of running. Fixed. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W8&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Feb 2 11:04:04 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W8L1 
<li>problem n: 1620 
<li>Status: fixed
<li>Type: RX
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: No errors after one week of running. Fixed. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W8&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Feb 2 11:12:53 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W8L2 
<li>problem n: 1469 
<li>Status: needs_observation
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: The frequency of error occurance has reduced dramatically after RX swap and turning dps off. Bit error rate now is <1%. ff or 7f error has only occured in calibration run (210,906). Need to continue observations for some time before declaring success. 
<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: Thu Feb 2 11:18:13 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W0L1 
<li>problem n: 1577 
<li>Status: fixed
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: no errors--Fixed. 
<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: Thu Feb 2 11:21:59 2006 -->
<pre><h3>PS GUI Crashed</h3> 
<p> 
<svxii@b0dasvx01>If same do nothing 
If same do nothing 
Status change prohibited 
ch = 4 
pcStatus = 0 
status = 1 
channelStatus = 2 
If same do nothing 
java.lang.ExceptionInInitializerError 
        at gov.fnal.robin.rRequest.unmarshal_response(rRequest.java:568) 
        at gov.fnal.robin.rRequest.get_response(rRequest.java:387) 
        at gov.fnal.robin.rRequest.invoke(rRequest.java:177) 
        at CAEN.CaenVme.CaenClient.getSiliconInfo(CaenClient.java:582) 
        at CAEN.PWR.resetValuesFromVMEFunction(PWR.java:530) 
        at CAEN.PWR.access$000(PWR.java:43) 
        at CAEN.PWR$resetValuesFromVMEThread.run(PWR.java:429) 
        at CAEN.PWR.resetValuesFromVME(PWR.java:475) 
        at CAEN.PSControlForm.refresh(PSControlForm.java:1627) 
        at CAEN.PSControlForm.access$000(PSControlForm.java:41) 
        at CAEN.PSControlForm$1.actionPerformed(PSControlForm.java:752) 
        at javax.swing.Timer.fireActionPerformed(Timer.java:271) 
        at javax.swing.Timer$DoPostEvent.run(Timer.java:201) 
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:189) 
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:478) 
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201) 
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151) 
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145) 
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137) 
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:100) 
Caused by: java.lang.NullPointerException 
        at org.omg.CORBA.CompletionStatus.<init>(CompletionStatus.java:23) 
        at org.omg.CORBA.CompletionStatus.<clinit>(CompletionStatus.java:6) 
        ... 20 more 
 
[1]    Done                          java -Xbootclasspath/p:/cdf/onln/code/cdfprod/robin/v2_4_10/classes -ss100m  ... 
<svxii@b0dasvx01> 
</p> 
<p> 
Turns out that the powerset.dat file was not pointing to a file that existed. We checked the scripts and rerun traceSilicon to see if something was wrong, but the file was generated and the link was fine... I suspect that at some point traceSilicon was ran and it gave an errro which only became apparent after Oscar and Ankush tried to restart the GUI. 
<p></pre>
<!-- Author: Oscar/Ankush/Sebastian -->

<!-- Date: Thu Feb 2 11:23:02 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W7L1 
<li>problem n: 1615 
<li>Status: fixed
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: no errors--fixed. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W7&layer=L1">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Thu Feb 2 11:48:23 2006 -->
<pre>We recovered the detector to STAND-BY again after the clock trip. We have several problems getting LB0W4L3 (f843) up again. We tried several things but they did not help. Finally we hockerize for recovering it. It failed to go to stand-by the first try (for the whole wedge), but in a second, individual, try, it came up nicely. Everything is ready and waiting for the collisions...</pre>
<!-- Author: Oscar/Ankush/Sebastian -->


<!-- Date: Thu Feb 2 12:06:37 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8261&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8262  width='300' align='top'></a></td><td>SB0W1L2 (e012) shows a drop in AVDD of 60, as shown in the figure. DCDD has increased a bit (5). We cannot check the ladder with SvxDaq since shot setup is right there. I will  keep an eye on the data from this ladder as soon as it comes.</td></tr></table>
<!-- Author: Oscar -->
<!-- Comment: Thu Feb  2 13;00;22 comment by...Mark -->
This guy has a history losing its z-side.  After the 1/14 quench the z-side appeared to be lost, but when I checked it out on 1/24, it was ok.
<!-- Date: Thu Feb 2 12:49:45 2006 -->
<h3>Silly CAEN Supplies</h3> 
 
<p>At the start of the run, ISL B4W0L* gave an INHIBIT.  Tried to power cycle trhe ladder, then wedge...then hockerised which fixed the problem.  Then the run restarted with an immediate L2 T0.</p>
<!-- Author: Ankush & Oscar -->



<!-- Date: Thu Feb 2 13:08:28 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8263&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8263  width='300' align='top'></a></td><td>Same as above (SB0W1L2, e012): after the data started, the "lost chip" recover for a while (with an HRR). However, it become to a bad status again. Checking the data we realized that we were getting data from 1 chip in the z-side (a4). Ankush suggested to power-cycle the wedge. After doing that, the ladder is recovered and providing data.</td></tr></table>
<!-- Author: Oscar/Ankush -->


<!-- Date: Thu Feb 2 13:10:59 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8264&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8264  width='300' align='top'></a></td><td>SVT SpyMon plot for store 4621 with initial luminosity: 75E30 
</td></tr></table>
<!-- Author: Oscar -->


<!-- Date: Thu Feb 2 13:59:25 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8265&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8265  width='300' align='top'></a></td><td>S_AVDD_B5W5L4 turned pink</td></tr></table>
<!-- Author: ai  -->
<!-- Comment: Thu Feb  2 14;06;07 comment by...Ankush -->
<pre>Ai (Monitoring ACE) spotted AVDD for e554 go pink.  But this is fine. It just went slightly below its limit.  After unmarking it went back to yellow.</pre>


<!-- Date: Thu Feb 2 14:16:41 2006 -->
<h3>b0sili01 incoming network has been blocked by FNAL computer security</h3> 
 
<p>Yesterday FNAL computer security informed us some typed "xhost +" into b0sili01 which makes the machine open to hacking.  Today we were informed they blocked the network connections and now one cannot connect to b0sili01.</p> 
 
<p>We have informed FNAL computer security the xServer has been restarted and asked them to remove the network block.</p> 
 
<p>We wish to keep the computers in the Silicon office open to everyone but we do rely on you being sensible and not to inadvertently make the computer open to attack. Sorry to sound like a pain, but please be aware that big-brother is watching us and is capable of being a royal-pain in the nether-regions.</p> 
 
<em>Thank you for your cooperation</em>
<!-- Author: Ankush & Ben -->



<!-- Date: Thu Feb 2 14:55:04 2006 -->
<h4>Just saw this entry....</h4> 
 
<pre> 
Thu Feb 2 14:41:29  RXPT Error for crate b0svx06. The 2nd error message: 
 
SRC Fatality Error for b0svx06: SI 6 Too Many L1A 2 L1A to Buff 
 
HRR, Ok now - sasha :: (run 211188)  
</pre> 
 
<em>evidence of Michael Flatley??</em>
<!-- Author: Ankush -->
<!-- Comment: Thu Feb  2 17;24;48 comment by...Sebastian -->
see <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=286&frame=2&anchor=17:06:17'>
this</a> entry...


<!-- Date: Fri Feb 3 01:56:52 2006 -->
Got paged because of a red ladder in IMON. However the trip was already recovered. Just a matter of unmarking the ladder in IMON.
<!-- Author: Sebastian -->


<!-- Date: Fri Feb 3 07:57:48 2006 -->
When I came I noticed IMON was not updating since 7:20am (it was 7:45am). I restarted it. The pinky reported by the ace (SB1W2L3, e123) is still there. Value just above the high end (701 vs 700). 
<br> 
I asked the ace to leave it pink but keep an eye on the history plot.
<!-- Author: Oscar -->


<!-- Date: Fri Feb 3 12:39:22 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><h3>PSGui set up</h3> 
 
I updated the UPS DB for caencontrol. Note that now "setup caencontrol" will return  
/cdf/onln/code/cdfprod/caencontrol/v4 as $CAENCONTROL_DIR. 
However the PSGui configuration files are located at /cdf/onln/data/svxii/caencontrol/PSfiles. I have also changed the startup script and we just checked it with Oscar.</td></tr></td></table>
<!-- Author: Sebastian -->

<!-- Date: Fri Feb 3 13:13:56 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W2L3 
<li>problem n: 683 
<li>Status: needs_longterm_monitoring
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Changed the high-end value in IMON to 705 (from 700).<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>579.957</td><td>579.957</td></tr>
<tr><td><b>Lower</b></td><td>	0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>700</td><td>705</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Fri Feb  3 13;15;07 comment by...Oscar -->
We changed the value since the current has been stable at 701 (being the old limit 700) and the IMON display was showing it pink.


<!-- Date: Fri Feb 3 13:30:33 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8266&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8266  width='300' align='top'></a></td><td>SVT SpyMon plot for store 4623 with initial luminosity: 106E30. Everything looks fine in SVXMon. In IMON, we have a pinky (SB5W5L4, e554 AVDD a bit lower than the limit, as it has been in the last days). </td></tr></table>
<!-- Author: Oscar -->


<!-- Date: Fri Feb 3 17:41:51 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8268&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8268' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8269&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8269' width='300'></a></center>
<!-- Author: Oscar -->
<!-- Comment: Fri Feb  3 17;46;44 comment by...Oscar -->
The plot on the left shows the current on AVDD for SB5W5L4 (e554). We had a small increase some time ago. Currently, this ladder is a bit below the low limit ahen ew are taking data.
<br>
In that case the value is 1105 (for a low limit of 1115). When the detector is not taking data (even in the Halt state), the value is a bit higher. For this reason, the ladder is giving a pinky in AVDD  during data-taking in the last days.
<br>
Checking the data and the error logger, the ladder seems to be fine, except for the distribution of the ADC for chip 1, which displays a bump around 50 (plot on the right). We may need to investigate that (any suggestion?). Since the rest is fine and all the chips see physics with negligible fraction of errors,
I have changed the limits on IMON to avoid having the pinky.

<!-- Date: Fri Feb 3 17:53:09 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W5L4 
<li>problem n: 1623 
<li>Status: needs_longterm_monitoring
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Changing IMON limits. Current central value is slightly below the low End. Current is stable (although changing sliughtly depending datataking to 'idle' state). <table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1120.73</td><td>1120.73</td></tr>
<tr><td><b>Lower</b></td><td>1115</td><td>1100</td></tr>
<tr><td><b>Upper</b></td><td>1135</td><td>1135</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Feb 3 18:58:52 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8273&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8273  width='300' align='top'></a></td><td><h3>Bias PINKY</h3> 
 
<p>Just noticed this Bias pinky for IB1W1L2.  There was a sudden jump from ~1175uA to ~2100uA.  This ladder has a pin-hole so it is a known problem. But it may be getting much worse.</p> </td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Fri Feb 3 19:00:31 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8274&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8274  width='300' align='top'></a></td><td><h3>Bias History for IB1W1L2</h3> 
 
<p>The bias current for this ladder has been jumping up and down for a while.  So no real surprise this is giving a pinky.  We should look at this ladder during the shutdown and see if we can play with the Bias.</p></td></tr></table>
<!-- Author: Ankush -->
<!-- Comment: Fri Feb  3 19;07;28 comment by...Ankush -->
<p>I have just put this cell to IGNORE and told the ACE to keep an eye on it.  If bias stays at this larger value in the morning, then I'll change the upper IMON limit.</p>

<!-- Date: Fri Feb 3 19:10:07 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W1L2 
<li>problem n: 790 
<li>Status: needs_longterm_monitoring
<li>Type: pinhole
<li>Action: Monitoring
<li>entered by: amitra 
<li>description is: <p>The bias for this ladder jumped up from 1175uA to 2100uA.  It is a know pinhole and ther Z side is not fully depleated.  However Monitoring should check how depleted this ladder is.  During the shudown, we may be able to adjust the bias splitting and bias value to get both sides working...maybe?</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Feb 4 01:27:10 2006 -->
Problems with the TEL. MCR can not recover withtin the 10min window, AGIGI2 got to 9E9 and the Si was put to STBY. See <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=103&frame=2&anchor=01:11:34.519'> 
this</a> plot.
<!-- Author: Sebastian -->
<!-- Comment: Sat Feb  4 02;38;14 comment by...sebastian -->
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=103&frame=2&anchor=02:33:55.176'>
Again</a>.

<!-- Date: Sat Feb 4 09:19:39 2006 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 431
Calibration type  : nonstandard
Run period tag    : Feb_2006
DPS-off run       : 211270
DPS-on run        : 211269
Requested by      : Dean
Main process id   : 18237
Comment           : Beam on.  everything else standard.
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->


<!-- Date: Sat Feb 4 10:13:58 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W6L3 
<li>problem n: 1624 
<li>Status: svxmon_ignore
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>for some reason SVXMON is still looking at this ladder even though it is unfixable.  So I'm adding this SVXMON ignore to hopefully fix this.</p>  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W6&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Feb 4 14:29:57 2006 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 431 finished successfully.

Job info
--------
Calibration type : nonstandard
Beam condition   : on
DPS-off run      : 211270
DPS-on run       : 211269
Requested by     : Dean
Submitted        : 2006-02-04 09:18:26
Completed        : 2006-02-04 14:29:39
Status           : SUCCESS
Comment          : Beam on.  everything else standard.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->
<!-- Comment: Mon Feb  6 08;58;43 comment by...Jason Nielsen -->
If everything is "standard," then the calibration should not be marked "nonstandard!"  I changed the calibration type in the database, and it is being assigned to new data runs.
<!-- Date: Sat Feb 4 16:20:17 2006 -->
<pre>Oscar and I took another bias scan with beam today.  We split the data into two runs.  In the first run, 211272, we varied only L00 bias voltages.  In the second run, we varied SVX L0 bias voltages as well.  Both runs used a new mix of track triggers. 
 
/cdf/onln/data/svxii/caencontrol/PSfiles/caenvoltsfiles/CAENvolts_02022006_1105AM.dat 
 
voltage run iev fev 
-130 211272 0 310968 
-110 211272 310969 396370 
-90 211272 396371 449859 
-70 211272 449860 513704 
-50 211272 513705 550850 
-30 211272 550851 600115 
-10 211272 600116 651720 
0 211272 651721 704848 
-120 211273 0 104316 
-100 211273 104317 143448 
-80 211273 143449 200791 
-65 211273 200792 250513 
-60 211273 250514 301951 
-55 211273 301952 351951 
-45 211273 351952 400307 
-40 211273 400308 450534 
-35 211273 450535 500223 
-25 211273 500224 551641 
-20 211273 551642 599936 
 
Voltages are back to their nominal values.</pre>
<!-- Author: boveia -->


<!-- Date: Sat Feb 4 16:41:35 2006 -->
Got paged because of a pinkie in DVDD, e414. Oscar is there and he will look into it. Thanks.
<!-- Author: Sebastian -->
<!-- Comment: Sat Feb  4 17;20;20 comment by...Oscar -->
Doing COLDSTART seemed to work. I will keep an eye on it while supervising shot-setup and beginning of new store. Reference link is <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=105&frame=2&anchor=16:34:07.358'>
here</a>



<!-- Date: Sat Feb 4 18:32:31 2006 -->
The SVT SpyMon plot should appear here. However, they changed something in the configuration and the plot is not available on the web. Stefano tells me that they will work on it and thet I can check it in the CO plots. I checked and it looked fine. If anybody knows an easy way of posting the plot, do not hesitate :) 
<br> 
SVXMon also looks fine, this is store 4624, with initial luminosity of 114E30. 
  
<!-- Author: Oscar -->


<!-- Date: Sat Feb 4 18:37:22 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8275&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8275  width='300' align='top'></a></td><td>This is the previous pinky (SB4W1L4, e414, DVDD). It was stable since we set it back to normal with config. However, there was an increase when datataking started. The second increase was right after a prescale change (in fact the small step up after that was also a prescale change). No action taken for now. </td></tr></table>
<!-- Author: Oscar -->


<!-- Date: Sat Feb 4 20:10:43 2006 -->
Store 4624 was short lived. It ended in a quench with no apparent problems for us (no pinkies, no problems in coldstart). However the crew (Anna) could not make the BLM plots because ACNET was not working correctly. I also tried from home but could not connect to the remote server. MCR has been notified and is working on it.
<!-- Author: Sebastian -->
<!-- Comment: Sat Feb  4 20;38;12 comment by...s -->
See <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=105&frame=2&anchor=20:28:50.156'>
this</a> entry.




<!-- Comment: Sat Feb  4 22;24;55 comment by...Sebastian -->
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=105&frame=2&anchor=21:42:47.759'>
BLM</a> plot.


<!-- Date: Sun Feb 5 06:21:10 2006 -->
Store 4627 in. Everything looks Ok this far.
<!-- Author: Sebastian -->
<!-- Comment: Sun Feb  5 09;16;00 comment by...s -->
SVXMon is (and was) fine...


<!-- Date: Sun Feb 5 14:33:25 2006 -->
More CCC work: today we spend the morning working on the CCC, trying to get the glitcher to work. After some problems (mostly due to my errors) we got the setup ready, but found that we can not see the glitches in the LA. We now think that the problem was the trigger on the LA...
<!-- Author: Shulamit and Sebastian -->


<!-- Date: Sun Feb 5 18:25:13 2006 -->
Updated my history of quenches with data for 2003. Those who are interested can check the history <a href= 
'http://www-cdf.fnal.gov/internal/people/links/AlexandrePronko/silicon/quench_history.html'> 
here </a>. Comments are welcome!  
Here is a list of things still to be done: 
<ol> 
<LI> Add data for year 2002</li> 
<LI> Add data for period from Oct-05 till March-06</li> 
<LI> Global summary of all affected ladders</li> 
<LI> When available, add information on AGIGI2</li>  
</ol>
<!-- Author: sasha -->


<!-- Date: Sun Feb 5 19:13:14 2006 -->
Some <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=108&frame=2&anchor=16:52:59.452'> 
problems</a> with e012 after a hockerization. All done correctly by the crew.
<!-- Author: s -->

<!-- Date: Mon Feb 6 08:05:26 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W1L2 
<li>problem n: 790 
<li>Status: needs_longterm_monitoring
<li>Type: pinhole
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>I guess the new bias lievel was stabel over the weekend.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td></td><td>1575.31</td></tr>
<tr><td><b>Lower</b></td><td>??</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>??</td><td>2015.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Feb 6 08:12:07 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8276&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8276  width='300' align='top'></a></td><td>Integrated Dose Alarm... once again, during squeezing.</td></tr></table>
<!-- Author: Jennifer :-) -->
<!-- Comment: Mon Feb  6 08;47;44 comment by...Ankush, Oscar, Ulrich, Jennifer :-), Sebastian -->
<pre>Fortunatly Ulrich & Jennifer were in the control room; so RadCo were already here. Guram then called MCR to let them know about the  alarm.

Ron: Any ideas why this happened ?</pre>



<!-- Comment: Mon Feb  6 09;50;16 comment by...Jennifer :-) -->
Please see <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=286&frame=2&anchor=09:49:03'>
better picture</a> here.
<!-- Date: Mon Feb 6 09:02:21 2006 -->
<h3>Week Summary</h3> 
<ul>  
<li><b>Monday:</b> Some SVX/L00 ladders tripped due to (Steve H) work on the CLK. A config was issued in time, no no major trip. 
More debugging of f002 (in two accesses), the problem is internal (and it is not the PS). Note that though the ladder was not giving data since (since soon after? - 15/Jan) the 14/Jan big quench. A store was aborted with AGIGI2 at 25E9 - no SVRAD dose. 
<li><b>Tuesday:</b> Store 4618, initial lumi: 120E30. Int dose alarm during sqeeze. New (tmp) LA in 1st floor, caught glitch during nearby work. 
<li><b>Wednesday:</b> silicon baggy will not be openned during shutdown (unless stronger reason).  
<li><b>Thursday:</b> major CLK trip when Accelerator people reboot a central CLK crate (TeVLLRF). Lots of work to bring system back (f843). Next store came,4621 with initial luminosity: 75E30. Hockerized IB4W0. 
<li><b>Friday:</b> Another store, 4623 with initial luminosity: 106E30 
<li><b>Saturday:</b> Problems with TEL. Need to change TeVmon warning to say that crew has 10min before putting Si to STBY. 
BIAS scan. Store 4624 was short. 
<li><b>Sunday:</b> Store 4627 in. 
</ul> 
Monday: Store #: 4628, 125E30.<br>
<!-- Author: Oscar/Sebastian -->


<!-- Date: Mon Feb 6 09:49:03 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8277&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8277  width='300' align='top'></a></td><td>A better view of the integrated dose alarm... following Ulrich's suggestion of a shorter time-window to see more easily who pulled the alarm. I stick with SVRAD0 (west, inner... shown in green). </td></tr></table>
<!-- Author: Jennifer :-) -->