<!-- Title: 10:16:38  Wed Aug 14 2002 -->
<!-- Crewchief: evelyn thomson -->
<!-- Op1: jong-young chung -->
<!-- Op2: cheng-ju lin -->
<!-- Op3: jay dittmann -->
<!-- Op4: phil koehn -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>XFT pager schedule 
==================================== 
Nov  7 -> Dec  3 Cheng-Ju Lin 
Dec  3 -> Dec 17 Jong-Young Chung
Dec 17 -> Jan  7 Evelyn Thomson 
 
</pre>


<!-- Date: Wed Aug 14 10:26:55 2002 -->
<pre>COT experts lowered the HV for SL2 quadrant C to avoid 
tripping last night.  I was paged and asked to mask off 
the corresponding wires for the XFT.  The following wires: 
COT SL2 cells 96-143 (Quad C) sense wires s4, s5, s6, s7 
have been masked off.</pre>
<!-- Author: Cheng-Ju -->


<!-- Date: Wed Aug 14 12:13:24 2002 -->
<center><a href='/elog/notebooks/xft/Wed_Aug_14_2002_121254.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-350' ></a><a href='/elog/notebooks/xft/Wed_Aug_14_2002_121303.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-352' ></a></center>
<!-- Author: e -->
<!-- Comment: Wed Aug 14 12;14;21 comment by...Evelyn -->
<pre>Quadrant C of COT SL2 has 4 dead wires per cell masked on - see
increased occupancy.  But linker track occupancy is still flat
so triggers are ok.</pre>


<!-- Date: Thu Aug 15 13:23:15 2002 -->
<pre>Got paged this morning due to frequent DTO from b0xft00. 
The crate has the new 2401 processor.  I suspected the problem 
has to do with the processor.  Paged Arnd Meyer and he is 
looking at the issue.</pre>
<!-- Author: Cheng-Ju -->
<!-- Comment: Thu Aug 15 13;26;21 comment by...Cheng-Ju -->
<pre>Arnd has found problem.  See his message below from the
shift e-log:

                    ***************************
   Thu Aug 15 12:11:30 I'm done with the XFT crates. I changed over to the latest FISION version (v2_16) - b0xft00 with
the 2401 is booting over the network, and was loading an older version with known bugs. I suspect this as the reason for the
observed instabilities of the crate. 

Please also note that b0xft00 takes significantly longer than any other crate to come back up after a reboot: it loads
everything over Ethernet instead of FlashRAM. This may have caused some of the confusion last night.  - Arnd 
</pre>


<!-- Date: Thu Aug 15 13:31:21 2002 -->
<pre>The XFT teststand crate is up and running.  The current 
setup uses one crate to do the TDC to finder tests. 
When the trigger supervisor is available, we will setup 
the finder to linker tests. 
The XFT teststand is in room 202 (second floor westside of B0). 
The top crate is the finder crate (tstxft1).  The bottom 
crate has the split J3 backplane (TDC for slots 1-17, and 
CAL for slots 18-21). 
 
</pre>
<!-- Author: Cheng-Ju -->


<!-- Date: Mon Aug 19 11:31:53 2002 -->
<center><a href='/elog/notebooks/xft/Mon_Aug_19_2002_113113.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-354' ></a><a href='/elog/notebooks/xft/Mon_Aug_19_2002_113127.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-356' ></a></center>
<!-- Author: evelyn -->
<!-- Comment: Mon Aug 19 11;32;25 comment by...Evelyn -->
<pre>Why are the error messages appearing when there are hardly any errors?</pre>

<!-- Comment: Mon Aug 19 12;14;53 comment by...Cheng-Ju -->
<pre>I set the bit error theshold at 0.8%.  I'll bump it
up to 1% event error rate in the next TrigMon release.
</pre>


<!-- Date: Mon Aug 19 12:18:11 2002 -->
<pre>Just a short progress report on the XFT teststand.  Last 
Friday I successfully reprogrammed Finder Flash RAM using 
tstxft1 crate.  I had to temporarily run a cable from the 
CDF clock crate to the tracer in tstxft1 for the test. 
I'll ask Dervin to connect the clock line to our teststand 
in a more permanent fashion.</pre>
<!-- Author: Cheng-Ju -->


<!-- Date: Mon Aug 19 12:22:18 2002 -->
<pre>Got paged last night close to midnight.  Aseet disabled all 
s3 and s8 sense wires in quad C of COT SL2.  I was asked to  
mask the corresponding bits in XFT.  It was excruciatingly 
slow running GUI from home via 56K modem but I managed 
to do it.   
 
At the present, all s3,s4,s5,s6,s7,s8 sense wires in quad C 
of COT SL2 have been masked off. 
 
</pre>
<!-- Author: Cheng-Ju -->


<!-- Date: Thu Aug 29 10:15:39 2002 -->
<pre>Unmasked 288 wires (sense wires 3-8 in SL2 quadrant C cells 96-143) 
 
Masked new dead wire SL2 cell 110 sense wire 5</pre>
<!-- Author: Evelyn -->


<!-- Date: Sun Sep 1 09:05:23 2002 -->
<center><a href='/elog/notebooks/xft/Sun_Sep__1_2002_090415.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-358' ></a><a href='/elog/notebooks/xft/Sun_Sep__1_2002_090431.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-360' ></a><a href='/elog/notebooks/xft/Sun_Sep__1_2002_090440.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-362' ></a><a href='/elog/notebooks/xft/Sun_Sep__1_2002_090448.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-364' ></a><a href='/elog/notebooks/xft/Sun_Sep__1_2002_090454.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-366' ></a></center>
<!-- Author: evelyn -->
<!-- Comment: Sun Sep  1 09;11;37 comment by...Evelyn -->
<pre>------------------------------------------------
			Live	TrigMon	XFLD
Run 	Time 		L(nb-1) Events 	errors
------------------------------------------------
150799	00:11-02:10	 98	3655	0
150801	02:21-03:02	 38	1116	0
150802	03:07-03:27	 17	 531	0
150803	03:33-12:19	363	?	?
150805	12:36-15:14	 85	5987	120 
150819	21:24-21:59	 38	 570	0
150820	22:10-05:44	391	3567	100
150821	05:59-07:20	 57	 745	0
----------------------------------------------------	

150805 errors were in all boards except b0xft05 14,16,18
150820 errors were only in b0xft01 slot 4</pre>


<!-- Comment: Sun Sep  1 09;52;09 comment by...e -->
<pre>Plots are for 150799, 150805,150819, 150820, 150821</pre>
<!-- Date: Sun Sep 1 09:16:45 2002 -->
<center><a href='/elog/notebooks/xft/Sun_Sep__1_2002_091620.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-368' ></a><a href='/elog/notebooks/xft/Sun_Sep__1_2002_091628.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-370' ></a><a href='/elog/notebooks/xft/Sun_Sep__1_2002_091634.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-372' ></a></center>
<!-- Author: evelyn -->
<!-- Comment: Sun Sep  1 09;18;34 comment by...evelyn -->
<pre>These plots show xft track occupancy in data (top-left)
and in simulation (bottom-right) and discrepancies (top-right)
and discrepancies with track (bottom-left).

The simulation track occupancy looks very different for
the areas with discrepancies.</pre>


<!-- Comment: Sun Sep  1 09;51;34 comment by...e -->
<pre>Plots are for runs 150799, 150805 and 150820</pre>
<!-- Date: Sun Sep 1 09:50:25 2002 -->
<center><a href='/elog/notebooks/xft/Sun_Sep__1_2002_095009.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-374' ></a><a href='/elog/notebooks/xft/Sun_Sep__1_2002_095016.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-376' ></a></center>
<!-- Author: evelyn -->
<!-- Comment: Sun Sep  1 09;51;05 comment by...evelyn -->
<pre>The same plots for run 150823 - there are errors
on b0xft01 slots 4 and 6 in this one.</pre>




<!-- Date: Sun Sep 1 13:52:39 2002 -->
<table><tr><td><a href=/elog/notebooks/xft/Sun_Sep__1_2002_135237.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-378  align='top'></td><td>Same plot for 150824 - no errors for this run</a></td></tr></table>
<!-- Author: e -->
<!-- Comment: Tue Sep 10 10;27;17 comment by...Cheng-Ju -->
<pre>I have fixed the error counter problem in TrigMon.</pre>
<!-- Date: Tue Sep 3 10:15:45 2002 -->
<pre>No errors since Monday run 150823 
 
----------------------------------------------- 
                        Live    TrigMon XFLD 
Run     Time            L(nb-1) Events  errors 
------------------------------------------------ 
150824  08:47-13:31     143     5277    0 
150827	13:57-14:34	 19	 235	0 
150853	00:28-01:49	 75	2675	0 
150856	02:50-06:40	194	3159	0 
150882	20:14-20:40	 22	 255	0 
150883	20:50-22:33	108	 687	0 
150884	22:45-23:25	 40	 316	0 
150885	23:43-05:31	259	 700	0 
150886	06:08-06:30	 14	 45	0 
------------------------------------------------------	 
</pre>
<!-- Author: Evelyn Thomson -->


<!-- Date: Tue Sep 3 10:18:36 2002 -->
<pre>From Sunday  
 
        I have investigated the errors in the "TrigSim vs Linker Track 
Discrepancy" plots.  The errors are since Saturday in 3 runs - 150805, 
150820, 150823.  The errors are not the same nor always on the same 
chip/board.  I have never seen this level of errors in TrigMon before for 
XFT. 
 
To check the errors, I reran only the XFT monitoring code over the data in 
the Stream A look area.  This uses the same code (XFTSim) as TrigMon, but 
without the histograms and other TrigMon code. 
 
I could not reproduce the errors seen online by TrigMon.  Admittedly, the 
events in the look area and the events used by TrigMon are different. 
But with the high error rate seen in runs 150805, 150820 and 150823, I 
would expect to see some similar errors. I did not. 
 
        eg online TrigMon ran over 1689 events and saw about 40 errors for 
        each of the 12 linker chips in b0xft01 slot 4 and 6. I ran over 
        2169 events in run 150823 and saw no linker chip errors. 
 
        eg online TrigMon ran over 5987 events in run 150805 and saw about 
        100 linker chip errors for each of the 12 linker chips in all 8 
        linker boards in b0xft01 and b0xft03, and 5/8 linker boards in 
        b0xft05.  I'm still running over this, but have seen no such 
        errors so far. 
 
So I declare the XFT data good.  I don't know why the TrigMon plots have 
errors, which I cannot reproduce.  I am going to tell the shift crew to ignore all XFT errors in TrigMon.  I will monitor the look area data myself until we can understand what's happened with TrigMon. 
 
 
</pre>
<!-- Author: e -->
<!-- Comment: Thu Sep  5 17;46;19 comment by...e -->
<pre>If the database could not be read then the simulation still keeps on going.  This could have been the problem.  I think I will add some ZOOM error messages to the XFTSim code, so that it there is a problem reading the database, then an error will
appear in the log file.  The problem has not happened again 
since Sunday morning.

</pre>
<!-- Date: Thu Sep 5 15:57:33 2002 -->
<pre>b0xft05 slot 16 reports a bunch-counter mismatch. 
This was for linker board serial #20. 
I removed this board and replaced it with #14. 
We shall see if the pesky bunch-counter error goes away...</pre>
<!-- Author: Evelyn Thomson -->
<!-- Comment: Mon Sep  9 09;32;27 comment by...e -->
<pre>No b0xft05 bunch counter errors now.  Looks like it was
something on board #20.
</pre>
<!-- Date: Thu Sep 5 16:48:13 2002 -->
<pre>Finder serial #23 (possible spare) put into b0xft04 slot 14. 
 
This one had problems with 2-miss design  before (bit error). 
One of the pins on one of the pixels chips was open.  Soldered 
back on.</pre>
<!-- Author: Cheng-Ju and Evelyn -->
<!-- Comment: Thu Sep  5 16;59;07 comment by...e -->
<pre>Passed 5000 events in finder-to-linker test in b0xft04 slot14
(20 and 2111Off400_2M files)!
Keep in system. Old board #26 is a fully tested spare

</pre>


<!-- Date: Thu Sep 5 17:00:52 2002 -->
<pre>Test finder #3 in b0xft04 slot 15.  This one had problems 
with the 1 miss design.  Chip 2a was replaced. 
 
</pre>
<!-- Author: et and cjl -->
<!-- Comment: Thu Sep  5 17;36;47 comment by...e -->
<pre>Passed 5000 events finder-to-linker test 
(2111Off400_2M file)
Keep in system. Old board #9 is a fully tested spare.

Serial numbers 
=============================
b0xft04 	old	new
=============================
14		26	23
15	 	9	 3</pre>

<!-- Comment: Thu Sep  5 17;38;50 comment by...cjl -->
<pre>This board passed finder to linker test (5000 evts) in
2-miss design.  Will have to repeat the test in 1-miss
design at a later date.</pre>





<!-- Date: Mon Sep 9 09:35:15 2002 -->
<pre>Looked at good runs 151087-151144 - 41,696 TrigMon events 
 
Saw 3 finder glitches, 1 finder w0 error and 1 linker error 
 
finder glitches (error rate is 1 x 10-4) 
151088 b0xft04 slot 8 
151120 b0xft00 slot 10 
151135 b0xft04 slot 9 
 
w0 glitch on b0xft04 slot 15 4C in 151135 
linker extra pixels b0xft01 slot 4 1A 151143</pre>
<!-- Author: e -->


<!-- Date: Tue Sep 10 10:25:48 2002 -->
<pre>The new processor 2401 was causing DTO in DAQ.  We decided 
to swap back the old 2301.  See e-log entry below: 
 
========================================================== 
Fri Sep 6 16:43:33 : 
 
B0XFT00 problem:  
 
xft00 was causing done timeouts in the Run Control.  The   
MVME 2401 in this crate was mostly frozen -- we could   
not issue any commands or login via rlogin.  
 
Resetting the crate would allow running, but eventually   
the MVME 2401 would hang up again.  
 
The software changes earlier were not to blame (tried   
old and new).  Reseating the MVME did not help.  
 
Arnd swapped back the original MVME 2301 into this   
crate and now the DAQ seems to be working.  However,   
it should continue running for a while to be sure.  
 
 - W.Badgett,A.Meyer,C-J.Lin  
</pre>
<!-- Author: Cheng-Ju -->



<!-- Date: Thu Sep 12 15:20:54 2002 -->
<pre>The XFT error is back again for b0xft01 slots 4 and 6 for 
run 151436.</pre>
<!-- Author: e -->


<!-- Date: Wed Oct 2 12:52:03 2002 -->
<pre>Result of finder to linker test in 1-MISS design: 
 
All (but 1) passed the test, including the SL24 board #3 in 
b0xft04 slot 15.  This board originally pass the 2-miss but 
failed the 1-miss test.  The problem was traced to a faulty 
finder chip, which was replaced. 
 
SL24 board #23 in b0xft04 slot 14 pass the 2-miss but fail 
the 1-miss test.  This was the board that had a loose 
solder connection on a pixel chip.  It appears that we may 
have to replace a finder chip on the board.  The log from 
finder-linker test showing the error is appended at the end. 
 
For now, I have put a working spare (SL24#9) in b0xft04 slot 14.   
 
*********************************************************************** 
*********************************************************************** 
 Finder offset               = 7 in 132ns units 
 Finder pipeline depth       = 143 in  33ns units 
 Finder L2HW pipeline depth  = 144 in  33ns units, should be finder depth  +1  
 
 Linker offset               = 15 in 132ns units, should be finder offset +8 
 Linker pipeline depth       = 142 in  33ns units, should be finder depth  -1 
*********************************************************************** 
 ERROR! Event 0	 Finder b0xft04 14 b0xft05 4 4d'  cell=3	 Finder pixels=  
   f0	 Expect pixels=    40	 FTLsys=0 
 ERROR! Event 2	 Finder b0xft04 14 b0xft05 4 4a'  cell=3	 Finder pixels=  
   f0	 Expect pixels=    c0	 FTLsys=0 
 ERROR! Event 2 b0xft04 14 b0xft05 4 4a'  cell=3	 Linker pixels=    f0	 
 Expect pixels=    c0	 FTLsys=0 
 
*********************************************************************** 
 ERROR! Event 0	 Finder b0xft04 14 b0xft05 4 4d'  cell=3	 Finder pixels=    f0	 Expect pixels=    40	 FTLsys=0 
 ERROR! Event 2	 Finder b0xft04 14 b0xft05 4 4a'  cell=3	 Finder pixels=    f0	 Expect pixels=    c0	 FTLsys=0 
 ERROR! Event 2 b0xft04 14 b0xft05 4 4a'  cell=3	 Linker pixels=    f0	 Expect pixels=    c0	 FTLsys=0 
 
Error 
</pre>
<!-- Author: Cheng-Ju Lin -->


<!-- Date: Mon Oct 7 15:20:35 2002 -->
<pre>Here is the message from Jonathan Lewis about the impending 
change of the XFT design from all 2-miss to all 1-miss: 
================================================================ 
Here is the draft plan for implementing pending trigger changes: 
 
0) Declare new Alpha firmware as default. 
1) Make a new table PHYSICS_1_02_v7.  This will have the global parameter 
for the XFT version changed from 1 to 2. 
2) Test the table at the end of a store to make sure it is OK, but don't 
change the XFT. 
3) Mark the data as bad 
4) Between stores, change the XFT to 1-miss per SL. 
5) Start next store with new table. 
6) Build and test PHYSICS_1_03 including all tested changes. 
7) Use PHYSICS_1_03 
 
If you object, please comment as soon as possible so we can move forward.  
I'm making the new table anyway, so you guys had better be happy. 
 
The change in the global parameters does not actually have an affect in the 
front end.  However, it will document the status of the system for 
proterity.  We should implement the version check in the front end as we 
have done for the muon trigger so we are ready for the next time. 
 
        Regards, 
 
        Jonathan</pre>
<!-- Author: Cheng-Ju Lin -->


<!-- Date: Wed Oct 9 07:21:07 2002 -->
<pre>Changed Finder designs to 1 miss in every layer. 
 
Tested 500 events (6500 tracks) with 0011Off400_1M patterns 
- no errors. 
 
Changed hdwd flashramlabels. 
 
</pre>
<!-- Author: Evelyn Thomson -->
<!-- Comment: Fri Nov  1 15;04;26 comment by...Evelyn -->
<pre>1 miss design in Run 152630 and on.</pre>
<!-- Date: Wed Oct 9 17:31:57 2002 -->
<center><a href='/elog/notebooks/xft/Wed_Oct__9_2002_173119.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-380' ></a><a href='/elog/notebooks/xft/Wed_Oct__9_2002_173127.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-382' ></a><a href='/elog/notebooks/xft/Wed_Oct__9_2002_173133.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-384' ></a><a href='/elog/notebooks/xft/Wed_Oct__9_2002_173142.ps'><img src='/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-386' ></a></center>
<!-- Author: Evelyn -->
<!-- Comment: Wed Oct  9 17;33;21 comment by...E -->
<pre>Here is what the monitoring plots look like for the 2400 events
analysed by TrigMon in run 152636!

Reasonably flat.  I don't see any nasty hole in the segment occupancies.</pre>


<!-- Date: Fri Oct 25 10:53:24 2002 -->
<pre>Maksed on 48 wires in COT SL2 sense wire 11</pre>
<!-- Author: e -->


<!-- Date: Tue Oct 29 10:27:25 2002 -->
<table><tr><td><a href=/elog/notebooks/xft/Tue_Oct_29_2002_102721.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-390  align='top'></td><td>SL2 occ slightly higher due to QC s11 masked on</a></td></tr></table>
<!-- Author: Evelyn -->



<!-- Date: Mon Nov 18 12:04:12 2002 -->
<pre>Attempt to reproduce finderboard bunch counter error in no-beam 
condition in RunControl.  RC configuration: 
- L1 calib continuous, varied "Interval 0" from 50 to 6000, 
- tried both "Auto L2 accept" and "Auto L2 ALT". 
 
Ran over 5million L2 accepts and no bunch counter error was 
reported.</pre>
<!-- Author: Cheng-Ju -->


<!-- Date: Mon Nov 18 14:07:49 2002 -->
<pre>Ran short input capture tests (1K events/10 iterations) to look 
for possible stuck XTC bits.   
 
b0cot00 - OK 
b0cot01 - OK 
b0cot02 - OK 
b0cot03 - OK 
b0cot04 - known rare zero (see previous capture test) 
b0cot05 - OK 
b0cot06 - OK 
b0cot07 - OK 
b0cot08 - OK 
b0cot09 - OK 
b0cot10 - known rare zero (see previous capture test) 
b0cot11 - OK 
b0cot12 - OK 
b0cot13 - OK 
b0cot14 - OK 
b0cot15 - OK 
b0cot16 - OK 
b0cot17 - OK 
b0cot18 - OK 
b0cot19 - known rare zero (see previous capture test) 
 
In previous capture test, b0cot08,15,16 also had rare zero 
problems.  Need longer tests (at least 10K events) to see them.</pre>
<!-- Author: Cheng-Ju -->


<!-- Date: Tue Nov 19 11:08:10 2002 -->
<pre>Unmasked SL2 Quad C wire 11 (96-143) 
Masked new dead wire: 
 
Superlayer 2, cell 099, wire 11 
 
</pre>
<!-- Author: Evelyn -->


<!-- Date: Tue Nov 19 11:27:38 2002 -->
<pre>From Jason Nielsen: 
 
P.S.  Using the database browser, I found the change between v2 and v3 of 
the L1_CEM_PT8 trigger bit.  (This change corresponds to the change from 
the 4-layer XFT requirement to the 3-layer requirement.)  If one removes 
run 147565 (which was a trigger test run), then all runs in Young-Kee's 
COT good run list up to and including 147689 use 4 layers, and all the 
runs after 147689 use 3 layers. 
 
 
</pre>
<!-- Author: e -->


<!-- Date: Tue Nov 26 14:50:25 2002 -->
<pre>Masked deadwires for:  SL4 cell 99 s8 and s9. 
 
This should get rid of the dip in track occupancy at phi ~120deg.</pre>
<!-- Author: Cheng-Ju -->


<!-- Date: Mon Dec 2 12:07:10 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-397&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=xft&action=view&page=-397  width='300' align='top'></td><td>4-trk occupancy vs phi now looks flat.  However, there is still a spike at ~150deg for 3-trk occupancy vs phi.   Updating the deadwire list may solve this problem????</a></td></tr></table>
<!-- Author: Cheng-Ju -->


<!-- Date: Mon Dec 2 12:22:48 2002 -->
<pre>According to Bob Wagner and Dave Ambrose, wire SL8 cell 417 s1 
is now alive.  I have removed the mask for this wire in 
the deadwire database. 
</pre>
<!-- Author: Cheng-Ju -->


<!-- Date: Thu Dec 5 15:13:10 2002 -->
<pre>b0xft00 slot 15 (SL 24 serial #16) had no green light 
after a power cycle.   
 
Download status showed that input chip had status 0. 
 
I successfully reprogrammed input SL24. 
Green light back.</pre>
<!-- Author: Evelyn -->


<!-- Date: Thu Dec 19 11:24:00 2002 -->
<pre>Masked on SL2 cell 108 s6 and SL6 cell 69 s11 in the 
deadwire register. 
 
 
Message from Bob and Dave: 
 
Cheng-Ju, 
    As seen in Dave's message below, SL2-108-06 and SL6-069-11, were bad 
long before the November 11 Tracktest run for the TDC, in which both TDC 
channels were ok.  Therefore, I would mask them in the XFT. 
                                                                Bob 
----- Original Message ----- 
From: "David Ambrose" &lt;ambrose@fnal.gov&gt; 
To: "Bob Wagner" &lt;wagner@fnal.gov&gt; 
Sent: Wednesday, December 18, 2002 1:36 PM 
Subject: Re: Masking XFT channels 
 
 
&gt; 
&gt; 
&gt; Both of these channels: 
&gt; 
&gt;    SL2-108 (C,452,06-07-0): #06/06 N = 0.000 (0.000,0.000,0.000) 
&gt;    SL6-069 (A,130,02-10-2): #11/71 N = 0.000 (0.000,0.000,0.000) 
&gt; 
&gt; are dead to calibration (exactly zero hits) over the last two months. 
&gt; 
&gt; The SL2-108 wire was dead in April, had zero-width/bad-DTH in June, and 
&gt; was back to dead in August. 
&gt; 
&gt; The SL6-069 wire had good (N=1.000) calibration occupancy for April 18 and 
&gt; August 28 checks, but was dead for all other calibrations (including other 
&gt; April and August checks) for the past year. 
&gt; 
&gt; 
&gt; - Dave 
&gt; 
&gt; On Wed, 18 Dec 2002, Bob Wagner wrote: 
&gt; 
&gt; &gt; Hi Dave, 
&gt; &gt;     Do you have any more information on XFT masking?  Unless there is 
more 
&gt; &gt; up to date information, they should mask the two channels that are dead 
in 
&gt; &gt; YMon, but alive in the Nov 11 Tracktest. 
&gt; &gt; 
&gt; &gt; *2 108 6 YM occ=0, mul=0; TDC6-7-6:OK 
&gt; &gt; *6 69 11 YM occ=0; TDC2-10-71:OK 
&gt; &gt; 
&gt; &gt;                                                             Bob 
&gt; &gt; 
&gt; 
&gt; 
 
</pre>
<!-- Author: Cheng-Ju -->


<!-- Date: Sun Jan 12 21:57:09 2003 -->
<pre>Got paged Saturday evening about large errors in Linker TrigMon 
plot (finder-linker pixel errors).  After looking at the plots 
and the error log, I did not think the errors were real.  We 
believe the problem has to do with the readout list.  After 
Peter and Greg dropped the readout list, the errors dissappeared.</pre>
<!-- Author: Cheng-Ju -->


<!-- Date: Mon Jan 13 13:57:21 2003 -->
<pre>Got paged this morning after site-wide power outage.  B0xft00, 
01, and 02 failed cold-start.  B0xft00 and 02 problem was 
solved by reprogramming the input chip flash RAM.  B0xft01 
failed cold-start because the technicians swapped the 
tracer fibers after replacing a chip on the tracer this morning.  I reconnected the fibers back to the rightful place.</pre>
<!-- Author: Cheng-Ju -->


<!-- Date: Fri Jan 24 17:08:37 2003 -->
<pre>Did short XTC to finder capture tests (1000events/10 iterations). 
All XTC checked out okay.  Will start finder to linker test now 
and leave it running for a day.</pre>
<!-- Author: Cheng-Ju -->


<!-- Date: Tue Jan 28 19:23:28 2003 -->
<pre>Ran some long finder-linker tests on Saturday.  There were 
some finder-linker pixel and linker track errors.  However, 
no BC error were seen. 
 
*********************************************************************** 
 ERROR! Event 3052 b0xft00 4 b0xft01 4 1b   cell=0	 Finder pixels=     0	 Linker pixels=    3c	 FTLsys=0 
 ERROR! Event 3052 b0xft00 4 b0xft01 4 1b   cell=1	 Finder pixels=   600	 Linker pixels=    3c	 FTLsys=0 
 ERROR! Event 3052 b0xft00 4 b0xft01 4 1b   cell=2	 Finder pixels=     0	 Linker pixels=    3c	 FTLsys=0 
 
 
 ERROR! Event 3052 b0xft01 4  chip 10	Linker track 	 wrd:  1	 tfnd:0	 phi:0	 pt: 7c	 sht:0	 dupl:0	 FTLsys=0 
 ERROR! Event 3052 b0xft01 4  chip 10	 Expect track	 wrd:  1	 tfnd:1	 phi:6	 pt: 26	 sht:0	 dupl:0 
 ERROR! Event 3052 b0xft01 4  chip 11	Linker track 	 wrd:  1	 tfnd:0	 phi:0	 pt: 7c	 sht:0	 dupl:0	 FTLsys=0 
 
</pre>
<!-- Author: Cheng-Ju -->


<!-- Date: Thu Feb 6 11:57:00 2003 -->
<pre>Bob Wagner recovered a COT wire during the January shutdown: 
COT SL 2 cell 108 wire#6.  I have updated the XFT mask accordingly.</pre>
<!-- Author: Cheng-Ju -->


<!-- Date: Wed Feb 26 17:28:44 2003 -->
<pre>Got paged yesterday morning due to problems in b0xft02. 
Problem traced to a blown fuse in finderboard #13 in 
b0xft02.  Replaced fuse.</pre>
<!-- Author: Cheng-Ju -->


<!-- Date: Wed Feb 26 17:33:12 2003 -->
<pre>COT folks disabled 3 axial wires.  I have masked on the 
following wires in the deadwire list:  
-  SL8 cell 3  s0, 
-  SL8 cell 3  s1, 
-  SL8 cell 29 s11. 
 
*********************************************************** 
Message from Bob: 
 
&gt;&gt;Tue Feb 25 19:27:30 
&gt;&gt;Today we fixed several problems in the COT. First we disabled 
&gt;&gt;SL7-Cell86. This was done by attaching all the sense wires to 
&gt;&gt;adjacent potential wires on the high &gt;&gt;voltage daughterboard. 
&gt;&gt;All wires in this cell had been drawing anomolous currents. 
&gt;&gt;This fix was complicated by the fact that a capacitor was 
&gt;&gt;missing on the replacement daughterboard that gave an unusual 
&gt;&gt;diagnostic reading from the capacitance meter which took some 
&gt;&gt;time to understand. 
 
&gt;&gt;Next we disabled SL8_S11_Cell29. Again this was done by 
&gt;&gt;attaching this wire to an adjacent potential wire on the high 
&gt;&gt;voltage daughterboard. Finally we disabled &gt;&gt;SL8_S0_Cell3 and 
&gt;&gt;SL8_S1_Cell3, again on the high voltage daughterboard. Minor 
&gt;&gt;grounding work was also done to reduce noise in the COT. 
</pre>
<!-- Author: Cheng-Ju -->