<!-- Title: 09:13:53  Mon Oct 31 2005 -->
<!-- Crewchief: Juan Pablo -->
<!-- Op1: Sebastian  -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre><pre><br>Chosen we have ... and we will be free serving what we've chosen. 
It will seem we are slaves of our decision but in fact it is multiplying us. </br> 
<br>"One is only free when he follows something pasionately." 
</br> 
  <br>  Martin Descalzo.</br> 
 
  </pre></pre>


<!-- Date: Mon Oct 31 10:46:58 2005 -->
Raised the handbrake to 33kHz to facilitate running the default trigger table at 139E30 (initial L1 rate was 30.8kHz and dead time 14.4%). 33kHz is the current limit imposed by the number of resonances we can take while trying to run... already high at this rate.
<!-- Author: Sebastian -->

<!-- Date: Mon Oct 31 10:51:13 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W0L4 
<li>problem n: 1506 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: fernand 
<li>description is: changing limits on this ladder<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>-</td><td>-</td></tr>
<tr><td><b>Lower</b></td><td>-</td><td>-</td></tr>
<tr><td><b>Upper</b></td><td>100</td><td>145</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Oct 31 14:17:00 2005 -->
We had lots of problems at the beginning of this store (4477), first the COT and then L2. Then the PS crate 7 returned information was screwed up (Marcel caught it while in the CR) and the crate had to be hockerized. Also, when Vadim changes L2 so that it returns a TO to the TS when it gets a bad event, the EVB started getting DMA transfer errros, possible (but we do not know yet) beacuse of conflicts in the silicon crates while trying to access the VRBs. We don not care about the L2 TO, we should only see a L2R from the TS, so I am not sure what was going on. 
<!-- Author: Sebastian -->

<!-- Date: Mon Oct 31 14:40:51 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W10L4 
<li>problem n: 603 
<li>Status: needs_longterm_monitoring
<li>Type: Chip_other
<li>Action: Monitoring
<li>entered by: alscott 
<li>description is: Everything looks good for this ladder--all chips look good in ADCmon, except for the sparsed out chips 89, 88, and a2.  DS EM reports a high error rate, but that is only from sparsed-out chip 88's stuck cap id.  Monitor for 2 weeks and if no problems declare fixed. 
<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: Mon Oct 31 15:39:58 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7780&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7780  width='300' align='top'></a></td><td> SVT spy mon is fine</td></tr></table>
<!-- Author:  Juan Pablo -->


<!-- Date: Mon Oct 31 17:26:32 2005 -->
<h3>More on SVXMon & Stuck Cell Id</h3> 
 
We did some more research regarding the stuck cell id problem from this <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=272&frame=2&anchor=13:07:29'>entry</a> and found that SVXMon is not masking ladders for stuck cell id errors based on the PDB entries, but rather this file: /cdf/svx/data1/svxmon/SvxMonConfig/stuckChips.txt.  The ladder of interest, e044, is not masked in this file, so it is still unclear why an SVXMon restart fixed the problem.  Probably there is an SVXMon bug involved.  If the problem appears again we should tell the ACEs to restart SVXMon.  If that does not work we can try editing stuckChips.txt.  Meanwhile I will look into e393 to see if that yields any more info.
<!-- Author: Juan Pablo/Sebastian/Mark -->
<!-- Comment: Tue Nov  1 09;00;16 comment by...sasha -->
<pre>But how about e154 and e393 which are marked as "needs_access_8hr" in problem database? CO and ACEs reported that these ladders also caused HRR's.</pre>
<!-- Date: Mon Oct 31 18:47:46 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W0L3 
<li>problem n: 1503 
<li>Status: needs_longterm_monitoring
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: fernand 
<li>description is: changed bias limits<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>100</td><td>125</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>110</td><td>150</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Oct 31 19:32:12 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7785&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7785  width='300' align='top'></a></td><td> AGIGI2 at the end of every store 
 (store 4269 is not there; it had a value of 10 but due to the fact that the acelerator people played with the beam at the end of store and at the same time we-CDF people- did some tests)</td></tr></table>
<!-- Author:  Sebastian / JP -->
<!-- Comment: Mon Oct 31 19;33;58 comment by...Sebastian/JP -->
<pre>We looked at the stores with the highest AGIGI2 and all terminated
gracefully. So, according to these results, we could run safely 
up to 7 Ex09 in AGIGI2.</pre>


<!-- Comment: Wed Nov  2 15;28;48 comment by...s -->
I think we can count the entry at 10 too, since we only care about whether the abort was clean.
<!-- Date: Tue Nov 1 00:02:15 2005 -->
<h3>More work on triggers and resonances</h3> 
 
Tonight I took advantage of some trigger changes that Ted and Veronica wanted to do to furhter study the resonance dependance on trigger rates (during run 206326). We ran at 32kHz with on initial luminosity of 50E30, with very low resonance rate, about 4-3reso/hr. This suggest to me that the number of resonances is luminosity dependenace... a few days ago (run 206251) at a similar l1 rate we got about 16reso/hr. A first comparision of RDBS signals seems to indicate that the width is larger at lower lum, so we pull less resonances, but this will have to be studied. 
See also <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=912&frame=2&anchor=20:11:13.635'> 
this</a> entry in the main elog. 
<br>
<!-- Author: Sebastian, Veronica and Ted. -->


<!-- Date: Tue Nov 1 00:04:04 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7788&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7789' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7786&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7787' ></a></center>
<!-- Author: Sebastian -->
<!-- Comment: Tue Nov  1 00;08;53 comment by...Sebastian -->
Two ladders acting up... e080 came back after the PS was reset (6), 
while e112 had that strange behavior in VBIAS (which I was afraid
may have been caused by spikes in B0AAGC, see main<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=912&frame=2&anchor=22:36:56.148'>
elog</a>), furtunatelly it came back by itself.


<!-- Date: Tue Nov 1 08:45:35 2005 -->
<pre>b0svx06:Messenger:Nov 1, 2005 8:37:36 AM->SRC Fatal Error:Sl 6 L2A w/o L1A  
 -->   
 Additional Information:  
 
 Attention !!!. FERML_SRC_FATALITY ERROR !!!  
  
 SRC Fatal Error from b0svx06: Sl 6 L2A w/o L1A  
  
 - HALT the run                    
 - record any relevant information in e-log      
 - RECOVER - RUN      
[MLE] 
(MLE) b0svx07:Messenger:Nov 1, 2005 8:37:35 AM->Silicon Resonator: Sl 08 Ch 6 -> f411: Bytes: 00106 
 
1 crate/s: b0svx06(16),  in error. [RXPT] 
(RC)   8:37:44 Halt -> HALTED 
(RC)   8:37:50 Recover -> RECOVERED 
(RC)   8:37:52 Run -> ACTIVE</pre>
<!-- Author: Juan Pablo -->



<!-- Date: Tue Nov 1 13:17:32 2005 -->
<pre>When putting silicon in stdby, IFIX lost comunication with 
svxinter. Restarting svxinter worked. The PS Gui had to be 
restarted as well. Now, everybody is in STDBY.</pre>
<!-- Author: Sebastian / Juan Pablo  -->


<!-- Date: Tue Nov 1 14:11:52 2005 -->
<h3>Silicon is OFF for cooling work.</h3>
<!-- Author: Sebastian -->
<!-- Comment: Tue Nov  1 17;22;46 comment by...Juan Pablo/Sebastian -->
During cooling work the coll hall racks tripped. Some
FIB crate CPUs had to be rebooted. 
We are back to STBY now (except for e3a4 which is giving problems).
<!-- Date: Tue Nov 1 15:12:07 2005 -->
<h3>Air Dryer Removed</h3> 
Warren and KC removed the broken air dryer in the pressurized air supply for the silicon cooling system (see also <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=272&frame=2&anchor=12:53:14'>here</a>). The pneumatic actuators for valves in the cooling system shut down if they are not connected to pressurized air. Hence, as expected, the cooling tripped during this operation, including the compressors in both the SVX and the ISL chiller.  
<p> 
After the air dryer was replaced by a valve manifold, Warren and KC found and replaced one leaking air line. Then we re-established flow to the detector (only L00E, L00W, and the whole ISL east side tripped) 
<p> 
One thing left to do: we performed our regular reboot of SVXIICON.
<!-- Author: Jennifer & Ulrich -->
<!-- Comment: Tue Nov  1 16;13;19 comment by...Ulrich -->
<br>
I forgot to mention: the e-valves in L00E and L00W are back to their default values (37% from 42% for L00E, 70% from 80% for L00W). 
<!-- Date: Tue Nov 1 15:29:16 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7790&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7790' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7791&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7791' width='300'></a></center>
<!-- Author: boveia -->
<!-- Comment: Tue Nov  1 15;30;06 comment by...boveia -->
<br> f044 chip 0x9a, then (left) and now (right).  No physics.

<!-- Comment: Tue Nov  1 15;44;22 comment by...boveia -->
<pre>I retreat from any statement about the physics content in either plot.  The distribution on the right resembles distributions for the other chips on this ladder, with roughly the same number of events at high charge.  Thus, the left plot might be the abnormal one.  In any case, we should watch this ladder.</pre>
<!-- Date: Tue Nov 1 15:30:45 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W4L4 
<li>problem n: 1566 
<li>Status: needs_urgent_monitoring
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: No physics on chip 10 (0x9a) in run 206285.  See <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=273&frame=2&anchor=15:29:16'> elog</a>. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W4&layer=L4">report</a></ul>
<!-- Author: Problem DB -->





<!-- Date: Tue Nov 1 16:33:35 2005 -->
<pre>After the cooling work we put the silicon to stdby. 
All ladders that should be on stdby are on stdby except SB3W10L4 
(AVDD overcurrent). I will give it some time and try later.</pre>
<!-- Author: Juan Pablo / Sebastian -->
<!-- Comment: Tue Nov  1 18;17;08 comment by...Sebastian -->
<br><b>e3a4 is back!</b>
I think the problem to recover this ladder might be temperature related...


<!-- Comment: Tue Nov  1 18;55;51 comment by...Marcel -->
this ladder has a history of tripping during accesses. it happened already twice. So i guess temperature/humidity dependence is the right guess
<!-- Date: Tue Nov 1 18:27:33 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7792&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7792' width='300'></a></center>
<!-- Author: Sebastian -->
<!-- Comment: Tue Nov  1 18;29;42 comment by...Sebastian -->
Temperatures in BHE1, where e3a4 lives. May be this ladder is more sensitive to temperatures changes... The ladder could be turn to STBY at 18:10.



<!-- Date: Wed Nov 2 04:17:41 2005 -->
<br>So, new store  (4480) and ...</br> 
<br>While we were running (run 206414) we lost the communication 
with CAEN PS 7.</br> 
We did the usual thing, i.e., put system in halt, hockerize the crate and reset trips. Seems are fine silicon wise ...</br>Data is not compromised (at least looking at SvxMon, those 
the mean strip charge seems normal for the wedges connected to 
that PS crate, IB0W4, IB0W5, IB2W2, LB0W0, LB0W5, 
(b0fib03)).</br>  
<!-- Author: Juan Pablo / Sebastian -->


<!-- Date: Wed Nov 2 09:01:55 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7793&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7794  width='300' align='top'></a></td><td> I forgot about spyMon ...</td></tr></table>
<!-- Author: Juan Pablo -->


<!-- Date: Wed Nov 2 09:05:43 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7795&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7795  width='300' align='top'></a></td><td> just a pinky DVDD for a sec...</td></tr></table>
<!-- Author:  Juan Pablo -->


<!-- Date: Wed Nov 2 11:47:09 2005 -->
<h3>More resonances/trigger rate studies</h3> 
Today we took the system when the inst lum was 66.5E30 and fully enabled FPS and UPS. We got up to 36.5kHz but were getting too many resonances (hadnbrake was 45kHz, ticks 10), this was run 206426. 
The resonace rate was about 36reso/hr. So I inceased the number of ticks to 12 (and expected a rate about 10 times lower). We started run 206427, ran for 40min, and got about 5.6reso/hr. No pinkies or jumps in IMON, and the ladders with jumper failures looked fine. 
<br> 
This is a list of interesting runs for resonances/trigger rate tests:<br> 
<pre> 
205416 205417 205418: studies with no solenoid 
205559 this run we hit 50kHz due to XTPR freak out. 
206251 tried to use default trigger table at the beginning of run (failed 
       because of other problems, so we increased manually the FPS rate) 
206326 enabled UPS at 50E30, handbrake was 33kHz 
206426 ticks=10 ilum=66 
206427 ticks=12 ilum=66 
</pre>
<!-- Author: Sebastian, Veronica, Ted (and Jonathan) -->
<!-- Comment: Wed Nov  2 11;53;16 comment by...Sebastian -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7796&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7796 width='300' align='top'></a></td><td>AVDD current of e494 during runs 206426 and 206427</td></tr></table>

<!-- Comment: Wed Nov  2 17;46;12 comment by...Sebastian -->
Resonances settings are now num kicks 11 and handbrake 40kHz.
<!-- Date: Wed Nov 2 13:35:17 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W2L4 
<li>problem n: 1423 
<li>Status: needs_urgent_monitoring
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: alscott 
<li>description is: Garbage data is back in run 206415.  If it persists in the next couple runs, pass to detector.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W2&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Nov 2 13:39:33 2005 -->
<pre>SB1W5L1 :  
The CAEN power supply lost comunication with it (in particular AVDD current) 
We hockerized the correspondent CAEN PS 5 and came fine 
(tried first turning the wedge off and on but did nothing).</pre>
<!-- Author: Juan Pablo / Sebastian  -->

<!-- Date: Wed Nov 2 13:41:38 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W11L0 
<li>problem n: 1493 
<li>Status: needs_longterm_monitoring
<li>Type: DropReadOut_nonRX
<li>Action: Monitoring
<li>entered by: alscott 
<li>description is: Error-free since run 203190 (2005.08.23).  If no error in next 2 weeks declare fixed. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W11&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Nov 2 14:05:34 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7798&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7799  width='300' align='top'></a></td><td> </td></tr></table>
<!-- Author:  Juan Pablo -->
<!-- Comment: Wed Nov  2 14;08;46 comment by...Juan Pablo -->
<pre>AGIGI2 went way above known limits ... 
Losses also starting to increase. See the plot above
</pre>



<!-- Date: Wed Nov 2 17:11:00 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7800&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7800' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7801&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7801' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Wed Nov  2 17;13;45 comment by...Ankush -->
<h4>Bias Current for IB1W4L0</h4>

<p>The Bias current for this ladder went over its upper IMON limit.  It looks like the usual gradual increase due to radiation damage.  Doing the usual linear fit, I will set the new upper IMON limit to 1212.  This should give enough room till 1st March; the start of the shutdown.</p>

<p>But one thing to note is the Bias Current is already quite large for this ladder.</p>

<!-- Date: Wed Nov 2 17:23:23 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W4L0 
<li>problem n: 1567 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>This ladder passed its upper IMON limit.  Now increased.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1069.0</td><td>1069.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>1130.0</td><td>1212.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W4&layer=L0">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Wed Nov 2 17:47:36 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7802&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7802  width='300' align='top'></a></td><td><h4>MCR monkeying with electron lens</h4> 
 
<p>About an hour ago we asked the MCR to clear up the Abort-Gap as AGIGI2 (count of particles in the Abort Gap).  So now they started (without telling us first) and silicon is on STANDBY until furthur notice.  Meanwhile CDF is running without silicon.</p></td></tr></table>
<!-- Author:  Ankush -->
<!-- Comment: Wed Nov  2 18;12;11 comment by...Ankush -->
<p>MCR did a good job and all our ACNET variables have gone down and look nice.  Silicon is back in taking data.</p>


<!-- Date: Wed Nov 2 21:02:15 2005 -->
<h4>RF Trip: Store Lost</h4> 
 
<p>A second RF station tripped off resulting in a lost store.  The Abort was clean for us.The shift crew did a post-quench check out and silicon went through COLDSTART with no problems along with no PINKIES in IMON.</p> 
 
<p>See <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=918&frame=2&anchor=20:27:52.220'> 
CDF shift e-log </a> for the BLM plots.</p>
<!-- Author: Ankush -->


<!-- Date: Thu Nov 3 04:44:03 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7803&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7803  width='300' align='top'></a></td><td> Spy Mon shows the usual 3 SVT "holes" ... 
 Regarding SVxMon, no problems</td></tr></table>
<!-- Author:  Juan Pablo -->
<!-- Comment: Thu Nov  3 04;45;09 comment by... Juan Pablo -->
<pre>Initial inst. luminosity was 160E30 s-1 cm-2 ... fingers keep crossed ...</pre>


<!-- Date: Thu Nov 3 11:56:14 2005 -->
<pre>e044 is giving stuck cell id errors according to the rc error log 
(run 206537 ). 
The ladder in other runs recently, the errors I see 
do not look like stuck cell id to me ... 
</pre>
<!-- Author: Juan Pablo -->

<!-- Date: Thu Nov 3 13:27:22 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W3L2 
<li>problem n: 717 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: fernand 
<li>description is: changing limits again <table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>105</td><td>255</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>250</td><td>380</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W3&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Nov 3 14:27:28 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W2L4 
<li>problem n: 1423 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: alscott 
<li>description is: Garbage data is back.  The error rate has been above 10% for the past 8 runs.  Pass to detector. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W2&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Nov 3 15:34:55 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7804&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7804' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7805&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7805' width='300'></a></center>
<!-- Author: Adam Scott -->
<!-- Comment: Thu Nov  3 15;40;05 comment by...Adam Scott -->
In the process of trying to further diagnose f044, I found a difference between ADCmon and daqana.
<br><br>
The left plot is from ADCmon (see <a href=http://nucsb03.fnal.gov/cgi-bin/hdirunplot?filename=ar03266d.0001.root&hdi=f044>here</a>).
The right is from daqana.  
<br><br>
Both plots are the ADC distribution in chip 10 of f044, in the same run: run 206445 (0x03266d).  Why are they so different?  I'll go ask David Stuart.


<!-- Comment: Tue Nov  8 12;25;36 comment by...David Stuart -->
<pre>Adam and I poked at ADCMon and daqana and understood why the two sides are different. ADCMon filters noisy channels while the plot on the right includes all of the channels. The long tail on the right is due to just two noisy channels.

For the record, ADCMon's filtering is done by:

1). Masking off any channels specifically listed as bad in
a file.

2). Masking off any channels that are over threshold more than
X% of the time. Where the values for X are layer dependent and
where crudely set by hand many years ago. X=0.1 for SVXII, 0.15 for ISL, and 0.5 for L00.

The second masking step is what removes the two noisy channels for the plot on the left.

One of the questions here is why does the cleaned up plot on the left have less of a tail from physics than we remember from long ago. There are two possible answers:

a). The number of events used is less than previously. I've been using 2000 events per run instead of the previous 4000 just to save CPU time. That change went into effect in mid 2005.

b). This is layer 7 which is very far from the beam so there is really not that many particles. What we see on the right is what you'd expect for lower R layers, but layer 7 is not very occupied .

My suspicion is (b), but I don't have time to quantify that now.
</pre>
<!-- Date: Fri Nov 4 17:39:42 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7806&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7807  width='300' align='top'></a></td><td> f533 just turned pink, after coldstart is back within 
limits  </td></tr></table>
<!-- Author:   Juan Pablo -->


<!-- Date: Sat Nov 5 19:43:42 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7808&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7809  width='300' align='top'></a></td><td> 206694 (store 4489 ) 
 started with 130 E30 cm-2 s-1 
 problems with CMX , BMU  ... silicon fine so far (SVXMon)</td></tr></table>
<!-- Author:  Juan Pablo -->


<!-- Date: Sun Nov 6 01:53:21 2005 -->
<pre>Based on high losses the shift crew decided to put silicon on stdby 
for some time ( approx 1/2 hour ). B0PAGC is ~10KHz and not spiky 
as before. Running with silicon back again. 
See cdf e-log entry <a href='/cgi/elog/elog.pl?nb=2005&action=view&page=928&frame=2&anchor=01:49:10.684'>here </a> </pre>
<!-- Author:  Juan Pablo -->
<!-- Comment: Sun Nov  6 01;59;01 comment by... Juan Pablo -->
<pre>Well, the situation was not that bad as I though (when
talking over the phone)... but better safe than sorry</pre>

<!-- Comment: Sun Nov  6 06;07;26 comment by... Juan Pablo -->
<pre>  Scico called the MCR and they do not feel confortable on doing a cleaninig of the abort gaps (all the other variables L1COLI, AGIGI2, RFSUM, are fine, also the inst. luminosity behaves fine).
  The mean is a bit bellow 18 KHz for B0PAGC with a sigma of 2 KHz
(so we go to warning often but we are seldomly on danger state ...
so close but not there yet)
  I will stay here monitoring the behaviour ... that is stable and
as I have described above ... in case of any change towards getting
worse we will put Si on stdby (it was on stdby for a while).</pre>

<!-- Comment: Sun Nov  6 08;50;44 comment by... Juan Pablo. -->
<pre>Saw a sudden change in losses. Now we are between 20 and 22 KHz.
Silicon is on stdby. I asked MPC to ask the experts if they
are willing to do something to reduce the abort gap...
if they do nothing, we just keep on stdby and see...
(see the elog entry at 8:36 am)

This is going to be the Sunday of the abort gap losses ... 
ah yeah, that Sunday ... a Sunday to remember ...</pre>


<!-- Comment: Sun Nov  6 13;26;16 comment by... Juan Pablo / Ankush -->
<pre> Now what happened ?
 The electron lens where dropped, then the AGIGI2 went high
(up to 10) but B0PAGC went down.
 Now they are trying to fix this. Electron lens are back on
and AGIGI2 is comming down. </pre>
<!-- Comment: Sun Nov  6 13;40;48 comment by... Juan Pablo / Ankush -->
<pre>CDF-Elog entry above the previous incident
<a href='/cgi/elog/elog.pl?nb=2005&action=view&page=929&frame=2&anchor=13:30:15.027'>
here </a>
</pre>
<!-- Date: Sun Nov 6 09:31:47 2005 -->
<h4>Overnight Ladder & PS Trip</h4> 
 
<p>23:23 5 November, SB4W9L4 tripped on AVDD.  (see <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=927&frame=2&anchor=23:32:52.065'> 
here</a> in CDF shift e-log).  This ladder was one of the ones which tripped during last months high L1A incident.</p> 
 
<p>04:48 6 November, CAEN PS 9 (NE Top Top) switched off. (see  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=928&frame=2&anchor=05:01:05.321'> 
here</a> in CDF shift e-log) 
</p> 
 
<p>Both of these trips were recovered by the ACEs</p> 
 
  
<!-- Author: Ankush -->




<!-- Date: Sun Nov 6 14:10:14 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7811&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7811  width='300' align='top'></a></td><td><h4>Checking Rick's Counters</h4> 
 
<p>So we been seeing very high losses in B0PAGC while all the other counters are fine.  So first thing to check we are seeing something real. So I plotted the output of the 4 individual counters (B0PBN, B0PBT, B0PBS, B0PBB), the total rate (B0PBSM) and B0PAGC.  In addition I plotted the output of the Scintillator telescope at E0 (E0LABT).</p> 
 
<p>The important feature of this plot is all the counters are consistent with each other.  So we are defintily seeing something real and Ricks counter are working fine.</p> 
 
<p>So back to the big question...why are the looses so high ?</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Sun Nov 6 17:50:23 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7816&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7816' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7817&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7817' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7818&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7818' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7819&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7819' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Sun Nov  6 18;03;09 comment by...Ankush -->
<h4>Evolution of Losses</h4>

<p>The 4 ACNET plots above show how the Tev Abort-Gap losses (B0PAGC, B0AAGC) have grown along with Abort-Gap Particle Content (AGIGI2).  The Electron lens current is also drawn.</p>

<p>From left to right are the plots for Stores 4414, 4485, 4488 and 4489.  Store 4414 show how the Abort Gap losses used to look like..very small and nothing to worry about.  Then the Tevatron tuning changed in October.  There was some temporary change in AGIGI2 and the Abort Gap losses. But they settled down as can be seen for store 4485. After this store, something changed and now our B0PAGC is much larger than before.  However it was always below our limit of ~20KHz.  Then today's store 4489 came in (the one on the right) and you can see B0PAGC is much higher than our limit of 20KHz.  THe MCR were not comfortable in doing anything to reuced these losses.</p>

<p>So even considering the new tunes and we have been running at higher than "normal" Abort Gap losess, this value for B0PAGC is much, much higer. The big question is why ?</p>


<!-- Date: Sun Nov 6 18:13:15 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7820&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7820' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7821&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7821' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Sun Nov  6 18;21;07 comment by...Ankush -->
<h4>Latest Update on Sotre 4489</h4>

<p>B0PAGC is not growing as fast but it is hanging around 25KHz. Much larger than the B0AAGC.  An interesting thing to note was around 13:00 when the Electron Lens was temporarily lost.  As soon as it went down, the B0PAGC dropped immediately and then rose again once the lens was back in.</p>

<p>The Electron lens is needed to clear particles out of the Abort Gap.  As the current absolute value of AGIGI2 is not that high given the current value of B0PAGC...is the following possible.  The Electron lens is actually doing a very good job and efficiently cleaning out the abort gap...by giving the particles in the abort gap a little kick. It is doing so well that we are now observing the much larger B0PAGC ?</p>


<!-- Date: Sun Nov 6 19:07:43 2005 -->
<h4>Interesting posting from Jim Morgan</h4> 
 
<p>The Plan: End of store check of <b>TEL timing</b> begins at 1930 and should take about 30 minutes. Afterwards, terminate the store and follow with shot setup for a Recycler-only shot, protons 265-285E9 per bunch in the Tevatron at 150 GeV. After the shot, resume stacking to 60E10 and sending pbars to the Recycler.</p> 
 
<p> - J. Morgan</p> 
 
<em>hmmm.....why would they want to check the TEL timings...curiouser and curiouser</em>
<!-- Author: Ankush -->
<!-- Comment: Sun Nov  6 22;13;58 comment by...ronmoore -->
Because the last 3 bunches in each train had poorer lifetimes than expected.  One reason is that the TEL pulses were mistimed to partially strike those bunches, thus reducing their lifetime.  Another reason the lifetimes could be worse is the pbar on proton beam-beam tune shift which is significantly different for the bunches on the front and back of each train.  Verifying TEL operation can rule out one those possibilities.


<!-- Comment: Sun Nov  6 23;07;32 comment by...Ankush (who has a lot to learn about acclerators) -->
<pre>Thanks Ron!!</pre>
<!-- Date: Sun Nov 6 22:52:34 2005 -->
<pre>Ok, this time was the time of the silicon ...  
an ISL ladder did not want to come to ON state (tripping on  
VIAS overvoltage). The ladder in particular is IB3W1L1. 
We took it out of the HRDB after the usual 3 trials. 
We should investigate it during quiet time.</pre>
<!-- Author: Juan Pablo -->
<!-- Comment: Sun Nov  6 22;54;09 comment by...JP -->
<pre>This ladder is ok according to the DB report</pre>

<!-- Comment: Sun Nov  6 23;04;46 comment by...Ankush -->
<p>hmmm...very wierd...I don&#39t remember ever seeing an overvoltage problem. O well something new.  Good thing the CO is good 'ol Silicon person. Thanks for helping out Florencia :-)!!</p>



<!-- Comment: Sun Nov  6 23;10;07 comment by...Ankush -->
<p>Here are the offending lines from the PSGui log file.</p>

<pre>
Sun Nov 06 22:27:05 CST 2005     IFix -  success: Silicon ON  
Sun Nov 06 22:28:09 CST 2005     TRIP: ISL  B3  W1 VBIAS01 OverVoltage
Sun Nov 06 22:29:28 CST 2005     success: Resetting trips
Sun Nov 06 22:29:34 CST 2005     success: Channel1 ISL B3 W1 ON
Sun Nov 06 22:31:06 CST 2005     TRIP: ISL  B3  W1 VBIAS01 OverVoltage
Sun Nov 06 22:31:57 CST 2005     success: Resetting trips
Sun Nov 06 22:32:06 CST 2005     success: Channel1 ISL B3 W1 ON
Sun Nov 06 22:33:37 CST 2005     TRIP: ISL  B3  W1 VBIAS01 OverVoltage
Sun Nov 06 22:34:53 CST 2005     success: Resetting trips
Sun Nov 06 22:35:30 CST 2005     success: Channel1 ISL B3 W1 ON
Sun Nov 06 22:36:53 CST 2005     TRIP: ISL  B3  W1 VBIAS01 OverVoltage
Sun Nov 06 22:40:07 CST 2005     success: Loading CAENvolts.dat
Sun Nov 06 22:41:41 CST 2005     success: Resetting trips
</pre>
<!-- Date: Sun Nov 6 23:07:23 2005 -->
<pre>SpyMon shows the typical 3 "holes" for the SVT and 
SVXMon is fine (the ladder we just got out shows in blue color 
as it should be). 
We are having troubles with L2 and have started a new run ... 
still debugging L2 ...</pre>
<!-- Author: Juan Pablo -->




<!-- Date: Sun Nov 6 23:16:52 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7822&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7822  width='300' align='top'></a></td><td> as promised </td></tr></table>
<!-- Author:  Juan Pablo -->


<!-- Date: Mon Nov 7 06:34:36 2005 -->
<pre> 
Things going on this week : 
 
 - handbrake studies by Sebastian, Veronica (raised L1 accept limit) : 
On run 206426 the L1 rate was 36.5 kHz. Handbrake was 45kHz, ticks 10. They got 
36reso/hr. With 12 ticks they got 5.6 reso/hr (while expecting 3.6) 
Inst lum was 66.5E30.  No pinkies or jumps in IMON, and the ladders  
with jumper failures looked fine. 
 
 - SVXMon & Stuck Cell Id (Mark) ...: SVXMon is not masking ladders for stuck cell id  
errors based on the PDB entries, but rather this file:  
           /cdf/svx/data1/svxmon/SvxMonConfig/stuckChips.txt 
   [ e393 did not gave us too much Stuck Cell Id errors this week ] 
 
 -  AGIGI2 : it seems we have had in the past a whole range of values for  
 AGIGI2 up to 10 [still a change in the pedestals can change AGIGI2 by a factor of 2] 
 
 - Cooling work : Air Dryer Removed. The broken air dryer in the pressurized air  
 supply for the silicon cooling system was removed. The e-valves in L00E and L00W are  
 back to their default values (37% from 42% for L00E, 70% from 80% for L00W).  
 
 - AGIGI2 vs B0PAGC :  
   AGIGI2 measures the no. of particles in the abort gaps 
   B0PAGC measures the no. of particles kicked out of the abort gaps 
   B0PAGC spotted above 20 KHz in the previous store but AGIGI2 was fine, so, MCR 
 was not comfortable trying to make a "better beam" because it was fine (according to them)... 
 and in the end we took silicon to stdby after having running for a good period of time just a bit bellow 
 the limit. 
 
  What I learnt :  
                  just once it happened that we lost the communication with a ladder 
                 but nothing showed up in the PS GUI. We got an trigger inhibit from IFIX 
                 but IFIX did not "complain" (making a series of sounds). Going to IFIX 
                 cdf logo -&gt; misc_menu -&gt; silicon inhibits you can know which was the guilty ... 
		  (just a reminder to myself) before rebooting svxinter, reboot PS Gui  
 
[  ... well the shift has not finished yet but I am going to paste this before I forget ...]</pre>
<!-- Author:  Juan Pablo. -->


<!-- Date: Mon Nov 7 08:47:56 2005 -->
<table border=0><td><tr><td bgcolor=#e0e030>Check out this  
<a href= 
'http://www-cdf.fnal.gov/internal/people/links/AlexandrePronko/silicon/quench_history.html'> 
link </a> for a history of quenches during 2004-2005 running period.  
</td></tr></td></table>
<!-- Author: sasha -->


<!-- Date: Mon Nov 7 08:57:24 2005 -->
<pre>needs monitoring: 
 
e1a4 - everything looks okay for now.  Monitor for 2 weeks and if everything okay declare fixed. 
e5b0 - error free for the past two months.  Declare fixed after 2 more weeks of monitoring. 
f044 - tail in ADC distribution has decreased over the last few months.  Unclear if it's a real problem or a monitoring software problem.  Checking the latter. 
 
needs work: 
 
e224 - garbage data for &gt;10% of events is back. 
</pre>
<!-- Author: Adam Scott -->

<!-- Date: Mon Nov 7 09:21:26 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W1L1 
<li>problem n: 1568 
<li>Status: needs_work
<li>Type: BIAS
<li>Action: Removed_hdwdb
<li>entered by: amitra 
<li>description is: <p>This was taken out of the harware database as it kept tripping on Bias0 overvoltage.  Should try to put it back when quiet time becomes available.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Nov 7 09:27:25 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W1L1 
<li>problem n: 1569 
<li>Status: needs_work
<li>Type: BIAS
<li>Action: Incident
<li>entered by: fernand 
<li>description is: This ladder resist to come to ON state (kept tripping on BIAS overvoltage). It will probably come back fine next time we integrate. I forgot to try powering off and on the whole wedge (will try to remember next time). 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->