<!-- Title: 08:56:42  Mon Aug 27 2001 -->
<!-- Crewchief: Jean & Sons -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>RUN TOO !!</pre>


<!-- Date: Mon Aug 27 10:58:37 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>PLAN for tiday(?): 
 
1) After CDF timing is restored. Take some 
data and especially check if ISL is OK again 
 
2) Timing scan (Lester) 
 
3) set everything back to BW=5 </pre></td></tr></td></table>
<!-- Author: APC & Doug -->
<!-- Comment: Mon Aug 27 13;46;44 comment by...doug -->
<pre>prior 1), verify ISL pipedepth correctly set.</pre>


<!-- Date: Mon Aug 27 13:56:26 2001 -->
<pre>so, all ISL polarities were switched (except on HDIs numbered 4) 
when moving to BW=2.  thus the poor ISL performance over the  
wkend.  Ought be fixed now (David looking at present run 124792). 
Kirsten testing new trig table for 1/2-hour in meantime.   
Afterwards, Lester+David will integrate/test L00, then timing 
scan. 
 
</pre>
<!-- Author: Doug -->
<!-- Comment: Mon Aug 27 13;59;54 comment by...Petra -->
<pre>how did I mess this up? is that clear to anybody?
had some difficulties with the java GUI (didn't change the 
BW for all I wanted, so did it fib by fib)...</pre>


<!-- Comment: Mon Aug 27 15;37;25 comment by...David -->
<pre>
ISL now looks fine in Run 124792.
</pre>
<!-- Comment: Mon Aug 27 17;18;25 comment by...SCN -->
Found Pilot Error + Bug can cause this...
<ul>
<li>Pilot Error is using the "Copy Selected Wedges" Button,
which copies <B>ALL</B> parameters (polarities etc) from the 
port card displayed to the selected portions of portcards,
using a 1-1 match of HDIs (modulo 5)
<li> Bug is under this code I had:<pre>
int copyChan = Chip.currentChip().hdiNum/5 + hdiAddr%5;</pre>

where hdiAddr is the hdi you are copying to but hdiNum/5 was suppossed to represent the portcard you were copying from.
This works fine if hdiNum < 5, but if not, you shift
the hdis by 1.  The code should be:<pre>
int copyChan = 5 * (Chip.currentChip().hdiNum/5) + hdiAddr%5; 
</pre>
In SVXII, you get all sorts of warning when this screws up
because the GUI complains when you replace the number of
chips with a different number.  In ISL, all hdis have the
same number of chips.  I just reproduced the problem, seems
consistent (I did not write the screwed up config to the hdwdb...)
</ul>

The Solution:
<ul>
<li>Use the "Clone Selected Chips" button<BR>
This button deals with the chips as objects, i.e.
doing things like:<pre>
copyChip.threshold = templateChip.threshold;
</pre> rather than directly changing bits in some 
calculated location in the bitstream, so it is
pretty robust.
<li> Fix bug as above, also warn people if they are
using the copy button that this is rather drastic.
This is done in my version, I'll put it into the 
default version tomorrow
</ul>

<!-- Comment: Tue Aug 28 10;11;51 comment by...SCN -->
Default Code updated with bug fix and Confirmation Pop-up
window (I hate them, but it seems necessary).
<!-- Date: Mon Aug 27 14:55:54 2001 -->
<pre>Turn on L00 B0W0 and B0W5 in HDWB and PS GUI. 
BW=2, DPSoff, ReadAll 
 
First run taken is 124794. Will check it for validity before timing scan. 
</pre>
<!-- Author: David and Lester -->
<!-- Comment: Mon Aug 27 16;00;07 comment by...David -->
<pre>L00 data looks good. Ready for fine timing scan.</pre>


<!-- Date: Mon Aug 27 16:58:41 2001 -->
<pre>SB2W7 AVDD OC on L3 again.  reset.</pre>
<!-- Author: doug -->



<!-- Date: Mon Aug 27 19:58:55 2001 -->
<pre>taking silicon to standby due to high losses (spikes to 30-40  
kHz). Used monitor ace switch, it worked but noted that L00  
did not go to standby, presumably because it is not in  
powerset.dat. Did that by hand. Also, because I forgot to 
load CAENvolts.dat, it turned on to standby SB4W6 which then  
tripped as previously. 
Perhaps we should make a transition with change to HV only  
depend on the current status rather than the ".dat" files?</pre>
<!-- Author: Lester -->


<!-- Date: Mon Aug 27 20:00:00 2001 -->
<pre>Trying to take timing scan: 
We've tried several runs, they fail with unrecoverable  
BUSY/DONE timeouts with VRB had no event errors.  
Also there is some other message at times about  
double SCPU acknowledgements of event received. 
Had to kick out SB4W6-0 for persistent DVDD overcurrents. 
GUI crashed. 
SB2W7-3 was off for no reason after restarting GUI. 
Took 15k events run 124809 with nominal SVX timing. 
</pre>
<!-- Author: Lester -->


<!-- Date: Mon Aug 27 20:05:31 2001 -->
<pre>During pause SB5W2 software tripped; restarting run when losses  
acceptable 
</pre>
<!-- Author: Lester -->


<!-- Date: Mon Aug 27 21:30:16 2001 -->
<pre>Lost almost all silicon to software trips when changing timing 
from -6 to +2 relative timing. Probably confused the SRC with 
a timing glitch in there. Powered on and eventually got things  
back in shape. 
</pre>
<!-- Author: Lester -->


<!-- Date: Tue Aug 28 00:45:35 2001 -->
<pre>So beam lost to D0 Tev abort at around midnight. 
 
Finished with the scan then: 
 
run 	relative time	delay (ns)	number events	 
------------------------------------------------------ 
124809	nominal		95		15k 
124816	-2		93		20k 
124817	-4		91		20k 
124818	-6		89		13k 
124822	-6		89		10k 
124824	+2		97		20k 
124825	+4		99		20k 
124826	+6		101		20k 
124828	+8		103		20k 
124829	+10		105		20k 
124830	+12		107		20k 
 
</pre>
<!-- Author: Lester -->


<!-- Date: Tue Aug 28 01:19:39 2001 -->
<pre>Trying to take calibrations. 
NOTE: I FOUND THE ISL N STANDBY WHEN BEAM DUMPED. 
So I don't know if the later timing runs have ISL. I hope 
so. 
 
Had to remove SB0WA-0, SB3W5-0, SB2W7-0, SB0WB-0 all for persistent DVDD overcurrents. I think switching through large swings in the timing tends to make the silicon very unhappy... 
Probably all four wedges taken out tonight could be put back in  
eventually. 
 
EVB proxy died first try. 
 
124843 DPS on 
124846 DPS off 
 
Took L00 out. 
</pre>
<!-- Author: Lester -->
<!-- Comment: Tue Aug 28 01;27;43 comment by...Lester -->
<pre>put detector to standby. I believe these overcurrent problems
are connected to the GUI, not to the ladders, in that it seems
the GUI remembers the trips and is not actually turning the 
ladders back on.

The GUI had java exceptions three times tonight.
</pre>


<!-- Date: Tue Aug 28 07:55:18 2001 -->
<pre>** 10 hardware trips this night 
 
** last 3 (JUST) after Lester left 
	SB2W7DVDD0 
	SB0W11DVDD0 
	SB0W10DVDD0 
	-&gt; this are X'ed and have onlineflag=0 in hdwdb 
	   -&gt; is this new ? 
 
** cratematch spot SB4W6L0 to be OFF (while is ON) 
   -&gt; checked the hardware database and foud that  
      cratematch is right (what's goig on !) -&gt; BAD 
   -&gt; I put an X in CAENvolts.dat 
 
** is this right ? [i'm no more sure...] 
&gt; cd $CAENCONTROL_DIR 
&gt; ls -l CAENvolts.dat 
lrwxrwxrwx   1 svxii    cdf            21 Aug 20 20:36 CAENvolts.dat -&gt; CAENvolts_01Aug17.dat 
 
-&gt; DID SOMEBODY CHANGE OR MODIFY CAENvolts.dat or is symbolic    
   link ?    
 
** resetted trips 
 
** took silicon crate in a separate partition 
   and ColdStart for fun</pre>
<!-- Author: francesco -->
<!-- Comment: Tue Aug 28 11;55;16 comment by...Lester -->
<pre>To quote from the immediately preceding entry to this logbook:

"Had to remove SB0WA-0, SB3W5-0, SB2W7-0, SB0WB-0 all for persistent DVDD overcurrents."
</pre>
<!-- Comment: Tue Aug 28 20;37;50 comment by...francesco -->
<pre>** Sorry Lester i didn't had time to read the log when 
   i wrote this entry</pre>
<!-- Date: Tue Aug 28 09:42:16 2001 -->
<pre>We really have to try to keep track of the new ladders which get excluded  
all the time. Otherwise Valeria's work will start from scratch!  
An entry in the portcard elog would be the best (only) solution.</pre>
<!-- Author: Petra -->




<!-- Date: Tue Aug 28 13:16:34 2001 -->
<pre>Changed bandwidth on ISL and SVXII to 5 on all chips.  
LEFT L00 AS IS (BW=2 ALL CHIPS). 
 
(I forgot to change this last night; no physics has happened  
since last night, however.)</pre>
<!-- Author: Lester -->


<!-- Date: Tue Aug 28 14:53:27 2001 -->
<pre>silicon calibrations taken: 
 
124935 DPS off 
124921 DPS on 
 
all was quiet.</pre>
<!-- Author: Lester -->


<!-- Date: Tue Aug 28 15:00:56 2001 -->
<table><tr><td><a href=/elog/notebooks/silicon/Tue_Aug_28_2001_150043.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-162  align='top'></td><td>This is what I see in the offline event display from a run  which had silicon integrated. It's probably known, but why does  it look so shitty? I think online it's fine?!</a></td></tr></table>
<!-- Author: Petra -->
<!-- Comment: Tue Aug 28 15;43;44 comment by...Lester -->
<pre>That's about the time I was taking DPS off readall calibration...</pre>

<!-- Comment: Tue Aug 28 15;45;05 comment by...Lester -->
<pre>oops sorry offline. Ignore that</pre>



<!-- Date: Tue Aug 28 20:45:36 2001 -->
<pre>** store 661 
 
** p_loss~7.8 pbar_loss~2.6 L~6.9E30 -&gt; ok to turn ON 
 
** problems from STDBY -&gt; ON 
	 
   SB0W6L4 ext trip VBIAS -&gt; back on -&gt; Idvdd~105uA Iavdd~555uA  
   SB4W1L2 ext trip DVDD  -&gt; back on -&gt; Idvdd~130uA Iavdd~395uA 
 
** take Si in separate partition -&gt; ColdStart 
 
** give detector to aces -&gt; run 124958</pre>
<!-- Author: Francesco -->
<!-- Comment: Tue Aug 28 21;03;29 comment by...francesco -->
<pre>** went trought flying wires (@46 after hour) biased without
   trips

** 374 Ref.Errors from SB5W2L0 (not yet excluded from run)

** 19% && 14% occupancy from ISL L6F and L6B respectively
   -&gt; something wrong with chip par ? -&gt; page Si DAQ
  </pre>

<!-- Comment: Tue Aug 28 21;47;39 comment by...francesco -->
<pre>** while i was at the phone with Petra beam dump (quench)

** Silicon back to STANDBY (sorry maybe i could have take   
   calibration run... )

** took Si crate in a separate partition and issue 2 ColdStart
   [maybe it helps to prevent High I states]

PS: the occupancy i quoted before comes from SVXMON</pre>

<!-- Comment: Wed Aug 29 09;55;34 comment by...Petra -->
<pre>and we checked some of the chip parameters through the phone, they 
seemed to be fine.</pre>


<!-- Date: Wed Aug 29 10:14:14 2001 -->
<pre>** SB3W1L4 Software Protection Trip that turn off the port-card 
   and so the entire wedge 
   -&gt; back to STDBY -&gt; L4dvdd~165uA  L4avdd~530uA</pre>
<!-- Author: francesco -->


<!-- Date: Wed Aug 29 10:37:44 2001 -->
<pre>** SB2W7L3 AVDD overcurrent 
   -&gt; back to STDBY: I_dvdd~80 uA  I_avdd~510uA</pre>
<!-- Author: francesco -->


<!-- Date: Wed Aug 29 12:12:06 2001 -->
<pre>** store 665 
 
** p_loss~8.2KHz  pbar_loss~2.9KHz  L~8.3E30 -&gt; ok to turn ON 
 
** detector biased and ColdStart issued immediately after the 
   end of the transition. Also runned for ~2K events with 
   software EVB 
 
** ext trip on VBIAS for SB0W7L1 
   -&gt; back to STDBY -&gt; back to ON (I_avdd~240uA and I_dvdd~84uA) 
 
** ColdStart again -&gt; will give crates to aces</pre>
<!-- Author: Petra, Francesco -->


<!-- Date: Wed Aug 29 16:40:55 2001 -->
<pre>short summary from the afternoon mess: 
======================================= 
 
**had ten-thousands of reformatter errors according to shift        crew, which excluded us from running then, which then caused a    wedge to trip. 
**in addition we were causing continuous done and busy timeouts,  
  which Steve then traced back to one wedge (I think it was         SB2W7) causing read busies, excluded this wedge (had only two  
  ladders left anyway :( 
**Steve and Francesco brought then the rest back to stable          running in our own partition and with the SEVB; after a while  
  the shift crew integrated us again. 
**Everything was fine to start with, a flood of RF errors in the  
  beginning of the run, which eventually stopped after a few        minutes. A EVB cleanup made partitioning necessary again, after  
  which certain silicon ladders failed 5 consecutive coldstarts  
  in a row. Just trying it one more time worked finally...No  
  errors then...I escaped... 
 
WE NEED TO HAVE A STRATEGY ON HOW TO UNDERSTAND THESE THINGS,  
WE CAN NOT OPERATE THE DETECTOR LIKE THIS, THE SHIFT CREWS GET  
CRAZY!!! 
</pre>
<!-- Author: Petra -->
<!-- Comment: Fri Aug 31 14;09;27 comment by...doug -->
<pre>Andrew has been asked to investigate the "External Trips" from
the GUI.  Steve has been asked to investigate some of the
reformatter errors.  We likely need more diagnostics to track
down DVDD hi-I states... again, that's Steve.  Repeated failures
of coldstart... Steve.  X-mode... Steve.

Tracking these things down is not easy since they're not readily
reproducible and we've a limited amount of downtime, during which
we're trying to balance many priorities (e.g. calibrations).  
The fact that many depend on the same person slows progress 
further.</pre>
<!-- Date: Wed Aug 29 21:00:38 2001 -->
<pre>I was called to the control room for silicon problems.  
They were having many busy/done timeouts.  
These were coupled with either VME bus errors in the  
VRB crates or a slew of "VRB had no event" errors. 
 
Suspecting that the no event errors are due to silicon missing 
a L2 accept (or evb receiving an extra L2) I checked that the SRC  
and the evb (scpu) were getting identical numbers of accepts,  
which they were. 
 
I left them in this situation; ran out of ideas. I don't think 
it could be a buffer number error, this should not show up at  
the event collection phase. It just seems the SRC command is  
maybe not getting to the VRB's... I checked the command cable 
but it seems OK.</pre>
<!-- Author: Lester -->


<!-- Date: Wed Aug 29 22:48:18 2001 -->
<pre>** a huge (peak~80KHz) and suddenly spike in the losses 
   around 21:21; fortunately the aces react well and put silicon  
   almost immediately to STBY 
   then going to STDBY produces Software protection trips  
   both in SVX and ISL   
   SB4W11L4 -&gt; back to STDBY -&gt; I_dvdd~175uA  I_avdd~535uA 
   IB5W0L0  -&gt; back to STDBY -&gt; I_dvdd~360uA  I_avdd~570uA 
        L1  -&gt; back to STDBY -&gt; I_dvdd~385uA  I_avdd~575uA 
	L2  -&gt; back to STDBY -&gt; I_dvdd~365uA  I_avdd~585uA 
 
** now Silicon is running fine in a separate partition 
 
</pre>
<!-- Author: francesco -->


<!-- Date: Thu Aug 30 08:02:34 2001 -->
<pre>** small collection of errors from run 125064: 
 
 Reject rate: 3.333 percent 
 
 Detector ID not known (yet?). 
 FIB ids found: 
  0xe0a103fc  0x5ef35f06  0x8b158a15  0xc1c10000  0x68046905  0xadeadcdf  0x050706f3  0x59055a02  0x00000003  0xadeadcdf 
 
  SCPU: 13 
  VRB : 5 
  LINK: 1 
  MINI: 0 
 
------------------ 
 Reject rate: 2.128 percent 
 
 Detector ID not known (yet?). 
 FIB ids found: 
  0xadeadcdf  0xe0a103fc  0xe0a203fc  0xe0a303fc  0xe0a403fc  0xadeadcdf  0x881d871d  0x05107004  0x6f187010  0xadeadcdf 
 
  SCPU: 13 
  VRB : 5 
  LINK: 4 
  MINI: 0 
----------------------- 
 
(MLE) b0l3gate1.fnal.gov:main:6:53:32 AM-&gt;Host b0eb17.fnal.gov, task tRec_0 
SCPU-P0-E-BadVrbByteCount: Event 48347 total byte count is lt 32, gt 65528, or not divisible by 8 for VRB in slot 16. 
Count = 51143. 
 
----------------------- 
(MLE) b0l3gate1.fnal.gov:main:6:53:32 AM-&gt;Host b0eb17.fnal.gov, task tRec_0 
SCPU-P0-E-VrbHeader: Dump of header words for event 48347 from VRB in slot 16: 
0xc7c748f3 0xc7c748f3 0xc7c748f3 0xc7c748f3 0xc7c748f3 0xc7c748f3 0xc7c748f3 0xc7c748f3 
----------------------- 
(MLE) b0l3gate1.fnal.gov:main:6:53:33 AM-&gt;Host b0eb25.fnal.gov, task tRec_0 
SCPU-P0-E-VrbReadFailed: Error reading VRB in slot 8 for event 48348. 
The VRB had no event. 
53'34" triggered readout sent events mismatch[EOR]1 crate/s: b0svx02(112),  busy.[RXPT] 
----------------------- 
 Reject rate: 0.526 percent 
 
 FIB ids found: 
  0xadeadcdf  0x74f37506  0xadeadcdf  0x88148714  0x8c148b14  0xe07041fc  0xe07141fc  0xe07241fc  0xe07341fc  0xe07441fc 
 
  SCPU: 13 
  VRB : 3 
  LINK: 0 
  MINI: 0 
 
---------------------- 
 Reject rate: 0.074 percent 
 
 Detector ID not known (yet?). 
 FIB ids found: 
  0xe08076fc  0x52045307  0x4ef34f05  0x75067606  0x04040505  0x12051302  0xe09376fc  0xa21848f3  0x550756f3  0x21f3220a 
 
  SCPU: 13 
  VRB : 4 
  LINK: 1 
  MINI: 0 
 
---------------------- 
 Reject rate: 0.074 percent 
 
 Detector ID not known (yet?). 
 FIB ids found: 
  0xe0a17ffc  0xe0a37ffc  0x750776f3  0x7c037d0b  0x4e064f04  0xadeadcdf  0x882d872d  0x000000ee  0x540268f3  0xadeadcdf 
 
  SCPU: 13 
  VRB : 5 
  LINK: 2 
  MINI: 0 
 
----------------------- 
 
 Reject rate: 0.072 percent 
 
 Detector ID not known (yet?). 
 FIB ids found: 
  0xadeadcdf  0xe0a182fc  0xe0a282fc  0xe0a382fc  0xe0a482fc  0xadeadcdf  0x71067202  0x37023ef3  0x01018c0a  0xadeadcdf 
 
  SCPU: 13 
  VRB : 5 
  LINK: 4 
  MINI: 0 
 
------------------------ 
 
 
 
 
</pre>
<!-- Author: francesco -->


<!-- Date: Thu Aug 30 09:00:01 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-166&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-166  width='300' align='top'></td><td>cucu</a></td></tr></table>
<!-- Author: francesco -->
<!-- Comment: Thu Aug 30 09;03;06 comment by...francesco -->
<pre>** a region of 5 strips that is causing collected charge and    
   occupancy to be high</pre>


<!-- Date: Thu Aug 30 09:04:50 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-164&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-164' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-165&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-165' width='300'></a></center>
<!-- Author: francesco -->
<!-- Comment: Thu Aug 30 09;06;19 comment by...francesco -->
<pre>** occupancy for SVX L3 and L4 is ok ? (i mean is
   well separated from the others) </pre>

<!-- Comment: Thu Aug 30 09;07;16 comment by...fp -->
<pre>better : the other layer are ok ?</pre>


<!-- Date: Thu Aug 30 09:13:15 2001 -->
<pre>** detector back to standby -&gt; TeV studies on going</pre>
<!-- Author: francesco -->


<!-- Date: Thu Aug 30 11:30:24 2001 -->
Looked at 166 Run starts from Run 124830 to 125067 or so,  
in which 24 were aborted due to  
at least one HDI Init failure.  There were 28 HDI Failures in all,breakdown 
is<ul> 
<li> b0fib00: 4 
<li> b0fib01: 3 
<li> b0fib02: 3 
<li> b0fib03: 2 
<li> b0fib04: 5 
<li> b0fib05: 2 
<li> b0fib06: 4 
<li> b0fib07: 5 
</ul> 
 
Right now SVX (b0fib00,02,04,06) tries three times, ISL (others) 
try twice.  Changed 3 to 10 attempts and rebooted ISL crates 
only, to see if the number drastically changes for them while 
being constant for SVX.  Please put a note in the log book if a fib 
crate gets rebooted. 
 
L2 is using Silicon for studies, we are on Standby.
<!-- Author: SCN -->
<!-- Comment: Fri Aug 31 10;34;10 comment by...SCN -->
<pre>Change is active since Run 125075</pre>
<!-- Date: Thu Aug 30 18:11:26 2001 -->
<pre>I believe Steve swapped the VRB for SB0W6 and SB0W7 which gave  
massive problems during the last 2 days. 
 
Lester changed the threshold for all ISL to 7. 
 
We are back integrated after they lost the store due to a quench.  
Silicon is at SB and L2 studies are ongoing. 
</pre>
<!-- Author: petra -->
<!-- Comment: Fri Aug 31 10;40;50 comment by...SCN -->
<pre>Yes, I did swap the Vrb, but I wouldn't describe the problems as
massive.  It is not exactly clear that this Vrb has a problem,
in fact, but it seems somewhat likely.  Occaisionally there
are a "flood" of Reformatter errors "coming from this Vrb",
cured by a HRR.</pre>
<!-- Date: Fri Aug 31 07:53:29 2001 -->
<pre>** quiet time -&gt; tacking calibrations  
 
** problems from STDBY -&gt; ON  
   SB1W2L3 ext trip  
  [doesn't report the trip on the GUI main window... 
   seems to be teated as spontaneous turn OFF...] 
	-&gt; back to STBY -&gt; then ON 
	DVDD	   130uA	130uA 
	AVDD	   415uA	415uA 
 
   SB5W2L4 -&gt; Software protection trip -&gt; B5W2 portcard OFF 
	(L4)	  STBY		ON 
	DVDD	   100uA	110uA 
	AVDD	   580uA	470uA 
	BIAS 	     0uA	248uA 
 
</pre>
<!-- Author: Francesco -->


<!-- Date: Fri Aug 31 08:41:40 2001 -->
<pre>** detector back to STANDBY 
 
** RUNNING in a separate partition with software event builder 
   </pre>
<!-- Author: francesco -->


<!-- Date: Fri Aug 31 08:53:11 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>** CALIBRATION RUNS (i hope...) [NO L00] 
 
DPS ON run with 2651 events  
 
08:40 /cdf/data08/look/icalir&gt; findfile 125169 
 
  Searching for files from run 125169 (0x1e8f1)...... 
 
-rw-r--r--    1     713M Aug 31 08:21 /cdf/data08/look/icalir/ir01e8f1.0002cali 
-rw-r--r--    1     713M Aug 31 08:11 /cdf/data08/look/icalir/ir01e8f1.0001cali 
 
 
 
DPS OFF run with 2661 events 
 
not yet still (i hope)...  
but logged in the Online Production Report 
 
125,170 9 3 silicon @ 2080 b0dap40.fnal.gov svxii 22,344 /_b0dap40.fnal.gov_ffffffffa88d81d5</pre></td></tr></td></table>
<!-- Author: Francesco -->
<!-- Comment: Fri Aug 31 09;05;22 comment by...fp -->
<pre>NOTES:

** BAD EVENTS/Ref. errors:	
  for run 125169:	2459 	1 Ref. error
  for run 125170:		3 Ref. errors

** PROBLEMS with CSL (?!? i don't know...)
  in run 125169: (EOR) b0svx00: readout 2658/sent 2657 events.
  in run 125170: (EOR) b0svx03: readout 2660/sent 2660 events.
	-&gt;&gt; while all the others vrb's red 2661 events ...</pre>

<!-- Comment: Fri Aug 31 09;06;26 comment by...francesco -->
<pre>** AND FINALLY:
08:48 /cdf/data08/look/icalir&gt; findfile 125170

  Searching for files from run 125170 (0x1e8f2)......

-rw-r--r--    1     703M Aug 31 09:05 /cdf/data08/look/icalir/ir01e8f2.0001cali

</pre>




<!-- Date: Fri Aug 31 14:03:39 2001 -->
Busy Timeouts and Software Trips on SB0W0, SB0W1 right when 
Steve Hahn <a href= 
'/cgi/elog/elog.pl?nb=2001&action=view&page=627&frame=2&anchor=13:53:27'> 
messes with the clock</a>.  I turned all the Si off until 
he is done 
<!-- Author: SCN -->
<!-- Comment: Tue Sep  4 08;53;41 comment by...Jean -->
<pre>This would be consistent with an interruption of Front end clocks to the fibs?  </pre>
<!-- Date: Fri Aug 31 15:12:33 2001 -->
<pre>** silicon back to STANDBY and running in separate partion 
   [NB: no trips powering the detector: the sequence  was 
    - detector off - partition in RC - detector to STDBY -  
    coldstart] 
 
** 16 Ref.errors so far over ~7000 events (some c2c2c4c4) 
 
   </pre>
<!-- Author: Steve,  Francesco -->


<!-- Date: Fri Aug 31 20:19:14 2001 -->
<pre>** silicon was running fine &gt;50 Kevents  
   	- got a busy timeout 
   	- issue HRR 
	- RC hangs in transition active-halt 
	- issue abort 
	- issue reset 
	- exit RC 
	- pop up a new one 
	- try to start over but b0svxo1 didn't acknoledge 
	  not even to a partition transition 
	- paged (Steve && general DAQ pager 2189520 ) X 2 
	- no answer 
	- try to restart messanger (td etc..)-&gt; did not help 
	- reboot of b0svx01 did not help 
	- finally got in touch with Lester and Steve 
	- hardware reboot of b0svx01... let's see 
	</pre>
<!-- Author: francesco -->
<!-- Comment: Fri Aug 31 20;40;52 comment by...fp -->
<pre>after the reboot everything OK and running again with softevb 
(...it was not very clear reading the entry)</pre>


<!-- Date: Fri Aug 31 20:51:49 2001 -->
<pre>** store 669 
 
** p_loss~7.6KHz pbar_loss~2.5KHZ  L~6.8E30 -&gt; ok to turn ON 
 
** detector ON (no trip this time during transition) 
 
** not yet running with CDF because of others problems 
   -&gt; so i keep running in a separate partition for now 
     (occasionals VRB's readout errors ~7/7000)</pre>
<!-- Author: Francesco -->
<!-- Comment: Fri Aug 31 21;26;21 comment by...fp -->
<pre>&gt;&gt; svt crate problems</pre>
<!-- Date: Fri Aug 31 21:17:07 2001 -->
<pre>** silicon integrated from run 125206 tonight 
 
** burst of 672 Ref. errors at the beginning of the run  
	-&gt; HRR seems to have fixed for now the problem...</pre>
<!-- Author: francesco -->
<!-- Comment: Fri Aug 31 21;53;33 comment by...francesco -->
<pre>** no way, the rate of reformatter errors is 3%

&gt;&gt;&gt; mainly from FIB_12 chan 1 == SB0W4L1 &lt;&lt;&lt;


** just before to take out this layer (CDF stopped running
   because of a cal crate) -&gt; beam DUMP
</pre>


<!-- Date: Fri Aug 31 22:29:06 2001 -->
<pre>** more calibration runs : 
run 125208 dps ON  3993 events ~0.3% Ref. errors @ 22 Hz 
run 125210 dps OFF 4437 events ~0.3% Ref. errors @ 22 Hz 
 
</pre>
<!-- Author: francesco -->
<!-- Comment: Fri Aug 31 22;32;07 comment by...francesco -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>** just want to notice that TO ME (i could be wrong..) 
   Ref. errors are not occasional but related to the DAQ  
   frequency:
&gt;&gt;&gt; to take those runs i asked the all l3 farm and used the
    hardware event builder (same running conditions)
&gt;&gt;&gt; before with beam the rate was ~3% Ref. errors @ 300 Hz
    [...compatible with the ~4% that one could expect]
</pre></td></tr></td></table>


<!-- Date: Fri Aug 31 22:42:28 2001 -->
<pre>** detector back to standby (NO TRIPS !!-&gt; bello) 
 
** coldstart immediately after transition and now  
   running happy again in a separate partition.... 
    
** will give now Si crate to aces again</pre>
<!-- Author: francesco -->


<!-- Date: Fri Aug 31 22:47:44 2001 -->
<pre>(when i ended the run...) 
 
** SB3W1 +5V DOIM ext trip (the only one raw stuff...) 
	-&gt; back to STBY -&gt; OK now 
</pre>
<!-- Author: francesco -->


<!-- Date: Sat Sep 1 14:59:06 2001 -->
<pre>** store 673  
 
** p_loss~5KHz pbar_loss~1.5KHZ  L~5.9E30 -&gt; ok to turn ON  
 
** detector ON (no trip this time during transition)  
 
** first run with silicon today is 125268 
 
** basically NO reformatter errors today (hummm...?!?) 
</pre>
<!-- Author: francesco -->
<!-- Comment: Sat Sep  1 15;09;58 comment by...fp -->
<pre>** lots of c4c4c4c4 in this run that stop almost immediately for     a  cleanup of the event-builder (40 reported Ref. errors over     66Kevents)</pre>

<!-- Comment: Sat Sep  1 16;29;24 comment by...francesco -->
<pre>** many many problems both for CDF an for us but then:

** take out from HDWDB SB1W4L0 SB1W4L1 -&gt; Ref. errors ~ 4-7%
   power OFF the two layers
   modify and reloaded CAENvolts.dat

** had to reboot b0svx07 (i mean by hand)

** first run pretty stable with CDF is then the 125275
   [Ref. errors rate is now 0.025% @ 300Hz l1 accept] </pre>

<!-- Comment: Sat Sep  1 19;48;12 comment by...francesco -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>** in order to understand what layer was giving errors
   i was trusting the RC error display windows and was 
   decoding a FIB header using the L3 labels -&gt; turns out
   that these could be wrong especially if the event is 
   corrupted -&gt; page Steve && Lester -&gt; Steve explain me 
   how to track a bad layer from the mini-structures

** All this to say that i took a bad action (based on this
   bad infromation) to take out from DAQ (layer after layer...)   
   the entire  wedge SB1W4 ==&gt; a chance must be given to this 
   wedge to be retested and putted back (at least L0,L1 & L2)
   before the next shot
   i had powered OFF those layers
   modified and reloaded poweset.dat 
   modified and reloaded CAENvolts.dat

** take out from HDWDB SB1W8L0 -&gt; c4c4c4c4 
   power OFF the layer
   modify and reloaded CAENvolts.dat
   [THIS SEEMS TO HAVE FIXED THE CDF DAQ PROBLEMS FOR NOW...]
     &gt;&gt;&gt; thanks STEVE &lt;&lt;&lt;&lt;
    first run with silicon again is: 125286
</pre></td></tr></td></table>


<!-- Comment: Sun Sep  2 05;44;58 comment by...francesco -->
<pre>** beam dump -&gt; will take 2 calibration run before to turn OFF</pre>
<!-- Comment: Sun Sep  2 06;13;57 comment by...francesco -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>** CALIBRATION RUNS (for the set that run this night)
 
run 125308 dps ON  3062 events  0.0  Ref. errors @ 22 Hz 
run 125309 dps OFF 3065 events ~4.6% Ref. errors @ 22 Hz 

</pre></td></tr></td></table>
<!-- Comment: Sun Sep  2 06;15;32 comment by...francesco -->
<pre>** detector back to STANDBY (no trips -&gt; bello)
   -&gt; immediately issued a coldstart at the end of the transition

** detector back to aces
</pre>
<!-- Date: Sat Sep 1 21:45:59 2001 -->
I worked on the External Trips (ET) problem today. 
<p> 
The bad news: I wasn't able to get a PS to trip solely by adjusting the 
ramp rates in our test crate (an idea Matt suggested).  I tried two     
supplies at both the minimum and maximum ramp rates to no avail. 
<p> 
The good news: I was able to create several trips before and after ramp up 
by using resistors and/or a screwdriver on the patch panel.  While I 
didn't find anything that matches our exact problem I did notice some 
weirdnesses in the GUI and at least rule out some possible causes for the    
ET problem. 
<p> 
(1)  I had to set the ramp rates via the terminal.  Whenever I used "set 
ramp rates" from the GUI it set them back to 10/10.  This may be pilot     
error--I have never used this feature before.  The file we are supposed to 
change the ramp rates in is volts.dat, right? 
<p> 
(2) Several times I caused a trip and did not get a new pop-up window or 
message line on the GUI.  In each case I had already gotten a message   
from a different layer on that wedge* previously.  Even a reset trips in   
between the two trips would not necessarily make it give error messages  
again. It seems that I had to actually send an on-off-stdby command to     
that wedges to get proper error messaging from it again.  The state of the 
newly (unreported) tripped wedges was correct in the GUI Full Status 
window and on the terminal, however. 
<p> 
(* This clue could be a red herring.  I only ever had one wedge powered at 
a time.) 
<p> 
I suspect this is the source of our "layer mysteriously off" problem.  Perhaps someone could check the log file (I was using the L00 GUI) to see what story it tells. 
 
<p> 
(3) I did get several OverCurrent and UnderVoltage trips on various bias 
layers.  In each case the AVDD and DVDD reported external trip.  In each   
case the full status window, dumb terminal, and crate face matched one     
another for the tripped layers. 
<p> 
Wish I found more, but at least it's a start.
<!-- Author: Napora -->
<!-- Comment: Sat Sep  1 21;48;39 comment by...Napora -->
<p>By "on-off-stdby" I meant that I had to send some command to change the state of at least one layer on the wedge, not that I had to send all three.





<!-- Comment: Tue Sep  4 10;51;34 comment by...Andrew -->
<pre>(1) Did you load a modified CAENvolts.dat before setting new 
ramp rates?
(2) These unreported tripped wedges are understandable. Once you
hit "TRIP ACKNOWLEDGE" button, the GUI masks the entire wedge not
to report the old trip again. When you get a trip on a different 
layer of the same wedge the GUI doesn't report it until you fix
the problem, i.e. turn the tripped layer back on and thus way 
unmask the tripped wedge. The problem is that when the more
detail scale of reporting trips was introduced, the GUI was 
unmasking the tripped layer, while masking the entire wedge in 
the old fashion. This is not, how it should work, and I will fix it.  
However, given that the GUI was failing to report trips in some 
cases, the status of tripped layers is monitored correctly and
iFix is alarming to any trip occurance. This is not an 
explanation of "layer mysteriously off" problem.</pre>
<!-- Date: Sun Sep 2 06:27:40 2001 -->
<pre>** PS stuff: 
 
going to STBY i had to turn OFF by hand a layer ... why ? 
 
 
### from the GUI log file 
 
&gt; more 20010902.log 
Sun Sep 02 06:06:04 CDT 2001     success: Power to STANDBY 
Sun Sep 02 06:19:29 CDT 2001     success: Channel0 SVX B1 W8 OFF 
 
### status of $CAENCONTROL_DIR/CAENvolts.dat 
 
B1W8 
104.0  1  A x 
100.0  2  A 
40.0  3  B x 
96.0  4  A 
40.0  5  B 
 
 
### IT IS NOW THE SECOND TIME THAT I NOTICE THAT BAD INDENTATION 
    CAUSES PROBLEMS</pre>
<!-- Author: francesco -->
<!-- Comment: Tue Sep  4 10;02;39 comment by...petra -->
<pre>this is the ladder you took out the last time, maybe you didn't 
reload the volts.dat file?</pre>


<!-- Comment: Tue Sep  4 11;30;01 comment by...francesco -->
<pre>** the file CAENvolts.dat was reloaded </pre>