<!-- Title: 13:56:42  Tue Dec 25 2001 -->
<!-- Crewchief: Santa Claus -->
<!-- Op1: the elves -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Christmas Day</pre>


<!-- Date: Tue Dec 25 13:58:11 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Be sure you read the end of last file for what Steve 
dir this AM. 
 
  I just reloaded powersets.dat and CAENvolts.dat to complete 
Steve's work.</pre></td></tr></td></table>
<!-- Author: jean -->


<!-- Date: Tue Dec 25 14:59:20 2001 -->
<pre>Dear Santa, 
 
For a change, you deserve a gift. 
 
Unmarked pinks squares on IMON: 
 
			latest	nom	   
			(mA)	(mA)	 
 
AVDD	SB1W11L2	770	850	 13:55:34  
AVDD	SB3W0L4		1010	1115	 13:55:42  
AVDD	SB4W9L3		780	850	 13:55:59  
AVDD	SB5W5L4		985	1060	 13:56:07  
AVDD	SB4W9L4		930	1155	 13:56:13  
DVDD	SB3W3L1		212	70	 13:56:19  
DVDD	SB3W8L4		170	140	 13:56:42  
 
BIAS	SB1W10L4	343	241	 13:57:32 (known) 
BIAS	SB3W11L2	69	177	 13:57:35 (known) turned pink again 
BIAS	SB4W4L2		798	903	 13:57:39 (known) 
BIAS	SB4W9L4		256	74	 13:57:45 (known)  
BIAS	SB5W5L2		110	312	 13:57:49 (known) turned pink again 
BIAS	SB5W6L4		144	304	 13:57:52 (known) turned pink again 
BIAS	IB0W0L0		33	151	 13:58:40 (known) turned pink again 
 
--your faithful elves</pre>
<!-- Author: Hung-Chung -->


<!-- Date: Tue Dec 25 22:16:40 2001 -->
<pre>MERRY CHRISTMAS!  Tonight there was a main circuit breaker trip 
that took down silicon cooling along with other CDF support 
systems.  Ace hit the rack crash button on advice from Andy F. 
Cryo guys got cooling re-established and racks back on.  I 
fine-tuned the ISL valve positions to their new defaults 
(CCW1 -&gt; 85%, CCW3 -&gt; 90%).  SVXINTER rebooted and GUI restarted. 
However, we will be leaving silicon OFF until after this breaker 
is replaced tomorrow (the replacement will necessitate another 
temporary interruption in cooling).  All 5V enables set to 
"INACTIVE" in iFix.  See CDF e-log for more info. 
 
</pre>
<!-- Author: Andy H. -->
<!-- Comment: Tue Dec 25 22;36;35 comment by...ADF -->
<pre>Asked ace to hit crash button, as GUI was frozen and both
fog horn alarms and sono alarms were sounding.

Silicon OFF until ready to turn it on and leave it on,
i.e. after Roser's crew fixes 90 Amp breaker (short
job in the morning).</pre>


<!-- Date: Wed Dec 26 10:54:12 2001 -->
<pre>Breaker has been fixed.  Andy F. and Steve Nahn are 
doing various tests and development with the system. 
Not everything is up yet.</pre>
<!-- Author: jean -->


<!-- Date: Wed Dec 26 14:36:48 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>DIAGNOSTIC of 26-12-2001  
 ========================  
 
 I will fron now onwards concentrate on single Bulkheads and   
 will give an overview of their problems.   
 
 I will begin with Bulkhead 2.   
 
 ---------------------------------------  
 
 SB2W0L0:  
          SVXMON: First Problem seen in SVXMON is at RUN 135060 0.3% level  
                  EOR not Found,  
                  Invalid EOR  
                  Invalid Word  
                  Wrong Chip Count  
                  Strip Out of Order  
                  Duplicate Channel   (1 time seen)  
          DEM:    bad events 0.5-1%, sometimes 2-11%  
                  Chip 83: most of the Channel ID Problems are caused  
                           by bit 5 high.  
                           some problems are caused by bit7   high  
                           there are also cases where  bit5,7 high  
 
                           and one sees also this:  
 
                           Channel ID 5a-&gt;ff: bit0,2,5,7 high  
 
                           0007 0105 0202 fcf3 ff07 5ef3 5f04  
                                          ^^   ^^  
                                   bit5 high   bit5+bit1 high  
 
                           Channel ID 5d-&gt;fd: bit2,5,7 high  
                           Channel ID 5b-&gt;ff: bit2,5,7 high  
                           Channel ID 5a-&gt;fe: bit2,5,7 high  
                           Channel ID 5c-&gt;fe: bit1,5,7 high  
 
                           0007 0105 0202 fcf3 ff07 5ef3 5f04  
                                          ^^   ^^  
                                   bit5 high   bit5+bit1 high  
 
                           0002 59f3 5a07 fbf3 fc05 5df3  
                                          ^^   ^^  
                                     bit 5high bit5 high  
 
                           0007 01f3 5a03 ff05 fcf3 5d06 5e01  
                                          ^^   ^^  
                                 bit2,5,7high  bit 6 high  
 
                  Chip 82: bit 4 and 5 high ==&gt; Wrong Channel ID  
 
        general comment:   RUNS with a bad event level of 2-11% do have  
                           in addition to the bit errors "00 f3" errors!!!!:  
                           ar020fce.0001test_e200; 135118  
                           ar021091.0001test_e200; 135313  
                           ar0210b8.0001test_e200; 135352  
                           ar0210bb.0001test_e200; 135355  
                           ar0210bb.000atest_e200; 135355  
 
 
 
 RUN:135628 - ar0211cc.0001_e200  
 Event Number: 199004  
 10500d0b 04104100 0000 0000 0000 0000 00000000 00000000 08160816 00000000  
 e2000000 e3360000 0000 6a0c e0004afc 8313 0006 0107 0201 1302 1406 150c 160c  
 .....  
 4401 4507 4604 7ff3 c1c10000  
 e2004afc 8313 0003 16f3 1706 18f3 1a01 1b06 1cf3 1d04  
 
 bunch crossing 00,backend state 00, switches to layer SB3W3L6 also with  
 bunch crossing 00,backend state 00, switches to layer SB0W0L0 with  
 bunch crossing 4a,backend state fc, after reading out this layer,  
 switches to SB2W0L0, bunch   crossing 4a, backend state fc  
 
                Silimon:  NO Entries for this layer  
 
 
</pre></td></tr></td></table>
<!-- Author: Cigdem -->


<!-- Date: Wed Dec 26 17:11:38 2001 -->
<h4>Software Progress</h4> 
I spent most of today <ol> 
<li> Answering Andy's questions with regards to the high speed test 
<li> Waiting for the crash button push recovery 
<li> Testing new code for automagic downloads of the 
fib crates, all fibs and all hdis which are not  
MASKED in the hdwdb.  This works, but has not been 
applied since it comes with some other changes I need 
to work on a little 
</ol> 
 
Still to do: 
<ol> 
<li> Run entire system on new code, make sure it all works 
<li> Upgrade Fib and Vrb firmware to latest and greatest 
<li> Fix X mode which has an not yet diagnosed vulnerability to 
corrupt data 
</li> 
 
Back tomorrow for the access.
<!-- Author: SCN -->
<!-- Comment: Thu Dec 27 08;34;13 comment by...   -->
</ol>
<!-- Date: Wed Dec 26 19:18:22 2001 -->
<pre> imon pink        volt   latest moninal 
 B5W10L4 SVX AVDD 7.93   1035   1105   19:15:21</pre>
<!-- Author: jong-young chung -->


<!-- Date: Wed Dec 26 22:30:00 2001 -->
<pre>Test for MRB</pre>
<!-- Author: ADF -->


<!-- Date: Thu Dec 27 00:37:46 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>SPARSE MODE ERRORS 
------------------- 
 
I was able to reproduce the errors reported by SvxMon and DEM  
on SB4W3L4 and SB5W10L4 in teststand mode ONLY WHEN RUNNING IN  
DPS/NN mode. HST (only works readall) and SvxDAQ readall mode no  
errors are detected. The data files from svxdaq are  
daq/svx/ne/laser84.svx and laser87.svx respectively. 
These layers represent 2 classes of error  
 
1) High channel numbers in the middle of readout stream - the 
"7f" problem 
 
2) Duplicate channel numbers. 
 
I created a new set of sequencies CPC_122601.seq where I  
stretched the beginningof readout to give TN hi in begin RO/end  
Digi -&gt; 1st BECLK in RO &gt;=800ns and so also increase fifo  
collapse time which was already aprox 1microsec. 
This number varies by 1-2 clocks due to fib processing time. 
 
New sequencies don't help fix the error.  
 
I suspect these 2 classes of problem are related to problems 
collapsing the fifo. NEED CHIP EXPERT INPUT!.  
 
PLAN: Switch some of the wedges with these classes of error into 
readall DPS on mode and see if errors disappear when integrated.</pre></td></tr></td></table>
<!-- Author: Mad Mary -->


<!-- Date: Thu Dec 27 00:40:05 2001 -->
<pre>SI Biased and integrated with CDF 1st run of the owl shift. 
 
SB3W0L0 and SB1W11L0 DVDD currents only went down  
to inited values after coldstart. </pre>
<!-- Author: Mad Mary. -->


<!-- Date: Thu Dec 27 01:01:51 2001 -->
<pre>imon pink     volt  latest  moninal  time 
SB3W8L4 DVDD  5.61  170     140      00:32:26 
              5.61  170     140      00:34:29 
              5.61  170     140      00:38:20 
              5.61  195     140      00:39:22 
              5.61  170     140      00:42:31 
              5.61  200     140      00:45:20 
 
Paged Mary Bishai. She said keep eyes on it and if it goes 
higher than 200, page her again.</pre>
<!-- Author: Yamashita -->


<!-- Date: Thu Dec 27 01:10:53 2001 -->
<pre>imon pink          volt  latest  moninal  time  
     SB3W8L4 DVDD  5.61  175     140      01:01:14  
                   5.61  200     140      01:03:42  
                   5.61  170     140      01:04:46 
     SB3W8L2 DVDD  5.53  160     120      01:06:01</pre>
<!-- Author: Yamashita -->


<!-- Date: Thu Dec 27 01:33:04 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>B2W0L1:  
          SVXMON: First Problem seen in SVXMON is at RUN 135073 0.02% level  
                  But Problems increased since then to an level of 1%  
                  EOR Not Found  
                  Strip out of Order  
                  Wrong Chip Count  
                  Bad ADC Value (if it happens than on a level of 15-60%)  
 
          DEM:    bad events 1-5%, sometimes 15-25%  
                  c2c2,d0c2 c2c40000, d0c2c2c4  ,c2c4  
 
                  Chip 83, Channel ID 6b-&gt;63:  bit3 high  
 
                  Datastream gets often corrupted, can't pinned to a certain  
                  bit or error:\  
 
                  ..... 7116 7207 7304 7502 760e 7704 7815 1e53 1852 0357 0756  
                                                           ^^   ^^   ^^  
                   0054 0055 0ac3 0ff3 0401 0303 0402 0c07 0506 0a04 0505 040f  
                   ^^   ^^  
                   040e 000a 021f 051e 001c ......  
 
          general comment: This Layer may gave OBDV problems?  
 
          Silimon: No entries for this layer  
 
 
 SB2W0L2:  
          SVXMON: First Problem seen in SVXMON is at RUN 135191 0.2% level  
                  Strip Out of Order 1-41%  
                  Wrong Chip Count 0.3-20%  
                  Pipeline Out of Sync 5-50% C4-C9  
                  Bad ADC Value 5%  
                  Duplicate Channel 70%-100%  
                  Invalid Cell Id 90%  
                  Stuck Bit | 1 | Cell id bit 0 gets stuck at 1  
                  with probability 0.290698 %-30%  
 
          DEM:    This is a really BAD LAYER.  
                  It has since RUN 135352 in all RUNs bad events on a level  
                  1%-98%, the last runs it had a level of bad events of ~3%  
 
                  -d0c2, c2c40000  
 
                  -CAP ID 01-&gt;18 bit3,4 high,bit0 low  
                   CAP ID 0e-&gt;12 bit4 high,bit2,3 low  
                   CAP ID 19-&gt;09 bit4 low  
                   CAP ID 17-&gt;21 bit5 high,bit4,1,2 low  
                   CAP ID 2b-&gt;2d bit2 high,bit1 low  
                   ChannelID 27-&gt;07 bit5 low  
                   ChannelID 28-&gt;08 bit5 low  
 
                  -Channel ID's are not always increasing:  
                   7006 71f3 76f3 7707 78f3 0808 0906 0a05 0c02 0d06 ....  
                                            ^^   ^^   ^^  
                   4601 4706 48f3 6ff3 7006 71f3 7403 7505 76f3 5008 51f3 5203  
                                                                ^^   ^^   ^^  
                   7001 7107 72f3 1a09 1b07 1f08 1d09 1e0b 1f08  
                                  ^^   ^^   ^^   ^^   ^^   ^^  
 
                  * Calibration/test RUN(full readout mode):  
 
                    - d0c2c2c4 , d0c1c1c4  
 
                    -Channel ID 03-&gt;00 bit0,1 low  
                     Channel ID 56-&gt;02 bit2,4,6 low  
                     Channel ID 72-&gt;00 bit1,4,5,6low  
 
                     Chip ID    a3-&gt;00 bit0,1,5,7 low  
                     CAP  ID    15-&gt;06 bit0,4 low bit1 high  
                     CAP  ID    0c-&gt;03 bit2,3 low,bit1 high  
                     CAP  ID    01-&gt;0c bit2,3 high  
 
                    -Than we have also the case, that a lot of channel id's are  
                     set to 00 and after a while channel ID  
                     and ADC entries are "00 00"  
 
                    -6904 6a00 6b00 6c00 6dd0 c2c2  
                                             ^  
                         shouldn't be here "70xx 71xx ... 7fxx" ?? in the  
                         full readout mode???  
 
                    -In some events the datastream just stops after the chip  
                     id is read,like for example here:  
                      .... 7d00 7e00 7f02 a20a that's it.  
                     or  
                      .... 7b04 7c00 7d09 7e00 7f00 a204 that's it.  
 
                    -I see here also that the Channel numbers are not  
                     increasing always like for example in this case  
                     for chip a4:  
 
                     a419 0df3 0e1c 0f0d 10f3 17f3 1809 19f3 26f3  
                     2707 2808 29f3 2ff3 3007 31f3 ....  
                     7417 7507 7611 770b 780f 7916 7a10 7b15  
                     7c11 7d09 7e0b 7ff3 45f3 460e 470b 48f3 490c....  
                                         ^^   ^^   ^^   ^^   ^^  
                     I would expect in the full read out mode, that  
                     the channel ID should start from 00 and that  
                     they increase like 00,01,02...0f,10,11,....  
                     What I see here is, that the first channel ID for this  
                     CHIP is ad, than it is skipping the Channels 11-16 and  
                     20-25. And as it reaches 7f, it start to parse  
                     40's.  
 
                    -I also see examples, were same channels are missing,  
                     but the datastream does goes back to smaller  
                     channel ID's.  
 
 SB2W0L3:  
          SVXMON: First Problem seen in SVXMON is at RUN 135143 0.02% level  
                  A quite layer. I see only 4 RUNS with error messages in  
                  SVXMON.  
                  EOR not found  
                  Strip out of order  
                  Wrong Chip Count  
 
          DEM:    Also here I see only a few RUNS with bad events.  
                  The bad event level is 0.2-6%  
                  Since RUN 135362 no error messages.  
                  (Problems in RUN 135666 are due to turned off Silicon)  
 
                  -d0c2c2,c2c2  
 
                  -a lot of channels have several bits low, causing  
                   very small channels Id's or "00".  
 
                  -Channel ID 31-&gt;0c bit0,4,5low ,bit2,3high  
                   channel ID 48-&gt;00 all bits low  
 
 SB2W0L4:  
          SVXMON: First Problem seen in SVXMON is at RUN 135230 17% level  
                  Strip Out of order  
                  This is a quite layer. I only saw one run wiht  
                  eRrors in SVXMON.  
 
          DEM:    Just a few RUNS wiht bad events on a level of 0.1-18%  
                  Since 135230 no errors.  
                 (Problems in RUN 135666 are due to turned off Silicon)  
 
                  -CHIP 88, sets 2 randomly choosen Channels somewhere  
                   in the datastream to always  
                   the same pattern: "00f3 a6xx":  
                   ...7601 770a 7801 00f3 a620 15f3 1605 17f3...  
                                     ^^^^^^^^^  
                                     ^^^^a single "00 f3"  
                  -Sometimes CHIP 88 parses only "00 f3".  
 
 
</pre></td></tr></td></table>
<!-- Author: Cigdem -->
<!-- Comment: Thu Dec 27 01;34;10 comment by...cigdem -->
<pre>DEM = David's Error Monitor</pre>


<!-- Date: Thu Dec 27 01:35:42 2001 -->
<pre>imon pink       volt  latest  moninal  time   
  SB3W8L2  DVDD  5.53  162    120      01:27:08 
  SB3W3L1  DVDD  5.43  228    70       01:31:43 
  SB0W10L4 DVDD  5.62  135    105      01:32:44</pre>
<!-- Author: Yamashita -->


<!-- Date: Thu Dec 27 01:41:24 2001 -->
<pre>imon pink       volt  latest  moninal  time    
 SB0W10L4 DVDD  5.62  145     105      01:39:16</pre>
<!-- Author: Yamashita -->


<!-- Date: Thu Dec 27 02:14:59 2001 -->
<pre>imon pink       volt  latest  moninal  time     
 SB0W10L4 DVDD  5.62  150     105      02:11:06</pre>
<!-- Author: Yamashita -->


<!-- Date: Thu Dec 27 02:46:22 2001 -->
<pre>imon pink      volt  latest  moninal  time      
 SB3W8L2 DVDD  5.53  150     120      02:42:41 
 SB3W8L3 DVDD  5.51  100     65       02:43:21</pre>
<!-- Author: Yamashita -->


<!-- Date: Thu Dec 27 02:53:51 2001 -->
<pre>imon pink      volt  latest  moninal  time       
 SB3W8L3 DVDD  5.51  105     65       02:50:48</pre>
<!-- Author: Yamashita -->


<!-- Date: Thu Dec 27 03:43:10 2001 -->
<pre>imon pink       volt  latest  moninal  time      
 SB0W10L4 DVDD  5.62  135     105      03:40:55</pre>
<!-- Author: Yamashita -->


<!-- Date: Thu Dec 27 03:57:01 2001 -->
<pre>imon pink      volt  latest  moninal  time       
 SB3W8L2 DVDD  5.52  150     120      03:53:55</pre>
<!-- Author: Yamashita -->


<!-- Date: Thu Dec 27 04:13:22 2001 -->
<pre>imon pink       volt  latest  moninal  time        
 SB3W8L3  DVDD  5.51  95      65       04:10:31 
 SB0W10L4 DVDD  5.62  125     105      04:08:53</pre>
<!-- Author: Yamashita -->


<!-- Date: Thu Dec 27 04:16:59 2001 -->
<pre>imon pink      volt  latest  moninal  time        
 SB2W5L4 DVDD  5.76  160     130      04:13:49 
 SB4W5L2 DVDD  5.51  125     95       04:15:44</pre>
<!-- Author: Yamashita -->


<!-- Date: Thu Dec 27 04:22:41 2001 -->
</ul>
<!-- Author: .. -->


<!-- Date: Thu Dec 27 04:23:31 2001 -->
<pre>imon pink      volt  latest  moninal  time        
 SB3W8L2 DVDD  5.53  150     120      04:19:56</pre>
<!-- Author: Yamashita -->


<!-- Date: Thu Dec 27 04:36:01 2001 -->
<pre>imon pink       volt  latest  moninal  time         
 SB0W6L4  DVDD  5.81  135     105      04:30:29 
 SB0W10L4 DVDD  5.62  145     105      04:33:04</pre>
<!-- Author: Yamashita -->


<!-- Date: Thu Dec 27 04:58:15 2001 -->
<pre>imon pink       volt  latest  moninal  time       
 SB0W10L4 DVDD  5.62  145     105      04:55:47</pre>
<!-- Author: Yamashita -->


<!-- Date: Thu Dec 27 05:12:33 2001 -->
<pre>imon pink       volt  latest  moninal  time       
 SB0W10L4 DVDD  5.62  150     105      05:02:26</pre>
<!-- Author: Yamashita -->


<!-- Date: Thu Dec 27 05:46:09 2001 -->
<pre>imon pink       volt  latest  moninal  time        
 SB0W10L4 DVDD  5.62  135     105      05:45:10</pre>
<!-- Author: Yamashita -->


<!-- Date: Thu Dec 27 05:57:20 2001 -->
<pre>imon pink      volt  latest  moninal  time         
 SB2W3L1 DVDD  5.43  317     80       05:52:57</pre>
<!-- Author: Yamashita -->


<!-- Date: Thu Dec 27 06:08:36 2001 -->
<pre>We set the silicon to standby for tev study. After that, 
SB2W3L1 DVDD become pink just after unmarking. Paged Marry. 
She said leave it and see if it recover when we start next 
cold start.</pre>
<!-- Author: Yamashita -->


<!-- Date: Thu Dec 27 06:49:54 2001 -->
<pre>imon pink       volt  latest  moninal  time        
 SB0W10L4 DVDD  5.62  145     105      06:40:14 
 SB3W8L2  DVDD  5.53  160     120      06:46:37</pre>
<!-- Author: Yamashita -->


<!-- Date: Thu Dec 27 06:59:48 2001 -->
<pre>After the cold start, unmarked SB2W3L1 DVDD. Its sabely green now. 
Another Imon pink 
                volt  latest  moninal  time         
 SB0W10L4 DVDD  5.73  200     170      06:52:43</pre>
<!-- Author: Yamashita -->


<!-- Date: Thu Dec 27 07:27:30 2001 -->
<pre>imon pink       volt  latest  moninal  time         
 SB5W0L4  DVDD  5.7   175     145      07:19:46  
 SB2W9L3  DVDD  5.5  160      120      07:21:28 
 SB0W10L4 DVDD  5.62 140      105      07:21:28</pre>
<!-- Author: Yamashita -->



<!-- Date: Thu Dec 27 10:16:01 2001 -->
<p>Removed the power supply in LB0W2 on controlled access and updated the CAEN map.  There are no longer any L00-flavor power supplies in the collision hall.
<!-- Author: Napora, Nahn, and Foland -->


<!-- Date: Thu Dec 27 10:58:34 2001 -->
<pre>FIB's on controlled access today 
 
Swapped out FIB for SB4W0/1; both wedges worked perfectly 
in SVXDAQ, 300 events, afterwards. 
 
Swapped out FIB for SB3W4/5; SB3W5 worked perfectly in  
SVXDAQ, but SB3W4 does not readback anything whatsoever 
for the init, and then does not read out anything in  
data-taking.  Swapped FIB command cables and remapped 
HSI &lt;-&gt; DDR; problem followed SB3W4.  So problem with 
SB3W4 is upstream of the FTM. 
 
Steve will enter serial numbers of the FIBs and what 
needs to be checked for the ones that came out.</pre>
<!-- Author: ADF / SCN -->
<!-- Comment: Thu Dec 27 11;26;58 comment by...SCN -->
<ul>
<li> SB3W4/5- swapped out because of <a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=85&frame=2&anchor=11:46:44'>
this </a> problem, though note that SB3W4 was off in hdwdb before
this.  Swapped Out: FIB 137 560622.  Swapped In: FIB 152 550968.
I will check in the test crate and see if the Glink Synch problem
persists.
<li> SB4W0/1 - swapped out because of <a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=85&frame=2&anchor=18:27:48'>
this</a> problem, which was noted way back in May but this
Fib snuck back into the system.  Fib Out: 129 560614  Fib In: 151
550969.  This Fib should go back to PREP and get checked out,
also troubleshot in DAQ3 since it has trouble initing ladders.
</ul>
Note that both 151 and 152 were swapped in and out of 
crates during the light level bonanza.<FONT COLOR=FF0000>  We <B>think</B> that
these were just done to exonerate the fibs, that is, nothing
is actually wrong with these guys, but our records are too
shoddy to be assured of this.  Anyone who swaps a VME board
without recording why from here on in will be shot.  No more 
entries like  <a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=72&frame=2&anchor=19:17:30'>
this</a> where it says that both of the boards I just swapped in
were swapped out but with no indication as to why.  Also, 
list VME hardware by both Serial Number and PREP ID, so that
they are easier to search for, and you can crosscheck for
typos.</FONT>
 
 
<!-- Comment: Thu Dec 27 15;43;56 comment by...SCN -->
I put the default sequences (CPC_120301a.seq) in these two
fibs.  Looks from the checksum like they had the 092501 
sequences in them.
<!-- Date: Thu Dec 27 11:22:29 2001 -->
<P> 
Beginning on 12/23, IB5W5L1 went from no errors to 100% errors. 
I poked into the data a bit and it all seems consistent with a bit0 low problem. 
<P> 
One odd feature is that during one run, the problem completely went away all of a sudden. It stayed fine for about 5 minutes and then slowly returned. 
The details are <A HREF="http://ncdf17.fnal.gov/cgi-bin/lgbk?user=stuart&ent=14113"> 
here</A>.  
<P>  
<!-- Author: David -->
<!-- Comment: Thu Dec 27 14;08;19 comment by...David -->
I looked at data from this morning (run 135738). The problem is now gone. Were the FIB crates power cycled because of the cooling problem yesterday? Maybe this is a flaky RX connection.

<!-- Date: Thu Dec 27 12:57:05 2001 -->
<pre> 
 
Diagnostic of SB2w1:  
====================  
 
 
SB2W1L0:  
         SVXMON: First Problem seen in SVXMON is at RUN 135117 1.5% level  
                 EOR not found  
                 Strip out of Order  
                 Wrong Chip Count  
                 I found 7 RUNS with error messages in SVXMON  
 
         DEM:    Just a few RUNS with bad events, on a level of 0.1-47%  
                 Since RUN 135362 no more bad events  
                 (Problems in RUN 135666 are due to turned off Silicon)  
 
                 -CHIP a1,82,83 are parsing a lot of "00 f3"'s.  
 
SB2W1L1:  
         SVXMON: First Problem seen in SVXMON is at RUN 135355 3% level  
                 Only one RUN found with ERRor messages in SVXMON.  
                 Strip Out of order  
 
         DEM:    Bad events level is 0.1%-6%, only one calibration run 100%.  
                 This layer is usually quite. During  
                 135181-135232,135451-135453 we had  
                 constantly in each RUn bad events.  
                 Since 135614 no bad events reported.  
 
                 -d0c2c4,00d0 c2c20000,d0 c2c20000,  
                 -datastream is messed up. I see frequently Channel and Chip  
                  ID "00" or some other low values.  
                 -see in some events only "00 f3" entries.  
 
                 * Calibration RUN  
                   -Here I see, that the first Chip ID is set to "ff"  
                   -d0c2c2c4,c2c40000  
 
 
SB2W1L2:  
         SVXMON: First Problem seen in SVXMON is at RUN 135115 &lt;0.05%  
                 EOR not Found  
                 Strip outof order 0.1%-3  
                 Wrong Chip count 0.1%-35%  
                 C6-C9 Pipeline Out of Sync 26%-100%  
                 Stuck Bit Cell id bit 0 gets stuck at 1  
                 with probability 0.39604 %  
                 Stuck Bit | 2 | Cell id bit 3 gets stuck at 0  
                 with probability 20 %  
                 Stuck Cell Id | 1 | Pipeline cell id is stuck at 128  
 
         DEM:    Problamatic Layer, I see a lot of runs (~60%) with  
                 bad events on a level of 3-96%.  
                 Since run 135471 no errors.  
 
                 -Cap ID's are wrong from Chip a3 or a2 onwards.  
                  Cap ID 15-&gt;23 bit1,5high bit2,4 low  
                  Cap Id 1d-&gt;15 bit3 high  
                  Cap Id 0d-&gt;1d bit4 high  
                  Cap ID 15-&gt;0d bit3 high, bit4 low  
 
                 -5d0c2 c4c40000,d0 d0c2c2c4,d0c1c1c40000  
 
                 -Channel ID wrong  
                  Channel ID 7d-&gt;04 bit0,3,4,5,6 low  
 
                 -Channel Id's are not increasing always  
                  7bf3 7c0c 7d0a 7e12 7f08 1a06 1b07 1c04  
                                           ^^   ^^   ^^  
                  7cf3 7d23 7ef3 7f42 a012 00f3 0163  
                                      ^^   ^^^^ ^^  
                                           ^^^^single "00 f3"  
 
                 -Some events do have only or a lot of "00 f3" entries.  
 
                 * Calibration RUN (full readout mode)  
 
                   -Cap ID's wrong from chip a3 onwards  
                    CAp ID 0c-&gt;03 bit0,1high bit2,3low  
                    Cap ID 24-&gt;01 bit0high bit2,5low  
                   -7e00c2c2  
 
SB2W1L3:  
         SVXMON: First Problem seen in SVXMON is at RUN 135060 22%  
                 Duplicate Channel   &lt;0.1%  
                 EOR not Found   22%  
                 Strip Out of Order 10-100%  
                 Stuck Bit | 1 | Cell id bit 0 gets stuck  
                 at 1 with probability 28.5714 %  
                 Nearly alls RUN after Problems start are buggy!  
         DEM:    A lot of RUNS do have bad events on a level of 1-55%.  
 
                 -Channel ID wrong in chip a3,  
                  most of the problems are caused by bit 5 low.  
 
                  Channel ID 29-&gt;0f bit5 low, bit1,2 high  
                  Channel ID 24-&gt;04 bit5 low  
                  Channel ID 72-&gt;52 bit5 low  
                  Channel ID 35-&gt;18 bit0,2,5 low, bit3 high  
                  Channel ID 60-&gt;20 bit6 low  
 
                 -d0d0c1c1c4  
 
SB2W1L4:  
         SVXMON: First Problem seen in SVXMON is at RUN 135060 0.3%  
                 EOR not found  
                 Invalid EOR  
                 Invalid Word  
                 Chip Side Error  
                 c0 Bad ADC value  
                 C1 Pipeline Out of Sync  
                 stuck bit Cell id bit 7 gets stuck at 1 with  
                 probability 2.15736 %  
 
         DEM:    A Lof of RUNS do have bad events on a level of 0.1-10%  
                 Channel ID in chip 8d wrong,  
                 Channel ID 60-&gt;e0 bit 7 high  
 
                 * Calibration RUN  
                   -Cap ID wrong from Chip a6 onwards  
                    Cap ID 03-&gt;2c bit2,3,5 high,bit0,1 low  
 
 
</pre>
<!-- Author: Hexa Cigdem  -->


<!-- Date: Thu Dec 27 13:46:48 2001 -->
Took advantage of system trip yesterday to run 
high-speed tests on most of the ladders that 
Cigdem has identified with <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=85&frame=2&anchor=23:27:10'> 
high rate (>1%) error rates </a>.  
Tested those in fib02, fib04, fib06.  Results for 100k events: 
<p> 
<ul> 
<li> Fib02: 10 identified problem ladders; 6 test PERFECT in HST 
  <ul> 
  <li> SB1W4 L0 had already been masked off 
  <li> SB0W9 L4 shows a likely FIB firmware problem 
  <li> SB1W5 L1 shows <0.1% strip 72 -> strip 52 
  <li> SB2W7 L4 shows bit 1 high 100% 
  </ul> 
<li> Fib04: 3 identified problem ladders; 3 test PERFECT in HST 
<li> Fib06: 4 identified problem ladders; 4 test PERFECT in HST 
</ul>  
<!-- Author: ADF -->


<!-- Date: Thu Dec 27 13:47:34 2001 -->
<pre>Ran high-speed tests on SB4W0, SB4W1, and SB3W4.  SB4W1 L4 
is not perfect; all else are.  Add rest into HWDB.</pre>
<!-- Author: ADF -->




<!-- Date: Thu Dec 27 16:01:05 2001 -->
<pre>Diagnostic of SB2W2 
=================== 
 
This is a quite layer. Has only a few problematic Runs.  
 
SB2W2L0: 
        SVXMON: Problem seen in SVXMON only in RUN 135351 0.5% 
                Strip Out of Order 
        DEM:    NO ERRors since RUN 135355 
                Before this RUN I see only a few runs with bad events on 
                a 0.1-5% level 
 
                -data stream of chip 82 
                 contains after a while "00 f3" entries. 
 
                 Some events to start imidiataly with "00 f3" entries 
                -In some events Chip ID's are messed up from the first Chip 
                 onwards. 
                 The datastreams switches without parsing any chip channels 
                 to another layer: 
                 e2200000 e4220000 e4fc0000 e6740000 e7020000...... 
                          ^^^^^^^^ 
 
                 e2200000 e3100000 e51c0000 
                          ^^^^^^^^ 
 
 
SB2W2L1: 
        SVXMON: Problem only seen in SVXMON is in RUN 135355 2% 
                Strip Out of Order 
        DEM:    Two runs with bad events seen on a level of 2.2and7% 
                (Problems in RUN 135666, because silicon was off) 
 
                -Chip and Channel ID's are often 00 
 
SB2W2L2: 
        SVXMON: First Problem in SVXMON starts at RUN 135279 0.5% 
                Strip Out of Order 
                only in very few RUNs problems, 
                Since RUN 135355 no problems 
        DEM:    4 runs with bad events on a level of 0.1-16% 
 
                -Channel ID wrong in Chip a3,88 
                 Channel ID 61-&gt;41 bit5 low 
                 Channel ID 1d-&gt;0d bit4 low 
 
                -I see events with "00 f3" entries. 
                -d0c2 c2c40000 
SB2W2L3: 
        SVXMON: First Problem in SVXMON starts at RUN 135164 0.1% 
                Strip Out of Order 
                C3,C9 BAD ADC Values 0.5-100% 
                No errors since RUN 135498 
        DEM:    One RUN with problems found on a 0.1% level 
 
                Channel ID wrong, because bit5 low. 
 
 
SB2W2L4: 
        SVXMON: First roblem in SVXMON starts at RUN 135279 2% 
                BAD AdC values 
                Since RUN 135500, no errors 
        DEM:    5 RUNS wiht bad events on a level of 0.1-0.5% 
 
                -The datastreams switches without parsing any chip channels 
                 to another layer: e2240000 e34a0000 
                -Channel ID are "00", or sometimes ff 
 
 
</pre>
<!-- Author: Cigdem  -->


<!-- Date: Thu Dec 27 16:56:52 2001 -->
<pre>Diagnostic of SB2W3  
===================  
 
this is quite wedge....it has in few runs problems:  
 
 
SB2W3L0:  
        SVXMON: First problem in SVXMON starts at RUN 135293 0.05%  
                Strip Out of Order  
                Since 135615 no more errors.  
        DEM:    Just a few runs with bad events on a level of 0.1-5%  
                Since 135362 no problems  
                (Problems in RUN 135666, because silicon was off)  
 
                -Data stream contains "00 f3" entries.  
 
                * Calibration RUN;  
                  the datastream switches without parsing any channel entries  
                  to another layer: e2300000 e9420000  
                                             ^^^^^^^^  
                  bunchcrossing and backendstate at the beginning of  
                  the datastream are 00.  
 
SB2W3L1:  
        SVXMON: First problem in SVXMON starts at RUN 135279 0.1%  
                Strip out of Order  
                Only 4 runs wiht errors  
        DEM:    just a few runs with bad events; level 0.1-2%  
                no problems since run 135471  
                (Problems in RUN 135666, because silicon was off)  
 
                -Channel ID in CHIP 84 wrong:  
                 Channel ID 06-&gt;26 bit5 high  
                 Channel ID 02-&gt;22 bit5 high  
 
                -Channel ID in CHIP 85 wrong:  
                 Channel ID 21-&gt;a1 bit7 high  
                 Channel ID 7d-&gt;f2 bit7 high  
                 Channel ID 7e-&gt;fe bit7 high  
SB2W3L2:  
        SVXMON:  first problem in SVXMON starts in run 135279 0.1%  
                 Strip Out of Order  
                 No errors since RUN 135497  
        DEM:     Only four runs with bad events; level 0.8-1.2%  
                 Since RUN 135355 no problems  
                 (Problems in RUN 135666, because silicon was off)  
 
                 -d0c1c1c40000  
 
                 * Calibration RUNS  
                   - the datastream switches without parsing any channel  
                     entries to another layer:  
                        e2320000 e9440000 e9440000 e9440000  
                     bunchcrossing and backendstate are "00"  
 
SB2W3L3:  
        SVXMON:  first problem in SVXmOn starts in run 135334 0.1%  
                 Strips outof order  
                 4 RUNS wiht errors.  
                 Last problematic run 135658 had  
                  Chip Side Error  
                  EOR not Found  
                  Wrong Chip count  
        DEM:     NO ERRORS :)  
                 (Problems in RUN 135666, because silicon was off)  
 
SB2W3L4:  
        SVXMON:  first and only problem in SVXMON starts in run 135355 0.1%  
                 Strips out of order  
        DEM:     two run with bad events, level 0.9%/21%  
 
                 -data stream contains "00 f3" entries.  
 
</pre>
<!-- Author: cigdem -->


<!-- Date: Thu Dec 27 17:20:34 2001 -->
<h3>Code work for today</h3> 
I rebooted all the crates to use the proposed new code, and 
it mostly worked fine.   
<ul> <li> Fib crates had no trouble, and 
the auto-boot-loader was running and they all autoloaded fine. 
<li>Vrb crates  had some trouble in the HALT transition 
where the change is to identify BUSY and DONE problems not 
only by Vrb slot but also Fib ID of the Ladder on Channel 0. 
This seems to be fixed but needs a little more testing. 
 </ul> 
I also took Fib 137 swapped out <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=86&frame=2&anchor=10:58:34'> 
here</a> and Vrb  151 swapped out <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=82&frame=2&anchor=16:33:14'> 
here</a> and ran them with a DEM, with the proposed new 
Fib Firmware. <ul> 
<li> The Vrb has no discernable memory problem.  I ran with 
various buffer addresses and sizes and never saw any bit error. 
<li> The Fib has no discernable Glink problem, although this 
may have been erased by the power cycle 
<li> The firmware parses DEM data fine.  I even used the 
Last chip IDs to vary the data size arriving on each channel 
and didn't see any problems, and just enabled random channels 
and also saw no problem. So far the firmware works 
on a single ladder over at FCC and a DEM 
</ul> 
  
I'm almost happy with the latest code, but want a chance to 
test a little more tomorrow.  Giving the system to MB now...  
  
<!-- Author: SCN -->


<!-- Date: Thu Dec 27 17:29:00 2001 -->
<pre>Diagnostic of SB2W4 + SB2W5  
===========================  
 
***********************************************************  
 
SB2W4: not included!  
 
***********************************************************  
 
SB2W5 is a quite wedge, just a few problematic runs  
 
SB2W5L0:  
        SVXMON: NO ENTRIES, because layer is off  
 
SB2W5L1:  
        SVXMON: first and only problems in runs 135496 & 135517 3%  
                C2 BAD ADC value  
                Strip out of order  
        DEM:    NO ERrors  
                (Problems in RUN 135666, because silicon was off)  
SB2W5L2:   
        SVXMOn: first and only problems in run 135496 & 135498 1.5%  
                C8 BAD ADC Value  
        DEM:    9 runs with bad events on a level of 0.1-0.7%  
                since 124829 no problems  
                (Problems in RUN 135666, because silicon was off)  
 
                -datastream switches without parsing any channel/or  
                 chip entries to the next wedge:  
                  e2520000 e2520000 e2520000 ....  
                 Bunchcrossing and backendstate 00  
 
SB2W5L3:  
        SVXMON: first problems starting in run 135496 6%  
                C4 Bad AdC Value  
                Strip out of order  
                only 4 runs with errors  
 
        DEM:    NO ERRORS :)  
                (Problems in RUN 135666, because silicon was off)  
 
SB2W5L4:  
        SVXMON: first problems seen in run 135539 0.1%  
                Strip out order  
                Duplicate Channel  
                only 3 runs with errors  
        DEM:    9 runs with bad events on a level of 0.1-0.3%  
                since run 124830 no problems  
                (Problems in RUN 135666, because silicon was off)  
 
                -datastream switches without parsing any channel/or  
                 chip entries to the next wedge:  
                    e2540000 e3500000 ....  
                 Bunchcrossing and backendstate 00 </pre>
<!-- Author: cigdem -->


<!-- Date: Thu Dec 27 18:15:13 2001 -->
<pre>SB1W6 L0 get c4c4c4c4 when tried to run all 69 wedges with SEVB 
Took that layer out of HDWDB and CAEN files - turned it off. 
 
SB1W4 PC was on but all layers off and masked. Redownloaded 
powerset.dat after checking it wasn't included and turned 
PC off. 
 
SI biased and ready for calibrations</pre>
<!-- Author: Mad Mary -->


<!-- Date: Thu Dec 27 18:16:37 2001 -->
<pre>iagnostic of SB2W6:  
====================  
 
Layer 4 is BAD.   
 
SB2W6L0:  
        SVXMON: first problems seen in run 135434 0.25%  
                Strip out of order  
                EOR not found  
                Invalid EOR  
                Wrong Chip Count  
                Since run 135635 no problems.  
 
        DEM:    one run wiht problems,level 0.1%  
                -datastream switches without parsing any channel/or  
                 chip entries to the next wedge:  
                   e2600000 e37a0000 ....  
                 Bunchcrossing and backendstate 00  
                -Channel ID wrong  
                 Channel ID 55-&gt;fd bit3,5,7 high  
 
SB2W6L1:  
        SVXMON:  only problems in run 135434 0.25%  
                 Strip out of order  
        DEM:     NO ERRors  
                 (Problems in RUN 135666, because silicon was off)  
 
SB2W6L2: OFF  
SB2W6L3: OFF  
SB2W6L4:  
        SVXMON: first problems in run 128066;level 0.3%  
                Strip Out of order  
                EOR not found  
                Invalid EOR  
                Invalid Word  
                This layer has in nearly all runs errors and is still  
                making problems  
 
        DEM:    Almost all runs have bad events; level of 0.7-1.2%  
 
                -CHIP 8d: channel id's wrong  
                 Channel ID 67-&gt;77 bit4 high  
                 Channel ID 76-&gt;74 bit1 low  
                 Channel ID 78-&gt;76 bit1 low  
                 Channel ID 75-&gt;77 bit1 high  
                 Channel ID 77-&gt;f7 bit7 high  
                 Channel ID 67-&gt;f7 bit4,7 high  
 
                -datastream is messed up at the beginning  
                    e2640000 00005009 e00056fc  
                        ^^^^          ^^^^  
                    Bunchcrossing 00 and backend state 00  
                    switches to another wedge.  
 
                -Sometimes Channel ID is set to "ff":  
                     8d29 00f3 fff3 6606 6703  
                          ^^^^ ^^^^  
                          ^^^^ a single 00f3 entry  
                  or  
                     8d1c 00f3 cff3 0000  
                          ^^^^ ^^^^ </pre>
<!-- Author: cigdem -->
<!-- Comment: Fri Dec 28 08;28;47 comment by...SCN -->
Hi
 Some explanation is in order:
<ul>
<li>  -datastream is messed up at the beginning  <BR>
                    e2640000 00005009 e00056fc<BR>
I think this is looking for the data in the wrong place.My guess
is that e2640000 is the pointer to the send of the SIXD bank,
then the TSL1 is 50, the TS Event Number is 09, and e000 is
the first HDI block (fib id for SB0W0L0) and the BXING is 56, the
BE state is fc.  The way the reformatter works, as long as
SB0W0L0 is integrated, it will always be the first in the bank.
Next is SB0W0L1, ...
<li> -Sometimes Channel ID is set to "ff": <BR> 
                     8d29 00f3 fff3 6606 6703  <BR>
                          ^^^^ ^^^^  <BR>
                          ^^^^ a single 00f3 entry  <BR>
Here what is ff should actually be Channel 65.  The leading 
00f3 is perfectly legal-Chan 0 had and ADC count below the DPS 
threshold.  I've noticed that in neighbor mode the first Channel
of the First Chip is always read out (probably because the last Channel of the Last chip is forced).
<li> or  <BR>
                     8d1c 00f3 cff3 0000  <BR>
This is similar to above, except that the offending Channel happened to match an HDI End Of Record (EOR) character, which
is defined as 0xCX where X is any character.  Whenever this 
byte appears in the Channel location, the Vrb will keep the next
byte and then throw away the rest of the data, because it thinks
there is no more data. (Those who complain about this don't want to do physics, or at least not with reasonable statistics/low deadtime.)
</ul>
                  
              
<!-- Date: Thu Dec 27 19:20:55 2001 -->
<pre>Took calibration runs biased &gt;5K each run: 
 
Run 135809  DPS ON READALL 2 reformatter errors looks like 
SB2W1L2 doesn't readout sometimes: 
 
c1c4c4c4 00000000 e213xxfc 
 
Run 135811 DPS OFF READALL lots of reformatter errors 100s/5K: 
 
c1c10000 c1c4c4c4 00000000 5940bf02 
                           ********* 
 
****** changes !</pre>
<!-- Author: Mad Mary -->


<!-- Date: Thu Dec 27 23:28:04 2001 -->
<P> 
I tried to turn on parts of L00 tonight and encountered several problems. The show stopper is that when I try to turn on L00 portcards, it crashes the corresponding FIB crate. 
If logged into the FIB, I see the following messages spew before it dies: 
 
<PRE> 
0xe7ecd8 (Messenger): Heap Error: 'Internal Inconsistency' at   bb24f0 (count = 2034) 
0xe7ecd8 (Messenger): Heap Error: 'Internal Inconsistency' at   bb24f0 (count = 2035) 
...etc with count increasing to about 2043 before communication is lost.  
</PRE> 
<P> That was for b0fib07. The same thing happened to b0fib03 but the complaint was "... at b83bc0". 
<P> 
This repeated at least twice. 
<P> L00 will wait until this is understood and fixed. 
  
<!-- Author: David -->
<!-- Comment: Fri Dec 28 09;56;28 comment by...SCN -->
Fixed this morning.  Issue had to do with turning Fibs online
without rebooting crates.  Bug fixed, and future method of
downloading crates is impervious to status of online flag...
<!-- Date: Thu Dec 27 23:31:45 2001 -->
<pre>Punted on L00 integration. The rest of the silicon is now running in CDF at standby. 
</pre>
<!-- Author: David -->


<!-- Date: Fri Dec 28 07:50:10 2001 -->
<pre>Report on a pink color of IMon during owl shift on Dec.28. 
 
All are coming form DVDD. 
 
          latest V    latest/Nominal current    Time 
SB4W6L4     5.61              145/100           1:38 
SB1W6L4     5.76              145/110           2:02 
SB0W10L4    5.62              150/115           4:12 
SB0W4L2     5.53              130/175           5:03 
SB3W5L4     5.59              140/170           0:32 
            5.59              140/170           5:50 
            5.59              140/170           7:10 
SB3W8L4     5.61              170/140          23:24 
                                                1:12 
                                                2:19 
                                                3:14 
                                                3:32 
                                                3:44 
                                                3:50 
                                                4:00 
                                                5:06 
                                                5:14 
                                                5:56 
                                                5:59 
                                                6:33 
                                                6:37 
                                                6:49 
                                                7:26</pre>
<!-- Author: Soushi -->



<!-- Date: Fri Dec 28 08:53:43 2001 -->
<pre> persistent pink cell. 
 DVDD SVX B0W4L2 LV:5.53, LC:130 NC:175</pre>
<!-- Author: jy -->



<!-- Date: Fri Dec 28 10:01:28 2001 -->
<h1>Nefarious Plans</h1> 
No SPLs = WE do what we want!<BR> 
So far, fixed the handshake vis a vis online flag bug, but 
David saw higher currents than he liked for LB0W1 forget which 
layers, both with handshake and real inits. We took a run and he's looking at it.  If all looks ok, we'll try one more guy<P> 
I would like to resume "new code testing"-in fact, everything 
seemed to be working yesterday, so I would just load the new code and run a bunch, and possibly leave it over the weekend with 
new code if I can
<!-- Author: SCN -->


<!-- Date: Fri Dec 28 11:33:44 2001 -->
<P> 
We added some of L00. Details are: 
<P> 
<UL> 
 <LI> LB0W1L0 had high DVDD currents, ~250mA. 
      <BR> Took data and found that cell ids don't match and we get some events with 00fe... after the last channel of the first chip. 
 <LI> LB0W1L1. Normal currents. 
      <BR> Took data and found that 1st 22 events are ok 
but then cell ids get messed up. They differ between chips and neither chip matches the other ladders. Some events have 00fe... 
after the last channel of the first chip. 
 <LI> Turned these guys off and moved to a different fib. 
 <LI> LB1W0L0, LB1W0L1, LB1W0L2. All fine. 
 <LI> We did not integrate LB1W0L3 because the HWDB to CAEN 
communication does not know about the L4 to L3Bias1 connection. 
Until that gets fixed, the narrows in L00 will have to stay off. 
</UL> 
<P>  
We set the nominal bias voltages to 3V. <B>This is intentional.</B> The reason is that if the full bias is left on during messy beam (e.g. during TeV studies), damage could be done. Until monitoring and procedures are established to prevent this, the nominal bias will be low to avoid damage. That allows us to run nominally for commissioning experience. When beam conditions are stable, I will temporarily raise the bias manually to collect some hits. 
<P> 
LB1W0 left integrated for the next shot. 
<P>  
<!-- Author: David and Steve -->


<!-- Date: Fri Dec 28 11:41:54 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>PROPOSED PLAN: 
 
1) SCN tests code till shot setup then we go back to default 
code 
 
2) Silicon (+L00) integrates in STDBY when shot setup starts 
 
3) When beam conditions stablize SI expert biases SVX/ISL 
 
4) D. Stuart will come in and bias L00 
 
IF  
 
SCN is done 1-2 hours before shot setup - HST/Sparse studies  
(by me) until ready to integrate. 
</pre></td></tr></td></table>
<!-- Author: Mad Mad Mary -->


<!-- Date: Fri Dec 28 11:43:35 2001 -->
<pre>Increased the IMON DVDD limit from 30mA to 50mA. This is to  
accomodate IDVDD increases from quiescent to high rate.</pre>
<!-- Author: Mad Mary -->


<!-- Date: Fri Dec 28 13:14:25 2001 -->
<h3>L00 Plans put on hold</h3> again...<BR> 
Upshot is that there is a problem between the L00 VRB crate's SCPU b0eb23 and the ATM switch, so we cannot run L00 with 
CDF.<a href= 
'/cgi/elog/elog.pl?nb=2001&action=view&page=946&frame=2&anchor=12:30:10'> 
Details</a>.  We are now running integrated on the new code, and 
all is well, but without L00.  (The new code runs fine with L00 and the SEVB).  In about 10 minutes I'll reboot all the 
crates back to old code (don't want to leave new code in while 
I am gone for several days) and we'll just be integrated, unless 
the Queen Mary has other plans.  I removed L00 from the HDWDB, 
updated CAENvolts.dat, but cratematch.pl and IMON are claiming that dump.now is not being updated (GUI is running fine).  Dave 
should be here soon to help fix that one, since he is more in tune with how that works.    
<!-- Author: SCN -->
<!-- Comment: Fri Dec 28 13;33;42 comment by...David -->
<pre>The GUI spy died and auto restarted itself, so the cratematch and IMON problem is now gone.</pre>


<!-- Date: Fri Dec 28 14:23:33 2001 -->
Backed out the new code, so as not to  
leave some bug and not be able to fix it for four days,  
but it looks as if it all works.  At the 
very end we had trouble initializing IB0W1 L4, which read back all ffs.  David power cycled it, but we're hoping it 
didn't need that, only a third attempt...It looked as if it 
did initialize but just didn't read back correctly.  We're now 
integrated into partition 0, at standby, pbars going in.  I'm leaving. 
<h1>Happy New Year!</h1>
<!-- Author: SCN -->


<!-- Date: Fri Dec 28 17:06:22 2001 -->
<pre>SI Biased and integrated. Had problems with L2 and COT tripped. 
1st OK run with good SI this store would be 135874.</pre>
<!-- Author: Mad Mary -->


<!-- Date: Fri Dec 28 17:29:33 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>INSTRUCTIONS FOR CALIBRATION RUNS FROM T.V. 
------------------------------------------- 
 
SUMMARY:  
1) due to the very large event size AND the lack of a TFRD bank 
   in these runs, please use RunSectionInterval = 10 in the run 
   configuration. [ED: I think this needs to be smaller] 
2) to have all files go to the look area use the lookarea menu 
   in run control 
 
</pre></td></tr></td></table>
<!-- Author: Mad Mary  -->


<!-- Date: Fri Dec 28 19:32:56 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Ze plan  
 ========  
 
 1) SVX/ISL integrated biased until shot end  
 
 IF beam lost AND/OR bad conditions   
 
 a) Ace puts SVX/ISL in STDBY. Use Ifix voltage page and  
 verify SI PS GUI also indicated SVX/ISL are in stdby mode.  
 
 b) If 4-5 hours until shot setup again and HEVB types   
 available(Boris?) concentrate on fixing L00 EVB problems.  
 Will need access to HEVB and Svx crates.  
 
 IF no beam, good conditions and no L00 EVB studies needed  
 
 a) SI is biased (call main pager for instructions)    
 
 b) Take SVX calibration runs DPS ON and DPS OFF 5000 events  
 each. Use COSMIC 4_2_0 null table. Instructions on ACE page.  
 
 If no beam, calibrations done, evb work done  
 
 a) Integrate SI in stdby. </pre></td></tr></td></table>
<!-- Author: Mary Bishai -->


<!-- Date: Fri Dec 28 23:48:00 2001 -->
<pre>Persistent pinkies presently: 
&lt;pre&gt; 
SVX B3W11 Bias2 (curr=71/nom=177) 
SVX B5W5  Bias2 (curr=132/nom=312) 
SVX B5W6  Bias4 (curr=157/nom=304) 
&lt;/pre&gt; 
</pre>
<!-- Author: Joel -->
<!-- Comment: Sat Dec 29 15;14;18 comment by...Slave of the Nile -->
<pre>These are grassy L2 and L4 whose currents decrease with time.</pre>
<!-- Date: Sat Dec 29 07:35:02 2001 -->
<pre>I see the same pinks as above shifter in BIAS which I 
return immediately after unmarking. Nominal readings in brackets: 
                        Time(Marked) Time(UM) 
BIAS SB3W11L2  71(177)  23:44        1:47 
     SB5W5L2   131(312) 23:46        1:50 
     SB5W6L4   157(304) 23:32        1:50 
 
!!!This DVDD is persistent!!!       
                      Time(Marked)  Times(marked reappearing) 
DVDD SB3W8L4 190(135) 00:11         1:45 1:51 2:00 2:14 2:29 
--------------------------------------------------------------- 
 
These DVDD's and AVDD's remain stable after 1 unmarking: 
Type                     Marked  Unmarked 
AVDD SB1W11L4 1050(1145) 4:42    5:42 
     SB3W0L4  1035(1115) 4:43    5:44 
     SB4W9L3   775(850)  4:43    5:46 
     SB4W10L3  735(825)  4:57    5:46 
DVDD SB3W3L1   240(70)   3:25    5:48 
     IB0W2L0  1850(295)  3:25    6:36 
     IB0W2L1  1835(295)  3:25    6:37 
     IB0W2L2  1780(320)  3:25    6:37 
     IB0W2L3  1840(300)  3:25    6:38 
     IB0W2L4  1760(315)  3:25    6:39 
      
     SB3W8L2  180(120)   6:38    6:41 
</pre>
<!-- Author: Tania -->


<!-- Date: Sat Dec 29 08:35:57 2001 -->
<pre> persistent pink cells 
 AVDD SB1W5L0 118(306) 07:50:37 
      SB1W5L1 243(507) 07:50:36 
      SB1W5L2 440(810) 07:50:36 
      SB1W5L3 440(825) 07:50:36</pre>
<!-- Author: JY -->


<!-- Date: Sat Dec 29 09:08:31 2001 -->
<pre> all parts are now stanby incluing silicon.</pre>
<!-- Author: jy -->


<!-- Date: Sat Dec 29 09:18:32 2001 -->
<pre> SVX B3 W10 external trip. 
 paged. followed instruction. 
 clicking 'full status' button gives some information on that channel. 
 channel 1 AVDD OFF (but I lost values after I set it on stanby  
 I could not note it here sorry) 
 
 </pre>
<!-- Author: jy -->
<!-- Comment: Sat Dec 29 14;51;08 comment by...Mary -->
<pre>This occured while switching system to STDBY</pre>
<!-- Date: Sat Dec 29 09:30:26 2001 -->
<pre> iMon red square (tripped one in previous note) 
 AVDD B3W10L1 OFF current 1.0 (nominal 508) time 09:09:05</pre>
<!-- Author: jy -->


<!-- Date: Sat Dec 29 14:10:02 2001 -->
<pre>silicon D mode calibration  
with DPS on 5000 events     run : 135909  
with DPS off 5000 events    run : 135910 </pre>
<!-- Author: jong-young -->




<!-- Date: Sat Dec 29 16:45:16 2001 -->
<p>Changed ISL CCW1 and CCW3 supply valves from their default 
settings to the correct settings (CCW1 = 85%, CCW3 = 90%). 
</p> 
<a href= 
'/cgi/elog/elog.pl?nb=2001&action=view&page=950&frame=2&anchor=16:39:10'> 
Also changed SVX_TE_PCW1A_2 warning limit.</a> 
<!-- Author: Andy H. -->


<!-- Date: Sat Dec 29 21:11:48 2001 -->
<pre>LOST B0FIB00 VME POWER SUPPLY when large losses occured during 
shot set up. 
 
Powered off  
SB0W0 1,2,3,10,11 
SB1W0 1,2,3,10,11 
SB2W0 1,2,3,10,11 
 
Fibs and HDIs online flags set to 0 in HDWDB. CAEN files updated 
and reloaded. 
 
Accidentally turned off SB5W0,1,2 and turned it back on again</pre>
<!-- Author: Not very Merry Mary -->


<!-- Date: Sat Dec 29 21:47:41 2001 -->
<pre>Persistent pink cell: 
   SB3W8L4 DVDD, the latest current is around 190, 
  for nominal 135.</pre>
<!-- Author: Yamashita -->
<!-- Comment: Sat Dec 29 22;00;05 comment by...Un Merry Mary -->
<pre>So long as the 190 is happening with data taking then its fine.
Check that it reverts to 135 when there are no triggers between
runs. </pre>


<!-- Date: Sat Dec 29 22:23:09 2001 -->
<pre>Another 3 persistent pinkies:  
 SB3W11L2 bias (curr=71/nom=177)  
 SB5W5L2  bias (curr=174/nom=312)  
 SB5W6L4  bias (curr=164/nom=304) 
They are decreasing with time.</pre>
<!-- Author: Yamashita -->


<!-- Date: Sat Dec 29 23:52:58 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>The rack SVX_SWB tripped off (fan fault) taking FIB02 and the CANEs with it. Cryo techs reset, crates are back on and I switched all of the ladders back on.</pre></td></tr></td></table>
<!-- Author: Joel -->
<!-- Comment: Sun Dec 30 13;11;33 comment by...Lester -->
<pre>This has happened a couple of times before. I thought the previous times were during accesses when work was being done. (I tripped it once). This sensor should be looked at since it's 
obviously flaky.
</pre>

<!-- Comment: Sun Dec 30 15;20;50 comment by...UnMerry Mary -->
<pre>Its been flaky since Si first arrived in B0 :( got better with
time though.</pre>


<!-- Date: Sun Dec 30 15:24:32 2001 -->
Got paged this morning about potentially serious Silimon 
errors: 
 
<a href= 
'/cgi/elog/elog.pl?nb=2001&action=view&page=952&frame=2&anchor=09:44:44'> 
No data from SB2W7L4 and bad chip in IB5W4L4NC3 </a> 
<!-- Author: Not Merry Mary -->
<!-- Comment: Sun Dec 30 15;51;20 comment by...UNMERRY MARY -->
<pre>SB2W7L4 bit 1 is stuck hi all the time here is a dump in SvxDaq:

0e48ef02 04104100 00000010 00000000 00000000 00000000 00000000  00000e24
e27447fc 8f230233 032c0235 03330633 07330632 07330a33 0b320a35 0b330e2c
0f330e2c 0f331232 1333122c 132c1634 17331632 17331a34 1b341a32 1b321e32
1f2c1e33 1f322234 23332233 23322633 27322632 27352a33 2b332a35 2b332e34

I will take the stinky thing out of commision
2f322e33 2f343233 33323233 33323634 37343632 37353a34 3b333a35 3b323e3</pre>


<!-- Comment: Sun Dec 30 16;47;06 comment by...UnMerry Mary -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Okay I will leave SB2W7L4 in and see if the bit error goes
away. Keep an eye for SIlimon and SvxMon errors!</pre></td></tr></td></table>
<!-- Date: Sun Dec 30 16:16:28 2001 -->
<pre>To use svxdaq it looks like some DDRs got disabled because  
AVDD currents are lower on the wedges in fib02. </pre>
<!-- Author: UnMerry Mary -->


<!-- Date: Sun Dec 30 16:29:19 2001 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sun_Dec_30_2001_162209.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-264  align='top'></td><td>It looks like the bad landaus reported on IB5W4L4 reported in Silimon may be due to an unbiased half ladder. This is the plot of noise/dnoise lastpulse/avg ped. Both Bias0 and Bias1 report 0 current on GUI</a></td></tr></table>
<!-- Author: UnMerry Mary -->
<!-- Comment: Sun Dec 30 16;30;55 comment by...MEEEEEE -->
<pre>Took a biased run

~svxii/daq/anywhere/data/laser1431.svx</pre>



<!-- Comment: Mon Dec 31 17;08;53 comment by...Mary -->
<pre>Silimon errors have persisted so far.</pre>
<!-- Comment: Mon Dec 31 17;53;42 comment by...UnMerry Mary -->
Silimon errors on this ISL ladder seem to have disappeared today:

<a href=
'/cgi/elog/elog.pl?nb=2001&action=view&page=955&frame=2&anchor=10:07:59'>
see this </a> 
<!-- Date: Sun Dec 30 17:22:41 2001 -->
<pre>Si Calibration runs (biased of course) 
 
135950 (0x2130e) DPS ON 
135951 (0x2130f) DPS OFF</pre>
<!-- Author: UnMerry Mary -->


<!-- Date: Sun Dec 30 17:27:28 2001 -->
<pre>SB3W2 L2 DVDD2 overvoltage!!</pre>
<!-- Author: I wanna get outa here -->
<!-- Comment: Sun Dec 30 17;30;42 comment by...Very UnMerry Mary -->
<pre>Silly thing is off anyway so how can you trip when 
you are off? Beats me I didn't design this system :(</pre>

<!-- Comment: Sun Dec 30 17;38;53 comment by...Moi meself and I -->
<pre>Actually other OFF ladders reported DVDD currents on the order
of 100mAs at the same time according to IMON. There is no
beam so weird stuff is happening</pre>


<!-- Date: Sun Dec 30 21:41:16 2001 -->
Mary's not completely crazy. I just saw the same thing on another ladder. Check  
<a href= 
'/cgi/elog/elog.pl?nb=2001&action=view&page=953&frame=2&anchor=21:34:14'> 
this</a>. 
<!-- Author: Joel -->
<!-- Comment: Sun Dec 30 23;24;20 comment by...Joel -->
<pre>Removed SB2W5L4 from database and CAENvolt due to DVDD tripping during cold start.</pre>


<!-- Date: Mon Dec 31 07:29:07 2001 -->
<pre>Had some persistent pink AVDD's in run 135969 which went away 
and stayed green after the cold start for a new run (135971) 
These were first marked at 5:04 and returned immediately when 
I tried to unmark them but are OK after the cold start. 
SB4W5L0 151(344)  
SB4W5L1 211(491) 
SB4W5L2 435(825) 
SB4W5L3 365(745) 
</pre>
<!-- Author: Tania -->


<!-- Date: Mon Dec 31 13:41:20 2001 -->
<pre>ISL tripped. iMon showed 4 squares pink. 
DVDD B0W2L0,1,2,3 
L2 1410(320) 
L3 1670(300) (sorry I lost L0,L1, because I didn't take a note 
before I press unmark button for checking iFix alarm disappear)</pre>
<!-- Author: jong-young chung -->
<!-- Comment: Mon Dec 31 13;42;02 comment by...jong-young chung -->
<pre>Now they disappeared by pressing unmark button.</pre>

<!-- Comment: Mon Dec 31 15;05;20 comment by...Mary -->
<pre>
After voltages came back Matt still couldn't init during 
coldstart b0fib01 was apparently taken out of the run. 
Beam conditions have been bad with bad losses.

&lt;a href=
'/cgi/elog/elog.pl?nb=2001&action=view&page=955&frame=2&anchor=13:54:51'&gt; See here &lt;/a&gt; </pre>


<!-- Date: Mon Dec 31 15:36:48 2001 -->
<pre>Checked IB0W2 with Svxdaq - everything looks OK. Ran with SEVB 
coldstart failed because b0fib02 wasn't rebooted after Joel 
took out SB2W5L4 last night. I am surprised this wasn't noticed  
before..</pre>
<!-- Author: Mary -->


<!-- Date: Mon Dec 31 15:45:00 2001 -->
<pre>Tried reintegrating SB2W5L4. After handshake currents are at 
nominal values but after COLDSTART IDVDD &gt; 900mA !!!. </pre>
<!-- Author: Mary -->
<!-- Comment: Mon Dec 31 15;46;19 comment by...Mary -->
<pre>Then the whole wedge trips off!</pre>

<!-- Comment: Mon Dec 31 15;49;47 comment by...Mary -->
<pre>After switching wedge back to stdby currents on L1,2,3 are
at nominal AVDD4 is at nominal but DVDD4&gt;1A!!. Turning L4
off and on again doesn't help IAVDD is fine but IDVDD is huge.</pre>

<!-- Comment: Mon Dec 31 15;55;46 comment by...Mary -->
There is no record of anything wrong with SB2W5L4 but the power
supply on this wedge was changed in May <a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=26&frame=2&anchor=20:43:08'>
See here </a> 

<!-- Comment: Mon Dec 31 15;57;07 comment by...ME -->
<pre>RECOMMEND checking sense cable/PS for this wedge</pre>


<!-- Date: Mon Dec 31 16:59:13 2001 -->
<pre>SVX Calibration runs 
 
Run 135999 DPS ON 
Run 136000 DPS OFF 
 
Webpage ACE instructions for SVX calibrations has been updated 
to pick the latest configurations</pre>
<!-- Author: UnMerry Mary -->



<!-- Date: Mon Dec 31 17:38:02 2001 -->
<pre>SB4W11L2 DVDD external trip switched it back on 
IDVDD=210 
IAVDD=600 
 
I don't think it handshook properly. Wait till COLDSTART to 
validate IMON</pre>
<!-- Author: UnMerry Mary -->
<!-- Comment: Mon Dec 31 17;49;56 comment by...UnMerry Mary -->
<pre>Started up SI in seperate partition and coldstarted. 
SB4W11L2 is now at nominal IAVDD and IDVDD values</pre>



<!-- Date: Mon Aug 16 23:03:02 2021 -->
<pre>Turned on Silicon. but we got the alarm message from SB2W0L2 
which should not be biased. This shows 12.9 V in the biasV. 
Paged Marry and then waited a couple of minuits after pushing on acknowlege button, but it still shows 12.9 V. She suggested to call PS expert.</pre>
<!-- Author: Soushi -->
<!-- Comment: Mon Aug 16 23;51;32 comment by...Soushi -->
<pre>DVDD and AVDD are zero.</pre>
<!-- Comment: Tue Jan  1 02;54;41 comment by...Poor me that is M.B. -->
<pre>Turns out that SB2W0L2 only shows 12.9V when SB3W0L2 the other
half ladder is also biased. When SB3W0L2 is on stdby there
is no voltage on SB2W0L2 bias. A short?</pre>
<!-- Comment: Wed Jan  2 11;20;05 comment by...Petra -->
this is already known since a while, check <a href=
'/cgi/elog/det-system-elog.pl?nb=e200-SVX-C-BRL-W-End-P-0&action=view&page=1&frame=2&anchor=19:55:12'>
this entry </a>...
<!-- Comment: Fri Jul  8 15;09;29 comment by...SCN (yes, the same one...) -->
<h1>Odd date</h1> For those who are browsing later, on Jan 1 2002 the timeservers went bananas, projecting CDF (FNAL?) into the year 2014 or something like that, which is why these dates are suddenly in August.  (I just noticed this, today is 7/8/2005!)
<!-- Date: Mon Aug 16 23:50:20 2021 -->
<pre>Paged Matt. He will fix this problem after consulting with Mary.</pre>
<!-- Author: Soushi -->



<!-- Date: Tue Aug 17 00:34:24 2021 -->
<pre>From Matt, if the voltage of SB2W0L2 exceed over 50 V,  
said me to push crush button. I hope it does not happen. 
Tevatron beam is now unstable. So, all silicons is standby now. 
(proton losses are over 20kHz.)</pre>
<!-- Author: Soushi -->
<!-- Comment: Tue Jan  1 03;23;10 comment by...Mary -->
<pre>If it exceeds 50V do not push crash button but switch 
SB3W0L2 to STDBY and see if this fixes it first.</pre>
<!-- Date: Tue Aug 17 00:37:02 2021 -->
<pre>SB3W8L1 external triped due to VBIAS. 
Turned to standby, IMon was unmarked. 
Now, all silicon is standby.</pre>
<!-- Author: Soushi -->


<!-- Date: Tue Aug 17 00:40:51 2021 -->
<pre>After fixing L3 problem (see shift e-log), we will turn ON of  
all silicons if beams are stable (now plos is 22000Hz).</pre>
<!-- Author: Soushi -->


<!-- Date: Tue Jan 1 01:28:50 2002 -->
<pre>As you can tell from the dates on the previous entries, at 
midnight 2001-2002 something horrible happened to b0dau30. 
Jim Patrick fixed stuff. As a result (?) the GUI died and  
we were unable to resurrect it on b0dap42. Eventually started 
it up again on one of the consumer machines. b0dap42 slowed 
to a crawl and simple operations like pwd were no longer working 
After failing to kill the xsession and so shutdown from the 
login window I clicked the reset button and rebooted the machine 
/home/swap FAILED to mount but other wise it came up fine.  
Restarted Imon and GUI  but GUI is unable to resume contact 
with IFIX. 
 
When GUI was restarted it turned off all layers that were 
on on SVX bulkheads 0,1,2 and ISL B0 but CPC power was left on. 
Here is what svxinter was reporting: 
 
Crate #: 12 
Group Name: "GROUP00" 
Crate #: 13 
Group Name: "GROUP00" 
Crate #: 14 
Group Name: "GROUP00" 
Crate #: 15 
Group Name: "GROUP00" 
Crate #: 16 
Group Name: "GROUP00" 
detector = 1, ps_n = 4, layer_n = 4 spontaneously turned standby 
turning it back off 
checkSt[1][4][4] = 1 
detector = 1, ps_n = 4, layer_n = 3 spontaneously turned standby 
turning it back off 
checkSt[1][4][3] = 1 
detector = 1, ps_n = 4, layer_n = 2 spontaneously turned standby 
turning it back off 
checkSt[1][4][2] = 1 
detector = 1, ps_n = 4, layer_n = 1 spontaneously turned standby 
turning it back off 
checkSt[1][4][1] = 1 
detector = 1, ps_n = 4, layer_n = 0 spontaneously turned standby 
 
More to come</pre>
<!-- Author: VERY VERY UNMERRY MARY -->
<!-- Comment: Tue Jan  1 01;31;43 comment by...Mad Mary -->
<pre>Oh yes when I tried to turn the bulkheads back on handshake 
failed svxinter reports

ERROR: not all Fibs are initialized

SVX deintegrated from CDF and IN MY POWER</pre>


<!-- Comment: Tue Jan  1 04;13;40 comment by...patrick -->
<pre>Whenever a control room PC boots it prints
the message about /home/swap not mounted.
This is because at the time the swap space is
declared the disk is not mounted. However,
later when the disk is mounted, the swap
space does get defined. We don't know a
good way to avoid this.</pre>
<!-- Date: Tue Jan 1 02:05:51 2002 -->
<pre>I tried doing a coldstart to redownload the maps and checked 
that messenger process is still running but all I can turn on 
is the CPC all ladders on B0,1,2 refuse to turn on because  
svxinter is failing to handshake.  
 
Reboot svxinter 
 
I get this error on starting GUI from PS/anywhere: 
 
b0dap24:bash: /cdf/people2/svxii/daq/PSEast/CAEN.map: No such file or directory 
 ERROR: reading mapping.info 
Voltage file is /cdf/people2/svxii/daq/PSEast/CAENvolts.dat 
v288 base address error 
 
WHY ON EARTH DOES IT THINK THE CAEN FILES SHOULD BE IN PSEAST? 
HOW LONG HAS THIS BEEN WRONG? 
 
Fixed the PS.conf file but now PSControl can't talk to svxinter 
reboot again!  
 
After rebooting again I am now able to switch ISL B0 SVX B0,1,2 
to STDBY but I still don't have connection to IFIX. 
 
Keep in mind that I still have no contact with IFIX and while 
I am rebooting svxinter I am blind as to power problems!! 
Nobody is anawering the GUI expert pager. 
</pre>
<!-- Author: Mad MAD Mary -->


<!-- Date: Tue Jan 1 02:29:27 2002 -->
<pre>Got a hold of Eva H. and she told me to restart PSMon on the 
PC downstairs. Did that and now IFIX is talking to GUI and 
everything is HAPPY HAPPY JOY JOY</pre>
<!-- Author: ME -->



<!-- Date: Tue Jan 1 02:57:44 2002 -->
<pre>SI biased. </pre>
<!-- Author: M.B. -->



<!-- Date: Tue Jan 1 03:40:27 2002 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>SPECIAL INSTRUCTIONS FOR MONITORING ACE 
---------------------------------------- 
 
1) When losses exceed 25K switch SI to STDBY from IFIX window 
 
2) When beam conditions are OK i.e. losses &lt; 25K and no spikes 
   ACE is allowed to bias Silicon using the following procedure: 
 
   a) Go to the PS GUI.  
   b) Click on a bulkhead circle. The bulkheads are 
      ISL B0 and B5 
      SVX B0 ,1 ,2, 3, 4 ,5 
   c) From the list of buttons on the right center of the 
      GUI click "on" the bulkhead you want to turn on 
      For e.g. "ISL Bulkhead 0" 
   d) Do each bulkhead seperately and wait for GUI to update 
      once and verify all ladders are green. 
  
   e) From a terminal window on the svxii account type   
      ~svxii/cratemap.pl 
      then enter again at the prompt  
      A list of all ladders integrated and biased should appear. 
      The summary at the end should look like this: 
" 
   The following wedges should NOT be crossed: 
   none  
 
   The following wedges should be crossed: 
   none  
 
   The following wedges should be biased and are not:  
   SB0W7L4   
 
   The following wedges should be OFF and are ON:  
   none  
 
   The following wedges should be Stand-By or ON and are OFF:  
   none  
 
   * * * Silicon is Ready to Cold Start ! * * * " 
 
3) Some known problems: 
 
 a) When SI is biased GUI reports a trip on SB2W0L2 BIAS 
    Please acknowledge trip and make sure SB2W0L2 BIAS 
    is &lt; 50V by clicking on that wedge in the GUI and  
    then clicking full status. A page will pop up displaying 
    all the PS problems. 
 
 b) SB2W7L4 is not biasable and will remain yellow when 
    B0 is biased. 
 
 c) During the transition from STDBY to BIASED/ON and vice 
    versa, several AVDD and DVDD cells on IMON will turn  
    pink and be persistent. If these cells do not reset 
    to nominal values after a coldstart please page SVX 
 
 d) During data taking some DVDD cells in IMON may turn  
    persistent pink. If after a run is ended and the  
    detector is quiet these cells do not return to green 
    please page SVX.</pre></td></tr></td></table>
<!-- Author: Mary Bishai -->



<!-- Date: Wed Jan 2 08:01:54 2002 -->
<pre>Only One persisten pink DVDD in this run 136040: 
M stands for Marked, UM stands for Unmarked.                    
SB3W8L4 190(135) 4:20M 7:23UM 7:30M 7:55UM </pre>
<!-- Author: Tania -->