<!-- Title: 10:21:10  Mon Nov 14 2005 -->
<!-- Crewchief: Shulamit  -->
<!-- Op1: Ankush -->
<!-- Op2: Sebastian -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Shulamit - first week as pager carrier. 
SPL on call - Ankush.</pre>

<!-- Date: Mon Nov 14 10:33:31 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W1L0 
<li>problem n: 1570 
<li>Status: fixed
<li>Type: Chip_capid
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Gone. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W1&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Nov 14 10:36:39 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W4L4 
<li>problem n: 1566 
<li>Status: fixed
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: No problem. 
<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: Mon Nov 14 11:09:36 2005 -->
<p>We were called by the Aces due to increased AGIGI2 and high spikes in the proton abort gap losses. We watched the losses and AGIGI2 for some time, called MCR and found out they were doing "something" with the tunes. As the losses seemed to be increasing steeply we put the silicon in Standby and ran without silicon. 
As soon as AGIGI2 value dropped below limit and went back to normal value and the losses were less spiky and more stable we included silicon again. 
plots can be found <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=953&frame=2&anchor=11:01:04.489'> 
here</a></p>
<!-- Author: Shulamit and Ankush -->


<!-- Date: Mon Nov 14 11:11:01 2005 -->
<pre>CAEN PS 3 lost communication, Ankush hockerized the crate, trips were recovered.</pre>
<!-- Author: Shulamit and Ankush -->


<!-- Date: Mon Nov 14 11:54:53 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7906&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7906  width='300' align='top'></a></td><td>AGIGI2 and proton losses from this morning, when we decided to take the silicon out for a while.</td></tr></table>
<!-- Author: Shulamit -->


<!-- Date: Mon Nov 14 19:53:19 2005 -->
<h4>Silicon Gallery</h4> 
 
<p>So you have been asked to make a silicon talk and you want to put some pretty pictures in.  But where do you go to get all the pictures.  You find out there are all over the place.  Why can't they be in the same place.</p> 
 
<p>Well you wishes have now been answered.  Have a look at the brand new <a href="http://www-cdf.fnal.gov/internal/silicon/talks/gallery/SiliGallery.html"> 
Silicon Gallery</a> which has just opened.</p>  
<!-- Author: Ankush -->


<!-- Date: Tue Nov 15 00:30:11 2005 -->
<h4>Lost monitoring of B0PAGC, B0AAGC....</h4> 
 
<p>Around mid-night (the witching hour) B0PAGC and B0AAGC both dropped to zero followed some time later with LOSTP and LOSTPB.  Then there was a PSM alarm for 1RR12C_4 Channel 1.</p> 
 
<p>As we had no monitoring, Silicon was put to STANDBY. No loss here as the store is about to be dropped at 1AM.</p> 
 
<p>From what I heard, Markus powercycled the affected rack and our monitoring returned. Looks like the Silicon crew owe Markus a free coffee.</p> 
<!-- Author: Ankush & Shulamit -->
<!-- Comment: Tue Nov 15 00;31;41 comment by...Ankush & Shulamit -->
<p>See <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=954&frame=2&anchor=00:00:18.046'>
here</a> for an ACNET plot showing the moment when we lost monitoring.</p>


<!-- Date: Tue Nov 15 00:37:21 2005 -->
<pre>There was a TevMon alarm for loosing monitoring of the abort gap losses. When I arrived Peter Dong was on the phone with Rick and was instructed to power cycle the relevant crate (appeared red on the rack alarm). 
TevMon was then fully moniroting again. 
If it happens again during the night Rick instructed to power cycle again, if it doesn't come up monitor in ACNET the parameter T:E0LABT. If this parameter appears flat then is should be fine to run with silicon but it's up to us to decide. 
Rick will come in the morning and have will check what's going on with this power supply.</pre>
<!-- Author: Shulamit -->


<!-- Date: Tue Nov 15 07:39:40 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7907&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7907  width='300' align='top'></a></td><td><p>Spymon plot for the beginning of store 4501. Initial luminosity 134.38. Store began with very high losses, we ran without silicon for about 3/4 of an hour and when losses dropped below limits and seem stable again we included silicon. <a href= 
'/cgi/elog/elog.pl?nb=2005&action=view&page=955&frame=2&anchor=07:24:40.482'> 
 link to ace plots at the beginning of the store</a></p></td></tr></table>
<!-- Author: Shulamit -->

<!-- Date: Tue Nov 15 09:51:17 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W4L2 
<li>problem n: 1572 
<li>Status: needs_urgent_monitoring
<li>Type: Chip_capid
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Chip b5 had stuck cap ID for 25% of run 207158. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W4&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Nov 15 11:58:23 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W11L0 
<li>problem n: 1493 
<li>Status: fixed
<li>Type: DropReadOut_nonRX
<li>Action: Monitoring
<li>entered by: yuji 
<li>description is: This ladder has no problem for more than one month. 
<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: Tue Nov 15 12:03:32 2005 -->
<br> 
The new setup scripts (/cdf/cdf.cshrc, ...) are on the b0dasvx0X 
machines. If you have problems with this let me know 
(<a href="http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=copyentry&page=936&time=17:42:43.995">reference</a>).  
<!-- Author: Sebastian -->


<!-- Date: Tue Nov 15 13:26:08 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7908&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7908  width='300' align='top'></a></td><td><h3>Beam Woes</h3> 
 
<p>Earlier in the day, the tunes were adjusted to reduce the losses for us.  That worked fine.  However we are now seeing an increase in B0PAGC with a similar increase in AGIGI2. </p> 
 
<p>At the moment both values are far below our safety limits.  But the gradient looks a little worrying.  If it continues to grow, we could have problems towards the end of the day.</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Tue Nov 15 21:44:43 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7911&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7911  width='300' align='top'></a></td><td><h4>Even more beam woes</h4> 
 
<p>I was just about to go home when I saw an entry in the ELOG: Run Terminated due to beam losses.  So I walk in to the Control Rool to find COT, Muons off and Silicon on STANDBY.  LOSTPB and B0AAGC started spiking like crazy...hence the Muon and COT trips. </p> 
 
<p>So we asked MCR and they were "looking into it". Eventually they twiddled whatever knobs they have and things  returned more-or-less back to normal.  However any explanation of what happened was completely lacking.  I guess they signed up to the accelerator non-proliferation treaty.  Hence their reticence in sharing any information.</p> 
 
<p>During this whole palava, I kept silicon out and watched the beam conditions for about 20 minutes.  The beam conditions looked better and I gave the go-ahead to start running with silicon.</p></td></tr></table>
<!-- Author: Ankush -->
<!-- Comment: Wed Nov 16 05;43;20 comment by...Ankush -->
<p>At the end of the MCR Evening Shift E-log, they say the sudden pbar losses are due to the Tevatron Orbit stabilisation programme which died.  Thye managed to get the programme restarted and then things went better. However during the owl shift we have had multiple muon trips and even the odd COT trip.</p>


<!-- Date: Wed Nov 16 07:59:07 2005 -->
Silicon iFix PC (svxiicon) rebooted.
<!-- Author: Ulrich H. -->


<!-- Date: Wed Nov 16 08:36:39 2005 -->
<h3>Silicon Cooling Work</h3> 
 
<p>Warren will be putting ina new replacement air filter for the cooling system.  As this will trip the detector, we have turned off the whole detector.</p>
<!-- Author: Ankush & Ulrich -->
<!-- Comment: Wed Nov 16 08;38;15 comment by...Ankush & Ulrich -->
<b>Do not forget to unsilence all alarms when colling work has completed!!!</b>

<!-- Comment: Wed Nov 16 08;52;14 comment by...Ulrich H. -->
<p>
Warren Bowman and Bill Noe are done with their work. The new air dryer had been mounted in the alcove already and was waiting to be piped in and switched on. They also installed a valve manifold to be able to bypass the air dryer without interrupting the pressurized air flow.
<p>
Fortunately, none of the e-valves tripped when the flow came back, so we only acknowledged the trips. Now Ankush is switching the silicon back on.



<!-- Comment: Wed Nov 16 09;08;03 comment by...Ulrich H. -->
<p>
Ankush brought up the silicon without a single trip. He is now checking out a few ladders. After that, he will take the system through a coldstart.


<!-- Comment: Wed Nov 16 09;45;30 comment by...Ankush -->
<p>The detecto came back up fine and I did a COLDSTART and ran for 5,000 events.  No errors were reported.  I also took a selection of random SVX & ISL ladders and ran them in SVXDAQ.  No problems seen there.</p>

<p>The only curious thing was I noticed the DVDD current for e180 was yellow. The current is only 1uA and the lower IMON limit is 5.0.  I hockerised the crate but the current returned to 1.0.  I ran this ladder in SVXDAQ and it ran error-free.  We should probably look at it again during the remaining quiet time.</p>
<!-- Date: Wed Nov 16 09:23:03 2005 -->
<p> I got paged at about 04:00 because of RF trip. AGIGI2 increased sharply at the time of the trip and then went down but not below the limit. MCR tried to clean the abort gap twice but the value of AGIGI2 stayed about 8 or a little higher. The Scico asked them to clean again, then it went down to about 7.6. The rest of the losses seem stable and under well under limits so at that point I told Peter who was the monitoring Ace that he can include silicon in the run but keep an eye in case there are some changes. 
There was less then 2 hours left till the end of the store. 
Plots can be linked now, will do later. </p>
<!-- Author: Shulamit -->



<!-- Date: Wed Nov 16 09:49:44 2005 -->
<h3>Database and Fileserver work</h3> 
 
<p>Database and fileserver work has just started.  It should take a couple of hours to complete.  Until then, we can't do any work on Silicon.</p>
<!-- Author: Ankush -->
<!-- Comment: Wed Nov 16 11;56;53 comment by...Ankush -->
<p>Computing work completed.  Silicon systems seem to be OK.</p>
<!-- Comment: Wed Nov 16 18;01;35 comment by...Ankush -->
<p>spoke to soon.  Had to edit the /etc/auto.cdf file to change the references of b0dap32 to b0dau30.  Then restart the services. I then checked we could run traceSilicon. hdimap, svxdaq and run-control on b0dasvx*.</p>
<!-- Date: Wed Nov 16 11:18:15 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7912&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7912  width='300' align='top'></a></td><td><h4>STORE 4501</h4> 
 
<p>This ACNET plot shows the losses for STORE 4501.  You can see after 8pm, the LOSTPB and B0AAGC went very big with very large spikes.  This was due to the Tevatron Orbit Stabilisation programme crashing.  During this period the Silicon was on STANDBY along with COT and Muons off.  Once the Orbit stabilisation weas recovered, we continued with data taking.</p> 
 
<p>Then in the middle of the night an RF station was lost which made AGIGI2 go crazy.  3 attempts to clean it helped a little bit.  However the store did terminate cleanly for us.</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Wed Nov 16 11:20:48 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7913&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7913  width='300' align='top'></a></td><td><h4>BLM summary for termination of store 4501.</h4> 
 
<p>The beam quality was not the best and AGIGI2 was quite high.  However you can see in the BLM plot that we didn't recieve much.  There is a small blip in E:SVBFA1.</p></td></tr></table>
<!-- Author: Ankush -->
<!-- Comment: Thu Nov 17 15;22;29 comment by...rainer -->
<pre>so here is the unique opportunity to calibrate something. what was the agigi2 at time of abort ? this value IMHO would then be too high.</pre>
<!-- Date: Wed Nov 16 13:13:06 2005 -->
<table border=0><td><tr><td bgcolor=#e0e030><big>Noise bias scan interrupted for filesystem work</big><br> 
The common code area which holds CAENvolts.dat is read-only for the next few hours.  This means that "ON" bias voltages are set to 3V for the time being.  When the CAENCONTROL_DIR becomes writable again, I will resume the bias scan or restore nominal voltage values. 
</td></tr></td></table>
<!-- Author: boveia -->
<!-- Comment: Wed Nov 16 18;00;02 comment by...Ankush -->
<p>The fileserver work still interrupted us.  Although silicon was fine, L2, L3, EVB, etcv are having problems. So I have abandonned the Bias Scan for today.  <em>Hopefully</em> another opportunity will become available.</p>

<p>overall this is very frustrating....grr....</p>


<!-- Comment: Thu Nov 17 01;20;02 comment by...boveia -->
<br>For the record, I reset all bias voltages to their nominal values late this afternoon.  

<!-- Date: Wed Nov 16 19:28:29 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L0 
<li>problem n: 633 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: mhartz 
<li>description is: We can reproduce the error in NN with dps on, but not RA or NN with dps off.  So error may be rate dependent.  Unfortunately our ability to reproduce the error in NN seemed to disappear in the middle of the investigation.    
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Nov 16 19:29:53 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W5L2 
<li>problem n: 853 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Monitoring
<li>entered by: mhartz 
<li>description is: Tried running in NN with readout length of 3000 to check for rate dependence.  Still could not reproduce the error. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Thu Nov 17 07;36;29 comment by...sasha -->
<pre>I thought we reproduced the error yesterday, right before file system work caused SVXDAQ to crash. We just didn't have an opportunity to look on the last event data and make sure it was the "right" type of error. Moreover, we were able to do it twice. </pre>


<!-- Date: Thu Nov 17 12:54:38 2005 -->
<pre>Did another noise vs bias scan today. 
 
Run 207342 
 
vdep iev fev 
-130 0 1019 
-120 1020 2092 
-110 2093 3033 
-100 3034 3976 
-90 3977 5009 
-80 5010 6030 
-70 6031 7000 
-60 7001 8008 
-50 8009 8831 
-40 8832 10010 
-30 10011 11015 
-20 11016 12008 
-10 12009 12994 
0 12995 13986 
-125 13987 15016 
-115 15017 15982 
-105 15983 17270 
-95 17271 17997 
-75 17998 19012 
-65 19013 19951 
-55 19952 21009 
 
Nominal voltages are now set as previously defined in CAENvolts_11072005_0450PM.dat </pre>
<!-- Author: boveia -->
<!-- Comment: Thu Nov 17 13;29;58 comment by...boveia -->
<pre>Integrated delivered luminosity ~ 1434/pb.</pre>



<!-- Date: Thu Nov 17 22:54:52 2005 -->
<h4>Quiet Time Studies</h4> 
 
<p>Finally Sasha, Mark and Shulamit got to start their quiet time studies.  (The previous attempts were thwarted by their daft SPL).  They went through their list to investigate the now difficult ladders.</p> 
 
<p>Details will on which ladders were worked on will appear.....</p>
<!-- Author: Sasha, Mark and Shulamit (& Ankush) -->


<!-- Date: Fri Nov 18 02:16:10 2005 -->
The DAQ round button on the PS GUI turned red during shot setup, silicon in standby. I was paged. There was not any visible alarm or problem. HRR didn't help, I exit and restarted the PS GUI and since then it is green again. If someone knows what could be the cause for it turning red please comment.  
<!-- Author: Shulamit -->
<!-- Comment: Fri Nov 18 08;20;29 comment by...Ankush -->
<p>The DAQ light on PSGUI is plain stupid.  One it goes red it stays red.  I can see why you&#d want it to latch but there should have been an option to reset it like in IMON.  However the authors did not forsee such a feature.  So the only way to reset it is to restart PSGUI.</p>

<p>So Shulamit did the right thing.  Unfortunatly PSGUI is dumb.</p>
<!-- Date: Fri Nov 18 07:34:17 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7915&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7915  width='300' align='top'></a></td><td>SpyMon plots for store 4506. Initial luminosity 68.15. Store came in without any problem, all losses were fine and silicon was included right at the beginning.</td></tr></table>
<!-- Author: Shulamit -->

<!-- Date: Fri Nov 18 07:58:11 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W5L4 
<li>problem n: 1385 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: mystery-guest 
<li>description is: Changed upper limit on bias0 current from 503micro-Apms to 520micro-Amps.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>445.406</td><td>445.406</td></tr>
<tr><td><b>Lower</b></td><td>0.0</td><td>0.0</td></tr>
<tr><td><b>Upper</b></td><td>503</td><td>520</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Nov 18 08:00:18 2005 -->
<pre>Changed IMON limit for ISL B4W5L4  bias0 from 503 micro-Amps to 520 micro-Amps.</pre>
<!-- Author: Shulamit and Ankush -->


<!-- Date: Fri Nov 18 09:35:04 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W7L2 
<li>problem n: 1046 
<li>Status: needs_work
<li>Type: AVDD2
<li>Action: Monitoring
<li>entered by: sasha 
<li>description is: We ran this ladder with SVXDAQ during quiet time studies. The ladder was tested in the following modes: RA; NN two ladders only (to speed up read out rate); NN two ladders only with readout length set to 2500; NN single ladder; NN single ladder with readout length set to 2500. No errors were observed in each mode after running 10K events. Further more, this ladder gave no errors during the period from 10/11/05 till 11/14/05. However, there were errors detected during 4 runs taken on 11/15/05. Let's hope it was just a single event of a 'mad ladder disease'. If no errors are detected during next few days, we will pass this ladder back to monitoring group.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W7&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Nov 18 09:59:32 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W11L3 
<li>problem n: 643 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: The error rate for this ladder has dropped from ~10-15% down to 2-5% over the period of last 90 days. We tested the ladder with SVXDAQ in RA and NN (with 2 ladders only) modes. We were able to reproduce CAP_ID and channel_id errors but a very low rate. Changing R-driver values doesn't help. The error rate seems to  have a trend to decrease. So, in the absence of other ideas we can only hope the error rate will fall even lower.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W11&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Nov 18 11:44:00 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: sasha 
<li>description is: This ladder is tough... It has a history of dropped readout problems and periods of error-free running. We looked on it  during quiet time studies again. We checked if there are any correlations between periods of error/error-free running with temperature cycles---no obvious correlation was found. Then,  we ran it with SVXDAQ. We confirmed the problem. We found that problems occure in a few channels of chip-89. They just give garbage. What is interesting is that, despite garbage data from  a few first channels, normal readout from remaining chips and channels sometimes recovers, and rest of the data looks fine.  Also, the error rate agrees with the one which is expected if only one chip is faulty: 1/14 ~ 6-10%. We tried to change R-driver values to see if it helps--- no, it doesn't (not a surprise). We also tried to sparse chip 89 out--- still getting errors. Finally, problems disappear only if we cut a chip chain after chip 8a (only 4 out 14 chips are re!
ad out).     Do we want to do it if the error rate is <10%?  
<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: Fri Nov 18 12:19:45 2005 -->
<table border=0><td><tr><td bgcolor=#e0e030>After recent changes to the online machines ups DBs a problem in the java settings was solved by changing the setup in setup_jeff. If you find problems with this (or with your private settings) please let me know. 
</td></tr></td></table>
<!-- Author: Sebastian -->


<!-- Date: Fri Nov 18 14:05:28 2005 -->
<table border=0><td><tr><td bgcolor=#e0e030><h4>Weekend instructions for PS Pager</h4> 
 
<p>If we have to get hold of a PS expert, you should call Jen on her cell phone (630-291-3454).  She will need at least 1 hour to travel in.</p> 
 
<p>BTW: This is just for this weekend (18 Nov to ~morning 21 Nov)</p></td></tr></td></table>
<!-- Author: Ankush on Jen&#39s behalf -->


<!-- Date: Sat Nov 19 08:36:01 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7918&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7919  width='300' align='top'></a></td><td>STORE 4508: Initial Lumi: 137E100 cm-2 s-1. Came in at 3AM. 
SVTSPYMon plot looks fine...usual 3 SVT holes. 
 
From the CDF Shift e-log, looses were OK; although initial LOSTPB was at ~5KHz but has been falling with time. 
 
</td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Sat Nov 19 08:38:24 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7920&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7920' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7921&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7921' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7922&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7922' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7923&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7923' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Sat Nov 19 08;40;04 comment by...Ankush -->
SVXMON status for current store: The summary page looks fine. The usual collection of blues, reds and greens.  Detector looks fine.


<!-- Date: Sat Nov 19 10:39:10 2005 -->
<h3>Tevatron Quench</h3> 
 
<p>B11 Separator sparked which caused the Tevatorn to Quench.  Low Betas D4, E1, F4, D0  quenched.  Shift crew did a post-quench check-out: Silicon OK.</p> 
  
<!-- Author: Ankiush -->


<!-- Date: Sat Nov 19 10:42:22 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7924&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7924  width='300' align='top'></a></td><td><p>BLM plot from quench. So we got some dose in the 4 BLMs but the dose is small.</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Sun Nov 20 03:34:11 2005 -->
<p>During scraping Sergo, the monitoring ace, suddenly noticed that the ISL bar on iFix went on (green and more than 100% high) and got an ISL trip immediately.</p> 
<p>No one had changed anything since the silicon was put in standby, Sergo says he didn't touch iFix or the PS GUI - even though - we got an ISL B3 W1 VBIAS14 OverVoltage. 
All AVDD for this wedge became red and some other parts of this wedge as well. When I came the silicon was in standby. I unmarked all and all turned green but the AVDD part which became yellow. Looking at the history plots the currents were higher than the limits. We included silicon in the run, did once HRR and everything turned green and went down to normal values. </p> 
<p>I have no idea how while being in standby the isl trips with overvoltage. Searching the silicon e-log sdoesn't really work, it did before but now takes ages already and just says "loading". From what I read before there were two similar incidents this year without a clear conclusion for the cause for that. 
At the moment everything is fine, taking data with silicon, hopefully it stays like this.</p>
<!-- Author: Shulamit -->
<!-- Comment: Sun Nov 20 12;03;07 comment by...Sebastian -->
From the log files it seems like VBIAS1 for IB3W1L4 suddendly decided to ramp up at about 2:36am... it tripped when it got to
140V (hardware trip limit). Looks like a spontaneous transition of this PS cr 11, sl 1. 
<!-- Comment: Sun Nov 20 17;33;49 comment by...Ankush -->
<pre>hmmm..that's a little worrying....is this crate or power-supply fault ?</pre>
<!-- Date: Sun Nov 20 03:38:26 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7926&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7926  width='300' align='top'></a></td><td>SpyMon plot for store 4514, initial luminosity 131.45. 
During scraping ISL tripped, see previous e-log entry, losses at the beginning of the store were fine, as soon as the trip was recovered we included silicon in the run.</td></tr></table>
<!-- Author: Shulamit -->




<!-- Date: Mon Nov 21 00:07:23 2005 -->
<h4>CAEN PS 3 Switched itself off</h4> 
 
<p>At 19:55, CAEN PS 3 (SW Top Top) switched itself off.  The ACE recovered the wedges and run continued.</p>
<!-- Author: Ankush -->


<!-- Date: Mon Nov 21 08:44:35 2005 -->
<b><h3>Summary of the week :</h3></b> 
<ul> 
<li> <b>Monday</b> - MCR were playing with the tunes. Losses and AGIGI2 went high, silicon was put to standby. CAEN PS 3 lost communication. 
<li> <b>Tuesday</b> - Lost monitoring of B0PAGC, B0AAGC... put silicon to standby and powercycled the affected rack. Store 4501 started with high losses, silicon included only after ~45 minutes. 
<li> <b>Wednesday</b> - RF tripped, AGIGI2 increased sharply and did not go down below the limits. Silicon was included after a while when losses and AGIGI2 seemed stable and SPL gave permission to run with AGIGI2 slightly above 8. 
Cooling work, put in a new replacement air filter for the cooling system. 
 File system work, bias scans were interupted. 
<li> <b>Thursday</b> - Queit time studies. 
<li> <b>Friday</b> - Changed imon limits for ISL B4W5L4. Continued queit time studies. 
<li> <b>Saturday </b> Beginning of store 4508, OK. 
<li> <b>Sunday </b> - ISL trip - VBIAS1 for IB3W1L4 ramped up by itself for an unknown reason. Beginning of store 4514 fine. 
</ul>
<!-- Author: Shulamit -->


<!-- Date: Mon Nov 21 09:04:26 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7927&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7928  width='300' align='top'></a></td><td>Store 4515: Initial Lumi 146.52E100 cm-2 s-1 
SVTSPYMON Plot looks the usual. 
 
 
</td></tr></table>
<!-- Author: Ankush & Shulamit -->


<!-- Date: Mon Nov 21 09:08:43 2005 -->
<h4>CAEN PS 8 Had to be Hockerised</h4> 
 
<p>CAEN PS 8 (NW Bottom Bottom) lost communications..Classic Hockerisation needed. I made the new ACE do it.  Took a little longer but hopefully he'll  be better next time.</p>
<!-- Author: Shulamit & Ankush -->