<!-- Title: 17:19:03  Thu Sep 27 2001 -->
<!-- Crewchief: the usual suspects -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>New store n. 725</pre>


<!-- Date: Thu Sep 27 17:24:24 2001 -->
<pre>Calibration runs taken by CDF ACEs: 
127758 DPS-on 
127759 DPS-off 
both files made to the CSL 
/cdf/b0/disk6/to_be_deleted/ir01f30e.0001cali 
/cdf/b0/disk6/to_be_deleted/ir01f30f.0001cali 
</pre>
<!-- Author: Sav -->


<!-- Date: Thu Sep 27 17:39:41 2001 -->
<pre>These files look quite big. May be the CSL did not divide them in run sections. To be investigated. Tony V. has been informed. 
Not yet in look area, 8 files ahead of them.</pre>
<!-- Author: Saverio -->


<!-- Date: Thu Sep 27 19:06:14 2001 -->
<pre>Took fib05 slot 11 and fib06 slot 10 (readall wedges 
IB5W2 and SB3W8, along with IB5W3 and SB3W9) offline for 
SVT studies.</pre>
<!-- Author: ADF -->


<!-- Date: Fri Sep 28 08:53:42 2001 -->
<pre>Date: Thu, 27 Sep 2001 18:14:31 -0500 (CDT) 
From: Tony Vaiciulis &lt;vaiciuli@b0urpc07.fnal.gov&gt; 
To: dauria@fnal.gov, nahn@fnal.gov 
Cc: cdf_csl@fnal.gov, piccoli@fnal.gov 
Subject: silicon calibration 
 
 
Hi, 
 
It looks like many events at the end of the read all silicon 
calibrations are being lost because the raw data file 
is reaching the maximum size of 2.0 GB. File ir01f30f.0001cali 
is an example of this. The problem is that the large event size 
of 600-700 kB is filling up 2 GB of disk before a new run section 
can be declared. The CSL only closes a file on a run section 
boundary. 
</pre>
<!-- Author: Sav -->


<!-- Date: Fri Sep 28 12:05:07 2001 -->
<pre>Looking at SB4W9 it seems the PS should be ok. 
We should try to integrate it again.</pre>
<!-- Author: Rob & Sav -->


<!-- Date: Fri Sep 28 16:06:53 2001 -->
<p> 
I expanded the scale on all dew point readings to -100 C to 
+100 C (was: -50 C to +100 C).  This is because iFix clamps the 
readings to the scale limit whenever they go "out of range" and 
generates a logfile message.  The SVX and ISL dew points hover 
around -50 C so the logfile had lots of these messages and it was 
annoying me.</p> 
<p> 
Just in case anyone besides me ever looks at these numbers.</p>
<!-- Author: Andy H. -->
<!-- Comment: Fri Sep 28 16;50;51 comment by...- Doug -->
<pre>the daily check-list for the main silicon pager records these
numbers every day... so thanks for fixing this.

</pre>


<!-- Date: Fri Sep 28 17:22:38 2001 -->
<pre>Mary loaded  CPC_092501.seq into all 
fibs.  However, she did nonot burn them int.  
So if the fibs are power cycled they will be lost. 
Once some data is successfully taken, we will 
burn them in. 
A short calibration run. bias off was done with 
all silicon. b2w0 and w1 only had new sequencies  
as a test.  Everything was fine. no reformatter errors  
on the wedtes with the new sequencies.</pre>
<!-- Author: Jean and Mad Mary -->


<!-- Date: Sat Sep 29 09:45:31 2001 -->
<pre>I have compared the 8/16/00 digitize sequence and the new 9/25/01 
digitize sequence and verified that only the intended changes were 
made.  Moreover, I have compared this sequence to a "good" sequence 
Maurice has sent from LBL.  I find that that our new sequence is 
functionally equivalent to the LBL sequence.  I note the following for 
the record: 
 
Changes in 9/25/01 sequence: 
1) Comparator reset delayed 80ns (closer to second PRD1) 
2) Ramp reference select delayed 240ns (now after second PRD1, only 80ns 
separating it from Ramp reset.  Maurice claims this is ok, Igor thinks 
it may cause more noise if not at least 100ns). 
3) DDR BE enable 400ns earlier than previously - should have no effect 
 
Differences to LBL sequence: 
1) We have Ramp reference select after the 2nd PRD1 , LBL places it in 
between PRD1s 
2) LBL has 420ns between Ramp reference select and Ramp Reset, we have 
only 80ns. 
 
</pre>
<!-- Author: jean for chris hill -->


<!-- Date: Sat Sep 29 09:49:16 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><h2>Run plan!</h2> 
 
<ol> 
<li> Next quiet time, take Dmode calibrations 
<li> Once taken, change all ramp trims to 255 
<li> Take Dmode calibrations again 
<li> Take xmode calibration, once Igor is ready 
<li> BW 5,6,7 scans with beam, DPS on.  Also, 
dmode calibrations to go with them. 
<li> BW 5,6,7 with DPS off, with beam.  Need to set new 
threshholds and it will probably disrupt CDF, so 
needs some warning.  Also, will need dmode calibrations. 
<li> Turn SB3W8/9 and IB5W2/3 (readall) back on 
<li> Get IB5W0 and IB5W1 back online 
<li> Pre-test SB5W11 and SB5W0 
<li> Take short beam run (with ISL expert there) with 
IB1W4 and IB1W5 
</ol> </td></tr></td></table>
<!-- Author: ADF/ Jean -->


<!-- Date: Sat Sep 29 16:44:10 2001 -->
<pre>The ACES are complaining about frequent busy time outs due to silicon, HRR eventually does not recover. I see a lot of the  
following errors: 
(MLE) b0l3gate1.fnal.gov:main:3:28:03 PM-&gt;Host b0eb24.fnal.gov, task tRec_0 
SCPU-P0-E-BadChannelCounts: In event 25 the sum of channel counts is inconsistent with the total count, VRB slot 16. 
 
(many different VRB's in the same event) 
 
and  
 
(MLE) b0l3gate1.fnal.gov:main:3:28:03 PM-&gt;Host b0eb24.fnal.gov, task tRec_0 
SCPU-P0-E-BadVrbByteCount: Event 26 total byte count is lt 32, gt 65528, or not divisible by 8 for VRB in slot 16. 
Count = 62785. 
(MLE) b0l3gate1.fnal.gov:main:3:28:03 PM-&gt;Host b0eb24.fnal.gov, task tRec_0 
SCPU-P0-E-VrbHeader: Dump of header words for event 26 from VRB in slot 16: 
0xf5414dfc 0x8f0e00f0 0x01f002f0 0x03f004f0 0x05f006f0 0x07f008f0 0x09f00af0 0x0bf00cf0 
 
again, many different VRB's. 
 
A lot of the header dumps are all zero's 
 
(MLE) b0l3gate1.fnal.gov:main:3:28:03 PM-&gt;Host b0eb18.fnal.gov, task tRec_0 
SCPU-P0-E-BadVrbByteCount: Event 26 total byte count is lt 32, gt 65528, or not divisible by 8 for VRB in slot 8. 
Count = 243. 
(MLE) b0l3gate1.fnal.gov:main:3:28:03 PM-&gt;Host b0eb18.fnal.gov, task tRec_0 
SCPU-P0-E-VrbHeader: Dump of header words for event 26 from VRB in slot 8: 
0x00f300f3 0x00f300f3 0x00f300f3 0x00f300f3 0x00f300f3 0x00f300f3 0x00f300f3 0x00f300f3 
 
but I think this is because most of the data we read out is the pathological ladders which read out 8k of zeros. I don't know 
if these cause the problems, or if this is some scpu problem. It 
happens in all crates, though. 
 
I have no proposed solutions at this point. </pre>
<!-- Author: Lester -->


<!-- Date: Sun Sep 30 08:01:18 2001 -->
<pre> Sat Sep 29 20:08:12 Silicon d-mode calibrations done -&gt; standby. - Larry N. :: (run 127924-5) 
-- Sat Sep 29 20:34:38 comment by...Vladimir --   
 
Did D-mode Silicon calibration (both extra 1 and 0) 
At this point we cannot locate files corresponding to runs  
127924 and 127925) in the lookarea. 
Since we could not successfully use script  ~cdfdaq/dhtools/lookareamon.sh 
we used findfile command  on fcdfsgi2, no luck. 
Will waite 10 more min. If we do not find the files again, 
we will repeat the D-mode calibration. 
 
 
-- Sat Sep 29 21:18:42 comment by...Vladimir --   
 
Repeated D-mode silicon calibrations (run 127930 and 127931) 
In the meantime the run 127924 made it lookarea  - over 1 hr after the run was completed.</pre>
<!-- Author: Sav -->
<!-- Comment: Sun Sep 30 08;03;09 comment by...Sav -->
<pre>This is the first calibration with the new sequence.</pre>


<!-- Date: Sun Sep 30 08:41:38 2001 -->
<p> A L00 Power Supply reads out <font color=red> max bias (512 V) </font>when OFF:<br> 
<pre>Fri Sep 28 16:59:43 CDT 2001     ALARM:   L00  B1  W0  L3 is reported OFF, but low/high voltage is above 2/5 V 
Sat Sep 29 04:33:38 CDT 2001     ALARM:   L00  B1  W0  L3 is reported OFF, but low/high voltage is above 2/5 V  
Sun Sep 30 02:29:27 CDT 2001     ALARM:   L00  B1  W0  L3 is reported OFF, but low/high voltage is above 2/5 V</pre> 
 <font color =red> Channel 102  status 1   condition 3  VBias 512.90   IBias  0.00 </font><br>
<!-- Author: Saverio -->


<!-- Date: Sun Sep 30 09:54:44 2001 -->
<pre>Unable to turn on the folowing wedges: 
Detailed event sequence will come later. 
 
 The following wedges should be Stand-By or ON and are OFF:  
 
SB3W5L2   
SB3W6L2   
SB3W7L2  SB3W7L3   
SB4W5L3   
SB4W6L2   
SB4W8L2  SB4W8L3  SB4W8L4   
SB5W4L2  SB5W4L3   
SB5W7L3   
 * * * Cold Start would fail ! * * *  
</pre>
<!-- Author: Saverio -->
<!-- Comment: Sun Sep 30 10;34;42 comment by...Saverio -->
<pre>All these have 0.5 V in OFF status</pre>

<!-- Comment: Sun Sep 30 11;25;04 comment by...Napora and Saverio -->
<p>It turns out that all DVDDs draw about half a volt when they are off and the PC is turned on.  These wedges were being fussy about turning on because this half a volt was causing an over voltage error on some layers (not all, apparently some layers are fussier than others) during turn on of the DVDDs.  The solution is to turn the wedge completely OFF and then back on to STANDBY and hope the command to turn on the DVDDs comes quickly enough after the PC turns on that the OVV does not register.  It should only take one or two tries.


<!-- Comment: Sun Sep 30 21;15;07 comment by...Jean -->
<pre>Why did this happen now?  Are these new wedges?  I don't remember seeing this the last couple of days?
</pre>
<!-- Comment: Mon Oct  1 10;43;40 comment by...Saverio -->
<pre>More detailed list of problems encountered:
- The GUI showed heartbeat, but no communication with 
  the PS was possible. I had to re-boot (HW) SVXINTER.
- Trying to turn on a channel with error it fails in silence
  does not report the error again in the log file.
  This should be corrected in the GUI.
- The GUI should be able to handle multiple error/alarms popping
  up more windows. We had a permanent error condition due to L00.
- Can the deadband on overvoltage be tuned ? 
- The GUI went into a strange state twice: it was updating but 
  did not accept any mouse click. This is a potentially dangerous
  feature.</pre>
<!-- Date: Sun Sep 30 12:31:16 2001 -->
<pre>ACE called and said that BUSY signal from silicon was causing  
very high dead time. The return crosspoint showed last crate to 
reply is b0svx02 in the ten's of milliseconds (normal is around 
0.5 ms). It turned out to be related to the presence of a two 
track trigger. Don't know why this would affect the silicon; it 
may be again the daq falsely blaming the silicon. Ashmanskis  
will be in later and will be asked.</pre>
<!-- Author: Lester -->
<!-- Comment: Mon Oct  1 10;17;27 comment by...SCN -->
Hello?  The only Silicon crate to reply will be b0svx02-this
does not help you that much.  Better is to issue a HRR and
look to see who is BUSY, or just scan through the log files<pre>
b0dap30.fnal.gov% pwd; grep -e ":BUSY" errorfile1279*
/cdf/code-common/cdfonline/errmon/log/daq
errorfile127900.log:(MLE) b0svx00:Messenger:2:42:32 PM->Silicon Timeout:BUSY- Slots:  18
errorfile127900.log:(MLE) b0svx03:Messenger:2:42:47 PM->Silicon Timeout:BUSY- Slots:  16
errorfile127900.log:(MLE) b0svx03:Messenger:2:45:46 PM->Silicon Timeout:BUSY- Slots:  16
errorfile127900.log:(MLE) b0svx00:Messenger:2:45:31 PM->Silicon Timeout:BUSY- Slots:  18
errorfile127911.log:(MLE) b0svx00:Messenger:3:27:04 PM->Silicon Timeout:BUSY- Slots:  16 18
errorfile127911.log:(MLE) b0svx01:Messenger:3:27:11 PM->Silicon Timeout:BUSY- Slots:  08 18 20
errorfile127911.log:(MLE) b0svx03:Messenger:3:27:19 PM->Silicon Timeout:BUSY- Slots:  08 16
errorfile127911.log:(MLE) b0svx04:Messenger:3:27:16 PM->Silicon Timeout:BUSY- Slots:  16
errorfile127911.log:(MLE) b0svx07:Messenger:3:28:10 PM->Silicon Timeout:BUSY- Slots:  16
errorfile127911.log:(MLE) b0svx02:Messenger:3:27:14 PM->Silicon Timeout:BUSY- Slots:  12
errorfile127912.log:(MLE) b0svx00:Messenger:3:42:52 PM->Silicon Timeout:BUSY- Slots:  16
errorfile127912.log:(MLE) b0svx03:Messenger:3:43:07 PM->Silicon Timeout:BUSY- Slots:  16
errorfile127923.log:(MLE) b0svx00:Messenger:6:54:39 PM->Silicon Timeout:BUSY- Slots:  18
errorfile127923.log:(MLE) b0svx07:Messenger:6:56:17 PM->Silicon Timeout:BUSY- Slots:  16
errorfile127948.log:(MLE) b0svx08:Messenger:12:58:35 AM->Silicon Timeout:BUSY- Slots:  17
errorfile127948.log:(MLE) b0svx00:Messenger:12:57:57 AM->Silicon Timeout:BUSY- Slots:  18
errorfile127948.log:(MLE) b0svx07:Messenger:12:59:03 AM->Silicon Timeout:BUSY- Slots:  16
errorfile127950.log:(MLE) b0svx08:Messenger:2:57:05 AM->Silicon Timeout:BUSY- Slots:  17
errorfile127950.log:(MLE) b0svx07:Messenger:2:57:32 AM->Silicon Timeout:BUSY- Slots:  16
errorfile127956.log:(MLE) b0svx00:Messenger:8:13:11 AM->Silicon Timeout:BUSY- Slots:  16 18
errorfile127956.log:(MLE) b0svx01:Messenger:8:13:17 AM->Silicon Timeout:BUSY- Slots:  08 18 20
errorfile127956.log:(MLE) b0svx07:Messenger:8:14:17 AM->Silicon Timeout:BUSY- Slots:  16
errorfile127956.log:(MLE) b0svx03:Messenger:8:13:27 AM->Silicon Timeout:BUSY- Slots:  08 16 20
errorfile127956.log:(MLE) b0svx04:Messenger:8:13:24 AM->Silicon Timeout:BUSY- Slots:  16
errorfile127956.log:(MLE) b0svx02:Messenger:8:13:20 AM->Silicon Timeout:BUSY- Slots:  12 20
errorfile127956.log:(MLE) b0svx03:Messenger:8:17:01 AM->Silicon Timeout:BUSY- Slots:  08 16
errorfile127956.log:(MLE) b0svx00:Messenger:8:16:44 AM->Silicon Timeout:BUSY- Slots:  16 18
errorfile127956.log:(MLE) b0svx04:Messenger:8:16:58 AM->Silicon Timeout:BUSY- Slots:  16
errorfile127956.log:(MLE) b0svx07:Messenger:8:17:51 AM->Silicon Timeout:BUSY- Slots:  16
errorfile127956.log:(MLE) b0svx01:Messenger:8:16:51 AM->Silicon Timeout:BUSY- Slots:  08 18 20
errorfile127956.log:(MLE) b0svx02:Messenger:8:16:54 AM->Silicon Timeout:BUSY- Slots:  12
errorfile127964.log:(MLE) b0svx07:Messenger:12:21:18 PM->Silicon Timeout:BUSY- Slots:  16
errorfile127964.log:(MLE) b0svx00:Messenger:12:30:03 PM->Silicon Timeout:BUSY- Slots:  18
errorfile127964.log:(MLE) b0svx05:Messenger:12:36:48 PM->Silicon Timeout:BUSY- Slots:  10
errorfile127964.log:(MLE) b0svx02:Messenger:12:36:00 PM->Silicon Timeout:BUSY- Slots:  12
errorfile127964.log:(MLE) b0svx03:Messenger:1:00:58 PM->Silicon Timeout:BUSY- Slots:  08
errorfile127964.log:(MLE) b0svx03:Messenger:1:48:29 PM->Silicon Timeout:BUSY- Slots:  08
errorfile127964.log:(MLE) b0svx08:Messenger:1:48:51 PM->Silicon Timeout:BUSY- Slots:  17
errorfile127966.log:(MLE) b0svx00:Messenger:3:01:05 PM->Silicon Timeout:BUSY- Slots:  18
errorfile127966.log:(MLE) b0svx01:Messenger:3:01:52 PM->Silicon Timeout:BUSY- Slots:  20
errorfile127967.log:(MLE) b0svx08:Messenger:3:44:11 PM->Silicon Timeout:BUSY- Slots:  17
errorfile127967.log:(MLE) b0svx00:Messenger:4:04:01 PM->Silicon Timeout:BUSY- Slots:  18
</pre>
No real smoking gun here, I'm afraid.  Note, one can replace ":BUSY" with "DONE-" and get<pre>errorfile127555.log:(MLE) b0svx00:Messenger:10:26:23 PM->Silicon Timeout:!DONE- Slots:  18
errorfile127555.log:(MLE) b0svx00:Messenger:10:31:15 PM->Silicon Timeout:!DONE- Slots:  18
errorfile127555.log:(MLE) b0svx00:Messenger:10:32:56 PM->Silicon Timeout:!DONE- Slots:  18
errorfile127555.log:(MLE) b0svx00:Messenger:10:33:37 PM->Silicon Timeout:!DONE- Slots:  18
errorfile127555.log:(MLE) b0svx00:Messenger:10:36:04 PM->Silicon Timeout:!DONE- Slots:  18
errorfile127555.log:(MLE) b0svx00:Messenger:10:36:38 PM->Silicon Timeout:!DONE- Slots:  18
errorfile127853.log:(MLE) b0svx02:Messenger:2:59:29 AM->Silicon Timeout:!DONE- Slots:  12
errorfile127853.log:(MLE) b0svx02:Messenger:3:05:46 AM->Silicon Timeout:!DONE- Slots:  12
errorfile127853.log:(MLE) b0svx02:Messenger:3:06:47 AM->Silicon Timeout:!DONE- Slots:  12
</pre>
which can help one find out what wedges are giving DONE TOs (!DONE).  Soon
we'll try to get some real wedge IDs in here

<!-- Date: Mon Oct 1 10:12:09 2001 -->
<pre>From CDF logbook: 
 Mon Oct 1 07:24:07 SVX Calibration done. 
Run with DPS on is 127985; 
            off is 127986 
- CR+JG :: (run 127985) 
FILES ARE IN THE LOOK AREA 
1     1.7G Oct  1 08:07 /cdf/data08/look/icalir/ir01f3f2.0001cali 
1     1.8G Oct  1 07:44 /cdf/data08/look/icalir/ir01f3f1.0001cali 
</pre>
<!-- Author: Sav -->
<!-- Comment: Tue Oct  2 12;13;15 comment by...Saverio -->
<pre>These calibration runs were taken with bias off on all ladders</pre>
<!-- Date: Mon Oct 1 11:19:51 2001 -->
<P> 
I looked at one of the runs taken this weekend after the sequence change. The p/n asymmetry seems to be mostly gone, but there are residual 10%ish asymmetries on some ladders. 
<P> 
An example of a symmetric ladder is 
<A HREF="http://ncdf17.fnal.gov/cgi-bin/ISLDmon?Run=127848&HDI=f543">here</A>. 
 
<P> 
An example of a 90% symmetric ladder is <A HREF="http://ncdf17.fnal.gov/cgi-bin/ISLDmon?Run=127848&HDI=e094"> 
here</A>. 
<P> 
It would be good if others could check more generally.  
<!-- Author: David -->