<!-- Title: 14:54:53  Mon Apr  2 2001 -->
<!-- Crewchief: Jean -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Prepare for 1x8 - scheduled for tomorrow: 
 
1. Quadlog wiring and  testing for ORC 
2. Alarm display 
3. follow up on yesterday's findings</pre>


<!-- Date: Mon Apr 2 16:01:02 2001 -->
<pre>I set jumpers on CAENET controllers for all 16 CAEN crates 
respectively and put them into the VME crate, so that next 
time it will be easy to figure out, if any of CAEN crates  
do not actually exist. Although the availability of extra 
controllers may potentially affect the PS GUI performance.</pre>
<!-- Author: Andrew -->


<!-- Date: Mon Apr 2 18:34:01 2001 -->
<pre>evd event display "fixed" in development. 
 
This fix involved making the new data representation 
default and instructing the event display not to 
display any strip with flag values.   Previously 
the event display had been dominated by strips with the 
243 data from chip = 0 flag code. 
 
Event display will not work well in any release up to 
3.14.0int2. 
 
I noticed that the L00 ladders look very noisy. 
 
</pre>
<!-- Author: herndon -->


<!-- Date: Mon Apr 2 19:22:50 2001 -->
<pre>Tested SB0W6 in standalone test stand mode and verified problem  
IGV spotted with layer 0 on integrated data runs.  
 
See CPC logs for details.</pre>
<!-- Author: Mad Mary -->


<!-- Date: Mon Apr 2 19:23:01 2001 -->
More plots from the DPS off calibration run 110920, now with bad bunch crossing suppressed. 
 
<P><A HREF="http://www-cdf.lbl.gov/~igv/Plots_run_110920_nobadbunchx/noise_n_dnoise_svx.ps">Noise and dnoise overlayed for SVX</A> 
 
<P><A HREF="http://www-cdf.lbl.gov/~igv/Plots_run_110920_nobadbunchx/noise_n_dnoise_l00_isl.ps">Noise and dnoise overlayed for ISL and L00</A> 
 
<P><A HREF="http://www-cdf.lbl.gov/~igv/Plots_run_110920_nobadbunchx/pulse_height_W07-APHI.ps">A scary pulse height distribution from one of the L00 ladders.</A> It has four peaks! 
  
<!-- Author: Igor -->


<!-- Date: Mon Apr 2 20:52:01 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><p> 
Bias current historical plots are available for all wedges.  Note that they only work on the cryo room computers facing east and west.  To get to them go to the main silicon cooling menu and click "SVX Hist. Menu" for SVX and "ISL Hist. Menu" for ISL/L00.  From there it should be obvious what to click on.</p> 
</td></tr></td></table>
<!-- Author: Andy H. -->


<!-- Date: Mon Apr 2 23:35:11 2001 -->
<pre>Instructions to plot silicon bias currents are also avairable on: 
/~svxii/runii/index.html 
</pre>
<!-- Author: Yohsei Iwata -->


<!-- Date: Tue Apr 3 01:55:51 2001 -->
<B>We have ORC</B>...now if we can just get the damn ladders to 
work. 
 
Found<UL> 
<LI> we can run with "minimal" errors with LB0W3, IB0W3, IB1W3, 
SB0W6, SB1W3, SB2W6, SB2W8, SB3W5, SB3W6, SB4W5 portcards.  Various ladders in here are off for various reasons 
<LI> Adding SB2W7 gives the mysterious "SEVB stops sending after 
100 events" message but no reformatter errors appear.  This is  
peculiar.  Swapping it for a different PC doesn't change this. 
<LI> Attempting to Bias and get a Ped Run In, Run 111061 via the SEVB. 
Then give it to CDF for the rest of the ... um ... morning. 
 
<ul>
<!-- Author: SCN + MB -->


<!-- Date: Tue Apr 3 02:02:32 2001 -->
<pre>Its 2:04 AM, and I believe i setenv DISPLAY before starting  
CAEN GUI, anyway its much faster than I have ever seen it  
running on b0dap63 (with cdfdaq running another job on same 
machine). Oh well could be slow network during the day.</pre>
<!-- Author: Sleepy Mary -->


<!-- Date: Tue Apr 3 10:13:51 2001 -->
<pre>Bias current plots are running well. 
 
LAST NIGHT (aroung 1am~2am, April 3rd), some of the plots 
showed HIGH bias currents and some others NO current as follows: 
 
L00 B0W3: OK 
SVX B0W6: OK 
SVX B2W6: L2 and L4 no current 
SVX B2W7: L0, L2 and L3 no current 
SVX B2W8: OK 
SVX B3W6: L4 no current 
SVX B1W6: L2 no current, L1 (~330uA) and L3 (~350uA) high currents 
SVX B3W5: L2 no current, L3 (~420uA) high current 
SVX B4W5: L2 (~490uA) high current 
ISL B0W3: L2bias1 and L4bias1 no current, 
          L1bias1 (~370uA) and L3bias1 (~460uA) high currents 
  
 
The bias currents are stable (=0) now (mornig, April 3rd). 
 
</pre>
<!-- Author: Yohsei Iwata -->


<!-- Date: Tue Apr 3 11:20:44 2001 -->
</ul>
<!-- Author: WEBWONKY -->
<!-- Comment: Tue Apr  3 11;21;19 comment by...Pumba -->
</UL>


<!-- Date: Tue Apr 3 11:24:32 2001 -->
So Far: 
<ul> 
<li> Found Silicon does not create COT noise when the discriminators are properly set 
<li> New Run Control is ok for HEVB, not for SEVB 
<li> Attempting some more calibration running.  SB0W6 giving 
0xc4 in the fib id headers...yucky... 
</ul> 
Plan: Take calibrations and think about Clock settings, nibble 
shifting, and bad Vrb headers (not necessarily in that order).
<!-- Author: SCN -->
<!-- Comment: Tue Apr  3 12;31;49 comment by...Petra/Steve -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>calibration data taken (fully biased):

read all, BW=5, PD=40, portcards: LB0W3, SB0W6, SB1W6, SB2W8, 
                                  SB3W5, SB3W6, SB4W5, IB0W3,
                                  IB1W3

DPS off: runs 111113, 111114 (~4000 events)
DPS on:  runs 111116, 111118 (~5000 events)</pre></td></tr></td></table>


<!-- Date: Tue Apr 3 12:46:20 2001 -->
<pre>Handed Silicon to Ace, Unbiased.  We still see 5% error rate 
due to nibble shifting, though during Calibrations it dropped 
to 2% roughly coincident with loss of beam.  Wonder if 
moving 53 Mhz phase might help? 
 
Once I see the Silicon running via the Ace, I will retire to 
think about it all...</pre>
<!-- Author: SCN -->


<!-- Date: Tue Apr 3 13:23:31 2001 -->
<pre>Mary Reminded me that the Fib masks were not adjusted for 
SB2W6.  Last night we had L0, L4 off but didn't turn off the 
fib channels.  I rectified this and put it back in (but it 
was not in the pedestal runs) maybe analysis people can use this 
wedsge (L1,2,3 are on) if it works (waiting on EVB people to test), 
maybe not.  Will turn it off again if it causes Readout probs.</pre>
<!-- Author: SCN -->


<!-- Date: Tue Apr 3 15:31:48 2001 -->
<pre>ISL B0W3 hdi 1 biased briefly during first run, 111147, from event 1500 - 2000. No problems. Peek at data before going more global....</pre>
<!-- Author: DS -->
<!-- Comment: Tue Apr  3 16;30;55 comment by...David, Auke, Tim -->
<pre>Looking at this first data we clearly see hits in ISL B0W3. For example, see <A href="http://ncdf17.fnal.gov/~stuart/firsthits.eps">here</A>.</pre>

<!-- Comment: Tue Apr  3 16;40;19 comment by...DS, APC, TKN -->
<pre>See also a <A HREF="http://ncdf17.fnal.gov/~stuart/Qcor.eps"> phi-z charge correlation</A> plot.</pre>


<!-- Date: Tue Apr 3 16:51:50 2001 -->
<pre>we biased wedge SVX B0W8 and took data: run 111148 
with non-colliding beams. Now we are waiting for the DAQ to get  
ready and then we will take collision data. </pre>
<!-- Author: Petra -->


<!-- Date: Tue Apr 3 17:34:16 2001 -->
<p> 
SVX/ISL/L00 bias voltage status is now being reported to iFix HV summary page.  Because I don't have anything masked off yet, the status will always be "7" and green (unless there's a trip, in which it case it will go to "12" and red).  The "min" bar will stay at 0%, and the "max" bar will be at 100% if anything is at STBY or ON.  Once I mask off the appropriate wedges the information on this page will be a little more relevant.</p> 
 
<p> 
Oh, you'll notice that our heartbeat status box, along with most everyone else's, is purple and not green.  This is because the computers on the iFix network forgot about Daylight Savings Time.  D'oh!</p>  
<!-- Author: Andy H. -->
<!-- Comment: Tue Apr  3 17;38;06 comment by...Andy H. -->
My bad... that should be "11," not "12."


<!-- Date: Tue Apr 3 18:07:36 2001 -->
<pre>Long run taken with DPS off and all 9 wedges biased: 
 
run 111160 (~40000 events) 
 
This run will be used to extract pedestals and for rough timing  
studies.</pre>
<!-- Author: Petra -->


<!-- Date: Tue Apr 3 18:31:53 2001 -->
<pre>Mark B proposes new Vrb firmware to deal with nibble shifting. 
I updated the vrb in 1RR21HT Slot 12 (e45x) whose layer 3 
had much nibble shifting (not layers 0,1,2,4 - odd.) 
VRb Emulated and Fib-Vrb tests seem ok...will integrate and see 
if the nibble shifting is reduced.</pre>
<!-- Author: SCN -->
<!-- Comment: Tue Apr  3 19;14;21 comment by...SCN -->
<pre>Looks good.  I updated this Vrb, which was the worst
one , and put only SVXII East into the integration run, which
is this Vrb and one other.  Where the worst VRB was 2.5 times worse, it now never nibble shifts, and the other one does
at a rate of about 0.1%.  I think I'll take the silicon out and apply this update to the other Vrbs...</pre>
<!-- Date: Tue Apr 3 18:47:24 2001 -->
<pre>Bias Current During Calibration of Apr.3,11:24~ 
 
     During the calibration of this noon, bias currents of silicon 
ladders were as follows.  Some of them showed high currents. 
 
     L00 B0W3: OK 
     SVX B0W6: OK 
     SVX B1W6: L2 no current, L1 (~300uA) and L3 (~400uA) high currents 
     SVX B2W8: L3 (~400uA) high current 
     SVX B3W5: L2 no current, L3 (~350uA) high currents 
     SVX B3W6: L4 no current, L3 (~200uA) 
     SVX B4W5: L2 (~500uA) high current 
     ISL B0W3: L2, L2bias1, L4 and L4bias1 no current 
               L1bias1 (~380uA), L3 (~200uA) and L3bias1 (~53uA) high currents 
     ISL B1W3: no current other than L0 and L4bias1 
 
Evening and owl silicon shift crews, please check the bias currents at the  
iFix_Plot when you bias the silicon system.  An instruction how to look at the  
bias current is given on the web: 
/~svxii/runii/index.html 
</pre>
<!-- Author: Yohsei Iwata -->



<!-- Date: Tue Apr 3 20:51:50 2001 -->
<pre>I looked at ~1k events from one of the ISL ladders during the first early Myron mode run, 111157, 
to see if there was any indication of which was the right bucket. A <A HREF="http://ncdf17.fnal.gov/~stuart/bucket.eps"> plot </A> of cluster charge in each of the 4 buckets indicates that 
crossing 7 is the one. In the plot, crossing 6 is red, 7 is black, 8 is blue, and 9 is green. Does this agree with the other calculations?</pre>
<!-- Author: David -->


<!-- Date: Tue Apr 3 22:07:03 2001 -->
<pre>From Dave, looks good!<BR> 
 
Hi, 
 
I looked at ~1k events from one of the ISL ladders during the first early 
Myron mode run, 111157,  to see if there was any indication of which was 
the right bucket. A  plot of cluster charge in each of the 4 buckets is 
<a href="http://ncdf17.fnal.gov/~stuart/bucket.eps">here</a> 
 
It indicates that crossing 7 is the one. In the plot, crossing 6 is red, 7 
is black, 8 is blue, and 9 is green. Does this agree with the other 
calculations? 
 
- David 
</pre>
<!-- Author: SCN -->
<!-- Comment: Tue Apr  3 22;54;18 comment by...SCN -->
<pre>Whoops.  Guess I should reload more often.  Blame it on 
sleep deprivation.  Sorry Dave.</pre>
<!-- Date: Tue Apr 3 22:08:38 2001 -->
<pre>This Was Done.  <B> Please be careful not to turn on these HDIS </B> 
<I> 
 
As we discussed, please make the following changes to L00 running. 
 
Deactivate HDI0 and HDI1 of L00 B0W3 since they each have readout 
problems. The first seems to be a lost bit2 (OFTM?). The second is the 
same weirdness you saw last night. 
 
Please set the BW in the chip chain for L00 B0W3 HDI 3 to be  
  BW=7 for chip 0 
  BW=5 for chip 1 
  BW=3 for chip 2 
Notice that this is not exactly as I requested before--I think the wider 
spread could be helpful. 
</I> 
 
If these changes could be in before the timing study runs it might help 
understand L00 timing better.</pre>
<!-- Author: SCN -->
<!-- Comment: Thu Apr  5 12;00;28 comment by...David -->
<pre>The settings used where by chip ID not readout order.</pre>
<!-- Date: Wed Apr 4 02:35:30 2001 -->
<pre>I wanted to make some comments about the Bias Voltage plots in iFix.<br> 
First, I cannot get the ISL B1W3 plot(s) to come up at all.  It is possible that this is a user error, but someone should look into it.<br> 
Second, I noticed that the current on SVX B3W6 layer 2 ramps up to almost twice its normal running value when first turned on.  I am told that this is not atypical for micron ladders, but an expert should give this a look as well. 
</pre>
<!-- Author: Napora -->
<!-- Comment: Wed Apr  4 02;40;42 comment by...Napora -->
<pre><p>Also, in case this isn't general knowledge, the iFix terminal upstairs does not generate any of these plots properly.<br>The silicon shifters have had to run downstairs to look at them.  This seems rather silly and should probably be fixed as well.</pre>

<!-- Comment: Wed Apr  4 03;25;05 comment by...Napora -->
<pre><p>I just looked at ISL B1W3 again.  It turns out that one current, layer 0, was showing up but it was so low (12.5 uA) that I couldn't see it.  Layers 2 & 4 still don't show up, but they are zero according to the GUI as well.  (Layers 1 & 3 are turned off.)</pre>


<!-- Date: Wed Apr 4 03:32:44 2001 -->
<table><tr><td><a href=/elog/notebooks/silicon/Wed_Apr__4_2001_033224.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-12  align='top'></td><td>The hard work Steve et. al. put in to fix the nibble shifting and other problems paid off.  I can now see the signs of clusters in SVXII. This plot from run 111193 </a></td></tr></table>
<!-- Author: matt and petar -->


<!-- Date: Wed Apr 4 04:12:20 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-13&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-13' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-14&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-14' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-15&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-15' width='300'></a></center>
<!-- Author: Napora -->
<!-- Comment: Wed Apr  4 04;14;52 comment by...Napora -->
<pre><p>For some reason I can only get DBANA to look at barrel 1.(?)  Here are pedestals for run 11114 with DPS off.</pre>


<!-- Comment: Wed Apr  4 07;54;32 comment by...Petra -->
<pre>this is probably due to the fact, that it's a B4 leftover:

barrel 4 was barrel 1 and nothing else existed :)

expert, please change that!</pre>
<!-- Date: Wed Apr 4 04:31:47 2001 -->
<table><tr><td><a href=/elog/notebooks/silicon/Wed_Apr__4_2001_043133.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-17  align='top'></td><td>Timing delayed by 38ns. Charge starts to move into next bucket as expected.</a></td></tr></table>
<!-- Author: Matt, Petar, Lester and Vladimir   -->


<!-- Date: Wed Apr 4 05:40:05 2001 -->
<pre>A silicon timing scan is completed. We varied 
the delay introduced by the SRC in the front end 
clock in 19 ns increments from 0 to 114 ns. 
 
Delay 	Run	Events ('000) 
----------------------- 
0	111193	50 
19	no L2 Taxi information (a conspiracy of timing) 
38	111196  10 
38	111197	2.5 
38	111199	17.5 
57	111200	20 
76	111208	21 
95	111207	25 
114	111206	11 
 
The nominal timing according to measurements by Steve  
Nahn and I predict 0 ns delay is appropriate. 
By looking at charge in clusters (wo tracking) this is 
in the right ballpark. The 'bucket hop' of the L1A seems to  
happen between the 38 and 57 ns delays. 
 
</pre>
<!-- Author: Lester,Matthew,Petar -->


<!-- Date: Wed Apr 4 05:45:34 2001 -->
<pre>Summary of the timing scan runs during the owl shift 04/04: 
 
 Run    Delay, ns	Nev 
 
111193	  0		51K 
111196	  38		11K 
111199	  38		18K 
111200	  57		20K 
111206	  114		11K 
111207	  95		26K 
111208	  76		22K</pre>
<!-- Author: Vladimir -->


<!-- Date: Wed Apr 4 06:14:10 2001 -->
<pre>Preliminary analysis of the timing study indicates 
that(after discussion of L1A hopping with Petar): 
  
1) 0ns delay is near the start of the bucket 
2) 38ns delay results in charge in initial 
   bucket and previous bucket.(start of buckets is 
   delayed or moves forward in time and the charge 
   effectively moves backward in the bucket.) 
3) L1A hop occurs between 0 and 38 in order to confuse 
   the issue. 
4) 57ns to 114ns all look about the same as the signal 
   moves back relative to the start of the bucket. 
5) Probably 0ns delay is near the correct timing. 
 
All this should be taken with a grain of salt since we looked 
at bare clusters rather than clusters on tracks.  We will try 
to get tracking to work tomorrow. 
</pre>
<!-- Author: matt and petar -->


<!-- Date: Wed Apr 4 06:43:54 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-18&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-18  width='300' align='top'></td><td>A nice five hitter (all in SVX), all 3D hits (the silver balls are 3D hits in vdf).  One can also see the effect  of multiplexing.  r-z view 101. </a></td></tr></table>
<!-- Author: Petar and Rob -->


<!-- Date: Wed Apr 4 07:10:49 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-19&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-19' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-20&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-20' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-21&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-21' width='300'></a></center>
<!-- Author: Napora -->
<!-- Comment: Wed Apr  4 07;13;08 comment by...Napora -->
<pre>Pedestals from Run 111118 with DPS On so you can compare and contrast them with those posted earlier...</pre>



<!-- Date: Wed Apr 4 08:10:32 2001 -->
<pre>The SVX has dropped off the CAEN GUI.  iFix no longer seems to be getting updated either.  I paged Andrew.</pre>
<!-- Author: Napora -->


<!-- Date: Wed Apr 4 08:21:56 2001 -->
<pre>When I came on shift I was told that the monitors were not working.  About an hour ago I actually had a few spare minutes to investigate and was -- after some struggling -- able to get silimon to work.  My only diagnosis for the earlier problems is that: "HistoDisplay can be really twitchy sometimes."</pre>
<!-- Author: Napora -->


<!-- Date: Wed Apr 4 09:17:17 2001 -->
<pre>Bias currents of SB1W6 L3 (780uA) and IB0W3 L3bias1 (540uA) inreased last  
night (Apr. 3).  More than 500uA is too high.  Do we reduce bias voltages for  
these ladders?</pre>
<!-- Author: Yohsei I. -->
<!-- Comment: Wed Apr  4 09;31;45 comment by...David -->
<pre>IB0W3 L3Bias1 is on the sensitive scale, so the 540 reading is actually 5.4uA not 540uA.</pre>
<!-- Date: Wed Apr 4 09:29:00 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><STRONG> 
Why we want the silicon bias off during lossy beam conditions.  
</STRONG> 
<P> 
 Several people have asked why we care if the silicon bias is on or off during lossy beam conditions. The concern is that the HV coupling capacitors can be damaged by voltage 
 spikes generated by large charge deposition from low angle and high multiplicity losses. These caps are glass strips about 100 nanometers thick fabricated into the silicon. They 
 are spec'd to holdoff about 100V which is fine for the bias voltage we apply, but adding the voltage spike of 1000 mips could break them down. If that happens, we get a low 
 impedance HV to ground connection. This happened to SVX' due to an accelerator accident in Run 1. Since it was single sided silicon the HV across the capacitor was very low 
 so it only affected a small region. The double sided silicon in RunII would make this sort of accident affect the entire ladder.  
<P> 
 We had the same policy of turning the silicon to standby during losses in Run 1. For the reason described above, it is important to follow the same policy now.  
Note that this is particularly important for L00 and L0 since they are close to the beam and exposed to low angle losses. 
<P> 
</td></tr></td></table>
<!-- Author: David Stuart -->


<!-- Date: Wed Apr 4 09:30:25 2001 -->
<pre>Turned L00 off (from standby) because beam is about to be dumped. During injection yesterday it tripped on over bias current even at standby (2V bias). So, play it safe now. 
</pre>
<!-- Author: David -->



<!-- Date: Wed Apr 4 09:51:15 2001 -->
<pre>we set the GUI current sensitivity to what we believe is the  
jumper setting on the power supply so that now what you read  
is what the current is (apart from a possible offset). 
Matt, can you please check, when you have time, this against the 
 PS list that you have ?</pre>
<!-- Author: Saverio & Andrew -->


<!-- Date: Wed Apr 4 11:18:35 2001 -->
<B> Details on the Rack Trip SVSWB</B><BR> 
Upon arriving this morning I heard that "b0fib02 is dead" 
and "The SVX has dropped off the PS GUI".  I immediately checked 
the Rack IFIX page and found that SVSWB (yes again!) had tripped off.<BR> 
This Rack has had problems with its Tachyometer circuit, which 
is intended to measure the RPMs of the fans and produce 
an interlocked <I>FAN FAILURE</I> signal which trips the Rack if 
it is not present.  Previously the Fans themselves have worked 
fine.  This time the symptoms are the same, upon <I>RESET</I> 
everything except the fan failure clears.  We attempted to  
resuscitate the Tach. circuit by pulling the fuse on  
the 24 V for 10 s, then reinserting it, but this did 
not help.  So for the meantime we bypassed the interlock on 
this signal, and Rob Roser will check to see what Voltage 
the TACH circuit is actually putting out.  The Rack has temperature probes which trip at 100 F, and on bringing up  
the Rack the temperatures look OK, but we should keep an eye 
on them when we turn on the CAEN crates, which generate a lot of 
heat.  Rob, Doug G, Petra, and I agreed that we can run the  
rack in this bypassed mode for some time while we think some more about the problem.  First priority is to check the ladders to  
see if the trip caused any oddities.<BR> 
 
There are other things to test, but that involves tripping the 
rack, which we do not want to do with the power on.  Perhaps 
when there is a decent break between shots Rob & Co can look at this to see if we need an access to fix the (temporarily bypassed) problem. 
<BR> 
<B> Please look at the Rack Temperatures on the IFIX page when powering any SVXII Silicon on the West side</B><BR> 
 
Meanwhile, Rob is also looking into the SVSET (ISL SE) Rack to see why that does not come up.
<!-- Author: SCN -->
<!-- Comment: Wed Apr  4 11;39;39 comment by...Petra  -->
<pre>I tested the three SVX wedges on the west side which are in 
this rack: SB0W6, SB1W6, SB2W8 in stand alone mode and they 
all seemed to work fine as before. Due to the beam situation I 
didn't bias the ladders. Now Rob and Steve are off to power 
cycle the rack.</pre>

<!-- Comment: Wed Apr  4 11;51;38 comment by...SCN -->
<pre>We tripped the "live" crate and waited about a minute, but
the voltage across this relay is still 25 V (should be 0)
so we need a (longish) access to fix this rack.  In the
meantime, when turing on the PSs the temperatures go up to
the same level as other similar racks, so we believe the
fans are working, and will run this way.</pre>


<!-- Comment: Thu Apr  5 02;49;01 comment by...Napora -->
<pre>SVSET is still not up.  Has anyone heard any more about this?</pre>
<!-- Date: Wed Apr 4 13:22:10 2001 -->
<pre>Quiet time, L00 b0w3 turned to stand-by as by DS. 
To be reinserted in the HWDB</pre>
<!-- Author: Sav -->
<!-- Comment: Wed Apr  4 13;59;24 comment by...Sav -->
<pre>Done by Petra</pre>


<!-- Date: Wed Apr 4 14:03:05 2001 -->
<pre>Running SiliMon off line 
We had problems with ISL banks. To be fixed: by who???? 
Runs "analysed" but  pedestals were not available yet. 
Program is very slow of fcdfsgi2. 
</pre>
<!-- Author: Saverio -->
<!-- Comment: Wed Apr  4 15;49;55 comment by...herndon -->
<pre>I "fixed" this problem.  There are real problems in the L00
and SVXII data stream.  These problems include strips out of
order on the L00 and incorrect chip ID's.  These problems
don't seem fatal so they are now logged to the error logger,
the output is somewhat suppressed and the events are kept.
The fix in in TrackingMods/src/SiClusteringModule in developmet.</pre>
<!-- Date: Wed Apr 4 14:27:41 2001 -->
<p> 
HISTORICAL PLOTS (temps, currents, etc.) ARE NOW VIEWABLE FROM THE CONTROL ROOM IFIX MACHINE.</p> 
 
<p>You will get some error messages related to the fact that it still doesn't know what to do with the calendar that normally appears in the top-left corner.  Click "OK" or "Cancel;" it really doesn't matter as long as you ALWAYS SAY "NO" WHEN IT ASKS YOU IF YOU WANT TO SAVE CHANGES TO BLAH_PLOT.GRF.</p> 
 
<p>Oh, and the "CLOSE" button on the plot doesn't work upstairs.  Close the picture in the normal Windows way -- click on the little "X" in the top-right corner.</p>
<!-- Author: Andy H. -->


<!-- Date: Wed Apr 4 14:54:36 2001 -->
<pre>We have errors every now and then, from SiliMon offline 
1) please, make the error message more intelligible ! 
2) can we do something about it ? 
3) event numbers are not in the right order. Is this because  
    of the L3 farms in parallel, I assume ? 
 
 
%ERLOG-w DaqInfoSet:chip status error:  barrel  1  half ladder  1  phi wedge  6  
          layer  5 GlobalLibraryLogger SiVrbInfoSet::setHdi ()  
          4-Apr-2001 14:42:30 run = 111193 event = 37 
%ERLOG-s Readout errors detected in Silicon Raw Banks (SIXD, ISLD):  
         SUB=@SiClusterningModule::event CHIP_INVALID SiClusteringModule  
          4-Apr-2001 14:44:15 run = 111193 event = 34 
</pre>
<!-- Author: Saverio -->



<!-- Date: Wed Apr 4 15:49:57 2001 -->
<pre>We noticed that DOIM ring on BHW1 (center barrel - west BH) runs 
near 20 C for 10 C collant temperature. All the others seem to be 
~10-12 C . This coud be that the RTD is touching the 
port card substrate. For now, we will le t it run ,but we should 
keep an eye on it. 
 
When turning on the Port  
 
Note: The DOIM ring is the A-ring on iFix.</pre>
<!-- Author: Steve Blusk -->


<!-- Date: Wed Apr 4 15:54:47 2001 -->
<pre>Igor has placed calibrations in the database.  Below 
is Petar's talto to use them.  After using this calibration 
I noticed that the ISL data does not improve very much.  We 
still seem dominated by noise and the noise occurs in all 
myron buckets.  However, David S. sees clusters so the Data 
is fine.  Suspects are the calibration or the numerology. 
 
module talk CalibrationManager 
  add onotl_dev OCI cdf_reader/reader@cdfondev 
  DataDB      set onotl_dev 
  Database    set onotl_dev 
# Define the entry in USED_SETS that we want to load. 
  ProcessName set RUN2_SILICON_PEDTEST 
exit 
 
module talk GeometryManager 
show 
  DetectorMenu 
    enableAll set t 
  exit 
exit 
 
module enable SiClusteringModule  
talk SiClusteringModule 
 DataRep set Run2V1_3BS 
 ClusterFinder set SIMPLE 
#   DebugMenu 
#     PrintNClusters set t 
#   exit 
   StripCorrectorMenu 
      FlagBad set t 
      RemoveBad set t  
      SubtractPedestal set t  
      RemoveUnderThreshold set t  
      NSigmaCut  set 2.0 
      DcmsMode   set f 
#      DcmsOffset set 0 
      DeadDBRun     set 111113 
      DeadDBVersion set 1 
      DeadDBStatus  set RAW 
  PhiClusParam 
    lowThresh set 2.0 
    minDeltaQ set 10 
   1stripThresh 
     peakThresh set 4.0  
   exit 
   2stripThresh 
     peakThresh set 3.0  
   exit 
   3stripThresh 
     peakThresh set 2.0  
   exit 
  exit 
  ZClusParam     
    lowThresh set 2.0 
    minDeltaQ set 10 
   1stripThresh 
     peakThresh set 4.0  
   exit 
   2stripThresh 
     peakThresh set 3.0  
   exit 
   3stripThresh 
     peakThresh set 2.0  
   exit 
  exit 
exit 
 
</pre>
<!-- Author: herndon -->
<!-- Comment: Wed Apr  4 17;39;50 comment by...herndon -->
<pre>Igor has a new calibration based on run 111193.  This calibration
clears up much of the noise seen in the ISL when using
calibration 111113.</pre>
<!-- Date: Wed Apr 4 16:00:15 2001 -->
<pre>I'm building default executables on fcdfsgi2.  These include 
development versions of  SiHitAnalyzer, Silimon and evd. 
 
The release is in 
fcdfsgi2: /cdf/data04/s6/tracking/herndon/shot1 
 
I also have default tcl files 
SiHitAnalyzer: siHit.tcl 
Silimon: SiliMon.tcl or SiliMon_nocalib.tcl 
evd: just run by typing evd and the name of the file. 
 
 
</pre>
<!-- Author: herndon -->



<!-- Date: Wed Apr 4 18:02:46 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030>Discovered bias values for SB2W8 were wrong. Values entered were 
the voltages for SB4W8. EDITED CAENvolts.dat with new numbers. 
crosschecked all other SVX biases - they are fine. Old layer 2 
bias settings were probably not large enough to fully deplete.</td></tr></td></table>
<!-- Author: Mary Bishai -->


<!-- Date: Wed Apr 4 18:08:59 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-22&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-22  width='300' align='top'></td><td>Silimon plots on-line run 111281 Voltages on</a></td></tr></table>
<!-- Author: Saverio & Sehban -->


<!-- Date: Wed Apr 4 20:28:18 2001 -->
<pre>silimon not working (its all saverio's fault!)</pre>
<!-- Author: worm -->


<!-- Date: Wed Apr 4 20:35:46 2001 -->
<pre>cot problems, magnet off, L3 problems, etc... 
(no run in progress... for last 30 min)</pre>
<!-- Author: worm -->


<!-- Date: Wed Apr 4 21:11:52 2001 -->
<pre>partitioning... almost ready to start running again...</pre>
<!-- Author: worm -->


<!-- Date: Wed Apr 4 21:18:39 2001 -->
<pre>...lacking any working online monitoring program, I ran Herndon's  
siHitAnalyzer: saw some really strange charge values.  Paged Matt 
and he tells me that the charge at ~500 is actually some new error codes (not charge) and that it should/will be filtered out.   
 
So ignore the strangely high cluster charges until he fixes...</pre>
<!-- Author: worm -->
<!-- Comment: Thu Apr  5 04;48;38 comment by...Petar -->
<pre>I was trying to build various online tools on b0 cluster.

- b0dap30 is too crowded: the system is crawling, there are
  too many tasks and gmake often doesn't work due to a system
  error "too many files open"

- couldn't log into b0dap31 (controlled access).

So I unfortunately we'll have to run our online monitors 
from fcdfsgi2 (which is not fast either)...</pre>
<!-- Date: Wed Apr 4 23:01:01 2001 -->
<pre>Starting from run 111291 we were taking data with the 9  
wedges in readall and DPS off. The trigger tables and non-silicon  
settings were vaying quite a bit I believe, so pay attention to  
that when you analyze these runs. Next step will be to switch  
to Nearest Neighbour and DPS on. Run numbers will follow... 
</pre>
<!-- Author: Petra -->


<!-- Date: Thu Apr 5 00:09:51 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Starting from run 111306 we are running the silicon wedges in  
Nearest Neighbour and DPS on with a threshold of 5 for all  
three detector types. Hopefully we will see a lot of stable data  
with these settings during the night! Happy analyzing for all!</pre></td></tr></td></table>
<!-- Author: Petra -->


<!-- Date: Thu Apr 5 00:59:23 2001 -->
<table><tr><td><a href=/elog/notebooks/silicon/Thu_Apr__5_2001_005901.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-26  align='top'></td><td>First hint for combined COT - Silicon track, hitting L00,  SVX, ISL and COT !</a></td></tr></table>
<!-- Author: Petra -->
<!-- Comment: Thu Apr  5 08;43;47 comment by...Petar -->
<pre>I've spent hours looking at plots like these in the 
commissioning run and yes, this one does look tantalizing!

BTW, Peter Tamburello published his latest recipe for the
COT tracking callibration, which I append below.  The evd
scrips perhaps should be keept abreast of these developments...

module talk CT_TrackingModule
  ConstantsMenu
    useT0Constants set t
    useRunFromTcl set t
    calibrationRun set 110737
  exit
exit

module talk CalibrationManager
  add database OTL cdf_reader/reader@cdfofprd
  DataDB       set database
  Database     set database
exit
</pre>
<!-- Date: Thu Apr 5 02:34:32 2001 -->
<pre>FYI.  Vladimir has informed me that Fib06 stopped responding.  He rebooted and it seems to work fine again now.</pre>
<!-- Author: Rob -->
<!-- Comment: Thu Apr  5 09;00;58 comment by...SCN -->
<pre>My impression is that a ladder or two has tripped off,
so the initialization is failing, which takes
a long long time.  "Not responding" is probably just
lask of patience.</pre>
<!-- Date: Thu Apr 5 02:41:33 2001 -->
<pre>Silimon is giving some new errors:<br> 
<br> 
StorableBank::get_I2_element(): out-of-bounds exception 
offset = 0, index = -1943337319, data_size = 1318 
out-of-bounds exception occurred while accessing Bank ISLD, 1 
<br> 
I am also have difficulties (i.e. total failure) getting the socket connection to HistoDisplay to work correctly. 
</pre>
<!-- Author: Rob -->



<!-- Date: Thu Apr 5 03:45:12 2001 -->
<pre>I used the SiHitAnalyzer to look more closely at the error codes Steve W. <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=16&frame=2&anchor=21:18:39'> 
mentioned previously</a>.<br> 
The error code that appears with the high frequency (causing the spike in the plots) is <B>#518</B>.<br> 
Other error codes which occur are: 583, 599, 601, 667, 690, 1130, 1228, 1426, 1554, 1558, 1654, and 2137.  These are all of very low frequency, however.</pre>
<!-- Author: Rob -->
<!-- Comment: Thu Apr  5 06;31;12 comment by...Rob -->
<pre>Almost all of the "#518 errors" can be attributed to just two strips.  These are strip 451/barrel 0/layer 7 and strip 388/barrel 1/layer 5.  The number conventions are that of the SiHitAnalyzer.</pre>
<!-- Date: Thu Apr 5 05:10:53 2001 -->
<pre>The fun has begun.  Around 0320 Vladimir noticed an "alarm" in iFix concerning PCW1A_2 and asked me to check the GUI.  This caused me to notice two things: 
<ol> 
<li>The corresponding component in the silicon, B2W8, had <b>not</b> tripped off. 
<li>B3W5 had a trip on channel 0, but did <b>not</b> give a trip acknowldege message. 
</ol> 
<p><b>B2W8:</b>After investigating we found the portcard was slightly over 20 degrees.  The graphic in iFix had given what looked like an alarm -- but was apparently only a warning -- about the temperature.  Since the CDF clock was having trouble and there was no run going anyways we turned the power off.  It  cooled back down to 11 degrees in a little under 5 minutes.  We will probably leave it off until an expert gets here in the morning.<br> 
<p><b>B3W5:</b>It looks like the trip was due to an over current on the DVDD0.  I tried several times to bring it back up to no avail.  It really disturbs me that I didn't get a trip acknowledge message from the GUI, nor was there originally any message in the log window.  I only found this because of the other problem Vladimir had me looking into.  (I did get trip messages/logs during my subsequent attempts to bring the channel back up, however.)<br> 
<p>Vladimir has also posted some comments in the <a href='/cgi/elog/elog.pl?nb=2001&action=view&page=182&frame=2&anchor=04:26:55'>CDF Shift Log</a>.  Be sure to note that he tweaked the DAQ some so he could continue running the other silicon components. 
</pre>
<!-- Author: Rob -->


<!-- Date: Thu Apr 5 05:25:17 2001 -->
<pre>The latest versions of DBANA that can readout SICHIPPED tables 
can not be yet posted in cvs. Hope this will change soon, but 
in the meantime, it can be run from: 
fcdfsgi2: /cdf/spool/vnagasl/Dbana/tmpdb/bin/IRIX6-KCC_4_0/DBANA</pre>
<!-- Author: Vladimir -->
<!-- Comment: Thu Apr  5 05;51;48 comment by...Vladimir -->
<pre>...and yes, it reads only SVX!</pre>
<!-- Date: Thu Apr 5 05:26:07 2001 -->
<pre>Offline news: there was a bug in SiClustering, fixed by Rick  
Snider earlier today (involves TrackingSI, but will be in 
development on Thursday). 
 
Also, Igor has updated the DPS off pedestal table, and has 
a first-pass for DH, so the correct SiClusteringModule talk-to 
now looks like this: 
 
talk ClusteringModule 
   StripCorrectorMenu 
      FlagBad set t 
      RemoveBad set f  
      SubtractPedestal set t  
      RemoveUnderThreshold set t  
      NSigmaCut  set 2.0 
 
      PedDBRun     set 111193 
      PedDBVersion set 2 
      PedDBStatus  set RAW 
 
      DeadDBRun     set 111193 
      DeadDBVersion set 1 
      DeadDBStatus  set RAW 
   exit 
exit 
</pre>
<!-- Author: Petar -->
<!-- Comment: Thu Apr  5 08;37;50 comment by...Petar -->
<pre>Looked at 111193 with the new pedestals.  What's interesting
is that the ISL looks OK, and there even seem to be hits.

However, the Vdf shows that the 3D hits are a little bit off
the intersection of phi and SAS strips in many ISL half-ladders,
indicating either an ISL geometry problem either in
SiliconGeometry or in Visualization (which copies it).

Aarond and Joe are just about to commit a bunch of changes,
so let's see what happens.  The bottom line is that the
pedestals seem OK.</pre>
<!-- Date: Thu Apr 5 07:17:17 2001 -->
<pre><p>As the SiShifter I have been regularly checking the Bias Current Histories in iFix.  These values (and those currents reported by the GUI) seem dubious to say the least.  Quite often they are so low as to virtually disappear from the plot due to the scale.  Truthfully, you can't even tell if iFix is reporting properly in half the cases. 
<p>Now, I am naturally inclined to blame the power supplies themselves for any misrepresentation of the currents reported in iFix (and the GUI), but these values seem a bit out of range even for CAEN.  The typical offset (error) in the bias current reading for SVX supplies is ~5-15 uA [exceptions are B1W6 layer 2 and B3W5 layer 3 which are ~45uA off, and B3W5 layer2 and B4W5 which are ~25-30 uA off].  This doesn't seem quite bad enough to fully explain what we are seeing now in iFix and the GUI.  Does anyone have any theories?</pre>
<!-- Author: Rob -->




<!-- Date: Thu Apr 5 08:52:44 2001 -->
<pre>Just to mention that a fairly recent versions of SiliMon 
and vdf-module (which I call pm_vdf) can be found in 
my development release in fcdfsgi2:/cdf/scratch/petar/d. 
 
The tcl files are in: 
/cdf/scratch/petar/d/Consumer/SiliMon/SiliMon.tcl for SiliMon 
 
and  
 
~/tcl/r2_vdf_clust.tcl for pm_vdf 
 
Both executables have all known patches and the talk-tos 
are up to date.  Good luck!</pre>
<!-- Author: Petar -->