<!-- Title: 11:43:16  Mon Apr 14 2003 -->
<!-- Crewchief: reid -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Starting a new week of pager carrying...</pre>


<!-- Date: Mon Apr 14 12:20:53 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1858&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1858  width='300' align='top'></td><td>The SVT plot for the beginning of this store.</a></td></tr></table>
<!-- Author: reid -->
<!-- Comment: Mon Apr 14 12;21;13 comment by...reid -->
<pre>TWO TIMES!</pre>
<!-- Date: Mon Apr 14 12:20:53 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1858&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1858  width='300' align='top'></td><td>The SVT plot for the beginning of this store.</a></td></tr></table>
<!-- Author: reid -->



<!-- Date: Mon Apr 14 12:31:48 2003 -->
As reported by the operation managers after the 9:00 am meeting 
 
<H1> there are not planned studies from BD this week</H1> 
 
This implies that we have to fit some of our studies with svxdaq in between stores.
<!-- Author: Gino -->


<!-- Date: Mon Apr 14 14:20:34 2003 -->
<pre>Access between 2:30 and 6:00 pm. 
 
 
PLAN FOR TODAY ACCESS: 
 
Reid 	untill 6	10036V 
Julia 	untill 6	13448N 
Gino 	untill 6	07410V 
Stan 	untill 6	work outside of the collision hall (NO KEY) 
Sal	untill 5	09601V 
Steve 	untill 5:15	08535V 
Lester	untill 6	09628V 
 
FIRST PRIORITY 
SB0W8/9  
	Check the fuse on the FTM and swap it if necessary. 
	If not the fuse wap the FIB 
	If not the FIB swap the FTM with a BUFFED one. 
 
SECOND PRIORITY 
Finish up buffing b0fib05 
	IB4W2/3 
	IB4W4/5 
	IB3W0/1 
	LB1W2/3 
	Get 2 out of the collision hall and we start soldering. 
	go back to the collision hall and get the other two out 
	   wait for the first two and go back in to install them 
	get the other 2 and install them. 
 
 
</pre>
<!-- Author: Gino -->
<!-- Comment: Mon Apr 14 17;05;35 comment by...Stan, Reid, Gino, Lester, Julia and Steve. -->
<pre>Mission accomplished.

There are still things going on in the first floor but the access is over.</pre>
<!-- Date: Mon Apr 14 15:58:46 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W5L4 
<li>problem n: 11 
<li>Status: needs_access_2hr
<li>Type: DropReadOut_nonRX
<li>Action: Diagnosis_update
<li>entered by: lmiller 
<li>description is: <pre>Tried swapping DOIM fiber with e153; problem stayed with ladder.
Needs light level measurement. (e154 remains out of hdwdb).</pre> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Apr 14 16:11:06 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W6L4 
<li>problem n: 345 
<li>Status: needs_access_2hr
<li>Type: RX
<li>Action: Diagnosis_update
<li>entered by: lmiller 
<li>description is: Tried swapping DOIM fiber with e563. Both ladders function that way.  Should swap RX between e563 and e564 (Channel 8 and 9). After swapping fibers back but 7 low problem reappeared. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B5W6&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Apr 14 16:20:05 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W5L0 
<li>problem n: 840 
<li>Status: needs_access
<li>Type: RX
<li>Action: Diagnosis_update
<li>entered by: lmiller 
<li>description is: Bit 4 high not reproduced in svxdaq. This problem is  intermittent, however.  
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=L00&wedge=B1W5&layer=L0">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Tue Apr 15 10:16:22 2003 -->
<h3>Gui Speed Up</h3> 
We are testing a potential speed up to the PS GUI, which currently spends something like 15% of the time just on updating the masks.  The change only affects the Java code, not the code running on svxinter. 
We set up a special version (Yimei's) and run as normal and 
had the following successes <ul> 
<li> Correct loading of masks from CAENvolts.dat, both at 
startup and when button is clicked with the masks slightly altered 
<li> Correct obeying of masked ladders, both when a wedge is turned on and when the masked ladder is specifically requested to 
go to STANDBY 
</ul> 
Is is a matter of typing a line at the command prompt and restarting the GUI to swap back and forth.  Therefore, we decided 
to keep Yimei's version running for now.  If no problems arise, we will move the code to the default version. <P> 
<h3> To swap back to the default GUI </h3> 
<ol> <li> Kill/Stop the current GUI 
<li> In the terminal from which it is running, type <BR>  
<I> setup caencontrol -j </i> 
<li> Restart the GUI (<i> PS </i>) 
</ol> 
If this doesn't work, you can always start the GUI from a new terminal using <a href='http://www-cdfonline.fnal.gov/internal/ops/svxii/runii/gui_restart.html'>normal instructions</a>
<!-- Author: SCN -->
<!-- Comment: Tue Apr 15 14;31;17 comment by...Gino -->
<pre>As for the next entry the system was brought to STDBY, from there to ON and back to STDBY. No problem with the new version of the code.</pre>
<!-- Comment: Tue Apr 15 15;22;56 comment by...Andy H. -->
So was it faster, or what?
<!-- Comment: Tue Apr 15 15;29;55 comment by...reid -->
<pre>The new version of the PS GUI took just under 6 minutes to bring the silicon from standby to on.  I don't know what the old transition time was though for comparison. </pre>
<!-- Comment: Wed Apr 16 06;12;12 comment by...SCN -->
The transistions won't be faster, but the 7 sec monitoring should be faster.  (it is hard to tell, but it seemed to me to be true)
as the GUI is doing much less networking between svxinter and b0dap42 for that.
<!-- Comment: Wed Apr 16 17;26;25 comment by...Andy H. -->
It does indeed seem faster --- good job!
<!-- Date: Tue Apr 15 12:44:24 2003 -->
Silicon now in standby.  Gino and I brought the system up from off to standby.  We took our time in bringing the system up and we were met with very few trips and a couple recalcitrant fib crates.  <p> 
After bringing the system to standby, we made use of the TeV quiet-time and brought the system to ON and took a couple hundred events (run 161517) to see that the digital side of the system was happy.  Everyting looked happy in SVXMon Cell ID slides.<p> 
We finished our run and brought the system back to STANDBY before the end of quiet-time. 
<!-- Author: reid -->


<!-- Date: Tue Apr 15 15:04:21 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W8All 
<li>problem n: 969 
<li>Status: needs_work
<li>Type: Wedgewide_Cap
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: Wedgewide random cap id errors beginning run 161408 (4/13) 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B5W8&layer=All">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Tue Apr 15 21;29;03 comment by...Gino -->
<pre>This is a good candidate for going up in the list of FTMs to be buffed up.</pre>


<!-- Date: Wed Apr 16 00:19:09 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1859&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1859  width='300' align='top'></td><td>Current SVT plot at the beginning of the new store (store #2433) . </a></td></tr></table>
<!-- Author: reid -->



<!-- Date: Wed Apr 16 09:04:14 2003 -->
<h3>Caen Communication Error</h3> 
Summary of the communication error that we had in the silicon this morning at around 7:30am.  <p> 
The NW Top Top CAEN Crate1 (or CRATE 0 in si ps conventions) lost communication with the GUI.  Because I was unsure on the  numbering conventions, and because i was just out the door headed for the lab, i told the shift to start another run and i'd be in shortly to reset the crate.  I figured it would result in less downtime to wait for me than to rush and reset the wrong crate.<p> 
While i was on the way in, Andy Hocker arrived and was able to reset the appropriate CAEN crate and get the run started again.  <p> 
<b>For the future:</b> 
<ul> 
<li>Andy explained the numbering scheme that he is using in iFix.  He uses a 1-16 numbering scheme where the number reported in an alarm by iFix corresponds to the label on the first floor reset buttons.   
<li>If this happens again an ACE could be told to use the crate number in iFix to reset the right crate with the buttons on the first floor.   
<li>If i were driving over the phone, i would have probably reset the wrong crate. crate 1 in the ps subgroup is NW Top Bot; we use a 0-15 scheme.   
<lI>Andy promised to write up a summary about the numbering convention along with some instructions to put on the webpages. 
</ul>
<!-- Author: reid -->
<!-- Comment: Wed Apr 16 17;24;55 comment by...Andy H. -->
For what it's worth, I use a 1-16 scheme because that's the scheme used in
$CAENCONTROL_DIR/CAEN.map.
<!-- Date: Wed Apr 16 09:55:48 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1860&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1860  width='300' align='top'></td><td>Last Night long run STUCK LADDER SUMMARY: IB0W4 is the only screamer.</a></td></tr></table>
<!-- Author: Gino -->


<!-- Date: Wed Apr 16 10:34:17 2003 -->
<a 
href=http://www-bd.fnal.gov/cgi-mcr/elog.pl?nb=2003&action=view&page=287&anchor=102546&hilite=10:25:46- 
target=_top>Tev Aborted</a> but it claims to be clean.  Post-Abort checkout in process.  Access possibilities being investigated. 
<!-- Author: SCN -->
<!-- Comment: Wed Apr 16 10;52;08 comment by...reid -->
The BLM's at the abort of store #2434 look clean.  <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=317&frame=2&anchor=10:44:42.831'>
Here is the link to the entry that I made in the shift e-log.</a> 

<!-- Comment: Wed Apr 16 10;54;50 comment by...reid -->
also, for future reference, these fast plots from the BLM's can be found on ACNET Page E20 -&gt Display Logged Data -&gt List Dates -&gt BLM Summary.

<!-- Date: Wed Apr 16 12:00:13 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W2L1 
<li>problem n: 961 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: This is a bit 7 high problem.  error rate of 2-5% for most runs, occasionally it is higher, but it is present in all runs. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B5W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Apr 16 13:53:57 2003 -->
<BR> 
biasInfo files (in /cdf/people2/svxii/public_html/biasInfo) were not being written since April 14. 
<BR> 
These files are important because they contain a list of biased  
ladders for each and every run. 
<BR> 
I have caught up the process by hand, but I don't know if the  
cron job is working correctly now.
<!-- Author: Jason -->


<!-- Date: Wed Apr 16 15:09:16 2003 -->
<h3>Access report </h3> 
<ul> <li> Put in Buffed FTMs in b0fib03 sl 8,9,11,12  
which is IB0W4/5, IB0W0/1, IB1W0/1, IB2W2 
<li> Swapped the FFOs between b0fib00 and b0fib03 to 
see if "crate-wide out of synch problems" follow FFO.
<!-- Author: SCN, Reid, Gino -->
<!-- Comment: Wed Apr 16 15;09;45 comment by...ulizer -->
</ul>

<!-- Comment: Wed Apr 16 16;44;30 comment by...SCN -->
Even in run 161555 last night there were still "massive" pipeline out of synch errors.  I did not check the source, but it is likely it was b0fib00-
<pre> b0dap63.fnal.gov:ConsumerErrorRe:9:52:17 AM->Runtime Error 2, Event 3903, RunNum 161555:
SvxMon Halt Recover Run: Pipeline out of synch in 735 silicon readout chips</pre> This is why we swapped the two fanouts.




<!-- Comment: Wed Apr 16 21;15;49 comment by...reid -->
The FFO's that were swapped are listed below
<table border=1>
<tr>
 <td>Fib Crate</td>
 <td>Installed FFO</td>
</tr>
<tr>
 <td>FIB00</td>
 <td>550319 (s/n 111)</td>
</tr>
<tr>
 <td>FIB03</td>
 <td>550321 (s/n 113)</td>
</tr>
</table>
This table lists the location of the FFO <b>AFTER</b> the boards were swapped.
<!-- Comment: Thu Apr 17 08;04;02 comment by...SCN -->
Hmm...we <i>still</i> get <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=319&frame=2&anchor=07:48:31.668'>cratewide out of synch</a> on b0fib00.  That pretty much exonerates the FFO.  Next steps <ol>
<li> Try to catch a protocol error in the FFO (pull CDF Error?) from the SRC (the FFO does error checking on the SRC commands)
<li> Look at light levels as measured by the FFO
<li> (Eventually) Swap cables at the Splitter to see how that 
affects light levels and/or the problem.
</ol>
If it ain't the light levels or transmission related, then
we'll need to start thinking about the backplane (flaky ADV_PIPE ttl signal?) in order to fix this (low rate non-safety issue) problem.  I would encourage this
to be coupled to buffing the FTMs on this crate (we need to do
7 of the 9 anyway) but it is not yet demanding urgency.
<!-- Date: Wed Apr 16 17:38:06 2003 -->
<h3>IB0W5L2</h3> 
Took a quick run (161596) with half of L3 to check the digital integrity of the silicon after messing with it all morning (see previous log entries).  Found a new "No Data" layer in SVXMon.  After some work learning how to decode the SVXMon map (by discovering this <a href="http://www-cdf.lbl.gov/~bachacou/form.html">beautiful link</a>, we discovered that it was IB0W5L2.  <p> 
My diagnosis reveals the following 
<ul> 
<li>b0fib03 passes cold start fine.<br> 
<li>IB0W5L2 initializes fine<br> 
<li>the AVDD and DVDD currents all look fine. 
<li>IB0W5L2 gives nothing but c2c2 errors. (laser3700.svx)<br> 
</ul> 
The decision was made to take the layer out of the hdwdb because there is not much more to be learned by keeping it in for the next store; the ladder is clearly sick and needs some attention.   
 
  
<!-- Author: reid -->
<!-- Comment: Thu Apr 17 06;52;17 comment by...Gino -->
<pre>Next step, during a short access, swap the fiber with a working channel of the DAQ. Move from there.</pre>
<!-- Date: Wed Apr 16 17:43:35 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W5L2 
<li>problem n: 1001 
<li>Status: needs_access
<li>Type: Other
<li>Action: Diagnosis
<li>entered by: reid 
<li>description is: No Data from this layer.  A buffed FTM was installed today and in the post-access checkout, the ladder looked fine.  Shortly after however, the ladder 'went booboo' as they say...  <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=150&frame=2&anchor=17:38:06'> Link to e-log entry describing the problem</a>  
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Apr 16 19:31:55 2003 -->
Upgraded the firmware for all Fibs in b0fib00 to fib_v16.jam  
(after checking that <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=149&frame=2&anchor=16:10:51'> 
b0fib05 upgrade</a> induced no new errors via the bitreporter)  Page me if there are any new problems.  2 down, 6 to go.   
<!-- Author: Reid, SCN -->



<!-- Date: Thu Apr 17 00:55:06 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1861&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1861  width='300' align='top'></td><td>SVT Coverage at the beginning of store 2436.</a></td></tr></table>
<!-- Author: reid -->



<!-- Date: Thu Apr 17 12:04:22 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W4All 
<li>problem n: 1002 
<li>Status: needs_access
<li>Type: Wedgewide_other
<li>Action: Removed_hdwdb
<li>entered by: reid 
<li>description is: Stuck Cell id numerous times.  The wedge still passes init according  to the init logs.  this FTM is already buffed (in fact its a super  buffed eleven).  Now she needs some work. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W4&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Apr 17 12:16:03 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1862&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1862  width='300' align='top'></td><td>New SVT with a big  hole where SB2W4 used to be</a></td></tr></table>
<!-- Author: reid -->

<!-- Date: Thu Apr 17 14:02:43 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W2L1 
<li>problem n: 784 
<li>Status: needs_work
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: Bit 0 high ~30%.  Causing errors in chip ids. there have been errors in several consecutive runs  
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Apr 17 14:06:06 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W0L0 
<li>problem n: 604 
<li>Status: needs_work
<li>Type: AVDD2
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: Cap ID errors 98% starting run 161555. is this the same AVDD2 problem?  
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Apr 17 14:13:04 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W2L3 
<li>problem n: 975 
<li>Status: needs_observation
<li>Type: RX
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: Bit 0 high ~5% starting 4/11.  From RX swap?  
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=L00&wedge=B0W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Apr 17 18:13:06 2003 -->
<b>Silicon Access Report</b><p> 
Swapped super-buffed FTM (564035/105) with buffed FTM (562398/111) for SB2W4. 
<ul><li>Stuck ladder not seen in pre-test nor post test.</li> 
<li>No problems introduced in wedge.</li> 
<li>A preliminary investigation of the board, using an ohm-meter, shows a bad FE-clock on Port A.</li></ul>
<!-- Author: David -->
<!-- Comment: Thu Apr 17 19;01;11 comment by...David -->
<pre>A coldstart was performed for all of silicon post-access.</pre>


<!-- Date: Thu Apr 17 21:45:49 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1863&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1863  width='300' align='top'></td><td>At the beginning of store 2438, SVT looks better again after this evenings access.  Early in the store but so far no screaming from SB2W4.  </a></td></tr></table>
<!-- Author: reid -->

<!-- Date: Thu Apr 17 23:46:24 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W8All 
<li>problem n: 969 
<li>Status: needs_access
<li>Type: Wedgewide_Cap
<li>Action: Monitoring
<li>entered by: bolla 
<li>description is: SHould be buffed ASAP 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B5W8&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Apr 18 14:43:45 2003 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 256
Calibration type  : standard
Run period tag    : Apr_2003
DPS-off run       : 161680
DPS-on run        : 161679
Requested by      : smaria/jonatan
Main process id   : 243318619
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->
<!-- Comment: Tue Apr 22 11;52;24 comment by...Jason Nielsen -->
This job did not exit cleanly (hence no "Failure" message in the e-log).<BR>
The disk on which calibrations are processed is full.  I have moved some data to the backup system at LBL, and I am adding a disk space check so that at least the job will fail with a well-defined error.
<!-- Date: Fri Apr 18 20:26:43 2003 -->
<pre>SB5W9L3 removed from HDWDB. The data did NOT MAKE much sense. 
With svxdaq it has some problem. It is probably responsible for the long readout time tails. 
A better understanding should be developed before getting it back in business. 
PDB updated. 
Gino and Reid</pre>
<!-- Author: Gino -->


<!-- Date: Fri Apr 18 21:36:59 2003 -->
Put in store 2441.  Losses were quite stable at the start of the  
run so i biased the silicon after the fast TeVMon gave the go-ahead.  SVT coverage has not changed significantly for this store.  
<!-- Author: reid -->


<!-- Date: Sat Apr 19 09:03:02 2003 -->
<p><b>Logging of CAEN crate communication errors</b></p> 
<p> 
On the SVXIICON PC desktop is a file called "CAENerrlog". 
Double-click it to open; it will say the file is in use and 
will ask if you want to make a copy.  Say yes.  Here's what it 
looks like so far:</p> 
<p><pre> 
04/18/03 09:15:11 PM --- Crate 5 reported an error. 
04/18/03 11:51:49 PM --- Crate 5 reported an error. 
04/19/03 03:33:54 AM --- Crate 5 reported an error. 
04/19/03 04:19:51 AM --- Crate 5 reported an error. 
04/19/03 04:42:40 AM --- Crate 5 reported an error. 
04/19/03 06:49:31 AM --- Crate 5 reported an error. 
</pre></p>
<!-- Author: Andy H. -->
<!-- Comment: Sat Apr 19 09;03;50 comment by...Andy H. -->
Note that the numbering scheme is 1-16.


<!-- Date: Sat Apr 19 09:24:56 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1864&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1864  width='300' align='top'></td><td>ErrorLogger shows that all of wedge 5 was giving stuck Cell Id and not just LB1W5L0.  The rest of the wedge is still in the hdwdb but will come out if it screams any more. </a></td></tr></table>
<!-- Author: reid -->


<!-- Date: Sat Apr 19 10:00:45 2003 -->
Paged several times for trips in LB1W5L0.  
<a href= 
'/cgi/elog/elog.pl?nb=2003&action=view&page=325&frame=2&anchor=06:11:21.756'>Here is the shift e-log.</a>  LB1W5 has stuck cell id problems (as noted above).  I brought the layer back up over the phone three times before coming in to take a closer look. 
<p> 
Took LB1W5L0 out of the hdwdb.  Mistakenly took out LB1W4L0 out too.  In trying to recover LB1W4L0, the whole wedge became obstinant and would not turn on with the error:<p> 
ERROR: not all Fibs are initialized<br> 
ERROR: FIB does not respond to Request for handshake 
<p> 
Talked with Steve and Gino.  Found that the CrateLoader was not working. The fib map was not downloaded after rebooting the b0fib07.  Manually loaded the config mess for the crate.  <p> 
Thought that this would fix the problem but didn't.  LB1W4 still refused to turn on with the error: <p> 
ERROR: Power Supply L00 East W4 Handshake - could not turn on power - tried 10 times. <p> 
At this point, it is unclear what the problem is.  I am able to initialize LB1W5L1-3 with svxdaq successfully so it doesn't appear to be a hosed FTM.  Is it a FIB problem?  Powersupply?  <p> 
decide to take out LB1W4 from the hdwdb so that we can get Si back into the run.    
<!-- Author: reid -->
<!-- Comment: Sat Apr 19 10;42;06 comment by...reid -->
Currents for LB1W5L0 (from 20030419.si_) before the first trip for which i was paged.
<pre>
210  0 -32765     5.20    93.00 
 210  0 -32765     5.20   110.00 
 210  0 -32765     5.20   108.00 
 210  0 -32765     5.22   101.00 
 210  0 -32765     5.20   103.00 
 210  0 -32765     5.22   103.00 
 210  0 -32765     5.20    96.00 
 210  0 -32765     5.21   111.00 
 210  0 -32765     5.20   141.00 
 210  1   4099     0.53     2.00 
 210  1   4099     0.52     2.00 
 210  1   4099     0.52     3.00 
 210  1   4099     0.52     2.00 
 210  1   4131     0.52     3.00 
</pre>
<!-- Comment: Sat Apr 19 10;44;41 comment by...reid -->
current sppikes got as high as 183 before one of the trips.  These are the currents for DVDD 
<!-- Date: Sat Apr 19 10:17:14 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W5L0 
<li>problem n: 1004 
<li>Status: needs_access
<li>Type: Chip_other
<li>Action: Diagnosis
<li>entered by: reid 
<li>description is: Stuck Cell ID which was leading to trips.  All layers in the wedge appear to have stuck Cell ID now too.  In need of a buffed FTM. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=L00&wedge=B1W5&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Apr 19 10:21:02 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W4All 
<li>problem n: 1005 
<li>Status: needs_observation
<li>Type: Wedgewide_other
<li>Action: Removed_hdwdb
<li>entered by: reid 
<li>description is: Had trouble powering the wedge on after troubles with neighboring  wedge LB1W5.  Here is a <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=150&frame=2&anchor=10:00:45'> description of the troubles</a>   
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=L00&wedge=B1W4&layer=All">report</a></ul>
<!-- Author: Problem DB -->





<!-- Date: Sat Apr 19 14:15:57 2003 -->
<h3>Lost a FIB/FTM for SB0W6/7</h3> 
All ladders in SB0W6 and SB0W7 started failing initialization 
upon a HRR at 12:57:48.  A subsequent COLDSTART at 1:14:36 brought this to the attention of the Aces.  Aces report that 
SVXMon is claiming "No First Chip" for at least some of these ladders, so, presumably we have lost an FTM or FIB (although the currents look "OK"?).  I turned those ladders offline in the hdwdb and Reid is downloading CAENvolts.dat.  We'll request  
an access ASAP to recover.  In the meantime b0fib02 now passes COLDSTART.
<!-- Author: SCN -->


<!-- Date: Sat Apr 19 19:51:00 2003 -->
<h3>Controlled Access Summary</h3> 
Went in to fix SB0W6/7.  It turned out to be a blown fuse on the FTM.  We replaced the fuse and re-installed the board.<p> 
These wedges are full of problems so it was hard to see if we introduced any new problems in the access.  It appears that there are some new errors on e061 that were not there before. "not chip id" errors are showing up at about a 5% rate.  We tried to re-clean and grease but the problem stayed.  The error seems wierd because you see the first chip-worth of data followed by a c2c4.  Is this a fib problem?  Doesn't really seem to have all the characteristics of a bit or Rx problem.  <p> 
Anyway, David and I didn't feel like we had the expertise to make the call to do anything more in such a short access.  The wedges were put back into the hardware database.  (sans the layers that were out before the fuse incident e072 and e060). 
<p> 
We also took a look at the interlocks for LB1W4.  Nothing obvious from the collision hall.  I put the wedge back into the hdwdb to try this wedge again.  It was still unhappy but tripped on DVDD Ovc without complaining about handshakes this time.  It is looking more like a PS problem...<p> 
We got two wedges back and introduced a new error on one layer.  We didn't drop the interlocks.  
<!-- Author: reid and david -->
<!-- Comment: Sat Apr 19 19;56;04 comment by...reid -->
<pre>Thanks to Andy for coming in on the access with us.</pre>

<!-- Comment: Sun May  4 08;57;17 comment by...Gino -->
<pre>e072 (SB2W0L2) was in before this incident and should be put back in ASAP.
</pre>
<!-- Date: Sat Apr 19 19:59:06 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W6/7All 
<li>problem n: 1006 
<li>Status: fixed
<li>Type: No_Init
<li>Action: Added_hdwdb
<li>entered by: reid 
<li>description is: Replaced blown fuse on the FTM to bring the wedges back. See the <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=150&frame=2&anchor=19:51:00'> Si elog entry</a>  for details. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W6/7&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Apr 19 20:02:57 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W6L1 
<li>problem n: 1007 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Diagnosis
<li>entered by: reid 
<li>description is: After changing the fuse on the FTM we get 'Not Chip ID' errors on  this channel at a low rate. See <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=150&frame=2&anchor=19:51:00'> log entry </a>  for details.  
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W6&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Apr 19 21:01:39 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1865&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1865  width='300' align='top'></td><td>access appears to have filled the SVT hole.  </a></td></tr></table>
<!-- Author: reid -->
<!-- Comment: Sat Apr 19 21;26;30 comment by...reid -->
<pre>Store # 2443.</pre>
<!-- Date: Sat Apr 19 21:19:14 2003 -->
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=150&frame=2&anchor=20:02:57'> 
THIS </a> is very likely due to the fact that the SRC parameter L2R/L2A is not 0 but 1. 
This is a left over of I do not know who that should be changed in the configuration files for svxdaq. 
  
<!-- Author: Gino -->
<!-- Comment: Sun Apr 20 09;02;27 comment by...SCN -->
Actually, let's not confuse people.  The DAQ and chips should be able to <B>easily</b> handle a L2R every once in a while. It is
really due to a glitch between the Chip and DDR when the READOUT cycle stops while some chip is still in readout (i.e. during an ABORT aka L2R).  There is new Fib firmware to work around this chip bug, which is slowly finding its way into the Fibs.<P>
The real question is why the SRC keeps finding its way into
1 L2A/L2R mode, which (currently) exposes this bug.  I'll bet it is not in a configuration file since most likely Reid and David just read back the RC configuration, but
rather it is in some other place.  We'll track it down in the next few days.<p>
Nice job on the access gents...
<!-- Date: Sat Apr 19 21:28:57 2003 -->
<pre>There was some trouble with the COT at the beginning of the store and the min-bias trigger went a little long so i biased the Si a minute or two after the &lt;b&gt;slow&lt;/b&gt; TeVMon gave the go-ahead.  Si still beat RC to coldstart.  </pre>
<!-- Author: reid -->


<!-- Date: Sun Apr 20 04:43:46 2003 -->
Paged for some troubles with SB5W8. <p>  
CO requested  several manual HRR's for its complaining in SVXMon.  Then the wedge started to pull auto HRR.  Lots of stuck ladder errors on all layers.  <p> 
I was paged a second time when it tripped all layers of the supply.  We recovered and it promptly returned to its errant ways, tripping most of the layers.  I've decided to take it out of the hdwdb.  <p> 
Looks like we didn't make it with our FTM buffing soon enough for this guy.  
<!-- Author: reid -->
<!-- Comment: Sun Apr 20 04;44;48 comment by...reid -->
<pre>another hole in SVT.  We should request an access asap to buff this FTM.</pre>


<!-- Date: Sun Apr 20 04:47:26 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1866&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1866  width='300' align='top'></td><td>A snapshot of the errors from SB5W8 in the SVXMon Error Logger.</a></td></tr></table>
<!-- Author: reid -->

<!-- Date: Sun Apr 20 04:53:47 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W8All 
<li>problem n: 969 
<li>Status: needs_access
<li>Type: Wedgewide_Cap
<li>Action: Removed_hdwdb
<li>entered by: reid 
<li>description is: Complaining loudly in SVXMon: Stuck Ladder. Needs the buffed FTM  loving. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B5W8&layer=All">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Sun Apr 20 17:02:56 2003 -->
<p><b>Silicon in for store 2445</b</p> 
<p> 
The shift crew forgot to page silicon during pbar loading (blame me) so Reid wasn't going to be able to get here in time.  He let 
me make the call for turning up HV.  Losses are below 10 kHz and look good.  The TEL went off and on a few times while we were ramping up; MCR said they were fixing it and that it should stabilize in a few minutes.</p>  
<!-- Author: Andy H. -->
<!-- Comment: Sun Apr 20 17;03;35 comment by...oops -->
</b>Un-bold


<!-- Date: Mon Apr 21 07:26:13 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1867&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-1867  width='300' align='top'></td><td>Run 161792 (Current store).  SB5W8 removed for excessive HRR, else OK.</a></td></tr></table>
<!-- Author: SCN -->


<!-- Date: Mon Apr 21 11:38:41 2003 -->
<p> 
iFix alarm logging re-enabled.  Already I think I've caught the source of the spurious "here one second, gone the next" SVX/L00 alarms --- appears to be excursions in the coolant conductivity readings --- to be investigated further.</p> 
<!-- Author: Andy H. -->