<!-- Title: 10:54:14  Mon Jul 28 2003 -->
<!-- Crewchief: Reid -->
<!-- Op1: the Get-Sili Crew -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Start of a new week</pre>

<!-- Date: Mon Jul 28 12:14:22 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W2/3All 
<li>problem n: 1086 
<li>Status: fixed
<li>Type: Other
<li>Action: Swap_VRB
<li>entered by: reid 
<li>description is: b0svx07 slot 10 VRB hung mid-run (see the <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=626&frame=2&anchor=11:40:42.745'> general e-log entry here</a>).  The VRB was swapped with one from  trigger room diag crate.<table border=1>
<tr><td><b>IN</b></td><td>PREP:</td><td>550280</td><td>Serial:</td><td>??</td></tr>
<tr><td><b>OUT</b></td><td>PREP:</td><td>551009</td><td>Serial:</td><td>??</td></tr></table> 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B4W2/3&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Jul 28 23:53:17 2003 -->
<h3>Access Report</h3> 
Very smooth access.  We believe that we've fixed 5 of 5 problems that we set out to cure. A brief summary follows. <br> 
<ul> 
<li><b>e284</b>  bit 0 problem fixed with Rx swap. 
<li><b>e294</b>  bit 2 problem fixed with Rx swap. 
<li><b>e152</b>  bit 5 problem disapeared with FIB swap.  
<li><b>e154</b>	 bit 0 problem disapeared after an Rx swap and the same FIB swap as mentioned above. 
<li><b>f830</b>  bit 0 problem fixed with Rx swap. 
</ul> 
No other problems were introduced in the course of the night and the interlocks were not dropped.  
<!-- Author: david and reid -->


<!-- Date: Tue Jul 29 10:51:11 2003 -->
 
<p> 
Please see shift e-log <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=629&frame=2&anchor=09:33:45.702'>entry</a> 
regarding this morning's BC mismatches in wedge 4, costing CDF ~30 minutes of high-luminosity beam time.  
<p>
<!-- Author: Bill A -->


<!-- Date: Tue Jul 29 13:46:49 2003 -->
<h3>Store 2828 Update</h3> 
Had a lot of trouble with the store so far today.  <br> 
There is some problem with the triggers that are using Silicon reconstruction in level 3.  In Level 1 and Level 2, silicon is fine.  SVT is not complaining at all.  But when we look at the trigger rates, the rates are far from their nominal values and make it look like level 3 is getting garbage for the reconstruction.  <p> 
Early in the store, there were BXing errors from the FIB that we put in last night.  SVT was modified to ignore errors so that the run could continue.  Then this silicon reconstruction problem was noticed.  <p> 
The thought was that the offending FIB and SVT modifications might have caused the problem.  We took the FIB out of the DB and ran.  The same problem showed up so it was confirmed that the FIB error is not at fault.  Those ladders (SB1W4/5) were re-included in the run. <p> 
We also looked at raw data from some of the crap runs.  We are able to see channels and data in the events so everything points to a working silicon detector.  Currents look good, and occupancies seem fine. 
Other things that have been tried:  
<ul> 
<li>Cleaned up Event Builder 
<li>Tried other Calibration Tag-sets and Trigger tables.  A new trigger table was tested last night and is being used today.  Maybe this screwed things up somehow. 
</ul> 
So far, nothing is conclusive and there are a myriad of experts looking into the problem.   
<p> 
Meanwhile, a couple of other, un-related, silicon problems have shown up: 
<ul> 
<li><b>e154</b> gives no data after the first two chips.  This is a ladder that we worked on last night.  It had an OBDV kludge on the FTM.  The current thought is that maybe the new FIB doesn't have the latest firmware??  Not sure though.  Seems weird to see the first two chips. 
<li><b>IB3W1L4</b> was giving no data in SVXMon.  It looked like it was reading out the first 64 channels and then quitting and reading again further on.  Possibly a bit 6 error?  The error is flaky at this point. 
</ul>
<!-- Author: reid -->
<!-- Comment: Tue Jul 29 14;53;31 comment by...Andy H. -->
The problem with the L3 silicon triggers was resolved --- the SVT process that writes the beamline to the bank read by L3 was not running, and therefore L3 was picking up a beamline of zeros.



<!-- Date: Tue Jul 29 15:51:19 2003 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2410&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2410' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2411&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2411' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2412&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2412' width='300'></a></center>
<!-- Author: Sunny -->


<!-- Date: Tue Jul 29 17:15:39 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2413&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2413  width='300' align='top'></td><td>SVT plot for store 2828	</a></td></tr></table>
<!-- Author: reid -->

<!-- Date: Tue Jul 29 18:05:11 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W0L0 
<li>problem n: 647 
<li>Status: needs_work
<li>Type: RX
<li>Action: Monitoring
<li>entered by: petemc 
<li>description is: Bit 3 high still intermittent, but in runs in which it appears, it has a higher rate (~50% in a recent run) 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B5W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jul 29 18:11:37 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W5L2 
<li>problem n: 1077 
<li>Status: needs_work
<li>Type: RX
<li>Action: Monitoring
<li>entered by: petemc 
<li>description is: Was quiet for a few days, but now bit zero problem is back. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jul 29 18:30:21 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W1L3 
<li>problem n: 65 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: petemc 
<li>description is: Persistent bit 5 and bit 2 errors at few percent level. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W1&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jul 29 19:34:35 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W5L0 
<li>problem n: 1088 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: petemc 
<li>description is: A few runs had bit 0 and C2 termination errors, which stopped on their own.  Watch to see if it recurs. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B5W5&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jul 29 19:53:08 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W8L0 
<li>problem n: 1012 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Monitoring
<li>entered by: petemc 
<li>description is: Since dropped first chip problem cleared up, persistent low level (~1%) of various problems including pipeline out of synch, dropped readout, invalid cell id, unknown channel. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B5W8&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Jul 30 08:46:24 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2414&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2414  width='300' align='top'></td><td>SVT plot for store 2830.	</a></td></tr></table>
<!-- Author: reid -->


<!-- Date: Wed Jul 30 13:38:09 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2415&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2415  width='300' align='top'></td><td>Paged for a pinkie in SB0W5L3 AVDD has lower current than  expected.  While I was looking at it, the current came back  to normal.  </a></td></tr></table>
<!-- Author: reid -->


<!-- Date: Wed Jul 30 16:23:35 2003 -->
<h3>post abort work</h3> 
David and I did some testing after the store was lost today. David is compiling a list of candidates for access work.  He  found a candidate for a VRB swap (SVX02 slot 11).  I got a spare VRB from the secret rack on the third floor and flashed it with the most current prom that I saw documented in the e-log (vrb3506P.hex) in the diag test stand.  <p> 
We were ready to swap but then realized that our VRB was in the SRC crate.  <p> 
After talking to Sal and Lester, we decided that if we were to turn that crate off, the Silicon should also be off.  We turned the silicon from off to standby but at this point, the beams people were putting test bunches into the machine.  We decided that we would wait until we had some quiet-time and could test to do the swap.  <p> 
I brought the Silicon back up from off to standby and brought the system through a cold-start.  Everyone came up fine.
<!-- Author: reid -->


<!-- Date: Wed Jul 30 16:26:00 2003 -->
<h3>SB1W3L4 update</h3> 
I put the layer back into the hdwdb and tried to power this layer again.  The behavior has not changed since last week and it looks like this guy is a candidate for some CAEN power supply work during an access.  
<!-- Author: reid -->


<!-- Date: Wed Jul 30 23:55:03 2003 -->
<b>Access Report</b><p> 
 
<ul> 
<li>Swapped the old FIB back for SB1W4/5 due to BXing errors in wedge 4 and not the right firmware for SB1W5L4 (BEclk for OBDV kludge).</li> 
<li>Swapped DOIM cables to isolate bit 6 low in IB3W1L4 - errors stayed with ladder - needs light measurement.</li> 
<li>Swapped RX for SB2W5L2 to fix bit 0 high - success.</li> 
</ul> 
The A-Team strikes again!
<!-- Author: David & Reid -->


<!-- Date: Wed Jul 30 23:56:40 2003 -->
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=165&frame=2&anchor=23:55:03'> 
Silicon Controlled Access Report </a> 
<!-- Author: reid and david -->

<!-- Date: Thu Jul 31 17:16:25 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W4L0 
<li>problem n: 135 
<li>Status: needs_maintenance
<li>Type: DRO_00F3
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: Still DRO OOf3 at signficant levels every 5 runs or so.   
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W4&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Aug 1 08:43:34 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W0L0 
<li>problem n: 962 
<li>Status: fixed
<li>Type: RX
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: no problems seen for several weeks, considered fixed 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=L00&wedge=B1W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Aug 1 08:46:45 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W5L0 
<li>problem n: 840 
<li>Status: needs_observation
<li>Type: RX
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: rate has decreased and is now at most a few percent every 15 runs or so.  should continue to monitor, 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: Fri Aug 1 08:59:32 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W1L4 
<li>problem n: 441 
<li>Status: fixed
<li>Type: RX
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: no problems introduced--fixed. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W1&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Aug 1 09:02:24 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W9L0 
<li>problem n: 755 
<li>Status: fixed
<li>Type: RX
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: no problems seen since swap--fixed 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W9&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Aug 1 09:03:40 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W0L0 
<li>problem n: 627 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: problem continues at fairly constant low rate, continue to monitor. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B1W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Aug 1 09:06:33 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W6L3 
<li>problem n: 977 
<li>Status: needs_observation
<li>Type: DRO_00F3
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: problem occurs every 10-15 runs at < 1 % rate.  continue to monitor to see if anything changes. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W6&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Aug 1 09:08:37 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W3L1 
<li>problem n: 558 
<li>Status: fixed
<li>Type: No_Init
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: no data run errors seen since 6/29.  considered fixed. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W3&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Aug 1 09:10:41 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W3L2 
<li>problem n: 899 
<li>Status: fixed
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: no errors seen since last entry, considered fixed. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W3&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Aug 1 09:15:24 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W11L3 
<li>problem n: 643 
<li>Status: needs_work
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: rate has been increasing and is now consistently over 5% in each run.  should probably take a look at it. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B3W11&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Aug 1 09:17:29 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W5L4 
<li>problem n: 1063 
<li>Status: fixed
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: no problems seen since last entry, fixed. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B5W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Aug 1 09:20:14 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W2L1 
<li>problem n: 474 
<li>Status: fixed
<li>Type: Other
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: no errors introduced.  swap successful. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B3W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Aug 1 09:25:06 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W3L3 
<li>problem n: 1033 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: still see bit errors at low rate, we should continue to monitor it. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=L00&wedge=B0W3&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Aug 1 09:25:06 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W3L3 
<li>problem n: 1033 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: tompkins 
<li>description is: still see bit errors at low rate, we should continue to monitor it. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=L00&wedge=B0W3&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Aug 1 09:43:51 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2416&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2416  width='300' align='top'></td><td>SVT for Store 2847</a></td></tr></table>
<!-- Author: reid -->


<!-- Date: Fri Aug 1 09:49:41 2003 -->
Paged last night because the LOSTP readings were really high.  It appears that the LOSTP hardware was misbehaving because the B0ALOS variable did not reflect the same high readings.  <p> 
Still, we decided to stay out with the Silicon until the problem  
was better understood.  <a href= 
'/cgi/elog/elog.pl?nb=2003&action=view&page=637&frame=2&anchor=05:23:22.040'> 
Here is the shift e-log entry</a> 
<!-- Author: reid -->


<!-- Date: Fri Aug 1 23:44:05 2003 -->
<b>Bias Scan</b> <BR> 
Run #166942 <BR> 
<TABLE bgcolor=#cdc9a5> 
<TR><TH>Delta-V</th><th>Start Evt</th><th>End Evt</th></tr> <tr><td> 0</td><td> 0</td><td> 1032</td></tr>  
<tr><td>-3</td><td> 1038</td><td> 2027</td></tr>  
<tr><td>-6</td><td> 2038</td><td> 3024</td></tr> <tr><td>-11</td><td> 3028</td><td> 4022</td></tr> 
<tr><td>-16</td><td> 4034</td><td> 5005</td></tr> <tr><td>-21</td><td> 5009</td><td> 6004</td></tr> <tr><td>-26</td><td> 6105</td><td> 7022</td></tr> <tr><td>-31</td><td> 7029</td><td> 8014</td></tr> <tr><td>-36</td><td> 8021</td><td> 9004</td></tr> 
<tr><td>-41</td><td> 9012</td><td>10006</td></tr> 
<tr><td>-46</td><td>10014</td><td>11003</td></tr> 
 </TABLE> These files can be found in the look area.<br> 
The previous bias scan can be found 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=161&frame=2&anchor=22:46:29'> 
here.</a> 
<!-- Author: David and Pete -->


<!-- Date: Sat Aug 2 23:03:05 2003 -->
<h3>Mysterious Mass SVX Trip Fest</h3> 
Paged for numerous trips from STANDBY in SVX.  The list of tripped wedges can be found <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=642&frame=2&anchor=22:14:27.047'> 
here in the shift e-log entry.</a>.  A bunch of layers tripped on Software protection trips on high DVDD currents and then a bunch of layers tripped on DVDD OverCurrent. 
<p> 
There were test bunches in the tevatron at the time of the trip but according to the monitoring ace, the losses were not significant.   
<p> 
I briefly looked in the PS logs and saw nothing too unusual at the time of the trips. 
<p> 
Between 15 and 30 minutes before the trips, there was a <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=642&frame=2&anchor=21:17:52.093'> 
fatal master clock error.</a>   The shift crew was able to recover the clock error and run a cosmics table (not including silicon).   
<p> 
My best guess is that during the clock error, the silicon got in some weird state that led to the trips.  When the Master Clock pulls a fatal error like this, does the silicon need to be coldstarted or something in order to return to its normal happy state?  It is also interesting that only SVX had trips.  
<!-- Author: reid -->
<!-- Comment: Sat Aug  2 23;30;26 comment by...Rainer -->
most likely so. See recent clock initiated SVX trip
<a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=158&frame=2&anchor=04:11:30'>
meltdown </a> I unintentionally produced. However,  you get punished, ie. tripped wedges right awa, in the elog there seems to be 1 one hour time lag so that speaks against it. In any case a cold start right after clock glitches gets silicon back  provided the clock is stable.  

<!-- Comment: Sun Aug  3 15;10;56 comment by...Gino -->
<pre>Unfortunately the PS SPY was down during this period so my attempt to see current behaviors was very sterile.</pre>


<!-- Date: Sun Aug 3 16:34:09 2003 -->
<pre>PS SPY and Temperature SPY were NOT running since 13:05 yesterday. I logged into b0dap43 and did: 
./cratematch.pl 
This restarted the 2 spy programs and now we are back logging data on the log files.</pre>
<!-- Author: Gino -->

<!-- Date: Sun Aug 3 21:42:24 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W0L3 
<li>problem n: 783 
<li>Status: needs_access
<li>Type: Wedgewide_DRO
<li>Action: Diagnosis_update
<li>entered by: reid 
<li>description is: No data on all but the first chip.  It looks like the problems  that previously disapeared have returned.  We should give some attention to this guy in an access. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B5W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sun Aug 3 22:10:08 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2417&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2417  width='300' align='top'></td><td>SVT plot for store 2857</a></td></tr></table>
<!-- Author: reid -->