<!-- Title: Day shift. Tue Oct 24, 2000 -->
<!-- Leader: Al Goshaw -->
<!-- Ace: Ivan Vila -->
<!-- Co1: Rob Napora -->
<!-- Co2: Olga Lobban -->
<!-- Co3: SOS Stan Thompson -->
<!-- Co4: &nbsp; -->
<!-- Co5: &nbsp; -->
<!-- Notes: -->
<pre>Status: 1x8 store in progress 
run plan: 
1. Set up run with trigger commissioning_collisions_mbias4 
2. When Greg/Carla arrive check timming 
3. COT threshold scans and SVX parameter studies 
4 Calor ADMEN timing scan 
5 Test L3 tag 64</pre>


<!-- Date: Tue Oct 24 09:38:56 2000 -->
Rick St. Dennis says we still have a problem with memory 
leak in Oracle -- this can kill run start as can not access 
run number (problem on owl shift). 
Rick will contact Bill Badgett to look at this, setup monitor. 
Seem to be using ~30mbtes of memory when start run ?? 
 
Stil trying to start run with trigger commissioning_collisions_mbias4. 
CLC with narrow timing gata for central pbar-p 
COT thresholds now set at: 300mv SL 1-5; 350mv SL 6; 
				300mv SL 7; 350mv S 
<!-- Author: Al Goshaw -->


<!-- Date: Tue Oct 24 10:01:25 2000 -->
Still trying to get DAQ up and running. 
Note that COT is running at 100% HV on all layers 
but SL4 quadrent D and SL3 quadrent C are off.
<!-- Author: Al Goshaw -->


<!-- Date: Tue Oct 24 10:04:13 2000 -->
<pre>It was noticed at the end of owl shift that 
the system response time was very slow. 
At some point it was noticed that the /data1 
disk was full. As a number of log files, including 
the run control log file, are written here this 
was likely the source of the slowness. 
Some free space was generated an attempts made to run. 
 
- Level 3 failed to partition. Cleaned up level 3 
 
- b0tsi00 failed to partition. Found suspended FER_messenger task 
  rebooted b0tsi00 
 
- b0svt02 failed setup, "Error code 1". 
  Reboot b0svt02, though that may not cure the root cause 
 
- b0xft00 failed to partition. Find FER tasks had not 
  been cleaned up. Also noted XFT expert logged in.... 
  Reboot b0xft00 
 
- b0svt02 fails again in the same manner as above 
  reboot again. 
 
- Event builder could not connect to converter nodes 
  b0l3cl15a, b0l3cl16a. We go ahead and cold start/activate, 
  but immediately get a busy timeout from the SVX. 
  There are no other event builder messages, even on the 
  green screen. Clean up event bulder and try again. 
 
</pre>
<!-- Author: patrick -->


<!-- Date: Tue Oct 24 10:10:25 2000 -->
<pre>Finally begin run successfully</pre>
<!-- Author: patrick :: (run 102272) -->


<!-- Date: Tue Oct 24 10:15:11 2000 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2000&action=view&page=-429&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2000&action=view&page=-429  width='250' align='top'></td><td>Integrated and Instantaneous Luminosity</a></td></tr></table>
<!-- Author: rvidal -->


<!-- Date: Tue Oct 24 10:28:06 2000 -->
STARTED RUN: trigger commissioning_collisions_mbias4 
	     Did not run COT startup script 
	    COT at 350mv all SL2C, SL3C, SL7c at 300mv 
Plans is to run until timining experts arrive, then 
give stop run give DAQ control to them.  
<!-- Author: Al Goshaw :: (run 102272) -->


<!-- Date: Tue Oct 24 10:35:26 2000 -->
Ended run 102272    with ~114K events 
Start timing stuides -- Greg, Carla, Ming
<!-- Author: Al Goshaw :: (run 102272) -->


<!-- Date: Tue Oct 24 11:06:58 2000 -->
With shift crew's permission, am rebooting b0svt0[126], to 
load version of spy buffer polling code that removes some 
redundant buffer data, so that relevant information is not 
dropped from the end of the sample.  I will take a short 
stand-alone run to make sure nothing fails, then give it 
back to the shift crew.  Estimate 15 minutes. 
<p>  
<!-- Author: Bill Ashmanskas -->
<!-- Comment: Tue Oct 24 11;19;48 comment by...Bill -->
Success ... back to Ace (13 minutes!)



<!-- Date: Tue Oct 24 11:27:58 2000 -->
<pre><pre> 
OK here is the deal on the scalers, in particular the 
relationship between the simple sum of prescaled FRED 
trigger counts and the number of L1A sent by the TS. 
 
In the limit of no deadtime AND no overlap of prescaled 
FRED triggers the simple sum of the prescaled FRED triggers 
should be EQUAL to the number of L1A sent by the TS 
for non-Myron mode.  In Myron mode the TS will send 
4 L1A for each prescaled FRED trigger count.  (This 
paragraph supercedes previous entries by me in this 
space). 
 
All of the FRED trigger counts (preFRED inputs, FRED 
triggers and prescaled triggers) are gated by GLIVE. 
Among other things GLIVE requires at least ONE free 
L2 buffer.  Likewise the TS L1A can only be sent when 
there is at least ONE free L2 buffer. 
 
In non-Myron mode, which is how we expect to be running 
most of the time, and for which we designed the way 
the livetime and deadtime accounting is handled, the 
relationship between TS L1A and the prescaled FRED 
counts should be as stated above EVEN if there is 
deadtime. 
 
In Myron mode, which is not how we plan to spend most 
of our time running, things are different.  In order 
for Myron mode to be useful, the TS requires ALL FOUR 
L2 buffers to be free before accepting a trigger from 
FRED.  This is a condition which clearly does not 
exist for non-Myron mode. 
 
However, it finally occurred to me, and I have confirmed 
this with Andrew Martin, that even in Myron mode, 
GLIVE is still defined by whether there is at least 
ONE L2 buffer free.  This has the effect that the  
prescaled FRED counts can continue to accumulate 
(when GLIVE is true) even though the TS has to wait 
for the reminder of the four events taken in a row to 
be read out in order to free the remaining L2 buffers. 
 
In the limit of very small deadtime, it should be that 
the relationship between the prescaled FRED rates and 
the TS L1A would be given as above.  However the relationship 
clearly changes (in a way I have not yet had time 
to sit down and give an alogorithm for; I will add 
a note when I come up with something) such that the 
sum of the prescaled FRED counts could indeed be larger 
than the TS L1A counts in Myron mode, as odd as that 
first seemed. 
 
Yes we should have realized this sooner.  No we will not 
make changes to the firmware on the fly now to redefine 
GLIVE for Myron mode.  Yes we may revisit this discussion 
later. 
 
Finally I would like to test my theory that there is 
no other confusion, by having a non-Myron mode run 
and the chance to look at the DAQMON for the scalers 
to see that the expectations hold. 
 
</pre> 
</pre>
<!-- Author: Michael Schmidt -->
<!-- Comment: Tue Oct 24 12;25;47 comment by...Michael Schmidt -->
<pre><pre>

At the risk of being yelled at for writing too much in the log
book, I would like to add a couple of comments:  

1) the passage above should read: "Yes I should have realized
this sooner"

2) I believe the true measure of the actual livetime when
running in Myron mode is: TS L1A count/(4 * sum of prescaled
FRED trigger counts).

3) I do not think there is a trivial way to convert from the
reported livetime to the actual livetime because it can
very well be that the readout deadtime reported in Myron
mode (which comes from the first of four events to be readout)
need not be the same as that associated with the remaining
events.

</pre></pre>
<!-- Date: Tue Oct 24 11:51:54 2000 -->
Greg and Carla continuing timing tests to sync 
in CLC, cal L1 triggers and cal ADMEM. Greg will 
enter detailed description of this.
<!-- Author: Al Goshaw -->



<!-- Date: Tue Oct 24 12:31:07 2000 -->
Bill Badgett entering new CLC and calorimeter timing 
in data base. Will run with these, and Greg/Carla 
will verify that timing chamges are OK. 
 
One of the database machines crashed -- looking for expert. 
<!-- Author: Al Goshaw -->
<!-- Comment: Tue Oct 24 12;45;15 comment by...W.Badgett -->
<pre>CLC and Calorimeter ADMEMs pipelinelength reduced by one count.</pre>
<!-- Date: Tue Oct 24 12:44:21 2000 -->
<pre>b0dau35 crashed, taking production database with it. 
 
Umesh was not available, so we rebooted the machine -- it  
was waiting for on "ok" to reboot. 
 
The Oracle production database seems to have recovered  
successfully.   However, the ResMgr seems to have frozen  
up & I had to force a restart.</pre>
<!-- Author: W.Badgett -->



<!-- Date: Tue Oct 24 12:50:48 2000 -->
<pre>Run 102281 - Running with the new trigger and cal and clc 
admem settings loaded to Front-end from database. 
This is a checkout run. 
More details on these changes shortly. 
Myron Mode 
SEVB 
Trigger table is commissioning cosmic[1,58] 
--------------------------------------------------- 
Calorimeter and CLC crates only. 
CLC is showing BC mismatches - we don't yet know why. 
------------------------------------------------------- 
Carla, Rick and Ming will do some offline analysis for  
trigger, cal and clc to verify new timings. 
-------------------------------------------------------- 
End after 15,000 events</pre>
<!-- Author: Greg F. :: (run 102281) -->
<!-- Comment: Tue Oct 24 13;21;46 comment by...Greg (for Carla)  -->
,<pre>
Only on plug crate made it into this run but the 
data look OK so far. Cal and CLC triggers and data
are all aligned.
</pre>
<!-- Date: Tue Oct 24 12:51:17 2000 -->
Taking short run to check new timing settings 
using data base. Experts (Greg/Carla) will check 
this offline.
<!-- Author: Al Goshaw :: (run 102281 ) -->


<!-- Date: Tue Oct 24 13:10:17 2000 -->
During the coldstart transition we get the following error. We  
restart runcontrol. 
 
 
java.lang.NullPointerException 
        at rc.messenger.generateReadoutCMess(messenger.java:658) 
        at rc.messenger.sendReadoutLists(messenger.java(Compiled Code)) 
        at rc.stateManager$SendReadoutListAction.execute(stateManager.java:873) 
        at rc.stateManager$ConfigMessageSender.execute(stateManager.java:1070) 
        at rc.ActionList.execute(ActionList.java:36) 
        at rc.FiniteStateMachine.processMoreActions(FiniteStateMachine.java:209) 
        at rc.FiniteStateMachine.access$2(FiniteStateMachine.java:201) 
        at rc.FiniteStateMachine$WaitForAck.run(FiniteStateMachine.java:724) 
<!-- Author: Ivan vila -->



<!-- Date: Tue Oct 24 13:30:29 2000 -->
Start series of COT Threshold scans. 
First one is baseline settings using script setup previously. 
==> run ASDQ thresholds to 1000mv, then set to: 
	SL 1-5, 7 at 300mv; SL 6,8 at 350mv 
Also silicon setting baseline parameters for this run.
<!-- Author: Al Goshaw :: (run 102285) -->


<!-- Date: Tue Oct 24 13:48:50 2000 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2000&action=view&page=-430&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2000&action=view&page=-430  width='250' align='top'></td><td>This is run 102285 fred's before prescale</a></td></tr></table>
<!-- Author: dan -->


<!-- Date: Tue Oct 24 13:49:11 2000 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2000&action=view&page=-431&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2000&action=view&page=-431  width='250' align='top'></td><td>This is the after prescale for run 102285</a></td></tr></table>
<!-- Author: dan -->


<!-- Date: Tue Oct 24 13:55:09 2000 -->
Noted that calorimeter trigger rates very high 
in last run. Also Sum Et should have been masked off 
and was Not. Do not understand this. Investigating
<!-- Author: Al Goshaw -->


<!-- Date: Tue Oct 24 14:01:37 2000 -->
For next run will delete a list of COT TDC on 
request of Morris B. and Bob W. See log entry. 
  
<!-- Author: Al Goshaw -->


<!-- Date: Tue Oct 24 14:10:28 2000 -->
<pre>Morris gave us a list of TDC's to remove from readout. 
This is not horridly slow to do....  
 
The list is : 
b0cot01 : slot 2 
b0cot05 : slot 7,8,10,11,12 
b0cot08 : slot 6 
b0cot16 : slot 12</pre>
<!-- Author: dan :: (run 102287) -->


<!-- Date: Tue Oct 24 14:10:57 2000 -->
Start second COT threshold scan: 
	SL1-5,7 at 250 mv;   SL6,8 at 350mv 
Also change SVX parameters: Steve Nahn will enter into log 
these changes.  
<!-- Author: Al Goshaw :: (run 102287) -->
<!-- Comment: Tue Oct 24 16;48;32 comment by...SCN -->
Summary of Runs for Silicon Scan so far is <a href=/cgi/elog/elog.pl?nb=2000&action=view&page=200&anchor=16:46:36 target=_top>here</a>
<!-- Date: Tue Oct 24 14:15:27 2000 -->
<pre>The first run of the cot scan will use the default script "cotdac" which sets SL  1-5,7 @ 300mV SL8 @ 350mV. 
 
The scan starts with run # of 102287, we had a done timeout pcal04,  
we rebooted crate and brought it back into the run by halting the run - then recovering. 
 </pre>
<!-- Author: dan :: (run 102287) -->
<!-- Comment: Tue Oct 24 14;23;30 comment by...dan -->
b0clc00 have numerous bunchcounter errors. 


<!-- Date: Tue Oct 24 14:25:39 2000 -->
<pre>         ATN (mV)    DTH (mV)    TRE (mV)    TRO (mV)    QEN (mV)    QDR (mV)           ----------  ----------  ----------  ----------  ----------  ---------- 
 SL1-A:  01 = +0000  02 = +0249  03 = +2000  04 = +2000  05 = +3000  06 = +0000 
 SL1-B:  01 = +0000  02 = +0249  03 = +2000  04 = +2000  05 = +3000  06 = +0000 
 SL1-C:  01 = +0000  02 = +0249  03 = +2000  04 = +2000  05 = +3000  06 = +0000 
 SL1-D:  01 = +0000  02 = +0249  03 = +2000  04 = +2000  05 = +3000  06 = +0000 
 SL2-A:  01 = +0000  02 = +0249  03 = +2000  04 = +2000  05 = +3000  06 = +0000 
 SL2-B:  01 = +0000  02 = +0249  03 = +2000  04 = +2000  05 = +3000  06 = +0000 
 SL2-C:  01 = +0000  02 = +0249  03 = +2000  04 = +2000  05 = +3000  06 = +0000 
 SL2-D:  01 = +0000  02 = +0249  03 = +2000  04 = +2000  05 = +3000  06 = +0000 
 SL3-A:  07 = +0000  08 = +0249  09 = +2000  10 = +2000  11 = +3000  12 = +0000 
 SL3-B:  07 = +0000  08 = +0249  09 = +2000  10 = +2000  11 = +3000  12 = +0000 
 SL3-C:  07 = +0000  08 = +0249  09 = +2000  10 = +2000  11 = +3000  12 = +0000 
 SL3-D:  07 = +0000  08 = +0249  09 = +2000  10 = +2000  11 = +3000  12 = +0000 
 SL4-A:  07 = +0000  08 = +0249  09 = +2000  10 = +2000  11 = +3000  12 = +0000 
 SL4-B:  07 = +0000  08 = +0249  09 = +2000  10 = +2000  11 = +3000  12 = +0000 
 SL4-C:  07 = +0000  08 = +0249  09 = +2000  10 = +2000  11 = +3000  12 = +0000 
 SL4-D:  07 = +0000  08 = +0249  09 = +2000  10 = +2000  11 = +3000  12 = +0000 
 SL5-A:  13 = +0000  14 = +0249  15 = +2000  16 = +2000  17 = +3000  18 = +0000 
 SL5-B:  13 = +0000  14 = +0249  15 = +2000  16 = +2000  17 = +3000  18 = +0000 
 SL5-C:  13 = +0000  14 = +0249  15 = +2000  16 = +2000  17 = +3000  18 = +0000 
 SL5-D:  13 = +0000  14 = +0249  15 = +2000  16 = +2000  17 = +3000  18 = +0000 
 SL6-A:  13 = +0000  14 = +0349  15 = +2000  16 = +2000  17 = +3000  18 = +0000 
 SL6-B:  13 = +0000  14 = +0349  15 = +2000  16 = +2000  17 = +3000  18 = +0000 
 SL6-C:  13 = +0000  14 = +0349  15 = +2000  16 = +2000  17 = +3000  18 = +0000 
 SL6-D:  13 = +0000  14 = +0349  15 = +2000  16 = +2000  17 = +3000  18 = +0000 
 SL7-A:  19 = +0000  20 = +0249  21 = +2000  22 = +2000  23 = +3000  24 = +0000 
 SL7-B:  19 = +0000  20 = +0249  21 = +2000  22 = +2000  23 = +3000  24 = +0000 
 SL7-C:  19 = +0000  20 = +0249  21 = +2000  22 = +2000  23 = +3000  24 = +0000 
 SL7-D:  19 = +0000  20 = +0249  21 = +2000  22 = +2000  23 = +3000  24 = +0000 
 SL8-A:  19 = +0000  20 = +0349  21 = +2000  22 = +2000  23 = +3000  24 = +0000 
 SL8-B:  19 = +0000  20 = +0349  21 = +2000  22 = +2000  23 = +3000  24 = +0000 
 SL8-C:  19 = +0000  20 = +0349  21 = +2000  22 = +2000  23 = +3000  24 = +0000 
 SL8-D:  19 = +0000  20 = +0349  21 = +2000  22 = +2000  23 = +3000  24 = +0000           </pre>
<!-- Author: dan :: (run 102288) -->


<!-- Date: Tue Oct 24 14:28:57 2000 -->
The current run 102288 is with the 8 TDC removed 
(see above list) and second set of COT ASDQ parameters 
SL 1-5,7 at 250 mv; SL6,8 at 350 mv 
Also second set of silicon parameter scan: Steve Nahn 
will enter details
<!-- Author: Al Goshaw :: (run 102288) -->


<!-- Date: Tue Oct 24 14:30:10 2000 -->
<br><b>Masked Trigger Tower:</b> 
<br>Masked trigger tower (eta,phi)=(9,10) due to a hot PMT 
(discharging?).  The PMT causing the problems appears to be. 
10W-5L.  The new mask should take effect beginning after run 
102288.
<!-- Author: R.J. Tesarek -->


<!-- Date: Tue Oct 24 14:39:19 2000 -->
<pre>Last COT scan : 
         ATN (mV)    DTH (mV)    TRE (mV)    TRO (mV)    QEN (mV)    QDR (mV)           ----------  ----------  ----------  ----------  ----------  ---------- 
 SL1-A:  01 = +0000  02 = +0249  03 = +2000  04 = +2000  05 = +3000  06 = +0000 
 SL1-B:  01 = +0000  02 = +0249  03 = +2000  04 = +2000  05 = +3000  06 = +0000 
 SL1-C:  01 = +0000  02 = +0249  03 = +2000  04 = +2000  05 = +3000  06 = +0000 
 SL1-D:  01 = +0000  02 = +0249  03 = +2000  04 = +2000  05 = +3000  06 = +0000 
 SL2-A:  01 = +0000  02 = +0249  03 = +2000  04 = +2000  05 = +3000  06 = +0000 
 SL2-B:  01 = +0000  02 = +0249  03 = +2000  04 = +2000  05 = +3000  06 = +0000 
 SL2-C:  01 = +0000  02 = +0249  03 = +2000  04 = +2000  05 = +3000  06 = +0000 
 SL2-D:  01 = +0000  02 = +0249  03 = +2000  04 = +2000  05 = +3000  06 = +0000 
 SL3-A:  07 = +0000  08 = +0249  09 = +2000  10 = +2000  11 = +3000  12 = +0000 
 SL3-B:  07 = +0000  08 = +0249  09 = +2000  10 = +2000  11 = +3000  12 = +0000 
 SL3-C:  07 = +0000  08 = +0249  09 = +2000  10 = +2000  11 = +3000  12 = +0000 
 SL3-D:  07 = +0000  08 = +0249  09 = +2000  10 = +2000  11 = +3000  12 = +0000 
 SL4-A:  07 = +0000  08 = +0249  09 = +2000  10 = +2000  11 = +3000  12 = +0000 
 SL4-B:  07 = +0000  08 = +0249  09 = +2000  10 = +2000  11 = +3000  12 = +0000 
 SL4-C:  07 = +0000  08 = +0249  09 = +2000  10 = +2000  11 = +3000  12 = +0000 
 SL4-D:  07 = +0000  08 = +0249  09 = +2000  10 = +2000  11 = +3000  12 = +0000 
 SL5-A:  13 = +0000  14 = +0249  15 = +2000  16 = +2000  17 = +3000  18 = +0000 
 SL5-B:  13 = +0000  14 = +0249  15 = +2000  16 = +2000  17 = +3000  18 = +0000 
 SL5-C:  13 = +0000  14 = +0249  15 = +2000  16 = +2000  17 = +3000  18 = +0000 
 SL5-D:  13 = +0000  14 = +0249  15 = +2000  16 = +2000  17 = +3000  18 = +0000 
 SL6-A:  13 = +0000  14 = +0349  15 = +2000  16 = +2000  17 = +3000  18 = +0000 
 SL6-B:  13 = +0000  14 = +0249  15 = +2000  16 = +2000  17 = +3000  18 = +0000 
 SL6-C:  13 = +0000  14 = +0249  15 = +2000  16 = +2000  17 = +3000  18 = +0000 
 SL6-D:  13 = +0000  14 = +0249  15 = +2000  16 = +2000  17 = +3000  18 = +0000 
 SL7-A:  19 = +0000  20 = +0249  21 = +2000  22 = +2000  23 = +3000  24 = +0000 
 SL7-B:  19 = +0000  20 = +0249  21 = +2000  22 = +2000  23 = +3000  24 = +0000 
 SL7-C:  19 = +0000  20 = +0249  21 = +2000  22 = +2000  23 = +3000  24 = +0000 
 SL7-D:  19 = +0000  20 = +0249  21 = +2000  22 = +2000  23 = +3000  24 = +0000 
 SL8-A:  19 = +0000  20 = +0349  21 = +2000  22 = +2000  23 = +3000  24 = +0000 
 SL8-B:  19 = +0000  20 = +0349  21 = +2000  22 = +2000  23 = +3000  24 = +0000 
 SL8-C:  19 = +0000  20 = +0349  21 = +2000  22 = +2000  23 = +3000  24 = +0000 
 SL8-D:  19 = +0000  20 = +0349  21 = +2000  22 = +2000  23 = +3000  24 = +0000              
</pre>
<!-- Author: dan :: (run 102289) -->


<!-- Date: Tue Oct 24 14:55:10 2000 -->
Start 3rd run for COT DAQ and silcon parameter scans. 
COT ASDQ thresholds at SL 1-5,7 at 250mv; SL6A,8 at 350 mv 
			SL6B-D at 250 mv 
All these 3 scans have been done using trigger 
	commissioning_collisions_mbias4 
		min bias / 4 
		zero bias/ 1000,000 
		2 jet Et >2 
		1 plug tower Et >2 
		1 plug photon Et >2 
		sum Et > 10 ??? should be masked out but get rate 
		2 CMU deltaphi>120 
Still do not understand observed change in rates with above.  
<!-- Author: Al Goshaw :: (run 102289) -->


<!-- Date: Tue Oct 24 14:59:56 2000 -->
<table><tr><td><a href=/elog/notebooks/2000/Tue_Oct_24_2000_Day.145926.ps align=top><img src=/elog/gifs/ghost64.gif  width='56' align='top'></td><td>A nice event from this mornings run...</a></td></tr></table>
<!-- Author: Frank Chlebana -->


<!-- Date: Tue Oct 24 15:01:13 2000 -->
<table><tr><td><a href=/elog/notebooks/2000/Tue_Oct_24_2000_Day.150052.ps align=top><img src=/elog/gifs/ghost64.gif  width='56' align='top'></td><td>Same event different view</a></td></tr></table>
<!-- Author: Frank Chlebana -->


<!-- Date: Tue Oct 24 15:01:58 2000 -->
<table><tr><td><a href=/elog/notebooks/2000/Tue_Oct_24_2000_Day.150145.ps align=top><img src=/elog/gifs/ghost64.gif  width='56' align='top'></td><td>same event yet another view...</a></td></tr></table>
<!-- Author: Frank Chlebana -->


<!-- Date: Tue Oct 24 15:03:23 2000 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2000&action=view&page=-438&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2000&action=view&page=-438  width='250' align='top'></td><td>same event...</a></td></tr></table>
<!-- Author: Frank Chlebana -->


<!-- Date: Tue Oct 24 15:24:27 2000 -->
<pre>Greg Hijacks DAQ to test Pipeline depths in the L1 Trigger 
system.  Most systems dumped for this short test, except 
CAL, CLC, and L1 TRIG</pre>
<!-- Author: Steve and Dan and Ivan :: (run 102293) -->


<!-- Date: Tue Oct 24 15:25:30 2000 -->
Further changes in Calorimeter timing. Will try 
short run to check this.  
 
Then short run checking new trigger: 
	Commissioning_collisions_lum1 
		min bias/4 
		zero bias/100000 
		2 jet Et> 4 GeV /10 
		1 plug tower Et >4 Gev/ 10 
		1 plug photon Et >4 Gev/ 10 
		sum Et > 10 GeV /10 
		2 CMU delta phi >120/ 10
<!-- Author: Al Goshaw -->


<!-- Date: Tue Oct 24 15:38:00 2000 -->
<font color=red>Shift Summary: </font><pre>Major activities of shift: 
	1. Carla and Greg worked timing of CLC, 
	   calorimeter triggers and ADMEM's. 
	   Ended shift with them checking the 
	   data to verify cahnges. 
	2. Carried out COT and SVX parameter scans 
	   as specified by experts: used commissioning_ 
	   collisions_mbias4 trigger. One puzzle is that 
           this trigger is now dominated by calorimeter 
	   triggers (higher rates than MB/4). Did not  
	   understand this change. 
	   COT scans of ASDQ thresholds 
		1. SL 1-5, 7 at 300mv  SL 6,8 at 350mv 
		2. Sl 1-5, 7 at 250 mv SL 6,8 at 350 mv 
		3. SL 1-5, 7 at 250 mv  SL 6A, 8 at 350 mv 
				Sl 6B-D at 250 mv 
	3. Plan was to repeatr COT scans with pure MB trigger 
		commissioning_min_bias (1,58) 
</pre> 
<br><b>End of Shift Numbers</b>
<table><tr><td width=60% align=left>
<b>CDF Run II <p></b>                       
<pre>
Runs                   102283 - 102293
Delivered Luminosity   OK  pb-1
Acquired Luminosity    Ok  pb-1
Efficiency             OK
   
</td></tr></table></pre>
<!-- Author: Al Goshaw -->


<!-- Date: Tue Oct 24 16:06:46 2000 -->
<pre>Taking Hadron TDC crate to swap TDCs...</pre><font color=red><cite>(Entry started on Tue Oct 24 16:06:42 2000)</cite></font>
<!-- Author: Ron Moore -->