<!-- Title: 13:57:34  Fri Sep 14 2001 -->
<!-- Crewchief: Jean -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Store 700 started.  silicon in and running. 
</pre>


<!-- Date: Fri Sep 14 14:43:46 2001 -->
<pre>Reformatter errors mysteriously went away upon restarting run. 
SVX + old ISL now happily taking data while ON.</pre>
<!-- Author: ADF -->


<!-- Date: Fri Sep 14 16:18:10 2001 -->
<p> 
In case anyone wonders, L00 is grey (the color code for "system not implemented yet") on the iFix HV summary page because there 
are no power supplies installed.  It is not any sort of bug. 
</p> 
<!-- Author: Andy H. -->


<!-- Date: Sat Sep 15 20:37:55 2001 -->
<h4>X Mode work today</h4> 
Spent most of the day debugging X Mode-new features 
include faster running, plus Error log summaries which  
end up in the Merlin database so we can see how often which 
HDIs go wrong in what way.  However, there is still some 
problem with b0svx07 when data is coming into VRB in slot 
16, corresponding to Fibs in b0fib07-After somewhere between 
0 and 50 events, the whole cpu just hangs-sometimes we see 
<pre> 
data access 
Exception current instruction address: 0x07987ebc 
Machine Status Register: 0x0000b130               
Data Access Register: 0x1041044c    
Condition Register: 0x42000040   
Data storage interrupt Register: 0x40000000 
Task: 0x78eb358 "SVX_X" 
</pre> 
Instruction address 0x7897ebc is in the parseData routine, 
but turning on much debug did not shed any light on the matter. 
So I'll have to chase this one in the near future. 
<P> 
Leaving out that Fib crate (which means we still use b0svx07, 
just not slot 16) and using all others, I took some runs, 
which are on /data1/svxData: 
<pre> 
/data1/svxData/dpsOff126847.edm  DPS OFF PED_X run 
/data1/svxData/shiftDpsOff126849.edm DPS OFF SHIFT_X run 
/data1/svxData/shiftDpsOn126854.edm DPS ON  SHIFT_X run 
</pre> 
I did not run the consumer on them, as I am tired and want 
to go home.  We can do that offline for now, as these are 
missing all HDIs from b0fib07 anyway.  They do however 
have the new features of an indication of how often 
each chip appears in the event and the 
noise on the Chip Pedestal for each back end state (aka "Common Mode Noise"). 
<P> 
Still have to get to Stage 3, where the VRBs are told what  
HDIs and Chip IDs to expect, instead of relying on data-driven 
parsing.  That is for next week. 
<P> 
Staying around to see Silicon integrated with CDF, then 
be in Monday (well, maybe tomorrow sometime...)  
<!-- Author: SCN -->


<!-- Date: Sun Sep 16 06:47:34 2001 -->
<pre>SB3W7 L2 tripped on Vbias overcurrent.  Could not turn 
back on.  Turned Vbias to 2V to get running (was 
100 V).  Then when turning it on, it tripped, without 
any messsage!  Could not turn it off, removed b0fib06 
from run (which will only last another 1 hr)</pre>
<!-- Author: ADF -->


<!-- Date: Sun Sep 16 08:47:11 2001 -->
<pre>Pilot error on my part this morning; I turned L1 Bias V down! 
 
Now I am doing it correctly.  Put L1 back to 100V, 
change L2 from 40V to 2V.  Can get L2 to stay on now. 
 
Here is I-V curve of L2. Current is not spiky / time dependent, 
when you change the voltage the current simply goes right to 
the new value, no need to let it settle down. 
 
Vbias   Ibias 
5	130 
10	446 
15	773 
20	1107 
25	1448 
27	1584 
30	1718 
31	1859</pre>
<!-- Author: ADF -->


<!-- Date: Sun Sep 16 08:47:43 2001 -->
<pre>Rebooted b0svx07 around 0830.  That seemed to fix the problem.</pre>
<!-- Author: ADF -->
<!-- Comment: Mon Sep 17 10;01;27 comment by...SCN -->
What problem did this fix?
<!-- Date: Sun Sep 16 12:31:36 2001 -->
<pre>The PS gui hung, causing all 3 systems to alarm on IFIX. 
TH GUI window was all grey.  The command jobs showed 2 PS 
GUIs running, but I could only find one, the all grey  
one.  I did a killall java and  a PS &.  then I tried jobs 
again and there were still 2. So explicitly killed 
both and restarted.  Now there is only one. 
</pre>
<!-- Author: jean -->



<!-- Date: Mon Sep 17 10:06:06 2001 -->
Got <a href= 
'/cgi/elog/elog.pl?nb=2001&action=view&page=677&frame=2&anchor=07:40:46'> 
paged</a> because b0fib03 is not responding.  So far <ul> 
<li> Xminicom shows nothing 
<li> Cannot rlogin 
<li> crate_reset does nothing 
<li> Backdoor SYS RESET via SRC-FFO glink resets all other 
Fib crates (I turned CAENs OFF to do this) but not this one. 
</ul> 
Most likely cause is no power on the backplane. 
Rack IFIX shows rack is Green, i.e. ON, but perhaps we've lost 
VME PS.  VME PS is not currently in IFIX monitoring, but 
I think the cable is hooked up, so I'll investigate probing it 
or getting it hooked up.  We may need access to fix this.
<!-- Author: SCN -->
<!-- Comment: Mon Sep 17 10;17;56 comment by...SCN -->
Fred Lewis and I will try to look at the VME PS via the
cable in about 15 minutes.  Leaving SVX off for now, will
do the failed init to download maps.


<!-- Date: Mon Sep 17 10:57:44 2001 -->
<h3>So much for ISL West</h3> 
Fred says the VME PS is dead.  We will live without this 
crate until Wednesday or Thursday (i.e. after the next shot, 
scheduled for today) when we can get in and replace the PS. 
In the meantime, I turned the whole crate offline.  I am not 
sure how to modify powerset.dat other than by hand.  In any 
case, there will be no handshake for those wedges.  This crate 
serves IB0W0, IB0W1, and I think IB0W4, IB0W5. 
<P> 
Also, found that something in the software does not 
like it when no FIBs are online.  Get "corrupt handle" messages. 
Not sure why, will track down. Note there are no Fibs online 
in b0fib01, which means we are no longer reading out 
any ISL on the West side.  I don't know why we have thrown 
out IB0W2 and IB0W3, I assume there is some reason.
<!-- Author: SCN -->
<!-- Comment: Mon Sep 17 11;29;22 comment by...SCN -->
HDIs in this crate:
<ul>
<li>IB0W0, IB0W1 (Slot 9)
<li>IB0W4, IB0W5 (Slot 10)
<li>IB1W0, IB1W1 (Slot 11)
<li>IB2W2, SOC   (Slot 12)
<li>LB0W0, LB0W1 (Slot 16)
<li>LB0W4, LB0W5 (Slot 17)
</ul>
Currently we are only using the IB0Wx ones... 

<!-- Comment: Mon Sep 17 11;31;30 comment by...SCN -->
Also, fixed the "corrupt handle" problems.

<!-- Comment: Mon Sep 17 11;40;55 comment by...SCN -->
Are the ladders ok?<BR>
It occurs to me that from the moment this PS died, around 
7:30 this AM, until I powered off all Silicon at
09:28, any of these ladders getting power were neither
receiving keep-alives nor even clocks.  Someone may
want to invesitgate Temperature and Current plots from this
time.

<!-- Comment: Mon Sep 17 11;41;58 comment by...Petra -->
<pre>See &lt;a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=66&frame=2&anchor=16:54:23'&gt;
here&lt;/a&gt; for original comment by Andy:
 
</pre>

<!-- Comment: Mon Sep 17 11;42;06 comment by...Petra -->
<pre>See &lt;a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=66&frame=2&anchor=16:54:23'&gt;
here&lt;/a&gt; for original comment by Andy:
 
</pre>

<!-- Comment: Mon Sep 17 11;43;14 comment by...Petra -->
<pre>See <a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=66&frame=2&anchor=16:54:23'> here</a> for original comment by Andy:
 
</pre>


<!-- Date: Mon Sep 17 15:25:15 2001 -->
Ran cratematch.pl, and found: 
<pre> 
List of the 282 ladders that are going to be integrated this time  
 
SB0W0L0  SB0W0L1  SB0W0L2  SB0W0L3  SB0W0L4   
SB0W1L0  SB0W1L1  SB0W1L3   
SB0W2L0  SB0W2L1  SB0W2L2  SB0W2L3   
SB0W3L2  SB0W3L3   
SB0W10L1  SB0W10L2  SB0W10L3  SB0W10L4   
SB0W11L1  SB0W11L2  SB0W11L3   
SB1W0L0  SB1W0L1  SB1W0L2  SB1W0L3  SB1W0L4   
SB1W1L0  SB1W1L1  SB1W1L2  SB1W1L3  SB1W1L4   
SB1W2L0  SB1W2L1  SB1W2L2  SB1W2L3  SB1W2L4   
SB1W3L0  SB1W3L1   
SB1W10L0  SB1W10L1  SB1W10L2  SB1W10L3  SB1W10L4   
SB1W11L0  SB1W11L1  SB1W11L2  SB1W11L3  SB1W11L4   
SB2W0L0  SB2W0L1  SB2W0L2  SB2W0L3  SB2W0L4   
SB2W1L0  SB2W1L1  SB2W1L2  SB2W1L3  SB2W1L4   
SB2W2L0  SB2W2L1  SB2W2L3  SB2W2L4   
SB2W3L0  SB2W3L1  SB2W3L2  SB2W3L3  SB2W3L4   
SB2W10L0  SB2W10L1  SB2W10L2  SB2W10L3  SB2W10L4   
SB2W11L0  SB2W11L1  SB2W11L2  SB2W11L3  SB2W11L4   
SB0W4L0  SB0W4L1  SB0W4L2  SB0W4L3  SB0W4L4   
SB0W6L1  SB0W6L3  SB0W6L4   
SB0W7L0  SB0W7L1  SB0W7L2  SB0W7L3  SB0W7L4   
SB0W8L0  SB0W8L1  SB0W8L2  SB0W8L3  SB0W8L4   
SB0W9L0  SB0W9L1  SB0W9L2  SB0W9L3  SB0W9L4   
SB1W4L0  SB1W4L1  SB1W4L2  SB1W4L4   
SB1W5L0  SB1W5L1  SB1W5L3  SB1W5L4   
SB1W6L0  SB1W6L1  SB1W6L2  SB1W6L3  SB1W6L4   
SB1W8L1  SB1W8L3  SB1W8L4   
SB1W9L0  SB1W9L1  SB1W9L2  SB1W9L3  SB1W9L4   
SB2W5L1  SB2W5L2  SB2W5L3  SB2W5L4   
SB2W6L1  SB2W6L2  SB2W6L3  SB2W6L4   
SB2W8L0  SB2W8L1  SB2W8L3   
SB2W9L0  SB2W9L1  SB2W9L2  SB2W9L3  SB2W9L4   
IB0W0L0  IB0W0L1  IB0W0L2  IB0W0L3   
IB0W4L0  IB0W4L1  IB0W4L3  IB0W4L4   
IB0W5L0  IB0W5L1  IB0W5L2  IB0W5L4   
SB3W0L0  SB3W0L1  SB3W0L2  SB3W0L3  SB3W0L4   
SB3W1L0  SB3W1L1  SB3W1L2  SB3W1L3  SB3W1L4   
SB3W2L0  SB3W2L1  SB3W2L3  SB3W2L4   
SB3W3L0  SB3W3L1  SB3W3L2  SB3W3L3   
SB3W10L0  SB3W10L1  SB3W10L2  SB3W10L3  SB3W10L4   
SB3W11L0  SB3W11L1  SB3W11L2  SB3W11L3   
SB4W0L0  SB4W0L1  SB4W0L2  SB4W0L3   
SB4W1L0  SB4W1L1  SB4W1L2  SB4W1L3  SB4W1L4   
SB4W2L0  SB4W2L1  SB4W2L2  SB4W2L3  SB4W2L4   
SB4W3L1  SB4W3L3  SB4W3L4   
SB4W10L0  SB4W10L2  SB4W10L3   
SB4W11L0  SB4W11L1  SB4W11L2  SB4W11L3  SB4W11L4   
SB5W1L0  SB5W1L1  SB5W1L2   
SB5W2L0  SB5W2L1  SB5W2L2  SB5W2L3  SB5W2L4   
SB5W3L0  SB5W3L1  SB5W3L3   
IB5W2L0  IB5W2L1  IB5W2L2  IB5W2L3  IB5W2L4   
IB5W3L1  IB5W3L3  IB5W3L4   
SB3W5L1  SB3W5L2  SB3W5L3  SB3W5L4   
SB3W6L0  SB3W6L1  SB3W6L2  SB3W6L3  SB3W6L4   
SB3W7L0  SB3W7L1  SB3W7L2  SB3W7L3  SB3W7L4   
SB3W8L0  SB3W8L1  SB3W8L2  SB3W8L3  SB3W8L4   
SB3W9L0  SB3W9L1  SB3W9L2  SB3W9L3  SB3W9L4   
SB4W4L0  SB4W4L1  SB4W4L4   
SB4W5L0  SB4W5L1  SB4W5L2  SB4W5L3  SB4W5L4   
SB4W6L1  SB4W6L2  SB4W6L4   
SB4W7L0  SB4W7L1  SB4W7L2  SB4W7L3  SB4W7L4   
SB4W8L0  SB4W8L2  SB4W8L3  SB4W8L4   
SB5W4L0  SB5W4L1  SB5W4L2  SB5W4L3  SB5W4L4   
SB5W7L1  SB5W7L2  SB5W7L3  SB5W7L4   
IB5W4L0  IB5W4L1  IB5W4L2  IB5W4L3  IB5W4L4   
IB5W5L0  IB5W5L1  IB5W5L2  IB5W5L4   
 
List of the 270 channels that have low voltage on:  
SB0W0L4  SB0W0L3  SB0W0L2  SB0W0L1  SB0W0L0   
SB0W1L3  SB0W1L1  SB0W1L0   
SB0W2L3  SB0W2L2  SB0W2L1  SB0W2L0   
SB0W3L3  SB0W3L2   
SB0W4L4  SB0W4L3  SB0W4L2  SB0W4L1  SB0W4L0   
SB0W6L4  SB0W6L3  SB0W6L1   
SB0W7L4  SB0W7L3  SB0W7L2  SB0W7L1  SB0W7L0   
SB0W8L4  SB0W8L3  SB0W8L2  SB0W8L1  SB0W8L0   
SB0W9L4  SB0W9L3  SB0W9L2  SB0W9L1  SB0W9L0   
SB0W10L4  SB0W10L3  SB0W10L2  SB0W10L1   
SB0W11L3  SB0W11L2  SB0W11L1   
SB1W0L4  SB1W0L3  SB1W0L2  SB1W0L1  SB1W0L0   
SB1W1L4  SB1W1L3  SB1W1L2  SB1W1L1  SB1W1L0   
SB1W2L4  SB1W2L3  SB1W2L2  SB1W2L1  SB1W2L0   
SB1W3L1  SB1W3L0   
SB1W4L4  SB1W4L2  SB1W4L1  SB1W4L0   
SB1W5L4  SB1W5L3  SB1W5L1  SB1W5L0   
SB1W6L4  SB1W6L3  SB1W6L2  SB1W6L1  SB1W6L0   
SB1W8L4  SB1W8L3  SB1W8L1   
SB1W9L4  SB1W9L3  SB1W9L2  SB1W9L1  SB1W9L0   
SB1W10L4  SB1W10L3  SB1W10L2  SB1W10L1  SB1W10L0   
SB1W11L4  SB1W11L3  SB1W11L2  SB1W11L1  SB1W11L0   
SB2W0L4  SB2W0L3  SB2W0L2  SB2W0L1  SB2W0L0   
SB2W1L4  SB2W1L3  SB2W1L2  SB2W1L1  SB2W1L0   
SB2W2L4  SB2W2L3  SB2W2L1  SB2W2L0   
SB2W3L4  SB2W3L3  SB2W3L2  SB2W3L1  SB2W3L0   
SB2W5L4  SB2W5L3  SB2W5L2  SB2W5L1   
SB2W6L4  SB2W6L3  SB2W6L2  SB2W6L1   
SB2W8L3  SB2W8L1  SB2W8L0   
SB2W9L4  SB2W9L3  SB2W9L2  SB2W9L1  SB2W9L0   
SB2W10L4  SB2W10L3  SB2W10L2  SB2W10L1  SB2W10L0   
SB2W11L4  SB2W11L3  SB2W11L2  SB2W11L1  SB2W11L0   
SB3W0L4  SB3W0L3  SB3W0L2  SB3W0L1  SB3W0L0   
SB3W1L4  SB3W1L3  SB3W1L2  SB3W1L1  SB3W1L0   
SB3W2L4  SB3W2L3  SB3W2L1  SB3W2L0   
SB3W3L3  SB3W3L2  SB3W3L1  SB3W3L0   
SB3W5L4  SB3W5L3  SB3W5L2  SB3W5L1   
SB3W6L4  SB3W6L3  SB3W6L2  SB3W6L1  SB3W6L0   
SB3W7L4  SB3W7L3  SB3W7L2  SB3W7L1  SB3W7L0   
SB3W8L4  SB3W8L3  SB3W8L2  SB3W8L1  SB3W8L0   
SB3W9L4  SB3W9L3  SB3W9L2  SB3W9L1  SB3W9L0   
SB3W10L4  SB3W10L3  SB3W10L2  SB3W10L1  SB3W10L0   
SB3W11L3  SB3W11L2  SB3W11L1  SB3W11L0   
SB4W0L3  SB4W0L2  SB4W0L1  SB4W0L0   
SB4W1L4  SB4W1L3  SB4W1L2  SB4W1L1  SB4W1L0   
SB4W2L4  SB4W2L3  SB4W2L2  SB4W2L1  SB4W2L0   
SB4W3L4  SB4W3L3  SB4W3L1   
SB4W4L4  SB4W4L1  SB4W4L0   
SB4W5L4  SB4W5L3  SB4W5L2  SB4W5L1  SB4W5L0   
SB4W6L4  SB4W6L2  SB4W6L1   
SB4W7L4  SB4W7L3  SB4W7L2  SB4W7L1  SB4W7L0   
SB4W8L4  SB4W8L3  SB4W8L2  SB4W8L0   
SB4W10L3  SB4W10L2  SB4W10L0   
SB4W11L4  SB4W11L3  SB4W11L2  SB4W11L1  SB4W11L0   
SB5W1L2  SB5W1L1  SB5W1L0   
SB5W2L4  SB5W2L3  SB5W2L2  SB5W2L1  SB5W2L0   
SB5W3L3  SB5W3L1  SB5W3L0   
SB5W4L4  SB5W4L3  SB5W4L2  SB5W4L1  SB5W4L0   
SB5W7L4  SB5W7L3  SB5W7L2  SB5W7L1   
IB5W2L4  IB5W2L3  IB5W2L2  IB5W2L1  IB5W2L0   
IB5W3L4  IB5W3L3  IB5W3L1   
IB5W4L4  IB5W4L3  IB5W4L2  IB5W4L1  IB5W4L0   
IB5W5L4  IB5W5L2  IB5W5L1  IB5W5L0   
  
List of the 280 biased channels: 
  
SB0W0L4  SB0W0L3  SB0W0L2  SB0W0L1  SB0W0L0   
SB0W1L3  SB0W1L1  SB0W1L0   
SB0W2L3  SB0W2L2  SB0W2L1  SB0W2L0   
SB0W3L3  SB0W3L2   
SB0W4L4  SB0W4L3  SB0W4L2  SB0W4L1  SB0W4L0   
SB0W6L4  SB0W6L3  SB0W6L1   
SB0W7L3  SB0W7L2  SB0W7L1  SB0W7L0   
SB0W8L4  SB0W8L3  SB0W8L2  SB0W8L1  SB0W8L0   
SB0W9L4  SB0W9L3  SB0W9L2  SB0W9L1  SB0W9L0   
SB0W10L4  SB0W10L3  SB0W10L2  SB0W10L1   
SB0W11L3  SB0W11L2  SB0W11L1   
SB1W0L4  SB1W0L3  SB1W0L2  SB1W0L1  SB1W0L0   
SB1W1L4  SB1W1L3  SB1W1L2  SB1W1L1  SB1W1L0   
SB1W2L4  SB1W2L3  SB1W2L2  SB1W2L1  SB1W2L0   
SB1W3L1  SB1W3L0   
SB1W4L4  SB1W4L2  SB1W4L1  SB1W4L0   
SB1W5L4  SB1W5L3  SB1W5L1  SB1W5L0   
SB1W6L4  SB1W6L3  SB1W6L2  SB1W6L1  SB1W6L0   
SB1W8L4  SB1W8L3  SB1W8L1   
SB1W9L4  SB1W9L3  SB1W9L2  SB1W9L1  SB1W9L0   
SB1W10L4  SB1W10L3  SB1W10L2  SB1W10L1  SB1W10L0   
SB1W11L4  SB1W11L3  SB1W11L2  SB1W11L1  SB1W11L0   
SB2W0L4  SB2W0L3  SB2W0L1  SB2W0L0   
SB2W1L4  SB2W1L3  SB2W1L2  SB2W1L1  SB2W1L0   
SB2W2L4  SB2W2L3  SB2W2L1  SB2W2L0   
SB2W3L4  SB2W3L3  SB2W3L2  SB2W3L1  SB2W3L0   
SB2W5L4  SB2W5L3  SB2W5L2  SB2W5L1   
SB2W6L4  SB2W6L3  SB2W6L2  SB2W6L1   
SB2W8L3  SB2W8L1  SB2W8L0   
SB2W9L4  SB2W9L3  SB2W9L2  SB2W9L1  SB2W9L0   
SB2W10L4  SB2W10L3  SB2W10L2  SB2W10L1  SB2W10L0   
SB2W11L4  SB2W11L3  SB2W11L2  SB2W11L1  SB2W11L0   
SB3W0L4  SB3W0L3  SB3W0L1  SB3W0L0   
SB3W1L3  SB3W1L2  SB3W1L1  SB3W1L0   
SB3W2L4  SB3W2L3  SB3W2L1  SB3W2L0   
SB3W3L3  SB3W3L2  SB3W3L1  SB3W3L0   
SB3W5L4  SB3W5L3  SB3W5L2  SB3W5L1   
SB3W6L4  SB3W6L3  SB3W6L2  SB3W6L1  SB3W6L0   
SB3W7L4  SB3W7L3  SB3W7L1  SB3W7L0   
SB3W8L4  SB3W8L3  SB3W8L2  SB3W8L1  SB3W8L0   
SB3W9L4  SB3W9L3  SB3W9L2  SB3W9L1  SB3W9L0   
SB3W10L4  SB3W10L3  SB3W10L2  SB3W10L1  SB3W10L0   
SB3W11L3  SB3W11L2  SB3W11L1  SB3W11L0   
SB4W0L3  SB4W0L2  SB4W0L1  SB4W0L0   
SB4W1L4  SB4W1L3  SB4W1L2  SB4W1L1  SB4W1L0   
SB4W2L4  SB4W2L3  SB4W2L2  SB4W2L1  SB4W2L0   
SB4W3L4  SB4W3L3  SB4W3L1   
SB4W4L4  SB4W4L1  SB4W4L0   
SB4W5L4  SB4W5L3  SB4W5L2  SB4W5L1  SB4W5L0   
SB4W6L4  SB4W6L2  SB4W6L1   
SB4W7L4  SB4W7L3  SB4W7L2  SB4W7L1  SB4W7L0   
SB4W8L4  SB4W8L3  SB4W8L2  SB4W8L0   
SB4W10L3  SB4W10L2  SB4W10L0   
SB4W11L4  SB4W11L3  SB4W11L2  SB4W11L1  SB4W11L0   
SB5W1L2  SB5W1L1  SB5W1L0   
SB5W2L4  SB5W2L3  SB5W2L2  SB5W2L1  SB5W2L0   
SB5W3L3  SB5W3L1  SB5W3L0   
SB5W4L4  SB5W4L3  SB5W4L2  SB5W4L1  SB5W4L0   
SB5W7L4  SB5W7L3  SB5W7L2  SB5W7L1   
IB5W2L41  IB5W2L3  IB5W2L31  IB5W2L2  IB5W2L21  IB5W2L1  IB5W2L11  IB5W2L0  IB5W2L01   
IB5W3L4  IB5W3L41  IB5W3L3  IB5W3L1  IB5W3L11   
IB5W4L4  IB5W4L41  IB5W4L3  IB5W4L31  IB5W4L2  IB5W4L21  IB5W4L1  IB5W4L11  IB5W4L0  IB5 
W4L01   
IB5W5L4  IB5W5L41  IB5W5L2  IB5W5L21  IB5W5L1  IB5W5L11  IB5W5L0  IB5W5L01    
 
The following wedges should be biased and are not:  
 
SB2W0L2   
SB0W7L4   
IB0W0L0  IB0W0L1  IB0W0L2  IB0W0L3   
IB0W4L0  IB0W4L1  IB0W4L3  IB0W4L4   
IB0W5L0  IB0W5L1  IB0W5L2  IB0W5L4   
SB3W0L2   
SB3W1L4   
IB5W2L4   
SB3W7L2 
 
  The following wedges should be OFF and are ON:  
 none  
 
 The following wedges should be Stand-By or ON and are OFF:  
 
IB0W0L0  IB0W0L1  IB0W0L2  IB0W0L3   
IB0W4L0  IB0W4L1  IB0W4L3  IB0W4L4   
IB0W5L0  IB0W5L1  IB0W5L2  IB0W5L4   
 * * * Cold Start would fail ! * * *  
</pre> 
 
Does anyone know why we have 270 with LV but 282 biased?  I 
looked at the IB0W1 and it has VBIAS = VBIAS1 = 2.  Is this 
the problem (to be sure, I used IFIX to drop the 5V enables 
on the ISL West).  Was this Chris's bug?  
<!-- Author: SCN -->
<!-- Comment: Mon Sep 17 15;30;13 comment by...SCN -->
<pre>My mistake, VBIAS's set points were 2, but actual was 0.</pre>

<!-- Comment: Mon Sep 17 15;42;56 comment by...SCN -->
Never mind, its just that there is a factor of 2 for
each ISL "ladder" in the bias counting...Maybe you 
all already knew this


<!-- Comment: Mon Sep 17 16;09;26 comment by...all -->
<pre>yupp</pre>
<!-- Date: Mon Sep 17 15:49:29 2001 -->
<pre>Took a DMODE DPS OFF RUN: Run #126950</pre>
<!-- Author: SCN -->



<!-- Date: Mon Sep 17 16:12:40 2001 -->
<pre>Shot Setup interrupted DPS ON DMODE run #126983. 
It has 150 Events, for whatever that is worth... 
Silicon put in standby for Shot Setup. </pre>
<!-- Author: SCN -->


<!-- Date: Mon Sep 17 16:31:53 2001 -->
<pre>changed more bits in f551, e162 and e164: 
 
f551,e162: changed RO and ramp/comp dir on n-side 
e164: changed RO order=0, ramp/comp dir=1 on p-side 
 
serving more studies for p/n asymmetry</pre>
<!-- Author: petra, tony, david -->


<!-- Date: Mon Sep 17 16:46:39 2001 -->
<a href= 
'/cgi/elog/elog.pl?nb=2001&action=view&page=679&frame=2&anchor=16:45:58'> 
Shift Crew Instructions</a>  Bye!
<!-- Author: SCN -->


<!-- Date: Mon Sep 17 17:31:55 2001 -->
<pre>we had an external "one-liner" trip on SB0W7L2 during proton injection;  
the GUI got frozen and I had to reset svxinter before I could  
restart it.</pre>
<!-- Author: Petra -->


<!-- Date: Tue Sep 18 01:00:59 2001 -->
<pre>Shift crew reported trips in SVX while turning to SBY after 
beam loss.  All B0W0 DVDD currents went high and had software 
protection trips. 
 
 B0W1 L3 turned off silently but was turned back on. 
 B0W1 L0 had DVDD overcurrent trips which persisted when 
turning back on.  An hour later (now), turned back on fine. 
 
 Silicon now in SBY during shot setup and waiting for 
next shot. 
 
</pre>
<!-- Author: ADF -->


<!-- Date: Tue Sep 18 01:02:24 2001 -->
<pre> Strange thing happened at 2041.  All interlocks were reported 
as not enabled,but nothing went off!  In a few minutes 
all interlocks were reported back on again.  Paged ilocks 
pager but no response.   
 
</pre>
<!-- Author: ADF -->


<!-- Date: Tue Sep 18 01:46:42 2001 -->
<pre>Silicon to ON for the next shot.</pre>
<!-- Author: ADF -->


<!-- Date: Tue Sep 18 12:44:17 2001 -->
<pre>I analyzed the data from last night's polarity bit change. It points the finger at the readout order checkbox. 
 
We changed the bits for f551 and e162 to the final combination which we expect to give us low gain on both sides. 
 
The specific change was to set the p-side of these ladders to the nominal settings (which is N-Side). 
 
This was done before (and or during) run 127032. The next run will be analyzed whenever it happens. 
</pre>
<!-- Author: David, Tony, Andy -->
<!-- Comment: Tue Sep 18 13;10;56 comment by...ADF (Tony, David present but absolved of blame) -->
<pre>Because I'm terrified whenever I use the chipeditor,
here's more detail on precisely what I think I did / what I wanted to do:

f551 = IB5W5 L1 = b0fib07 Slot 11 HDI 6
        p-side chips 0-7: Changed polarity bits to their
               "n-side" setting, from "user"

e162 = SB1W6 L2 = b0fib02 Slot 13 HDI 2
        p-side chips 5-9: Changed polarity bits to their
            	"n-side" setting, from "user"</pre>


<!-- Date: Tue Sep 18 13:26:02 2001 -->
<pre>** CHIPS status failures reported online (run 127030) by SVXMon: 
 
LAYER   BARREL  CHIP num.               SIDE 
 
7       0       114                     phi 
7       0       112                     Z 
7       5       125, 141                phi 
7       5       4,5,6,7,8,9             Z 
 
6       0       5,75                    Z 
6       5       1,8,16,76,77            phi 
 
4       0       6                       phi 
4       0       3                       Z 
4       1       70,76,77,79,80,81,82    phi 
4       2       70,71,76,78             phi 
4       2       18,47,78                Z 
4       5       20                      phi 
 
3       1       3                       phi 
3       1       26,37,46                Z 
3       2       15,63                   phi 
3       2       0,1,38                  Z 
3       5       18                      phi 
 
2       0       36                      Z 
2       1       21,56                   Z 
2       2       0,1,39                  phi 
2       2       2                       Z 
 
1       1       17                      phi 
 
0       1       6,7                     phi 
0       2       0,1                     phi 
 
[these are the failures monitored BEFORE a huge spike of 
 of Ref. Errors (&gt;533) preliminar to the end of the run]</pre>
<!-- Author: francesco -->
<!-- Comment: Tue Sep 18 14;37;02 comment by...David -->
<pre>Huh?

Isn't barrel 0 of ISL completely off and out of the run? So why would it give SVXMON errors?

</pre>

<!-- Comment: Tue Sep 18 15;25;38 comment by...francesco -->
<pre>ISL barrel 0 went off in the SVXMon only AFTER the huge spike
of reformatter errors... </pre>


<!-- Comment: Tue Sep 18 16;23;55 comment by...SCN -->
Uh, what makes most sense is that ISL B0 tripped off and
caused the huge spike fo reformatter errors (as does any
ladder when it loses power).  Note that reality
does not always make sense
<!-- Date: Tue Sep 18 16:23:37 2001 -->
<pre>Removed IB5W4L0 from HWDB (reported from SCN that 
it gives no chip ID's, bit 8 stuck low.)</pre>
<!-- Author: ADF -->



<!-- Date: Tue Sep 18 16:28:11 2001 -->
<h3>X Mode victory</h3> 
Ok, I found the bug in X Mode which was causing b0svx07 to 
go belly up <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=67&frame=2&anchor=20:37:55'> 
last time</a>.  Turns out f540 (ISL B5 W4 L0) has bit 8 stuck 
low, so no Chip IDs.  Now X Mode checks to make sure there 
was a Chip ID before assuming the Chips data structures are there.  I took some calibrations and put the files on /data1/svxData, run #s around 127040...<P> 
By the way, I asked Andy to remove IB5W4L0-it is not really 
helping anyone to have a ladder w/o Chip IDs.   
<!-- Author: SCN -->
<!-- Comment: Tue Sep 18 18;52;33 comment by...DS -->
<pre>Yes, IB5W4L0 has been bad for months. Good see it's detectable.</pre>
<!-- Comment: Wed Sep 19 08;00;27 comment by...Lester -->
<pre>This doesn't show up in my bit checker because I was not counting 
the "No Data" error. I will change that now.</pre>
<!-- Date: Tue Sep 18 16:59:16 2001 -->
<pre>Found several instances in which all the enables are 
reported spontaneously off, then spontaneously on, in 
the GUI. 
 
Mon Aug 27 1954 
Wed Aug 29 2114 
Sun Sep 02 1710 
Mon sep 17 0700 
Mon Sep 17 2041</pre>
<!-- Author: ADF -->



<!-- Date: Tue Sep 18 19:30:33 2001 -->
<pre>As part of the SVT-&gt;TS studies, b0fib06 slot 10 has been taken offline under the expert-on-call directions.</pre>
<!-- Author: Bill A -->


<!-- Date: Wed Sep 19 00:33:21 2001 -->
<pre>It seems SB0W3 L3 turned itself off spontaneously when 
run control paused.  Then there was an alarm complaining 
that there were still voltages present.  Reset trips and 
turned L3 back to ON.</pre>
<!-- Author: ADF -->


<!-- Date: Wed Sep 19 01:30:37 2001 -->
<pre>Well, SB0W3 L3 was a toughie.  As it turns out, it was 
silently tripping on a Vbias overcurrent (really, 
check the GUI log; there's no mention of it) even 
though somehow the CDF global HV knew about it 
(?!) 
 
 The Vbias overcurrent was caused by running at 100 V, 
ace & I took an I-V curve and got the following 
 
V            I 
10           2.5 
20           4.8 
30           6.0 
50           15 
60           20 
70           28 
75           32 
80           34 
85           38 
 
        Decided to run for now at 85 V, since this 
should be 5V above depletion, and still not  
tripping.  Changed Caenvolts.dat (was 100 V) 
 
 
 
 
</pre>
<!-- Author: ADF -->


<!-- Date: Wed Sep 19 06:14:02 2001 -->
<pre> GUI was restarted after noticing it was not updating. 
Ace turned silicon OFF so it will need to be brought up 
from scratch.</pre>
<!-- Author: ADF -->



<!-- Date: Wed Sep 19 10:22:30 2001 -->
<pre>we changed two of the test ladders again: 
 
e162 went back to normal since it has an intrinsic gain problem anyway 
f551 changed back to normal bit settings, but the pipeline readamp current reduced from 70 to 35uA per channel (all 16 chips) 
 
</pre>
<!-- Author: Petra,Tony -->


<!-- Date: Wed Sep 19 11:26:59 2001 -->
<pre>&lt;br&gt; HV slow control monitoring, first floor: 
&lt;br&gt; The crate controller was replaced by other one; Rack 1RR06C; 
&lt;br&gt;</pre>
<!-- Author: Nikolay Luzhetskiy -->


<!-- Date: Wed Sep 19 13:53:55 2001 -->
<P> 
Status of p/n asymmetry and how we should proceed. 
<P> 
As you may know, we have made several more changes to the polarity bits 
for the test ladders so that we have tested all the combinations of 
READOUT ORDER and RAMPDIR bits. We conclude that it is the READOUT ORDER 
bit which is causing the reduced gain, or to be completely correct the 
gain is low when the READOUT ORDER checkbox is checked. 
<P> 
There are several things which we still need to do to track down why this 
is the case. First, it does not match Gino's results at the TStand, so we 
need to understand if bit mapping differs between the two. Second, we also 
need to understand why it changed between early sidet measurements and 
now. The leading hypothesis for that is a timing change in the FIB 
sequence. That will be tested by changing the sequence on a test 
stand--doing so on the full detector is too dangerous. These tests should 
provide an understanding of why the gain is low. 
<P> 
But, even before we completely understand why, I think we should change 
the full detector to the configuration which equalizes the gain. This has 
advantages for subsequent clustering studies. I think that the best way to 
do this is to change the java code which defines the meaning of the  
"N-side" button (i.e. p-side of the detector). 
<P> 
Currently that means, 
<BR>  CALDIR=1, PipeSel=0, ReadoutOrder=1, RampDir=0, CompDir=0 
<BR>(where 1=checked and 0=unchecked). 
<P> 
The new configuration would be 
<BR>  CALDIR=1, PipeSel=0, ReadoutOrder=0, RampDir=1, CompDir=1 
<P> 
Changing the meaning of this polarity button in the code seems better 
(e.g. less prone to error) than manually setting each chip in USER mode. 
<P> 
If you agree, I think that this should be done at the earliest possible 
time that the detector is stable and a calibration can be performed. Given 
the impact of such a change, it makes sense to test it beforehand and have 
independent verification. 
 
  
<!-- Author: David -->


<!-- Date: Wed Sep 19 14:10:27 2001 -->
<pre>INTERLOCK DISABLED/ENABLED MESSAGES. 
The GUI is reporting status of Interlock, as it is being sent via 
Smart Sockets from iFix. During the time, when one turns on/off 
Silicon power from iFix, this message with the current status of  
Interlock interferes with a message, commanding to change a  
power status of Silicon. The PS GUI gets all zeros and thinks, 
that Interlock is disabled. It takes a few minutes to turn off  
Silicon from iFix and at this time the GUI is reporting Disabled 
Interlock. 
      These "strange" things were happening during at least 6  
months.  I can remove these messages from the GUI, if it is too 
confusing. We always have an iFix window, reporting status of Interlock. 
</pre>
<!-- Author: Andrew -->


<!-- Date: Wed Sep 19 14:24:46 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><h1>Took tremendous doses to SVX</h1>  
 
This occurred during MCR TeV studies (aperture scans, done without warning to CDF!) 
<P> 
 The doses caused a warning alarm, but did not 
trip.  The dose rates were ~2 rads / s, in three 
separate incidents of ~10 s apiece.  The incidents 
occurred at 12:07:00, 12:39:20, and 13:00:40 .  
Peak rates reached 6 rad /s (the trip is at 10 rad / s). 
<P> 
 The integrated doses were 
<P> 
W Inner BLM 0.21 
<P> 
W Outer BLM 0.035 
<P> 
E Inner BLM 59.5 
<P> 
E Outer BLM 43.98 
<P> 
The main elog has an entry about this with a <a href= 
'/cgi/elog/elog.pl?nb=2001&action=view&page=684&frame=2&anchor=13:19:38'> 
acnet plot of the integrated dose </a>  
<P> 
 There has been exactly one serious incident since 
we began Run II, on Mar 9 at 0044.  The integrated 
dose in that incident was 2 rad.  When we did  
loss scans for the beam tilt studies, during which 
we really hammered the detector, the total shift 
integrated 0.2 rad.   
<P> 
<h3>50 rad on SVRAD is a factor of 25 worse than 
the next worst incident, and more than 200 times 
worse than a bad shift.</h3> 
<P> 
 The loss monitors during these times indicate that the 
radiation doses came from the antiproton beam.   
<P> 
 The SVRAD integrated dose was reset. 
</td></tr></td></table>
<!-- Author: ADF / Ricardo -->


<!-- Date: Wed Sep 19 15:28:23 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-181&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-181' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-180&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-180' width='300'></a></center>
<!-- Author: Saverio -->
<!-- Comment: Wed Sep 19 15;29;35 comment by...Sav -->
<pre>History plot of SB0W3. The behaviour was erratic since
bias on (yesterday) and may be trip was related to a flying wire.
First trip at 00:26:00, followed by 4 attempts to turn it on
at 00:31, 00:47, 01:01, 01:03 (09/18/2001)</pre>

<!-- Comment: Wed Sep 19 15;39;25 comment by...Saverio -->
<pre>The erratic behaviour, and in particular the increase of a factor of 2 between 14h and 20h00 looks not related to either beam
or temperature conditions.</pre>


<!-- Date: Wed Sep 19 21:11:32 2001 -->
<pre>Bill A and I were looking at the L2R situation tonight. 
 
We took out the fib containing B1WB and put it back in. 
 
We changed all silicon thresholds to 255 to reduce the data size. 
I left instructions with Bill to put them back to ISL 7 and SVX 
5. We plan to leave the silicon out tonight due to the aperture  
studies. 
</pre>
<!-- Author: Lester -->
<!-- Comment: Wed Sep 19 23;24;15 comment by...Bill A -->
I think I put the tresholds back to the right values, but it may be worthwhile for someone who really knows what s/he is doing to make sure it worked.

<!-- Date: Wed Sep 19 22:08:44 2001 -->
<pre>Silicon OFF for aperture scans</pre>
<!-- Author: ADF -->
<!-- Comment: Thu Sep 20 13;28;39 comment by...ADF -->
<table border=0><td><tr><td bgcolor=#e0e030>Last night had two SVRAD beam aborts!
There are detailed in the main
elog, they occurred at
<a href=
'/cgi/elog/elog.pl?nb=2001&action=view&page=685&frame=2&anchor=23:20:38'>
2320 </a> and 

<a href=
'/cgi/elog/elog.pl?nb=2001&action=view&page=686&frame=2&anchor=00:46:07'>
0046 </a> 


</td></tr></td></table>
<!-- Date: Thu Sep 20 10:32:22 2001 -->
<b>Silicon Controlled Access:</b> <ul> <li>Checked the enable line on SB4W9. It registered 4.3V 
on the ohm-meter. As a double check we powered on the PC via the front panel. It stayed on for a 
full 10s before we manually turned it back off. <BR> 
<b>Conclusion: problem is <i>not</i> with the enable line.</b> <li>Visually inspected the HV cable 
for SB1W3. No bent pins or other problems detected. Re-inserted into PS afterwards. Further 
diagnosis needed. <li>Inserted two L00 flavor PSs into LB1W4 and LB1W5. They were <b>not</b> 
cabled or load-box tested. </ul> 
<!-- Author: Napora and Foland -->


<!-- Date: Thu Sep 20 13:23:25 2001 -->
Had SVSWB rack trip (Inet crate temperature) and subsequent 
very high temps today, so requested access.  See 
<a href= 
'/cgi/elog/elog.pl?nb=2001&action=view&page=687&frame=2&anchor=13:16:04'> 
main shift elog </a> for more details.   
At least we did not drop the interlocks! 
<P> 
For the record, here is, from top to bottom, the 
order of cooling and power elements in the 
crate.  Flow is from bottom to top. 
 
<ul> 
<li> Heat Exchanger (HE) 
<li> CAEN PS 
<li> HE -> Outlet Temp Sensor 
<li> CAEN PS 
<li> HE -> Outlet Temp Sensor 
<li> FIB crate 
<li> Air filter -> Inlet Temp Sensor 
<li> Fan pack 
<li> VME rack 
<li>      
<li>        Power Transformer (under rack) 
</ul>
<!-- Author: ADF / herndon -->
<!-- Comment: Thu Sep 20 15;26;42 comment by...ADF -->
<pre>Worth noting: the inlet temperatures were 97-172, the
outlet was steady between 67 and 71; so the FIB is
not only a readout device, it's also a refrigerator!
</pre>


<!-- Date: Thu Sep 20 15:27:45 2001 -->
fib03 now <a href= 
'/cgi/elog/elog.pl?nb=2001&action=view&page=687&frame=2&anchor=15:27:14'> 
online</a>
<!-- Author: SCN -->


<!-- Date: Thu Sep 20 15:58:38 2001 -->
<pre>Silicon to SBY, and initialized, in 
preparation for next store.</pre>
<!-- Author: ADF -->


<!-- Date: Thu Sep 20 16:05:08 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-182&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-183' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-184&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-185' ></a></center>
<!-- Author: SCN -->
<!-- Comment: Thu Sep 20 16;12;02 comment by...SCN -->
<h4>Fib Abort Testing</h4>
Since it is so popular lately, I did some testing of
what happens when the Src issues an abort during Readout.
Method was to simply stop the data from a DEM in 
the Fib output Fifo (before the GLINK) by disabling the glinks, and then read out the output fifo (including the valid bit) and scanning the event for the Abort EOR (0xC8C8).  Sometimes (picture on
left) the fib inserts 0xc1c4c4c4 (in red box) into the output fifo between the 0xc8c8 (c4c4c4c4) EOR and the next event (e2a0...) and sometimes (picture on left) not (red line is event border).  Note this is also a "reformatter error" even when we do L2A sometimes.  I would like to know where this extra stuff
comes from, though it is unclear that this is the smoking gun.
Need to look deeper into the Fib for that.

<!-- Comment: Thu Sep 20 16;15;26 comment by...SCN -->
By the way, this is using the Fib Firmware glinkv2.jam
which is different from standard:  Ken's mail:<pre>
Hi Steve,
   I have placed two new versions on our ftp server for you to
try.  GlinkV1 is the same as GlinkV but with more states in the reset
logic.   GlinkV2 is GlinkV1 plus one more extra read (two total) after
the fifo is empty.</pre>



<!-- Date: Thu Sep 20 16:17:02 2001 -->
<pre> Silicon to ON to take data.</pre>
<!-- Author: ADF -->


<!-- Date: Thu Sep 20 16:39:42 2001 -->
<pre>Power cycled and reinitialized SB3W6 L2 to 
exorcise reformatter errors.  </pre>
<!-- Author: ADF -->


<!-- Date: Thu Sep 20 17:55:01 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-186&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-186  width='300' align='top'></td><td>I measured this I-V curve this morning on SB3W7L0. It looks like a pinhole has developed.  The trip happened within a few minutes from a flying wire: Channel 962 tripped on overcurrent Sun Sep 16 06:26:00 2001 * * May be we need to adjust the power supply to provide negative voltage, this may increase the noise but the ladder  may still see some signal.</a></td></tr></table>
<!-- Author: Saverio -->
<!-- Comment: Fri Sep 21 15;06;09 comment by...ADF -->
<pre>Flying wires that night flew ~13 after the hour.</pre>
<!-- Comment: Wed Nov 14 14;12;27 comment by...herndon -->
<pre>caption is wrong!   this should be layer 2</pre>
<!-- Date: Fri Sep 21 09:27:30 2001 -->
<pre>I started a spy-spy cron job that automatically  
restarts the caen-spy program if it is not running. 
</pre>
<!-- Author: Saverio -->


<!-- Date: Fri Sep 21 12:07:58 2001 -->
<pre>Updated Firmware in b0svx00 Slot 9 (SB0W2 SB0W3) 
to glinkv2.jam.  Looks ok</pre>
<!-- Author: SCN -->
<!-- Comment: Tue Sep 25 09;41;43 comment by...SCN -->
This seems to have made the situation slightly worse (but not
horribly worse) rather than slightly better.  I am
regressing back to glinkv1.jam, see if that one is better.
<!-- Date: Fri Sep 21 14:51:24 2001 -->
<pre>Removed B4W1 L4 from HWDB and CAENVOLTS due to 
reformatter errors.</pre>
<!-- Author: ADF / SCN -->



<!-- Date: Fri Sep 21 17:12:43 2001 -->
<pre>Silicon ON to take data!</pre>
<!-- Author: ADF -->