<!-- Title: 08:29:24  Mon Jan 14 2002 -->
<!-- Crewchief: silicon people -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>New week -  
--------------- 
1. analyze ISL ISEL work - see previous file for David's 
       explanation 
2. charge injection geometry runs 
3. BW scans once ISEL is decided 
4. X-mode 
5. decide further response to AVDD2 situation  
6. decide priorities for rpoblem wedges and ladders 
7. During accelerator studies day, integrate remaining possible  
    ladder set.</pre>


<!-- Date: Mon Jan 14 08:56:18 2002 -->
<pre>Tuning ON the Silicon after the shot set up. 
b0fib01 came back to handshake. 
SB0W3L3 went on bias overcurrent, twice. I had to reduce the voltage to 60 V instead of the nominal 100.  
This is a good candidate for intervention next access:  
change the PS scale. 
SB0W7L4 is set to 2 V and SB1W4L3 is also set to 2 V. 
IB4W3L4 is (partially ?) unbiased 
L00 is in stand-by.</pre>
<!-- Author: saverio -->
<!-- Comment: Mon Jan 14 11;29;47 comment by...Petra -->
<pre>why do we run ladders in standby?! there should be no reason for that!</pre>


<!-- Comment: Mon Jan 14 15;44;58 comment by...David -->
Good question. Here are the reasons for the ISL and L00. L00 is in standby except in cases when the losses are clearly stable and a L00 expert is present. This is a temporary situation until we understand the issue of losses better. The ISL guy is in standby because one HDI corresponds to two ladders. One of the ladders works fine and we want to run it biased. The other ladders has a pinhole and we leave it set to standby until we're convinced that we've safely fixed it. Since they have separate biases but a single readout chain, we have to readout the unbiased guy along with the biased guy. (But, its threshold is set to counter-mod.)

<!-- Date: Mon Jan 14 12:55:10 2002 -->
<pre>the plan for BW scans using more RA wedges is on hold until the 
COT recovers a lost crate, which spans exactly that phi slice 
we need to run RA in. 
 
COT expects to recover this crate sometime tomorrow or wednesday. 
We should aim to be ready to take these BW runs during the first 
store after the TeV study period. i will send email to the ops 
managers and we ought make this request clear at the 0800 
meeting. 
 
I'll post the run plan later (i have to escape to a meeting now).</pre>
<!-- Author: Doug -->


<!-- Date: Mon Jan 14 13:08:21 2002 -->
<pre>Persistent pink color from IMon even after "coldstart". 
 
                 latest/nominal (current) 
SB0W2L0-4 : AVDD 103/321, 439/522, 405/835, 435/880, 540/1060 
SB0W0L2   : DVDD 70/210 
SB0W3L3   : DVDD 90/140 
SB4W0L4   : AVDD 105/1150 (too low!!) 
 
SB5W8L2   : BIAS 605/428 (??) 
 
Most AVDD of biased-ISLs are lower current.</pre>
<!-- Author: Soushi/Naho -->


<!-- Date: Mon Jan 14 14:47:50 2002 -->
<pre>The run plan for the RA wedges is: 
 
* ================================================== 
 
  &gt; RA wedges 
	- during collisions 
 
	- detector bias is necessary 
 
        - parasitic to normal data taking 
 
	- require track-trigger, magnet&COT ON,  
	  "dflt" physics trigger table 
 
	- set the following wedges/layers in RA 
 
		S-B3W8L0:4  (SVT should mask this wedge off) 
		S-B5W8L0:4  (SVT should mask this wedge off) 
		I-B2W0L4 
		I-B1W4L4 
		I-B1W5L0,L2 
		any available L00 
 
	  and take the following runs (in this order): 
 
        ------ BW SETTING ----- 
	      SVX/ISL     SVX 
	L00   PHI/SAS   90-DEG    DPS    NEVENTS    
        ===   =======   ======    ===    ======= 
     1.  3       5         4      OFF     450k 
     2.  3       5         4       ON     120k 
     3.  4       6         5      OFF     450k 
     4.  2       7         6      OFF     450k 
     5.  5       4         3      OFF     450k  (if time) 
     6.  3       5         4       ON     450k  (if time) 
 
          &gt;&gt;&gt; care should be taken that a CALIBRATION be made 
	  &gt;&gt;&gt; BEFORE EACH of the different BW RUNS !!! 
 
	  &gt;&gt;&gt; the BW is changed ONLY on these special   
          &gt;&gt;&gt; wedges/layers, the rest of the detector is  
	  &gt;&gt;&gt; in its dflt settings 
 
	  &gt;&gt;&gt; using run 128501, we find that CDF collected 450  
          &gt;&gt;&gt; kevts in about 2.5 hrs of running.  the efficiency  
          &gt;&gt;&gt; was 70% and the inst luminosity was about   
          &gt;&gt;&gt; 5E30/cm^2/s for this run. we thus estimate it will  
          &gt;&gt;&gt; take about 9 hours to get thru the first 4 runs and  
          &gt;&gt;&gt; an additional 5 hours to get thru all 6 
 
</pre>
<!-- Author: doug -->
<!-- Comment: Fri Jan 18 09;52;41 comment by...Doug -->
<pre>We're using a different trigger table than the one used to
estimate how many events we need.  With physics_0_03, WE NEED
ONLY HALF AS MANY EVENTS AS INDICATED ABOVE.  We need about
40/nb at each point.

Also, WE NEED PT 5 (so ignore the "(if time)" comment for 5th 
run).</pre>
<!-- Date: Mon Jan 14 14:49:41 2002 -->
<pre>Joel paged me tonight since he couldn't get the handshake to work  
for the recovered fib01 wedges. After the VME PS was exchanged  
he put everything back together but couldn't make the SVXINTER to  
listen to the fib's handshake. Rebooting fib and svxinter and GUI didn't help. 
The fib claimed that the handshake went well, but GUI and svxinter  
wouldn't think so... 
He left the corresponding wedges out during the night. 
 
At the next attempt this morning everything was fine.  
Does anybody know (SCN?) what this capricious behaviour means?</pre>
<!-- Author: Petra -->



<!-- Date: Mon Jan 14 17:14:26 2002 -->
<pre>There is a VRB header problem with SB1W4. The VRB header is completely missing (see entries &lt;a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=42&frame=2&anchor=16:50:44'&gt; 
here &lt;/a&gt; and &lt;a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=42&frame=2&anchor=17:00:17'&gt; 
here &lt;/a&gt;).  
It went away for something like 15 minutes and then happened again.  
I try to diagnose the wedge now by taking out first all five ladders  
of this wedge, run for 10 minutes, and then put ladder after ladder  
back in to see which one is causing the problem.  
 
</pre>
<!-- Author: Petra -->


<!-- Date: Mon Jan 14 17:14:42 2002 -->
<pre>There is a VRB header problem with SB1W4. The VRB header is completely missing (see entries &lt;a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=42&frame=2&anchor=16:50:44'&gt; 
here &lt;/a&gt; and &lt;a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=42&frame=2&anchor=17:00:17'&gt; 
here &lt;/a&gt;).  
It went away for something like 15 minutes and then happened again.  
I try to diagnose the wedge now by taking out first all five ladders  
of this wedge, run for 10 minutes, and then put ladder after ladder  
back in to see which one is causing the problem.  
 
</pre>
<!-- Author: Petra -->


<!-- Date: Mon Jan 14 17:15:35 2002 -->
There is a VRB header problem with SB1W4. The VRB header is completely missing (see entries 
<a href=  
 
'/cgi/elog/elog.pl?nb=2002&action=view&page=42&frame=2&anchor=16:50:44'>  
 
here </a> and <a href=  
'/cgi/elog/elog.pl?nb=2002&action=view&page=42&frame=2&anchor=17:00:17'>  
 
here </a>).   
It went away for something like 15 minutes and then happened again.   
I try to diagnose the wedge now by taking out first all five ladders   
of this wedge, run for 10 minutes, and then put ladder after ladder   
back in to see which one is causing the problem.   
  
<!-- Author: A HTML victim -->
<!-- Comment: Mon Jan 14 17;45;08 comment by...Petra -->
<pre>so far I re-added L4 and L3 without the BTO reappearing. After 
adding L2 we got a BTO after a couple of minutes. A HRR fixed it 
for this time. Now the x-session of the RC PC crashed and delays 
this debugging process.</pre>

<!-- Comment: Mon Jan 14 19;00;33 comment by...Petra -->
<pre>so, I saw BTOs with both, L1 and L2.
I tried L2 several times, a few times it gave a BTO, but a HRR helped. 
I don't have enough statistics about L1 yet.</pre>


<!-- Comment: Mon Jan 14 19;11;13 comment by...Petra -->
<pre>so, I conclude that the L1 of SB1W4 is the problematic kid. 
sometimes it runs for thousands of events, sometimes it gives 
several BTOs in a row and even a HRR doesn't help. 
I will take it out for now and then we should investigate it 
during the accelerator study days.</pre>
<!-- Date: Mon Jan 14 19:04:06 2002 -->
<pre>SB0W2 
This wedge has a very weird behavior since a long time. 
It is at least a few days that all 5 ladders are oscillating between a good and a bad state. 
More precisely the AVDD currents are jumping between their normal value and a much lower value. 
The lower value could be explain in at least the following ways: 
1- All 5 ladders get initialized with all 0s on the bitstream 
2- All 5 ladders stop receiving 
         PARST 
Looking at silimon we see no occupancy for these 5 ladders. 
Working together with the CDF crew we associated at least the last change in current  
From BAD to GOOD with a cold start 
From GOOD to BAD with the beginning of DATA TAKING. 
 
Mary best bet is a BAD FIB. 
Another piece of information is that SB0W3 (the other half of the same FIB) is working fine 
Still working on it 
 
 
</pre>
<!-- Author: Gino & Mary -->
<!-- Comment: Mon Jan 14 21;27;51 comment by...Hungry Mary  -->
<pre>Here is what I think is happening. We know from the measurements
I did with Gino that these currents look almost exactly like
what we expect when missing PARSTS and maybe also FECLKS. 
Since this doesn't happen for the second wedge if it is a 
FIB problem it is most likely something to do with FIB Clock1 
getting disabled. We can verify this by initing then switching
off clock1 on the fib by hand and measuring what happens to
the currents. Clock1 disabled should only switch off PARSTs
and other commands but FECLK, L1A and PRD2 will still
get through. BECLK needs CCLK to enable the DDR BECLK so 
we would not get BECLKs either.</pre>
<!-- Comment: Mon Jan 14 21;30;23 comment by...Mary  -->
<pre>I am not sure its clear from what Gino says that ONLY AVDD
is oscillating not DVDD on this wedge. So it is not really
a deinit. </pre>
<!-- Comment: Mon Jan 14 21;35;40 comment by...Lester -->
<pre>Just to comment we do see data from 0,1,3,4 layers offline,
the data just have lots of CAPID errors. L2 seems to just 
give c2c2.</pre>
<!-- Date: Mon Jan 14 21:22:48 2002 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>I CHANGED THE DVDD IMON CAUTION RANGE FROM 50mA TO 70MA. 
I AM TIRED OF DVDD READOUT IMON PINKIES.</pre></td></tr></td></table>
<!-- Author: Mary -->





<!-- Date: Mon Jan 14 22:03:43 2002 -->
<pre>I took SB1W4L2 out as well. It gave BTOs in the same way as the L1 of this wedge. Just to be clear: it did it already BEFORE I took out L1. 
</pre>
<!-- Author: Petra -->


<!-- Date: Mon Jan 14 22:12:12 2002 -->
<pre>10:11 pm IMON died in front of me.  
Maybe it was my fault. I could have clicked on Exit while I was trying to unmark a current.</pre>
<!-- Author: Gino -->
<!-- Comment: Mon Jan 14 22;55;32 comment by...Gino -->
<pre>I restarted it immediately</pre>
<!-- Date: Mon Jan 14 22:47:35 2002 -->
<pre>In the middle of run 137021 (started at 20:36) at around 20:03 pm they did a HRR and around the same time, ISL B4W1 IMON 
latched pink AVDD where AVDD on all 3 HDIS was around 600mA.  
DVDD and all 3 HDIS was at nominal. We paused the run and  
did a fib crate config at 22:31 - AVDD is now yellow (OK?) and we 
have resumed the run. D. Stuart says to deintegrate this wedge 
because we don't understand what happened. If we follow this 
procedure we might as well take 50% of the Silicon out of CDF 
everytime we don't understand what happened but recoved OK ! 
 
I will wait to see if this happens again and THEN take the ISL 
wedge out. Dave, you can shoot me tomorrow.</pre>
<!-- Author: Mary and only Mary -->
<!-- Comment: Mon Jan 14 22;51;09 comment by...Mary -->
<pre>One reason a HRR might put the chip in bad state is the 
following:

The SVX3D chip reset is a mini init which will RELATCH the bits
on the chip shift register. NOW from the SEU tests we know that
this bits are very stable so unless something is sticking 
different bits in the shift register the mini init should always
put the chips in the same state as the previous init. </pre>


<!-- Comment: Mon Jan 14 23;17;43 comment by...Gino -->
<pre>More on IB4W1:
IB4W1L2 changed its current from 1200 mA to 620 mA 
	at 21:28 when an HRR was applied
IB4W1L0 changed its current from 1230 mA to 735 mA
 	at 22:03 when an HRR was applied
IB4W1L4 changed its current from 1210 mA to 710 mA
	at 22:03 when HRR was applied
Well this behavior is similar to what we wrote for SB0W2 but 
here it is NOT happening for the full wedge at the same 
time so it is a little puzzling.


</pre>

<!-- Comment: Mon Jan 14 23;25;42 comment by...David -->
<P>
No, we need to understand what happened, even if it recovers ok. Like all problems, this needs to be reproduced, understood, and fixed, not just recovered. I think catching the correlation with HRR is a good first step, and checking further for correlations would be good, though not all ladders in both IB4W1 and SB0W2 need be exposed for this test.
<P>
When we push in an init bitstream, does the old bitstream get pushed out so it can be read? If so, we might be able to check this.
<P>
Gino's pitwib should be brought online soon to debug these types of problems.
<P>
 


<!-- Comment: Tue Jan 15 00;16;06 comment by...Commitee against the pitwib -->
<pre>How can the pitwib debug this problem when only a few ladders
out of several 100's recieving an HRR AT THE SAME TIME
display this problem at any one time? </pre>
<!-- Date: Mon Jan 14 23:37:44 2002 -->
<pre>SB5W8L2 Bias current: 
PINK on IMON. Probably since a long time 
Looking at AUke's plots there is a sudden change in the current  
around 10 am on 01/13/2002. There is not a correlated chnage in voltage so I cannot explain what is going ON. 
The change is from 400 to 600 uA. 
We should look at this device OFFLINE.  
</pre>
<!-- Author: gino -->


<!-- Date: Mon Jan 14 23:48:53 2002 -->
<pre>ADDED a postit to the list of PINKs to be ignored by the monitoring ACE. 
The devices included on the postit are: 
SB5W8L2 BIAS current due to the previous entry 
SB0W2L0,1,2,3,4 AVDD current problem described before. 
 
I hope this postit is taken away tomorrow. 
</pre>
<!-- Author: Gino -->


<!-- Date: Tue Jan 15 00:10:19 2002 -->
Instructions for COs regarding SILIMON are <a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=42&frame=2&anchor=23:47:28'> 
here </a>  
 
<!-- Author: Mary  -->


<!-- Date: Tue Jan 15 00:11:09 2002 -->
Instructions for Monitoring ACE are <a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=42&frame=2&anchor=00:07:48'> here </a> 
<!-- Author: Mary Bishai -->



<!-- Date: Tue Jan 15 04:10:18 2002 -->
<pre>Trying to turn the Silicon back on: 
 On the Java GUI 3 bulkheads couldn't be turn directly on 
(B0,B2 and B3) because they looked like being on (On button was set); only the PCs were really on; looks like a GUI bug (Andrew, please have a look at this problem as soon as possible); I had to  
turn these bulkheads channel by channel (a time consuming solution, somebody knows a better one ?)  
 Two channels I tried to turn them on were jumping back on Standby( B1W7Channel3 and B0W7Channel 4);  
 SB0W3L3 went on bias overcurrent, I have reduced the voltage to 60 V instead of the nominal 100 and worked;   
 Also I had to turn on the ISL manually, I tried from GUI, but didn't work(a GUI bug !? or it is suppose to work like this) 
Now the Silicon is integrated in the run 137026</pre>
<!-- Author: Mircea Coca -->
<!-- Comment: Tue Jan 15 09;57;36 comment by...Petra -->
<pre>a better solution (but the bug needs to be fixed!):
turn the offending bulkheads first from ON to SB and then back to ON</pre>
<!-- Comment: Tue Jan 15 15;33;24 comment by...Mary -->
<pre>The fix is simple:

Only system on/stdby and lower granulaities actually checks 
powerset.dat. And so PCs on wedges with no ladders are turned
on when you do a bulkhead by bulkhead turnon or higher
granulaity. COULD WE HAVE EVERYTHING UP TO A WEDGE check
powerset.dat! </pre>
<!-- Date: Tue Jan 15 04:24:08 2002 -->
<pre>&lt;BR&gt;B2W8L3 turned to pink 
&lt;BR&gt;it is not on the list which can be ignored 
&lt;BR&gt;AVDD 520(815) 04:14 
&lt;BR&gt;DVDD 290(13)  04:13</pre>
<!-- Author: jy -->
<!-- Comment: Tue Jan 15 04;24;33 comment by...jy -->
<pre>(130) not (13)</pre>


<!-- Date: Tue Jan 15 04:48:48 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-265&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-265  width='300' align='top'></td><td>b0fib02 crate got stuck due to a readout problem. Called Steve Nahn who wanted to get this plot in elog... </a></td></tr></table>
<!-- Author: Mircea C -->


<!-- Date: Tue Jan 15 04:58:12 2002 -->
We see that half of the Silicon barrel 0 appears to be off -- this from viewing HitmapRphiCanvas in SiliMon (see ~cdfdap/questionPlots/silimon_15Jan2002_owl_01.ps).  The problem was solved by rebooting fib crate b0fib02.
<!-- Author: Bruce Knuteson -->
<!-- Comment: Tue Jan 15 13;25;46 comment by...SCN -->
<pre>Hmm, don't think this was the solution, unless it is also
true of barrel 1...</pre>

<!-- Comment: Tue Jan 15 15;30;15 comment by...Mary -->
<pre>A coldstart didn't work?</pre>



<!-- Date: Tue Jan 15 17:42:23 2002 -->
<pre>Bias control from iFix HV summary page is working again. 
Apparently a buggy version of the page had been loaded.</pre>
<!-- Author: Andy H. -->


<!-- Date: Tue Jan 15 19:46:58 2002 -->
<pre>I see that 2 additional ladders have been taken out. 
Not a word in the logbook. 
it's so nice ! 
 
SB1W4L1  SB1W4L2 what was wrong with them ?</pre>
<!-- Author: Saverio -->
<!-- Comment: Tue Jan 15 19;51;56 comment by...Sav -->
<pre>Also SB2W7L4 is back in. </pre>


<!-- Comment: Wed Jan 16 07;21;30 comment by...A careful and less hasty reader -->
No, not ONE word, <a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=91&frame=2&anchor=17:15:35'>
many</a>!   How's that humble pie taste? 

<!-- Date: Tue Jan 15 19:59:52 2002 -->
PS GUI work:</p> 
1) In addition to global L00, SVX, ISL buttons, "Barrel" and  
"Bulkhead" turn on only wedges specified in powerset.dat. 
This should eliminate situation with PCs being ON, while layers 
are OFF.</p> 
2) The ISL B2 bug removed. ISL Central Barrel can be turned ON 
using global ISL button from now on.</p> 
3)<a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=90&frame=2&anchor=19:06:38'> 
Spontaneous turning on </a> can be explained as follows:  
External trip happened on IB5W0 PC. Normally CAEN should trip all 
IB5W0 layers so that they also must have been in trip status. But  
at the same time the GUI was processing PS information, found a  
trip on PC and assumed that the entire wedge must be OFF. Since 
CAEN did not trip the entire wedge yet, it was still in STANDBY.  
The GUI turned off layers reporting spontaneous transition.  
My opinion is that it is quite normal except for confusing message. We put an additional message on server side, which will report what layers are in trip status. This message will appear again and again until the trip is cleared. Eventually the plan is to eliminate message about spontaneous turning on in case if the GUI itself took care of the trip.
<!-- Author: Andrew & Doug -->
<!-- Comment: Tue Jan 15 20;53;50 comment by...David -->
<pre>This behavior makes sense if the bias was on. Since it takes a while for the bias to ramp down, the PC could get off a second or two before the layers do. Did this happen when biased?</pre>


<!-- Comment: Wed Jan 16 08;49;37 comment by...Andy H. -->
<pre>Yup... it happened when we went from ON to STBY.</pre>
<!-- Date: Tue Jan 15 21:12:12 2002 -->
<pre>B2W4 and B3W4 are still "ON" in that their portcards are on but no ladders are on and the wedges are not in powerset.dat. So, after verifying with Jean, I turned the PCs off. Now the GUI no longer says that anything is on, everything is in standby. 
</pre>
<!-- Author: David -->


<!-- Date: Tue Jan 15 21:13:01 2002 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Plan 
----- 
Tuesday Evening 
  1. 18:00-21:00 GUI work - Andrew and Doug - Done 
  2. 21:00 - ??? David - ISL/L00 integration, checking 
Wednesday 
--------- 
  1. 9:00 AM - IIya, Steve T. - Readall Hardware event 
                builder debugging 
  2. ?? X-mode run - Steve N. assuming he is still here 
  3. re-integration of SVX - Lester 
  4. 16:00-20:00 controlled access - pwer supply jumpering 
  5. if still quiet time - full D-mode calibration. 
  6. what have I forgotten?</pre></td></tr></td></table>
<!-- Author: Jean -->


<!-- Date: Wed Jan 16 01:19:32 2002 -->
I integrated some more ISL ladders. The details are 
<A HREF="http://ncdf17.fnal.gov/cgi-bin/lgbk?user=stuart&ent=14139"> 
here</A>. 
The summary is: 
<P>The following ladders have been newly integrated: IB0W0L4, IB0W1L4, IB0W4L0, IB0W4L4, IB5W2L4, IB5W3L2, 
IB5W4L0. 
 
<P>The following can be integrated with some work: 
<UL> 
<LI> B1W0Lx no power supply 
<LI> B1W1Lx no power supply 
<LI> B4W1Lx low current from HRR? Off until that is fixed 
<LI> B5W3L0 High current, no init. Appeared after Oct access. Need JC bore work. 
<LI> B5W4L4 DVDD OC trip. Appeared after last access. Need bore access to fix. 
</UL> 
 
<P> 
The following ladders are the final dregs which are probably hopeless: 
<UL> 
<LI> B1W2L4 Priority problem after 4 chips 
<LI> B5W1L0 Dead DOIM 
</UL> 
  
<!-- Author: David -->


<!-- Date: Wed Jan 16 01:39:23 2002 -->
<pre> 
The effect of HRR is pretty clear when watching IMON. A HRR causes a wave of yellow (and a little pink) to wash across IMON when halted. It goes green again when recovered. So, the two wedges with the persistently low currents are not the only ones having problems from this, just the most sensitive. 
 
Even while waiting for a PITWIB, I think we should connect a blinkly light board to the PITWIBs fib cable and see what is happening to the chips ASAP. 
</pre>
<!-- Author: David -->




<!-- Date: Wed Jan 16 09:45:24 2002 -->
<pre>IMon "RED" color in only DVDD of SB1W9L2. 
The latest value of this DVDD current was 0.029 mA. 
But we could not see any trip in the PS Gui. 
It seems that it is still biased on stantby. 
After talking with Jean, we decided "unmark" of this ladder. 
Now it is fine.</pre>
<!-- Author: Soushi -->


<!-- Date: Wed Jan 16 15:07:16 2002 -->
<P> 
I have set all 4 of the currently powered L00 wedges (f84x,f85x,fa0x,fa4x) into 
latch all, DPS off, BW=3. I also set RAMPPED=13 on some of the 
chips which need it. 
<P>  
<!-- Author: David -->


<!-- Date: Wed Jan 16 15:46:08 2002 -->
<P> 
I have fixed the ISL isel bits to be (I think) correct. The previous cloning attempt generated some mutants. 
<P> 
I have set IB2W0L4, IB1W4L4, IB1W5L0, IB1W5L2 to be latch all, DPS off. 
<P> 
<font color=red>PLEASE DO NOT USE CLONING WITHIN AN HDI ON ISL</FONT> now since it will override some of the chip specific ISEL settings and mess up the charge collection. 
Things like bandwidth and threshold can be individually cloned with the specify stuff at the bottom of the HWDB. 
<P>
<!-- Author: David -->


<!-- Date: Wed Jan 16 17:13:57 2002 -->
<pre> 
IB5W5L4 has been having errors since the previous access (when an RX was swapped on a different HDI in that FTM). I cleaned and regreased the DOIM connection. This could fix it, do nothing, or cause the init bit to go bad... 
 
</pre>
<!-- Author: David -->


<!-- Date: Wed Jan 16 18:44:01 2002 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Run plan from Doug g. 
 
Jay,  here's the list of our special runs, along w/ many specifics. 
  Please have the shift crew page lester miller (218.9611) about 45 
  minutes prior to collisions.  they should also understand that in 
  between runs he'll need some time to change the silicon chip parameters 
  and take a couple calibration runs prior to re-integrating the silicon 
  in the data taking. 
 
--------------------------- 
 
 
  Executive Summary:  we need about 10-15 hours of running time to take 
    a series of runs which scan through SVX chip settings in order to 
    choose the optimal settings based on physics performance.  we'll set 
    a few HDIs into read-all mode.  since we already have an SVX wedge in 
    read-all, and the additional HDIs will be read-out in parallel, this 
    addition shouldn't appreciably affect CDF deadtime.  we'll need to 
    have the magnet and COT ON, the dflt physics trigger table, and would 
    prefer long uninterupted runs to several shorter ones. 
 
  Specifics: 
 
        - set the following wedges/layers in RA 
 
                S-B3W8L0:4  (SVT has masked this wedge off) 
                S-B5W8L0:4  (SVT has masked this wedge off) 
                I-B2W0L4 
                I-B1W4L4 
                I-B1W5L0,L2 
                any available L00 
 
        - during collisions 
 
 
        - detector bias is necessary 
 
        - parasitic to normal data taking 
 
        - require track-trigger, magnet/cot ON, "dflt" physx trigr tble 
 
 
        take the following runs: 
 
        ------ BW SETTING ----- 
              SVX/ISL     SVX 
 
 
        L00   PHI/SAS   90-DEG    DPS    NEVENTS 
        ===   =======   ======    ===    ======= 
     ----- take dps-on and dps-off calibration ------ 
     1.  3       5         4      OFF     450k 
     2.  3       5         4       ON     120k 
 
     ----- take dps-on and dps-off calibration ------ 
     3.  4       6         5      OFF     450k 
 
     ----- take dps-on and dps-off calibration ------ 
     4.  2       7         6      OFF     450k 
 
     ----- take dps-on and dps-off calibration ------ 
     5.  5       4         3      OFF     450k 
 
     ----- take dps-on and dps-off calibration ------ 
     6.  3       5         4       ON     450k  (if time) 
 
          &gt;&gt;&gt; care should be taken that CALIBRATIONS be made 
          &gt;&gt;&gt; BEFORE EACH of the different BW RUNS !!! 
 
          &gt;&gt;&gt; the BW is changed ONLY on these special wedges/layers 
          &gt;&gt;&gt; the rest of the detector is w/ "normal" settings 
 
          &gt;&gt;&gt; using run 128501, we find that CDF collected 450 kevts 
          &gt;&gt;&gt; in about 2.5 hrs of running.  the efficiency was 70% and 
          &gt;&gt;&gt; the inst luminosity was about 5E30/cm^2/s for this run. 
          &gt;&gt;&gt; we thus estimate it will take about 12 hours to get thru 
          &gt;&gt;&gt; the first 5 runs and an additional 3 hours to get thru 
          &gt;&gt;&gt; all 6; we need at least the first 5 
 
  - I verified from SVT that the SB3W8 and SB5W8 were masked-off. 
 
  - if the silicon gets "handshaked" (handshook?) in the middle of the run, 
    YOU NEED TO PERFORM A COLDSTART in order to recover the special ISL 
    low power settings.  this can happen, for instance, if a CAEN power 
    supply trips off and is recovered. THIS IS IMPORTANT!!! 
 
 
 
 
 
</pre></td></tr></td></table>
<!-- Author: Doug G.&#39;s email -->
<!-- Comment: Fri Jan 18 09;55;23 comment by...Doug -->
<pre>We're using a different trigger table from the one used to
estimate how many events we needed.  With physics_0_03, WE NEED
HALF AS MANY EVENTS AS INDICATED ABOVE.  We need about 40/nb at
each point.

</pre>
<!-- Date: Wed Jan 16 18:52:01 2002 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Plans for next day or so: 
-------------------------- 
Wednesday evening - Thursday morning  
-------------------- 
   1. Aaron is doing L00 charge injection for geometry 
   2. Crates that went off to install ISL power 
      supply and SVX jumper need to be turned back on. 
      A fib crate was power cycled: same one as had its 
      CAEN off - it needs maps downloaded and power back on 
   3. 20:00 - Ilya returns with a possible fix to hardware 
      evt builder read all problems 
   3. after Ilya finishes, Lester does integration of 
       SVX final dregs. 
   4. Once store is established and Lester is finished, 
       go on to BW scans as in the message above.</pre></td></tr></td></table>
<!-- Author: Jean -->


<!-- Date: Wed Jan 16 19:06:18 2002 -->
<b>Power Supply stuff done during today's access:</b> 
<ul> 
<li>Installed PS SN#19 into IB1W1.  This is in NW Bot Bot, Slot 3.  Jumpers were inserted which should prevent layer 6 from being turned on.  It was cabled and enabled. 
<li>Changed current jumpering for SB0W3 Layer 3.  It is now jumpered for the coarse current reading. 
<li>Verified that SB0W7L4 and SB1W4L3 are jumperd for the coarse current setting (they are). 
<li><b>Power cycled Fib00</b> per Saverio's request. 
</ul>
<!-- Author: Napora and Cigdem -->
<!-- Comment: Thu Jan 17 07;33;52 comment by...SCN -->
I would like to know why Sav felt it was necessary to 
power cycle this crate.  If it were just because it might
do something, he can have my pager.  By doing so, he
removed the keep-alives and PARSTs from the 90 ladders
served by that Fib crate.  Perhaps they were all off anyway.
<!-- Comment: Thu Jan 17 08;03;13 comment by...Sav -->
<pre>I was only Jean's messenger. Ask Jean and Mary exactly why.</pre>
<!-- Date: Wed Jan 16 19:26:24 2002 -->
<pre>Aaron started having trouble with his L00 geometry runs  
Symptom was fib headers but everything else was garbage. 
For not particulrly good reasons we: 
  1. exited run control 
  2. redownloaded maps using crateLoader to the fib00 that 
     had been power cycled in the access 
  3. rebooted and crateloaded fib_isl_7 - the only fib crate 
     that Aaron had in his run control 
  4. restarted run control and now things are fine again in 
     readall, but not in sparse. 
  5. Aaron didn't try reallall before, so things may not have 
     been helped at all. 
 
Our model is that power cycling fib00 affected things even though 
it was not included in what Aaron was trying to run with.  
Or else it was related to downloading CAEN.map when Rob finished. 
  - that sounds ridiculous.</pre>
<!-- Author: jean -->
<!-- Comment: Wed Jan 16 19;47;41 comment by...jean -->
<pre>When the exact same number of channels have charge injection,
we can readout both hdis, hdi 2 and 3 of LB1W4.  when there are
 different masks for hdi 2 and 3, you 00f3 in hdi 3 which has
 more channels than  hdi 2.  The second event is OK! We 
are probably both hallucinating...
</pre>

<!-- Comment: Wed Jan 16 19;49;32 comment by...jean -->
<pre>137296 is the run number with an example of this.</pre>


<!-- Date: Wed Jan 16 20:19:28 2002 -->
<pre>I think I put the hdwdb back to its original chip settings for the L00 ladders in LB1W4 and LB0W4. 
 
It would be good if someone else could cross check this to make sure I didn't screw it up.</pre>
<!-- Author: Aaron -->
<!-- Comment: Wed Jan 16 21;10;55 comment by...David -->
<pre>Look fine.</pre>
<!-- Date: Wed Jan 16 20:20:56 2002 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>I accidentally rebooted b0fib07 by hitting ctrl-x while in minicom.  Bummer. 
 
I downloaded the maps after it came back. 
 
Sorry about that...</pre></td></tr></td></table>
<!-- Author: Aaron -->


<!-- Date: Wed Jan 16 20:43:12 2002 -->
<pre>Aaron put the hardware database back together again.  I checked 
it by comparing a "remains" listing from the hardware database 
with the printout I had from this afternoon and it agrees. 
 
I then turned on all of teh wedges that had been off because the SVX adn ISL caen crates were turned off. 
 
 
 </pre>
<!-- Author: Jean -->



<!-- Date: Wed Jan 16 21:12:20 2002 -->
<P> 
I backed out the L00 rampped changes, (13 instead of 6). They cause the init readback to fail. I recall seeing this way back at sidet (in the previous millenium), and being told it was a bug in the readback comparison that hadn't been fixed for lack of a need. There is now a need.  
<!-- Author: David -->
<!-- Comment: Mon Jan 21 13;02;27 comment by...SCN -->
<a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=93&frame=2&anchor=12:59:35'>
Done</a> 

<!-- Date: Thu Jan 17 00:58:37 2002 -->
<pre>SVX Ladders still out (31 of them) 
 
Power problems: 
---------------- 
SB0W1L4         AVDD 
SB0W8L3         BIAS 
SB0WBL1         BIAS   
SB0W6L3         DVDD 
SB1W3L0         BIAS 
SB1W4L3         BIAS (taken out tonight) 
SB2W5L4         DVDD 
SB3W1L4         BIAS 
SB3W2L2         DVDD 
SB3W7L2         BIAS 
SB5W3L2         DVDD 
 
Other: 
--------------- 
SB0W6L0         Dead FE  
SB4W0L2         reformatter (leading 00) 
SB1W7           PRD2 
SB2W4           Command cable 
SB3W4           Command cable 
SB0W3L4         No INIT, DVDD 1050 (drops RO z side)  
SB1W4L1,2	VRB header problem 
 
=============================== 
I just integrated: 
 
other 
--------------- 
SB0W5L1         DRO     (chip 85) [obdv] 
SB0W7L4         BIAS    (should try bias by hand) 
SB1W0L3         OBDV 
SB1W5L4         BIT     (bit 2 high) 
SB1W6L0         ?? 
SB2W6L3         OBDV    (c4c4c4c4) 
SB2W7L1         BIT     (bit 1 0uW) 
SB2W8L0         BIT     (bit 1 hi) 
SB3W6L4         CapID chip 8, DRO, AVDD2?, 'burnin?' 
SB3WBL3         BIT     (bit3) 
SB4W1L4         BIT 
SB4W2L0         VRB 
SB4W4L4         BIAS 
SB4W7L2         DRO     (lclc) 
SB4W8L1         DRO     (data only -- HST ok) 
SB4W9L0         BIT 
SB4WAL4         OBDV    (DRO lclc?) [dro] 
SB5W5L3         BIT 
SB5W9L2         BIT 
SB5WBL0         BIT     (bit 0 hi) 
 
AVDD2  
---------------- 
SB0W0L2 (already was in) 
SB0W1L2 
SB0W3L2 (already was in) 
SB0W6L2 
SB0WAL1 (already was in) 
SB1W1L3  VARYING I_AVDD  
SB1W8L2 
SB1WBL1 (already was in) 
SB2W9L4 (already was in)  
SB3W3L0  INCREASING I_AVDD 
SB3W3L4 
SB3W5L1  INCREASING I_AVDD  
SB4W3L2 
SB4WBL2 (already was in) 
 
Other strange no init or dropped RO 
---------------- 
SB4W5L4         OBDV    [Init] 
SB4W6L3         INIT 
SB5W1L4         DRO     (chip a6) [Init] 
 
================================= 
 
Had to mask readback for SB4W6L3 and SB3W3L4 
I took a few hundred SEVB events no problems. 
 
</pre>
<!-- Author: Lester -->


<!-- Date: Thu Jan 17 00:59:03 2002 -->
<pre>Integrated IB1W1 with no problems</pre>
<!-- Author: Lester -->


<!-- Date: Thu Jan 17 01:00:57 2002 -->
<pre>SVX IFIx went yellow. A temperature sensor on bulkhead 2 
was measuring 24.6 degrees (SVX_TE_PCW1A_2). Andy helped me 
change the limit for this sensor to 27 (it has its own limit). 
</pre>
<!-- Author: Lester -->


<!-- Date: Thu Jan 17 01:01:39 2002 -->
<pre>MonAce paged me because SVX_TE_PCW1A_2 was 24.6 deg and yellow in iFix.  I had Lester raise the trip limit for this guy from 25 to 27 deg C to keep us from tripping.  It's still yellow but I'll deal with that tomorrow.</pre>
<!-- Author: Andy H. -->
<!-- Comment: Thu Jan 17 01;03;34 comment by...Andy H. -->
<pre>Whoops!  Redundant post!</pre>


<!-- Comment: Thu Jan 17 12;02;40 comment by...Andy H. -->
<pre>OK, iFix warning limit for this RTD now at 25, alarm limit at 26.</pre>
<!-- Date: Thu Jan 17 01:05:39 2002 -->
<pre>(Yes this is a backlog of entries) 
 
During shot setup we lost b0fib03 power supply. 
I turned off the affected ladders and took all fib's 
in this crate offline (in retrospect not necessary maybe.) 
 
Miraculously none of the BW scan ladders are in this crate,  
so we're still in business.  
</pre>
<!-- Author: l -->


<!-- Date: Thu Jan 17 01:11:45 2002 -->
<pre>Finally, set up for first run: 
all L00 
SB3W8 
SB5W8 
IB2W0L4 
IB1W4L4 
IB1W5L0,2 
 
	-------- BW --------------- 
DPS 	L00 	SAS/PHI		90 
----------------------------------- 
OFF/RA	3	5		4 
 
I found ISL and L00 already in this state (thanks Dave) 
Changed SVX. I find that cloning phi or z side works! 
 
For reference, ISL cloning parameters: 
 
HDI	Bulkhead	SuperPhi	Layer 
---------------------------------------------- 
f204	2		8		5 
f144	1		28		6 
f150	1		30		6 
f152	1		32		6 
</pre>
<!-- Author: Lester -->
<!-- Comment: Thu Jan 17 03;03;36 comment by...L -->
<pre>Calibrations:
DPS on  137337
DPS off 137338

Taking data at 15 Hz (~8hrs for 450k events!)
</pre>


<!-- Comment: Thu Jan 17 06;56;41 comment by...lhm -->
<pre>The transfer of data seems to have stopped early in the transfer
of 137340, with little of either calibration getting over 
either. It's all intact at B0, however.</pre>
<!-- Date: Thu Jan 17 04:30:02 2002 -->
On the SiliMon display, zero ADC counts are observed in: IB4W3L0*, IB4W3L2*, IB4W3L4*, IB5W3L2*, IB5W5L4*, and many in SB[0-5]*.  
<!-- Author: Bruce Knuteson -->


<!-- Date: Thu Jan 17 06:32:59 2002 -->
Stuck bit warnings observed with SiliMon for chips 
SB2W5L0PC0(176), SB2W7L1PC0(510), SB5W9L2PC0(1163), and SB4W6l3PC[0-4] (1908-12) during Run 137343.
<!-- Author: Bruce Knuteson -->




<!-- Date: Thu Jan 17 07:46:44 2002 -->
<h3>Some info for <B>HALT</B></h3> 
Yesterday I set up a LA on the 2nd floor test crate and looked 
at the end of a Fib Timing cable via the Blinky board, as well 
as at the Fib Commands coming out of the SRC.  In normal running, 
I saw PARSTs (CMD 0x62 and 0x64) coming out of the SRC and 
getting to the Blinky Board.  I also saw the keep alives 
on the Blinky Board (a PRD2, and some BE Clocks)  
(I did not look for them explicitly in 
the SRC).  Then I told the SRC to <B>HALT</B> (via svxdaq). 
The keep-alives and PARSTs were not observed coming out of the 
SRC nor on the Blinky Board. FE CLOCKS were still there.  My conclusion:<P> 
<I>Neither PARSTs nor keep-alives are sent by the SRC when it is 
in the HALT state</I><P> 
Is this enough to cause the "waves of yellow and pink"?  What 
happens to the current when the preamps are saturated?  The lore 
of the keepalive so far is that only "some" ladders need them, 
but maybe this is just a function of time-any of them will trip 
if the keep alives are withheld for a significant amount of time. 
<P> 
Unfortunately, we will lose the ability to study this because the 
VME PS in the test crate will be removed to replace b0fib03, 
which is now dead.  Yes, one might use the pitwib-have fun. 
<!-- Author: SCN -->
<!-- Comment: Thu Jan 17 10;22;05 comment by...SCN -->
More on Halt <P>
I went back to find out when Bill A was pulling CDF Error.
Looks like run 136264 (at least).  Here's a snippet of the 
Error file<pre>
(RC)   20:42:29 Config -> READY
(RC)   20:42:55 Activate -> ACTIVE
43'1" 1 crate/s: b0svt06(124),  in error.[RXPT]
(MLE) b0dap59.fnal.gov:AWT-EventQueue-0:8:43:01 PM->Errors reported by the Trigger Supervisor:
  Partition Error XPT

"If you think it's a problem with the Trigger Supervisor, think again!"

(RC)   20:43:17 Halt -> HALTED
(RC)   20:43:24 Recover -> RECOVERED
(MLE) b0tsi00:Messenger:8:43:27 PM->TS failed to Recover (State 2)
43'29" 2 crate/s: b0svt03(125), b0svt05(126),  in error.[RXPT]
(MLE) b0dap59.fnal.gov:AWT-EventQueue-0:8:43:30 PM->Errors reported by the Trigger Supervisor:
  Partition Error XPT

"If you think it's a problem with the Trigger Supervisor, think again!"

46'16" 2 crate/s: b0svt03(125), b0svt05(126),  in error.[RXPT]b0dau32.fnal.gov:csl_mon_send:8:46:12 PM->Data file for partition 0, run
 136264 was closed with zero events.
 [MLW]
46'16" 2 crate/s: b0svt03(125), b0svt05(126),  in error.[RXPT]
46'16" 2 crate/s: b0svt03(125), b0svt05(126),  in error.[RXPT]b0dau32.fnal.gov:csl_mon_send:8:46:13 PM->Data file for partition 0, run
 136264 was closed with zero events.
 [MLW]
46'20" 2 crate/s: b0svt03(125), b0svt05(126),  in error.[RXPT]
(RC)   20:46:33 Abort -> IDLE
</pre>
What I see<ul>
<li> 20:43:01 CDF Error (and therefore TS HALT) pulled
<li> 20:43:24 Ace attempts to get to RECOVER, but TS fails!
Potentially means no RECOVER was sent to SRC
<li> 20:46:33  Ace use ABORT to get RC back to IDLE. It is my
recollection (to be checked, for sure) that when RC issues
ABORT (or END) the VME controller makes the SRC stop listening
to the TS, and issues a HRR.
</ul>
Next run there were some issues with tripped Si (not everything)
<pre>
Partition:0 Run number: 136265 (0x21449)
(MLE) b0fib03:Messenger:8:47:41 PM->Error Initializing HDI Slot 12 Chan 6: ISL B2W3
(MLE) b0fib03:Messenger:8:47:41 PM->Statechange failed
(MLE) b0fib02:Messenger:8:47:46 PM->Error Initializing HDI Slot 18 Chan 0: SVX B2W6
(MLE) b0fib02:Messenger:8:47:46 PM->Statechange failed
</pre>
Next as well, but they were overcome, and again SVT pulls error
<pre>
(MLE) b0fib03:Messenger:8:49:59 PM->Error Initializing HDI Slot 12 Chan 6: ISL B2W3
(MLE) b0fib03:Messenger:8:49:59 PM->Statechange failed
(MLE) b0fib02:Messenger:8:50:05 PM->Error Initializing HDI Slot 18 Chan 0: SVX B2W6
(MLE) b0fib02:Messenger:8:50:05 PM->Statechange failed
...
(RC)   20:53:34 Config -> READY
(RC)   20:53:52 Activate -> ACTIVE
(MLE) b0dap59.fnal.gov:AWT-EventQueue-0:8:53:55 PM->Errors reported by the Trigger Supervisor:
  Partition Error XPT

"If you think it's a problem with the Trigger Supervisor, think again!"

53'56" 1 crate/s: b0svt06(124),  in error.[RXPT]
(RC)   20:54:15 Halt -> HALTED
(RC)   20:54:23 Recover -> RECOVERED
(MLE) b0tsi00:Messenger:8:54:26 PM->TS failed to Recover (State 2)
(MLE) b0dap59.fnal.gov:AWT-EventQueue-0:8:54:27 PM->Errors reported by the Trigger Supervisor:
  Partition Error XPT

"If you think it's a problem with the Trigger Supervisor, think again!"

54'29" 2 crate/s: b0svt03(125), b0svt05(126),  in error.[RXPT]
55'22" 2 crate/s: b0svt03(125), b0svt05(126),  in error.[RXPT]b0dau32.fnal.gov:csl_mon_send:8:55:19 PM->Data file for partition 0, run
 136266 was closed with zero events.
 [MLW]
55'26" 2 crate/s: b0svt03(125), b0svt05(126),  in error.[RXPT]
(RC)   20:55:41 Abort -> IDLE
</pre>
Same exact progression of events, this time SRC got HALT at
20:53:55 and got out of HALT at 20:55:41<P>
Next Run, for those paying attention still, the Si was BUSY,
but it looks to me that the HEVB didn't see any events <pre>
(EOR) EVB: rundb.HardEvbSummary@80d3862
  RunNumber             136267
  PartitionId           0
  nEventsInput          0
  nEventsOutput         0
  nEventsError          0
  FlushedOrRejected     0
  LoadingErrors         0
  SendingErrors         0
</pre>
Maybe it needed to be cleaned up-maybe it doesn't like CDF ERROR
either?<P>
After that, all sorts of weirdness ensued, not related to CDF Error...Anyway, normally when we do HALT-RECOVER-RUN, we spend
at most 1 sec in the HALT state.  In these instances my guess
is that was increased to 2-3 minutes, not because of slow reaction time of the ACE, but (maybe) due to some failure in
the TS crate actually sending the signal.  Due to sequencing
of RC commands, it is probable b0svx02 never even saw the RC
recover command.
<!-- Date: Thu Jan 17 09:03:30 2002 -->
<pre>Instantaneous luminosity is low (2E30), so we are getting 
data for the bandwidth scans at ~10Hz.  This means that the run  
plan will be stretched out over several stores instead of being  
completed during this store. 
</pre>
<!-- Author: Jason -->