<!-- Title: 10:49:47  Mon Oct  2 2006 -->
<!-- Crewchief: Tuula (MPC) -->
<!-- Op1: Ankush (SPL on call) -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Take good data.</pre>


<!-- Date: Mon Oct 2 11:17:49 2006 -->
<h3>Rasnik business</h3> 
After the upgrade of b0sili01, b0rasnik stopped copying stuff over to b0sili01. I had to remove the RSA key of b0sili01 in <tt>~rasnik/.ssh/known_hosts</tt>.
<!-- Author: Ulrich -->


<!-- Date: Mon Oct 2 11:57:50 2006 -->
<h3>Reformatter Errors</h3> 
 
<p>So last night's VRB swap did not help.  The reformatter errors reappeared this morning.  As thr FIB and VRB have already been swapped, the next thing to try is the VTM.</p> 
 
<p>However I am a little suspicious that there is something else going on.  When I examined the raw events, it appeared more than one VRB was missing from the raw data.  This is odd.</p> 
 
<p>If anyone else is interested, I have collected the events with reformatter errors on b0gateway:/cdf/onln/home/mitra/reformatterError.</p>
<!-- Author: Ankush -->


<!-- Date: Mon Oct 2 11:57:56 2006 -->
<h3> IMON </h3> 
Modified version of IMON is running officially. Comment if you see any problems while using it.
<!-- Author: Jose -->


<!-- Date: Mon Oct 2 12:11:34 2006 -->
<h3>DS Jobs still appear not to be running</h3> 
 
<p>Last night it was discovered David Stuart's scripts were not running properly as they were still writing to /data. In the <em>old</em> b0sili01 setup, /data was a soft link to /data02/data.  Althought this link has now been added, it still appears none of the *.dat files have been updated....currently under investigation.</p>
<!-- Author: Jose & Ankush -->


<!-- Date: Mon Oct 2 12:50:56 2006 -->
Offline ADCMon is down because of the Scientific Linux upgrade.  In the meantime, I wrote some scripts to copy the online ADCMon output, which consists of ROOT files located on the online machines at<br> 
/cdf/onln/data/cdfdaq/consumer/results/SVXMon 
<br>,to b0sili01.  After the copy, the scripts produce a directory full of eps plots, gif thumbnails, and a web page to view these plots. 
<p> 
The scripts are at /b0sili01/data04/boveia/online_adcmon/.  To process a particular run, do "get_online_adcmon.pl -r 123456".  To get some recent runs, run without the "-r" option.  The recent run code tries to parse the recent stores web page for runs with large statistics, but it doesn't work very well at the moment, so use a run number.  
<!-- Author: boveia -->
<!-- Comment: Mon Oct  2 12;54;21 comment by...boveia -->
There are a few problems that I'll leave to others:
<ul>
<li>It converts each eps plot to a gif with a separate "convert" process.  This is really slow.
<li>As mentioned above, the recent run code doesn't know how to parse the recent store list efficiently.
<li>Plots for ISL and L00 sometimes don't appear.
<li>The code is not automated.
</ul>

<!-- Comment: Mon Oct  2 12;55;36 comment by...boveia -->
An example web page for a recent run is <a href="http://b0sili01.fnal.gov//monitoring_wg/svxmon_224126/">224126</a>.  (The linked plots will eventually disappear.)


<!-- Date: Mon Oct 2 15:36:00 2006 -->
<h3>Sound on b0dasvx03, b0dasvx02</h3>
 
<p>Jason Hedden came in to fix the sound on the b0dasvx** machines.  I have confirmed sound on b0dadvx03 and b0dasvx02 but nothing from b0dasvx01.</p>
<!-- Author: Ankush -->


<!-- Date: Mon Oct 2 16:00:08 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9986&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9987' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9988&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9989' ></a></center>
<!-- Author: Ankush -->
<!-- Comment: Mon Oct  2 16;10;14 comment by...Ankush -->
<h3>Sound Card Connections</h3>

<p>The b0dasvx** machines have CD approved sound cards.  However it appears we have two types.</p>

<p>The picture on the left is for b0dasvx03 and b0dasvx01.  The picture on the right (with the convenient <font color="green">green</font> connector) is for b0dadvx02.</p>


<!-- Date: Mon Oct 2 19:47:33 2006 -->
<h3>Lightening problems</h3> 
 
<p>There was a large thunder-crack and then a slew of DAQ errors from run-control including a bunxh of SRC errors.  The first suspicion is the lightening caused a clock glitch.  But I could see no evidence of it in the Logic Analyser.</p> 
 
<p>The ACEs tried to HRR out of it but with no success.  So the started a new run and, so far, things seem OK.</p>
<!-- Author: Ankush -->


<!-- Date: Mon Oct 2 21:18:04 2006 -->
<pre>I got paged because the shift crew couldn't restart SVXMON. They said they got an error message: 
 
Error Opening b0server08.fnal.gov:9094  
 failed.   
 
I asked them to page Consumers. However, the problem recovered before the Consumers expert got to the control room.  </pre>
<!-- Author: Tuula -->


<!-- Date: Mon Oct 2 22:14:49 2006 -->
<pre>Increased B0PAGC caused TeVMon warning. The shift crew put Silicon on standby. Soon after that the beam was aborted. </pre>
<!-- Author: Tuula -->
<!-- Comment: Mon Oct  2 22;17;24 comment by...Tuula -->
<pre>There has  been a lot of lightning.</pre>

<!-- Comment: Mon Oct  2 23;39;30 comment by...Ulrich -->
Here's the MCR e-log around that time. First they lost the stash, then the store, they they quenched:
<pre>
22:03:26-  More lightning. Stash is gone. (Stack, store intact.) Also tripped: MI-10 kickers, Booster CEPNW1. - maggie
-- Mon Oct 2 22:05:38 comment by...maggie --  Stash was a ~180 e10 loss. 
-- Mon Oct 2 22:05:59 comment by...aria --  Cons (OnCall) has been paged.
 22:06:48-  Run Co has been paged. - Aria
-- Mon Oct 2 22:14:24 comment by...aria --  he will call us back when he has a plan.
 22:08:48-  Store Gone. No Quench. - Aria
-- Mon Oct 2 22:11:11 comment by...maggie --  Dzero SVX losses was the singular indication on T67. 
-- Mon Oct 2 22:34:45 comment by...maggie --  
 22:22:52-  We just quenched D1. - Aria
-- Mon Oct 2 22:28:50 comment by...maggie --  both D1 and Dzero low betas quenched. We were still at high field at the time. We seem to have lost the abort link, as well as half the Tev serial link. Also all AP1 supplies tripped. 
</pre>


<!-- Date: Mon Oct 2 23:39:51 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9990&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9990' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9991&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9991' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Mon Oct  2 23;51;42 comment by...Ankush -->
<h3>clock glitch this time</h3>

<p>This clock glitch occured at 21:29; quite likely related to the ligthening.  This is what the error logger gave:</p>

<pre>
CT: 2006.10.02 21:28:36
28'36" b0control21.fnal.gov:Rejoin Orphaned PartitionThread[Thread-23,6,main]:Oct 2, 2006 08:03:40 PM->Successfully shepherded client ERRLOG (errlog) -->  
 Additional Information: 

 Attention!!!. FERML_SHEPHERD_SUCCESS !!! 
 
 Successfully Shepherded b0control21.fnal.gov:Rejoin Orphaned PartitionThread[Thread-23,6,main]b0svx06:Messenger:Oct 2, 2006 09:28:37 PM->SRC Fatal Error:Sl 6 Too Many L1A 2 L1A to Buff 
 -->  
 Additional Information: 

 Attention !!!. FERML_SRC_FATALITY ERROR !!! 
 
 SRC Fatal Error from b0svx06: Sl 6 Too Many L1A 2 L1A to Buff 
 
 - HALT the run                   
 - record any relevant information in e-log     
 - RECOVER - RUN     
[MLE]
</pre>

<p>Looking through the error-logger, there was another SRC error:</p>

<pre>
CT: 2006.10.02 21:48:47
48'47" b0control21.fnal.gov:Rejoin Orphaned PartitionThread[Thread-23,6,main]:Oct 2, 2006 08:03:40 PM->Successfully shepherded client ERRLOG (errlog) -->  
 Additional Information: 

 Attention!!!. FERML_SHEPHERD_SUCCESS !!! 
 
 Successfully Shepherded b0control21.fnal.gov:Rejoin Orphaned PartitionThread[Thread-23,6,main]b0svx06:Messenger:Oct 2, 2006 09:48:48 PM->SRC Fatal Error:Sl 6 Too Many L1A 2 L1A to Buff 
 -->  
 Additional Information: 

 Attention !!!. FERML_SRC_FATALITY ERROR !!! 
 
 SRC Fatal Error from b0svx06: Sl 6 Too Many L1A 2 L1A to Buff 
 
 - HALT the run                   
 - record any relevant information in e-log     
 - RECOVER - RUN     
[MLE]

<em>...and immediately another...</em>

CT: 2006.10.02 21:48:48
48'48" b0control21.fnal.gov:Rejoin Orphaned PartitionThread[Thread-23,6,main]:Oct 2, 2006 08:03:40 PM->Successfully shepherded client ERRLOG (errlog) -->  
 Additional Information: 

 Attention!!!. FERML_SHEPHERD_SUCCESS !!! 
 
 Successfully Shepherded b0control21.fnal.gov:Rejoin Orphaned PartitionThread[Thread-23,6,main]b0svx02:Messenger:Oct 2, 2006 09:48:48 PM->SRC Fatal Error:Sl 6 L2A w/o L1A 
 -->  
 Additional Information: 

 Attention !!!. FERML_SRC_FATALITY ERROR !!! 
 
 SRC Fatal Error from b0svx02: Sl 6 L2A w/o L1A 
 
 - HALT the run                   
 - record any relevant information in e-log     
 - RECOVER - RUN     
[MLE]
</pre>

<p>For the second and third SRC error, one cannot say for sure this was related to a clock glitch as the LA was already triggered by the first SRC error.  But considering the lightening, it is quite likely.</p>


<!-- Date: Tue Oct 3 00:02:22 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9992&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9992' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Tue Oct  3 00;10;54 comment by...Ankush -->
<p>see entry below</p>
<!-- Date: Tue Oct 3 00:05:59 2006 -->
<h3>Another clock glitch</h3> 
 
<p>The logic analyser sent me another email.  This time you can see multiple clock glitches; each one is a few microseconds.  Unfortunatly I can't give the actual SRC error as Silicon (& CDF) is not running now due to the lightening induced quench.</p>
<!-- Author: Ankush -->


<!-- Date: Tue Oct 3 09:09:17 2006 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 448
Calibration type  : standard
Run period tag    : Oct_2006
DPS-off run       : 224206
DPS-on run        : 224205
Requested by      : Jason
Main process id   : 16067
Comment           : beam off
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->



<!-- Date: Tue Oct 3 10:49:52 2006 -->
Mark did a long  high speed test  for VRB 165 (the one taken out on Monday early morning). It did not show any errors. I handed it to prep to fix the reset botton which was loose.
<!-- Author: Mark/Ignacio -->

<!-- Date: Tue Oct 3 13:53:51 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 448 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 224206
DPS-on run       : 224205
Requested by     : Jason
Submitted        : 2006-10-03 09:08:52
Completed        : 2006-10-03 13:52:13
Status           : FAILURE
Comment          : beam off

Last processing stage reported : starting remote analysis scripts
Failure diagnostics :
Tcl error code : NONE
Tcl error info : child process exited abnormally
    while executing
"error $status"
    invoked from within
"if {[catch {exec  ssh -x ${silicon_remote_account}@${silicon_remote_host} \
        $silicon_scripts_dir/make_standard_tables.tcl \
        [info host..."
    (file "/cdf/data05/s1/hardware/svxii/SVXMon_calibration/Calib_scripts/run_calib_analysis.tcl" line 974)
</pre>
<!-- Author: D-mode script  -->
<!-- Comment: Wed Oct  4 01;25;22 comment by...Jason -->
Two of the required Tcl libraries was missing after the b0sili01 upgrade.  Mark and I installed them, and now the calib job server is up and running again.
<!-- Date: Tue Oct 3 14:03:44 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W2L4 
<li>problem n: 1423 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: tmaki 
<li>description is: Last 4 days this ladder has had errors at ~25% rate. Before that it used to be error free for a month. 
<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: Tue Oct 3 14:12:46 2006 -->
<pre>I went through the problem database. There is nothing we could do at an access of max 4 hours. For quiet time studies, we could try adjusting chip settings for SB3W2L0. 
 
I also went through bit reporter. SB2W2L4 has had error rates of ~25% for the last 4 days. Before that, it was running error free for at least a month.</pre>
<!-- Author: Tuula -->

<!-- Date: Tue Oct 3 17:53:38 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W0L4 
<li>problem n: 37 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Added_hdwdb
<li>entered by: jwagner 
<li>description is: Reinclude e404 in HWDB 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Oct 3 18:56:25 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W0L4 
<li>problem n: 37 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Removed_hdwdb
<li>entered by: jwagner 
<li>description is: <pre>Took it out of HWDB again.
AVDD current was too low (about 250), which caused a permanent pinky. 
Checked ladder e404 in SVXDAQ again. In contrast to the observation of the last week only the first chip was working properly.</pre> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Wed Oct 4 10:37:15 2006 -->
<h3>b0sili01 is shutting down for emergency maintanance</h3> 
 
<p>b0sili01 is going to be powered down in 10 mins for emergency maintanance.  It appears one of the drives in the RAID have degraded.</p>
<!-- Author: Ankush, Mark, Jose -->
<!-- Comment: Wed Oct  4 10;55;42 comment by...Ankush -->
<h3>...and b0sili02....</h3>

<!-- Comment: Wed Oct  4 11;46;49 comment by...Ben, Ankush, Mark -->
The machines are back up.  We changes some RAID bios information in the hopes that heavy disk access on the data array will not hose the system disk.

<!-- Comment: Wed Oct  4 11;48;22 comment by...Mark -->
Also b0sili01 has a drive that seems to be functioning only intermittently.  When we get the bad drives back from Tiger Direct, we will replace it.

<!-- Comment: Wed Oct  4 13;58;47 comment by...Ankush -->
<p>....and please let any of us know if you experience any strangeness with the b0sili machines.</p>
<!-- Date: Wed Oct 4 12:49:53 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W2L4 
<li>problem n: 1423 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: sasha 
<li>description is: I used quiet time during D0 access to investigate this ladder. I confirmed that it's giving errors with 100% rate. The problems occure on first channels of chip 88. Then it reads garbage. I also noticed that sometimes the ladder initializes OK (it has init readback masked). In this case, the ladder runs OK with no errors. The problems are likely related to older AVDD2 troubles. I tried to chop chips starting from 88 (last 3 chips have been already chopped). After that, the ladder initis OK and runs error free in RA and NN modes (5K events). The test was repeated twice---same result. So, my suggestion is to keep this ladder as it is for a while because it has a history of magic recoveries. If it continues giving errors during next 2 weeks, then we may want to chop all chips starting from 88.    
<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 -->
<!-- Comment: Wed Oct  4 12;52;56 comment by...sasha -->
<pre>While testing e224, I noticed that all the other ladders give 00_sequence errors at a very low rate ~2-3/5K. The problems usually occure on the first chips. I checked that other ladders are OK in the PDB and bit reporter. Could it be something with a fib?</pre>



<!-- Date: Wed Oct 4 17:04:55 2006 -->
<h3>A symphony of sili machines</h3> 
 
<p>We now have sound on all the b0dasvx machines. :-)</p>
<!-- Author: Ankush -->


<!-- Date: Wed Oct 4 17:34:58 2006 -->
<h3> Reformatter Errors </h3> 
 
More on reformatter errors. I have put in <a href=http://b0sili01.fnal.gov/FormatterError.html> FormatterError </a> a script that can help to determine which VRB, FIB,... is causing problems. As an input you have to upload a raw data file and it gives you as an output the on-line ladders that can not be found in the event.
<!-- Author: Jose -->


<!-- Date: Wed Oct 4 23:17:25 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9993&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9994  width='300' align='top'></a></td><td>SVTSPYMon for store #5002, initial luminosity 125.</td></tr></table>
<!-- Author: Tuula -->
<!-- Comment: Thu Oct  5 01;02;09 comment by...Tuula -->
<pre>SVXMON is fine.</pre>
<!-- Date: Wed Oct 4 23:38:50 2006 -->
<h3>FIB SEU  for ISL IB4W0/1 </h3> 
 
<p>Oscar noticed a block of red cells in SVXMon which corresponds to the fib for IB4W0/1.  A new run was restarted and that seem to fix the problem.  Now running OK.</p> 
  
<!-- Author: Ankush -->

<!-- Date: Thu Oct 5 00:00:42 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W9L2 
<li>problem n: 1775 
<li>Status: needs_work
<li>Type: Unknown
<li>Action: Incident
<li>entered by: amitra 
<li>description is: <p>During the run, the ladder started giving yellows.  I looked at the raw data and it looks weird.  Putting it to needs work and then ananlyse during quiet time.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W9&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Oct 5 00:03:21 2006 -->
<h3>SVXMon yellow for SB0W9L2</h3> 
 
<p>During data taking this ladder started giving a yellow in SVXMon.  So I have put it to needs work in the PDB and got the CO to restart SVXMon.</p> 
 
<p>This is what I got out of the raw data:</p> 
 
<pre> 
1380: e092c1c1 89a853fd d9f0808c dbf1daef  
1384: c0f188a8 53fde093 00f38928 46f38828  
1388: 48f34709 86288728 63088528 65056416  
1392: a3288428 a128a228 7e0d7df3 a0287f12  
1396: 6d0500f3 6f036e09 c1c17ff3 53fde094  
</pre> 
 
<p>This looks odd to me.  It may look better after some sleep.</p> 
 
<p><em>All I wanted to do was finish my PERL script...grrrr...</em></p>
<!-- Author: Ankush -->



<!-- Date: Thu Oct 5 03:45:25 2006 -->
<pre>I was paged because of an error window "Number of pinky ladders: 7". There were no pinkies in IMON. Per Ankush, this is from a test version of IMON which was left running, and those error messages can be ignored.</pre>
<!-- Author: Tuula -->
<!-- Comment: Thu Oct  5 08;44;15 comment by...Ulrich -->
The main confusion came from the red DAQ button (see <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=738&frame=2&anchor=02:56:10.866'>
main e-log entry</a>), which we usually ignore. However, the 
<a href="https://www-cdfonline.fnal.gov/internal/ops/svxii/svx_for_aces/monitoring/psgui-ref.html">PSMON instructions</a>
 on the Monitoring Ace website says the following:
<pre>
The TRIP indicator turns RED in the case of a trip, it should go back to GREEN after the trip recovery. The DAQ and COOLING buttons are always GREEN and should only turn RED on e.g. a cooling incident. However the DAQ button might turn RED as well in case of a RTServer problem. Consult the Main pager Carrier in this case.
</pre>
I guess we will have to revise this web page.
<!-- Date: Thu Oct 5 05:34:49 2006 -->
<h3> RF issues </h3> 
Had a look at <a href="http://www-cdfonline.fnal.gov/java/cdfdb/servlet/ShowFile?FILE=/cdf/onln/data/cdfdaq/rcLog/errmon/log/errorfile224126_reformatter.log">Run 224126 RF errors</a> and saw a lot of 
<pre> 
RAWREF Error - UTILSILDEC - with code 39 -- START 
 Line - 1152 in: src/library/rr_rawevt.c 
 Buffer position: 59511 
 Error count: 1 of 1 
 Reject rate: 0.015 percent 
 
 Detector ID not known (yet?). 
 FIB ids found: 
  0xadeadcdf  0xadeadcdf  0xadeadcdf  0xadeadcdf  0xadeadcdf 0xadeadcdf  0xadeadcdf  0xadeadcdf  0xadeadcdf  0xadeadcdf 
 
 Error location code: 0x010013a0 
 
 
 Crate Id?: 0x00000010 
 
 Error during scanning MINI structure! 
 Last Unit prob. worked on (all counts from 0): 
  SCPU: 1 
  VRB : 3 
  LINK: 10 
  MINI: 0 
 
 Buffer (59491 until posi+2=59513) 
 0x1e301a2f  0x23322231  0x0b341833  0x07360935  0x0b45f344  0xf34e0646  
 0x06500b4f  0x096ef36d  0xf372f36f  0xf3741973  0x02760975  0xc1c1037f  
 0x091b2000  0x08411004  0x18411004  0x00000000  0x00000000  0x00000000  
 0x00000000  0x00000000  0x091b9010  0x00044100  0x00044110  
 
 
 NOTE: Event rejected! 
 
RAWREF Error - UTILSILDEC - with code 39 -- FINISHED: L<  945 
</pre> 
 
What you have here is a VRB which just gave 32 bytes of header and no data, which is why each channel reads "adeadcdf".  If I unbyteswap starting with the last data out of the previous Vrb (0xc1c1), I get  
<pre> 
0x7f03c1c1  
0x00201b09  0x04104108  0x04104118  0x00000000  0x00000000 0x00000000 0x00000000  0x00000000   
0x10901b09  0x00410400  0x00410400  
</pre> 
So there is 0x0020 bytes total, TSL1A is 0x1b, Event number is 0x09, then two 4 byte status words, and 10 2 byte channel counts, all of which are 0, then the next VRB with 0x1090 total bytes, same TSL1A and Event number, and some different status words.<br> 
This is what one should expect from a VRB if all channels were disabled but it was still receiving commands from the SRC.  The SRC commands via the J3 backplane are suppossed to be disabled at CONFIG time if there is no data expected, and besides, if this were the case you'd expect it every event.  It also might be what one expects if the VRB times out-long ago we put in a timeout (of 20 μs?) between the L1A and Read Busy going high, and if I recall correctly the VRB was just supposed to respond this way if we hit the timeout, but we never saw it actually happen.  For  this VRB, the status bits are 
<verbatim>0x04104108  0x04104118 = 000001 000001 000001 000001 000010 (00) 000001 000001 000001 000001 000110 (00)</verbatim> <br> looks like bit #0 high is "normal", but #1 is high on Chan 4  and both 1 and 2 on Chan 9.  Might want to look up what those ones mean, however, the veracity of these status bits has never really been checked, so this may be a red herring. One can also disable the timeouts, but it requires a code change in svx_proc.c<pre> 
  /* Some day we should put these into the state, * 
   * but for now, enable the L1A timeouts, disable the WYSIWYG */ 
  for (i=0; i<10; i++) { 
    vrb_enable(VRB_L1_TO_BASE + i, vrbM->slot, &error); 
    vrb_disable(VRB_WYSIWYG_BASE+i, vrbM->slot, &error); 
  } 
</pre> 
Perhaps "Some day" has come (the comment is from Dec 1, 2001) although I would try to identify the suspect VRB and disable the timeouts by hand after CONFIG, just to seee that it has the desired effect<br> 
 Unfortunately, the VRB itself puts no identification in the header, so from this data you cannot tell who it is.  The EVB guys have some information, which might be more reliable now than in the past, however, the "LINK=10" should scare you a bit, since LINKs go from 0 to 9-presumably its coordinates are pointing at the previous VRB. <br> 
I don't have the patience to look for other RF problems in that log, hidden amidst the swath of occurances of this particular error.
<!-- Author: Guess -->


<!-- Date: Thu Oct 5 08:37:31 2006 -->
<h3>No data in e092</h3> 
We had a look at the raw data this morning. This time it looks like a perfectly fine ladder: 
<pre> 
1172: c1c1 e091 79fe 852c 00f3 842c 832c a22c 
1176: a12c a02c 7f03 c1c1 e092 79fe 892c 0003 
1180: 882c 872c 862c 2106 220e 2317 2458 25e2 
1184: 263e 2716 2802 852c 7df3 7e0a 7ff3 a42c 
1188: 26f3 270c 28f3 a32c 5103 5216 5373 54f0 
1192: 55f3 6007 6111 62f3 630f 6403 a22c 0302 
1196: 040b 0556 06f3 3ef3 3f0c 405f 41f3 a12c 
1200: 32f3 3309 34f3 3903 3a0c 3b1c 3c5c 3df0 
1204: 3ef3 3f2c 40f3 410b 4207 7608 770b 7807 
1208: a02c 7f02 c1c1 
</pre>  
<!-- Author: Tuula & Ulrich -->



<!-- Date: Thu Oct 5 16:41:44 2006 -->
<h3>Trigger Test & AGIGI2 calibration</h3> 
 
<p>The Ops-head/Calorimeter Trigger expert (Peter Wilson) wishes to do a trigger test.  The lowest-count is to be lowered from 0.5GeV to 0.25GeV.</p> 
 
<p>At 8pm tonight, the electron lens will be turned off to help recalibrate AGIGI2.</p> 
 
<p>Given both of these we will have the silicon off, they are to be scheduled together.  So at 7:30pm, the Silicon will be ramped down to STANDBY and then remain so for the rest of the store.</p>  
<!-- Author: Ankush -->


<!-- Date: Fri Oct 6 00:32:29 2006 -->
<pre>New store came in. After half an hour, the beam was aborted. The ACEs are performing post-quench check-out.</pre>
<!-- Author: Tuula -->
<!-- Comment: Fri Oct  6 09;36;17 comment by...Ankush -->
<h3>Quench Post-Mortem</h3>

<p>For the record, this is the run co-ordinator&#39s summary of last night&#39s quench:</p>

<pre>
Overnight we lost store 5003 at about 0022hrs due to a transformer oil level low indication at B3. Experts verified the oil level was good and jumpered the interlock. On resumption of the Tevatron ramp and an attempt at a dry squeeze, the ramp was lost on a lead failure at D2 while after the first ramp. Also the lowbeta sequence was out of order which required some sequencer gymnastics. The Lead 0 VFC card was replaced for the lead trip problem. Meanwhile while performing Proton tune up to transfer Pbars to Recycler there were some apparent problem in Pbar as well but were resolved.
</pre>

<p>It&#39s a pity the store was lost as the initial lumi was 204.08E30.....and D0 saw 210.22E30.....pooey, I prefer the old says when we had more....o well C'est la vie.</p>



</p>


<!-- Date: Fri Oct 6 09:57:09 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9996&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9996  width='300' align='top'></a></td><td><h3>AGIGI2 calibraiton</h3> 
 
<p>Last night, they did a calibration of AGIGI2.  This is done by turning the electron lens off to fill the abort gap. (Silicon was at STANDBY for this!!)   
I pulled this ACNET plot straight out of the Tev elog which shows this.  AGIGI2 starts settling towards a value of ~7 which seems to be a bit low.  We shall have to hear from the Tev people what they think.</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Fri Oct 6 11:32:24 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9997&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9997  width='300' align='top'></a></td><td>A big trip just before beginning of store.</td></tr></table>
<!-- Author: Tuula, Ulrich, Ankush, Jose -->
<!-- Comment: Fri Oct  6 11;35;11 comment by...Tuula, Ulrich, Ankush, Jose -->
<pre>Everything is recovered now, and we are taking data with Silicon. The reason for the trips was probably due to "riverdancing".</pre>


<!-- Comment: Fri Oct  6 12;47;10 comment by...Ulrich -->
Ankush found a discman on top of one of the logic analyzers downstairs. The CD in it was by a guy called Gary Allan. Is that stuff (river-) dancable?
<!-- Comment: Fri Oct  6 12;50;39 comment by...Ulrich -->
Boring slow lethargic country music, I checked in iTunes.
<!-- Comment: Fri Oct  6 12;54;31 comment by...Tuula -->
<pre>It took about half an hour to recover all the ladders. This was because SB2W9L0 and SB4W8 were tripping. SB2W9L0 was recovered by  giving config to this ladder as quickly as possible. SB4W8 was still tripping after that procedure. We rebooted b0fib06, corresponding to SB4W8, after that everything was OK.


</pre>
<!-- Comment: Fri Oct  6 16;11;25 comment by...Ankush -->
<p>I should point out that we checked the Logic Analyser.  It showed no evidence of a clock glitch; so that is why we believe this is not a clock problem.</p>
<!-- Date: Fri Oct 6 11:39:20 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9998&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9998  width='300' align='top'></a></td><td>ISL shows a yellow FIB, we try to start a new run.</td></tr></table>
<!-- Author: Ulrich -->
<!-- Comment: Fri Oct  6 11;43;44 comment by...Ulrich -->
Apparently, the problem went away with the new run.


<!-- Comment: Fri Oct  6 12;28;44 comment by...Ulrich -->
The yellows are in ISL B3 W2, which is living in b0fib07. We had a similar problem a couple of weeks ago, after the <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=317&frame=2&anchor=09:28:44'>
crate CPU had to be re-seated</a>.
<!-- Comment: Fri Oct  6 12;47;20 comment by...Ankush -->
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=321&frame=2&anchor=23:38:50'>
...and earlier in the week for ISL IB4W0/1</a>



<!-- Date: Fri Oct 6 12:08:54 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9999&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10000  width='300' align='top'></a></td><td>SVTSPYMon for store #5006. SB2W7 seems to have lower occupancy than usually.</td></tr></table>
<!-- Author: Tuula -->
<!-- Comment: Fri Oct  6 12;17;17 comment by...Ankush, Tuula, Ulrich -->
We have looked into the raw data of that wedge. It seems that e271 does not return any data. The termination of the data is bad as well:
<pre>
5764: 030f 0403 5ff3 600a 61f3 7ff3 c1c1 e271
5768: 0cfc c561 e272 0cfc 8911 0001 8811 8711
</pre>



<!-- Comment: Sun Oct  8 03;10;19 comment by...  -->
Looks like first Chip is 0xC5 rather than 0x85, and Cap Id is 0x61 rather than 0x11.  I think if the VRB sees 0xC<i>z</i> (where <i>z</i>=anything) in the channel byte it assumes it is some sort of termination and throws the rest of the channel data away.
<!-- Date: Fri Oct 6 12:40:26 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W7L1 
<li>problem n: 1397 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: amitra 
<li>description is: <p>I'm suspicious of the unfixable here.  Currently looking at the raw data, the ladder is missing a FIB termination (c1c1 or c2c2).  I suspect something else is going on.  Needs investigation during quiet time.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W7&layer=L1">report</a></ul>
<!-- Author: Problem DB -->







<!-- Date: Fri Oct 6 14:36:41 2006 -->
The Aces had to hockerize CAEN crate 9, see 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=742&frame=2&anchor=14:04:59.597'> 
main e-log</a>.
<!-- Author: Ulrich -->



<!-- Date: Sat Oct 7 10:48:04 2006 -->
<h3>Interesting entry in the shift elog</h3> 
 
<pre> 
ISL has flashed yellow twice...  under the D tab, I noticed that "CCE1 Pressure at COT face" is 
fluctuating up a bit. 
 
 - Adam :: (run 224445) 
</pre> 
 
<p>The entry can be found  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=745&frame=2&anchor=10:03:53.990'> 
here</a>.</p>
<!-- Author: Ankush -->
<!-- Comment: Sat Oct  7 11;49;18 comment by...Ulrich -->
Aha, an Ace finally caught one of those. The point is that I tuned the e-valve for ISL cooling circuit CCE1 just below the warning limit to ensure maximum flow to the compromised cooling line CCE1. The COT face pressure is still a bit away from the trip limit of 13.6 psi. Over the last weeks the pressure slipped over the limit a few times a day. Seems that this has become a little more frequent during the last days. Generally, the COT face pressures don't have a large correlation with the temperatures. My guess is that the vacuum got slightly worse. I'll have a look at it later today or tomorrow.


<!-- Comment: Sat Oct  7 13;26;57 comment by...Ulrich -->
<h4>E-valves retuned</h4>
I have tried to release the pressure on CCE1 a little by changing some valve settings. The new (old) settings are:
<ul>
<li>CCE1: 70% (75%)</li>
<li>CCE2: 85% (80%)</li>
<li>CCE3: 80% (75%)</li>
</ul>
The idea is to equalize the pressure a little better by closing the valve where the pressure is too high and opening up others. Of course this is only possible because in ISL every cooling line on the East (West) side is connected to all other cooling lines on the East (West) side. I will have another look at the system in a couple of hours.
<p>
I have also looked at the history of the pressures. Over the last 14 days, they creep up very very slowly, which may be caused by the vacuum which deteriorates also very very slowly. I was considering to swap to the other vacuum pump (VP1-A), but it is unclear if that pump creates much better vacuum.
<!-- Date: Sat Oct 7 12:17:22 2006 -->
<pre>I was trying to run e271 at SVXDAQ. At the time when I was getting everything ready for running, four ladders tripped. They were SB2W7L0, SB0W5L0, SB0W4L4 and SB2W6L0. I was trying to recover SB2W7L0, but the MCR called they are injecting beam. I closed SVXDAQ and recovered trips.</pre>
<!-- Author: Tuula -->



<!-- Date: Sat Oct 7 15:14:56 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10001&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10002  width='300' align='top'></a></td><td>SVXSPYMon for store #5007, initial luminosity 188E30.</td></tr></table>
<!-- Author: Tuula -->
<!-- Comment: Sat Oct  7 15;17;21 comment by...Tuula -->
<pre>SVXMON OK with the usual yellow from IB1W5L2. </pre>

<!-- Comment: Sat Oct  7 15;18;35 comment by...Tuula -->
<pre>SB2W7, which had lower ocupancy at SVTSPYMon plot yesterday, is OK today.</pre>


<!-- Date: Sat Oct 7 18:05:21 2006 -->
<pre>Tevatron had tune excursion. The LOSTP started increasing, and the shift crew turned Silicon to standby. At that time LOSTP was well below 5 kHz. </pre>
<!-- Author: Tuula -->
<!-- Comment: Sun Oct  8 08;43;12 comment by...Ulrich -->
According to the AD run coordinator, they made a mistake while changing tunes:
<pre>
Late on the day shift, Tevatron tunes were adjusted as expected during the store 5007 to maintain store performance. Unfortunately an error was made in one of the corrections causing a period of about 15 min were lifetime suffered greatly. Fortunately the error was corrected and the store was not lost.
</pre>
<!-- Comment: Mon Oct  9 08;50;07 comment by...Tuula -->
<a href=
'/cgi/elog/elog.pl?nb=2006&action=view&page=746&frame=2&anchor=17:50:44.016'>
plot of losses </a>
<!-- Date: Sat Oct 7 19:21:17 2006 -->
<pre>I was paged because at the High Voltage Summary page SVX lower bar was low. According to ACEs everything looked good at PSGUI and IMON, but there were a trigger inhibit. I asked the ACEs to have a look at the Silicon Inhibits page at IFIX. At SVX there was SB0W10L2 giving trigger inhibit. I asked the ACEs to hockerize the corresponding PS. 
 
After hockerization the ACEs couldn't recover the trips because of  
Sat Oct 07 18:46:03 CDT 2006                        ERROR: Power Supply SVX B0 W1 Handshake - No response from the FIB 
They wanted to try hockerization again (maybe they were uncertain if they did it correctly). I asked them to page me again if that nor restarting PSGUI doesn't work. It didn't and decided to come to the Control Room. 
 
At the time I got to the Control Room, Ankush had called there. The reason for the problems was that the Run Control wasn't in the "HALT" state but in "RECOVERED" state. Ankush gave instructions to ACEs, and they had almost solved the problems at the time I was driving there. 
 
The ladder which gave trigger inhibit was pinky. The bias current was twice as high as it is supposed to be. I don't know if the ACEs noticed this was the same ladder when they were talking with me in the phone, but at least I didn't know these two problems were from the same ladder. 
 
Now we are taking data with Silicon, and SB0W10L2 is green in IMON. 
</pre>
<!-- Author: Tuula -->
<!-- Comment: Sun Oct  8 00;06;26 comment by...Ankush -->
<p>A couple of points:<br>
1) I was paged by the SciCo...that&#39s why I called in<br>
2) this interupppted my beer drinking<br>
<br>
clearly we need the machine which goes "PING!!"<br>
</p>
<!-- Date: Sat Oct 7 21:33:18 2006 -->
<pre>ISL cooling problems.  Asked the shift crew to page Silicon cooling.</pre>
<!-- Author: Tuula -->
<!-- Comment: Sun Oct  8 00;13;44 comment by...Ankush -->
<p>...and another reason for the machine which goes <a href="http://uk.imdb.com/title/tt0085959/">ping!!</a>.</p>

<!-- Comment: Sun Oct  8 00;16;07 comment by...Ulrich -->
I don't understand. How did you conclude that this was a cooling problem? Apparently was no iFix alarm and no audio alarm, and the full detector was on according to IMON and the PSGUI. Let me repeat here what I commented in the shift e-log:
<ol> 
<li><b>Non-severe problems</b>: iFix global alarms page turns yellow or red, one or more alarms <em> other than the ones ignored by us</em> should show up. We are very careful with ignoring alarms, so to first order I would trust ignored alarms. A non-severe problem will <em>never</em> cause a trigger inhibit. <li><b>Severe problems</b>: Let me assure you, if there is a real cooling problem, you will notice it. An annoying beeping sound will go off and the cooling alarm LEDs will be switched off. A cooling problem will always trip at least one bulkhead of one subdetector, most of the time entire subdetectors. This will be seen by IMON and the power supply GUI (and you get a trigger inhibit). The cryo tech will also get an alarm in this case. 
</ol> 
The problem you saw was very similar to the problem you saw earlier in your shift. The HV readback of CAEN crate 8 was garbled, reading back zero voltage (at non-zero current - see Ohm's law). This caused the trigger inhibit.

<!-- Comment: Sun Oct  8 00;17;32 comment by...Ulrich -->
Our machine may no go PING, but it certainly goes BEEEEEP if there is a cooling problem.

<!-- Comment: Sun Oct  8 00;18;22 comment by...Ankush -->
<p>...and one of the temperature alarms would have lead you <a href="http://en.wikipedia.org/wiki/Nitrogen">this</a>.</p>


<!-- Comment: Sun Oct  8 00;57;57 comment by...Ankush -->
<p>..although at the moment <a href="http://arago4.tnw.utwente.nl/stonedead/movies/meaning-of-life/ra/07-tiger.ra">
this</a> is more appropiate.</p>
<!-- Comment: Sun Oct  8 01;01;12 comment by...Ankush -->
<p>..but then again we&#39re a <a href="http://arago4.tnw.utwente.nl/stonedead/movies/meaning-of-life/ra/galaxy-song.ra">
world class experiment</a>.</p>
<!-- Comment: Sun Oct  8 01;11;29 comment by...Ankush -->
<p>...but we Silis only ever deal with <a href="http://arago4.tnw.utwente.nl/stonedead/movies/meaning-of-life/ra/12-its-only-wafer-thin.ra">
wafers</a>.</p>
<!-- Comment: Sun Oct  8 15;27;53 comment by...Ulrich -->
There is one thing I don't understand. If any bias voltage in the system is zero when the nominal value for the state is non-zero, the PSMon program on SVXIICON is supposed to issue the iFix alarms PS_SMTH_OFF. I implemented that 1.5 years ago, and it worked fine for SVX earlier. I'll have to check the source code again.
<!-- Comment: Sun Oct  8 15;42;25 comment by...Ulrich -->
So the code checks the ON bit on the individual power supply channel. The PS_SMTH_OFF is issued if the ON bit not set, but the nominal voltage is larger than 0. This catches spontaneous switch-offs, but not garbled read-back. I'll start thinking about making PSMon a little more intelligent, which would also make the Auto-Hocker even more useful.                                                                                    
<!-- Comment: Mon Oct  9 08;52;35 comment by...Tuula -->
<a href=
'/cgi/elog/elog.pl?nb=2006&action=view&page=746&frame=2&anchor=21:35:03.683'>
link to main e-log entry</a>
<!-- Date: Sun Oct 8 00:28:14 2006 -->
<h3>Speculations on Hockerization and Beam Conditions</h3> 
The current store looks pretty bad in terms of antiproton losses. At the same time, we already had two incidents tonight, where the readback of CAEN crates got bad. Both of the crates (1 and 8) were in the NW rack (i.e. on the proton side). I wonder if it would be possible to establish a correlation of CAEN crate failures and losses in addition to luminosity.
<!-- Author: Ulrich -->







<!-- Date: Sun Oct 8 11:33:45 2006 -->
<pre>B0AAGC is having large spikes. The mean of this variable is reasonable, 1.7 KHz, but the RMS is ~100%. I will keep an eye on Silicon trips, pinkys, CMX trips. If they start to happen, I will ask to put Silicon on standby.</pre>
<!-- Author: Tuula -->
<!-- Comment: Mon Oct  9 09;16;33 comment by...Tuula -->
<a href=
'/cgi/elog/elog.pl?nb=2006&action=view&page=748&frame=2&anchor=14:18:24.788'>
plot of B0AAGC </a>
<!-- Date: Sun Oct 8 11:41:51 2006 -->
<pre>The store will be terminated at 20:30 tonight. There may be two hours of Tevatron studies (Tune-Mult calibration maintenance, whatever that is) before that. We will get our D-mode calibration before that. It is unclear at the moment if there will be quiet time.</pre>
<!-- Author: Ulrich -->
<!-- Comment: Sun Oct  8 15;29;33 comment by...Ulrich -->
Word from our ops manager: we should expect very little quiet time.


<!-- Date: Sun Oct 8 18:17:43 2006 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 449
Calibration type  : standard
Run period tag    : Oct_2006
DPS-off run       : 224483
DPS-on run        : 224482
Requested by      : Artur Apresyan
Main process id   : 12476
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->



<!-- Date: Sun Oct 8 19:05:59 2006 -->
<h3>broken b0sili02 monitor</h3> 
 
<p>I have just discovered the monitor for b0sili02 has broken.  It keeps flashing on/off.  I have already mailed JJ for a replacement. </p>
<!-- Author: Ankush -->


<!-- Date: Sun Oct 8 19:18:51 2006 -->
<h3>Updated/New links to Si-Ops page</h3> 
 
<p>I have updated the links under the "Talks and Publications" section to take advantage of the anchor points in the talks page.  So this should make those links more useful.</p> 
 
<p>I have also add a new section called "Sub-Detectors" which have links ot the original SVX, L00 and ISL web pages.  They contain alot of important historical information. Eg: sensors installed, burn-in voltages, location in the detector, etc.</p>
<!-- Author: Ankush -->


<!-- Date: Sun Oct 8 19:37:01 2006 -->
<h3>SRC Error at end of DMode calibration</h3> 
 
<p>I just recieved a mail at 18:15 from the logic analyser of an SRC error.  This is coincident with the  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=749&frame=2&anchor=18:15:00.078'> 
end of DMode calibration</a>.  As this occured just after the DMode calibration, there is no error log for this. But looking at the Logic Analyser, the GhostBuster did not fire....so it was not a resonance error. Also only the SVX SRC pulled error, the ISL SRC was fine. I checed the SVX clock lines and they looked fine.I  have saved the trace and rearmed the logic analyser.</p>
<!-- Author: Ankush -->

<!-- Date: Sun Oct 8 22:51:38 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 449 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 224483
DPS-on run       : 224482
Requested by     : Artur Apresyan
Submitted        : 2006-10-08 18:16:54
Completed        : 2006-10-08 22:51:10
Status           : FAILURE

Last processing stage reported : calculating DPS-off pedestals
Failure diagnostics :
child process exited abnormally
</pre>
<!-- Author: D-mode script  -->



<!-- Date: Sun Oct 8 23:55:46 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10003&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10004  width='300' align='top'></a></td><td>SVTSPYMon plot for store #5008, initial luminosity 203E30.</td></tr></table>
<!-- Author: Tuula -->
<!-- Comment: Mon Oct  9 00;01;51 comment by...Tuula -->
<pre>SVXMON OK with the usual yellow from IB1W5L2. </pre>


<!-- Date: Mon Oct 9 07:16:06 2006 -->
<h3>Beam joy-riding</h3> 
 
<p>Around 1AM, the beam was doing  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=750&frame=2&anchor=02:17:10.711'> 
very interesting</a> things. The shift did the right thing by going to STANDBY...but no real explanation in the MCR logs.  Only comment I have found is:   
<pre> 
02:51:07-   The store lifetime has not been real good - the Tev tunes needed quite a bit of adjustment to get them where they are supposed to be. - djnn 
</pre> 
 
<p>...and on a side note, some ACEs have now become distracted that one ISL RTD is at -200C and the ISL conductivity is high.  Both are currently IGNORED aand have been for some time....now they fret about this........</p>
<!-- Author: Ankush -->
<!-- Comment: Mon Oct  9 07;16;53 comment by...Ankush -->
<p>...and I should really fix the AVDD for f511</p>


<!-- Date: Mon Oct 9 08:16:16 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10005&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10005  width='300' align='top'></a></td><td>The spike in the antiproton losses last night correlates nicely with an abrupt change in the horizontal pbar tune.</td></tr></table>
<!-- Author: Tuula, Juan Pablo, Ulrich -->


<!-- Date: Mon Oct 9 08:47:50 2006 -->
<pre>Week summary: 
 
Monday: 
reformatter errors 
work with sound cards 
possible clock glitch 
problems with restarting SVXMON 
clock glitch 
beam lost due to lightening 
 
Tuesday: 
D-mode calibration: beam off 
 
Wednesday: 
emergency maintenance for b0sili01/02 
new store with initial luminosity 125E30 
FIB single event upset 
SVXMon yellow for SB0W9L2 
 
Thursday: 
IMON test version confuses 
trigger test and AGIGi2 calibration 
new store with initial luminosity 204E30 
 
Friday: 
quench 
big trip just before end of store 
yellow cells in SVXMON 
low occupancy cell in SVTSPYMon 
CAEN crate 9 hockerization 
 
Saturday: 
new store with initial luminosity 188E30 
Tevatron tune excursion, increased LOSTP 
pinky 
CAEN crate 1 hockerization 
CAEN crate 8 hockerization 
 
Sunday: 
B0AAGC spiky 
D-mode calibration, beam on 
SRC error 
new store with initial luminosity 203E30 
 
Monday: 
unstable beam conditions 
CAEN crate 2 communication failure 
  
 
</pre>
<!-- Author: Tuula -->