<!-- Title: 10:56:31  Mon Mar 22 2004 -->
<!-- Crewchief: reid(main pager) -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Finish up the shutdown and get back on our feet.</pre>


<!-- Date: Mon Mar 22 11:04:44 2004 -->
<h3>ISL Cooling Trip</h3> 
Paged for ISL cooling trip.  <p> 
L00 and W-IN, W-Cen, W-Out, E-In, E-Cen, E-out ISL interlocks were all tripped.  I paged Eva.  She said that she'd come in to take care of it.  While i've been typing this entry, the West ISL and L00 interlocks have come back green.  Only the East ISL is still complaining of Flow too low and a bad delta P.
<!-- Author: reid -->
<!-- Comment: Mon Mar 22 12;13;59 comment by...Andy H. -->
ISL flows tripped off on ISL dew point.  Dew point took a momentary excursion that was likely due to people's hands in the west bore.



<!-- Date: Mon Mar 22 17:23:42 2004 -->
<pre>SB0WB 132 b0fib00 NWT 
SB2WA 126 b0fib00 NWT 
IB0W4 124 b0fib03 NWB (directly over SL2 cell)(will be unclamped and moved)  
SB0WA 117 b0fib00 NWT (directly over SL2 cell)(will be unclamped and moved)  
SB1WA 121 b0fib00 NWT (directly over SL2 cell)(will be unclamped and moved)  
IB2W2 113 b0fib03 NWB 
SB1W9 111 b0fib02 SWB 
 
 
IB3W2   b0fib07 NEB 
SB5W10  b0fib04 NET 
SB4W10  b0fib04 NET 
IB5W4   b0fib07 NEB 
SB3W10  b0fib04 NET 
SB4W9   b0fib06 SEB 
LB1W4   b0fib07 NEB 
 
</pre>
<!-- Author: rainer -->


<!-- Date: Mon Mar 22 21:09:35 2004 -->
<pre>Checked resistance through DVDD3/DGND3 and Bias0+/Bias0- paths 
to check for unseated junction cards in regions of COT work. 
All look OK. Numbers below: 
 
Wedge     DVDD3/         Bias0+/ 
          DGND3          Bias0- 
--------------------------------- 
IB0W4     1.7/2.6 MOhm   OL, both connectors (but look OK) 
IB3W2     .46/.91 kOhm   OL, both connectors (but look OK) 
LB1W4     1.7/2.6 MOhm   18.6/14.3 MOhm (after the crowbar) 
                         ~21 MOhm (before the crowbar) 
SB4W9     1.0 kOhm       27/31 kOhm 
SB1W9     1.0 kOhm       37/40 kOhm 
SB0W11    1.0 kOhm       29/22 kOhm 
SB1W10    1.0 kOhm       29/35 kOhm 
SB0W10    1.0 kOhm       40/46 kOhm 
SB2W10    1.0 kOhm       38/42 kOhm 
</pre>
<!-- Author: Reid M., Erik B. -->


<!-- Date: Mon Mar 22 22:00:10 2004 -->
<b> boroscope fun </b> <p> 
<table border=1> <tr> <th>  wedge <th> JC slot <th>  comment </tr> 
<tr><td> SB5W8 <td> S8OUT <td> OK  <td>   </tr> 
<tr><td> SB5W7 <td> S7OUT <td> OK  <td>   </tr> 
<tr><td> SB3W8 <td> S8IN  <td> OK  <td>   </tr> 
<tr><td> IB5W4 <td> OUT4  <td> OK  <td>   </tr> 
<tr><td> SB4W10<td> S10CON<td> OK  <td>   </tr> 
<tr><td> SB3W10<td> S10IN <td> OK  <td>   </tr> 
<tr><td> SB5W10<td> S10OUT<td> separation but RTV is solid    <td> </tr> 
<tr><td> SB0W11<td> S11OUT<td> gap in connector and alignment pins    <td> </tr> 
<tr><td> SB2W10<td> S10IN <td> bias side of JC looked (no gap) LV side of JC had small gap    <td> </tr> 
<tr><td> SB0W10<td> S10OUT<td> tiny gap across connector <td> </tr> 
<tr><td> SB1W10<td> S10CON<td> OK, also done by reid     <td> </tr> 
</table>
<!-- Author: The fabulous boroboys (Marcel, David, Rainer) -->


<!-- Date: Mon Mar 22 22:00:39 2004 -->
<pre>baggies are up and cooling down.</pre>
<!-- Author: rainer -->


<!-- Date: Mon Mar 22 22:07:57 2004 -->
<pre>Silicon cool down beginning.  SVX going to -6C, ISL to 6C.</pre>
<!-- Author: Eva H. -->
<!-- Comment: Tue Mar 23 00;27;50 comment by...Eva H. -->
We are cool.  <br> <br>

Trip thresholds set back to normal, as listed <a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=187&frame=2&anchor=11:04:05'> here.</a> 

<br>
<br>

All alarm are "un-ignored", except for SVX coolant conductivity.  This should settle back to normal value in a few days.


<!-- Date: Tue Mar 23 01:43:07 2004 -->
<h2> let the festivities begin! </h2> <p> 
<li> enabled interlocks 
<li> found SVX SRC in error state, re-initialize loading down clock file 
<li> ran guinea pigs e481,e 0b1, f840 ok 
<li> check VRB glink syncs. some of them show error, some of them are happy. reset the VRB via SVXDAQ for ISL. for SVX it's too many so we reset the VRBs by hand.
<!-- Author: julia, jared, rainer, marcel, antonio -->


<!-- Date: Tue Mar 23 02:17:53 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3615&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3615' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3616&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3616' width='200'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3617&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3617' width='100'></a></center>
<!-- Author: antonio,julia,marcel,jared,rainer -->
<!-- Comment: Tue Mar 23 02;28;54 comment by...night shift -->
status immediately after switch on of silicon
<!-- Date: Tue Mar 23 02:28:00 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3618&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3618' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3619&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3619' width='200'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3620&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3620' width='100'></a></center>
<!-- Author: the night shift -->
<!-- Comment: Tue Mar 23 02;29;14 comment by...night shift -->
after idle and coldstart 


<!-- Date: Tue Mar 23 02:58:21 2004 -->
<center><a href='/elog/notebooks/silicon/Tue_Mar_23_2004_025752.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3622' ></a><a href='/elog/notebooks/silicon/Tue_Mar_23_2004_025804.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3624' ></a></center>
<!-- Author: rainer -->
<!-- Comment: Tue Mar 23 02;59;01 comment by...night shift -->
<pre>running DPS ON dmod calibration</pre>

<!-- Date: Tue Mar 23 03:57:19 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W5L2 
<li>problem n: 1225 
<li>Status: needs_work
<li>Type: Unknown
<li>Action: Incident
<li>entered by: thom 
<li>description is: <pre>post-shutdown: trips on high DVDD and yellow in svxmon</pre> 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Mar 23 03:59:21 2004 -->
<center><a href='/elog/notebooks/silicon/Tue_Mar_23_2004_035827.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3626' ></a><a href='/elog/notebooks/silicon/Tue_Mar_23_2004_035849.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3628' ></a></center>
<!-- Author: rainer -->
<!-- Comment: Tue Mar 23 04;00;23 comment by...rainer -->
<pre>running DPS OFF during dmod calibration - SB0W5L2 tripping frequently.</pre>


<!-- Date: Tue Mar 23 04:00:34 2004 -->
<pre>had persistent DVDD oc trip of B0W5L2. Also yellow in svxmon in DPS off.</pre>
<!-- Author: thom -->


<!-- Date: Tue Mar 23 04:33:08 2004 -->
<pre><b> pete run result </b> 
<p>using the runcontrol preset configuration 'newpete' <p> 
bias ON= 180563<br> 
bias OFF=180567<br> 
<p> 
pete does not find anything wrong ....</pre>
<!-- Author: rainer -->


<!-- Date: Tue Mar 23 04:37:38 2004 -->
<h3> Table of misbehaving wedges</h3> 
Here is a short table about the wedges, that showed up either on SVXMON or the Power supply gui together with some information from the Problem data base 
<TABLE FRAME=BOX CELLSPACING=0 COLS=3 RULES=GROUPS BORDER=1> 
	<COLGROUP><COL WIDTH=80></colgroup> 
	<COLGROUP><COL WIDTH=180></colgroup> 
	<COLGROUP><COL WIDTH=96></colgroup> 
	<TBODY> 
		<TR> 
			<TD WIDTH=80 HEIGHT=16 ALIGN=LEFT><B>Wedge</b></td> 
			<TD WIDTH=180 ALIGN=LEFT><B>Power Supply Gui</b></td> 
			<TD WIDTH=96 ALIGN=LEFT><B>History</b></td> 
		</tr> 
	</tbody> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=30 ALIGN=LEFT>SB0W0L4</td> 
			<TD ALIGN=LEFT>yellow, current at upper limity</td> 
			<TD ALIGN=LEFT>unfixable low bit 6</td> 
		</tr> 
	</tbody> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=44 ALIGN=LEFT>SB0W8L4</td> 
			<TD ALIGN=LEFT>DVDD:0 (pink) AVDD slightly low Bias, weird curve</td> 
			<TD ALIGN=LEFT>chips Sparsed, fixed</td> 
		</tr> 
	</tbody> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=16 ALIGN=LEFT>SB0W11L4</td> 
			<TD ALIGN=LEFT>green</td> 
			<TD ALIGN=LEFT>Low bit 5</td> 
		</tr> 
	</tbody> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=30 ALIGN=LEFT>SB0W3L3</td> 
			<TD ALIGN=LEFT>green</td> 
			<TD ALIGN=LEFT>unfixable problem</td> 
		</tr> 
	</tbody> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=30 ALIGN=LEFT>SB0W8L0</td> 
			<TD ALIGN=LEFT>green</td> 
			<TD ALIGN=LEFT>stuck bits, fixed</td> 
		</tr> 
	</tbody> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=30 ALIGN=LEFT>SB1W4L3</td> 
			<TD ALIGN=LEFT>AVDD low voltage 550, pink</td> 
			<TD ALIGN=LEFT>stuck cell id</td> 
		</tr> 
	</tbody> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=16 ALIGN=LEFT>SB4W6L3</td> 
			<TD ALIGN=LEFT>green</td> 
			<TD ALIGN=LEFT>stuck bit</td> 
		</tr> 
	</tbody> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=30 ALIGN=LEFT>SB1W2L2</td> 
			<TD ALIGN=LEFT>Pink AVDD</td> 
			<TD ALIGN=LEFT>AVDD problems</td> 
		</tr> 
	</tbody> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=44 ALIGN=LEFT>SB1W8L2</td> 
			<TD ALIGN=LEFT>green</td> 
			<TD ALIGN=LEFT>unfixable AVDD problem</td> 
		</tr> 
	</tbody> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=30 ALIGN=LEFT>SB3W7L2</td> 
			<TD ALIGN=LEFT>Pink AVDD, Current half (790->385 )</td> 
			<TD ALIGN=LEFT>AVDD problems ?</td> 
		</tr> 
	</tbody> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=30 ALIGN=LEFT>SB3W8L2</td> 
			<TD ALIGN=LEFT>green</td> 
			<TD ALIGN=LEFT>fixed low bit problems</td> 
		</tr> 
	</tbody> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=16 ALIGN=LEFT>SB4W10L2</td> 
			<TD ALIGN=LEFT>pink bias</td> 
			<TD ALIGN=LEFT>fixed</td> 
		</tr> 
	</tbody> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=30 ALIGN=LEFT>SB2W5L0</td> 
			<TD ALIGN=LEFT>green</td> 
			<TD ALIGN=LEFT>unfixable bad doim</td> 
		</tr> 
	</tbody> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=16 ALIGN=LEFT>SB0W5L4</td> 
			<TD ALIGN=LEFT>pink bias</td> 
			<TD ALIGN=LEFT>all fixed</td> 
		</tr> 
	</tbody> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=30 ALIGN=LEFT>SB0W3L2</td> 
			<TD ALIGN=LEFT>pink bias</td> 
			<TD ALIGN=LEFT>AVDD, 2 chips bad</td> 
		</tr> 
	</tbody> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=30 ALIGN=LEFT>SB0W8L2</td> 
			<TD ALIGN=LEFT>pink bias</td> 
			<TD ALIGN=LEFT>fixed problems</td> 
		</tr> 
	</tbody> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=30 ALIGN=LEFT>IB0W4L0</td> 
			<TD ALIGN=LEFT>green</td> 
			<TD ALIGN=LEFT>Readout problems</td> 
		</tr> 
	</tbody> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=30 ALIGN=LEFT>IB0W0L4</td> 
			<TD ALIGN=LEFT>pink AVDD 1190->810 </td> 
			<TD ALIGN=LEFT>Dropped Readout</td> 
		</tr> 
	</tbody> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=16 ALIGN=LEFT>IB0W3L4</td> 
			<TD ALIGN=LEFT>Yellow in Bias</td> 
			<TD ALIGN=LEFT>all fixed</td> 
		</tr> 
	</tbody> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=30 ALIGN=LEFT>IB1W4L1</td> 
			<TD ALIGN=LEFT>green</td> 
			<TD ALIGN=LEFT>dropped readouts</td> 
		</tr> 
	</tbody> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=16 ALIGN=LEFT>IB3W1L4</td> 
			<TD ALIGN=LEFT>green </td> 
			<TD ALIGN=LEFT>bit 6 dead </td> 
		</tr> 
	</tbody> 
	 
</table>
<!-- Author: The night shift -->
<!-- Comment: Tue Mar 23 04;44;34 comment by...the night shift -->
<pre>of all these entries, only SB0W5L4,SB0W3L2 and SB0W8L2 showed up only in the PS guuuui</pre>

<!-- Date: Tue Mar 23 05:30:21 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W10L2 
<li>problem n: 1226 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Init_RB_mask
<li>entered by: boveia 
<li>description is: flaky readback after COT wireplane work. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B4W10&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Mar 23 05:35:37 2004 -->
<pre>Several Trips of SB0W2L2 </pre>
<!-- Author: The night hawks -->


<!-- Date: Tue Mar 23 06:22:29 2004 -->
can't get ISL DAQ to  run - VRBs get frequently un-synched 
and I get error messages I cannot decipher - see <pre> 
 10675 E 74 Error:Data Overrun      index 4112 Fib 0 Pipe 1 Chip  15 
R 10675 E 74 Error: No EOR           Fib 0 Pipe 1 
R 10675 E 74 Error: OO Sequence      Fib 0 Pipe 2 Chip 15: ..6a,6b 00, 00.. 
R 10675 E 74 Error: OO Sequence      Fib 0 Pipe 2 Chip 15: ..6b,00 00, f1.. 
R 10675 E 74 Error:Data Overrun      index 6160 Fib 0 Pipe 2 Chip  15 
R 10675 E 74 Error: No EOR           Fib 0 Pipe 2 
R 10675 E 74 Error: OO Sequence      Fib 0 Pipe 3 Chip 15: ..6a,6b 00, 00.. 
R 10675 E 74 Error: OO Sequence      Fib 0 Pipe 3 Chip 15: ..6b,00 00, f1.. 
R 10675 E 74 Error:Data Overrun      index 8208 Fib 0 Pipe 3 Chip  15 
R 10675 E 74 Error: No EOR           Fib 0 Pipe 3 
R 10675 E 74 Error: OO Sequence      Fib 0 Pipe 4 Chip 15: ..6a,6b 00, 00.. 
R 10675 E 74 Error: OO Sequence      Fib 0 Pipe 4 Chip 15: ..6b,00 00, 42.. 
R 10675 E 74 Error:Data Overrun      index 10256 Fib 0 Pipe 4 Chip  15 
R 10675 E 74 Error: No EOR           Fib 0 Pipe 4 
R 10675 E 75 --------- Error Print 
 
R 10675 E 75 Pipes != Sum        0 
R 10675 E 75 Too Many Fibs       0 
R 10675 E 75 PcA Byte Format     0 
R 10675 E 75 ChipState Format    0 
R 10675 E 75 PcA Byte            0 
R 10675 E 75 pcB Byte            0 
R 10675 E 75 Bxing Byte          0 
R 10675 E 75 ChipState           0 
R 10675 E 75 Not Chip ID         0 
R 10675 E 75 Wrong Chip ID       0 
R 10675 E 75 Truncate            0 
R 10675 E 75 OO Sequence         750 
R 10675 E 75 Illegal Chan        0 
R 10675 E 75 Data Overrun        375 
R 10675 E 75 Too Many Chips      0 
R 10675 E 75 No EOR              375 
R 10675 E 75 CAP ID              0 
 
R 10675 E 75 ------- Buffer Dump 
R 10675 E 75     F 0 P 0B 0 Err 0B 1 Err 0B 2 Err 75B 3 Err 75 
R 10675 E 75     F 0 P 1B 0 Err 0B 1 Err 0B 2 Err 75B 3 Err 75 
R 10675 E 75     F 0 P 2B 0 Err 0B 1 Err 0B 2 Err 75B 3 Err 75 
R 10675 E 75     F 0 P 3B 0 Err 0B 1 Err 0B 2 Err 75B 3 Err 75 
R 10675 E 75     F 0 P 4B 0 Err 0B 1 Err 0B 2 Err 75B 3 Err 75 
</pre> 
what is data overrun ? the wedges seem to be fine before the hiatus.  
<!-- Author: rainer -->
<!-- Comment: Tue Mar 23 17;33;17 comment by...rainer -->
<pre>this was due to the IGNORE VRB bit being set - a cazzo type behaviour also on the new firmware</pre>
<!-- Date: Tue Mar 23 07:08:47 2004 -->
Bias Current Check: <br> 
<br> 
The following ladders have zero current, but had current greater than 10uA on Ben's List.<br> 
<br> 
ladder(old current)<br> 
IB1W4L0(23.7)Bias0<br>  
IB5W1L1(7.9)Bias0 now off<br> 
IB5W1L1(27.1)Bias1 now off<br> 
IB5W3L4(11.5)Bias0<br> 
IB5W5L2(25.5)Bias0<br> 
 
 
 
  
<!-- Author: Jared -->


<!-- Date: Tue Mar 23 08:20:35 2004 -->
<center><a href='/elog/notebooks/silicon/Tue_Mar_23_2004_082015.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3630' ></a><a href='/elog/notebooks/silicon/Tue_Mar_23_2004_082024.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3632' ></a></center>
<!-- Author: rainer -->
<!-- Comment: Tue Mar 23 08;20;53 comment by...rainer -->
<pre>during cosmics data taking.</pre>


<!-- Date: Tue Mar 23 12:34:09 2004 -->
<center><a href='/elog/notebooks/silicon/Tue_Mar_23_2004_123050.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3634' ></a><a href='/elog/notebooks/silicon/Tue_Mar_23_2004_123129.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3636' ></a><a href='/elog/notebooks/silicon/Tue_Mar_23_2004_123142.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3638' ></a><a href='/elog/notebooks/silicon/Tue_Mar_23_2004_123153.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3640' ></a></center>
<!-- Author: florencia, ben -->
<!-- Comment: Tue Mar 23 12;37;36 comment by...Florencia, Ben -->
ISL dnoise biased (black) and dnoise unbiased (red) from left to right: 
IB0W5L4, IB5W3L4, IB5W5L2, IB5W5L4. These ladders have 0 current but before the shutdown had more than 8 muA.


<!-- Date: Tue Mar 23 14:36:27 2004 -->
<pre>Testfest almost finished, reset trips in B0W5, B0W4L0, L00 West W0 L3, eb4W10L0, eb4w10L4 and ran a coldstart, everything biased  
and no trips so far. </pre>
<!-- Author: julia,reid, ben, Florencia -->


<!-- Date: Tue Mar 23 15:03:13 2004 -->
<h3>e044</h3> 
New BeClock for OBDV kludge installed during this shutdown. 
<br> 
<ul> 
<li>Updated the firmware in FIB02 slot 8 with <b>pipe29o_ch4.jam</b> 
<li>Added "Last Chip Override" flag in Chip Editor for e044. 
</ul> 
Still have not completely tested the change to make sure that everything works as expected.  David said that the problem that we are trying to fix for this guy only shows up in Neighbor mode
<!-- Author: reid -->
<!-- Comment: Tue Mar 23 15;05;08 comment by...reid -->
Current versions of firmware can be found 
<a href="http://www-cdf.fnal.gov/internal/silicon/silicon_commission/daq/firmware.html">here</a>


<!-- Date: Tue Mar 23 15:13:03 2004 -->
<h3>Test Fest Complete</h3> 
All of our findings are listed on the Test Fest worksheets.  One new error, <b>e4a2</b>.  This ladder started by showing a flaky readback and now gives no data.  I believe that there is also a possible first chip AVDD2 failure candidate but am not sure who.  This would bring the cost of the shutdown to two ladders.
<!-- Author: reid -->


<!-- Date: Tue Mar 23 15:22:37 2004 -->
<h3>SB1W5L4</h3> 
This is a ladder that David was working on.  It has two leads at the FTM that can be used to tune the delay line for the BECLK. The upper lead is to pipe 9 and the lower line is to BECLK.  <br><br> 
<b>BEFORE Data taking, we need to take these leads off</b><br><br> 
At the next opportunity, we need to use an oscilliscope to tune the BECLK delay in the detector.  It would be nice to have the assistance of Gino for this tuning job since David is out of town until Saturday and none of the rest of us have done this before.
<!-- Author: reid -->

<!-- Date: Tue Mar 23 16:07:53 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W2L4 
<li>problem n: 1177 
<li>Status: needs_work
<li>Type: Unknown
<li>Action: Diagnosis_update
<li>entered by: reid 
<li>description is: no header seen, junk data in post shutdown checkout 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W2&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Mar 23 16:22:50 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W4L3 
<li>problem n: 1227 
<li>Status: needs_observation
<li>Type: RX
<li>Action: Diagnosis
<li>entered by: reid 
<li>description is: Wrong Cap ID chip 85.  Spotted in post-shutdown checkout. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W4&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Mar 23 16:26:04 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W10L2 
<li>problem n: 1226 
<li>Status: needs_work
<li>Type: Unknown
<li>Action: Diagnosis_update
<li>entered by: reid 
<li>description is: No chip ID and no data in post-shutdown checkout. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B4W10&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Mar 23 16:36:25 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W8L2 
<li>problem n: 1191 
<li>Status: needs_observation
<li>Type: RX
<li>Action: Diagnosis_update
<li>entered by: reid 
<li>description is: Bit 7 low shows up again in post-shutdown checkout. Its back. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B3W8&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Mar 23 17:13:16 2004 -->
We had a closer look on some of the pinkies : 
<pre> 
SB0W1L2 AVDD  790  high (should be 580)    Already has AVDD problems 
SB1W0L0 AVDD 160-300    (should be 300)    oscillating, has AVDDD history 
SB3W7L2 AVDD  385  low  (should be 790)    Showed this before 
IB0W0L4 AVDD  880  low  (should be 1110)   new      
</pre>  
<!-- Author: Reid, Marcel, Rainer  -->


<!-- Date: Tue Mar 23 17:19:17 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3641&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3642  width='300' align='top'></a></td><td>intermittent current swings on SB1W0L0</td></tr></table>
<!-- Author: rainer, marcel -->


<!-- Date: Tue Mar 23 17:23:50 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3643&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3643' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3644&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3644' width='150'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3645&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3645' width='100'></a></center>
<!-- Author: Rainer, Marcel -->



<!-- Date: Tue Mar 23 18:02:08 2004 -->
    <h1>preliminary shitlist </h1> 
<li> <a href='http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W1&layer=L2'> e012 </a>  200mA AVDD drop 
 
<li> <a href='http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W5&layer=L2'> e052 </a> persistent SPT on DVDD in dmod DPS OFF  
<li> <a href='http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L4'> e084 </a> had c2c2 before, cable swap helped 
<li> <a href='http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W0&layer=L0'> e100 </a> oscillating AVDD 
 
<li> <a href='http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W4&layer=L3'> e143 </a> new cap id problem on chip 085 
<li> <a href='http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B4W10&layer=L2'> e4a2 </a> <b>no chip ID, no data </b> 
<li> <a href='http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B3W7&layer=L2'> e372 </a> <b>b7l only 1 chip -AVDD2 ? </b> 
 
<li> <a href='http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B3W8&layer=L2'> e382 </a> <b>b7l which stays with ladder </b>  
<!-- Author: marcel,rainer -->
<!-- Comment: Fri Mar 26 16;29;58 comment by...rainer -->
<pre><li>  <a href='http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L0'> e080 </a> 00f3 problem seen in cosmics data.</pre>
<!-- Date: Tue Mar 23 18:26:13 2004 -->
This is what we see from Ladder e4a2 using SVX DAQ 
<pre> 
e4a206fc 00f300f3 00f300f3 00c2c2 
</pre>  
<!-- Author: Rainer, Marcel -->

<!-- Date: Tue Mar 23 18:31:59 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W10L2 
<li>problem n: 1226 
<li>Status: needs_work
<li>Type: DRO_00F3
<li>Action: Diagnosis_update
<li>entered by: rainer 
<li>description is: <li> during cosmics  <pre> e4a2 21fc 00f3 00f3 00f3 00f3 00c2 c2c4  </pre> <li> capid trouble on chip 89 in calbration run: <pre> e4a2 35fc 8910 000a 0103 020a 0302 3901 3a08 3b00 <br>            8812 1100 120a 1307 1403 150a 1604 1706 <br>                 1809 1908 <br>            8712 1904 1a09 1b00 2a01 2b07 ... <br> </pre> 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B4W10&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Mar 23 18:47:56 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W8L2 
<li>problem n: 1191 
<li>Status: needs_study_time
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: rainer 
<li>description is: b7l appears to stay with HDI.  
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B3W8&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Mar 23 19:09:28 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L4 
<li>problem n: 1228 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Incident
<li>entered by: rainer 
<li>description is: had DRO c2c2 without chip id or anything until magic reid'o swapped the power line and back. have an eye on it. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Mar 23 19:10:03 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3646&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3646  width='300' align='top'></a></td><td>e100 as seen in the SVXDAQ </td></tr></table>
<!-- Author: Rainer, Marcel -->

<!-- Date: Tue Mar 23 19:14:12 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W4L3 
<li>problem n: 1227 
<li>Status: needs_observation
<li>Type: DropReadOut_nonRX
<li>Action: Diagnosis
<li>entered by: rainer 
<li>description is: <pre>e143 21fc 890c 00f3 880c 870c 860c 851e 5fd0 d0c2 c2c4 0000 </pre> in post COT wire plane shutdown. keep and eye on it. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W4&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Mar 23 19:57:09 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3648&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3648  width='300' align='top'></a></td><td>we warmed up during the cot cooling excercise  02/19 - 02/26- no appreciable damage (at least not reported). we stayed warm during this access 03/15 - 03/23 - several ladders appear to be damaged. what is the difference between these two thermocycles which affects SVX ?</td></tr></table>
<!-- Author: rainer -->


<!-- Date: Tue Mar 23 22:18:50 2004 -->
<h3> Interlock madness</h3> 
We did some  tests on the L00 noise while suddenly (21:56:42) we got a weird message from the power supply gui 
All interlocks went to not enabled and the silicon went to standby. Funny thing, we didn't do anything at that time... 
The aces also say, the didn't press any button. 
At 21:57:15 the interlocks came back and we were able to power up the silicon again.  
No problem seen since then.  
<!-- Author: Gino and Marcel -->
<!-- Comment: Wed Mar 24 07;34;33 comment by...SCN -->
Usually this is a sign of the PS GUI losing connection with IFIX,
because of a smartsockets problem, which recovered itself.
<!-- Date: Tue Mar 23 23:09:10 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3649&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3649  width='300' align='top'></a></td><td>We took data in regular mode and limiting the triggers only BEFORE or AFTER the preamp reset comand in LB1W4L0. The 3 colors on the plots are the 3 different curves. The differences in the noise level are not due to the changes in the timing but just to time passing between a measurment and the next one. Basically this work rule out any connection between the noise in L00 and the relative time between PARST and the trigger. Too bad we have to come up with something else (I do not have much in mind).</td></tr></table>
<!-- Author: Marcel and Gino -->
<!-- Comment: Wed Mar 24 07;52;05 comment by...SCN -->
I guess what is plotted is Noise (or Dnoise) vs Channel?  When
you say "time passing between a measurement", do you mean <ol>
<li> Time between consecutive L1A within a run
<li> Time between consecutive runs, i.e. the  ladder settles down
after the BIAS has been on for a while
</ol>
I guess you mean #2, but if you do mean #1, then going to 2 SRC mode should have had a visible effect on noise levels in L00, I think.


<!-- Date: Wed Mar 24 10:45:40 2004 -->
<h3>Quick test for smartsockets on Fib Crates</h3> 
Reid called, said Fib crates weren't responding, so I did a quick test to see if they listen to smartsockets message by using the "Handshake Test" program to pretend I need a handshake to turn on ladder e060<pre> 
b0dap30.fnal.gov% setup fer 
setup-ppc: assuming PowerPC 603 processor 
CDFVME_COMMON: Last updated by feild on Thu Feb 19 17:35:24 CST 2004 
b0dap30.fnal.gov% java si_ss.HvHdskT e060 
 
 
Please remember this was just a tool to test a handshake 
and was not really meant to be used to initialize the chips 
so I don't want to hear about 'friendliness' or lack thereof 
 
Sending Wedges: e060  
Attempting connection to <tcp:b0dap33:5101> RTserver. 
Connected to <tcp:b0dap33:5101> RTserver. 
Got 1 Ready from /_b0fib02_14148368 
Got 1 Done from /_b0fib02_14148368 
 
 
         ******* Current Status **************  
 ID     #       READY                                   DONE 
e060    2       /_b0fib02_14148368              /_b0fib02_14148368 
                --------------------------- 
Server                  Count 
/_b0fib02_14148368      0 
        ************************************ 
Finished! and  done 
 
 
 
         ******* Current Status **************  
 ID     #       READY                                   DONE 
e060    2       /_b0fib02_14148368              /_b0fib02_14148368 
                --------------------------- 
Server                  Count 
/_b0fib02_14148368      0 
        ************************************ 
b0dap30.fnal.gov%</pre> 
The above shows that indeed b0fib02 responded to the handshake, 
which means <ol> 
<li> It is listening to smartsockets 
<li> It does have its map of ladder to Fib downloaded 
</ol> 
So Reid tried again, and it all works now.  We chalk his problems up to either a smartsockets problem or <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=174&frame=2&anchor=09:54:02.316'>recent network interruptions</a>
<!-- Author: SCN -->
<!-- Comment: Wed Mar 24 10;51;59 comment by...a happy SPL -->
<pre><b> A new GIMMICK! :) </b></pre>

<!-- Date: Wed Mar 24 12:44:11 2004 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 317
Calibration type  : standard
Run period tag    : Mar_2004
DPS-off run       : 179874
DPS-on run        : 179873
Requested by      : Jason Nielsen
Main process id   : 25920241
Comment           : test submission on b0sili01
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->


<!-- Date: Wed Mar 24 12:44:35 2004 -->
<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 317 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 179874
DPS-on run       : 179873
Requested by     : Jason Nielsen
Submitted        : 2004-03-24 12:43:59
Completed        : 2004-03-24 12:44:19
Status           : FAILURE
Comment          : test submission on b0sili01

Last processing stage reported : start of the run_calib_analysis.tcl script
Failure diagnostics :
Host key not found from the list of known hosts.
You have no controlling tty.  Cannot read confirmation.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Wed Mar 24 13:19:28 2004 -->
<h3> Ladders showing up on bit reporter</h3> 
<TABLE FRAME=BOX CELLSPACING=0 COLS=3 RULES=GROUPS BORDER=1> 
	<COLGROUP><COL WIDTH=104></COLGROUP> 
	<COLGROUP><COL WIDTH=103></COLGROUP> 
	<COLGROUP><COL WIDTH=90></COLGROUP> 
	<TBODY> 
		<TR> 
			<TD WIDTH=104 HEIGHT=21 ALIGN=LEFT><B><FONT SIZE=3>Bad ladder</FONT></B></TD> 
			<TD WIDTH=103 ALIGN=CENTER><B><FONT SIZE=3>Went away</FONT></B></TD> 
			<TD WIDTH=90 ALIGN=LEFT><B><FONT SIZE=3>History</FONT></B></TD> 
		</TR> 
	</TBODY> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=18 ALIGN=LEFT><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/errmon/makeladder.pl?beginrun=179287&endrun=180709&ladder=I004">IB0W0L4</A><A HREF="http://nucsb03.fnal.gov/cgi-bin/errorMon?HDI=f004&RUN=all"></A></TD> 
			<TD ALIGN=CENTER>no</TD> 
			<TD ALIGN=LEFT><FONT FACE="Times New Roman"><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B0W0&layer=L4">Problem DB</A></FONT></TD> 
		</TR> 
	</TBODY> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=18 ALIGN=LEFT><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/errmon/makeladder.pl?beginrun=179287&endrun=180709&ladder=I103">IB1W0L3</A><A HREF="http://nucsb03.fnal.gov/cgi-bin/errorMon?HDI=f103&RUN=all"></A></TD> 
			<TD ALIGN=CENTER>no</TD> 
			<TD ALIGN=LEFT><FONT FACE="Times New Roman"><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B1W0&layer=L3">Problem DB</A></FONT></TD> 
		</TR> 
	</TBODY> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=18 ALIGN=LEFT><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/errmon/makeladder.pl?beginrun=179287&endrun=180709&ladder=I141">IB1W4L1</A></TD> 
			<TD ALIGN=CENTER>yes</TD> 
			<TD ALIGN=LEFT><FONT FACE="Times New Roman"><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B1W0&layer=L3">Problem DB</A></FONT></TD> 
		</TR> 
	</TBODY> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=18 ALIGN=LEFT><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/errmon/makeladder.pl?beginrun=179287&endrun=180709&ladder=I432">IB4W3L2</A><A HREF="http://nucsb03.fnal.gov/cgi-bin/errorMon?HDI=f432&RUN=all"></A></TD> 
			<TD ALIGN=CENTER>no</TD> 
			<TD ALIGN=LEFT><FONT FACE="Times New Roman"><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B4W3&layer=L2">Problem DB</A></FONT></TD> 
		</TR> 
	</TBODY> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=18 ALIGN=LEFT><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/errmon/makeladder.pl?beginrun=179287&endrun=180709&ladder=L130">LB1W3L0</A></TD> 
			<TD ALIGN=CENTER>no</TD> 
			<TD ALIGN=LEFT><FONT FACE="Times New Roman"><A HREF="http://nucsb03.fnal.gov/cgi-bin/errorMon?HDI=f432&RUN=all"></A><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B4W3&layer=L2">Problem DB</A></FONT></TD> 
		</TR> 
	</TBODY> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=18 ALIGN=LEFT><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/errmon/makeladder.pl?beginrun=179287&endrun=180709&ladder=S033">SB0W3L3</A><A HREF="http://nucsb03.fnal.gov/cgi-bin/errorMon?HDI=e033&RUN=all"></A></TD> 
			<TD ALIGN=CENTER>no</TD> 
			<TD ALIGN=LEFT><FONT FACE="Times New Roman"><A HREF="http://nucsb03.fnal.gov/cgi-bin/errorMon?HDI=f432&RUN=all"></A><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B4W3&layer=L2">Problem DB</A></FONT></TD> 
		</TR> 
	</TBODY> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=17 ALIGN=LEFT><FONT FACE="Times New Roman"><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/errmon/makeladder.pl?beginrun=179287&endrun=180709&ladder=S043">SB0W4L3</A><A HREF="http://nucsb03.fnal.gov/cgi-bin/errorMon?HDI=e043&RUN=all"></A></FONT></TD> 
			<TD ALIGN=CENTER>lowering</TD> 
			<TD ALIGN=LEFT><FONT FACE="Times New Roman"><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W4&layer=L3">Problem DB</A></FONT></TD> 
		</TR> 
	</TBODY> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=18 ALIGN=LEFT><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/errmon/makeladder.pl?beginrun=179287&endrun=180709&ladder=S044">SB0W4L4</A><A HREF="http://nucsb03.fnal.gov/cgi-bin/errorMon?HDI=e044&RUN=all"></A></TD> 
			<TD ALIGN=CENTER>lowering</TD> 
			<TD ALIGN=LEFT><FONT FACE="Times New Roman"><A HREF="http://nucsb03.fnal.gov/cgi-bin/errorMon?HDI=e034&RUN=all"></A><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W3&layer=L4">Problem DB</A></FONT></TD> 
		</TR> 
	</TBODY> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=18 ALIGN=LEFT><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/errmon/makeladder.pl?beginrun=179287&endrun=180709&ladder=S080">SB0W8L0</A><A HREF="http://nucsb03.fnal.gov/cgi-bin/errorMon?HDI=e080&RUN=all"></A></TD> 
			<TD ALIGN=CENTER>no</TD> 
			<TD ALIGN=LEFT><FONT FACE="Times New Roman"><A HREF="http://nucsb03.fnal.gov/cgi-bin/errorMon?HDI=e080&RUN=all"></A><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L0">Problem DB</A></FONT></TD> 
		</TR> 
	</TBODY> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=18 ALIGN=LEFT><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/errmon/makeladder.pl?beginrun=179287&endrun=180709&ladder=S100">SB1W0L0</A><A HREF="http://nucsb03.fnal.gov/cgi-bin/errorMon?HDI=e100&RUN=all"></A></TD> 
			<TD ALIGN=CENTER>no</TD> 
			<TD ALIGN=LEFT><FONT FACE="Times New Roman"><A HREF="http://nucsb03.fnal.gov/cgi-bin/errorMon?HDI=e080&RUN=all"></A><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L0">Problem DB</A></FONT></TD> 
		</TR> 
	</TBODY> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=18 ALIGN=LEFT><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/errmon/makeladder.pl?beginrun=179287&endrun=180709&ladder=S122">SB1W2L2</A></TD> 
			<TD ALIGN=CENTER>yes</TD> 
			<TD ALIGN=LEFT><FONT FACE="Times New Roman"><A HREF="http://nucsb03.fnal.gov/cgi-bin/errorMon?HDI=e122&RUN=all"></A><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W2&layer=L2">Problem DB</A></FONT></TD> 
		</TR> 
	</TBODY> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=18 ALIGN=LEFT><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/errmon/makeladder.pl?beginrun=179287&endrun=180709&ladder=S143">SB1W4L3</A><A HREF="http://nucsb03.fnal.gov/cgi-bin/errorMon?HDI=e143&RUN=all"></A></TD> 
			<TD ALIGN=CENTER>yes</TD> 
			<TD ALIGN=LEFT><FONT FACE="Times New Roman"><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W4&layer=L3">Problem DB</A></FONT></TD> 
		</TR> 
	</TBODY> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=17 ALIGN=LEFT><FONT FACE="Times New Roman"><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/errmon/makeladder.pl?beginrun=179287&endrun=180709&ladder=S152">SB1W5L2</A></FONT></TD> 
			<TD ALIGN=CENTER>yes</TD> 
			<TD ALIGN=LEFT><FONT FACE="Times New Roman"><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W5&layer=L2">Problem DB</A></FONT></TD> 
		</TR> 
	</TBODY> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=18 ALIGN=LEFT><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/errmon/makeladder.pl?beginrun=179287&endrun=180709&ladder=S372">SB3W7L2</A></TD> 
			<TD ALIGN=CENTER>no</TD> 
			<TD ALIGN=LEFT><FONT FACE="Times New Roman"><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W5&layer=L2">Problem DB</A></FONT></TD> 
		</TR> 
	</TBODY> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=18 ALIGN=LEFT><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/errmon/makeladder.pl?beginrun=179287&endrun=180709&ladder=S382">SB3W8L2</A><A HREF="http://nucsb03.fnal.gov/cgi-bin/errorMon?HDI=e382&RUN=all"></A></TD> 
			<TD ALIGN=CENTER>no</TD> 
			<TD ALIGN=LEFT><FONT FACE="Times New Roman"><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W5&layer=L2">Problem DB</A></FONT></TD> 
		</TR> 
	</TBODY> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=18 ALIGN=LEFT><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/errmon/makeladder.pl?beginrun=179287&endrun=180709&ladder=S433">SB4W3L3</A></TD> 
			<TD ALIGN=CENTER>no</TD> 
			<TD ALIGN=LEFT><FONT FACE="Times New Roman"><A HREF="http://nucsb03.fnal.gov/cgi-bin/errorMon?HDI=e433&RUN=all"></A><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B4W3&layer=L3">Problem DB</A></FONT></TD> 
		</TR> 
	</TBODY> 
	<TBODY> 
		<TR> 
			<TD HEIGHT=18 ALIGN=LEFT><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/errmon/makeladder.pl?beginrun=179287&endrun=180709&ladder=S4A2">SB4WAL2</A></TD> 
			<TD ALIGN=CENTER>no</TD> 
			<TD ALIGN=LEFT><FONT FACE="Times New Roman"><A HREF="http://nucsb03.fnal.gov/cgi-bin/errorMon?HDI=e433&RUN=all"></A><A HREF="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B4W3&layer=L3">Problem DB</A></FONT></TD> 
		</TR> 
	</TBODY> 
</TABLE>
<!-- Author: Rainer,Marcel -->

<!-- Date: Wed Mar 24 14:13:03 2004 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 318
Calibration type  : standard
Run period tag    : Mar_2004
DPS-off run       : 179874
DPS-on run        : 179873
Requested by      : Jason Nielsen
Main process id   : 26135598
Comment           : test submission from b0sili01
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->


<!-- Date: Wed Mar 24 14:13:13 2004 -->
<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 318 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 179874
DPS-on run       : 179873
Requested by     : Jason Nielsen
Submitted        : 2004-03-24 14:12:46
Completed        : 2004-03-24 14:13:06
Status           : FAILURE
Comment          : test submission from b0sili01

Last processing stage reported : start of the run_calib_analysis.tcl script
Failure diagnostics :
Host key not found from the list of known hosts.
You have no controlling tty.  Cannot read confirmation.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Wed Mar 24 14:48:27 2004 -->
<pre><h3>e154 BECLK tuning</h3> 
Pre-tuning look at e154: 
<pre> 
e15418fc 8d000031 00300036 00370536 04380435 06380939 
0x00001ea0:  08370836 09380c39 0d380c39 0c381139 103f1036 10381539 15371439 1637193e 
0x00001ec0:  18381a3a 19381c39 1c381c3a 1d38203e 213f223a 23382439 253b263a 26382939 
0x00001ee0:  283f283d 29382c39 2d3b2e3a 2d3f303e 303f323a 31383439 353b363a 353f3839 
0x00001f00:  393c383e 3b383c39 3c383c39 3f38003e 003c003e 01380439 053b063a 04380846 
0x00001f20:  48400836 0b380c39 0d370e3a 0e3f113e 113f123d 11381439 153b163a 14381846 
0x00001f40:  193b183e 18381c39 1d381e3a 1e38213e 213c223a 20382439 253b263a 243f2839 
0x00001f60:  293b2a3d 2a382d39 2d3b2e3a 2e383139 313c703e 32477546 34447645 36383946 
0x00001f80:  78403a42 3a383d39 3c383c39 7e380406 8d010001 00f3003e 00070439 05380446 
</pre> 
 
Looks like some bit 1 and 0 errors for higher number channels (above 10).  </pre>
<!-- Author: reid, marcel, and rainer -->
<!-- Comment: Wed Mar 24 17;57;16 comment by...reid and marcel -->
After we tweaked the timing on the BECLK delay line, we get the following.
<pre>
e1548bfc 8d1e045e
0x00000e80:  05500275 077a047d 077f066e 076c0c78 0b6a0a68 0b6a0c6f 0d6e0e6f 0f6f146e
0x00000ea0:  1569126f 1769146e 156f166c 176d1878 1b6b1a68 1b6a1c6e 1d6f1e6e 1f6e2478
0x00000ec0:  216b2268 236a246e 256c266e 276d2c6e 2d6a2a6b 2b6a2c6a 2d6d2e6d 2f6e346f
0x00000ee0:  356e3664 376e346f 356c366f 37643c6f 3d6c3e6f 3f643c66 3d6f3e6c 3f6c446f
0x00000f00:  45654669 436c446e 4562466e 476d4c6b 496b4a6a 4b644c6d 4f6e4e6e 4f6c5066
0x00000f20:  576f566e 576d546f 556e566f 576c5c69 5b665e64 5f675c6f 5d6d5e6f 5f6c646b
0x00000f40:  6166666e 676f646f 656c666d 676f6c6c 6d6f6e6c 6f6a6c6e 6d6c6e6d 6f6f706a
0x00000f60:  7162726d 776f746f 756c766e 77657c6e 7f6e7b6f 7c6e7d6a 7e6e7f6d 8e1e0565
</pre>
So it looks like we've gotten rid of the bit 0 and 1 errors in favor of bit 2 and 3 errors.
<!-- Comment: Wed Mar 24 17;57;53 comment by...reid -->
<pre>pictures of the BECLK tuning to follow.</pre>
<!-- Date: Wed Mar 24 15:30:28 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W8L1 
<li>problem n: 1229 
<li>Status: needs_quiet_time
<li>Type: Other
<li>Action: Monitoring
<li>entered by: sforrest 
<li>description is: <pre>Removed fiber from FTM. Optical signal now reads out through 
opticla harness -> G-link -> 1RR30C-E245 for long term 
monitoring of DOIM light level outputs.</pre> 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B4W8&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Mar 24 15:31:02 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W11L1 
<li>problem n: 1230 
<li>Status: needs_quiet_time
<li>Type: Other
<li>Action: Monitoring
<li>entered by: sforrest 
<li>description is: <pre>Removed fiber from FTM. Optical signal now reads out through 
optical harness -> G-link -> 1RR30C-E245 for long term 
monitoring of DOIM light level outputs.</pre> 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W11&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Mar 24 16:38:03 2004 -->
<p>Installed two more optical harnesses in order to use output of 
otherwise useless DOIMs to monitor light levels. These are the 
connections of DOIM output channels (channels 2-10 are used) to 
spare G-link cables:</p> 
<p></p> 
 
<table border=3> 
<caption><b><i>DOIM e0b1 cable connections</i></b></caption> 
<tr><td><b>Output channel</b></td><td><b>FIB-SPL #</b></td> 
    <td><b>Cable bunch #</b></td><td><b>Cable #</b></td></tr> 
<tr><td>2</td><td>????</td><td>84730</td><td>6</td></tr> 
<tr><td>3</td><td>????</td><td>84733</td><td>5</td></tr> 
<tr><td>4</td><td>????</td><td>84733</td><td>6</td></tr> 
<tr><td>5</td><td>S023</td><td>84727</td><td>5</td></tr> 
<tr><td>6</td><td>S023</td><td>84727</td><td>6</td></tr> 
<tr><td>7</td><td>S001</td><td>84726</td><td>5</td></tr> 
<tr><td>8</td><td>S001</td><td>84726</td><td>6</td></tr> 
<tr><td>9</td><td>S123</td><td>84729</td><td>5</td></tr> 
<tr><td>10</td><td>S123</td><td>84729</td><td>6</td></tr> 
</table> 
<p></p> 
<table border=3> 
<caption><b><i>DOIM e481 cable connections</i></b></caption> 
<tr><td><b>Output channel</b></td><td><b>FIB-SPL #</b></td> 
    <td><b>Cable bunch #</b></td><td><b>Cable #</b></td></tr> 
<tr><td>2</td><td>S567</td><td>84746</td><td>6</td></tr> 
<tr><td>3</td><td>S545</td><td>84740</td><td>5</td></tr> 
<tr><td>4</td><td>S545</td><td>84740</td><td>6</td></tr> 
<tr><td>5</td><td>S445</td><td>84739</td><td>5</td></tr> 
<tr><td>6</td><td>S445</td><td>84739</td><td>6</td></tr> 
<tr><td>7</td><td>S389</td><td>84743</td><td>5</td></tr> 
<tr><td>8</td><td>S389</td><td>84743</td><td>6</td></tr> 
<tr><td>9</td><td>S367</td><td>84742</td><td>5</td></tr> 
<tr><td>10</td><td>S367</td><td>84742</td><td>6</td></tr> 
</table>  
<!-- Author: Erik & Stan -->
<!-- Comment: Wed Mar 24 17;44;08 comment by...rainer -->
both of these optical harnesses were unplugged and the fibre put back into the readout channel because both of them are guinea pigs.
<!-- Date: Wed Mar 24 17:28:08 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W11L1 
<li>problem n: 1230 
<li>Status: needs_observation
<li>Type: Other
<li>Action: Diagnosis_update
<li>entered by: rainer 
<li>description is: put fibre back in. this ladder is a guinea pig and needs to be present for DAQ tests. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W11&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Mar 24 17:29:33 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W8L1 
<li>problem n: 1229 
<li>Status: needs_observation
<li>Type: Other
<li>Action: Diagnosis_update
<li>entered by: rainer 
<li>description is: put fibre back in. this ladder is a guinea pig and needs to be present for DAQ tests.   
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B4W8&layer=L1">report</a></ul>
<!-- Author: Problem DB -->






<!-- Date: Wed Mar 24 18:09:14 2004 -->
<center><a href='/elog/notebooks/silicon/Wed_Mar_24_2004_180817.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3651' ></a><a href='/elog/notebooks/silicon/Wed_Mar_24_2004_180830.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3653' ></a></center>
<!-- Author: reid -->
<!-- Comment: Wed Mar 24 18;10;24 comment by...reid -->
<h3>e154 Tuning pictures</h3>
<b>Before</b> is on the left<br>
<b>After</b> is on the right


<!-- Date: Wed Mar 24 19:00:08 2004 -->
<b> bitreporter overview for ALL ladders </b> 
<a href=' http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/errmon/makepage.pl?beginrun=165580&endrun=today&errors=All&custom=1%2C2%2C3&least_rate=1&least_freq=5&least_event=100&namefilter=*B*W*L*'>here </a>
<!-- Author: rainer -->

<!-- Date: Wed Mar 24 20:57:09 2004 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 319
Calibration type  : nonstandard
Run period tag    : Mar_2004
DPS-off run       : 180807
DPS-on run        : 180806
Requested by      : Paul Lujan
Main process id   : 27024203
Comment           : No beam or B-field; newest trigger table
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->


<!-- Date: Wed Mar 24 20:57:32 2004 -->
<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 319 FAILED.

Job info
--------
Calibration type : nonstandard
DPS-off run      : 180807
DPS-on run       : 180806
Requested by     : Paul Lujan
Submitted        : 2004-03-24 20:57:06
Completed        : 2004-03-24 20:57:25
Status           : FAILURE
Comment          : No beam or B-field; newest trigger table

Last processing stage reported : start of the run_calib_analysis.tcl script
Failure diagnostics :
Host key not found from the list of known hosts.
You have no controlling tty.  Cannot read confirmation.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Wed Mar 24 21:38:10 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3654&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3654' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3655&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3655' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3656&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3656' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3658&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3658' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3657&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3657' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3659&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3659' width='300'></a></center>
<!-- Author: rainer -->
<!-- Comment: Wed Mar 24 21;41;15 comment by...rainer -->
DPS OFF dmod calibration plots for 168853 (before sept 2003 shutdown), 170969 (during sept 2003 shutdown) and 180807 (after march 2004 shutdown). so some ladders indeed drop readout in DPS OFF mode for a longer time.


<!-- Date: Wed Mar 24 21:43:29 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3660&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3661  width='300' align='top'></a></td><td>SB05L2 incessently trips in DPS OFF dmod calibration.  we increased the SPT limit from 275 to 300 mA.</td></tr></table>
<!-- Author: rainer -->

<!-- Date: Wed Mar 24 21:47:06 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W5L2 
<li>problem n: 1225 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: Diagnosis_update
<li>entered by: rainer 
<li>description is: correction: trips during DPS off dmod calibration only. plot see    <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=188&frame=2&anchor=21:43:29'> here</a>  SPT limit upped from 275 to 300.  
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Mar 24 22:30:38 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W7L2 
<li>problem n: 1046 
<li>Status: needs_quiet_time
<li>Type: AVDD2
<li>Action: Removed_hdwdb
<li>entered by: reid 
<li>description is: no/garbage data from this guy but stuck cell id during cosmics after COT wire plane shutdown. <pre>e372 18fc 892c 00f3 f3aa 00c0 a8ff a0ec 00c0 00c0 <br>      fbaa 00c0 a8ff 00c0 a0ff 00c0 fbaa 00c0 c2c2 0000 </pre> 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B3W7&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Mar 24 23:43:24 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L0 
<li>problem n: 1231 
<li>Status: needs_work
<li>Type: DRO_00F3
<li>Action: Incident
<li>entered by: rainer 
<li>description is: no data in post COT wireplane cosmics running. <pre> e080 8bfc 00f3 00f3 00f3 00f3 00c2 c2c4 e081 8bfc 8511 </pre> 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Mar 25 09:17:05 2004 -->
<h3>Turning off the Silicon for SRC tests/Apeture Scans</h3> 
Reid and I turned off the Silicon during a COSMIC run 180836 
to test the inhibits. <ul> 
<li> L00 off from PS GUI <BR> 
Get IFIX:L00 inhibit and ISL06:TRIP inhibit, the latter because 
one L00 PS tripped 
<li> ISL off from PS GUI <br> 
Get IFIX:ISL inhibit 
<li> Reset Trips from PS GUI <br> 
ISL06:TRIP goes away 
<li> SVX off from PS GUI <br> 
Got IFIX:SVX and several SVXxy:TRIP because of things tripping when they go off </ul> 
Then something strange happened.  SVX went off, but then the GUI 
started attempting to turn it back on (or to standby).  It failed 
only because the Fib crates were still in the ACTIVE state, so no handshakes.  Once it was done, in IFIX <ul> 
<li> The Standby button was lit up 
<li> When trying to send an OFF via IFIX, it refused, with a little pop up window saying "you have to be in Standby first" 
<li> The last message in the GUI was "IFIX:Success Silicon ON" 
</ul> 
So, we enabled the Kill switches, and then issued the STANDBY transition to IFIX (knowing the ladders cannot go on), just so 
we can "go to OFF" in IFIX.  We got the expected "tried 10 times" messages, but then the GUI started trying to recover from spontaneous trips.  Rather than watching it fail across the board, we decided to kill the GUI and restart it<P> 
Now, svxinter is printing out endless messages involving 
array elements (like "count[0][29][2] = 17") etc which while 
time consuming is not all that informative to the novice.<P> 
When done, however, the PS GUI did not convince IFIX that the 
detector is not ON.<P> 
We somehow rectify (or readdress at least) this IFIX confusion when it is time to turn on Guinea Pigs. 
  
<!-- Author: SCN, Reid -->


<!-- Date: Thu Mar 25 12:37:51 2004 -->
<h3> SRC Firmware Swap</h3> 
 
The SRC firmware swap is underway. The following is a transcription 
of what is happening now: 
 
<ol> 
<li> Turned silicon OFF</li> 
<li> Swapped <i>Dopey</i> (old test stand board) for <i>Sneezy</i>  
(b0svx02 "old reliable").</li> 
<li> Brought up svxdaq with no fibs to check status. 
All checked out okay. KEEPALIVES were coming as expected.</li> 
<li> Ran with the SRC only at high rate. All looked normal 
(digitize, readout, no scanbusy or readbusy (obviously)). No 
keepalives since the rate of L1A was so high it wasn't  
necessary.</li> 
<li> Added a FIB, run at a low rate. Everything normal 
(digitize, readout, scanbusy, readbuys).</li> 
<li> Took some fake data in RC. Had to Manually override 
the failure of the fib crate to config to take "fake data". 
<font color="red">Don't try this at home!</font> Everything 
looked normal (digitize, readout, readbusy, scanbusy, 
keepalives in HALT, RECOVER, RUN).</li> 
<li> Brought out the <b>PIGS!</b> (e481,e0b1,f840).</li> 
<li> Included them in RC. Using SEB, Interval0 = 100000.</li> 
</ol> 
  
We are currently running the guinea pigs only, for a little 
while. The plan is to integrate the pigs with CDF for 
an extended period of time (as long as is possible).  
<!-- Author: Sal, SCN, Marcel -->


<!-- Date: Thu Mar 25 13:36:14 2004 -->
<h3>The Pigs are IN!!!</h3> 
We have started the "COSMICS_SILIPIGS_TAPE" run in the full 
system. They are spinning their wheels happily. The plan is to run with them as long as possible given other constraints.
<!-- Author: Sal, SCN, Rainer, Marcel -->


<!-- Date: Thu Mar 25 14:06:01 2004 -->
<table border=0><td><tr><td bgcolor=#e0e030>The SiliGuineaPig run is working quite well now. We  
are going to run like this for a long time. If there 
are any problems, please <b><font color="red">page SRC (SAL) : 722-7599</font></b>. </td></tr></td></table>
<!-- Author: Sal, SCN, Rainer, Marcel -->


<!-- Date: Thu Mar 25 17:13:14 2004 -->
<b> silicon  at standby now </b> 
<p> 
switched silicon to standby, brought it through a coldstart and ran a few thousand events. no problems seen.  
<!-- Author: Sal, Rainer, Marcel -->

<!-- Date: Fri Mar 26 14:23:43 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W5L4 
<li>problem n: 11 
<li>Status: needs_quiet_time
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: rainer 
<li>description is: tried to tune the BECLK clock, but not with too much success. bit0,1 errors became bit2,3. oscilloscope <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=188&frame=2&anchor=18:09:14'> plots </a> here. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Mar 26 14:27:23 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W8L2 
<li>problem n: 1191 
<li>Status: needs_access
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: rainer 
<li>description is: suggest light level measurement. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B3W8&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Mar 26 14:29:27 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L0 
<li>problem n: 1231 
<li>Status: needs_quiet_time
<li>Type: DRO_00F3
<li>Action: Diagnosis_update
<li>entered by: rainer 
<li>description is: change to needs quiet time. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Mar 26 14:35:40 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W0L0 
<li>problem n: 1232 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: rainer 
<li>description is: pipeline out of sync, stuck cell id problems after shutdown which died away. keep an eye on it. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Mar 26 14:38:51 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W10L2 
<li>problem n: 1226 
<li>Status: needs_observation
<li>Type: DRO_00F3
<li>Action: Diagnosis_update
<li>entered by: rainer 
<li>description is: problems seem to have gone away in cosmics data taking after COT wire plane shutdown - keep an eye on it. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B4W10&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Mar 26 15:19:07 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L4 
<li>problem n: 1228 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Diagnosis_update
<li>entered by: rainer 
<li>description is: not seen in cosmics anymore. keep an eye on it. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L4">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Sat Mar 27 13:15:23 2004 -->
<font size=+1><b>Handling spontaneous transitions is removed from the PS GUI</b>  </font></LI><br>   
</font> 
 
<p> I have successfully tested the new version of the code by powering OFF<->STBY the detector from the PS GUI and iFix. <br> 
<p> I can't respond meaningfully to messages regarding the GUI earlier this week, because all GUI log files mysteriously dissappeared sometime between 9 am and 12pm March 25, exactly after the problem was reported or more likely they were moved to another directory?<br> 
<p>I can just say that in previous version all ways to power down the detector other than through the GUI or iFix were treated as spontaneous and the GUI was programmed to recover from them, which may have led to confusions.<br>
<!-- Author: Andrew -->
<!-- Comment: Sat Mar 27 18;57;34 comment by...rainer -->
<pre>the files was restored. a cleanDaq was issued, and the gui log files was split in half. old gui files go to /cdf/svx/daq/PSanywhere/log
</pre>


<!-- Date: Sat Mar 27 19:01:38 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3671&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3672' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3667&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3668' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3669&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3670' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3662&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3662' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3663&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3664' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3665&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3666' ></a></center>
<!-- Author: rainer -->
<!-- Comment: Sat Mar 27 19;03;06 comment by...rainer -->
A closer look at the last two thermocycles already discussed 

<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=188&frame=2&anchor=19:57:09'>
here </a>. temperatures and durations are comparable, but damage sustained was different. 



<!-- Date: Sun Mar 28 06:18:59 2004 -->
<center><a href='/elog/notebooks/silicon/Sun_Mar_28_2004_061811.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3674' ></a><a href='/elog/notebooks/silicon/Sun_Mar_28_2004_061839.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3676' ></a></center>
<!-- Author: rainer -->
<!-- Comment: Sun Mar 28 06;20;28 comment by...rainer -->
<pre>spyplot after and before the shutdown.</pre>


<!-- Date: Sun Mar 28 06:26:40 2004 -->
<center><a href='/elog/notebooks/silicon/Sun_Mar_28_2004_062605.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3678' ></a><a href='/elog/notebooks/silicon/Sun_Mar_28_2004_062612.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3680' ></a><a href='/elog/notebooks/silicon/Sun_Mar_28_2004_062619.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3682' ></a><a href='/elog/notebooks/silicon/Sun_Mar_28_2004_062626.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3684' ></a></center>
<!-- Author: rainer -->
<!-- Comment: Sun Mar 28 06;27;04 comment by...rainer -->
<pre>current SVXMon plots.</pre>


<!-- Date: Sun Mar 28 06:33:51 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3685&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3685' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3687&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3687' width='150'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3686&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3686' width='100'></a></center>
<!-- Author: rainer  -->
<!-- Comment: Sun Mar 28 06;35;25 comment by...rainer -->
<pre>imon current state of affairs.</pre>


<!-- Date: Sun Mar 28 10:17:00 2004 -->
<h2> persistent SVX SRC fatal error </h2> on L2 w/o L1 
<p> 
according to the aces: 
<li> they where taking data happily (run <a href='http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=180969'> 180969 </a>) 
<li> they ended the run for other reasons (SMX calibration) and then they got the silicon back in 
<li> they configured without problems, but on activate b0tsi00 reports error from SVX SRC: <p> 
<pre> 
(RC)   9:05:02 Config -> READY 
(MLE) b0tsi00:Messenger:9:05:10 AM->TS L2 FSM failed to start (State 14) 
CT: 2004.03.28 09:05:23 
5'23" 1 crate/s: b0svx02(112),  in error.[RXPT] 
(MLE) b0dap73.fnal.gov:Thread-24690:9:05:23 AM->FrontEnd Crate Error Condition from: 
VRB_SVX_02 
 
(MLE) b0dap73.fnal.gov:Thread-24690:9:05:23 AM->FrontEnd Error: VRB_SVX_02  
</pre> 
(run <a href='http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=180974'> 180974 </a>) 
<li> this fell into a dead loop
<li> when I came in, the SVX SRC was in error but the LA did not fire ...
<!-- Author: rainer -->
<!-- Comment: Sun Mar 28 10;33;25 comment by...rainer,marcel,sal -->
the trigger for the LA was:
<p>

             1)  Find (SRC #1 Error || Src #2 Error)<br>
             2)  Start Timer1, Then trigger on   (Timer1 > 400ns) once
                 else on (BRAKE == 1) goto 1
</pre>
(from SCN email)

<!-- Date: Sun Mar 28 10:45:33 2004 -->
<h3>L2 W/O L1 Problem</h3> 
The shift crew was unable to clear an "L2 w/o L1" problem today. 
Before I get into that, I will say what we did to examine, 
and clear the problem. 
 
<br><br> 
Marcel and I looked at the SRC status while it was in error. 
There was one error in the "SRC Error" tab page, which of course 
was "L2 w/o L1". I tried to simply HALT-RECOVER-RUN to clear 
the problem. Upon RECOVER, the SRC went into the "Green and Happy" state. Upon RUN, the "L2 w/o L1" error incremented and the SRC went to "Red and Sad".  
<br><br> 
Subsequently, I pulled up the TSI Emulator from the SRC. We triggered on L1A || L2A in the scope. Upon L1A, the LA did not fire. The SRC was still in error. However, upon L2A, the LA 
<b>DID</b> fire, incrementing the "L2 w/o L1A" error on the SRC 
errors page. 
<br><br> 
I then performed an HRR. This cleared the error immediately. 
We then triggered the scope on L1A successfully, as well as L2A. 
The SRC is now happy. 
<br><br> The recovery sequence for the near future is: 
<ol> 
<li> Bring up svxdaq, open connection only.</li> 
<li> Open the SRC status page.</li> 
<li> Open the TSI emulator page. </li> 
<li> Send L1A, followed by L2A</li> 
<li> Send HRR sequence</li> 
</ol> 
This cleared the error today. 
<b>What needs to be understood is why the SRC went into this 
error in the first place.</b> Steve's trigger on "Error without 
handbrake" did not fire, so we have no information on what 
happened before this. 
<br><br> Until further notice, if this error occurs again, please 
page both Marcel and myself, and we will come and clear the problem. 
<br><br> Our working theory is that either there is something wrong with the SRC error logic, or for some reason, the SRC keeps pulling this "L2 w/o L1A" error high on RUN. We will try to 
reconstruct the sequence of events that lead up to this.  
<!-- Author: Sal, Marcel, Rainer -->


<!-- Date: Sun Mar 28 11:08:06 2004 -->
<h3>Furher Saga (or maybe Prequels) To the L2 w/o L1A Problem</h3> 
As far as I can see, the events leading up to the SRC problem are: 
 
<pre> 
Run	Si In?	Desc			Error 
--------------------------------------------- 
180964	No	Normal datataking	SVT problems, EVB problems, XFT problems. PCAL11 giving problems. 
180965	No	Normal datataking	SVT problems, EVB problems, XFT problems. PCAL crates missing from run. 
180966	Yes	Normal datataking	Bunchcounter errors all over the place 
180967	Yes	Normal datataking	Lots of PCAL errors, couldn't take data 
180968	Yes	Normal datataking	EVB immediately goes haywire, gives lots of errors 
180969	Yes	Normal datataking	Problems with PCAL11 crate, EVB went bananas 
180970	No	Plug Calibration	N/A 
180971	No	Plug Calibration	N/A 
180972	No	Plug Calibration	N/A 
180973	No	Plug Calibration	N/A 
180974	Yes	Normal datataking	SRC was in error as soon as ACTIVATE occurred 
180975	Yes	Normal datataking	SRC was in error as soon as ACTIVATE occurred 
180976	No	Normal datataking	N/A 
180977	No	Normal datataking	N/A 
</pre> 
<b>Our guess is that SRC went into error sometime around run 180967 or something like that, and the aces didn't notice it until several runs later.</b> I'm not that surprised that the SRC was thrown into a weird state.  
<br><br> 
I think at this point, our only actual problem is why we couldn't recover from this. I think the "initial" problem was not a silicon crate issue at all, but we couldn't recover from it.
<!-- Author: Sal, Marcel, Rainer -->
<!-- Comment: Mon Mar 29 07;19;13 comment by...SCN -->
I'm sorry, but if the SRC pulls CDFERROR, you cannot take another L1A until it is cleared.  It is not possible.  So it didn't go
into error in some run earlier and then get noticed later. More likely,
something is happening between CONFIG (when the SRC starts listening to the TS) and ACTIVATE.
<!-- Date: Sun Mar 28 19:35:46 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W3L3 
<li>problem n: 752 
<li>Status: needs_study_time
<li>Type: Chip_other
<li>Action: Incident
<li>entered by: rainer 
<li>description is: cap id errors on 0x85 since COT wire plane shutdown. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W3&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Mar 28 22:12:44 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W8L2 
<li>problem n: 1191 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: rainer 
<li>description is: b7L error disappeared like has happened before - keep an eye on it. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B3W8&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Mar 29 05:25:00 2004 -->
<h2> Another night with the SRCs </h2> 
<li> while I happen to be here for shot setup, RC hangs with a b0tsi00 error on activate to take data. The SRCs did NOT have the error LED lit - also, the LA did not fire. See  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=188&frame=2&anchor=04:26:47.769'> 
main elog </a>  
<li> on ABORT, the  SVX SRC goes into error state - also the additional information in RC reveal <pre>6'14" 1 crate/s: b0svx02(112),  in error.[RXPT]b0svx02:Messenger:4:26:05 AM->SRC Fatal Error:Sl 5 L2A w/o L1A  </pre> 
  
<!-- Author: rainer -->


<!-- Date: Mon Mar 29 05:27:08 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3688&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3688' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3689&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3689' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3690&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3690' width='300'></a></center>
<!-- Author: rainer -->
<!-- Comment: Mon Mar 29 05;32;59 comment by...rainer -->
<li> in this error state, the left plot shows the SVXDAQ main page 30 Unknown state.
<li> Applying Sal's trick <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=188&frame=2&anchor=10:45:33'>
trick </a>  (L1A, L2A, HRR) the SRC clears the error (see middle snapshot).
<li> DAQ goes through CONFIG alright and both SRCs are happy (not shown)
<li> however, on ACTIVATE get immediate BUSY TO from b0svx06, and right picture shows state of that SRC. See 
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=188&frame=2&anchor=04:32:41.633'>
main elog </a>. The SRC and ISL SRCs show all 4 yellow buffer indicators  lit (indicating L1 buffers filled), but the ISL SRC in addition has 4 red LEDs lit as well ( indicating L2 buffers pending ?)
<li> another CONFIG does not help - instruct the Aces to drop the silicon crates.
<li> As I want to pick them up in my own run control, cannot get them because every partitiion thinks the FIB crates are in the other paritition - see 
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=188&frame=2&anchor=05:07:50.277'>
main elog.</a>  The partition command attributes them correctly to the local partition, but in the local rc partition transition
fails with <pre>
Failed to Book:
FIB_ISL_01
FIB_ISL_03
FIB_ISL_05
FIB_ISL_07
FIB_SVX_00
FIB_SVX_02
FIB_SVX_04
FIB_SVX_06
</pre>
<li>  currently RC expert is looking into it.
<li> BTW, beam conditions are stable this time .... ( LOSTP RMS is 10%)

<!-- Comment: Mon Mar 29 06;34;22 comment by...rainer -->
<li> after ray cleared the run database (?), I could finally restart my own run control - silicon went through coldstart and activate with no problem.
<li> re-integrated silicon, again with no problem.
<li> it's not clear whether the b0svx06 busy TO was the SRC's fault or the EVB was hosed, or whatnot. certainly, there was oddness going on in the rundb, as evidenced by the double booking problem above and 
this
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=188&frame=2&anchor=06:16:37.960'>
error </a> 


<!-- Date: Mon Mar 29 06:42:52 2004 -->
<li> biggest disappointment is that <b> LA never triggered </b> 
<li> <b> is Sal's recovery procedure safe or does it hose b0svx06 with the 'extra' L1A and L2A ? </b>  
<!-- Author: rainer -->
<!-- Comment: Mon Mar 29 07;24;37 comment by...W.C. Fields -->
I believe you are only talking to b0svx02, the SVXII SRC.  How
would this trick possible effect b0svx06?  Would the same thing
happen if you used for instance an SRC at FCC?

<!-- Comment: Mon Mar 29 07;36;13 comment by...Harpo Marx -->
It appears to me that in run 181020-22 the "magic number of 7 L2A" was being seen, i.e. you could do 7 L2A and then you'd get a BUSY timeout.  I believe this is know to be a problem somewhere
in the EVB/TSI system (either between SM and SCPUs or TM and SM)
I note that I believe run 181020 was ABORTed rather than ENDed, 
(standard problem, already complained about several times: Run Control gives no option but to ABORT if ERROR occurs "very early" in the run) 
and conject that perhaps the something in the EVB system was not
cleaned up nicely.  Once someone could repartition, life got better. 

<!-- Comment: Mon Mar 29 08;34;58 comment by...Groucho -->
well, I thought b0svx06 runs in 'tracer mode' and so maybe it listens to L2A sent to b0svx02 - but judging from your answer I guess they get the trigger signals independently from the TSI. oh well.