<!-- Title: Eve shift. Fri Mar 30, 2001 -->
<!-- SciCo: Alan Sill -->
<!-- DAQAce: Ivan Vila -->
<!-- MonAce: Francesco Palmonari -->
<!-- CO: Will Bell -->
<!-- OpManager: Seve Hahn -->
<!-- Notes: -->
<pre>Plan: 
Do all calibrations, as possible.  Test YKK's new trigger
table(s), see below.
Follow with L3 torture test  with BEAMGAS_COSMIC_MAR28[1,98],
which will occupy most if not all of remainder of shift.</pre>


<!-- Date: Fri Mar 30 16:08:22 2001 -->
Hadron TDC crate returned to service.  TDC cabled for wedges 4-7 only.  Please include in DAQ if possible.
<!-- Author: Jonathan Lewis -->


<!-- Date: Fri Mar 30 16:13:49 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030>
<pre>created a trigger table  
	INTEGRATION_MINBIAS_CAL_TRIGGERS_v-2 
for Peter Wilson and Greg Field to test timining between 
CLC and calorimeter triggers. 
The table contains 
 
	------------------------------------------ 
	Description	Threshold	Prescale 
	------------------------------------------ 
	Minimum bias (CLC E*W)			 1 
	Sum Et > 50		 		 1 
	Sum Et > 50 * Minimum bias		 1 
	Central Jet Et > 20			10	  
	Central Jet Et > 20 * Minimum bias	10 
	Plug Jet > 20				 1 
	Plug Jet > 20 * Minimum bias		 1 
	------------------------------------------ 
Please test this table with proton bem and let ykk 
(ykkim@fnal.gov, x5007) know the rate of each trigger since 
the CLC trigger rate may need to have a large prescale  
factor depending on the beam condition.
</pre></td></tr></td></table>
<!-- Author: Young-Kee -->


<!-- Date: Fri Mar 30 16:47:00 2001 -->
<pre>Made the LED_ALL configuration file "invisible". The only option the ACES have now is to use ACE_LED_ALL. One needs to go into 
"expert mpde" to do that.</pre>
<!-- Author: Vaia, Bill, Ivan -->


<!-- Date: Fri Mar 30 17:02:29 2001 -->
<pre>/fp/ 
 
CURRENT SLOW CONTROL STATUS: 
 
-> SILICON RE-WIRING RTDs  
  (THAT HAD GENERATED LOW DP ALARM ON ISL EAST -> acknowledge) 
	  
-> COT/CMU/CMX/CMP/BMU in STANDBY 
 
-> WORK ON VOLTMAN IS FINISHED  
   (NOTE FOR THE FUTURE: EXPERT INSTRUCTED US TO WAIT AT LEAST  
    15 MINUTES BEFORE TO CONFIRM AN ALARM BECAUSE THIS TIME SCALE 
    IS ABOUT THE REFRESH TIME OF VOLTMAN AND SOME TIMES ALARMS     
    ARE GENERATED ONLY FROM BAD COMUNICATIONS)  
 
</pre>
<!-- Author: F.Palmonari -->


<!-- Date: Fri Mar 30 17:13:25 2001 -->
<pre>Recent files in the /data1/consumer/results/TrigMon area: 
 
28      105505CalTrigger_Summary.txt 
28      107866CalTrigger_Summary.txt 
30      107313CalTrigger_Summary.txt 
30      107886CalTrigger_Summary.txt 
31      110067CalTrigger_Summary.txt 
33      101500CalTrigger_Summary.txt 
33      109038CalTrigger_Summary.txt 
33      110014CalTrigger_Summary.txt 
34      110070CalTrigger_Summary.txt 
36      101547CalTrigger_Summary.txt 
38      108709CalTrigger_Summary.txt 
39      106357CalTrigger_Summary.txt 
40      107757CalTrigger_Summary.txt 
41      107604CalTrigger_Summary.txt 
41      107606CalTrigger_Summary.txt 
41      109588CalTrigger_Summary.txt 
42      107759CalTrigger_Summary.txt 
42      107811CalTrigger_Summary.txt 
43      101559CalTrigger_Summary.txt 
43      101587CalTrigger_Summary.txt 
43      105406CalTrigger_Summary.txt 
45      101560CalTrigger_Summary.txt 
46      107758CalTrigger_Summary.txt 
53      108672CalTrigger_Summary.txt 
55      108708XFTTrigger_Summary.txt 
56      109817XFTTrigger_Summary.txt 
64      108103CalTrigger_Summary.txt 
69      101545CalTrigger_Summary.txt 
70      107776CalTrigger_Summary.txt 
83      107744CalTrigger_Summary.txt 
83      109229CalTrigger_Summary.txt 
91      107807CalTrigger_Summary.txt 
97      108602XFTTrigger_Summary.txt 
106     103568CalTrigger_Summary.txt 
110     108709XFTTrigger_Summary.txt 
115     107651CalTrigger_Summary.txt 
116     108710CalTrigger_Summary.txt 
123     101586CalTrigger_Summary.txt 
127     107775CalTrigger_Summary.txt 
163     101502CalTrigger_Summary.txt 
164     101501CalTrigger_Summary.txt 
282     101591CalTrigger_Summary.txt 
385     101480CalTrigger_Summary.txt 
 
Clearly the TrigMon output, essentially all of which consists of 
the following message, has swollen a lot lately... there are now 
14 Gb of such stuff... 
 
 -- event number =1 eta = 16, phi = 0 
clustering_word_sim[word=0][card=0][block=0] = 0 --   clustering_word_Real[word=0][card=0][block=0] = fc00fc00 
 
Can someone look at why this is happening, please?</pre>
<!-- Author: AFS -->
<!-- Comment: Fri Mar 30 17;16;54 comment by...AFS -->
<pre>Actually 12 Gb:

33 /data1/consumer/results % du -hsm * | sort -n
1       led.root
1       Monitor1.tcl
1       PhysMon
54      Stage0
86      LumMon
890     XMon
945     YMon
12283   TrigMon
</pre>


<!-- Date: Fri Mar 30 17:35:47 2001 -->
<pre>XTRP fails coldstart transition.... Messenger process suspended. 
Reboot XTRP.</pre>
<!-- Author: Peter Wilson -->


<!-- Date: Fri Mar 30 17:50:32 2001 -->
<pre>Testing new RC (devel) with DIRAC track inputs masked for  
wedges without XTRP boards.  All L1CAL, L2CAL, East PCAL, XTRP.</pre>
<!-- Author: Peter and Greg :: (run 110753) -->
<!-- Comment: Fri Mar 30 18;18;05 comment by...Peter -->
<pre>Had trouble getting events to disk.  End run after 10000 events.</pre>
<!-- Date: Fri Mar 30 18:02:38 2001 -->
<pre>Calibrations do not seem to be making it into the database. 
Ace and Vaia are looking into it. 
 
Also, ypbind seemed to be taking 98% of the cpu on b0dap29. 
Called Jim Patrick to ask that he look at it. 
 
Possibly related or not, it is also true that Will is having 
trouble printing from b0dap50.</pre>
<!-- Author: AFS -->
<!-- Comment: Fri Mar 30 18;05;15 comment by...patrick -->
ypbind on b0dap29 corrected.



<!-- Date: Fri Mar 30 18:19:03 2001 -->
<pre>Start new run including Central cal and XFT crates.</pre>
<!-- Author: Peter and Greg :: (run 110758) -->
<!-- Comment: Fri Mar 30 18;21;22 comment by...Peter -->
<pre>Done timeout from ccal00, 01, 02.  Removed from run and starting 
again.</pre>
<!-- Date: Fri Mar 30 18:19:37 2001 -->
<pre>Trying to do LED and Xenon calibrations. 
The LED calibration we did was done with the "old" RC. 
For the Xenon we tried first the "New" RC and then switched to 
the "old" (Run 110752) since in the "new" the run number is set to -1. 
In all calibrations with either "old" or "new" RC we get 
in the log file: 
Abnormal Termination caused by signal: 15 Framework abort. 
The QIEPED calibration (run 110748) we did right before the 
led and Xenon runs worked fine and the data went in data base. 
Tony is looking into the "abort job" problem and Bill is trying 
to fix the run number problem in "new" RC. </pre>
<!-- Author: Ivan, Vaia :: (run 110752) -->



<!-- Date: Fri Mar 30 18:39:54 2001 -->
New Xenon Calibration after Tony fixes on the CSL  
It seems not work again,i.e, no table shows up in 
the database. I checked for any differences between 
the consumer logfiles before and after the fix, they 
are identical.
<!-- Author: Ivan :: (run 110768) -->


<!-- Date: Fri Mar 30 18:42:53 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre> 
Created a trigger table for the end of 1x8 collisions. 
Trigger table name : 1x8_END_1_v-2 
The information can be found from 
 
http://www-cdf.fnal.gov/internal/cdfoperations/trigger_table_1x8_end.html 
</pre></td></tr></td></table>
<!-- Author: Young-Kee -->


<!-- Date: Fri Mar 30 18:53:13 2001 -->
<pre>Tony thinks that we have some network problems connecting 
with the consumer server, this thing can translate with 
the problems transfering tables to the data base. </pre>
<!-- Author: Ivan  -->


<!-- Date: Fri Mar 30 19:02:18 2001 -->
It is clear that we have extensive network problems on the 
online machines.  (b0dap29, an exception, is actually on the 
offline network according to Steve H.; Will notes that 25 is 
also OK but the b0dap5x machines all seem to be affected.) 
 
Calls to both of the online computer experts and to the Run Control pager went unanswered.  Now trying to reach Jeff Schmidt.
<!-- Author: Alan Sill -->
<!-- Comment: Fri Mar 30 19;10;36 comment by...Arnd -->
That's not completely true ... I immediately went to the control room (answering the RC pager), but I couldn't do anything about the problem and told people to wait for the network experts.



<!-- Comment: Fri Mar 30 22;07;22 comment by...patrick -->
b0dap29 is still on the online network. However
its configuration was not changed like the
b0dap5X and 6X machines were.
<!-- Date: Fri Mar 30 19:10:40 2001 -->
<pre>We tryed new Qie Calibration to check the consumer 
behavior, It seems that again there are problems  
communication with the consumer server...Tony 
suggest to wait until the network problem is fixed. 
 
The experts are working of that.		</pre>
<!-- Author: Ivan -->
<!-- Comment: Sat Mar 31 18;54;13 comment by...Tony Vaiciulis -->
<pre>clarification: I think the consumers had no problem
communicating with the CSL. After receiving a begin-of-run event
the consumer apparently was trying to make some network
connection (to a database?) which it could not do. Therefore
the consumer never requested any events except the begin-of-run,
which it received.
</pre>
<!-- Date: Fri Mar 30 19:40:19 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre> 
Created a trigger table for the beginning of 1x8 collisions 
1x8_BEGIN_1_v-1 
 
The information can be found from 
http://www-cdf.fnal.gov/internal/cdfoperations/trigger_table_1x8_begin.html 
</pre></td></tr></td></table>
<!-- Author: Young-Kee -->


<!-- Date: Fri Mar 30 19:45:49 2001 -->
Network is still crisped in various ways as mentioned above, 
preventing us from logging data but leaving us alive in other  
ways, so we decide to proceed with testing the above trigger tables. 
Presently have coalseced beam at 150 GeV in the machine.  Will start 
by testing INTEGRATION_MINBIAS_CAL_TRIGGERS_v-2
<!-- Author: AFS -->
<!-- Comment: Fri Mar 30 20;19;00 comment by...AFS -->
(Failed due to hardware database problem, see below.)
<!-- Date: Fri Mar 30 19:49:22 2001 -->
<pre>Getting this error when connection to database: 
 
2001.03.30 19:48:44 java.sql.SQLException: ORA-00257: archiver  
error. Connect internal only, until freed. 
 
Yikes! 
 
 
</pre>
<!-- Author: W.Badgett -->
<!-- Comment: Fri Mar 30 19;52;40 comment by...W.Badgett -->
<pre>Found that the archive log disk had filled:

  b0dau35> df -k .
Filesystem            kbytes    used   avail capacity  Mounted on
/dev/vx/dsk/oradg/archlogvol
                     7340032 7335122    4910   100%    /dbs8
</pre>


<!-- Date: Fri Mar 30 19:59:19 2001 -->
Waiting to have fixed our network problem and 
hardware database.  
<!-- Author: Ivan -->


<!-- Date: Fri Mar 30 20:12:42 2001 -->
<pre>The physical disks of b0dau35 volume /dev/vx/dsk/oradg/archlogvol 
had some spare space, so I increased the volume size  
by 2Gb.   This should keep us sitting pretty for a while. 
</pre>
<!-- Author: W.Badgett -->



<!-- Date: Fri Mar 30 20:21:18 2001 -->
Have placed official help call through FNAL help desk. 
E-mail sent with description of problem.
<!-- Author: AFS -->
<!-- Comment: Fri Mar 30 20;32;07 comment by...AFS -->
Phil Demar arrives to look at network problem.


<!-- Date: Fri Mar 30 20:42:50 2001 -->
Approx. after 20min. of starting the consumer the calibration run 110779 appears in the <a href="http://cdfdbb.fnal.gov:8520/cdfr2/databases?cs=d&minor=&col=RUNDATE&whr-RUNDATE=&col=WRITEDATE&fmt-WRITEDATE=T&whr-WRITEDATE=&col=PERIOD&fmt-PERIOD=&whr-PERIOD=&col=CALIB_RUN&major=-CALIB_RUN&fmt-CALIB_RUN=&whr-CALIB_RUN=&col=CALIB_TABLE&whr-CALIB_TABLE=&col=DATA_STATUS&whr-DATA_STATUS=&col=CALIB_VERSION&fmt-CALIB_VERSION=&whr-CALIB_VERSION=&skip=&limit=50&email=&type=gen-tbl&do=d&src=3&tbl=DATE_RUNLIST_VIEW">table</a>. 
<!-- Author: William Bell :: (run 110779) -->
<!-- Comment: Fri Mar 30 21;12;03 comment by...AFS -->
<table border=0><td><tr><td bgcolor=#e0e030>
<pre>However the date is wrong, as in this example:<br>

30.03.2001 19:24:55 2001 Mar 29 19:25CST 13 110,787 COTCHANT0 BAD 1</pre></td></tr></td></table>

<!-- Date: Fri Mar 30 21:00:49 2001 -->
<pre>----------------------------------------------------------------- 
RUN 110752 
PHYSIC TABLE: INTEGRATION_MINBIAS_CAL_TRIGGERS_v-2[2,101] 
----------------------------------------------------------------- 
RUN DESCRIPTION: 
	ALL CAL CRATES 
	L2 & L3 CAL TRIG CRATES 
	ALL COT CRATES BUT B0COT17 SLOT 17 AND BOCOT18 SLOT 12 
	ALL CMU CMP CMX_01 IMU_00  
	SCINT CRATES  
	HAD TIMING 
	SCALERS 
 
 
MEASURED TRIGGER RATES: 
-----------------------------------------------------------------  
Description     Threshold       Prescale    RATE    PRESC.RATE 
					     Hz	        Hz							 
----------------------------------------------------------------- 
Minimum bias (CLC E*W)                   1   12		12 
Sum Et > 50                              1   22		22 
Sum Et > 50 * Minimum bias               1   00		00 
Central Jet Et > 20                     10   05		0.6      
Central Jet Et > 20 * Minimum bias      10   00		00 
Plug Jet > 20                            1   00		00 
Plug Jet > 20 * Minimum bias             1   00		00 
-----------------------------------------------------------------  
  
 
</pre>
<!-- Author: Ivan & Francesco :: (run 110752) -->
<!-- Comment: Fri Mar 30 21;22;11 comment by...sempre noi ! -->
<pre>run stopped after 116397 events</pre>
<!-- Date: Fri Mar 30 21:03:23 2001 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2001&action=view&page=-381&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2001&action=view&page=-382  width='300' align='top'></td><td>FANTASTICO !! </a></td></tr></table>
<!-- Author: Ivan & Francesco  -->


<!-- Date: Fri Mar 30 21:08:18 2001 -->
Jim Patrick called, thinks the b0dap5x network problems and the 
csl problems are unrelated, but will check.  Immediately thereafter, Phil Demar called back saying they would like to 
do an "interface restart" - asked him to coordinate 
this with Jim.
<!-- Author: AFS -->




<!-- Date: Fri Mar 30 21:27:04 2001 -->
<pre>STEVE will re-initialize the timer crate 
</pre>
<!-- Author: F.Palmonari -->


<!-- Date: Fri Mar 30 21:27:26 2001 -->
At approx. 21:20 our network and consumer difficulties cleared up.  A running YMon took roughly 3000 events before the network was fully visible to the problem machines.
<!-- Author: William Bell -->


<!-- Date: Fri Mar 30 21:35:32 2001 -->
<pre>This afternoon Jeff Schmidt changed the access configuration 
on the b0dap5x and b0dap6x nodes so that they would only 
see subnet 236/237 addresses plus some other required addresses. 
fnprt was left off the allowed list, this was an oversight. 
There should have been no restrictions on access within the 
236 and 237 subnets, so if this caused a problem with data 
taking we need to find out why. Why it would affect consumers 
is a mystery, if it in fact did. 
The access configuration was restored so something like 
it has been recently, which prevents incoming connections 
from outside the lab but doesn't have too many other restrictions. 
We will have to figure out the correct configuration next week.  
Recall the online security plan calls for limiting access 
to the online subnet to whatever is necessary for data taking.</pre>
<!-- Author: patrick -->


<!-- Date: Fri Mar 30 21:52:51 2001 -->
<pre>PHYSICALLY REBOOTED THE CRATE b0tsi03 
 
(NO MORE LINK WITH HIM VIA VXLOGIN OR MINICOM) 
 
 </pre>
<!-- Author: Ivan & Francesco -->
<!-- Comment: Fri Mar 30 22;10;18 comment by...patrick -->
At least once per day this processor gets its heap corrupted,
as shown on the vxmon display, and eventually must be
physically reset.
<!-- Date: Fri Mar 30 21:58:47 2001 -->
We started a new run, with the same configuration as  
the previous run but this time using the physics 
table 1x8_END_1[2,101] 
  
<!-- Author: Ivan :: (run 110794) -->



<!-- Date: Fri Mar 30 22:09:05 2001 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2001&action=view&page=-383&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2001&action=view&page=-384  width='300' align='top'></td><td>Fred rates</a></td></tr></table>
<!-- Author: Ivan -->


<!-- Date: Fri Mar 30 22:09:36 2001 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2001&action=view&page=-385&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2001&action=view&page=-386  width='300' align='top'></td><td>Fred Prescaled</a></td></tr></table>
<!-- Author: Ivan -->



<!-- Date: Fri Mar 30 22:11:16 2001 -->
<table><tr><td><a href=/elog/notebooks/2001/Fri_Mar_30_2001_Eve.221045.ps align=top><img src=/cgi/elog/elog.pl?nb=2001&action=view&page=-388  align='top'></td><td>Hot muon chambers, shown in the event display, seem  to fire often.</a></td></tr></table>
<!-- Author: William Bell -->
<!-- Comment: Sat Mar 31 11;15;12 comment by...hyunsoo -->
<pre>Those are well known spots although their locations are 
not correctly displayed on evd.</pre>
<!-- Date: Fri Mar 30 22:14:52 2001 -->
<pre>GAS ALARM briefly sound 
 
-> no way to track what it was, got in contact with the 
   tech. downstairs but also for him, no way to know  
   what it was...we look forward  </pre>
<!-- Author: F.Palmonari -->
<!-- Comment: Fri Mar 30 22;25;51 comment by...AFS -->
This was the second case of an alarm occurring and clearing too quickly to be seen this shift!  Suggestion: can IFIX have an overall summary and log of alarm conditions (counting occurrences and not just listing them, of course, in case they com too quickly, and logging the most recent time that each occurred)?
Note some few IFIX pages have such historical logs, but there is no overall summary page of them as far as I know.
<!-- Comment: Fri Mar 30 22;37;15 comment by...F.Palmonari -->
<pre>Thanks to Steeve we know what it was:

glitch in the LS-BOTBUBHI-ALM bubbler </pre>
<!-- Date: Fri Mar 30 22:19:58 2001 -->
<pre>IT SEEMS THAT THE PRESCALING IS NOT WORKING FOR THE LAST TABLE 
(SEE PLOTS)</pre>
<!-- Author: Ivan  :: (run 110795) -->
<!-- Comment: Fri Mar 30 22;26;33 comment by...ole ! -->
<pre>
this is the run were we tested the 1X8_START trigger table</pre>


<!-- Comment: Fri Mar 30 22;38;58 comment by...AFS -->
(maybe due to clock problems?)
<!-- Date: Fri Mar 30 22:34:58 2001 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2001&action=view&page=-389&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2001&action=view&page=-390  width='300' align='top'></td><td>Fred trigger rates</a></td></tr></table>
<!-- Author: Ivan -->
<!-- Comment: Fri Mar 30 22;35;19 comment by...Ivan -->
1x8_BEGIN


<!-- Date: Fri Mar 30 22:36:58 2001 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2001&action=view&page=-391&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2001&action=view&page=-392  width='300' align='top'></td><td>Fred Prescaled, too many zeros... 1x8_BEGIN</a></td></tr></table>
<!-- Author: Ivan  -->




<!-- Date: Fri Mar 30 22:47:45 2001 -->
We stop the run  with physics 1x8_begin after 100kevents
<!-- Author: Ivan :: (run 110797) -->


<!-- Date: Fri Mar 30 22:54:30 2001 -->
After testing the trigger tables, we go back to 
the Xenon calibration since the network problem 
is solved.  
 
The table appears in the database... !!!!
<!-- Author: Ivan & Francesco :: (run 110798) -->


<!-- Date: Fri Mar 30 23:00:22 2001 -->
Ivan Vila pointed out that the clock scope in the clock rack was displaying incorrectly.  On closer investigation, it was very wrong.  None of the signals (usually from 1 to 4, CDF_CLK, CDF_BC, CDF_B0, and one of the beam pickups) was syncing to the external trigger.  All of these signals except for the beam pickup are generated in the adjacent clock fanout crate, so they should be synced to each other. 
<p> 
This crate may have gone down during the power outage earlier today (there is no good way to tell that I know of).  If so, the clock would need to be reinitialized and downloaded as per the clock instructions.  I did that, but the scope picture was still not synced. 
<p> 
I called Steve Chappa, and he tried to debug it over the phone with me as his waldo.  Basically, he did not understand what I was seeing either, and so he is coming in.  One thing I noticed while playing with the scope inputs was that the external trigger is a -1 V pulse; however, it appears to have a sinusoid superimposed on it such that this pulse varies between -1 V and 0 V.  The last thhing Steve had me try was to use "PCC A TRIG" out of the sequencer module in the clock crate as the external trigger.  When I did that CDF_CLK and CDF_BC looked stable, but the other two (CDF_B0? and beam pickup) did not.  Huh?
<!-- Author: Steve Hahn -->
<!-- Comment: Sat Mar 31 01;08;15 comment by...Steve Chappa -->
As per Steve Hahn's request, I came in to verify/fix the Clock's operation. I have no way of knowing what was initially displayed on the scope and what, if any, problems there were. What I found was: 1) The scope's trigger was incorrect. I instructed Steve to use the Prog-Trig output from the Sequencer's front panel. Instead, Heused the BC_PH_Trig output. This caused the scope to trigger three times per revolution and trying to look at a signal (B_ZERO, the third scope trace) that only happens once a revolution. The result is the scope will display an incorrect picture of B_ZERO. 2) The cable used for the scope trigger was not plugged in all the way. This could futher cause some uncertainty in what the scope is displaying. 3) The Clock was in Normal mode and the accelerator was doing dumps and injections. This will cause Sync_Timing errors and Seq_Hold errosrs. This is not an problem with the Clock, it is just displaying the accurate beam to Clock sync operation. 4) After setting up the scope properly, I found no problem with the Clock's operation. I do not know what Steve saw or what, if any, problem there really was.

I suspect that the initial alarm over the scope picture was over confusion as to what the scope was actually displaying and what the viewer thought the scope was displaying. Add to this, the RF_Locking mode of operation is not quit the same as Free_Run mode. The Clock uses and generates vaious cyclical and patterned signals. Unless you know exactly what the scope is monitoring and what the trigger is, it can very confusing and thus would bring one to the conclusion that somehow the Clock is operating incorrectly. Also, I suspect that upon re-initializing the Sequencer operation, the Prog_Trig was not loaded. If not loaded via the Set Prog_Trig button (a numeral "6" must be entered) in the Clock operating software, the Sequencer will not generate the Prog_Trig and thus the scope, under the standard picture setup, will not get an external trig. This will then make the scope signals appear to operate independantly and thus it will look like the Clock is really messing up.

A helpful suggestion: I usually leave the scope with a standard timing picture. If you are unsure as to what you are seeing, DO NOT just open the door and start fiddling with the scope and the cables going to the scope. Chances are, you do not know what you are doing. Ask the ops manager. I do not want to be called in to just set up the scope. (I exempt you Steve from this "hint")

The Clock is now in RF_Locking mode. Remember, a Sync_Timing error on the PCC is usually normal for this mode of operation, especially when the accelerator is doing dumps, injections etc. The Clock is not trying to sync to the accelerator anyway. Do not confuse this error with incorrect operation. As I leave it, The Clock seems to be operating OK; as I left it Friday morning.
<!-- Date: Fri Mar 30 23:02:09 2001 -->
<pre>Had to reset cmx00 - trying to run TDCtest on the muons 
</pre>
<!-- Author: dan -->
<!-- Comment: Fri Mar 30 23;02;33 comment by...dan -->
<pre>tdc's had "dropped"
</pre>


<!-- Comment: Fri Mar 30 23;16;01 comment by...dan -->
<pre>TDCtest successful on muons. Ran cratesum - noticed that it copied over several cot crates as well as the muons.</pre>
<!-- Date: Fri Mar 30 23:03:08 2001 -->
LED Calibration also makes its way to the DB. 
It seems that the network  problems where  
the origin of the database/consumer  problems.
<!-- Author: Ivan & Francesco :: (run 110799) -->



<!-- Date: Fri Mar 30 23:17:31 2001 -->
<pre>COT CALIBRATION 
 
THE SUGGESTED PARAMETER TO RUN THE COT CALIBRATION SEEMS  
OUT OF DATE (...350/2000/2000... -> ...350/3500/3500...) 
 
WE RUN LEAVING THE DEFAULT VALUES (THAT DIFFERS FROM THE  
ONE SUGGESTED IN THE WEB) 
 
</pre>
<!-- Author: Ivan,F.Palmonari :: (run 110800) -->
<!-- Comment: Mon Apr  2 10;33;36 comment by...Bill Orejudos -->
<pre>3350 is the correct value...this is now updated 
in the documentation</pre>
<!-- Date: Fri Mar 30 23:24:32 2001 -->
<pre>Noticed that IMU01 is in the muon calibration configuration. I removed the crate from the configuration. Will return it, when the crate is fixed. 
 
</pre>
<!-- Author: dan -->


<!-- Date: Fri Mar 30 23:30:53 2001 -->
<pre>MUON CALIBRATION: RUN NUMBER 110805 
----------------------------------- 
 
(JUST FOR FUN) WITH THE NEW RC A CRATE (b0tsi02) FAIL 
TO SETUP (-> RETURN CROSS POINT CRATE ERROR) 
 
WE GO BACK TO THE OLD RC AND EVERYTHING GOES SMOOTH 
</pre>
<!-- Author: Ivan and Francesco :: (run 110805) -->


<!-- Date: Fri Mar 30 23:42:12 2001 -->
<pre>SMX CALIBRATION: RUN NUMBER 110807 
---------------------------------- 
 
NB: CRATE pcal01 INCLUDED ! 
</pre>
<!-- Author: Ivan & Francesco :: (run 110807) -->
<!-- Comment: Fri Mar 30 23;56;33 comment by...Ivan -->
we redo the SMX calibration because the previous
one wasn't showing up in the database
run number 110808


<!-- Comment: Sat Mar 31 00;07;50 comment by...rob snihur -->
This problem is because the calibration consumer is not found.
<!-- Date: Sat Mar 31 00:01:46 2001 -->
<font color=red>Shift Summary: </font><pre>Network problems due to access changes, see above, caused various 
problems that eventually stopped data taking.  These were cleared 
up by Jim w/ onlooker's assistance from the FNAL network people. 
 
Some clock confusion -- Steve Chappa came in and showed it was 
OK all along. 
 
We completed all calibrations except CLC QIE and CLC LED, plots 
filed. 
 
We are now set up for the scheduled offline data writing test. 
See run plan ON WEB (not paper copies).</pre> 
<br><b>End of Shift Numbers</b>
<table><tr><td width=60% align=left>
<b>CDF Run II <p></b>                       
<pre>
Runs                   lots o' junk
Delivered Luminosity   0  pb-1
Acquired Luminosity    0  pb-1
Efficiency             100
   
</td></tr></table></pre>
<!-- Author: Alan Sill -->