<!-- Title: 08:49:31  Mon Jun 11 2001 -->
<!-- Crewchief: usual suspects -->
<!-- Op1: Jean -->
<!-- Op2: Steve N. -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Plan: 
   Day/evening - Steve and Colin continue the x-mode  
                 debuggins 
   late evening/owl - run integrated</pre>


<!-- Date: Mon Jun 11 11:12:59 2001 -->
<pre>From Saverio - here are runs that could have 
silicon data - but bias may or may not be on. 
One can use Saverio's files to see if the 
bias is on. 
 
List of runs that have the SVX crate included 
 
117 381 
117 379 
117 376 
117 375 
117 374 
117 373 *** 222350 events 
117 372 
117 371 
117 370 *** 149904 events 
117 363      86300 
117 361 *** 184064 
 
</pre>
<!-- Author: Jean -->


<!-- Date: Mon Jun 11 12:00:44 2001 -->
<pre>Bias configuration for run 117373 
Due to low sensitivity switch on power supply 
It is difficult to tell if L2 and 4 were actually biased 
on the basis of the current reading. 
 
SB0W0 L0 OFF  What about L2, L4 ??? 
SB0W2 L2 and 4 ?? 
SB0W3 all biased 
SB1W2 L2 off ??? 
SB2W2 L2 and 4 ??? 
SB2W3 L2 ??? 
IB0W0 L2, L4 ???? 
 
</pre>
<!-- Author: Saverio -->


<!-- Date: Mon Jun 11 12:46:45 2001 -->
<p> 
I tried to see if bias voltage control from iFix would work. 
I set IB0W0 to standby with the GUI and tried to turn it off 
by clicking on "ISL OFF" in iFix.  The GUI hung, but the wedge 
did in fact turn off which you could see when the GUI was 
restarted.</p> 
 
<p> 
I went through the same exercise, this time clicking "ISL OFF" 
<b>on the GUI</b> (this is essentially what iFix does -- it 
sends a message to the GUI saying "do the same thing you do when 
someone clicks 'ISL OFF' in the Java window").  I got the same 
result (wedge off but GUI hung).</p> 
 
<p>I thought maybe the reason for this is that IB1W1's PS is 
not physically there but it isn't X'd out in CAENvolts.dat.  So 
I X'd it out, tried again, same result.  This time I was watching 
what was going on on the server side -- it says "v288 base address error."</p> 
 
<p>So, it looks like we're going to need Andrew around to get 
this working...</p> 
<!-- Author: Andy H. -->
<!-- Comment: Mon Jun 11 12;48;24 comment by...Andy H. -->
By the way I returned CAENvolts.dat to the state it was in
before I was monkeying around with it.


<!-- Date: Mon Jun 11 13:53:08 2001 -->
<h1>C4! (not the explosive)</h1> 
Found some more interesting effects in the search for the "C4" cure. Was working with SB0W0, which in particular had a  <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=38&frame=2&anchor=13:45:53'> 
double C4 problem</a> in HDI 0.  Previously updating the firmware with glinkv.jam made this become a single C4 problem.  Today found:<ul> 
<li> Running DPS on Nearest Neighbor Threshold 5  problem doesn't happen 
<li> Running DPS on Nearest Neighbor Threshold 200 problem doesn't happen 
<li> Running DPS on Sparse Threshold 200 problem doesn't happen 
<li> Running DPS on Sparse Threshold   5 problem happens 
</ul> 
So it looks like it is really a problem when the data size and 
fluctuating greatly on an event by event basis, and  
perhaps fluctuates low...This would explain why you see 
it in Sparse but not NN, as the byte count is ~ factor of 
3 in Sparse.  When I updated the Fib (b0fib00 Slot 8 FIB     123     560597  ) to 
glinkv1.jam, which is the same fix as glinkv.jam but an extra bubble, the problem went away.<P> 
Along the way, I learned that in NN mode with high threshold, 
for some reason you get both the lsat chip last channel and 
first chip first channel for some reason.  Proof (from the Vrb output fifo):<pre> 
0x00000000:  00b8060f 10410410 04104100 00120016 001e001e 00260000 00000000 00000000 
0x00000020:  e00040fc 83150003 8215a115 a0157f00 c1c10000 00000000 e00140fc 85150004 
0x00000040:  84158315 a215a115 a0157ff3 c1c10000 e00240fc 89150004 88158715 86158515 
0x00000060:  a415a315 a215a115 a0157f03 c1c10000 e00340fc 89150007 88158715 86158515 
0x00000080:  8415a315 a215a115 a0157ff3 c1c10000 e00440fc 8d15000c 8c158b15 8a158915 
0x000000a0:  88158715 a615a515 a415a315 a215a115 a0157ff3 c1c10000 
</pre> Here you can see the first chip (0x8x, always after the  
0x40fc) always has channel 0 on, and the last chip (0xa0) always 
has channel 127 (0x7f) on.  Don't know exactly if this is expected or desired, but that is how it is...
<!-- Author: SCN -->
<!-- Comment: Mon Jun 11 14;00;15 comment by...SCN -->
Typos:
<ul>
<li> "data size <i>and</i> fluctuating" should be "data size <i>is</i> fluctuating"
<li> "byte count is ~ factor of 3 in Sparse" should be "byte count is ~ factor of 3 <i>less</i> in Sparse."
<li> "lsat" should be "last"
</ul>
I never said I could type and think at the same time...


<!-- Comment: Mon Jun 11 16;39;16 comment by...jean -->
<pre>Steve changed the hardware database and the CAENVolts.dat
to include L0,  However the chip settings should be checked.
</pre>
<!-- Date: Mon Jun 11 14:58:21 2001 -->
<pre>I'm going to play w/ ISL flow valves.  DON'T power ISL 
until I finish (in about an hour or so). 
 
Thanks.</pre>
<!-- Author: Doug -->


<!-- Date: Mon Jun 11 15:40:33 2001 -->
<pre>Here is a mail message from this weekend.  Turns out this 
occurred after a trip.   
 
Another CAEN problem was flagged yesterday, Sunday, morning at 07:03:20. 
According to the SPY data, it looks like the DOIM voltages where turned 
off while AVDD, DVDD, and BIAS was left on for each layer in SB1W2. I have 
not checked the GUI logs etc nor will I have time. Could a GUI person 
please figure out how this could have happened? 
 
- David 
A history of the power supply values around the time of the problem is at 
  http://ncdf17.fnal.gov/cgi-bin/lgbk?user=stuart&ent=12851 
 
</pre>
<!-- Author: David S. by way of Jean -->
<!-- Comment: Mon Jun 11 15;57;49 comment by...Doug G -->
<pre>
  This is likely more accurately described as a "GUI Feature".
  The CAENs were not spec'd to prevent this.  Instead, we ought
  be preventing this voltage status in the control software.
  Andrew returns Wednesday... his list of work continues to
  grow!</pre>


<!-- Date: Mon Jun 11 15:59:11 2001 -->
<pre> 
  OK - I'm done playing with ISL supply valves.  Assuming 
  all goes smoothly for the next 24 hours, will make these 
  the default ("Download") settings. 
</pre>
<!-- Author: Doug G -->



<!-- Date: Tue Jun 12 00:47:15 2001 -->
<pre>There were two L00,SVX,ISL "bird" alarms withini the last 
 15 minutes: when I look into the text message it claimes  
a problem with the heartbeat; the alarm cleared itself after  
a minute or less. There was NO cooling trip and NO GUI 
 peculiarities at the same time. So I will just keep an eye on it.</pre>
<!-- Author: Petra -->


<!-- Date: Tue Jun 12 00:50:44 2001 -->
<h1>X Mode and such</h1> 
We succeeded (we think) in writing from a file with an X mode 
bank in it to the development database, making the <I>Valid Set</I> also work.  Tomorrow we'll try to download it.  We 
still have some trouble running in real time, where 
<ul> 
<li> we claim to write to the database, but the table doesn't appear.  However, if we successfully write via a file, the 
version number skips 1, like we did write something but 
we don't know where it went 
<li> we got core dumps when running the dpsshift algorithm.  Since this was the first time we got that far, this is not  
too surprising. 
</ul> 
 
Now Integrating <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=39&frame=2&anchor=11:13:01'> 
previous base set</a> plus <ul> 
<li> SB1W0 worked fine in standalone after C4 fix download, but 
HDI 1 drops readout, HDI 2 doesn't give anything, running 
integrated.  Turned these two off. 
<li> SB1W3-the devil's wedge.  Had to turn off HDI 2,3,4.  Already replaced the FTM several times, but always with some other 
problem.  Time to look at PS and cables... 
</ul> 
Did not get to IB0W1 (sorry Doug) but will endeavour to do so tomorrow (or if Petra gets bored...). 
<!-- Author: SCN -->
<!-- Comment: Tue Jun 12 00;54;14 comment by...SCN -->
<pre>Forgot to mention, at about 21:30 they put in the store, which
had huge Plosses (25 kHz) followed by Gargantuan Alosses (300 kHz) so we stopped for a while until things cooled down.  At
300 kHz it didn't take long for the beam to fritter away to nothing...Also, for above wedges CAENvolts.dat and the hdwdb are
updated...Default configuration is running NN BW 5 Th 5.</pre>


<!-- Date: Tue Jun 12 01:21:26 2001 -->
<pre>got a trip from SB1W2: bias overcurrent. Put it back to SB  
for the moment, the crates are just passing cold start, will  
bias that ladder later. First silicon included run of the day: 
117487. </pre>
<!-- Author: Petra -->
<!-- Comment: Tue Jun 12 07;28;27 comment by...Petra -->
<pre>the trip was in L1 of course, the known-to-be-problematic guy...
lateron I played a little with it: turning bias on and off, 
ramping bias voltage by hand. After about 3 hours of being 
turned on the bias current stabelized. So I could run the ladder 
at 40V corresponding to ~40uA flat...</pre>
<!-- Date: Tue Jun 12 01:36:19 2001 -->
<pre>New run started with silicon included. For those who are   
concerned, the following wedges are powered:  
 
SB0W0: L0,1,2,3,4  
SB0W2: L0,1,2,3  
SB0W3: L1,2,3,4  
SB1W0: L0,3,4  
SB1W2: L0,1 (only at 70V),2,3,4  
SB1W3: L0,1  
SB2W2: L0,1,3,4  
SB2W3: L0,1,2,3,4  
IB0W0: L0,1,2,3 
 
</pre>
<!-- Author: Petra -->


<!-- Date: Tue Jun 12 03:28:00 2001 -->
<pre>Problems with SB1W2, L1 bias current: it's very slowly increasing.  
Now I am down to 30V (started out with 50V) and the current is  
around 30uA and increasing (limit=50uA). </pre>
<!-- Author: Petra -->


<!-- Date: Tue Jun 12 03:30:18 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>I observed problems with ACNET, no plots would update or been  
created. I restarted the PC and therefore ACNET and then I was  
able to bring up the relevant plots. Looking at the values  
from the SVXRADMON makes me think that they were reset during  
this procedure. Everything is 0. 
</pre></td></tr></td></table>
<!-- Author: Petra -->
<!-- Comment: Tue Jun 12 03;33;57 comment by...ppppppppppppsssssssssss -->
<pre>P.S.: I'm very proud of myself to start understanding ACNET 
in the middle of the night :)</pre>


<!-- Date: Tue Jun 12 03:56:01 2001 -->
<pre>ach ja:  
in the first silicon run tonight I saw frequent timeouts  
from the VRB_02 (my first reaction was to take out ISL - did I  
take drugs or what?) but then, after some thinking I found out  
that rc was only complaining about one single slot (10).  
So I checked that the VRB in slot 10 (11 in some numenclature?)  
reads out two wedges which are not currently read out, and  
then I took out this VRB card. Afterwards the problem did not  
reappear (yet) ! 
So maybe we should safe this configuration in the HWDB for the  
time being, will talk to Steve in the morning...</pre>
<!-- Author: I can&#39;t remember... -->


<!-- Date: Tue Jun 12 04:39:08 2001 -->
<pre>The CO is not able to start SiliMon, it complains about the  
bank structure of the SIXD bank. Did something change? He is  
not sure about since when it is not working, could be  
days/hours(?)</pre>
<!-- Author: Petra -->
<!-- Comment: Tue Jun 12 08;53;51 comment by...Doug -->
<pre>
  Anyes is following-up on this.  She will try to figure
  it out and/or notify Ronan/Tara.</pre>
<!-- Date: Tue Jun 12 07:08:56 2001 -->
<pre>When we lost the beams I wanted to switch off the silicon  
wedges, but the GUI got stalled. Since not quite clear about  
Tevatron actions and since there was nothing to lose anyway  
I pushed the crash buttons. Called the Cryo tech who reset  
all the rack and other alarms. In the meantime while trying  
to restart the GUI (quite some problems, rebooted svxinter  
several times!), I disabled all bulkheads in iFix. 
Crates are out of rc and now I will switch off the 5V enables. 
Last run during beams: 117493.</pre>
<!-- Author: Petra -->
<!-- Comment: Tue Jun 12 07;12;33 comment by...p. -->
<pre>So, GUI is back up and everything is really off and disabled.
By the way: during beam loss not a single ladder tripped.</pre>



<!-- Comment: Tue Jun 12 08;59;13 comment by...Doug G -->
<pre>
  Excellent!  This is exactly a situation we had in
  mind when putting these crash buttons in the sytem.
  As of ~0830, everything was back (thanks to Dr. Roser
  and company).</pre>


<!-- Date: Tue Jun 12 09:00:25 2001 -->
<pre> 
  I've re-re-adjusted the ISL flow valves.  The pressures and 
  flows held steady all night, so i'll ask that the "Download" 
  defaults be changed to these new settings. 
</pre>
<!-- Author: Doug G -->


<!-- Date: Tue Jun 12 09:02:04 2001 -->
<pre> 
  We understand there's a chance of a short access sometime 
  soon.  We will plan to power two more crates (1 SVX and 1 ISL). 
  Jean is ironing-out which.  Likely on the East.</pre>
<!-- Author: Doug and Jean -->


<!-- Date: Tue Jun 12 10:09:29 2001 -->
<u>Added another wedge, more HDI problems:</u><P> 
Added IB0W1, and found:<ul> 
<li> All ladders readout ok in read all mode, although they 
are very noisy (pronounced difference between one polarity and the other).  Noise goes away with bias. 
<li> HDI 1 has bit 2 stuck in Nearest Neighbor mode.  Don't 
understand why a bit is stuck or not depending on readout mode 
<li> HDI 8 occasionally drops readout in NN mode. 
</ul> 
Dropped HDI 6,8 and modified HDWDB/PS Gui appropriately. 
This wedge is now "integrated".
<!-- Author: SCN -->


<!-- Date: Tue Jun 12 11:11:25 2001 -->
<h1>Pbar Studies-We're Off</h1> 
They are planning to inject beam soon, and do pbar studies 
(perhaps to understand why the losses were hundreds of kHz 
last evening) during the day.  Expecting that this will 
produce conditions unsuitable for running the detector, 
we cease pursuing calibrations etc for awhile.  I turned 
all PSs to <B>OFF</B> and disabled all IFIX channels, 
as well as the kill switches.
<!-- Author: SCN -->


<!-- Date: Wed Jun 13 08:16:09 2001 -->
<pre>Had some quiet time and took ISL geometry check runs for David: 
--------------------------------------------------------------- 
 
I run IB0W0, HDI 0,1,2,3 all in sparse mode with threshold=200  
for all the chips but the first one in the RO order; this  
means I had only one chip per run at a threshold of 2, all the  
others were at 200. 
 
HDI 0: run=117603, 2855 events taken (a little less actually  
written out I guess :) 
 
HDI 1: run=117602, 2939 events taken 
 
HDI 2: run=117604, 3314 events taken 
 
HDI 3: run=117605, 2574 events taken 
</pre>
<!-- Author: Petra -->


<!-- Date: Wed Jun 13 13:38:46 2001 -->
<pre> 
  Andy Foland is carrying the Silicon General Pager for the 
  next few days.  He'll be taking care of the daily checks during 
  this time and will work with Jean/Colin to implement run plan. 
 
  </pre>
<!-- Author: Doug G -->


<!-- Date: Wed Jun 13 15:36:54 2001 -->
 
 So, we learned that BSC (Beam Shower Counters... the  
 scintillators used to determine the B0PLOS and B0ALOS #s) and 
 the CLC (Cerenkov Luminosity Counter) share the same VME crate. 
 Thus, work on either can cause us to lose information about the 
 losses.  We don't want to power in such a situation (unless  
 it's guaranteed quiet time).  The shift crew has been notified 
 and i've posted a sign in the control room letting people know 
 that we need to be notified prior to any CLC/BSC work. 
 <P> 
 Presently, CLC is trying to integrate a new board, so they're 
 turning their crates off/on.  The BSC numbers are coming and 
 going simultaneously.  
 <P> 
 <B>I've observed non-zero ALOS</B>, so <B> the loss monitors 
 are working</B>.  Once CLC is finished, they've been asked to 
 page the silicon general pager (ie. Andy F) and he'll arrange 
 for us to resume studies/calibrations or integration. 
<!-- Author: Doug G -->


<!-- Date: Wed Jun 13 16:57:14 2001 -->
<p> 
<a href= 
'/cgi/elog/elog.pl?nb=2001&action=view&page=391&frame=2&anchor=16:54:57'> 
New ISL cooling supply valve deafults </a> </p>
<!-- Author: Andy H. -->