<!-- Title: 08:43:05  Mon Aug 13 2001 -->
<!-- Crewchief: silicon squad -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>It's Monday morning! 
 
Plan: 
  1. andrew and re-tries on bias - see 1st below 
  2. x-mode/fid pedestal subtraction 
  3. feedback on timing scan 
  4. calibration runs D-mode when store gets dropped.</pre>


<!-- Date: Mon Aug 13 08:45:08 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030>See this  
<a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=61&frame=2&anchor=08:32:49'> 
entry </a>  
for CAEN GUI problems from last night.</td></tr></td></table>
<!-- Author: jean -->
<!-- Comment: Mon Aug 13 15;19;12 comment by...doug -->
<pre>
Andrew found a bug in the GUI (a typo) which explains last
night's strange behavior.  Here's what happened:
 
  - andrew modified gui so that it would _not_ automatically
    reset software or hardware trips; he tested that the gui
    reaction to software trips worked, and assumed it was ok
    for hardware trips (since code was "the same")

  - there was a typo in the code which handled the hardware
    trips so that the GUI treated them like spontaneous on/offs

  - andrew fixed the bug, and (successfully) tested that the gui
    properly handles both software and hardware trips

  - the ISL ladder in question, IB5W3L3 has been operating very
    near the trip point for the fine I_bias scale on bias_1...
    it was occassionally creeping &gt;50 uA, which caused the trips;
    we will need to set this to the coarse scale before returning
    full bias to this ladder.  We set V_bias_1 to 2 volts in 
    CAENvolts.dat</pre>
<!-- Date: Mon Aug 13 09:45:31 2001 -->
<pre>Calibration runs 123542, 123544 have been processed. The 
following tables have been written: 
 
Table       Run    Version  Status 
SICHIPPED : 123544   1      COMPLETE_DPS 
SISTRIPDH : 123544   1      COMPLETE 
 
These tables may currently be used with the following runs: 
 
123546 123547 123551 123552 123553 123559 123560 123562 123564 123565 
123566 123568 123571 123573 123574 123575 123577 123582 123586 123591 
123595 123604 123605 123614 123615 123616 123618 123619 123623 123624 
123626 
 
Note that the timing scan runs with L00 (runs 123607, 123608, 
123609, 123611, and 123612) can not be processed with these 
tables because the calibration runs did not include L00. 
</pre>
<!-- Author: Igor -->


<!-- Date: Mon Aug 13 11:27:17 2001 -->
<font size=+2> 
<ol> 
 
<li> CAEN PS cable swap 
<li> change FFO in Fib 06 as possible source of bunch crossing 
    errors in  that crate 
</ol></font>
<!-- Author: jean -->
<!-- Comment: Mon Aug 13 15;01;27 comment by...doug  -->
<P>
I assume this is an access request list?  If so, we should
also add:<BR>
<B> 3. Change ISL B5W3L3 to coarse I_bias scale for bias_1 <BR>
</B> (leave bias_0 as is)
<!-- Comment: Fri Aug 17 17;27;18 comment by...doug -->
<P>
<B>
All three of these accomplished during the <BR>
afternoo access of 17-Aug-01.  See below.
</B><P>
<!-- Date: Mon Aug 13 12:19:07 2001 -->
<pre>Initial comments from Matt on timing study on Sunday 
 
  In the data that you sent me we are seeing an average of 4 tracks per 
event in the correct myron bin.  However the pt distribution is very low. 
We see .5 tracks per event above 1 GeV and about .05 tracks per event 
above 2.0 GeV. 
 
  If I analyze what we have on disk I can probably make plots with about 
750 clusters per sensor type for tracks above 1.0GeV.  This would be a 
somewhat decent study.  If I analyze the entire 100k events I can get 
about 1250 clusters per sensor type for tracks above 2.0GeV.  However, 
this will probably take a whole week because I'll have to stage the data 
to disk.  This would be a decent study. 
 
   To do a good study we would want to be able to look at individual 
sensors.  For this I think we need data with a better trigger.  Track 
trigger above 2.0GeV with level 3 turned off so that events aren't 
filtered out.  200k events.  However we only really want this at the more 
important bins.  For a quick study you would only really need 10K events 
with this trigger. 
 
  I'm going to start the quick study now.  However, the results will be 
somewhat suspect since the database access is still messed up.  Petar is 
working on it. 
 
</pre>
<!-- Author: Matt&#39;s email -->


<!-- Date: Mon Aug 13 12:20:07 2001 -->
<pre>Calibration runs right after end of the store: 
123637 DPS-on  /cdf/data08/_ICALIR.0000/ir01e2f5.0001cali  1.9G Aug 13 11:41  
123649 DPS-off /cdf/data08/_ICALIR.0000/ir01e301.0001cali  1.9G Aug 13 12:04  
No L00.</pre>
<!-- Author: Saverio -->
<!-- Comment: Mon Aug 13 14;53;13 comment by...doug -->
<P>
For future reference:
<P><B>
If there's no beam in the machine, should page <BR> David and
try to get L00 in the calibrations</B>




<!-- Date: Mon Aug 13 15:32:11 2001 -->
<pre>David and I (well, mostly David) looked at IB5W3L3, the ISL 
ladder which was tripping on Vbias and being auto-reset by the 
GUI last night.  It has been operating near the trip limit (50  
uA) and would occassionally spike high enough to trip.  Presently 
we have set Vbias_1 to 2.0 volts in CAENvolts.dat.  Vbias_0 is 
fine. 
 
&gt;&gt;&gt; When you use cratematch.pl, there will now be an additional 
&gt;&gt;&gt; ladder listed as "should be biased" but is not IB5W3L3 
 
Presently this ladder is "x"d (from this morning) and out of 
the HWDB.  Prior to physics, need to remedy this. 
 
During next access, need to change the I_bias_1 to the coarse 
scale so that we can bias this channel.</pre>
<!-- Author: doug -->
<!-- Comment: Mon Aug 13 16;19;14 comment by...doug -->
<pre>OK - I-B5W3L3 is included in run.  V_bias_1 set to 2.0 volts
in CAENvolts.dat and un-"X"d. CAENvolts.dat downloaded to GUI.
Re-included this ladder in HWDB.

We're in run and ready for physics.  TeV has injected all 36 
proton bunches... so it looks like a real shot set-up.</pre>


<!-- Date: Mon Aug 13 17:42:17 2001 -->
<pre>store in, but it's pitiful (~0.5E30) and losses at about 
2.5 kHz for Plos and 0.5 kHz for APlos.  they lost 2/3 the beam 
during the ramp.  still, they won't shoot again until tomorrow, 
when the stack is larger (damn PBars). 
 
had to "X" S-B2W8L4 b/c it immediately trips on DVDD OV when 
moving to STBY.  CAENvolts.dat updated and downloaded. HWDB  
appropriately modified. 
 
SB4W6L0 tripped on bias OC from standby.  Too fast for the SPY, 
which just records I_bias = 0 uA at 2 V and then OFF at the 
next update.  This happened during the TeV ramp and the trip may 
have been co-incident w/ the large losses the TeV reported.  I 
reset it and it looked fine.  Now at full volts (90) and drawing 
~0.3 uA - OK. 
 
Lastly, had a couple software DVDD OC trips during the chaos of 
run start, where they had to stop/restart the run several times 
owing to several problems (only 1 silicon related)</pre>
<!-- Author: doug -->


<!-- Date: Mon Aug 13 18:32:22 2001 -->
<pre>w've been in and running fine at full bias for awhile now. 
run number is 123712 (but many stops/starts for L2 studies). 
we've 73 wedges.  only difference from calibration runs is that 
I-B5W3L3 was included again (Vbias0 at full volts, while Vbias1 
at 2 volts, so 1/2 the ladder will be inefficient) and SB2W8L4 
was excluded. 
 
</pre>
<!-- Author: doug -->


<!-- Date: Mon Aug 13 18:44:36 2001 -->
<pre>since store is so pitiful and runs are for L2 studies, we 
decide to take silicon for some studies of our own.  petra 
will try to re-integrate the wedges tossed out due to reformatter 
errors and the two wedges lester had to boot just after the 
over-enthusiastic aces hit the crash button. 
 
we'll go to stby for these studies. 
 
she'll return us to run when L2 is done and return to full bias 
then (assuming losses allow).</pre>
<!-- Author: doug -->


<!-- Date: Mon Aug 13 23:48:35 2001 -->
<pre>Summary of my investigations this evening: 
========================================== 
 
the four points I wanted to look at were: 
1) software protection trips @ pause state 
2) sporadicly failing coldstarts (single ladders) 
3) sporadic reformatter errors (single ladders) 
4) reintegrate previously kicked out ladders (due to reformatter errors) 
 
coldstart problems summary: 
--------------------------- 
IB5W1L1 and SB0W0L2 failed CS every second time almost, I masked  
them off (HDI#+16), that helped... 
I also had many single failures of different ladders and I started  
a list (on paper) to start to keep track of them, you find the list  
where the GUI mistery list is. 
 
work on previously kicked out ladders: 
-------------------------------------- 
SB4W10L4 still shows a lot of errors (still out) 
SB4W5L2 is ok now 
SB3W11L4 still shows errors (still out) 
SB5W1L3 is ok now 
SB0W5L0L2L3 is ok now 
SB3W4L0L1L2 doesn't show the errors, but many software protection trips  
in L1 and L2 and "normal" DVDD OC trips on L0. I kicked this wedge  
out again in order to get a more stable situation; but readout wise it looks fine. 
SB4W9L3 already included anyway 
SB4W1L4 is ok now 
SB3W1L3 already in anyway 
SB0W5L1 is ok now 
 
"work" on software trips due to paused/halted run: 
-------------------------------------------------- 
I paused the run twice and halted it once for about 2 minutes each  
and nothing tripped... so at least it's not THAT repeatable... 
 
reformatter errors: 
------------------- 
I didn't have any new persistent reformatter errors in any of the other ladders during several hours of work! 
 
new calibration runs: 
--------------------- 
in the end I took new calibrations with the current set of ladders: 
DPS on: run 123763 
DPS off: run 123770 
both runs copied to /cdf/scratch/petra/. on fcdfsgi2 
 
</pre>
<!-- Author: Petra -->
<!-- Comment: Tue Aug 14 07;44;15 comment by...SCN -->
Regarding sporadic failed initializations, it would be nice
to know how they fail-is it all ffs, all 0s, or a scrambled
return bitstream...
<!-- Comment: Tue Aug 14 13;25;03 comment by...Igor -->
<pre>The typical noise level in these calibration runs is about 12%
higher than usual. If the common mode is suppressed than the
noise is about 5% higher. Are these runs taken with the beam in
the machine? If so, maybe this noise is more realistic...

</pre>
<!-- Comment: Thu Aug 16 17;06;42 comment by...doug -->
<pre>Yes, there was beam in the machine (collision data) when these
runs were taken.</pre>
<!-- Date: Tue Aug 14 00:26:31 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>I turn everything but L00 to ON and it is integrated.</pre></td></tr></td></table>
<!-- Author: petra -->


<!-- Date: Tue Aug 14 00:37:35 2001 -->
<pre>after integrating it again, i got ~2% reformatter errors from SB0W5L2.  
Since I want to go home now, I took it out...</pre>
<!-- Author: petra -->
<!-- Comment: Tue Aug 14 01;01;15 comment by...petra -->
<pre>and then it takes the next ladder in this wedge! I kicked the whole SB0W5 out now!</pre>



<!-- Date: Tue Aug 14 08:13:44 2001 -->
<pre>External trip of one layer in B4W11.  There is no reason 
that this should ever happen.  I investigated and found 
from full status that there was an external trip status in 
the crate.  Cleared trip and turned ladder back to standby. 
 
ISL B0W1 Layer 0 triped due to software protection trip. 
</pre>
<!-- Author: matt and doug -->
<!-- Comment: Tue Aug 14 14;40;05 comment by...doug -->
<pre>just observed an I-B0W5L2 "External trip" on Vbias0.  the 
"External trip" matt mentions above was on DVDD-3.  perhaps these
are another "feature" of CAENnet?  i'll bug andrew about this.
we simultaneously had a software protection trip on SB10W4L4 at
the same time as this "External Trip".  perhaps these are 
correlated.</pre>
<!-- Date: Tue Aug 14 08:54:05 2001 -->
<pre>ISL cooling investigations... 
 
  - set ISL N_2 flow to 15 scfh 
  - have silenced related alarms on process systems alarms page 
  - will leave this way for ~1-2 hours 
  - cryo techs helping to keep an eye on the ISL dew pt; 
    they will page me if it gets &gt;= -20 deg-C (ilocks won't 
    be affected until dp ~0 deg-C, presently they're -50 deg-C) 
 
</pre>
<!-- Author: doug -->
<!-- Comment: Tue Aug 14 11;56;55 comment by...doug  -->
<pre>finished w/ these tests.  all back to nominal.
alarms un-silenced.</pre>
<!-- Date: Tue Aug 14 09:19:58 2001 -->
 
Temporarily turned off IB5W1-L1 after Matt Noticed AVDD 
current was high. 
<a href= 
'/cgi/elog/elog.pl?nb=2001&action=view&page=576&frame=2&anchor=09:17:35'> 
see here</a>   
<!-- Author: jean -->
<!-- Comment: Tue Aug 14 09;41;49 comment by...petra -->
<pre>this is one of those ladders where I masked off the HDI#...</pre>


<!-- Comment: Tue Aug 14 12;40;53 comment by...doug -->
<pre>tried to include this into a pre-physics run.  sat w/ I_avdd_1
at about 1500-1600 mA while they partitioned, etc.  even after
coldstart, it stayed at this hi-I.  i power cycled it and it
came back w/ I_avdd_1 ~ 1250 mA, which is healthy.  after another
coldstart (they had to restart run due to EVB) the current stayed
healthy and passed CS just fine.  running smoothly now.  petra
and i unmasked the HDI (22 -&gt; 6 in HWDB).  </pre>
<!-- Comment: Tue Aug 14 14;18;47 comment by...doug -->
<pre>the saga continues... i got paged b/c IB5W1 was repeatedly 
failing coldstarts.  i came over and found the currents all
reading ok.  the run was "idle". i remasked the HDI (6-&gt;22),
and noticed that I_avdd_1 immediately jumped to &gt;1500 mA (from
a healthy 1250).  i power cycled this wedge and the hi-I 
remained.  after coldstart and some data taking, hi-I still 
there.  this leads me to believe that "masking" the HDI in this
manner somehow affects the chip initialization (although this is
_not_ what anyone expects).  i'm uncomfortable leaving it in this
hi-I state.  so i return the HDI 22-&gt;6 but mask-off this ladder
and "X" it from CAENvolts.dat.</pre>
<!-- Date: Tue Aug 14 11:40:03 2001 -->
<pre> I just want to be sure that everyone realizes that individual ladders can 
be left out of the handshake upon turning on the CAENs.  Andrew only sends 
a list of wedges to Steve, not a list of ladders.  Steve determines which 
ladders in those wedges to init based on the maps.  The maps are 
downloaded to the fibs only upon initialization during coldstart, not just 
bevcause there is a handshake. So, if individaul ladders are enabled in 
the hardware database and in CAENvolts.dat after the system is 
initialized, those ladders will not have their DDRs turned on and will not 
be sent a keepalive initialization. 
 
   What this means is that one should not re-integrate ladders unless one 
is prepared to immediately initialize them via coldstart. 
 
</pre>
<!-- Author: jean -->
<!-- Comment: Tue Aug 14 12;14;55 comment by...Steve Nahn&#39;s email -->
<pre>   For the handshake, all 10 DDRs of a FIB are enabled, and the same 16 chip
bitstream is sent to all at the same time, completely independent of 
any map.  The issue is which DDRs are left enabled after this is done, thus
which ladders receive the keepalive.  
For this the Fib uses the map which was updated at the time of the last RC
initialization or the last "downloadMaps"
from the teststand.

I think it is a very good policy not to turn on ladders until you are
ready to initialize them.


</pre>






<!-- Date: Tue Aug 14 14:42:23 2001 -->
<pre>we were in at full bias and running. track trigger problems 
forced them to restart run.  they're partitioning run 123836 now. 
 
Plos = 11 kHz and Alos = 3.5 kHz Lum = 5E30.  we're at full bias.</pre>
<!-- Author: doug -->


<!-- Date: Tue Aug 14 14:44:00 2001 -->
<P> 
<B> Matt just changed the ramp rates: 
<UL> 
  <LI> ramp-up = 5 v/sec 
  <LI> ramp-dn = 20 v/sec 
</UL> 
</B> 
re-loaded CAENvolts.dat and "set Ramp rates" in GUI.
<!-- Author: doug (for matt) -->
<!-- Comment: Thu Aug 16 15;26;28 comment by...doug -->
<pre>i have observed that the ramp-up takes longer and is consistent
w/ a rate of 5 v/sec</pre>
<!-- Date: Wed Aug 15 15:51:42 2001 -->
<pre>i should have noted that yesterday at around 1700 the CO 
noticed that SiliMon was finding no clusters in the silicon.  we 
spent some time confirming that we were at full bias and that 
there were no reformatter errors.  also, the occupancy plots  
were fine.  i concluded it was an offline problem and told them 
to page Tara.</pre>
<!-- Author: Doug -->


<!-- Date: Wed Aug 15 20:05:13 2001 -->
<pre>Update on calibrations: 
 
a recent run:  
  Beam Run 123879 2001.08.15, started at 11:39:08 
Most recent calibration:  
  Pedestal Run 123637 2001.08.13, started at 11:26:17 
List of mismatch: 
There are 4 ladders in the data run  
that were not included in the calibration run: 
SB4W1L4  
SB5W1L3  
IB5W3L3  
SB4W5L2  
 
We can (and should) use this calibration with the most recent data, paying this little price of just 4 HDIs non calibrated. 
</pre>
<!-- Author: Saverio -->


<!-- Date: Wed Aug 15 22:38:28 2001 -->
<pre>It also should be noted that at around 3 PM I stopped the  
PS GUI running the L00 supply on b0dap41, so that I could 
use that terminal to do DAQ stuff.  I told Jean, and 
we called and paged Andrew but to no avail.  Jean called 
back later and said she would see about starting it again...</pre>
<!-- Author: SCN -->


<!-- Date: Thu Aug 16 06:11:21 2001 -->
<pre>There are no new calibrations, so I marked the used sets for the 
PROD_PHYSICS_SVX process in such a way that all runs taken from 
Aug 13 until now will use calibration runs 123637, 123649. These 
calibrations are typically missing 5 ladders compared to the 
ladder sets included in the data runs. 
</pre>
<!-- Author: Igor -->


<!-- Date: Thu Aug 16 09:11:16 2001 -->
Was going to do X Mode, but...<BR> 
MonAce came in with a Alarm from SVXII, L00, ISL on global  
IFIX page.  Turns out GUI was dead, alarm was due to handshake 
between GUI and IFIX missing.  Could not find the terminal 
in which the java process was started.  Last ~50 printfs 
of svxinter look like (can be found in /cdf/people2/~svxii/deathOfPS.010816):<pre> 
Module busy 
Sending Request for f020 
Sending Request for f030 
Sending Request for f040 
Module busy 
Sending Request for f050 
Sending Request for f500 
Module busy 
Sending Request for f510 
Sending Request for f520 
Sending Request for f530 
Module busy 
Sending Request for f540 
Sending Request for f550 
 Caenet_write: Error number -1 ffffffff received 
group_info:cr_n = 16, response = -1 
 Caenet_write: Error number -1 ffffffff received 
group_info:cr_n = 14, response = -1 
 Caenet_write: Error number -1 received 
 
Errcode 10-1 
setPSStatus -- getPSInfo,err = 10,detector = 1, ps_n = 38 
setDetectorStatus,err = 1, detector = 1setStatus,err = 1detector = 1, ps_n = 11, 
 layer_n = 2 spontaneously turned on/off (to status = 1) 
turning it back on/off (status = 0) 
Sending Request for e0b0 
detector = 1, ps_n = 14, layer_n = 5 spontaneously turned on/off (to status = 1) 
turning it back on/off (status = 0) 
detector = 1, ps_n = 25, layer_n = 0 spontaneously turned on/off (to status = 1) 
turning it back on/off (status = 0) 
Sending Request for e210 
detector = 2, ps_n = 2, layer_n = 0 spontaneously turned on/off (to status = 1) 
turning it back on/off (status = 0) 
Sending Request for f020 
Sending Request for e210 
Sending Request for e4b0 
Sending Request for f020 
Module busy 
Module busy 
detector = 1, ps_n = 26, layer_n = 0 spontaneously turned on/off (to status = 1) 
turning it back on/off (status = 2) 
Sending Request for e220 
detector = 1, ps_n = 31, layer_n = 4 spontaneously turned on/off (to status = 2) 
turning it back on/off (status = 1) 
detector = 1, ps_n = 42, layer_n = 4 spontaneously turned on/off (to status = 1) 
turning it back on/off (status = 2) 
Sending Request for e360 
detector = 1, ps_n = 43, layer_n = 0 spontaneously turned on/off (to status = 1) 
turning it back on/off (status = 2) 
Sending Request for e370 
Module busy 
</pre> 
 
  Found <ul> 
<li> Many Many (~ 15) identical PS java processes running 
on b0dap40.  Please remember that just because there is a 
lock file does not mean the PS GUI exited-you have to kill it. 
(<I>killall -KILL java</I>) 
<li> Trying to restart, had to eliminate all ROBINObject 
processes on svxinter 
<li> On sucessful restart, had Software trip 
in ISL B5 W5 L2.  Jean says this is because things were turned off and 
then turned on without RC initialization.  Note, the restarting 
of the GUI took 5 minutes, we do not know how long the 
affected ladders were in a high current state, but it could be of that order.  <B>Seems to me we have no idea of high current conditions if the GUI is not working</B> 
</ul> 
  
<!-- Author: SCN -->
<!-- Comment: Thu Aug 16 09;12;16 comment by...SCN -->
Forgot to mention-attempted to initialize all FIBs with RC,
so currents should be low now.

<!-- Comment: Thu Aug 16 14;13;54 comment by...Lester -->
<pre>On running PS: we should run it not as a background process. 
If you then control-c out of it, it will die as it should 
and not leave java running.</pre>


<!-- Date: Thu Aug 16 14:28:42 2001 -->
<pre>We ramped-up in this last store and are running smoothly in 
run 123961.  Deadtime problems (not associated w/ us) 
necessitating frequent run starts/stops, etc. 
 
Lum = 7.5E30 
Plos = 11.4 kHz 
Alos = 4.4 kHz 
 
Steve/Colin had us in at standby at start of store.  We ran  
smoothly for a short while before asking they restart the run w/ 
us at full bias.  While ramping the HV, S-B2W1 tripped on DVDD-0 
OC (hardware trip).  During coldstart, I-B5W0 failed once and 
S-B0W0 also failed once.  Fine since then.  </pre>
<!-- Author: doug g -->


<!-- Date: Thu Aug 16 14:39:26 2001 -->
<pre>Ploss got up to avg of 25 kHz w/ spikes up to 45-50 kHz.  Myron 
called MCR.  They fixed it in &lt;30 minutes.  Presently at about 
12 kHz and taking data.</pre>
<!-- Author: Doug -->



<!-- Date: Thu Aug 16 16:19:09 2001 -->
<pre>&lt;h3&gt;X Mode news and Request&lt;/h3&gt; 
Yesterday, the CALIB. CSL failed, today, it was 
the SEVB's turn.  That is now fixed, and some 
obvious bugs in the Calibration State Manager were found, 
but instead of attempting to wrest the Si crates from the 
Physics partition to spend only ~1/2 hour testing, we 
decided to leave them in this nice store while the luminosity 
is high.&lt;P&gt; 
In exchange, we could use some time with the crates, tomorrow  
perhaps even if the store is still in (presumably the lumi is 
waning).  Anyone who wants data can have all that 
is collected over the evening...</pre>
<!-- Author: SCN -->
<!-- Comment: Thu Aug 16 16;19;54 comment by...SCN -->
<h3>X Mode news and Request</h3> 
Yesterday, the CALIB. CSL failed, today, it was 
the SEVB's turn.  That is now fixed, and some 
obvious bugs in the Calibration State Manager were found, 
but instead of attempting to wrest the Si crates from the 
Physics partition to spend only ~1/2 hour testing, we 
decided to leave them in this nice store while the luminosity 
is high.<P> 
In exchange, we could use some time with the crates, tomorrow  
perhaps even if the store is still in (presumably the lumi is 
waning).  Anyone who wants data can have all that 
is collected over the evening...


<!-- Date: Thu Aug 16 17:01:23 2001 -->
<pre>COT having trouble holding HV for part of SL2.  They're out of 
run and anticipate needing of order 2-3 hours  to get back to 
full volts.  So, Petra is taking our crates and making some 
calibrations.  THERE'S BEAM IN THE MACHINE (L = 6.5E30), Plos 
of order 15 kHz.</pre>
<!-- Author: doug -->



<!-- Date: Thu Aug 16 18:22:27 2001 -->
<pre>New calibrations (during collisions, L_inst=6.1E30): 
==================================================== 
DPS on: run 123977 
DPS off: run 123979 
both files copied to fcdfsgi2:/cdf/scratch/petra/. 
 
the following ladders were included in these runs: 
-------------------------------------------------- 
 List of the 347 biased channels:  
 
SB0W0L4  SB0W0L3  SB0W0L2  SB0W0L1  SB0W0L0   
SB0W1L3  SB0W1L2  SB0W1L1  SB0W1L0   
SB0W2L3  SB0W2L1  SB0W2L0   
SB0W3L3   
SB0W4L4  SB0W4L3  SB0W4L2  SB0W4L1  SB0W4L0   
SB0W6L4  SB0W6L3  SB0W6L2  SB0W6L1   
SB0W7L3  SB0W7L2  SB0W7L1  SB0W7L0   
SB0W8L4  SB0W8L3  SB0W8L2  SB0W8L1  SB0W8L0   
SB0W9L4  SB0W9L3  SB0W9L2  SB0W9L1  SB0W9L0   
SB0W10L4  SB0W10L3  SB0W10L2  SB0W10L1  SB0W10L0   
SB0W11L3  SB0W11L2  SB0W11L1  SB0W11L0   
SB1W0L4  SB1W0L3  SB1W0L2  SB1W0L1  SB1W0L0   
SB1W1L4  SB1W1L3  SB1W1L2  SB1W1L1  SB1W1L0   
SB1W2L4  SB1W2L3  SB1W2L2  SB1W2L1  SB1W2L0   
SB1W3L1  SB1W3L0   
SB1W4L2  SB1W4L1  SB1W4L0   
SB1W5L4  SB1W5L3  SB1W5L1  SB1W5L0   
SB1W6L4  SB1W6L3  SB1W6L2  SB1W6L1  SB1W6L0   
SB1W8L4  SB1W8L3  SB1W8L2  SB1W8L1  SB1W8L0   
SB1W9L4  SB1W9L3  SB1W9L2  SB1W9L1  SB1W9L0   
SB1W10L4  SB1W10L3  SB1W10L2  SB1W10L1  SB1W10L0   
SB1W11L4  SB1W11L3  SB1W11L2  SB1W11L1  SB1W11L0   
SB2W0L4  SB2W0L3  SB2W0L1  SB2W0L0   
SB2W1L4  SB2W1L3  SB2W1L2  SB2W1L1  SB2W1L0   
SB2W2L4  SB2W2L3  SB2W2L1  SB2W2L0   
SB2W3L3  SB2W3L1  SB2W3L0   
SB2W5L4  SB2W5L3  SB2W5L2  SB2W5L1   
SB2W6L4  SB2W6L3  SB2W6L1   
SB2W7L3  SB2W7L2  SB2W7L0   
SB2W8L3  SB2W8L1  SB2W8L0   
SB2W9L4  SB2W9L3  SB2W9L2  SB2W9L1  SB2W9L0   
SB2W10L4  SB2W10L3  SB2W10L2  SB2W10L1   
SB2W11L4  SB2W11L3  SB2W11L2  SB2W11L1  SB2W11L0   
SB3W0L4  SB3W0L3  SB3W0L1  SB3W0L0   
SB3W1L4  SB3W1L3  SB3W1L2  SB3W1L1  SB3W1L0   
SB3W2L4  SB3W2L3  SB3W2L1  SB3W2L0   
SB3W3L3  SB3W3L2  SB3W3L1  SB3W3L0   
SB3W5L4  SB3W5L2  SB3W5L1  SB3W5L0   
SB3W6L4  SB3W6L3  SB3W6L1  SB3W6L0   
SB3W7L4  SB3W7L3  SB3W7L2  SB3W7L1  SB3W7L0   
SB3W8L4  SB3W8L3  SB3W8L2  SB3W8L1  SB3W8L0   
SB3W9L4  SB3W9L3  SB3W9L2  SB3W9L1  SB3W9L0   
SB3W10L4  SB3W10L3  SB3W10L2  SB3W10L1  SB3W10L0   
SB3W11L3  SB3W11L2  SB3W11L1  SB3W11L0   
SB4W0L3  SB4W0L2  SB4W0L1  SB4W0L0   
SB4W1L4  SB4W1L3  SB4W1L2  SB4W1L1  SB4W1L0   
SB4W2L4  SB4W2L3  SB4W2L2  SB4W2L1  SB4W2L0   
SB4W3L4  SB4W3L3  SB4W3L1   
SB4W5L4  SB4W5L3  SB4W5L2  SB4W5L1  SB4W5L0   
SB4W6L4  SB4W6L1  SB4W6L0   
SB4W7L4  SB4W7L3  SB4W7L2  SB4W7L1  SB4W7L0   
SB4W8L3  SB4W8L2  SB4W8L0   
SB4W9L3  SB4W9L1   
SB4W10L3  SB4W10L2  SB4W10L0   
SB4W11L4  SB4W11L3  SB4W11L2  SB4W11L1  SB4W11L0   
SB5W1L3  SB5W1L2  SB5W1L1  SB5W1L0   
SB5W2L4  SB5W2L3  SB5W2L2  SB5W2L1  SB5W2L0   
SB5W3L3  SB5W3L1  SB5W3L0   
SB5W4L4  SB5W4L3  SB5W4L2  SB5W4L1  SB5W4L0  
SB5W7L4  SB5W7L3  SB5W7L1   
IB0W0L3  IB0W0L31  IB0W0L2  IB0W0L21  IB0W0L1  IB0W0L11  IB0W0L0  IB0W0L01   
IB0W1L4  IB0W1L41  IB0W1L3  IB0W1L31  IB0W1L0  IB0W1L01   
IB0W2L4  IB0W2L41  IB0W2L3  IB0W2L31  IB0W2L2  IB0W2L21  IB0W2L1  IB0W2L11  IB0W2L0  IB0W2L01   
IB0W3L4  IB0W3L41  IB0W3L3  IB0W3L31  IB0W3L2  IB0W3L21  IB0W3L1  IB0W3L11  IB0W3L0  IB0W3L01   
IB0W4L4  IB0W4L41  IB0W4L3  IB0W4L31  IB0W4L1  IB0W4L11  IB0W4L0  IB0W4L01   
IB0W5L4  IB0W5L41  IB0W5L2  IB0W5L21  IB0W5L1  IB0W5L11  IB0W5L0  IB0W5L01   
IB5W0L4  IB5W0L41  IB5W0L3  IB5W0L31  IB5W0L2  IB5W0L21  IB5W0L1  IB5W0L11  IB5W0L0  IB5W0L01   
IB5W1L4  IB5W1L41  IB5W1L3  IB5W1L31  IB5W1L2  IB5W1L21   
IB5W2L41  IB5W2L3  IB5W2L31  IB5W2L2  IB5W2L21  IB5W2L1  IB5W2L11  IB5W2L0  IB5W2L01   
IB5W3L4  IB5W3L41  IB5W3L3  IB5W3L1  IB5W3L11   
IB5W4L4  IB5W4L41  IB5W4L3  IB5W4L31  IB5W4L2  IB5W4L21  IB5W4L1  IB5W4L11  IB5W4L0  IB5W4L01   
IB5W5L4  IB5W5L41  IB5W5L2  IB5W5L21  IB5W5L1  IB5W5L11  IB5W5L0  IB5W5L01    
 
  
</pre>
<!-- Author: Petra -->


<!-- Date: Thu Aug 16 23:56:59 2001 -->
SB3W1L4 bias current vs time comments<a href= 
'/cgi/elog/det-system-elog.pl?nb=e310-SVX-C-BRL-E-End-P-1&action=view&page=1&frame=2&anchor=23:53:12'> 
here </a>   
<!-- Author: petra -->


<!-- Date: Fri Aug 17 09:31:03 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-159&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-160  width='300' align='top'></td><td>This is the plot of current vs. time (hours) </a></td></tr></table>
<!-- Author: Saverio -->


<!-- Date: Fri Aug 17 09:42:10 2001 -->
<P> 
around 0250 this morning, they started having troubles w/ our 
crates.  they rebooted the VRBs and we never recovered.  Steve 
think a glink transmitter was broken in the process.  look 
<a href= 
'/cgi/elog/elog.pl?nb=2001&action=view&page=584&frame=2&anchor=02:49:28'> 
here </a> for the saga as documented in the CDF log. 
 
<P> 
we can't take data w/ large fraction of east side until this is 
fixed.  steve will try to address the problem this morning. 
 
<P> 
We should make it clear to the shift crew that if silicon is 
biased, but won't be included in a run for > 1hour (e.g. b/c they're having troubles w/ other systems), they should page the main pager.  We may wish to turn to standby in that case (of course, we'll have to be paged to go back to full volts later).   
<!-- Author: doug -->
<!-- Comment: Fri Aug 17 15;02;54 comment by...doug -->
<pre>Steve power cylced the suspect crate and all was ok (well...
he could at least move-on to the next problem).</pre>
<!-- Date: Fri Aug 17 11:33:39 2001 -->
<pre>there will be an access of a few hours starting between 
1300-1400.  steve has been contacted.  waiting for response from 
caen pager.  the access list is above and we expect to take  
an hour or two.</pre>
<!-- Author: doug -->


<!-- Date: Fri Aug 17 14:59:59 2001 -->
<pre>Nahn and Napora headed downstairs around 1430 to take care of 
our access needs.  When they are finished, Ivanov would like 
to test the latest update to the GUI code.   
 
&gt;&gt;&gt; Steve/Rob: Please page me(218.8227) when you're  
&gt;&gt;&gt; done so that I can arrange things with Andrew!</pre>
<!-- Author: doug -->



<!-- Date: Fri Aug 17 16:06:40 2001 -->
<pre>Just had an EXTERNAL TRIP on SB4W9.  Do not know what 
causes an EXTERNAL TRIP on just one PS.  I repowered it, it 
seems ok.</pre>
<!-- Author: SCN -->
<!-- Comment: Fri Aug 17 16;19;35 comment by...SCN -->
<pre>It tripped again, so I removed it from powerset.dat and 
the hdwdb.  Loss of two ladders (3 were already masked).</pre>


<!-- Date: Fri Aug 17 17:09:13 2001 -->
<h3>X Mode news</h3> 
It has been a productive day (after the SRC debacle and 
the access).  Stage 2 X Mode crate code, which has enhanced  
robustness but is still data driven (and therefore not 
super-robust) is working, and doesn't crash and burn 
even when the event is pretty ugly.  There are 
still a few things I might want to do to speed it along 
a bit, getting rid of printf's on every error and 
generating a summary instead etc.<BR> 
Also, the Run Control bits seem to work, with the exception 
that the CALIB CSL still won't accept our mega-event.   
Experts were emailed...
<!-- Author: SCN -->



<!-- Date: Fri Aug 17 17:30:59 2001 -->
<pre>Plan: 
 
  - Ivanov coming at 1730 to test latest GUI change 
  - Miller coming at 1800 to try for D-mode calibrations 
    prior to shot set-up (to start at ~1900) 
  - I will try to squeeze in some tests of the recent access 
    fixes to verify them.  Namely, we need to: 
        - power SB3W4 and see that it draws bias current 
        - verify that IB5W3L3 I_bias_1 is set to coarse scale 
          and I_bias_0 to fine scale (need to modifiy CAENvolts 
          file to do so) 
  - integrate and wait for data</pre>
<!-- Author: doug -->
<!-- Comment: Fri Aug 17 20;12;01 comment by...doug -->
<pre>Status:

  - Ivanov tested GUI, found a bug, fixed it

  - we're still trying to get calibrations (L3 problems)

  - i learned that while the CAENs have separate jumpers for
    Vbias0 and 1 of an ISL channel, the GUI doesn't afford the
    same granularity, only allowing you to choose coarse/fine
    settings for both together.  So, IB5W3L3 still set to Vbias1
    to 2.0 volts in CAENvolts.dat

  - tried to bring back SB4W9; can't turn-on portcard;  GUI gets
    stuck in infinite loop trying to bring it back from
    "spontaneous turning off";

  - SB3W1L4 tripped on Bias-OC; draws 500 mA at 5 volts and 
    1700 mA at 10 volts... looks like a pinhole :(  i've
    set it to 2.0 volts in CAENvolts.dat

  - now troubles w/ VRB crates; Nahn paged and told aces what to
    do;  no rebooting involved (yet)

All in all a pretty terrible 3 hours (and we're not finished...)</pre>
<!-- Comment: Fri Aug 17 20;12;53 comment by...doug -->
<pre>forgot to mention that andrew and i also tested the gui fix.</pre>
<!-- Date: Fri Aug 17 18:35:32 2001 -->
<pre>"POWER OFF" button has been debugged and fixed. 
The response of the GUI to dropped Interlock has been tested. </pre>
<!-- Author: Andrew -->




<!-- Date: Fri Aug 17 20:36:25 2001 -->
<pre>while trying to bring back SB4W9, we had a "DTerm UnderVoltage" 
trip on SB3W7.  It read 0.00 volts while other wedges (i didn't 
check them all) read ~3.0 volts.  Presently it reads 1.2 volts. 
It's also drawing current (85 uA) while the others draw nothing. 
Looks like a short?</pre>
<!-- Author: doug -->


<!-- Date: Fri Aug 17 20:42:33 2001 -->
<pre>Lester fobbed-off the calibration work on an unsuspecting 
Rob Napora.  90 minutes later, Rob has succeeded in taking 
calibration runs... 
 
  - 124086 (2k evts) DPS  ON (standard set - SB4W9) 
 
  - 124091 (2k evts) DPS OFF (standard set - SB4W9, no L3 mngr) 
 
Rob is trying to confirm w/ Boris that they actually made it 
to disk.</pre>
<!-- Author: doug for rob -->
<!-- Comment: Fri Aug 17 20;54;39 comment by...doug -->
<pre>ok.  boris/rob confirm that these above two runs made
it to the LOOK area.</pre>
<!-- Date: Fri Aug 17 20:45:18 2001 -->
<pre>The following ladders had software DVDD OC trips while we were 
waiting to be brought into a cosmic run.  Nothing was happening 
to our crates, we were part of no partition: 
 
  - SB1W10-L2, SB2W11-L0, SB4W11-L2 
 
I will reset them.</pre>
<!-- Author: Doug -->



<!-- Date: Fri Aug 17 21:21:26 2001 -->
<pre>the much awaited cosmic run has damn near started... SVT failing 
coldstart.  but we made it.  now if we could only get the run 
active and take some triggers...</pre>
<!-- Author: doug -->


<!-- Date: Fri Aug 17 22:21:52 2001 -->
<pre>so, we've been in cosmic run for a bit (trig rate, of course, 
very low).  i'm outta here.  shot set-up just starting.</pre>
<!-- Author: doug -->


<!-- Date: Sat Aug 18 00:53:39 2001 -->
<pre>script for getting a guess of the max currents is ready: 
/cdf/code-common/cdfonline/caencontrol/devel/get_currents.pl 
It produces a file called CAENcurrents.dat that has the same 
format as the file volts.dat and should be read by the GUI  
to set the maximum current for individual ladders. 
Safety margins can be chosen by the "user".</pre>
<!-- Author: Saverio -->