<!-- Title: Day shift. Wed Apr  4, 2001 -->
<!-- SciCo: Pekka Sinervo -->
<!-- DAQAce: Arkady Bolshov -->
<!-- MonAce: Ben Kilminster -->
<!-- CO: Fotis Ptohos -->
<!-- OpManager: Kevin Burkett -->
<!-- Notes: -->
<pre>Inherit shift with a store in machine from yesterday.  Continue run plan.</pre>


<!-- Date: Wed Apr 4 08:17:28 2001 -->
<pre>Moving on to  1X8_END_1 [3,102] 
</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?111217' target=_top>111217</a>) -->


<!-- Date: Wed Apr 4 08:18:14 2001 -->
<pre>COT threshold scans were completed by end of owl shift.</pre>
<!-- Author: Ben -->


<!-- Date: Wed Apr 4 08:39:02 2001 -->
<pre>1X8_END_1 
 
Dead time:  1.23% 
73% readout 
27%  Level 2 
 
Rate:  13 Hz 
 
Prefred trigger rates: 
 
LOW PT muon stub  : 7850 Hz 
Min bias          : 187 
dirac jet  10     : 103 
MET 12            : 85 
2 dirac jet  6    :  0.2 
CMU low pt stub   : 518 
CMU low pt track  : 518   (this and above are identical)  
dirac track 1.5   : 11 
dirac photon 6    : 148 
min bias          : 187 
dirac central photon : 232 
sum et 10         : 108 
dirac electron et3 pt1.5 : 0.1 
dirac jet plug 8  :  0.1  
MET 20            :  56 
dirac photon plug :  0.2 
zero bias         :  1,715,265 Hz 
 
 
Fred rates: 
 
L1 2 jet 6*MINBIAS : 0.0  Hz (25/8000)    
L1 CMU LOW PT ST   : 1.7 
L1 CMU track 1.5   : 0.2 
l1 Jet 10* MINBIAS : 0.1 
L1 dirac track 1   : 8.8 
L1 min bias/1      : 186 
L1 MET 12*MIN      : 0.1 
L1 Electron Et 3   : 0.1 
L1 photon 6 *MIN   : 0.1 
L1 jet plug 8*min  : 0.0  (count 35) 
L1 photon central  : 1.2 
L1 MET 20*MIN      : 0.0  (count 6) 
L1 sum et 10 *MIN  : 4.4 
L1 photon plug 4   : 0.1 
L1 zero bias/1,00..: 1,715,265 
 
 
Fred PRESCALED   : 
 
L1 2 jet 6*MINBIAS : 0.0  Hz (38/10000)    
L1 CMU LOW PT ST   : 0.0     (18) 
L1 CMU track 1.5   : 0.2 
l1 Jet 10* MINBIAS : 0.0      (7) 
L1 dirac track 1   : 8.8 
L1 min bias/100    : 1.9 
 
L1 MET 12*MIN      : 0.0  (9) 
L1 Electron Et 3   : 0.1 
L1 photon 6 *MIN   : 0.0  (10) 
L1 jet plug 8*min  : 0.0  (50) 
L1 photon central  : 0.0   (15) 
L1 MET 20*MIN      : 0.0  (9) 
L1 sum et 10 *MIN/10: 0.4 
L1 photon plug 4   : 0.1 
L1 zero bias/1,00..: 1.7 
 
 
MISSING:  
 
PCAL east !!! 
SVX fib 02 
CMX W 00 
MU SCINT</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?111217' target=_top>111217</a>) -->


<!-- Date: Wed Apr 4 09:08:49 2001 -->
Turned L00 off in preparation for beam dump.
<!-- Author: D. Stuart :: (run <a href='/cgi-bin/runSummaryRun.cgi?111217' target=_top>111217</a>) -->


<!-- Date: Wed Apr 4 09:13:28 2001 -->
<pre>we failed on warm start with a message from carte b0fib01 Error initializing HDI Slot 16 Channnel 7  
</pre>
<!-- Author: Arkadiy :: (run <a href='/cgi-bin/runSummaryRun.cgi?112219' target=_top>112219</a>) -->


<!-- Date: Wed Apr 4 09:17:22 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030>MCR is going to end this store at 09:30.   They will go into shot-setup as soon as they have tidied up after the store.  Their guess was that the next store would be in by perhaps around 4 PM, perhaps longer. 
<p> 
Given yesterday's experience, we are going to focus this morning on fixing the following: 
<ul> 
<li> VRB firmware problem 
<li> Hadron TDC crate 
<li> L2 processor compatibility with Myron mode running 
<li> Fix iFIX and smart alec  
</ul> 
Tentative plan is to bring system together no later than 12:00, perform calibrations, and get runnning again with the full detector prior to the store.</td></tr></td></table>
<!-- Author: Pekka -->


<!-- Date: Wed Apr 4 09:18:03 2001 -->
<pre>failing on xtrp crate there is a suspended process in it  
rebooting it and starting calibrations </pre>
<!-- Author: Arkadiy :: (run <a href='/cgi-bin/runSummaryRun.cgi?111219' target=_top>111219</a>) -->


<!-- Date: Wed Apr 4 09:20:30 2001 -->
Ending the run at 9:15 and bringing down the COT and muon HV.  Silicon is already at standby (and L00 is off --  <a href= 
'/cgi/elog/elog.pl?nb=2001&action=view&page=180&frame=2&anchor=09:26:11'> 
Dave Stuart's note.</a> )
<!-- Author: Pekka -->


<!-- Date: Wed Apr 4 09:22:52 2001 -->
<pre>Why are there no bars on the High Voltage Summary? 
Status is unclear of these high voltages. 
 
Went downstairs and found Mark Knapp working on some aspect of 
IFIX. 
 
Paged muon people, and they say that HVMON went down, and that 
the expert has been paged.  Before they restart it, they want  
the expert to take a look.  They are going to check power  
supplies to tell us what state the muon crates are in  
(standby, or on?). 
</pre>
<!-- Author: Ben -->
<!-- Comment: Wed Apr  4 09;23;44 comment by...Ben -->
<pre>Muon systems are ON.</pre>


<!-- Date: Wed Apr 4 09:24:10 2001 -->
<pre>doing QIE calorimeter calibration </pre>
<!-- Author: Arkadiy :: (run <a href='/cgi-bin/runSummaryRun.cgi?111220' target=_top>111220</a>) -->


<!-- Date: Wed Apr 4 09:26:11 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><STRONG> 
Why we want the silicon bias off during lossy beam conditions. 
</STRONG> 
<P> 
Several people have asked why we care if the silicon bias is on or off during lossy beam conditions. The concern is that the HV coupling capacitors can be damaged by voltage spikes generated by large charge deposition from low angle and high multiplicity losses. These caps are glass strips about 100 nanometers thick fabricated into the silicon. They are spec'd to holdoff about 100V which is fine for the bias voltage we apply, but adding the voltage spike of 1000 mips could break them down. If that happens, we get a low impedance HV to ground connection. This happened to SVX' due to an accelerator accident in Run 1. Since it was single sided silicon the HV across the capacitor was very low so it only affected a small region. The double sided silicon in RunII would make this sort of accident affect the entire ladder. 
<P> 
We had the same policy of turning the silicon to standby during losses in Run 1.  For the reason described above, it is important to follow the same policy now. 
<P></td></tr></td></table>
<!-- Author: David Stuart -->


<!-- Date: Wed Apr 4 09:41:28 2001 -->
<pre>data from QIE calibration finally went into the data base  </pre>
<!-- Author: Arkadiy :: (run <a href='/cgi-bin/runSummaryRun.cgi?111222' target=_top>111222</a>) -->


<!-- Date: Wed Apr 4 09:42:20 2001 -->
<pre>by the way i've noticed that sevb does not work on partition 0</pre>
<!-- Author: Arkadiy :: (run <a href='/cgi-bin/runSummaryRun.cgi?111222' target=_top>111222</a>) -->


<!-- Date: Wed Apr 4 09:43:09 2001 -->
<pre>Main Control Room called to confirm with us that they are 
dumping the beam. 
 
Checking HV power supply status is difficult. 
Checked COT, TOF, silicon HV that they were off. 
Can't tell with muon HV because HVMON is down. 
 
Saw Jaco and CLC also wants to be on list to be notified at  
end of store conditions. 
 
HV turn off procedure didn't go especially well - especially 
considering David's note above. Should the monitoring ACE be 
responsible for turning off HV for every system at beam dump ?   
 
Is there a defined procedure ? 
 
 
</pre>
<!-- Author: Ben -->
<!-- Comment: Wed Apr  4 09;52;26 comment by...Ben -->
<pre>Found muon systems expert and had them go into Standby.
CLC was also turned off main lines.</pre>
<!-- Date: Wed Apr 4 09:44:08 2001 -->
<pre>starting Shower Max QIE calibarion </pre>
<!-- Author: Arkadiy :: (run <a href='/cgi-bin/runSummaryRun.cgi?111223' target=_top>111223</a>) -->
<!-- Comment: Wed Apr  4 09;49;44 comment by...Arkadiy -->
<pre>waiting for the data </pre>
<!-- Date: Wed Apr 4 09:47:03 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030>HTDC00 Problem : Bent pins on the backplane in slot5. Looking for Fred Lewis to repair in time for shot in pm.</td></tr></td></table>
<!-- Author: dan -->



<!-- Date: Wed Apr 4 09:51:54 2001 -->
<pre>starting LED calibarion</pre>
<!-- Author: Arkadiy :: (run <a href='/cgi-bin/runSummaryRun.cgi?111224' target=_top>111224</a>) -->



<!-- Date: Wed Apr 4 10:21:55 2001 -->
<pre>HVmon++ was crashed last night without any clue. It works after log off then log on again. It is advisable to do the log off and on for a while in a similar situation. How ever, when you do, please make a e-logbook entry.</pre>
<!-- Author: Yeongdae Shon -->


<!-- Date: Wed Apr 4 10:23:57 2001 -->
<pre>
Arkadiy finds that SMX calibration does not receive data
for OLD RC. 

Trying SMX calibration with NEW RC. 
Problem is that crates have an empty configuration. 
 
However,  as Frank noticed, if you REMOVE a crate, and then add 
it, then it will be correct. 

Also, not sure if hardware database is configured correctly 
for shower max since it is a differnet configuration than 
when running.
 </pre>
<!-- Author: Ben -->


<!-- Date: Wed Apr 4 10:34:54 2001 -->
Abraham Gallas and I briefly power cycled 1RR12F (there's only one supply there) to install some logic to regenerate MULOSE/MULOSW.
<!-- Author: Tom LeCompte -->


<!-- Date: Wed Apr 4 10:50:18 2001 -->
<pre>On Control Room High Voltage Monitor,  
I now see some bars: 
 
CHA is on. 
COT is at standby. 
 
SVX and ISL are ON (talked to Andy Hocker, and they are 
			actually in STANDBY) 
</pre>
<!-- Author: Ben -->


<!-- Date: Wed Apr 4 10:51:12 2001 -->
<pre>SEVB problems are making it tough to do calibrations. 
Arkadiy talks with Luciano.</pre>
<!-- Author: Ben -->


<!-- Date: Wed Apr 4 11:09:15 2001 -->
<pre>We try a couple runs of shower max calibrations 
with Luciano on the phone. 
 
SEVB core dumps during calibration - but we are still able  
to get into DONE state so SEVB acknowledges DONE, and then  
dies at some point later.   Therefore, when we click end, there 
is no response from SEVB. 
 
This was tried in several partitions.</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?111229' target=_top>111229</a>) -->


<!-- Date: Wed Apr 4 11:20:49 2001 -->
<pre>Tried other calibrations. 
As long as you remember to START the SEVB proxy 
before you do the calibration, the calibrations work. 
 
Calibration LED  
</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?111235' target=_top>111235</a>) -->


<!-- Date: Wed Apr 4 11:21:51 2001 -->
<pre>Set CAFEDELAY=120 for ADMEM_TOF_40 (See TOF e-logbook entry). 
Last night's runs had CAFEDELAY=4 which probably gives somewhat 
degraded timing resolution. 
 
Finished with b0wcal02.</pre>
<!-- Author: M Jones -->


<!-- Date: Wed Apr 4 11:24:22 2001 -->
<pre>We have L1cal, L1Global, L2cal, L2decision to test  
how fer devel handles L2 processors. 
</pre>
<!-- Author: Stephen Miller :: (run <a href='/cgi-bin/runSummaryRun.cgi?111234' target=_top>111234</a>) -->
<!-- Comment: Wed Apr  4 11;58;29 comment by...Stephen -->
<pre>Continuing this work for runs 111236, 111239.
Run 111241 is in myron mode which successfully ran 23K events
before I ended the run.</pre>
<!-- Date: Wed Apr 4 11:30:06 2001 -->
<pre>Heartbeat problem on HVMon++ has been solved 
temporarily.</pre>
<!-- Author: hyunsoo -->


<!-- Date: Wed Apr 4 11:31:26 2001 -->
<pre>Done with COT and LED calibrations  
made sure that data is in the data base </pre>
<!-- Author: Arkadiy :: (run <a href='/cgi-bin/runSummaryRun.cgi?111237' target=_top>111237</a>) -->


<!-- Date: Wed Apr 4 11:31:52 2001 -->
<pre>WITH DAYLIGHT SAVING TIME CENTRAL HV PISABOX PC WAS OFF BY 1HR. 
NOW THIS HAS BEEN FIXED WITH A PATCH. 
 
</pre>
<!-- Author: Simone Dell&#39;Agnello -->


<!-- Date: Wed Apr 4 11:36:23 2001 -->
<pre>There is no beam around  
So, we are doing CLC calibration</pre>
<!-- Author: Arkadiy :: (run <a href='/cgi-bin/runSummaryRun.cgi?111240' target=_top>111240</a>) -->


<!-- Date: Wed Apr 4 11:37:11 2001 -->
<pre>COT HV is at 1/3 height and red.  Probably someone is 
looking at this, but there are no log entries.  
 
Paged experts. 
Ben</pre>
<!-- Author: Ben -->


<!-- Date: Wed Apr 4 11:39:45 2001 -->
Beam was finally dumped sometime in the last 10 minutes and we begin CLC calibrations.   
<p> 
I note that Greg Fields made a request to download new firmware(?) into L2.  I suggested we hold off on that till we have successfully established consistent DAQ operating conditions.  Suggested this be raised at the ops meeting tomorrow.
<!-- Author: Pekka -->


<!-- Date: Wed Apr 4 11:41:15 2001 -->
<pre>Doing QIE time of flight calibration</pre>
<!-- Author: Arkadiy :: (run <a href='/cgi-bin/runSummaryRun.cgi?111242' target=_top>111242</a>) -->


<!-- Date: Wed Apr 4 11:45:12 2001 -->
<pre>Bob Wagner responds to COT page. 
COT HV is at 25%,  and the version of IFIX being used 
considers this an error since it is expecting 50%. 
Bob is notifiying Aseet. 
 
</pre>
<!-- Author: Ben -->


<!-- Date: Wed Apr 4 11:47:54 2001 -->
<pre>So we are done with calibrations except for Xenon flashers  
and muon calibration  
 
Dan is keeping muon crates right now to do a muon calibration using new run control  
 
we might want to do Xenon flashers calibration at some point</pre>
<!-- Author: Arkadiy :: (run <a href='/cgi-bin/runSummaryRun.cgi?111243' target=_top>111243</a>) -->


<!-- Date: Wed Apr 4 11:49:30 2001 -->
<pre>NEW RC : Muon crates readout (and calibrate) under new (and old) RC. 
Muon Calibration performed (under new RC) </pre>
<!-- Author: eric + dan + kevin :: (run <a href='/cgi-bin/runSummaryRun.cgi?111244' target=_top>111244</a>) -->
<!-- Comment: Wed Apr  4 12;14;32 comment by...dan -->
<pre>NEW RC : The new RC calibration was 1/2 successful. The run proceeded, but Kevin reports no D banks in the run. Reran with old RC. #111245</pre>
<!-- Date: Wed Apr 4 11:54:57 2001 -->
<pre>All VRBs were reprogrammed with version 1123 of the firmware. 
All of them reprogrammed smoothly, except that the problems 
in the plug VRB crate from last evening were reproduced. 
Two more spare VRBs were taken, and reprogrammed successfully 
in a different crate, then installed in the plug crate. 
So there is something wrong with the plug VRB crate, 
however we don't have more spares to burn to try and 
diagnose it.</pre>
<!-- Author: patrick -->



<!-- Date: Wed Apr 4 12:01:08 2001 -->
<pre>Cleaned up HEVB. 
 
b0l3gate1.fnal.gov: 
-> SQL error:  cannot connect to Hardware Database. 
 
Next attempt works.</pre>
<!-- Author: Ben -->


<!-- Date: Wed Apr 4 12:04:36 2001 -->
<pre>We tested changes made by Jim Patrick  
with Event Builder Everything worked well</pre>
<!-- Author: Arkadiy -->



<!-- Date: Wed Apr 4 12:14:50 2001 -->
<pre>Done with Xenon flashers calibration  
i'm going downstairs to turn them off  </pre>
<!-- Author: Arkadiy :: (run <a href='/cgi-bin/runSummaryRun.cgi?111246' target=_top>111246</a>) -->


<!-- Date: Wed Apr 4 12:25:04 2001 -->
Have completed calibrations.  Steve Nahn is pulling out the VTM's in the SVX crates that are not receiving power so that we can avoid any trigger timeouts created by these.  They will have to go back in once we have power in those crates. 
<p> 
Next steps are: 
<ul> 
<li>  Test with integrated system to see of VRB firmware fixes work (one successful test with only one crate has been done). 
<li> Slow control system reboot 
<li>  Check L2 processors in Myron mode 
<li>  Try adding b0l2de01 
<li>  Try adding b0htdc00 
<li>  Run with 1x8_BEGIN_1[7,101] 
</ul> 
<p>
<!-- Author: Pekka -->


<!-- Date: Wed Apr 4 12:30:21 2001 -->
MUON CRATES are ready for the run : all except for b0imu01  
<!-- Author: dan -->
<!-- Comment: Wed Apr  4 12;34;26 comment by...eric + dan -->
Work performed by Eric and Dan : tested crate readout problems noticed in previous shifts. "Fixed" b0htdc00 (a more permanent fix requires replacement of backplane in crate). Crates now can be readout in both new and old RC. Performed calibration, and tested readout under SEVB (hevb we couldnt get our hands on). All crates ran well, but any problems with TDC readout should be noted, and the crates reset (not rebooted). 


<!-- Date: Wed Apr 4 12:49:09 2001 -->
<pre>Several run attempt made to integrate SVX. 
Still have repeating problem  fib 02. 
 
Try 3 times. 
 
Problem is due to power up problem which wipes 
out readout sequence. 
 
Finally running. 
</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?111249' target=_top>111249</a>) -->
<!-- Comment: Wed Apr  4 13;10;53 comment by...SCN -->
<B><FONT COLOR=FF0000>Friendly </FONT> <FONT COLOR=00FF00> Advice </FONT> <FONT COLOR = FFFF00>to</FONT> <FONT COLOR = 00FFFF>Aces</FONT> <FONT COLOR=0F00F0>regarding</FONT>:  If a fib crate does not initialize:</B><BR>
it is for one of four reasons<ul>
<li> The Rack is off.  Check IFIX RACK display.  There is no alarm for this
<li> The crate CPU is hosed.  Login, type i(), look for abnormal
response, hung stuff etc.  Reboot if necessary
<li> The ladders are not powered.  Check IFIX display for trips, Silicon GUI over by the IFIX stuff, etc.
<li> The FIB sequences are not correct.  This can happen after
a the crate is power cycled (though it is not expected to happen). Find an Expert.
</ul>

If you can log on to a crate, you'll see many messages like <BR>
<I> ERROR initializing HDI Slot x Chan y EXPECTED QQ RECEIVED qq</I>.</BR>  If the power is off, <I>qq</I> will be either <I>0</I> or <I>ff</I>, most likely <I>0</I>.  If the sequences are incorrect, <I>QQ</I> and <I>qq</I> will be related by a shift of some bits.
<!-- Date: Wed Apr 4 13:00:20 2001 -->
<pre>3  Level 3 converter nodes went dead - 
so we only have 1 out of 4 sub-farms running. 
 
Notified Ilya and Boris.</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?111249' target=_top>111249</a>) -->



<!-- Date: Wed Apr 4 13:17:11 2001 -->
Now trying all detector elements EXCEPT: 
<ul> 
<li> L2 decision crates (to be tested), 
<li> Hadron TDC's (to be tested), 
<li> SVT crates (not to be tested at this point), and 
<li> 2 XFT crates that we are waiting for (about 15 minutes?). 
</ul> 
When these work, we'll try adding the missing pieces (except SVT).
<!-- Author: Pekka -->
<!-- Comment: Wed Apr  4 14;00;04 comment by...Stefano -->
Hey !! DO not add "all SVT crates" just add b0l2de01 !
Leave b0svtxx out. And make sure b0l2de01 is in.
<!-- Date: Wed Apr 4 13:18:15 2001 -->
<pre>We were reading out TDC slot 17 from COT crate 17. 
This we fixed locally in RC yesterday. 
Also, Bill fixed it in database, but this will only work for 
NEW RC. 
 
We went in to new RC and changed it in the "old rc" database, 
also.  
 
So COT 17 should be fixed in both old RC and new RC.</pre>
<!-- Author: Ben -->


<!-- Date: Wed Apr 4 13:26:42 2001 -->
<pre>CMP 00 
CMX 00 
MUSC 00 
 
all failed COLDSTART. 
 
checked with VISIONdemo:  they are EMPTY in all slots, 
except CMX 00 had a value in slot 15. 
 
Issue bus reset to CMX 00, CMP 00, MUSC 00. 
 
Try again.</pre>
<!-- Author: Ben -->
<!-- Comment: Thu Apr  5 01;35;02 comment by...dan -->
<pre>Eric and I are trying to understand this : What happened prior to this run? Before we handed the muon crates over, they had worked for several runs in a row.</pre>
<!-- Date: Wed Apr 4 13:34:41 2001 -->
<pre>SVX experts figure out problem (port card not powered). 
 
Fibs COLDSTART.</pre>
<!-- Author: Ben -->


<!-- Date: Wed Apr 4 13:38:29 2001 -->
<pre>COT goes to alarm state again. 
Checked with experts; they are still at 25% HV, so I  
should ignore this.</pre>
<!-- Author: Ben -->


<!-- Date: Wed Apr 4 13:45:41 2001 -->
TrigMon spits out continuous error messages of the form: 
 
%ERLOG-e Inconsistent number of blocks and data size:  
         /home/cdfsoft/dist/packages/TriggerObjects/V00-00-40/src/XFFD_StorableBank.cc  
        : 566   XFFD XFDD_StorableBank::get_word()  4-Apr-2001 13:37:22  
         run = 111253 event = 804 
 
  
<!-- Author: fotis :: (run <a href='/cgi-bin/runSummaryRun.cgi?111253' target=_top>111253</a>) -->


<!-- Date: Wed Apr 4 13:47:28 2001 -->
<pre>3 Level 3 converter nodes die at the same time  
we get COT data truncation errors. 
 
We did forget to run cotsl6, but this is ussually not fatal. 
 
We go to COLDSTART again. We are in IDLE, but COLDSTART is  
not an option. ABORT puts us back in IDLE with no start choice  
(old RC). 
 
We ABT+clean up Level 3+PARTITION and try again.</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?111253' target=_top>111253</a>) -->


<!-- Date: Wed Apr 4 13:49:52 2001 -->
<pre>XFT 00, and 01 are integrated. 
Now we only don't have:   Level 2 and HDTC. 
</pre>
<!-- Author: Ben -->


<!-- Date: Wed Apr 4 13:56:30 2001 -->
<pre>SVX VRB 02  gives DONE TIMEOUT after 1 trigger. 
 
Error reading VRB in slots  [10, 12, 16] 
VRB had no event.  </pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?111254' target=_top>111254</a>) -->



<!-- Date: Wed Apr 4 14:03:37 2001 -->
<pre>SVX DO-timeout-after-1-event-error repeats. 
SVX people check the smartosckets connection.</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?111255' target=_top>111255</a>) -->


<!-- Date: Wed Apr 4 14:03:56 2001 -->
Solenoid back up to full field.	
<!-- Author: Pekka -->


<!-- Date: Wed Apr 4 14:05:05 2001 -->
<pre>Next run SVX 02 fails coldstart. 
It is rebooted.</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?111256' target=_top>111256</a>) -->


<!-- Date: Wed Apr 4 14:10:50 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030>Here comes a list of SILICON wedges for 1x8 and their FIB/VRB addresses: <br><br>
 
these wedges should be included in the moment: <br><br><br>
 
L00: B0W3 = b0fib01 (slot 16), b0svx06 (slot 18) <br>
SVX: B0W6 = b0fib02 (slot  9), b0svx00 (slot 16) <br>
     B1W6 = b0fib02 (slot 13), b0svx01 (slot 16) <br>
     B2W8 = b0fib02 (slot 19), b0svx02 (slot 18) <br>
     B3W5 = b0fib06 (slot  8), b0svx03 (slot 12) <br>
     B3W6 = b0fib06 (slot  9), b0svx03 (slot 16) <br>
     B4W5 = b0fib06 (slot 12), b0svx04 (slot 12) <br>
ISL: B0W3 = b0fib01 (slot  9), b0svx08 (slot 13) <br>
     B1W3 = b0fib01 (slot 10), b0svx08 (slot 10) <br><br><br>
 
 
these wedges might be included soon: <br><br>
 
L00: B1W3 = b0fib05 (slot 16), b0svx06 (slot 10) <br>
SVX: B2W6 = b0fib02 (slot 18), b0svx02 (slot 16) <br>
     B2W7 = b0fib02 (slot 18), b0svx02 (slot 16) <br>
ISL: B5W2 = b0fib02 (slot 13), b0svx01 (slot 16)<br>
</td></tr></td></table>
<!-- Author: Petra -->


<!-- Date: Wed Apr 4 14:17:01 2001 -->
<pre>Hvmon expert is on vacation until April 15. Please, contact Dan Cyr or Hyunsoo Kim, if you have problems. Most of functions in Hvmon program works well now except some security related problems.  </pre>
<!-- Author: Yeongdae Shon -->


<!-- Date: Wed Apr 4 14:27:08 2001 -->
I am attempting, with the knowledge of A 
rnd Meyer and Stephen Miller, to configure crate b0l2de01 so that it reads out t 
he 
SVTD bank using the L2/Track board, but does not make any  
attempt to use the L2 processor in this crate.  When you try 
to include b0l2de01 in the run (currently item #4 on the 
"before shot" list), please first make sure someone from SVT 
(me, for example) is around to deal with any posssible issues. 
<p> 
I just modified, with Arnd's permission, the crate set 
level2_decision_01 and the bank set svtd_01, to reflect 
the above.  I am now trying to test it in a separate 
partition. 
<p>  
<!-- Author: Ashmanskas -->
<!-- Comment: Wed Apr  4 14;38;23 comment by...Ashmanskas -->
<table border=0><td><tr><td bgcolor=#e0e030>Please call the SVT pager, 266-2706, so that we are here when you are about to try this.</td></tr></td></table>


<!-- Comment: Wed Apr  4 14;49;55 comment by...Ashmanskas -->
<table border=0><td><tr><td bgcolor=#e0e030>OK, I just tested this in a separate partition, and it 
worked for me.  I think it's ready to go.
<p>
Just add DAQ_LEVEL2_DECISION_01 to the crate list.
<p>
</td></tr></td></table>
<!-- Comment: Wed Apr  4 14;51;43 comment by...Ashmanskas -->
The effect of this is that whatever happens to come down
the SVT output cable will wind up in the SVTD bank.  This
was used extensively in the commissioning run, worked
fine, and has nothing to do with L2 triggers.  It is just
a way to get SVT data into the readout.  The SVT crates
themselves will remain in expert mode.  It is just the
readout of the SVTD bank, at the end of this cable, that
we need.

<!-- Comment: Wed Apr  4 15;15;42 comment by...Ashmanskas -->
Note that B0L2DE01 should be set up to read out only SVTD, not TL2D.  The slot number is 13.

<!-- Date: Wed Apr 4 14:45:37 2001 -->
Suddenly see ORACLE errors of this type: 
 
2001.04.04 14:43:56 *** Error fetching PrimaryUsedSet L1_PHYSICS_CAL TRIGWEIGHTS2001.04.04 14:43:56 java.sql.SQLException: ORA-00942: table or view does not exist 
  
<!-- Author: SCN + Pekka + mary + Arkidady -->




<!-- Date: Wed Apr 4 14:52:25 2001 -->
<pre>If you are unable to control muon HV from the slow control 
monitor, login to iFIX as ace (page either JC or hyunsoo 
for the password) and try it again.</pre>
<!-- Author: hyunsoo -->


<!-- Date: Wed Apr 4 14:58:50 2001 -->
<pre>BMU section 24 tripped.</pre>
<!-- Author: hyunsoo -->


<!-- Date: Wed Apr 4 14:59:15 2001 -->
While investigating previous Timeout (Done or busy?) on SVX Vrbs 
discovered that the west L00 VRB in b0svx06 was "busy". Turned 
power off to the L00 ladders that aren't being read out since 
sometimes causes FIBs to hand and not send data to VRB. Restarted 
RC and ran for about 2700 events before something else (not SVX) 
went blah.
<!-- Author: Mary Bishai -->


<!-- Date: Wed Apr 4 14:59:22 2001 -->
frank clhlebana just reset the clock (cleared many errors)
<!-- Author: ashmanskas -->


<!-- Date: Wed Apr 4 15:10:01 2001 -->
MCR called to say that they are clearing the scalars on page E20 that log the loss counters.
<!-- Author: Pekka -->



<!-- Date: Wed Apr 4 15:17:06 2001 -->
<pre>Failed to start a run. Scanner manager did not see any triggers. 
Logged into b0tsi00 and saw: 
 
 
TM_reset   TM_reset       c83ab0 180 SUSPEND      2818fc   c839a8  3d0001     0 
TM_activateTM_activate    c48958 180 PEND         28034c   c48890       0     0 
Messenger  FER_messenge   e846f0 200 PEND+T       27f1bc   e84278      46     3 
Mon_III    FER_monitorI   c68bf8 220 DELAY        282134   c68b58       0    23 
tLogTask   logTask        efc720 250 PEND         29f490   efc658       0     0 
</pre>
<!-- Author: Frank Chlebana -->


<!-- Date: Wed Apr 4 15:19:53 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030>I set up some CSX-based loss monitors today.  There are two - MULOSE and MULOSW.  Only MULOSW works; MULOSE has a dead cable between the 1st and 2d floors. 
 
They take the coincidence between CSX counter #61 internal and external on the east (MULOSE) and west (MULOSW) sides.  This coincidence is converted to TTL and plugged into a ratemeter on the 2d floor, and sent to ACNET as LOSTP (MULOSE) and LOSTPB (MULOSW).  These should  be logged on D44 so we should have history information. 
 
These counters cover a very small bit of solid angle on the south side of the experiment.  The coincidence rate is small (under a Hz), and I have the ratemeters on their lowest settings just to see that much (with quiet beam conditions). 
 
This is a temporary setup - the CSX people don't like the way that I've picked off the signal (correctly - I wouldn't like this as a long-term solution either) but it will give us some information on how best to monitor losses near the muon systems, so our next plan can build on this one. 
 
The shift crews should be aware that they have another tool to monitor losses. 
 
Feel free to email me (lecompte@fnal.gov) if you have any questions.</td></tr></td></table>
<!-- Author: Tom LeCompte -->


<!-- Date: Wed Apr 4 15:29:00 2001 -->
We experienced a SILICON rack trip this morning (SWB) and are  
bypassing this problem right now. It is a Fan Failure although  
we are convinced that the fan is working and we think it's  
safe to run that rack anyway. See also entry in the <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=16&frame=2&anchor=11:18:35'> 
silicon e-log</a>.  
<!-- Author: Petra -->


<!-- Date: Wed Apr 4 15:31:40 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030>Zhaoou Yu, Trigger Manager expert, is now here till Sunday.  If there is a problem, call him at (203) 589-7386 (cell).  </td></tr></td></table>
<!-- Author: Pekka -->


<!-- Date: Wed Apr 4 15:42:38 2001 -->
<pre>Tried a test run with the hadron timing crate and b0l2de01  
(SVTD). 
 
First attempt failed because the TDC in the hadron timing crate 
was not visible. Bus reset and it came back... 
 
Second try worked. 
 
</pre>
<!-- Author: Frank Chlebana -->


<!-- Date: Wed Apr 4 15:45:07 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Why is XTRP crates always takes so long to activate on partition transition and on cold start ? 
it is even longer than Level3 which actually does a lot of work  
on those transitions </pre></td></tr></td></table>
<!-- Author: Arkadiy -->


<!-- Date: Wed Apr 4 15:50:27 2001 -->
<pre>PSM monitoring turned off. 
Marguerite called and the Slow Power Monitor is being set to  
gray while it is worked on.  This means that there won't be any  
PSM alarms until this is re-enabled. </pre>
<!-- Author: Ben -->


<!-- Date: Wed Apr 4 15:53:56 2001 -->
<pre>We had a busy time out from SVX crates  
HRR did work  
CPU-P0-E-BadVrbByteCount: Event 8992 total byte count is lt 32, gt 65528, or not divisible by 8 for VRB in slot 16. 
Count = 1038. 
(MLE) b0l3gate1.fnal.gov:main:3:50:12 PM->Host b0eb17.fnal.gov, task tRec_0 
SCPU-P0-E-VrbHeader: Dump of header words for event 8992 from VRB in slot 16: 
0x040e0000 0x0a1a0612 0x0e220a1a 0x00000000 0x00000000 0xe0600000 0x833f0cfc 0x01330033 
50'23" 1 crate/s: b0svx02(112),  busy.[RXPT] 
(MLE) b0tsi02:Messenger:3:50:44 PM->BUSY timeout 
(MLE) b0tsi02:Messenger:3:50:49 PM->BUSY timeout 
(MLE) b0tsi02:Messenger:3:50:53 PM->BUSY timeout 
(MLE) b0tsi02:Messenger:3:50:57 PM->BUSY timeout 
(MLE) b0tsi02:Messenger:3:51:01 PM->BUSY timeout 
(MLE) b0tsi02:Messenger:3:51:05 PM->BUSY timeout 
(MLE) b0tsi02:Messenger:3:51:09 PM->BUSY timeout 
(MLE) b0tsi02:Messenger:3:51:13 PM->BUSY timeout 
(RC) Halt -> AUTOREC 
51'3"  
(RC) Run -> ACTIVE 
(END)  
</pre>
<!-- Author: Arkadiy :: (run <a href='/cgi-bin/runSummaryRun.cgi?111270' target=_top>111270</a>) -->


<!-- Date: Wed Apr 4 16:04:15 2001 -->
<pre>Started a run with the hadron timing crate (one TDC) and the  
L2 decision crate (SVTD). 
 
This works... and we should include these crates by default... 
 
Had a busy timout from b0eb23 
 
HRR worked...</pre> <font color=red><cite>(entry outside this shift's time range )</cite></font>
<!-- Author: Frank Chlebana -->


<!-- Date: Wed Apr 4 16:04:43 2001 -->
<font color=red>Shift Summary: </font>Early part of the shift was spent finishing up the store.  Then, 
<ul> 
<li> We ended the run around 09:15 and started calibrations. 
<li> Work on HV monitoring took place, but complete fix requires a reboot of the PC's on the 1st floor. 
<li> Spent latter part of the shift trying to establish a working DAQ system.  Finally succeeded after many  attempts and soft errors.
<li>  Store arrived right at end of shift.
</ul>
<br><b>End of Shift Numbers</b>
<table><tr><td width=60% align=left>
<b>CDF Run II <p></b>                       
<pre>
Runs                   111217-111270
Delivered Luminosity   0  pb-1
Acquired Luminosity    0  pb-1
Efficiency             100
   
</td></tr></table></pre>
<!-- Author: Pekka Sinervo -->