<!-- Title: 17:30:20  Mon Feb 18 2002 -->
<!-- Crewchief: Silicon People -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>- monitoring activity 
- plans for access</pre>


<!-- Date: Mon Feb 18 17:41:37 2002 -->
<pre>FOLLOW-UP from w-e pager call #1 
 
SB4W1L1,2 - Trip for overcurrent on DVdd at 17:22 02/17 
 
It is possible that it is fib-related. 
CAP-ID mismatch error rate fluctuates from 0 to 90% within the  
run range that we could analyze with DEM 
The problem occurred during run 139300. 
The first time we had CAP-ID errors in this ladder was in run 138233 (layer-3) 
and for Layer-2 was run 135919 at 90% level. 
 
Currents on DVdd go up on all 5 layer at the same time. 
CAP-ID out of sync are reported also in HDI from the same wedge, that did not trip 
and this error rate is the same as for the incriminated ladders. 
CAP-ID are different for different chips, but they keep the 
pace, incrementing the same amount for the same chip from an event to the "next". 
In runs that have low error rate the last chip is the only one to have  
CAP-ID errors. 
 
We have no errorlogfile from run control for the run 139300. 
We know that the run was paused, but it is unclear if it was cause or effect of the trip. 
 
This is a possible job for DAQ WG: check the FIB ? 
Also the other wedge (W0) on the same FIB shows current bump  
at the same time. 
</pre>
<!-- Author: Saverio, Cigdem -->
<!-- Comment: Mon Feb 18 17;52;24 comment by...SCN -->
We have swapped this Fib out <a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=86&frame=2&anchor=10:58:34'>
before</a> (in fact several times).  I suggest we check
the FTM and clock signals.



<!-- Date: Mon Feb 18 19:14:00 2002 -->
<pre>We had a full CAEN CRATE that went OFF. it involved the  
following wedges: SB0W7-8-9 SB1W7-8-9 SB2W7-8-9. 
The CAEN GUI FROZE and while restarting I got a  
problem with b0dap42. Talking with the expert I had to reboot  
the LINUX BOX.  
GUI restarted and devices brought back to STDBY so NO  
PERMANENT EFFECT on the CAEN system. Episode will be  
investigated OFFLINE. 
 
I ramped UP the voltages and I gave the silicon to CDF. 
</pre>
<!-- Author: Gino -->
<!-- Comment: Mon Feb 18 19;14;27 comment by...Gino -->
<pre>I forgot, I'm going to file an ACCIDENT REPORT.</pre>

<!-- Date: Mon Feb 18 21:32:14 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 80 finished successfully.

Job info
--------
Calibration type : standard
DPS-off run      : 139341
DPS-on run       : 139340
Requested by     : Keyoung
Submitted        : 2002-02-18 07:59:34
Completed        : 2002-02-18 19:31:59
Status           : SUCCESS
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Mon Feb 18 23:24:57 2002 -->
<pre>IMON LOG Files: 
=============== 
 
The latest imon log file in the directory  
 
~svxii/imon/logfiles is from the 13th of Feb 2002.  
Where can I find the most up to date ones? 
 
</pre>
<!-- Author: Cigdem  -->
<!-- Comment: Tue Feb 19 13;57;02 comment by...Saverio -->
<a href="/svx-data1/datalog/ps/imon/logfiles/">
/svx-data1/datalog/ps/imon/logfiles/</a>
<!-- Date: Mon Feb 18 23:33:44 2002 -->
<pre>Diagnostic Report IB5W4L4 
========================= 
 
AT 19:27 Feb-17-2002 DVDD over current  
 
Couldn't find entry in David's Error Monitor (DEM).  
Is this because this layer was masked? 
 
According to "merlin.MLDbDisplay" at 19:26 a RUN was stopped.  
 
No Conclusion yet.  
 
 
</pre>
<!-- Author: cigdem -->
<!-- Comment: Tue Feb 19 14;40;10 comment by...Lester -->
<pre>This madder is out, this was apparently a spontaneous on
which tripped before the GUI was able to correct it.
</pre>
<!-- Comment: Tue Feb 19 15;24;44 comment by...Andy H -->
There is no spontaneous transition listed for this ladder in
Saverio's logfiles.  Auke-Pieter plots show that this ladder
was never on.  I suspect this trip was a spurious one
along the lines of the mysterious "external trips."  Will run
that hypothesis by Andrew I.
<!-- Date: Mon Feb 18 23:38:21 2002 -->
<pre>Diagnostic REport SB3W3L0-L4 
============================= 
 
Feb-17-2002, 19:39, ext trip 
 
L0-L3 no problems in DEM (&lt;sim 0.1% and very rarely showing up) 
 
L4: 100% error level in DEM, First problematic RUN=137075=0x20003. 
 
Cap ID of Chip 8a is wrong, it is stuck to a constant value in a RUN for each event. Datastream is messed up from Chip 8a onwards.  
 
</pre>
<!-- Author: cigdem  -->
<!-- Comment: Tue Feb 19 14;41;17 comment by...Lester -->
<pre>The Capid problem is diagnosed AVDD2 (although my summary has
the wrong chip for historical reasons!) The trip itself was
a mystery external trip associated with a global CAEN transition.
</pre>
<!-- Date: Tue Feb 19 06:29:03 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 81
Calibration type  : standard
Run period tag    : Feb_2002
DPS-off run       : 139379
DPS-on run        : 139378
Requested by      : giolo kim
Main process id   : 68346285
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->



<!-- Date: Tue Feb 19 09:43:46 2002 -->
<pre>SB3W3L4 Chip 8a is a AVDD2 chip that has been bad since plugin.  </pre>
<!-- Author: affolder -->



<!-- Date: Tue Feb 19 14:22:28 2002 -->
<p>I moved all the IMON logfiles to the area designated for them. 
The data are available from web, here is a 
<a href="/svx-data1/datalog/ps/imon/logfiles/imon_list.html"> link to the list</a> of available files. 
<br> some missing files willbe neade available soon. (they are there, just not visible in the list for a question of file name)<br> 
Also, the list is updated daily, automatically.<br>  
<!-- Author: Saverio -->





<!-- Date: Tue Feb 19 15:51:21 2002 -->
<pre>Silicon diagnosis work: 
 
SB4W5L3: was kicked out over the weekend for no init. 
	In svxdaq readsback ff's, reads out all but last chip. 
	Currents seem OK. 
	Reintegrated so we can monitor better 
 
SB2W10: Wedge software tripped repeatedly this morning. 
	Tried powering, still got bad DVDD's on L1,2 
	After bringing up svxdaq, powering currents looked ok 
	All layers initialized OK.  
	Sequnce checksums OK. 
	Could svxdaq have changed something? Init boards was off. 
</pre>
<!-- Author: Lester -->
<!-- Comment: Tue Feb 19 16;07;31 comment by...Lester -->
<pre>Oops left the fib in command fifo overflow. Now its ok.</pre>

<!-- Comment: Wed Feb 20 14;08;38 comment by...Saverio -->
<pre>Did you mask the init readback check ?
</pre>
<!-- Date: Tue Feb 19 18:29:38 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 81 finished successfully.

Job info
--------
Calibration type : standard
DPS-off run      : 139379
DPS-on run       : 139378
Requested by     : giolo kim
Submitted        : 2002-02-19 04:28:20
Completed        : 2002-02-19 16:29:37
Status           : SUCCESS
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Tue Feb 19 19:03:49 2002 -->
<h1>One-button iFix bias control now active in the control room</h1> 
<p> 
Here's what I sent the aces:</p> 
<pre> 
Hello aces, 
 
You will notice that the SVX / ISL / L00 buttons on 
the iFix HV summary page have been replaced by one 
big, fat set of buttons.  With these you can turn all of 
the silicon ON or to STANDBY in one go.  (You can also 
turn it all off, but if you do we will be really mad). 
 
The transition will take place in the following stages: 
L00, SVX west barrel, SVX central barrel, SVX east barrel, ISL. 
During the stages, you will see the HV bars blinking, indicating 
that the power supplies are busy turning on/stby. 
In between each stage, there will be a pause (about 30 seconds) 
to allow our monitoring software (like the GUI) to update. 
The bars will stop blinking during this time. 
 
After the ISL has finished, wait another minute to make 
sure a final update has occurred.  Then, you can consider things 
done.  The whole process will take about 6-7 minutes. 
 
As you probably already know, trips are fairly common during 
these transitions.  Work is underway to correct this problem. 
Our policy on trips remains the same: page the expert (218.8227). 
 
REMEMBER: TURNING THE SILICON ON IS STILL AN EXPERT-PERMISSION-ONLY 
OPERATION.  JUST BECAUSE YOU CAN DO IT FROM IFIX NOW DOESN'T 
MEAN YOU DON'T HAVE TO PAGE THE EXPERT! 
 
Send questions to cdf-silicon-op@fnal.gov and/or me (hocker@fnal.gov). 
 
Maximum love, 
Andy 
</pre>
<!-- Author: Andy H. -->


<!-- Date: Tue Feb 19 19:36:15 2002 -->
<pre>Diagnostic Report for SB4W1 
=========================== 
 
Got an incident report from the last night.  
L3 and L2 tripped because of DVDD overcurrents. 
 
Mon Feb 18 22:40:48 CST 2002 Software protection trip: High DVDD Current SVX B4 W1 L3  
Mon Feb 18 23:56:20 CST 2002 Software protection trip: High DVDD Current SVX B4 W1 L2  
Mon Feb 18 23:56:21 CST 2002 Software protection trip: High DVDD Current SVX B4 W1 L3  
 
Overall the DVDD currents are not stable. They are jumping up 
and down and now and then they jump above the trip threshold, which we than recognize.  
 
The trips aren't caused by pausing the runs. I have one example,  
where the trip happened before the Run was paused.  
See, Shift logbook entry of 18-Feb-2002 at 23:57:41. 
 
I also checked with the Monitor-Shifty the proton and antiproton 
losses. We weren't able to see any correlation between the trips  
and the beam losses.  
 
This report was pass to the Detector and DAQ Experts.  
</pre>
<!-- Author: Cigdem  -->


<!-- Date: Tue Feb 19 19:39:31 2002 -->
<pre>Diagnostic Report for SB2W10 
============================ 
 
Got an incident report from the pager carrier (Chris).  
Layer 2,1 and 3 tripped in total 4 times, where we were not  
taking any data.  
 
We checked, if we can correlated the trips with beam losses.  
And again that is not the case. 
2 out of 4 trips are not correlated to beam losses.  
 
Report passed to the DEtector and DAQ expert. </pre>
<!-- Author: Cigdem  -->


<!-- Date: Tue Feb 19 20:28:53 2002 -->
<pre>Test on CAEN spontaneous transitions. 
The purpose is to verify whether spontaneous transitions are 
contained within CAEN crate. 
For the test I specially created powerset.dat which had power 
supplies SB0W4-6,SB1W4-W6,SB2W4-6 ( all of them are located i 
CAEN crate #5). Turning On&lt;-&gt;Stby each time I log spontaneous 
transitions. On-&gt;Stby transition is done from the GUI. Stby-&gt;On 
is from iFix. In each transition there is a small delay between 
turning on SVX Barrels, therefore I may track down whether the 
spontaneous transition occured during turning on (B0,B1) or B2.  
 
Here is what I get: 
 
Action       Spon. Trans.   
On-&gt;Stby     SB2W4L3       during B0,B1 
             SB2W5PC       during B2     
Stby-&gt;On     NONE 
On-&gt;Stby     NONE 
Stby-&gt;On     SB2W4L3       during B0,B1 
             SB2W6L0       during B2 
On-&gt;Stby     NONE   
Stby-&gt;On     NONE 
On-&gt;Stby     SB1W6L3 AVDD  Ext.Trip      during B0,B1 
 
Stby-&gt;On     NONE 
On-&gt;Stby     NONE   
Stby-&gt;On     NONE 
On-&gt;Stby     SB0W4L3       during B0,B1 
Stby-&gt;On     NONE 
On-&gt;Stby     SB2W5PC       during B0,B1 
Stby-&gt;On     NONE 
On-&gt;Stby     NONE   
Stby-&gt;On     NONE 
On-&gt;Stby     SB1W5L3       during B2 
Stby-&gt;On     SB0W6L1       during B1 
 
  At this point I got tired switching power back and forth.  
This may be done automatically, if someone believes that the  
above results are still inconclusve 
All power supplies which experienced spontaneous transition are 
located in the same crate. External Trips happen not so often but 
may also be contained within a CAEN crate. 
During the test there were spontaneous OFF transitions on port 
cards but CAEN did not complain and did not trip the power 
supply. Earlier I saw External Trip on port Card and the server 
code on the next 7 seconds update gracefully turned off all 
layers. It is extremely unlikely that it succeded doing that 
faster that CAEN hardware would take an action. Apparently CAEN 
hardware does not trip a power supply in case, if there is an 
external trip on port card. </pre>
<!-- Author: Andrew -->


<!-- Date: Wed Feb 20 08:44:41 2002 -->
<pre>iFIX lost contact with Silicon. 
Messages are sent, Ifix does not listen. "dump.now" is updated. 
The ace is dealing with it now.</pre>
<!-- Author: Saverio -->
<!-- Comment: Wed Feb 20 10;01;54 comment by...Andy H. -->
This morning's network troubles got PSMon into a state of
confusion.  I restarted it and alles ist gut.



<!-- Date: Wed Feb 20 13:13:21 2002 -->
<h1>Handshake permission change</h1> 
I just changes the fib code only to respond to a handshake request if the crate is not in a partition or if it 
is in a partition and in the IDLE state.  Any other attempt 
to power it on (including recovering from spontaneous trips) 
will result in a handshake error (I believe...)
<!-- Author: SCN -->



<!-- Date: Wed Feb 20 15:05:49 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Wed_Feb_20_2002_150541.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-289  align='top'></td><td><h3>Calib SVX Mode Works</h3> <a href= '/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=94&frame=2&anchor=13:35:50'> previous study</a> found problem in logging data.  These settings:  CALIB PIPE 26, CAL ENABLE 0, CAL INT 0 , INT  0 0, INT 1 1, INT 2 3, INT 3 5  </a></td></tr></table>
<!-- Author: SCN -->
<!-- Comment: Thu Feb 21 09;08;54 comment by...SCN -->
Perhaps some more explanation is necessary.  What the
plot means is that in "CalibSvx" mode you can
space 4 L1A exactly where you want.  In the above case,
I arranged them to start on CDF Clock 0, with a 1 clock,
then 3 clock, then 5 clock gap between successive L1A.
This implies you can do a L1A timing scan on the entire detector
instead of just one read all wedge.
<!-- Date: Wed Feb 20 18:51:59 2002 -->
<pre>Diagnostic Shift Report of SB4W5L2 
================================== 
 
Type of Diagnostic Work: Routine 
Ladder: SB4W5L2 
 
Diagnostic: 
----------- 
 
The level of errors in David's Error Monitor for this ladder jumped since RUN = 139295 = 0x2201f (17-Feb-2002) up to 80%.  
And it is now fluctuating between 40-100% 
Before this RUN it was a quite ladder, which had rarely  
problems on the 0.3% level, which were "7f" on Chip 87 problems.  
 
The RUNS since 17-Feb do have problems with the Cap-ID's. They are wrong from Chip 88 onwards.  
They are shifted with respect to the Cap ID of Chip 89.  
And I see also sometimes events with the "00 f3"-problem.  
 
Scan of the Silicon Elog for this ladder: 
----------------------------------------- 
 
Fri Aug 10 17:57:19: caused reformator errors. 
Sat Aug 11 16:59:37: SVX WBH1 trip and Quadlog drops crate pwr  
                     drop SB4W5L2, SB3W1L4, SB5W1L3 (rf errors...                      multi-c4)  
Mon Aug 13 23:48:35: SB4W5L2 is ok now  
Mon Dec 24 23:27:10: SVXMON  Problems since RUN 128066  
                             Bunch X Out of Sync 50%  
                             Strip Out of Order 0.5%  
                     DEM:    "7f" problem in chip 87  
Thu Dec 27 04:16:59: imon pink     volt  latest  nominal  time  
                     SB4W5L2 DVDD  5.51  125     95   04:15:44   
Mon Dec 31 07:29:07: 
Had some persistent pink AVDD's in run 135969 which went away  
and stayed green after the cold start for a new run (135971)  
These were first marked at 5:04 and returned immediately when  
I tried to unmark them but are OK after the cold start.  
SB4W5L0 151(344)   
SB4W5L1 211(491)  
SB4W5L2 435(825)  
SB4W5L3 365(745)   
 
CDF-Shift Elog Scan for RUN=139295(DEM errors jumped up): 
--------------------------------------------------------- 
 
Run was taken at the 17-Feb-2002, started at  7:51:46 
                                  ended   at 11:05:22 
                                  Physics,Beam data 
 
Entries During this RUN, which I found to be noticed: 
 
"L3A NO IDEA Hz !- Trigger Rate Monitor shows 0; known problem 
L3 expert was called.  
The deadtime increased to about 4%, did a HRR and went down to 1%. This happened twice in the 
last hour. The largest downtime is caused by L2.  
Also I had a Busy condition EVB/VRB, cured by HRR.  
had software protection trip (DVDD overCurrent)  
in SVX B4 W1 L2,3" 
 
Check of the Currents for SB4W5 with Auke's PS-tool: 
---------------------------------------------------- 
17-Feb-2002 
AVDD currents are unstable for all layers. 
DVDD currents are unstable and spiky. 
Bias currents do have steps, non stable.  
 
01-Feb-2002 
AVDD currents are much more stable. 
DVDD currents stable 
Bias currents stable 
 
Will scan tomorrow SVXMON ERROR-LOG FILES. 
 
 
 
 
 
</pre>
<!-- Author: Cigdem  -->
<!-- Comment: Fri Feb 22 12;27;34 comment by...Cigdem -->
<pre>Addition to Diagnostic Report of SB4W5L2
========================================

Scan of SVXMON Errsum-files:
----------------------------

First error in SVXMON errsumfiles (Bunch X out of Sync) seen in RUN=128066.

Bunch X Out of Sync Errors on the level of ~50% for 71 RUNs out of 905 Runs:
  "Bunch X Out of Sync | 17 | This error was present in  17          events out\
 of  33"

Strip Out of Order Errors on the level of 1-10% for 87 Runs out of 905 RUNs (fi\
rst in RUN=135355):
  "Strip Out of Order | 1 | This error was present in  1 events      out of  55\
2"

Strips -- Bad ADC Value Error on a level of &lt;1% for 16 RUNs out of 905 Runs (fi\
rst in RUN=135804).

Chip Side Error,EOR Not Found,Out of Order Chip on a level of 100% and 50%
in the RUNS=135919(2001.12.29) and 138778(2002.02.08).
In parrallel with these errors this layer has "Pipeline Out of Sync" errors.

Pipeline Sync ERRORS seen in following RUNS:

    RUN            date          DEM error level    DEM ERROR
135919 212ef    2001.12.29           90 %           d0c2c2c4 termination
135969 21321    2001.12.31       not processed
136287 2145f    2002.01.05           74 %           Capid wrong from 88
                                                    onwards
                                                    "00 f3" problem
138778 21e1a    2002.02.08       not processed
138809 21e39    2002.02.09       not processed
139253 21ff5    2002.02.16       not processed
139278 2200e    2002.02.16           0.0 %
139295 2201f    2002.02.17           82 %           Cap ID wrong from 88
                                                    onwards
                                                   "00 f3"

since RUN 139295 more or less all RUNS have "Pipeline Out of Sync" Errors
in SVXMON!

This means, that this layer had in the past at least 2 times an error level
of 90% in DEM, but these were spikes. Most of the time it was quite.

Scan of the CDF-Shift-Elog for these RUNS&lt;139295:
-------------------------------------------------

    RUN            date          Entries
135919 212ef    2001.12.29       Deadtime was bad and L3 turning green.
                                 High busy dead time due to high accept rate at\
                                 L3

                                 Some high rate L3 triggers...
                                 TOF tripped, SL2. CPR tripped, NW 0-5.
                                 Reset them.
                                 CPR tripped again. NW-Slices-West, 0-5.
                                 Reset it
                                 CPR tripped again. NW-Slices-West, 0-5.
                                 Reset it.
                                 CPR tripped again at same slices.
                                 COT SL2 tripped again.


135969 21321    2001.12.31       Silicon added back to this run.
                                 Seeing an increase in the number of large
                                 loss spikes. CMP and CMX starting to trip.
                                 Called MCR. They will try to move a
                                 collimator more parallel to the beam and
                                 see if it helps.
                                 CMX NW 2,3 and CMP Top ceiling A2 trip
                                 due to high proton losses. Brought them up.

136287 2145f    2002.01.05       We got the following error:
                                 Busy Conditionin VRB/EVB forwarded
                                 by the crate: VRB_SVX_02.

                                 Additional Information:

                                 Busy Timeout!
                                 Event Builder SCPU_VRB_READ_FAILED Error !!!
                                 This BTO was caused by a bus error in
                                 the HEVB crate.
                                 HRR worked in this case.
                                 - Abraham Gallas :: (run 136287)
                                 -- Sat Jan 5 06:57:27 comment by...
                                 Abraham Gallas --  We are having a
                                 reformatter rejected rate of 6%.


138778 21e1a    2002.02.08       Shift Summary:
                                 1. No beam during shift due to MI
                                 magnet problem
                                  - fixed this and TEL during this shift
                                 2. Controlled access until 20:30
                                  - silicon folks tried to find
                                  intermitent open
                                  in fib command cable -- no luck
                                 3. During shift tested
                                 (as well as we could) new trigger table
                                 Physics_0_04_[5,258]
                                 This removes CLC from photon triggers,
                                 has L3 cutting on hadronic
                                 B triggers with prescales removed.
                                 Should use this trigger at start of next store\

                                 4. Some L3 work by Illya: memory leak checks,
                                 and some modification of L3 trigger names
                                 5. Work on silicon gui during shift
                                 Left shift with promise of shot setup at 3:00
                                 Note that CMP current limit is now set
                                 at 15 microA, so should
                                 try to include CMP in next run
                                 End of Shift Numbers
                                  CDF Run II
                                   Runs                   138752 - 138778
                                    Delivered Luminosity   0
                                     Acquired Luminosity    0

138809 21e39    2002.02.09       Ooops!! The
                                 data-taking-stops-but-no-timeout-
                                 from-run-control problem is back. DAQ stops 2
                                 times in 5 minutes. Also the second time we
                                 got a busy condition in VRB/EVB crates:
                                 VRB_SVX_02
                                 HHR worked.
                                 TS states:
                                 L1     L2     RO
                                 08     14     02
                                 The av deadtime went down: 1.4%



                                 CO noted large hot regions looking
                                 at the West PES and PPR plots.
                                 Data from the last data taking
                                 (early morning 2/8/02) show normal behavior.
                                 Experts notified.

                                 Stopped the run because b0svt01 no responding
                                 after a HRR. After a reset_crate it was fine,
                                 but during the Cold Start had an
                                 initialization problem:
                                 HDI Slot 11 chan 3: SVX B4 W4.
                                 &lt;font color=Blue&gt; The cure is to abort and do
                                 a Cold Start again. It worked 4 times today.
                                 I don't understand why failed the
                                 initialization the first time! &lt;/font&gt;

                                  - Mircea C
                                  -- Sat Feb 9 13:56:01 comment by...Frank Chle\
bana --
                                  Both of these problems SVT crate crashing
                                  and SVX initialization
                                  error are known problems...


139253 21ff5    2002.02.16        see included ps-File.
</pre>
<!-- Comment: Fri Feb 22 12;30;44 comment by...Cigdem  -->
<pre>The CDF-Shift-elog ps-file for run 139253 you find further 
below....because I can't add in my comment postscript files. 
This should be changed!
</pre>
<!-- Date: Wed Feb 20 18:54:14 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Wed_Feb_20_2002_185312.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-291  align='top'></td><td>Currents of SB4W5 for the 17-Feb-2002</a></td></tr></table>
<!-- Author: Cigdem  -->


<!-- Date: Wed Feb 20 18:57:14 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Wed_Feb_20_2002_185657.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-294  align='top'></td><td>Currents of SB4W5 at 01-Feb-2002</a></td></tr></table>
<!-- Author: Cigdem -->


<!-- Date: Thu Feb 21 08:27:26 2002 -->
Jim Ellermeier caused a flow trip this morning around 7:45 while 
he was exercising the spare chiller.  This is a routine operation 
that normally causes no disruptions, and we think we understand 
what happened this time -- ask us if you want to know.
<!-- Author: Andy H. -->


<!-- Date: Thu Feb 21 08:28:59 2002 -->
<p>Warm-up started (16 deg C).</p> 
<p> 
Silicon power OFF (thanks to flow trip)<br> 
All bulkheads INACTIVE in iFix<br> 
5V switches off<br> 
All temperature trip limits 25 deg C<br> 
</p>
<!-- Author: Andy H. -->



<!-- Date: Thu Feb 21 12:11:06 2002 -->
<pre>B0cluster rebooted to add disk. Back at 
Thu, 21 Feb 2002 11:08:06 -0600  
Spy restarted automatically at Thu, 21 Feb 2002 11:21:01 
Temp spy and init spy restarted (manually !) at about noon.</pre>
<!-- Author: Saverio -->


<!-- Date: Thu Feb 21 17:36:10 2002 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-295&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-295' width='300'></a></center>
<!-- Author: Gino -->


<!-- Date: Thu Feb 21 17:37:43 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-295&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-295  width='300' align='top'></td><td>A Scope picture of the comand 3 line as measured on the PIT with the OSCILLOSCOPE (Differential probes) for TOP a wedge that works SECOND FROM TOP SB3W4 with the old FTM THIRD FROM TOP SB3W4 with the old FTM just by wigling the                 connector FOURTH FROM TOP SB3W4 with the new FTM  </a></td></tr></table>
<!-- Author: Gino -->
<!-- Comment: Thu Feb 21 17;54;01 comment by...Lester, Steve and Gino -->
<pre>Well I still have some lessons to take before I get to be an e-log expert.

FOR SB3W4 there was a identified problem with the C_3 comand line
(the above picture I hope is selfexplaining) and so we reproduced 
the simptoms and swapped FTM.

		OUT		IN
PREP ID		564021		566672
Serial #	102		152
RX-ch-0		878		376
RX-ch-1		1012		346
RX-ch-2		527		891
RX-ch-3		526		449
RX-ch-4		583		218
RX-ch-5		482		270
RX-ch-6		634		415
RX-ch-7		555		481
RX-ch-8		427		859
RX-ch-9		636		287

FOR SB1W4 a similar problem was identified on the L1A line.
Today we could not see any L1A at all out of this FTM channel.
So the FTM was swapped.


		OUT		IN
PREP ID		565890		565876
Serial #	135		132
RX-ch-0		134		176
RX-ch-1		146		752
RX-ch-2		131		799
RX-ch-3		178		800
RX-ch-4		145		770
RX-ch-5		1096		261
RX-ch-6		993		197
RX-ch-7		1108		216
RX-ch-8		1078		242
RX-ch-9		1106		1088

These 2 wedges will be tested as soon as we can cool down the
 system (it is now pending on COT work).

</pre>

<!-- Comment: Thu Feb 21 17;59;55 comment by...the same -->
<pre>Other ladder command cable signals probed at the FTM:
None had any real problems noticed
------------------------------------
SB5W2
SB3W2
SB4W1
SB0W6
SB2W5
SB4W5
SB4W8
SB3W2
SB4W1 -- BE clock phase jitter ~3ns (usually smaller)
SB5W2
</pre>


<!-- Comment: Tue Mar  5 08;50;40 comment by...SCN -->
FTM SN 135, PREP 565890, Bad L1A guy, fixed in PREP, tested
by Petra at FCC, and now in 2nd floor test crate.
<!-- Date: Thu Feb 21 19:01:19 2002 -->
Made changes to the Silicon Interlock Code: Changed default supply valve settings for ISL CCE3 and CCW2 back 
to 75%. (From 90%. 
<a href='/cgi-bin/ 
det-system-elog_res.pl?nb=silicon&action=xe&page=97&time=17:54:58'> See this link  </a>) Also changed it so that RTD PCW1A_2 (RTD which touches the Port Card) is included in determining the Max/Min Temp on 
the SVX Max/Min display in iFIX. 
  
<!-- Author: Eva H., Andy H. -->


<!-- Date: Fri Feb 22 00:17:27 2002 -->
Starting cooldown to 6 deg C.
<!-- Author: Andy the Owl -->


<!-- Date: Fri Feb 22 03:04:33 2002 -->
<p> 
Cooldown is complete (6 deg C).</p> 
<p> 
Temperature trip limits set to:</p 
<p> 
SVX BH: 15 deg C<br> 
SVX DOIM: 20 deg C<br> 
SVX PCW1A_2: 28 deg C<br> 
SVX DDR: 20 deg C<br> 
</p> 
<p> 
ISL CC: 17 deg C<br> 
ISL CPC: 15 deg C<br> 
ISL blocked CC: 30 deg C<br> 
</p> 
<p> 
L00 Sil: 15 deg C<br> 
L00 Hyb: 15 deg C<br> 
</p> 
<p> 
All alarms unsilenced.  Everything is GO for powering on again. 
</p>
<!-- Author: Andy H. -->


<!-- Date: Fri Feb 22 07:42:02 2002 -->
<center><a href='/elog/notebooks/silicon/Fri_Feb_22_2002_074102.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-297' ></a></center>
<!-- Author: Gino -->
<!-- Comment: Fri Feb 22 07;43;06 comment by...Gino & Lester -->
<pre>BECLK for SB4W1 measured out of the FTM by Lester and Gino as reported last night.</pre>


<!-- Date: Fri Feb 22 08:31:46 2002 -->
I would like to swap out two FIBs<ul> 
<li> b0fib07 Slot 17 LB1W4/5 has a bad Glink 2 status bit. 
<li> b0fib04 Slot 17 SB5W0/1 L4 is 100% 00f3 00f3.  I wold 
like to swap this board to verify that this is a firmware problem (if the problem does not follow the board) and have a Fib which 
is known to exhibit this problem from intensive debugging at FCC. 
</ul> 
It would be great if we can have a benchmark run this morning 
before the swap (STANDBY is ok) to be able to compare against 
post-swap conditions.  If someone can perform this, great, otherwise I will be there in about 1/2 hour
<!-- Author: SCN -->




<!-- Date: Fri Feb 22 12:36:11 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Fri_Feb_22_2002_123604.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-304  align='top'></td><td>Diagnostic of SB4W5L2 ======================      This is the output of the CDF-Shift Elog for the RUN 139253 21ff5    2002.02.16. Have a look at it, because  after this date SB4W5L2 has continously  "Pipe Line Out of Sync." Errors (Cap ID's wrong). (has more than one page) </a></td></tr></table>
<!-- Author: Cigdem  -->


<!-- Date: Fri Feb 22 13:37:02 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-305&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-305  width='300' align='top'></td><td>Another BAD FIB that goes to PREP for repairs</a></td></tr></table>
<!-- Author: Gino -->
<!-- Comment: Fri Feb 22 14;48;27 comment by...SCN -->
This is Fib 112 PREP 560608, currently a "spare".  It in the past spent some
amount of time serving LB0W4/5, not sure exactly when (perhaps
was not even used).<p>
Other troubled Boards <ul>
<li> FIB 165 PREP 562365: Bad (Flaky) Glink Ch 2, swapped with Channel
3 and problem followed Glink.  Action-send to PREP with instructions to replace Glink Rx Chan 3 with new daughterboard.  Also checked Clocks, they look fine.  Replaced with Fib 134 PREP 560619.
<li><a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=98&frame=2&anchor=17:37:43'>
FTM Bad Timing signals</a>.  Action: Send 565890/135 (Bad L1A) to Auke to
see if he can learn anything about the bit 2 problem on Chan 9,
then to PREP.  Other board 564021/104 (Bad CMD_3) to PREP.
</ul>
<!-- Comment: Fri Feb 22 18;45;39 comment by...Lester -->
<pre>The optical problem persisted after the swap (SB1W5L4 bit 2) 
so this may not have been an RX problem.</pre>
<!-- Date: Fri Feb 22 14:36:41 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-306&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-306  width='300' align='top'></td><td>Here is the report from the access</a></td></tr></table>
<!-- Author: gino -->
<!-- Comment: Fri Feb 22 15;32;02 comment by...SCN -->
Comment on Flaky BE Clocks-I don't know of a reason why
this would cause observed peculiarities in particular
wedge (SB4W1).  Is there a theory tying BE Clocks 
with observed behaviour together?


<!-- Date: Fri Feb 22 17:01:59 2002 -->
<pre>Changed limits in HWDB for max voltage on L00 bias to be 137V. 
Made and linked and loaded new CAENvolts.dat 
 
This is to avoid triggering the crowbar which is set to 142V. </pre>
<!-- Author: Chris Hill -->



<!-- Date: Sat Feb 23 13:31:46 2002 -->
<pre>During global ON for the current store: 
 
SB5W5L2, SB5W8L2, IB5W3L3 trip on OC on bias. 
Current limits are likely incorrect due to access activities. 
 
For now, these ladders are in STNDBY. 
 
</pre>
<!-- Author: CH -->

<!-- Date: Sat Feb 23 18:26:20 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 82
Calibration type  : standard
Run period tag    : Feb_2002
DPS-off run       : 139756
DPS-on run        : 139754
Requested by      : giolo
Main process id   : 6321858
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->



<!-- Date: Sat Feb 23 20:27:18 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sat_Feb_23_2002_202655.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-320  align='top'></td><td>Addition to Diagnostic Report of SB4W5L2:  These are the days <= 16.Feb.2002, where this ladder had  "Pipeline out of Sync" Errors.  </a></td></tr></table>
<!-- Author: cigdem  -->
<!-- Comment: Sat Feb 23 20;37;43 comment by...cigdem  -->
<pre>IN the RUN = 139253 and 139278 this ladder has 
Pipeline out of Sync Errors in SVXMON. 

139253   started at 03:08:27 ended at 08:33:06

139278   started at 23:24:46 ended at 04:00:20

</pre>
<!-- Date: Sat Feb 23 20:28:43 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sat_Feb_23_2002_202825.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-323  align='top'></td><td>Addition to Diagnostic Report of SB4W5L2</a></td></tr></table>
<!-- Author: cigdem  -->
<!-- Comment: Sat Feb 23 20;39;48 comment by...cigdem  -->
<pre>Pipeline out of Sync Errors in SVXMON for RUN=138809
started at 11:30:37 ended at 12:44:11.</pre>
<!-- Date: Sat Feb 23 20:29:38 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sat_Feb_23_2002_202916.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-326  align='top'></td><td>Addition to Diagnostic Report SB4W5L2</a></td></tr></table>
<!-- Author: cigdem  -->
<!-- Comment: Sat Feb 23 20;41;31 comment by...cigdem  -->
<pre>Pipeline out of Sync Errors in SVXMON in RUN = 138778
started at 21:13:26 ended at 22:53:28</pre>
<!-- Date: Sat Feb 23 20:30:19 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sat_Feb_23_2002_203005.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-328  align='top'></td><td>Addition to Diagnostic Report SB4W5L2</a></td></tr></table>
<!-- Author: cigdem  -->
<!-- Comment: Sat Feb 23 20;43;36 comment by...cigdem  -->
<pre>Pipeline out of SYNC. Errors in SVXMON in RUN=136287
started at 06:23:44 ended at 07:04:44</pre>
<!-- Date: Sat Feb 23 20:31:05 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sat_Feb_23_2002_203047.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-330  align='top'></td><td>Addition to Diagnostic Report SB4W5L2</a></td></tr></table>
<!-- Author: cigdem  -->
<!-- Comment: Sat Feb 23 20;44;45 comment by...cigdem  -->
<pre>Pipeline out of Sync error in SVXMON in RUN 135969
started at 03:05:15 ended at 06:26:40</pre>
<!-- Date: Sat Feb 23 20:31:47 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sat_Feb_23_2002_203131.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-332  align='top'></td><td>Addition to Diagnostic Report SB4W5L2</a></td></tr></table>
<!-- Author: cigdem  -->
<!-- Comment: Sat Feb 23 20;45;54 comment by...cigdem  -->
<pre>Pipeline out of Sync errors in RUN 135919
started at 20:02:17 ended at 20:08:34</pre>

<!-- Date: Sat Feb 23 22:34:50 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 82 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 139756
DPS-on run       : 139754
Requested by     : giolo
Submitted        : 2002-02-23 16:25:54
Completed        : 2002-02-23 20:34:32
Status           : FAILURE

Last processing stage reported : comparing to the reference calibration
Failure diagnostics :
The calibration failed the following reference comparison criteria:

           Cut Name    Sensor Set   Cut Value   Data Value
-------------------    ----------   ---------   ----------
dps_off_ped abs max    SVX_PHI      0.5         0.652266  
 dps_on_ped abs max    SVX_PHI      0.2         0.327425  
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->
<!-- Comment: Tue Feb 26 14;42;20 comment by...Igor -->
<pre>It looks like there was some grounding work done during
the last access so that the pedestals have changed -- am I
right? This trips the calibration comparison script.
I had to switch to a new reference calibration (runs 139756
and 139754) taken after the access.
</pre>
<!-- Date: Sat Feb 23 23:39:11 2002 -->
<pre>Diagnostic Shift Report of SB4W5L2  
==================================  
 
Type of Diagnostic Work: Routine  
Ladder: SB2W6L0  
 
Diagnostic:  
-----------  
 
This Layer is interesting, because is has a certain RUN Period, when it 
had a error level of 100% in David's error monitor. Last processed RUN  
in DEM is 139426. Last RUN in SVXMON error-files:139730 
 
 
From 138211=0x21be3 to 139278=0x2200e DEM shows for this layer 100% bad  
events.  
  
RUN=138211: 2002.01.30 19:24:07-20:16:36 DAQ Testing 
.... 
RUN=139278: 2002.02.16 23:24:46-04:00:20 Beam data 
 
Outside this RUN-Period this layer has an error level of 0% except for  
the RUNS=135666,135628,131076,131075 (1-60%). 
 
RUN=135666: 2001.12.25 18:19:11-20:26:18 Beam data 
RUN=135628: 2001.12.24 09:52:20-15:18:56 Beam data 
RUN=131076: 2001.11.05 22:09:22-22:11:15 Calibration RUN,CEM,XEF 
RUN=131075: 2001.11.05 21:43:16-21:45:04 Calibration RUN, CEM,LED 
 
Error Type in DEM for 138211&lt;=RUN&lt;=139278: 
------------------------------------------ 
 
For the RUNS with 100% error level DEM shows, that parts of the data stream  
repeated (duplicated) partically. You can identify the  
out of order data stream by the fact, that the first out of order Channel ID  
has a "f3" as Data. Sometimes I see also in the out of order Data Stream  
has more than one Data-"f3"-entry. 
Actually I see in this data streams quite a lot of "f3" entries.  
 
RUN=138211 
Event Number: 3 
10500d0b 04104100 00000000 00000000 00000000 00000000 08160816 00000000  
e26009fc 83110004 07f30007 01020402 05060601 17f32005 21f323f3 24072501 
                  ^^^^     
20f32106 22f324f3 250526f3 30f33106 32f35303 54065503 57046006 61f36004 
^^^^     ^^^^^^^^     ^^^^ ^^^^     ^^^^                       ^^^^        
61056203 73f37405 75038211 10031107 12041402 150616f3 16011706 20f36602 
         ^^^^                                                  ^^^^ 
670670f3 74017506 76017102 72067304 74047505 7603a111 03040406 05030504 
    ^^^^                                                            
060707f3 10061106 120314f3 15061606 17012006 210722f3 24032505 26042703 
    ^^^^              ^^^^                       ^^^^ 
20032103 26012707 30f33107 320236f3 37073004 310732f3 33023407 35073603 
                  ^^^^         ^^^^              ^^^^     
37064002 41074207 43074404 41f34205 43055001 51075206 530154f3 550756f3 
                           ^^^^                           ^^^^     ^^^^ 
570650f3 52035307 54045507 560262f3 630664f3 65f36606 67076002 a01104f3 
    ^^^^                       ^^^^     ^^^^ ^^^^                  ^^^^ 
050606f3 04030506 060607f3 100711f3 25f32605 27f32401 25062602 34f33506 
    ^^^^              ^^^^     ^^^^ ^^^^     ^^^^              ^^^^ 
36f33706 30043203 33053407 350536f3 52f35305 540157f3 500651f3 55035605 
^^^^                           ^^^^ ^^^^         ^^^^     ^^^^ 
570264f3 65066602 60f36106 62f377f3 c2c20000                            
    ^^^^          ^^^^     ^^^^^^^^ 
The datastreams terminated with c2c2 0000. 
 
 
Error Type in DEM for  RUNS=135666,135628,131076,131075: 
-------------------------------------------------------- 
 
135666 (bad events 1.19%): datastream starts after e26035fc with a c2c2.  
135628 (bad events 01.%): some events start with a 00 backend state and 
                          bunch crossing 
131076 (bad events ~60%): All events of the RUNS have the same Cap ID! 
                          or Cap ID = ff 
131075 (bad events ~60%): Cap ID's of most of the events = "cd".   
 
 
Scan of the Silicon-Shift-Elogbook for SB2W6L0: 
----------------------------------------------- 
 
Fri Oct 19 11:47:31:  SB2W6L0  Pretest: Bias undercurrent  
Fri Nov 16 16:37:17:  SB2W6L0: Imax is set too low in the file  
         bias applied, histos look fine, ~1count rails  
         normal run: 1000 events, 0 errors  
         HST: 1000 events, 0 errors  
        THIS LADDER IS FINE 
Thu Dec 27 18:16:37:  
SB2W6L0:   
        SVXMON: first problems seen in run 135434 0.25%   
                Strip out of order   
                EOR not found   
                Invalid EOR   
                Wrong Chip Count   
                Since run 135635 no problems.   
 
        DEM:    one run wiht problems,level 0.1%   
                -datastream switches without parsing any channel/or   
                 chip entries to the next wedge:   
                   e2600000 e37a0000 ....   
                 Bunchcrossing and backendstate 00   
                -Channel ID wrong   
                 Channel ID 55-&gt;fd bit3,5,7 high   
 
 Wed Jan 30 17:33:25: 
SB4WAL0 and SB2W6L0 failed cold start with the ACE.  
They were not supposed to be masked from the bitstream readout.  
I masked them out and I'm going to monitor them in the next coldstart.  
 - Gino 
-- Thu Jan 31 10:37:04 comment by...Gino --   
This morning I came in and I found the following: 
SB2W6L0 is still failing INIT furthermore it gave us readout errors consistent 
with Bit 3 stuck LOW 
 
 Fri Feb 15 01:03:03: 
 
Added the following to be masked out of SiliMon checks on Jason's  
advice:  
Known stuckbit3chips (on SB2W6L0):  
180,181 and 324,325  
These changes will take effect from run 139202. 
 
Scan of the SVXMON Errsum files for SB2W6L0: 
-------------------------------------------- 
 
Also in the SVXMON Errsum files I see, that after RUN=138211 the type of  
errors and also the level of errors had changed! And from RUN=139278,  
the newly occured error types are not anymore there.  
 
 
Before RUN 138211 I see in the errsum-files a few  
"Strip Out of Order" Errors on the level of &lt;0.2%, for RUN&lt;138211 
               "         "                  =100%, for RUN&gt;=138211  
 
"EOR Not Found,invalid EOR, Wrong Chip Count" Errors on the level of &lt;0.2%  
in 3 RUNS. 
 
"Strips -- Bad ADC Value" Errors on the level of &lt;3% in 63 RUNS. 
 
"Duplicate Channel" Errors on the level of 11% for RUN&gt;=138211. 
 
"Pipeline Out of Sync" Errors on the level of &lt;=50% 
 
"Stuck Cell Id" Errors for RUNS&gt;=138220: 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 21 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 32 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 37 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 5 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 32 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 0 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 35 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 35 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 17 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 4 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 16 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 16 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 16 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 0 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 6 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 4 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 1 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 33 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 3 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 3 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 3 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 6 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 5 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 36 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 22 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 22 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 22 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 33 
        Stuck Cell Id | 1 | Pipeline cell id is stuck at 43 
 
"Occup Out of Limits" on a level of ~30%. 
 
Scan of the CDF-Shift-Elog for SB2W6: 
------------------------------------- 
No Entries found.  
 
Entries in CDF-Shift-Elog during RUN=138211 (100% error level starts): 
--------------------------------------------------------------------- 
 
Before this RUN shift crew has problems with L2; L2 is hunging up, because 
L2 settings were wrong. They changed them to AutoL2Accept = 1 and started 
the RUN=138211.  
In RUN=138211 they took cosmics without SVT and L2 Auto Accept. 
"Dead time is still very high : 60% (all from Busy time-out)  
although there is no beam at all.   
We changed the prescale of 2 Jets trigger to 0 for a while, which gave us a 
total rate of about 2 Hz 
(instead of 300 Hz). Changed the prescale back to 1 in order to try to find out 
where the problem 
comes from.  
There were some occurances of the SRC bus error (we get our PROM burner back 
tomorrow!) and a bazillion "The Vrb had 
no Event" which are due to BUSY timeouts (guess what-when the Silicon system is 
BUSY because the EVB stopped 
anywhere, doesn't even have to be in the Silicon, none of the Silicon VRBs get 
any more L2A...).  
 
With all of that in mind, I would guess the reason you have high Dead Time is 
that you are Auto-L2A. With L2 not cutting, 
you probably need to turn down the L1A rate. 
Not only that, but it looks like L3  
didn't any rejection either, so, you are trying 
to stuff the L1A rate down the CSL's throat. (You should try to see how much 
data you are trying to push through the CSL, 
see if you are saturated.) You also might want to use the RXPT monitor 
(from the DAQ mon GUI) to see which crates are 
the slow ones (but BUSY deadtime is really due to the EVB/L3/CSL). 
By the way, when you get a chance put the Silicon back in, if noone is doing 
something useful with it." 
</pre>
<!-- Author: cigdem  -->
<!-- Comment: Sat Feb 23 23;51;46 comment by...cigdem  -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>I have a cut and paste error in the title of this 
diagnostic report. It is the diagnostic report for SB2W6L0!!!!
</pre></td></tr></td></table>
<!-- Date: Sat Feb 23 23:41:31 2002 -->
<center><a href='/elog/notebooks/silicon/Sat_Feb_23_2002_234052.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-334' ></a></center>
<!-- Author: cigdem  -->
<!-- Comment: Sat Feb 23 23;43;22 comment by...cigdem  -->
<pre>Addition to Diagnostic Report of SB2W6L0:
-----------------------------------------

This are the CDF-Shift-Elog Entries for the Run 139278, when
the 100% level errors in DEM occured the last time. 
</pre>


<!-- Date: Sat Feb 23 23:44:51 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sat_Feb_23_2002_234428.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-336  align='top'></td><td>Addition to Diagnostic Report of SB2W6L0,  CDF-Shift-Elog entries (2nd part) for RUN 139278</a></td></tr></table>
<!-- Author: cigdem  -->


<!-- Date: Sat Feb 23 23:46:20 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sat_Feb_23_2002_234602.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-338  align='top'></td><td>Currents of SB2W6 for the 2002.01.30</a></td></tr></table>
<!-- Author: cigdem  -->
<!-- Comment: Sat Feb 23 23;50;05 comment by...cigdem  -->
<pre>At this day DEM error levels are rising up from 0% to 100%. 
This happens in RUN=138211, which was taken during
19:24:07-20:16:36.

According the current plots this wedge was not biased. 
</pre>



<!-- Date: Sun Feb 24 10:14:37 2002 -->
<pre>Persistent pink on IMON : 
Run139776 - 139778 
 
SVX============================== 
AVDD ---------------------------- 
         Latest current/Nominal current        
 
SB0W2L2  980/820  
SB0W7L3  710/725 
SB1W2L2  890/915 
SB1W4L4 1100/1110 
SB1W5L3  815/825 
SB2W4L4 1090/1080 
SB3W6L0  351/362 
SB3W6L1  503/521 
SB3W6L2  800/815 
SB3W6L3  855/880 
SB3W6L4 1040/1055 
SB3W7L0  328/339 
SB3W7L1  511/527 
SB3W7L2  800/815 
SB3W7L3  855/880 
SB3W7L4 1040/1055 
SB4W1L4  945/1045 
SB4W4L0  210/318 
SB4W4L1  376/496  
SB4W4L2  650/800 
SB4W4L3  665/815 
SB4W4L4 955/1130 
SB4W5L3  760/745 
SB5W0L2  810/820 
SB5W0L3  795/810 
SB5W1L3  760/770 
SB5W5L4 1060/1045 
 
DVDD ------------------- 
 
SB1W4L4  230/145 
SB4W1L3  220/105 
SB5W1L4  230/160 
SB5W3L4  145/275 
 
BIAS ------------------- 
 
SB0W7L4  168/22    
SB0W9L2  307/1  &lt;----Is this OK??? 
SB1W10L4 241/27 &lt;----!! 
SB1W11L4 172/11 
SB2W0L4   121/10 
SB2W10L4  160/49 
SB3W10L2  213/14 
SB4W4L2  1022/172  &lt;---OK????? 
SB4W4L4  1484/485    &lt;---OK? 
SB4W9L2   114/10 
SB5W2L4   136/26 
SB5W5L2  266/19 
SB5W6L4  172/12 
SB5W8L2  742/0 &lt;--Nominal current should be 0 ? &lt;--NO!! 
 
ISL========================= 
AVDD 
IB0W1L1 995/985 
IB0W1L3 980/970 
IB0W2L3 975/965 
IB0W4L4 1050/1060 
IB5W1L1 595/1030 
IB5W1L2 595/1045 
IB5W1L3 605/1045 
IB5W1L4 630/1045 
IB5W3L2 1350/1380 
 
 
L00===================== 
DVDD 
LB0W1L0 140/75 
LB0W1L1 160/65 
 
</pre>
<!-- Author: Monitoring ACE, Naho -->


<!-- Date: Sun Feb 24 12:54:34 2002 -->
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> 
<style type="text/css"> 
        .indented { 
                margin-left: 15pt; 
                margin-top: 3pt; 
                margin-bottom: 3pt; 
        } 
</style> 
<h2>L00 Gain Scan</h2> 
<body> 
<div class="indented">Purpose: 
        <div class="indented">Gain scan for full detector as of 2/23/02: BW 2-7, DAC 5-8 
        </div> 
        <div class="indented">L00 must be in RA, DPS off, others in NN, DPS on 
        </div> 
        <div class="indented">Only have time to do one bandwidth setting because quiet time is too short.  Need to scan over bandwidth from 2-7 when we have more time.</div> 
</div> 
<div class="indented">Parts included in run: 
        <div class="indented">SVX 
                <div class="indented">None 
                </div> 
        </div> 
        <div class="indented">ISL 
                <div class="indented">Whatever is in fib03 and fib07 
                </div> 
        </div> 
        <div class="indented">L00 
                <div class="indented">All: fib03,07 
                </div> 
        </div> 
</div> 
<div class="indented">Biased: 
        <div class="indented">SVX 
                <div class="indented">All 
                </div> 
        </div> 
        <div class="indented">ISL 
                <div class="indented">All 
                </div> 
        </div> 
        <div class="indented">L00 
                <div class="indented">All 
                </div> 
        </div> 
</div> 
<div class="indented">Chip settings: 
        <div class="indented">Global 
                <div class="indented">DPS: off 
                </div> 
                <div class="indented">Bandwidth: default 
                </div> 
                <div class="indented">BRS: default 
                </div> 
                <div class="indented">ReadNN: no 
                </div> 
                <div class="indented">ReadAll: yes 
                </div> 
                <div class="indented">CounterMod: 250 
                </div> 
                <div class="indented">DRS: default 
                </div> 
                <div class="indented">RampPed: default 
                </div> 
                <div class="indented">PipeDepth: default 
                </div> 
                <div class="indented">Thresh: default 
                </div> 
                <div class="indented">ISEL: default 
                </div> 
                <div class="indented">RampTrim: default 
                </div> 
                <div class="indented">DAC (Charge inj): 5-8 
                </div> 
        </div> 
        <div class="indented">Parts with special chip settings: 
                <div class="indented">L00 RA DPS off 
                </div> 
        </div> 
</div> 
<div class="indented">Triggers: 
        <div class="indented">COSMICS[5,232] 
        </div> 
        <div class="indented">SVX pedestal D &amp; physics 
        </div> 
        <div class="indented">L3MaxProc 16 
        </div> 
        <div class="indented">L3Output 1, subfarmOutput 1 
        </div> 
</div> 
<div class="indented">Events required: 1000/run 
</div> 
<div class="indented">Run numbers: 
        <div class="indented">139745 
                <div class="indented">Default settings, DAC 0 
                </div> 
        </div> 
        <div class="indented">139747 
                <div class="indented">Default settings, DAC 5 
                </div> 
        </div> 
        <div class="indented">139748 
                <div class="indented">Default settings, DAC 6 
                </div> 
        </div> 
        <div class="indented">139750 
                <div class="indented">Default settings, DAC 7 
                </div> 
        </div> 
        <div class="indented">139752 
                <div class="indented">Default settings, DAC 8 
                </div> 
        </div> 
</div> 
<div class="indented">Nearest calibration runs: 
        <div class="indented">DPS on: 
                <div class="indented">139734 
                        <div class="indented">Full detector (L00/SVX/ISL), default chip settings 
                        </div> 
                        <div class="indented">Biased, beam off, magnet on 
                        </div> 
                </div> 
        </div> 
        <div class="indented">DPS off: 
                <div class="indented">139737 
                        <div class="indented">Full detector (L00/SVX/ISL), default chip settings 
                        </div> 
                        <div class="indented">Biased, beam off, magnet on 
                        </div> 
                </div> 
        </div> 
</div> 
<div class="indented">Location of plots or files 
        <div class="indented">Look area of fcdfsgi2 ir0221e[1-8].0001cali 
        </div> 
</div> 
<div class="indented">Dates and people involved 
        <div class="indented">Date: 2/23/02 
        </div> 
        <div class="indented">People: Aaron 
        </div> 
</div> 
<p>
<!-- Author: Aaron -->


<!-- Date: Sun Feb 24 14:30:54 2002 -->
<pre>SB4W4 tripped on DVDD overcurrent SOFTWARE PROTECTION TRIP 
2 times today  
10:58 
14:03 
The Layer 3 was the first one to trip on both cases but all 5  
ladders were in an HIGH CURRENT states on both cases. 
This is impacting operations A LOT so (after calling the silicon 
main pager) we decided not to turn the device back to ON but to  
leave it OFF and exclude it from the HDWDB. 
 
The FTM and the FIB should be checked during the next access. 
 
A plot of DVDD currents vs time will follow</pre>
<!-- Author: Gino -->
<!-- Comment: Sun Feb 24 15;11;27 comment by...Gino -->
<pre>I abviousoly made a new CAENvolts.dat and powerset.dat and downloaded them both on the CAEN GUI.</pre>
<!-- Date: Sun Feb 24 14:32:23 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-339&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-340  width='300' align='top'></td><td>Here is the current vs time (DVDD) for SB4W4 from 8 this morning to 3 pm. the 2 events associated to the trips are clearly visible. </a></td></tr></table>
<!-- Author: gino -->


<!-- Date: Sun Feb 24 15:09:58 2002 -->
<pre>SB1W2L1 tripped on overcurrent on VBIAS. 
No evidence of current above limit (50 nA) from all the various  
spy program I have access to. 
I raised the limit to 300 nA and turned the devices back ON. 
I monitored it for 1 hour so far and the current is stable around 20-25 nA.</pre>
<!-- Author: Gino -->



<!-- Date: Sun Feb 24 18:53:33 2002 -->
<pre>I increased rampped for the following L00 chips: 
 
f821 chip 81 
f823 chip 81 and 80 
f831 chip 81 and 80 
f853 chip 81 and 80 
fa00 chip 81 and 80 
fa01 chip 80 
fa10 chip 81 
fa21 chip 81 and 80 
fa41 chip 81 
fa42 chip 81 and 80 
fa51 chip 81 and 80 
fa53 chip 82 and 81 
</pre>
<!-- Author: David -->

<!-- Date: Sun Feb 24 19:51:29 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 83
Calibration type  : standard
Run period tag    : Feb_2002
DPS-off run       : 139792
DPS-on run        : 139791
Requested by      : anne-sylvie nicollerat
Main process id   : 8305589
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->
<!-- Comment: Tue Feb 26 14;38;00 comment by...Igor -->
<pre>This job has never finished because
1) fcdfsgi2 crashed
2) the data from run # 139792 was lost in the data handling
</pre>




<!-- Date: Fri Apr 19 18:21:53 2002 -->
<pre>&lt;br&gt;WHA Wedge10-E, PMT 8L, ID 2289 (WL1008LE):&lt;br&gt; 
sourcing is done, new LER=1.046000, err=10.5E-3, new HV for this PMP is already 
set. </pre>
<!-- Author: Nikolay Luzhetskiy -->