<!-- Title: 09:42:12  Mon Mar 19 2001 -->
<!-- Crewchief: GBauer -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>************ Inauguration of TOF e-Log ***************** 
 
Some recent history pre-dating the e-Log 
 
 
March 14:  
  Turned on west LV in the morning. Had been generally off. 
  Turned on east LV in the late afternoon....also had been off. 
 
  Installed Central Clock unit in TNW crate 
  Installed Local   Clock unit in BSW crate 
 
Franco Spinella checked out clock as much as he can, and is happy. Rick Tesarek is also satisfied with our installation job.</pre>


<!-- Date: Mon Mar 19 09:46:30 2001 -->
<pre> 
************ Inauguration of TOF e-Log *****************  
 
Some recent history pre-dating the e-Log  
 
 
March 14:   
  Turned on west LV in the morning. Had been generally off.  
  Turned on east LV in the late afternoon....also had been off.  
 
  Installed Central Clock unit in TNW crate  
  Installed Local   Clock unit in BSW crate  
 
Franco Spinella checked out clock as much as he can, and is happy. Rick Tesarek is also satisfied 
with our installation job.</pre>
<!-- Author: GBauer -->


<!-- Date: Wed Mar 21 16:44:29 2001 -->
<pre>Current register contents on b0wcal02 slot 9: 
[ 0] XBRD_DIAG = 0xaa 
[ 1] XBRD_SERNUM = 0x02 
[ 2] STATUS = 0x1a 
[ 4] TOAD0 = 0x10 
[ 5] TOAD1 = 0x00 
[ 6] TOAD2 = 0x00 
[ 8] CAL_ENABLE = 0xf0 
[ 9] ANMUX_SEL = 0x00 
[10] CLOCK_MON = 0x04 
[12] DAC_SR_LOW = 0x7c 
[13] DAC_SR_HIGH = 0x01 
[14] ADC_SR_LOW = 0xf0 
[15] ADC_SR_HIGH = 0x67 
[28] AUX_PORT_0 = 0x00 
[29] AUX_PORT_1 = 0x00 
[30] AUX_PORT_2 = 0x00 
[31] AUX_PORT_3 = 0x00 
</pre>
<!-- Author: Matthew Jones -->


<!-- Date: Thu Mar 22 12:32:18 2001 -->
<pre>Scanned DTHR0,1,2 for QIAMP=50, GATE0,1,2=255 
Same scan on ch0, 1, 2 in sequence. 
Scanned GATE0,1,2 for DTHR=20 (I think). 
 
Added 80 ns cable in front of STOP.  New value for 
CAFE_DELAY should be 75.  Hardware database not yet 
updated. 
 
Scanning CAFE_DELAY for different cable delays on CAL. 
 
- Matthew & Rolf</pre>
<!-- Author: Matthew Jones -->


<!-- Date: Thu Mar 22 16:30:19 2001 -->
<pre>Finished DAQ development for today.  Released resources.</pre>
<!-- Author: Matthew Jones -->


<!-- Date: Thu Mar 29 11:00:57 2001 -->
<pre>I Furic and M jones are trying to turn on HV to take 
some data with cosmics. 
 
High voltage PC was completely hung. 
ctrl-alt-delete didn't work. 
Hit the reset button. 
 
Tried to page Gerry but got no response. 
</pre>
<!-- Author: M Jones -->


<!-- Date: Fri Mar 30 04:35:03 2001 -->
<pre>Turning on HV for channels 360, 361 leaving 362 off.</pre>
<!-- Author: M Jones -->


<!-- Date: Fri Mar 30 06:09:14 2001 -->
<pre>Conditions as of about 5:30 AM: 
 
b0dap19:/cdf/people2/mjones/tof/tomain/checkout/ cat Mar30_reg.dat  
@ 
@ Setting default register configuration: 
@ 
@ All discriminators are enabled, pulse monitor disabled. 
@ 
XBRD_DIAG 0x55      ; Arbitrary value for diagnostic register 
TOAD0 0x92          ; Monitor channels 0,1,2 
TOAD1 0x00 
TOAD2 0x00 
CAL_ENABLE 0x00     ; Disable all calibration signal fanout buffers 
CLOCK_MON 0x04      ; Monitor common stop 
AUX_PORT_0 0x00 
AUX_PORT_1 0x00     ; These values turn off RESET 59 ns before STOP and 
                    ; turn it on about 27 ns after STOP. 
 
b0dap19:/cdf/people2/mjones/tof/tomain/checkout/ cat Mar30_dac.dat 
@ Disabling all charge injectors... 
QIAMP0 255 fullbuf  ; Disable all charge injectors 
QIAMP1 255 fullbuf 
QIAMP2 255 fullbuf 
@ Set nominal discriminator thresholds to 50 mV... 
DISC0 50 fullbuf 
DISC1 50 fullbuf 
DISC2 10 fullbuf   ; Lower threshold on the channel without HV 
DISC3 50 fullbuf 
DISC4 50 fullbuf 
DISC5 50 fullbuf 
DISC6 50 fullbuf 
DISC7 50 fullbuf 
DISC8 50 fullbuf 
@ Set gate width to 0 V - wide gate. 
GATE0 0 fullbuf 
GATE1 0 fullbuf 
GATE2 0 fullbuf 
GATE3 255 fullbuf 
GATE4 255 fullbuf 
GATE5 255 fullbuf 
GATE6 255 fullbuf 
GATE7 255 fullbuf 
GATE8 255 fullbuf 
 
HV is on for channels 360, 361.  CH362 is off. 
 
Added 32+32+16 ns of cable in front of common stop at about 5:45. 
 
</pre>
<!-- Author: M Jones -->


<!-- Date: Fri Mar 30 06:28:05 2001 -->
<pre>Run 110677 is in progress and should be entirely with 
a common configuration. 
 
b0dap19:/cdf/people2/mjones/tof/tomain/checkout/ ./read_voltages  
 VCC5 voltage =   5.046 V 
 VEE5 voltage =  -5.402 V 
VCC15 voltage =  15.069 V 
VEE15 voltage = -15.862 V 
  VTT voltage =  -1.982 V  
Nominal TEMP_T temperature =  24.98 deg C 
Nominal TEMP_B temperature =  24.67 deg C 
 
We will leave things in this state for this run and should 
probably turn off HV when the COT ramps down. 
 
Run 110677 may not have actually been in Myron mode.  The ACE 
is going to stop this run, put the DAQ in Myron mode and start 
another run.</pre>
<!-- Author: M Jones -->


<!-- Date: Fri Mar 30 06:29:29 2001 -->
<pre>We need to find a bunch crossing signal and bring it downstairs 
to trigger the scope.  Using the 132 ns CDF_CLK can lead to 
confusing trigger conditions on the scope.</pre>
<!-- Author: M jones -->


<!-- Date: Fri Mar 30 09:33:29 2001 -->
<pre>We were not able to update the hardware database for the 
proton-only runs thismorning so the phase of QIE_CLK is 
wrong and no valid TAC or ADC data should be present in 
the banks.  We need to adjust the phase by about 80 ns. 
Assuming 1 ns per count, the correct value should show up 
at a value of around 23.</pre>
<!-- Author: M Jones -->


<!-- Date: Fri Mar 30 11:39:37 2001 -->
<pre>Found a suitable signal to trigger scope.  Using CDF_BX* on 
pin 18 of J8 on Tracer in pulser crate.</pre>
<!-- Author: M Jones -->


<!-- Date: Fri Mar 30 14:21:11 2001 -->
<pre>Trying to time in CAFE_DELAY again.  Using cable delay to 
generate CAL pulse again.</pre>
<!-- Author: M Jones -->


<!-- Date: Fri Mar 30 14:29:01 2001 -->
<pre>New value for CAFE_DELAY appears to be about 20. 
</pre>
<!-- Author: M Jones -->


<!-- Date: Fri Mar 30 14:31:07 2001 -->
<pre>Updated hardware database with new value. 
 
SQL> SELECT CAFEDELAY FROM CARDS WHERE CARDNAME='ADMEM_TOF_40'; 
 CAFEDELAY 
---------- 
        75 
 
SQL> UPDATE CARDS SET CAFEDELAY=20 WHERE CARDNAME='ADMEM_TOF_40'; 
1 row updated. 
SQL> COMMIT; 
</pre>
<!-- Author: M Jones -->


<!-- Date: Fri Mar 30 14:49:35 2001 -->
<pre>Run control appears to be running the new code in the front 
end crates which configures the TOMAIN board during 
coldstart/warmstart: 
 
<from stdout on b0wcal02...> 
 
Slot 9: 
  Configuring TOMAIN S/N = 0x2 (0x2) 
  VCC5= 5.009 V, VEE5=-5.083 V, VCC15=15.011 V, VEE15=-15.068 V, VTT=-1.982 V 
  Board temperature: 76.638 deg F (top), 75.999 deg F (bottom). 
  TOF ADMEM pipeline length/offset = 29/7 
ADMEM_config: using pedestal = 50  
==> ADMEM_setCafeDelay: geo32:/slot=9 status 0 cafe delay old/target/new 0x8a/0x14/14 
 
Hence, starting a run will overwrite registers which may have 
been previously set by hand.</pre>
<!-- Author: M Jones -->


<!-- Date: Fri Mar 30 14:54:26 2001 -->
<pre>I think we're ready to turn on HV again. COT HV is at only 25% 
while a HV problem gets tracked down.</pre>
<!-- Author: M Jones -->


<!-- Date: Fri Mar 30 15:29:09 2001 -->
<pre>Here is what I wrote in the HV log book after we got stable 
beams again and b0wcal02 got timed in.  The SciCo thought the 
magnet was on so I assumed it was. 
 
Power outage at about 10:30.  Now it's 3:00 pm - stable beams. 
Restarting PC. 
 
30 march 2001  3:00 PM 
 
Can't find the directory where HV files are stored. 
 
Loaded [B=14kG] file but HV for ch 361 is still at 1096 V. 
 
3:19 PM.  Pulses look large [and ratty looking... lots of 
afterpulsing and some rounding-off of peak due to preamp saturation]...  I really can't tell if the magnet is on or 
off.  Turned down to B field off value. 
[At this point I went upstairs and asked the Aac...they 
 weren't sure if it was on or off.] 
 
We still have pulses -- I suspect the field is off although all 
the HV status indicators say it is on. 
 
Rob Roser confirms that the magnet is off. 
 
We have the potential for a real problem here. 
 
Reloading HV off file.</pre>
<!-- Author: M jones -->


<!-- Date: Fri Mar 30 15:32:07 2001 -->
<pre>It should be obvious from my previous little adventure that if 
you don't know for sure that the B field is on, assume that it 
is off.  I don't think the HV indicators on the PC are correct. 
Rob claims the field is off but the status says that it is on.</pre>
<!-- Author: M Jones -->


<!-- Date: Sun Apr 1 18:29:25 2001 -->
<pre>I did not konw we have already a e-log !</pre>
<!-- Author: Ivan  -->


<!-- Date: Mon Apr 2 09:01:50 2001 -->
<pre>Here's how to tell if the magnet is on.  Gerry and I learned 
this from Rob this morning. 
 
As you are walking into the cryo area, there is a set of racks 
on your right.  When you are facing these racks the right-most 
rack contains two meters which read out Hall probes.  When the 
magnet is off, the green light on the left side of the meter 
is off and the reading will drift around.  When the magnet is 
on, the green light will be on and the reading will be stable 
at about 1.4....  Tesla to many decimal places.</pre>
<!-- Author: M Jones -->


<!-- Date: Mon Apr 2 09:05:49 2001 -->
<pre>Updating hardware database so that the TOAD0=0x92 
and CLOCK_MON=0x04 whenever a new run is started. 
 
SQL> UPDATE CARDS SET TOADCTRL0=146 WHERE 
            CARDNAME='ADMEM_TOF_40'; 
1 row updated. 
SQL> UPDATE CARDS SET CLOCKMON=4 WHERE 
            CARDNAME='ADMEM_TOF_40'; 
1 row updated. 
SQL> COMMIT; 
</pre>
<!-- Author: M Jones -->


<!-- Date: Tue Apr 3 15:14:51 2001 -->
Changed HV configuration file fnal_b14kG_Ch360_1_2 to new current threshold settings.  All channels other than PMT 360, 361, and 362 are off.  Voltages are correct for Solenoid on.  No guarentee that the current thresholds are high enough.
<!-- Author: Mike Mulhearn -->
<!-- Comment: Tue Apr  3 15;18;47 comment by...M Mulhearn -->
Here's the full directory path for the 
<P>
C:\Program Files\DevStudio\VB98\CDF\SmacsPro2.0\SmacsPro2.0_Server\SmacsPro2.0\StandardSettings
</P>
I added a shortcut to this directory on the desktop.


<!-- Date: Tue Apr 3 16:42:52 2001 -->
<pre>At 4:41 we removed 16 ns of cable from STOP and changed 
CAFEDELAY to 4 in the hardware database. 
 
This was after Ivan showed plots of the TDC distribution 
showing a sharp cutoff at the maximum possible dynamic 
range on channel 362 of about 3572 counts.  This is the 
maximum possible since the TAC slope is about 58 counts/ns 
and the time during which the RESET signal is not active is 
only 60 ns. 
</pre>
<!-- Author: M Jones -->


<!-- Date: Tue Apr 3 17:06:47 2001 -->
<pre>The 3 pmts have been powered up. A 16ns cable delay have been 
remove from the common stop. After that the next good run  
is 111157</pre>
<!-- Author: Ivan -->


<!-- Date: Tue Apr 3 18:48:31 2001 -->
<pre>Gate width is currently set to 128.  We should probably scan 
the values 255 245 225 200 175 if we can during the next runs. 
We might also try to default to 255 for normal operations.</pre>
<!-- Author: M Jones -->


<!-- Date: Tue Apr 3 18:55:16 2001 -->
<pre>Connection to hardware database rather slow.  Changed 
gate width: 
 
SQL> SELECT GATEWIDTH0,GATEWIDTH1,GATEWIDTH2 FROM CARDS WHERE CARDNAME='ADMEM_TOF_40'; 
GATEWIDTH0 GATEWIDTH1 GATEWIDTH2 
---------- ---------- ---------- 
       128        128        128 
SQL> UPDATE CARDS SET GATEWIDTH0=255,GATEWIDTH1=255,GATEWIDTH2=255 WHERE CARDNAME='ADMEM_TOF_40'; 
1 row updated. 
SQL> commit; 
Commit complete. 
SQL> SELECT GATEWIDTH0,GATEWIDTH1,GATEWIDTH2 FROM CARDS WHERE CARDNAME='ADMEM_TOF_40'; 
GATEWIDTH0 GATEWIDTH1 GATEWIDTH2 
---------- ---------- ---------- 
       255        255        255 
</pre>
<!-- Author: M Jones -->


<!-- Date: Tue Apr 3 19:16:36 2001 -->
<pre>Field is now up to 12 kGauss.</pre>
<!-- Author: M Jones -->


<!-- Date: Tue Apr 3 19:19:03 2001 -->
<pre>Analysing run 111159 (0x1b237) shows that we are in the right 
bucket so we don't need to adjust our pipeline index. 
The common stop seems to be adjusted correctly.  It's difficult 
to say whether CAFE_DELAY is correct without a dedicated scan. 
In principle, it should be correct.</pre>
<!-- Author: M Jones -->


<!-- Date: Tue Apr 3 20:01:05 2001 -->
<pre>Magnet is up now.  Turning up HV on tubes. 
</pre>
<!-- Author: M Jones -->


<!-- Date: Tue Apr 3 21:05:22 2001 -->
<pre>Hardware database updated with gate width = 245 while run 
111174 in progres.</pre>
<!-- Author: M Jones -->


<!-- Date: Tue Apr 3 22:21:47 2001 -->
<pre>Updated hardware database with gate width = 225 before 
run 111178.  Not sure if this change got applied to this 
run or whether it takes effect on the next run.</pre>
<!-- Author: M Jones -->


<!-- Date: Wed Apr 4 09:32:00 2001 -->
<P> 
Turned off HV to all channels (360,361, and 362). 
</P>
<!-- Author: M. Mulhearn -->


<!-- Date: Wed Apr 4 10:38:12 2001 -->
<pre>I sorted out the difference between the STOP phase when 
using the CAL cable delay and when it goes directly into 
the TTL->ECL translator.  I think we may have had CAFE_DELAY 
in the wrong place because of a 16 ns difference in these 
two setups.</pre>
<!-- Author: M Jones -->


<!-- Date: Wed Apr 4 11:12:31 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-1&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-1  width='300' align='top'></td><td>Here is how the cable delay is configured to give the same common stop phase.  Delay wrt CDF_CLK triggering scope, obtained from CDF_CLK receiver module, is 69.52 ns for normal operation and 69.52 ns with cable delay configuration. </a></td></tr></table>
<!-- Author: M Jones -->


<!-- Date: Wed Apr 4 11:13:50 2001 -->
<table><tr><td><a href=/elog/notebooks/tof/Wed_Apr__4_2001_111329.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-3  align='top'></td><td>This is the CAFEDELAY scan obtained with the cable delay configured in this way.</a></td></tr></table>
<!-- Author: M Jones -->


<!-- Date: Wed Apr 4 11:15:10 2001 -->
<pre>A more optimal value for CAFE_DELAY would be 120.  The value used 
for the previous runs was 4 which is a bit too late.  The timing 
data will be useable but with a somewhat degraded timing resolution, particularly on channel 362.</pre>
<!-- Author: M Jones -->


<!-- Date: Wed Apr 4 11:19:11 2001 -->
<pre>Changing the CAFE_DELAY to this new value is likely to shift us 
into a different pipeline entry so we may need to adjust the 
pipeline offset. 
 
In any case, the hardware database is updated with the new 
value for CAFEDELAY. 
 
SQL> SELECT CAFEDELAY from CARDS WHERE CARDNAME='ADMEM_TOF_40'; 
 CAFEDELAY 
---------- 
         4 
SQL> UPDATE CARDS SET CAFEDELAY=120 WHERE CARDNAME='ADMEM_TOF_40'; 
1 row updated. 
SQL> COMMIT; 
Commit complete. 
SQL> 
</pre>
<!-- Author: M Jones. -->


<!-- Date: Wed Apr 4 13:50:43 2001 -->
have figured out that the solenoid trip was not functioning 
because the trip limits were not set around the current  
operating point. they were set very narrow.... 
....have gotten them changed this morning, so HV should trip  
if it is less than 90% of nominal (or if the phase lock  
is lost, i guess?) 
...we now have to test it again once the magnet comes up  
this afternoon
<!-- Author: bauer/sumorok -->


<!-- Date: Wed Apr 4 18:31:22 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-4&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-4  width='300' align='top'></td><td>I just analysed the first file from run 0x1b2b1 in the look area and it appears that we are still timed in.</a></td></tr></table>
<!-- Author: M Jones -->


<!-- Date: Wed Apr 4 19:31:52 2001 -->
experiment was running, solenoid on, and TOF hv on... 
<P> 
solenoid tripped, TOF hv went off....store still going, 
cdf runs continue.....run 111285 (aka 1B2B5) was last 
run.... 
<p> 
i have now loaded B=0 HV file, and disabled interlock, 
and put HV on for 360,361,362 (863.8, 632.4, 809.2V) 
so TOF can take data with everyone else!
<!-- Author: gbauer -->


<!-- Date: Wed Apr 4 20:25:30 2001 -->
<pre>Magnet and HV on again at 20:20.  But now level 3 is hung...</pre>
<!-- Author: M Jones -->


<!-- Date: Thu Apr 5 22:12:48 2001 -->
<pre>Turned HV on for ch360,361,362(Solenoid Locked). 
Store not yet started. 
</pre>
<!-- Author: Koji Sato -->


<!-- Date: Fri Apr 6 05:43:55 2001 -->
<P> 
Store lost.  HV to all channels (i.e. 360-362) was turned off. 
</P>
<!-- Author: M Mulhearn -->


<!-- Date: Fri Apr 6 10:10:21 2001 -->
<pre>After switching to the production database, I took a 
new TOF QIE calibration. It worked and the tables  
appeared on the "run calibration list" in the ACE 
page.  Run number 111399 There are some error because 
of too large sigmas or failing the calibration. </pre>
<!-- Author: Ivan  -->


<!-- Date: Sun Apr 8 13:57:08 2001 -->
<pre>I took more TOFqiecalibration, with the new  
run control version. The tables appeared in 
the database.Run number 111,527 
 
Now I try the new run control version. 
 
First problem, no admem board is included in 
the run configuration I include it  by hand 
and start over from the begining. 
 
Active transtion does not work. I abort the calibration. 
Bottom line, keep using the old run control.</pre>
<!-- Author: Ivan -->
<!-- Comment: Sun Apr  8 13;58;14 comment by...Ivan -->
<pre>The first try was with the old rc version.</pre>


<!-- Date: Wed Apr 11 21:25:32 2001 -->
<pre>CalibInterval Scanning from 1 to 4. Run number 111800, 111801, 
111802, 11804. 
 
The time interval between CALIB and COMMON_STOP was set to  
~ 25 ns.  We checked out all the rest of clock signal and  
they seemed to be fine. We just noticed that the RESET and 
the QIE_CLOCK were almost simultaneous (within a few ns) 
 
Navigator advises 
 
-The CIC DIP switch had the same setting than the COT CIC, we 
Switch the CIC switch to  0x03. 
 
-The DDG base address is 0xE000 
 
 
 
 
 
</pre>
<!-- Author: Gervasio & Ivan  -->


<!-- Date: Mon Apr 23 20:08:44 2001 -->
<pre>Another Manual TAC calibration, we have done: 
 
-Cross check stability of the calibrations. 
-Compare calibration with scope measurements. 
-Do a fine (~1n step) scann. 
 
And that's it. 
</pre>
<!-- Author: Gervasio & Ivan  -->


<!-- Date: Tue Apr 24 16:57:58 2001 -->
<pre>Koji and I turned on the HV to channels 144-152 and 360-362 
sequentially and observed the output of the pulse monitor 
cables.  All channels appeared to be working as expected. 
 </pre>
<!-- Author: M Jones -->


<!-- Date: Thu Apr 26 12:38:46 2001 -->
<pre>Removed a 32 ns cable from the DDG oupout signal. Now the TDC dynamic range is within the delay interval [5,70] ns  
(to be determined more precisely soon).  
 
Tested automated script for TAC calibration. Runs fine, needs only fine tunning: restrict the scan to an optimal delay range, 
and perhaps reduce the number of loops of L1buffer readout in order to speed up the calibration. Just need to run ~mjones/tof/tomain/checkout/scan_pulser, a 
script which loops over DDG delays and writes out delay.dat in the following format:  
 
delay #measurements mean rms #measurements mean rms ... ... ...  
 
1 line per delay, 9 or 3 channels per line.  
Other relevant files called by the scan_pulser script are:  
bnc    (controls DDG and sets delays, default width 10 ns)  
avglv1 (reads out the L1 buffers)</pre>
<!-- Author: Gervasio and Mathew -->


<!-- Date: Sat Apr 28 09:57:51 2001 -->
<pre>End-Of-Store TAC Calibration: 
============================= 
Everything went smoothly.  
With a relatively quiet network, the entire calib process took about 15 minutes from the time I started Run Control to the time scan_pulser finished scanning (I suppose the only interesting time is the time we actually need to hold the crates). 
The scanning was from 0 to 75 nanoseconds, and it read BOTH crates WCAL06 and WCAL02. 
The root script needs a slight modification in the fitting range for WCAL02, but apart from that it works fine and it creates the database files. 
Today's calib files are: 
 
~cdf_tof/tools/tac_calib_wcal02_apr28.dat 
~cdf_tof/tools/tac_calib_wcal02_apr28.db 
~cdf_tof/tools/tac_calib_wcal06_apr28.dat 
~cdf_tof/tools/tac_calib_wcal06_apr28.db 
</pre>
<!-- Author: Gervasio -->


<!-- Date: Sat Apr 28 10:28:09 2001 -->
<pre>tac_calib.C root script modified. For crate WCAL06 it fits from 15 to 71 ns, while for crate WCAL02 the lower bound is 16. 
File tac_calib_wcal02_apr28.db has been "updated". 
Both .db files are in ~cdf_tof/tools 
Youngdo will put them into the development DataBase. 
 
Note1: Youngdo and Koji were added to the list of people who can 
ksu cdf_tof 
 
Note2: It might be convenient to add a few definitions in the .login and .cshrc files for the tof account. For the moment, in order to run root, one needs to:  
setenv DISPLAY to the local machine 
xhost +b0dau30 on the local machine 
source ~cdfsoft2/cdf2.cshrc 
setup cdfsoft2  -or- setup cdfsoft2 development (for DB stuff) 
</pre>
<!-- Author: Gervasio -->


<!-- Date: Sat Apr 28 18:27:46 2001 -->
<pre>Beam was lost. New TAC calibration done starting at 6:00. 
Again, took about 30 minutes for the entire job. 
Things went OK. Relevant files are: 
 
~cdf_tof/tools/tac_calib_wcal02_apr28b.dat 
~cdf_tof/tools/tac_calib_wcal02_apr28b.db 
~cdf_tof/tools/tac_calib_wcal06_apr28b.dat 
~cdf_tof/tools/tac_calib_wcal06_apr28b.db 
</pre>
<!-- Author: Gervasio -->


<!-- Date: Tue May 1 13:15:47 2001 -->
TOF HV supplies turned off, steve hahn will lock them out. 
this morning i've unplugged TOF HV. 
all this is necessary because they are removing the COT baggie before normal argon/ethane flush cycle. 
do not even *think* about trying to run either system. should be able to restore things on wed.
<!-- Author: gbauer -->


<!-- Date: Wed May 2 16:58:03 2001 -->
This afternoon we re-installed Crate-1 into TOF racks, and tried it out. first time around things did not work. but eventually did....see paper logbook. we created a test hv file that puts on only 50 volts to the tubes, this seemed to work fine. we have not attempted to put full voltages. be careful what files you load in!</BR> 
 
gerry, marco, koji
<!-- Author: gbauer -->


<!-- Date: Thu May 3 19:35:05 2001 -->
<pre>TAC calibration for both crates wcal02 and wcal06. 
The dac is now buffered and it sets reasonable adc gates and  
thresholds. Scanned from 0 to 75 ns as usual, and the calibration 
plots STILL show the initial saw tooth discontinuity. 
</pre>
<!-- Author: Gervasio Gomez -->


<!-- Date: Sat May 5 10:58:01 2001 -->
<pre>TAC calibration using a DDG pulse width of 20ns. 
At first glance, no significant difference in the saw-tooth behavior.</pre>
<!-- Author: Gervasio -->


<!-- Date: Wed May 9 12:17:10 2001 -->
Magic boxes for scope test measurements wrapped up in plastic in order to not screw up grounding. They are placed at the bottom north-east / bottom north-west crates.
<!-- Author: Philipp Schieferdecker -->


<!-- Date: Wed May 9 12:20:36 2001 -->
Turned on (ie plugged in) east TOF LV. (no convient lift, so not sure of west status)
<!-- Author: gbauer -->


<!-- Date: Thu May 10 14:38:18 2001 -->
<pre>TAC calibrations (performed May 9). 
Scanned in "lsb" or 39.0625 steps and in 2*lsb steps a region between 50 and 55 ns of delay (pulse width=10ns as usual). 
Residues present a clear oscillation. 
Also performed "standard" 1 ns scan from 0 to 75 ns. Everything seems to agree with expectations from the changes during the last access. 
Performed a calib_interval scan from 0 to 10, run numbers 114356,57,58,59,60,61,62,64,66,67,68 respectively. 
</pre>
<!-- Author: Gervasio and Rolf -->


<!-- Date: Mon May 14 12:03:30 2001 -->
<pre>Test of DDG using oscilloscope: fine scan in 4*lsb (4*39.0625) ps 
steps. We are pretty convinced that the oscillating behavior of TAC calibration residues is due to the DDG. We find the same oscillation, with the same period and even the same magnitude, when reading out the delays using the scope. 
 
Normal 1 ns scan from 0 to 75 ns to check for stability 
Calib interval (1..15) scan with interval0=4, runs 114669 through 
114683 
Calib interval scan (1..12) with interval0=3, runs 114684,85,87,88,89,90,92..97 
 </pre>
<!-- Author: Gervasio, Matthew, Rolf -->


<!-- Date: Wed May 16 10:47:04 2001 -->
<pre>Turned on West LV at 10:20</pre>
<!-- Author: gbauer -->


<!-- Date: Fri May 18 13:55:42 2001 -->
<pre>About to remove TOF VTT supply from east end of detector.</pre>
<!-- Author: M Jones -->


<!-- Date: Fri May 18 16:00:04 2001 -->
<pre>East VTT supply on b0wcal06 has been refurbished.  Now the 
ripple and spikes are &lt;&lt; 20 mV.</pre>
<!-- Author: M Jones -->


<!-- Date: Mon May 21 20:02:56 2001 -->
<pre>TAC calibrations. 1 ns scan from 0 to 75 ns. 
lsb = 39.0625 ps 
2*lsb scan from 50 to 55 ns 
repeated 2*lsb scan but adding a 1 ns cable to DDG output 
4*lsb scan from 15 to 70 ns 
Results of these calibrations will be analyzed shortly. The 1 ns scan looks normal. 
Looked at the DDG output with the scope after setting the delay and width using Run Control; there is something which is not 
working properly. The signal is erratic and it became "normal" after setting the DDG using the stand alone program "bnc".</pre>
<!-- Author: Gervasio, Ivan -->


<!-- Date: Wed May 23 11:36:50 2001 -->
Disabled TOF HV monitoring in the control room---people getting 
confused about us being in the alarm state
<!-- Author: bauerg -->


<!-- Date: Wed May 30 09:08:04 2001 -->
<pre>Today I will swap proms on transition boards in wcal02 and wcal06 
in preparation for production electronics.  The new proms were 
burned at Penn with the xilinx_logic_v2r19 bitstream with CRC 
enabled.  After these are installed we can make changes to the 
tools in ~cdf_tof/tools and the front end readout code which 
reads the ADC's on the TOMAIN board.  All other functionality 
will remain unchanged. 
 
</pre>
<!-- Author: M Jones -->


<!-- Date: Wed May 30 09:55:45 2001 -->
<pre>PROM's on TOMAIN boards in wcal02 and wcal06 replaced.  Code 
in ~cdf_tof recompiled on dap30 and dau30 to reflect changes 
in the ADC readout.  fer code tested also and can be installed.</pre>
<!-- Author: M Jones -->


<!-- Date: Fri Jun 1 14:53:18 2001 -->
<pre>TAC calibration, 1 ns steps from 1 to 75 ns using the DDG. 
Results are consistent with previous calibrations. 
</pre>
<!-- Author: Gervasio -->


<!-- Date: Wed Jun 6 19:06:44 2001 -->
<pre>New ToF_calib code tested succesfully. MRKD banks are created.  
We can use the generic calibration state manager to control the 
ddg and readout the crates.  I also noticed that channel 
147 is working again!  
 
Intrisic resolution measured with the DDG is around 1.6 TDC counts.</pre>
<!-- Author: Ivan  -->


<!-- Date: Thu Jun 7 11:21:48 2001 -->
<pre>Normal scan, 1ns steps in [0,75] ns range. 
Tested the DDG script: recorded some calibration points from run control. Run numbers 117049,50,52..55. 
Tested jpython script for automatized calibration. 
Still a few bugs need to be fixed.</pre>
<!-- Author: Gervasio, Ivan, Matthew -->


<!-- Date: Thu Jun 7 22:01:26 2001 -->
<pre>Run 117132 - PMT HV turned on for ch. 144-149,360-365.  Gain 
             set to 3E4.  This is a very low intensity store.</pre>
<!-- Author: m jones -->


<!-- Date: Thu Jun 7 22:33:22 2001 -->
<pre>Even though channel 147 works for calibration pulses, 
it does not appear to work for PMT pulses.  The problem 
must be in the receiver or discriminator.</pre>
<!-- Author: m jones -->


<!-- Date: Fri Jun 8 01:10:02 2001 -->
<pre>Checked TOF HV downstairs.  Not being a TOF expert it is hard to tell what I am looking at.  It looks like it is on, but only board 8 in crate 2.  Since there are no trip messages that I can see I assume this is the correct state.  Someone may want to clarify in the ace instructions exactly what it is we are looking for, otherwise all we will check is that the little system light is green.  (Which may really be all that you want, but it would be nice for us to know that for sure.)</pre>
<!-- Author: Rob Napora, Mon. Ace -->


<!-- Date: Sat Jun 9 13:36:50 2001 -->
<pre>We did normal scan from 0 to 75ns. Think they look good. 
 
Single delay points from run control. 
    delay0	delay1	run # 
	20	30	117263 
	20	100	117264 
	30	40	117266 
	30	100	117267 
	40	50	117268 
	40	100	117269 
	50	60	117270 
	50	100	117271	 
	60	70	117272 
	60	100	117273 
	70	80	117274 
	70	100	117275 
</pre>
<!-- Author: K.Sato and Gervasio -->


<!-- Date: Tue Jun 12 16:31:12 2001 -->
<pre>Detailed TOF Qie calibration of  some instrumented channels. 
(b0wcal02, admem 9) using the qietest program 
The qie calibration for these channels fails. 
It looks like the DAC chip that is stepping through the  
cafe input  voltage levels is not working properly or the 
CAFE input is not switched to the DAC path during calibrations</pre>
<!-- Author: Rolf, Koji & Ivan -->


<!-- Date: Tue Jun 12 22:33:30 2001 -->
<pre>Study of calibration pulse width effects using different sets of 
delays from Run Control. 
Also normal 1ns scan from 0 to 75 ns delays. 
</pre>
<!-- Author: gervasio, k.sato -->


<!-- Date: Fri Jun 15 14:13:09 2001 -->
<pre>Changed TOADCTRL0 register values on hardware database so that 
pulse monitoring is now DISABLED by default.  This changes the 
response of the CAFE card and we may now see the mean of the ADC distribution shift to slightly larger values.  So that entire 
runs are recorded with the same set of operation conditions, do 
not turn on pulse monitoring during a physics run.</pre>
<!-- Author: m jones -->


<!-- Date: Sat Jun 16 12:35:30 2001 -->
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> 
<html> 
<head> 
   <meta name="Author" content="Ivan Vila"> 
   <meta name="GENERATOR" content="Mozilla/4.61 [en] (X11; I; Linux 2.0.36 i686) [Netscape]"> 
</head> 
<body> 
We tryed the new jpython script for the TOF TAC calibration. 
<br>we have been able to do only the first iteration, more 
<br>investigation is needed to see what is going on. After 
<br>that we did a successfully two TAC calibrations, the 
<br>first one with all the TOAD channels enabled and the second 
<br>one just enable the channels 0,3 and 5. From this last 
<br>calibration we saw that there is not time-time cross talk 
<br>at all. 
<br>&nbsp; 
<p>Output b0puls01 
<p><font color="#3366FF">b<b>0puls01-> Messenger: processPartition 2</b></font> 
<br><b><font color="#3366FF">Sent ack to Run Control: 2 IDLE SUCCESS</font></b> 
<br><b><font color="#3366FF">Messenger: processStatechange Setup [0]</font></b> 
<br><b><font color="#3366FF">Slot&nbsp; 2: 0116 001 TRACER__V2.1A</font></b> 
<br><b><font color="#3366FF">Messenger: processReadoutlist</font></b><b><font color="#3366FF"></font></b> 
<p><b><font color="#3366FF">Current r/o settings:</font></b> 
<br><b><font color="#3366FF">---------------------</font></b> 
<br><b><font color="#3366FF">EVB node / port&nbsp; b0dap62 / 6502</font></b> 
<br><b><font color="#3366FF">Crate Id&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
120</font></b> 
<br><b><font color="#3366FF">Output->EVB/VRB&nbsp; 1/0</font></b> 
<br><b><font color="#3366FF">Trigger mode&nbsp;&nbsp;&nbsp;&nbsp; 1</font></b> 
<br><b><font color="#3366FF">Verbosity:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Minimal</font></b><b><font color="#3366FF"></font></b> 
<p><b><font color="#3366FF">TRACER: VISIONopen Name=geo32:/slot=2</font></b> 
<br><b><font color="#3366FF">TRACER: done enabled</font></b> 
<br><b><font color="#3366FF">Client id: 0</font></b> 
<br><b><font color="#3366FF">FER_initEVB: Connection established. Node 
b0dap62 Port = 6502</font></b> 
<br><b><font color="#3366FF">Here we are.DDG configuration:</font></b> 
<br><b><font color="#3366FF">&nbsp; Base address: 0xe000</font></b> 
<br><b><font color="#3366FF">&nbsp; External trigger, 2.500000 V, negative 
edge.</font></b> 
<br><b><font color="#3366FF">&nbsp; Output pulse V(low) = 0.000 V, V(high) 
= 5.000 V</font></b> 
<br><b><font color="#3366FF">&nbsp; Waveform modes:&nbsp; 0x22&nbsp; 0x22&nbsp; 
0x22</font></b><b><font color="#3366FF"></font></b> 
<p><b><font color="#3366FF">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
requested&nbsp;&nbsp; register&nbsp; nominal</font></b> 
<br><b><font color="#3366FF">&nbsp; Channel&nbsp; delay (ns)&nbsp; contents&nbsp; 
delay (ns)</font></b> 
<br><b><font color="#3366FF">&nbsp; -------&nbsp; ----------&nbsp; --------&nbsp; 
----------</font></b> 
<br><b><font color="#3366FF">&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
20.000000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 512&nbsp;&nbsp; 20.000000</font></b> 
<br><b><font color="#3366FF">&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
40.000000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1024&nbsp;&nbsp; 40.000000</font></b> 
<br><b><font color="#3366FF">&nbsp;&nbsp;&nbsp;&nbsp; 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
0.000000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 
0.000000</font></b> 
<br><b><font color="#3366FF">&nbsp;&nbsp;&nbsp;&nbsp; 3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
0.000000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 
0.000000</font></b> 
<br><b><font color="#3366FF">&nbsp;&nbsp;&nbsp;&nbsp; 4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
0.000000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 
0.000000</font></b> 
<br><b><font color="#3366FF">&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
0.000000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 
0.000000</font></b> 
<br><b><font color="#3366FF">&nbsp; -------&nbsp; ----------&nbsp; --------&nbsp; 
----------</font></b> 
<br><b><font color="#3366FF">DDG_setup() - Initialization completed.</font></b> 
<br><b><font color="#3366FF">Interrupt mode.&nbsp; Level 2 vector 0x2</font></b> 
<br><b><font color="#3366FF">Sent ack to Run Control: 2 READY SUCCESS</font></b> 
<br><b><font color="#3366FF">Messenger: processStatechange Activate [0]</font></b> 
<br><b><font color="#3366FF">Starting run 117877 at 992703361</font></b> 
<br><b><font color="#3366FF">Sent ack to Run Control: 2 ACTIVE SUCCESS</font></b> 
<br><b><font color="#3366FF">Sent ack to Run Control: 2 CALIBRATION DONE 
SUCCESS</font></b> 
<br><b><font color="#3366FF">Messenger: processStatechange End [0]</font></b> 
<br><b><font color="#3366FF">TRACER: Closing MyTRACER</font></b> 
<br><b><font color="#3366FF">Connection is closed file = 19</font></b> 
<br><b><font color="#3366FF">Sent ack to Run Control: 2 IDLE SUCCESS</font></b> 
<p>THe second iteration failed and the error messages on the java terminal 
<br>is : 
<br>&nbsp;<b></b> 
<p><b><font color="#FF6600">2001.06.16 09:55:29 Attempting connection to 
&lt;tcp:b0dau30:5101></font></b> 
<br><b><font color="#FF6600">RTserver.</font></b> 
<br><b><font color="#FF6600">2001.06.16 09:55:30 Connected to &lt;tcp:b0dau30:5101> 
RTserver.</font></b> 
<br><b><font color="#FF6600">2001.06.16 09:55:33 Fetching from HdwDb... 
10658 ms 2001-06-16</font></b> 
<br><b><font color="#FF6600">09:54:57.0</font></b> 
<br><b><font color="#FF6600">2001.06.16 09:55:44 Fetching from RunDb... 
458 ms</font></b> 
<br><b><font color="#FF6600">2001.06.16 09:55:46 ** Error while requesting 
partition 0 ***</font></b> 
<br><b><font color="#FF6600">2001.06.16 09:55:46 java.sql.SQLException: 
ORA-20100: Partition 0</font></b> 
<br><b><font color="#FF6600">already allocated by another user</font></b> 
<br><b><font color="#FF6600">ORA-06512: at "HDWDB_PRD.HDWDB", line 277</font></b> 
<br><b><font color="#FF6600">ORA-06512: at line 1</font></b><b><font color="#FF6600"></font></b> 
<p><b><font color="#FF6600">2001.06.16 09:55:46 ** Command: &lt;BEGIN</font></b> 
<br><b><font color="#FF6600">HDWDB.REQUEST_PARTITION(0,'/_b0dap20.fnal.gov_21bab392','TAC</font></b> 
<br><b><font color="#FF6600">Calibration','b0dap20.fnal.gov','cdf_tof',4850);END;></font></b> 
<br><b><font color="#FF6600">2001.06.16 09:55:46 ** Error while requesting 
partition 1 ***</font></b> 
<br><b><font color="#FF6600">2001.06.16 09:55:46 java.sql.SQLException: 
ORA-20100: Partition 1</font></b> 
<br><b><font color="#FF6600">already allocated by another user</font></b> 
<br><b><font color="#FF6600">ORA-06512: at "HDWDB_PRD.HDWDB", line 277</font></b> 
<br><b><font color="#FF6600">ORA-06512: at line 1</font></b><b><font color="#FF6600"></font></b> 
<p><b><font color="#FF6600">2001.06.16 09:55:46 ** Command: &lt;BEGIN</font></b> 
<br><b><font color="#FF6600">HDWDB.REQUEST_PARTITION(1,'/_b0dap20.fnal.gov_21bab392','TAC</font></b> 
<br><b><font color="#FF6600">Calibration','b0dap20.fnal.gov','cdf_tof',4850);END;></font></b> 
<br><b><font color="#FF6600">2001.06.16 09:55:46 ListenToEndOfRun: &lt;/partition-2/endRun/*></font></b> 
<br><b><font color="#FF6600">runTAC(TAC Calibration, 3, -1, TOF_TAC_CALIB, 
1024)</font></b> 
<br><b><font color="#FF6600">2001.06.16 09:55:47</font></b> 
<br><b><font color="#FF6600">2001.06.16 09:55:47</font></b> 
<br><b><font color="#FF6600">------------------------------------------------------------------------</font></b><b><font color="#FF6600"></font></b> 
<p><b><font color="#FF6600">2001.06.16 09:55:47 Iteration # 1 of 2: Amplitude 
= 10,&nbsp; delay time 20,</font></b> 
<br><b><font color="#FF6600">Num Events=1024</font></b> 
<br><b><font color="#FF6600">2001.06.16 09:55:47</font></b> 
<br><b><font color="#FF6600">------------------------------------------------------------------------</font></b><b><font color="#FF6600"></font></b> 
<p><b><font color="#FF6600">2001.06.16 09:55:47 Configurable action detected: 
iteration 1</font></b> 
<br><b><font color="#FF6600">2001.06.16 09:55:47 SELECT</font></b> 
<br><b><font color="#FF6600">TABLE_SUFFIX,TABLE_TYPE,TABLE_SOURCE,PROCESS_VARIABLE,PROCESS_DEFAULT,COLUMN_LIST</font></b> 
<br><b><font color="#FF6600">FROM CALIB_LOADS&nbsp; WHERE DAQVALID=1 AND 
RUNTYPE=47 ORDER BY TABLE_SUFFIX</font></b> 
<br><b><font color="#FF6600">2001.06.16 09:55:51 Configurable action detected: 
nEvents 1024</font></b> 
<br><b><font color="#FF6600">2001.06.16 09:55:51 DatabaseInstance &lt;cdfonprd></font></b> 
<br><b><font color="#FF6600">2001.06.16 09:55:53 SELECT</font></b> 
<br><b><font color="#FF6600">TABLE_SUFFIX,TABLE_TYPE,TABLE_SOURCE,PROCESS_VARIABLE,PROCESS_DEFAULT,COLUMN_LIST</font></b> 
<br><b><font color="#FF6600">FROM CALIB_LOADS&nbsp; WHERE DAQVALID=1 AND 
RUNTYPE=47 ORDER BY TABLE_SUFFIX</font></b> 
<br><b><font color="#FF6600">2001.06.16 09:55:54 UPDATE RUNCONFIGURATIONS 
SET</font></b> 
<br><b><font color="#FF6600">RS_NAME='RUN_117877',INHIBITENABLEMASK=0,FETCHTIME=TO_DATE('2001.06.16</font></b> 
<br><b><font color="#FF6600">09:55:17','YYYY.MM.DD HH24:MI:SS') WHERE RUNNUMBER=117877</font></b> 
<br><b><font color="#FF6600">2001.06.16 09:55:54 DatabaseInstance &lt;cdfonprd></font></b> 
<br><b><font color="#FF6600">2001.06.16 09:55:58 UPDATE RUNCONFIGURATIONS 
SET ACTIVATETIME='' WHERE</font></b> 
<br><b><font color="#FF6600">RUNNUMBER=117877</font></b> 
<br><b><font color="#FF6600">2001.06.16 09:56:09 UPDATE RUNCONFIGURATIONS 
SET TERMINATETIME='' WHERE</font></b> 
<br><b><font color="#FF6600">RUNNUMBER=117877</font></b> 
<br><b><font color="#FF6600">&nbsp;====== Iteration done ======</font></b> 
<br><b><font color="#FF6600">2001.06.16 09:56:11</font></b> 
<br><b><font color="#FF6600">2001.06.16 09:56:11</font></b> 
<br><b><font color="#FF6600">------------------------------------------------------------------------</font></b><b><font color="#FF6600"></font></b> 
<p><b><font color="#FF6600">2001.06.16 09:56:11 Iteration # 2 of 2: Amplitude 
= 10,&nbsp; delay time 30,</font></b> 
<br><b><font color="#FF6600">Num Events=1024</font></b> 
<br><b><font color="#FF6600">2001.06.16 09:56:11</font></b> 
<br><b><font color="#FF6600">------------------------------------------------------------------------</font></b><b><font color="#FF6600"></font></b> 
<p><b><font color="#FF6600">2001.06.16 09:56:11 Configurable action detected: 
iteration 0</font></b> 
<br><b><font color="#FF6600">2001.06.16 09:56:11 SELECT</font></b> 
<br><b><font color="#FF6600">TABLE_SUFFIX,TABLE_TYPE,TABLE_SOURCE,PROCESS_VARIABLE,PROCESS_DEFAULT,COLUMN_LIST</font></b> 
<br><b><font color="#FF6600">FROM CALIB_LOADS&nbsp; WHERE DAQVALID=1 AND 
RUNTYPE=47 ORDER BY TABLE_SUFFIX</font></b> 
<br><b><font color="#FF6600">2001.06.16 09:56:13 *** Error calling PL/SQL 
procedure Record_UsedSet</font></b> 
<br><b><font color="#FF6600">2001.06.16 09:56:13 java.sql.SQLException: 
ORA-00001: unique constraint</font></b> 
<br><b><font color="#FF6600">(CALIB_PRD.US_PK) violated</font></b> 
<br><b><font color="#FF6600">ORA-06512: at "SYS.CALIBDB", line 31</font></b> 
<br><b><font color="#FF6600">ORA-06512: at line 1</font></b> 
<br><b></b>&nbsp; 
<br>&nbsp; 
</body> 
</html>  
<!-- Author: Ivan -->


<!-- Date: Mon Jun 18 17:25:06 2001 -->
<pre>TOF HV seems to have hanged in some fashion. Later found out 
there were/are some iFix problems...maybe the two are related?? 
Tried to restart Smacs, but partial restarts did not work. 
Had PC do a full "restart", and proceeded by scratch. I tried 
following the various bits of intstructions in the TOF (paper) 
logbook carefully, and did not get Smacs to run through its 
monitor loop....it did seem  to function as far as ON/OFF is 
concerned, but did not update color status. I THINK the error 
in my efforts may have been to  start Smacs by the icon 
"Smacs_iFixClient.exe" rather than "Smacs.exe" icon (and in 
both cases open the iFix version of the "1_2_3" crate version. 
Perhaps "Smacs_iFixClient.exe" is pointing to obsolete code??? 
 
***************be careful what version you load in********** 
</pre>
<!-- Author: gbauer -->


<!-- Date: Wed Jun 20 02:01:09 2001 -->
<pre>Around 11:00pm quad quenched. 
Got paged at 12:22. 
Started working on TAC calibration at 12:59. 
WCAL_02 and WCAL_06 were not partitioned when I loaded TOF_DDG_TEST, so added them. 
Finally finished calibration safely and the data look OK. 
The program running itself took about 45 minutes. 
</pre>
<!-- Author: Koji Sato -->


<!-- Date: Thu Jun 21 02:03:52 2001 -->
<pre>At around 1:45 came up to the control room to check the HV, 
and found out that SMACS was freezed. 
The icon stayed on the task bar but did not show up a window 
when I hit it.  iFix looked OK. 
 
Killed the SmacsProject from TaskManager and started it again. 
HV looks operating OK.   
It doesn't show a sign in the control room monitor and I don't know whether it is supposed to or not. 
 
This process took place during run #118331, for later reference. 
</pre>
<!-- Author: Koji Sato -->


<!-- Date: Thu Jun 21 13:23:24 2001 -->
<pre>At end of store, turned OFF the Time of Flight HV, and restarted iFIX and SMACS from scratch (approximately 13:10) 
Accelerator beam studies will go on until 17:00 (they claim). 
SMACS was NOT monitoring the HV status, all the bars were light green. Seems OK after restart.</pre>
<!-- Author: Gervasio -->


<!-- Date: Thu Jun 21 18:02:24 2001 -->
<pre>TAC calibration: 1 ns scan, all channels active.  
Things look fine. Will try to do 0x30,0x50 and 0x90 next end of store. Fixed minor bugs in avglv1 code.</pre>
<!-- Author: Gervasio -->


<!-- Date: Fri Jun 22 09:24:34 2001 -->
<pre>The HV SMACS program is again in a state where all the colors are light green. The scrolling bar at the bottom is running this time. Checked YMON display to make sure ToF plots look OK.  
HV is set correctly, but the monitoring seems to hang often.</pre>
<!-- Author: Gervasio -->


<!-- Date: Sat Jun 23 13:05:22 2001 -->
<pre>I did ToF Calib with CAL_ENALBE 0x30 and 0x50.</pre>
<!-- Author: Minsuk -->


<!-- Date: Mon Jun 25 12:42:22 2001 -->
<pre>Performed TAC calibration with Non-standard settings 
 
./register b0wcal02 9 -set CAL_ENABLE 0x90 
./register b0wcal06 9 -set CAL_ENABLE 0x90 
 
 
</pre>
<!-- Author: mike mulhearn -->


<!-- Date: Mon Jun 25 18:01:15 2001 -->
<pre>Tried to run the jpython script to automatize the TAC calibration. Still crashes at second iteration...</pre>
<!-- Author: Gervasio Gomez -->


<!-- Date: Tue Jun 26 01:37:24 2001 -->
<pre>At around 00:30 came up to the control room to check HV. 
 
iFix was not working. Maybe just that the workspace was not opened. 
The shift persons were taking test runs waiting for the store to be stable.  
And HV was set off about 30 min. ago (I believe this is what they 
were supposed to do). 
 
Seeing Rolf's recent reports about HV problems, I thought it was  
a good opportunity to check and restart the HV software. 
Seeing solenoid was locked, I tried to put the HV on and found 
that SMACS was showing some trips in disabled channels and all the other channels on including the disabled ones. 
 
As I was impressed that only restarting softwares does not 
solve these problems, I restarted the PC, started iFix and SMACS 
and loaded fnal_b14kG_g30k_6W6E_chan.suf. 
After this reseting, everything appeared OK except that one 
chennel (ch227) remained "tripped" in iFix (although this 
appeared recovered in SMACS). 
 
As I was just in time for the new shot(run 118723), I decided to 
leave ch227. 
 
</pre>
<!-- Author: Koji Sato -->


<!-- Date: Wed Jun 27 10:23:39 2001 -->
<pre>Tried to make a TAC calibration. 
Data coming out but for some reason TAC return values always stay 397X (overflow). 
 
Cannot find Matthew or Rolf.  Anyway they are not making controlled access. 
 
Checked that DDG is accessed and triggering by looking at the LEDs. 
 
Gave up the calibration for the moment.</pre>
<!-- Author: Koji S. and Gervasio -->


<!-- Date: Wed Jun 27 13:43:34 2001 -->
<pre>I think this is the series of events which took place... 
1.  At 5:00 pm June 27th, Rick Tesarek unplugged the common 
    stop cable from the CIC module but then forgot which 
    connector it came from.  It was plugged into the external 
    trigger input of the CIC module.  Hence, nothing was getting 
    the common stop signal even though the calibration signal 
    got generated and fanned out... hence the overflows. 
2.  I checked the voltages on the boards using the power monitor 
    ADC's and all seemed fine.  However, turning on the clock 
    monitor did not give any pulses out. 
3.  Steve Vejcik stared pulling the pulser crate apart at about 
    12:00.  I helped him put it back together and get their DDG 
    configuration code working.  That corrected the misplaced 
    LEMO cable from the CIC module and we got clock signals on 
    b0wcal06 but not b0wcal02. 
4.  Koji and I went down to look at b0wcal02 and found that the 
    -5.2 volt power supply was in a fault condition.  We told 
    Steve Hahn who came down and reset the power supply. 
    Now we see clock signals. 
 
I think everything is back to normal now. 
 
Koji & Matthew </pre>
<!-- Author: mjones -->


<!-- Date: Fri Jun 29 12:15:50 2001 -->
<pre>At around 11:15 store ended. 
Tried to refresh the iFix HV monitor, but almost all the channels 
turned RED after resetting the PC.  Don't know how to refresh them 
without solenoid on.  Gave up this refreshing and told the  
monitoring to concentrate on the elec-installed channels. 
</pre>
<!-- Author: Koji Sato -->


<!-- Date: Fri Jun 29 14:39:24 2001 -->
<pre>Finished a TAC calibration. 
It took about 45 min. this time. 
 
</pre>
<!-- Author: koji sato -->


<!-- Date: Tue Jul 3 09:54:07 2001 -->
<pre>Finished a TAC calibration.  I am saving the output files I generate in the directory ~cdf_tof/mulhearn/.</pre>
<!-- Author: Mike Mulhearn -->


<!-- Date: Wed Jul 4 02:42:42 2001 -->
<P> 
The COT tripped, then had trouble with the solenoid interlock while restoring HV.  See <a href= 
'/cgi/elog/elog.pl?nb=2001&action=view&page=452&frame=2&anchor=02:05:28'> 
shift log</a>.  
As far as I can tell, the interlock was not broken for TOF and the HV remained on.   
</P> 
<P> 
The history is not enabled.  In the morning I will find out why. 
</P>
<!-- Author: Mike Mulhearn -->


<!-- Date: Wed Jul 4 03:10:42 2001 -->
To reassure myself that all is well before going back to bed, I checked the first 1000 events in run 119334.  This is the first run after the <a href= 
'/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=1&frame=2&anchor=02:42:42'> 
COT HV trip</a>.  There are non-zero TDC counts for all channels from 144-149 and 360-365 except 147.  This is <a href= 
'/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=1&frame=2&anchor=22:33:22'> expected</a>.   
<!-- Author: Mike Mulhearn -->


<!-- Date: Sat Jul 7 18:44:08 2001 -->
<pre>Turned on HV.</pre>
<!-- Author: Mike Mulhearn -->


<!-- Date: Sat Jul 7 20:16:57 2001 -->
<pre>I have checked for TOF data in roughly one run per shift to make sure everything is OK.  These runs had non-zero TDC counts in the expected channels:  119346, 119359, 119360, 19406, 119423, 119506, 119539, and 119615.  The HV was off for run 119388.</pre>
<!-- Author: mulhearn -->


<!-- Date: Sun Jul 8 13:14:34 2001 -->
<P> 
Checked HV, program was hung.  I had to do a hard reboot.  I had some troubles restarting the program until Gerry helped. 
</P> 
<P> 
Restarting the program does not bring down the HV.   
</P> 
<P> 
One channel was tripped even though it was set to off, giving a red condition.  The only way to reset this trip condition without using the reset all channels feature was to turn it on then off.  We should add the capacity to reset an individual trip. 
</P>  
<!-- Author: Mike Mulhearn -->


<!-- Date: Wed Jul 11 17:48:23 2001 -->
<pre>Performed QIE calibrations using qietest script for crates 
b0wcal03, b0wcal07. Slot 7 of b0wcal03 fails the calibration because the DAC self calibration fails. 
Downloaded FRAM.</pre>
<!-- Author: Gervasio -->


<!-- Date: Thu Jul 12 00:44:59 2001 -->
<pre>Pager from control room at last 10:30 pm with messages "ramp solenoid, turn on COT HV, and not working iFix/smacs". I recognized it has remained off ever since Daniele worked for software development during yesterday. I don't know how much HV monitoring was improved. 
 
After coming and starting ifix and smacs, let SciCo know that. ToF HV was on. For activating channel history, the inadequate save directory for monitor file was modified. Now the monitor works. this eve/owl run is cosmic L2 test run for 1 million evts.</pre>
<!-- Author: Minsuk -->


<!-- Date: Thu Jul 12 10:08:38 2001 -->
<pre>Magnet tripped at 6:40 am, COT HV did trip and so, ToF HV off. refer &lt;a href='/cgi/elog/elog.pl?nb=2001&action=copyentry&page=476&time=07:56:18'&gt;Shift summary&lt;/a&gt; 
 
When starting of day shift, computers were down and DB unavailable for at least 2 hours. 
</pre>
<!-- Author: Minsuk -->
<!-- Comment: Thu Jul 12 10;25;49 comment by...Minsuk -->
refer to <a href=
'/cgi/elog/elog.pl?nb=2001&action=view&page=476&frame=2&anchor=07:56:18'>
owl shift summary</a> 


<!-- Date: Thu Jul 12 23:13:10 2001 -->
<pre>From about 10:30 pm, cosmic ray test run started. 
Solenoid on, so turned the COT and TOF voltages on. 
Ace person paged to ask why all channel have green color and whether this means all chnnel's HV on. I answered it's fine.</pre>
<!-- Author: Minsuk -->


<!-- Date: Fri Jul 13 17:17:30 2001 -->
<pre>Installed 6 transition boards in wcal07.  Fixing up hardware 
database. 
 
</pre>
<!-- Author: m jones -->


<!-- Date: Fri Jul 13 18:04:14 2001 -->
<pre>Installed in b0wcal07: 
 
             slot 5 slot6  slot7  slot8  slot9  slot10 
TOMAIN#       0x06   0x09   0x0e   0x0a   0x08   0x07 
Frontpanel#   5098   5097   5101   5096   5099   5100 
TOAD0#        1551   1566   1580   1574   1560   1559 
TOAD1#        1553   1567   1577   1576   1562   1565 
TOAD2#        1556   1568   1579   1549   1563   1557</pre>
<!-- Author: Rolf -->


<!-- Date: Fri Jul 13 22:22:50 2001 -->
<pre>The ifix/smacs program is working with magnet off at this moment. 
I got paged from control room whenever cosmic test run late in the evening because program was not running concerned with program development. Today Daniele considered cosmic test run and so let program be running.</pre>
<!-- Author: Minsuk -->


<!-- Date: Sun Jul 15 10:41:17 2001 -->
<pre>Magnet Off, I take control for short time </pre>
<!-- Author: Daniele -->


<!-- Date: Sun Jul 15 11:25:27 2001 -->
<pre>Smacs system back to run mode 
</pre>
<!-- Author: Daniele -->


<!-- Date: Mon Jul 16 09:06:25 2001 -->
<pre>I'm trying to track down the reason for slot 10 not working 
in b0wcal03 and b0wcal07.  So far I have verified that all 
installed cards receive STOP, CAL and RESET except for slots 
10 in b0wcal07 and b0wcal03.  These ones get STOP and RESET 
but not CAL.  Next I will interchange two clock cables to see 
if the problem is with the LCF+clock cable or with the TOMAIN.</pre>
<!-- Author: mjones -->


<!-- Date: Mon Jul 16 09:53:55 2001 -->
<pre>Swapped clock cables on slots 10 and 9 in b0wcal03.  Now it is 
slot 9 that does not get the CAL signal.  So, the problem is 
either the clock cable or the LCF module.  Now we will try swapping the cable with another one.</pre>
<!-- Author: mjones -->


<!-- Date: Mon Jul 16 10:02:31 2001 -->
<pre>Swapped the clock cable at the LCF module and the problem stays 
in slot 9.  Therefore, it's the cable.  We will now replace the 
cable with a spare one from upstairs.</pre>
<!-- Author: mjones -->


<!-- Date: Mon Jul 16 10:16:11 2001 -->
<pre>Replaced the cable on slot 9 and now slots 8, 9 and 10 get 
all their clock signals in b0wcal03. 
 
Now let's have a look at the east end... 
</pre>
<!-- Author: mjones -->


<!-- Date: Mon Jul 16 10:28:16 2001 -->
<pre>Swapped clock cables on slots 9 and 10 in b0wcal07.  The 
CAL problem moves to slot 9.  We will now replace the clock 
cable.</pre>
<!-- Author: mjones -->


<!-- Date: Mon Jul 16 10:42:34 2001 -->
<pre>Replaced the clock cable which was now in slot 9 and all 
clock signals work in b0wcal07 now.  I guess it was just 
a wierd coincidence that it was the CAL signal in slot 10 
on both ends.  I think that given that we have two failures 
in out of 27 clock signals we can look at then there is a 3.8% 
chance of them being on exactly opposite ends of the detector 
for the same clock signal. 
</pre>
<!-- Author: mjones -->


<!-- Date: Mon Jul 16 10:47:19 2001 -->
<pre>I take the hv computer control. </pre>
<!-- Author: Daniele -->


<!-- Date: Mon Jul 16 15:22:58 2001 -->
<pre>I did a quick check with the pulser and avglv1, and I find: 
  
b0wcal07: all slots, all channels OK 
b0wcal03: slot 8: ch5 fails (ch2 on middle toad) 
          slot 9: ch2 fails (ch2 on upper toad) 
          slot10: ch0 fails (ch0 on upper toad)                                 </pre>
<!-- Author: rolf -->


<!-- Date: Tue Jul 17 02:41:59 2001 -->
<pre>I've just tried loading configulation files for HV generated by 
my newly developed program(This time not edited by hand). 
This went on pretty well without any problem. 
 
The next check should be a real operation check when the magnet 
comes on.</pre>
<!-- Author: koji sato -->


<!-- Date: Tue Jul 17 06:47:20 2001 -->
<pre>I did cafe delay scans for all instrumented channels. 
(1 ns steps from 90 to 150 ns, see ~cdf_tof/tunecafedelay) 
I haven't made plots or fits yet, but I learned several things from  a 
quick analysis of the ascii files. 
  
- The timing between the intrumented crates/slots differs less than 5 ns. 
  (I'm glad to see this, it includes both tof_clock and cdf_clock) 
  
- The TAC plateau typically stretches from 104-125 ns. 
  (plateau defined as the range &lt;5 counts from the value at 115ns) 
  the start of the plateau ranges from 102 to 106 ns, the end of the 
  plateau from 122 to 129 ns. 
  (NB: the end of the plateau depends on the height of the plateau: early 
  pulses have a higher TAC output and a shorter plateau. This test was 
  done with a high TAC output, around 3100 DECAF counts) 
  
- I think the present default value in the hardware database is 0x78=120. 
  That is at the end of the plateau for all instrumented channels, like it 
  should be (cafe_delay should be as large as possible to prevent charge 
  leaking into the next bucket). It is a bit thight for those channels 
  whose plateau ends at 122 ns, but I wouldn't change it now. 
  
 
  
                plateau (ns) 
b0wcal07 slot 5  105-126    (NB, determined from ch0 only, should 
         slot 6  106-129     be verified for other channels) 
         slot 7  105-127 
         slot 8  105-128 
         slot 9  104-127 
         slot10  105-127 
b0wcal03 slot 8  104-124 
         slot 9  102-122 
         slot10  104-124 
b0wcal02 slot 9  103-127 
b0wcal06 slot 9  102-124                                                        </pre>
<!-- Author: Rolf -->


<!-- Date: Tue Jul 17 18:28:34 2001 -->
<pre>Replaced 3 toads on the wcal03 tomains: 
 
slot 8, tomain 0x14, channel 5 bad, replaced toad 1546 by 1539. 
slot 9, tomain 0x13, channel 2 bad, replaced toad 1510 by 1544. 
slot10, tomain 0x1a, channel 0 bad, replaced toad 1504 by 1545. 
(bad means here that the TAC does not respond to the calibration 
signal)  
The channels are fixed now, but there is a new one in 
slot 8, channel 2. 
I have the suspicicion that it all has to do with how well the 
toads are plugged into the tomain.</pre>
<!-- Author: Rolf -->


<!-- Date: Wed Jul 18 07:48:22 2001 -->
<pre>TOAD status. Last updated July 18 2001  
 
 S/N location 
 001 FNAL   pre-production, installed on CDF 
 002 FNAL   pre-production, Fermilab 
 003 FNAL   pre-production, installed on CDF 
 004 FNAL   pre-production, installed on CDF 
 005 FNAL   pre-production, installed on CDF 
1500 Penn   hand stuffed 
1501 0x0d_0 OK (used for TOMAIN checkout) 
1502 0x0d_1 OK (used for TOMAIN checkout) 
1503 0x0d_2 SUSPECT high resistance GND-POWER large (used for TOMAIN checkout) 
1504 FNAL   SUSPECT (damaged EL05, calib signal fails ch0) 
1505 0x1a_1 OK 
1506 0x1a_2 OK 
1507 0x14_0 OK 
1508 FNAL   SUSPECT - low resistance GND-POWER 
1509 0x16_2 OK 
1510 FNAL   SUSPECT - calibration signal fails on ch2 
1511 FNAL   SUSPECT - low resistance GND-POWER 
1512 0x13_2 OK 
1513 FNAL   SUSPECT  -low resistance GND-POWER 
1514 0x13_1 OK 
1515 0x12_2 OK (missing 0.1uF on bottom put on by hand) 
1516 FNAL   OK 
1517 FNAL   OK 
1518 FNAL   OK 
1519 FNAL   OK 
1520 FNAL   OK 
1521 FNAL   OK 
1522 FNAL   OK 
1523 FNAL   OK 
1524 FNAL   OK 
1525 FNAL   OK 
1526 FNAL   OK 
1527 FNAL   OK 
1528 FNAL   OK 
1529 FNAL   OK 
1530 FNAL   OK 
(1531 does not exist - missing S/N label) 
1532 0x12_0 OK 
1533 FNAL   SUSPECT  - low resistance GND-VCC 
1534 0x12_1 OK 
1535 0x14_2 OK 
1536 FNAL   OK 
1537 FNAL   OK 
1538 0x2e_0 OK 
1539 0x14_1 OK 
1540 0x10_2 OK 
1541 FNAL   SUSPECT 
1542 FNAL   OK 
1543 FNAL   SUSPECT 
1544 0x13_0 OK 
1545 0x1a_0 OK 
1546 FNAL   SUSPECT - calibration signal fails on ch2 
1547 0x0a_0 OK 
1548 FNAL   SUSPECT - low gating pedestal 
1549 0x0a_2 OK 
1550 0x16_1 OK 
1551 0x06_0 OK 
1552 FNAL   BAD - missing resistor 
1553 0x06_1 OK 
1554 FNAL   SUSPECT - low gating pedestal 
1555 0x16_0 OK 
1556 0x06_2 OK 
1557 0x07_2 OK 
1558 FNAL   SUSPECT - low gating pedestal 
1559 0x07_0 OK 
1560 0x08_0 OK 
1561 FNAL   BAD - no calibration pulse to ch1 
1562 0x08_1 OK 
1563 0x08_2 OK 
1564 FNAL   BAD - lifted 402 
1565 0x07_1 OK 
1566 0x09_0 OK 
1567 0x09_1 OK 
1568 0x09_2 OK 
1569 0x0c_0 OK 
1570 FNAL   BAD - high resistance GND-Q_BUFFER3 - plots fail  
1571 FNAL   BAD - high resistance - plots fail 
1572 0x10_1 OK 
1573 0x0c_2 OK 
1574 0x10_0 OK 
1575 0x0c_1 OK 
1576 0x0a_1 OK 
1577 0x0e_1 OK 
1578 FNAL   SUSPECT - high resistance VCC5-GND  
1579 0x0e_2 OK 
1580 0x0e_0 OK 
1581 0x29_1 OK 
1582 FNAL   SUSPECT - low resistance GND-D9SIG 
1583 0x21_2 OK 
1584 0x29_2 OK 
1585 0x29_0 OK 
1586 FNAL   SUSPECT - low resistance GND-D9SIG 
(1587 does not exist - missing label)  
1588 FNAL   BAD - missing resistor 
1589 0x22_2 OK 
1590 FNAL   BAD - missing capacitor 
1591 0x21_1 OK 
1592 FNAL   SUSPECT 
1593 FNAL   OK 
1594 FNAL   OK 
1595 FNAL   SUSPECT 
1596 0x22_0 OK 
1597 0x28_1 OK 
1598 0x15_2 OK 
1599 FNAL   BAD - one channel fails  
1600 FNAL   SUSPECT - low gating pedestal  
1601 FNAL   BAD - missing resistor   
1602 FNAL   SUSPECT 
1603 FNAL   BAD - missing resistor 
1604 0x28_0 OK 
1605 FNAL   SUSPECT - low gating pedestal 
1606 0x28_2 OK 
1607 0x1d_1 OK 
1608 0x22_1 OK 
1609 0x1d_2 OK 
1610 0x15_1 OK 
1611 0x1d_0 OK 
1612 0x21_0 OK 
1613 0x15_0 OK 
1614 FNAL   SUSPECT - low resistance GND-VCC5 
1615 0x2e_2 OK 
1616 0x2a_1 OK 
1617 FNAL   BAD lifted pin on ch0 EL05 
1618 0x2a_2 OK 
1619 FNAL   SUSPECT - low resistance GND-T0 
1620 0x2d_1 OK 
1621 0x2d_0 OK 
1622 FNAL   SUSPECT 
1623 FNAL   BAD - lifted pin 
1624 0x2d_2 OK 
1625 0x2f_0 OK 
1626 FNAL   BAD - lifted pin 
1627 FNAL   SUSPECT - one resistor on its side 
1628 0x2f_2 OK 
1629 FNAL   SUSPECT - low resistance GND-SIG2 
1630 0x2f_1 OK 
1631 FNAL   SUSPECT - low gating pedestal 
1632 FNAL   SUSPECT - calibration signal fails on ch2 
1633 0x2b_2 OK 
1634 0x2a_0 OK 
1635 0x2b_0 OK 
1636 FNAL   SUSPECT - low gating pedestal 
1637 0x2b_1 OK 
1638 FNAL   SUSPECT - low gating pedestal 
1639 0x2e_1 OK 
1640 0x2c_2 OK 
1641 0x2c_1 OK 
1642 0x2c_0 OK 
1643 FNAL   OK 
1644 FNAL   OK 
1645 FNAL   OK 
1646 FNAL   SUSPECT - low gating pedestal 
1647 FNAL   SUSPECT - low gating pedestal 
1648 FNAL   OK 
1649 FNAL   BAD - missing 402 resistor on bottom 
1650 FNAL   OK 
1651 FNAL   OK 
1652 FNAL   OK 
1653 FNAL   BAD - wrong resistor on bottom side 
1654 FNAL   OK 
1655 FNAL   OK 
1656 FNAL   SUSPECT - resistance GND-POWER small 
1657 FNAL   SUSPECT - GND-TRAFO_OUT small/Samtec connector problem 
1658 FNAL   OK 
1659 FNAL   OK 
1660 FNAL   OK 
1661 FNAL   OK 
1662 FNAL   OK 
1663 FNAL   OK 
1664 FNAL   BAD - ch0 fails 
1665 FNAL   BAD - GND-TRAFO_OUT large / ch1 fails 
1666 FNAL   OK 
1667 FNAL   SUSPECT - low resistance GND-POWER  
1668 FNAL   OK 
1669 FNAL   SUSPECT - low resistance GND-POWER 
1670 FNAL   OK 
1671 FNAL   OK 
1672 FNAL   OK 
1673 FNAL   OK 
1674 FNAL   OK 
1675 FNAL   OK 
1676 FNAL   OK 
1677 FNAL   OK 
1678 FNAL   BAD - 9 chips not stuffed 
1679 FNAL   BAD - 9 chips not stuffed 
1680 FNAL   BAD - 9 chips not stuffed 
 
 
 
</pre>
<!-- Author: Rolf -->


<!-- Date: Thu Jul 19 19:20:08 2001 -->
<pre>Went down with Gerry to get b0wcal03 up after Rick's tests. 
We pulled out 4 of the transistion modules and left only 
slot 9 and 10 occupied. Also put in a filed Z-module. 
Did a cafe_delay scan on the TAC output and found that 
in slot 10 ch2 fails, in slot 9 ch0 fails. 
These failures are attributed to the misplaced D9-hole in the 
front panel.</pre>
<!-- Author: Rolf -->


<!-- Date: Thu Jul 19 21:15:46 2001 -->
<pre>Smacs-iFix connection tested and working. 
Now it is possible switch on/off and get channels parameters  from iFix in CR. 
More improvenments in few days. 
</pre>
<!-- Author: Daniele -->


<!-- Date: Sun Jul 22 22:52:00 2001 -->
<pre>Finished installing electronics in b0wcal04.  While cabling up 
the boards I saw the VTT power trip off.  The AC power was still 
on so I unplugged the AC power cord and left it until I had 
finished cabling.  The VTT LED's then came on...  this might be 
a problem with the Vicor module itself.  So, we should keep an 
eye on this supply and swap it if necessary.</pre>
<!-- Author: mjones -->


<!-- Date: Mon Jul 23 01:07:42 2001 -->
<pre>Finished installing for tonight.  Swapped VTT supply with the 
next one on the list...  the problem might be the thermal 
shutdown set a little low.  The supply is currently unplugged 
but could be plugged back in tomorrow when people are around 
to notice any wierdness. 
 
Here's what we installed in b0wcal04: 
 
Slot  Penn S/N  TOMAIN S/N  PCI S/N  TOAD S/N 
  5     5123      0x1f      001228   1673, 1674, 1660 
  6     5122      0x20      001219   1530, 1536, 1537 
  7     5121      0x11      001172   1659, 1658, 1661 
  8     5124      0x1b      001199   1672, 1654, 1663 
  9     5126      0x1e      001227   1662, 1666, 1675 
 10     5125      0x18      001193   1671, 1668, 1655</pre>
<!-- Author: Matthew/Rolf/Gerry -->


<!-- Date: Mon Jul 23 13:23:47 2001 -->
<pre>Finished installing in b0wcal01.  Now checking out b0wcal03 
since the PEI supply got swapped this morning.  The board 
in slot 5 is not behaving correctly...  the serial number is 
not read back correctly.  We will swap it with TOMAIN 0X2F 
PCI S/N 001186, TOAD S/N 1625, 1630, 1628. 
</pre>
<!-- Author: mjones -->


<!-- Date: Mon Jul 23 20:06:15 2001 -->
<pre>Problems with B0wcal01, the crate failed the "setup" transition 
of the qie state diagram. I rebooted the crate but I get the 
same error...  I wonder if the mismatch between the s/n 
stored  in the hwd database and the actual board s/n can trigger 
this error... I  remove the crate from the qie calibration  
run set.  
 
That's the error...  
 
b0wcal01-&gt; Messenger: processStatechange Config [0] 
Slot  2: 0087 001 TRACER__V2.1A           
Slot  5: 0134 003 ADMEM_V4.0          470 
Slot  6: 0344 003 ADMEM_V4.0          460 
Slot  7: 0317 003 ADMEM_V4.0          470 
Slot  8: 0323 003 ADMEM_V4.0          470 
Slot  9: 0143 003 ADMEM_V4.0          470 
Slot 10: 0369 003 ADMEM_V4.0          460 
Slot 16: 0295 003 ADMEM_V4.0          470 
Slot 17: 0308 003 ADMEM_V4.0          470 
Slot 18: 0190 003 ADMEM_V4.0          470 
Slot 19: 0374 003 ADMEM_V4.0          460 
Slot 20: 0368 003 ADMEM_V4.0          460 
Slot 21: 0297 003 ADMEM_V4.0          470 
Messenger: processReadoutlist 
 
Current r/o settings: 
--------------------- 
EVB node / port  b0dap62 / 6501 
Crate Id         18 
Output-&gt;EVB/VRB  1/0 
Trigger mode     2 
Verbosity:       Minimal 
Mode             0  (RE 0) 
 
TRACER: VISIONopen Name=geo32:/slot=2 
TRACER: done enabled 
ADMEM: VISIONopen Name=geo32:/slot=5 
ADMEM: VISIONopen Name=geo32:/slot=6 
ADMEM: VISIONopen Name=geo32:/slot=7 
ADMEM: VISIONopen Name=geo32:/slot=8 
ADMEM: VISIONopen Name=geo32:/slot=9 
ADMEM: VISIONopen Name=geo32:/slot=10 
FER_imp: setting cafe sleep default = 25 
ADMEM_setCafeSleep: set to 25 
Configuring  6 TOF ADMEMs 
Slot 5: 
  Configuring TOMAIN S/N = 0x23 (00) 
  Hardware/database serial numbers do not match.  VCC5= 0.000 V, VEE5= 0.000 V, VCC15= 0.000 V, VEE15= 0.000 V, VTT= 0.000 V 
 
Floating point divide by zero 
Floating point inexact 
Exception current instruction address: 0x00e06e78 
Machine Status Register: 0x0010b130 
Condition Register: 0x42000088 
Fp Control and Status Register: 0xc6004070 
Task: 0xe85c38 "Messenger" 
 
Floating point underflow 
Floating point divide by zero 
Floating point inexact 
Floating point invalid operation for INF - INF 
Floating point invalid operation for INF / INF 
Floating point invalid operation for 0 / 0 
Floating point invalid operation for invalide compare 
Floating point invalid operation for software request 
Floating point invalid operation for square root 
 
program 
Exception current instruction address: 0x00282134 
Machine Status Register: 0x0011b130 
Condition Register: 0x24000000 
Task: 0xe37360 "Mon_III" 
 
</pre>
<!-- Author: Ivan  -->
<!-- Comment: Mon Jul 23 20;08;45 comment by...Ivan  -->
<pre>I just forgot to comment that after this error the
FER_messenger and monitor proccess are suspended.

</pre>

<!-- Comment: Tue Jul 24 02;36;57 comment by...rolf -->
<pre>This error shows up if the hardware database is not updated
for just-installed transistion boards.
What happens is that the calibration-constants for transforming
adc-counts to voltages are set to zero, and then then a division by
zero follows. We hadn't finished updating the database this morning.
Matthew promised to update the code that is will take a 
reasonable average for the calibration constants instead of zero</pre>


<!-- Date: Tue Jul 24 02:40:03 2001 -->
<pre>Installed transistion boards in b0wcal05. 
Replaced ADMEM in b0wcal01, slot 8. It didn't let us talk well 
with the transistion board. 
</pre>
<!-- Author: Matthew, Gerry, Rolf -->
<!-- Comment: Tue Jul 24 02;46;58 comment by...Matthew, Gerry, Rolf -->
<pre>Also repaired 3 channels in b0wcal07, slot 10: Apparently the TOAD
had completely fallen off (The TOMAINs in b0wcal07 and b0wcal03 have the unmodified
front-panels that do not allow the TOAD to be fully connected. </pre>


<!-- Date: Tue Jul 24 13:22:51 2001 -->
<pre>QiePed Consumer updated, we are using the same consumer used 
by the calorimeter folks. We also found a bug on the 
shell script launched by Run Control. Issues addressed: 
 
The consumer ends automatically after the active transition ends 
 (it is worth to have the proxy consumer display open to see when 
 the consumer finishs sending the data) 
 
The calibrations can be downloaded. 
 
The consumer is going to be compatible with the new sevb.  </pre>
<!-- Author: Ivan, Gervasio -->


<!-- Date: Tue Jul 24 14:16:42 2001 -->
<pre>TAC calibration using Python script. 
5000 events per channel,  the script worked fine  
14 time delays every 5ns. Run number 121441.</pre>
<!-- Author: Gervasio, Ivan  -->


<!-- Date: Wed Jul 25 21:58:54 2001 -->
<pre>Many change done to Smacs program. 
Now i leave it running for test porpouse with file set up:    smaller_b14kG_g30k_E162W168. 
I'll come back asap 
 
 
</pre>
<!-- Author: Daniele -->


<!-- Date: Wed Jul 25 22:47:45 2001 -->
<pre>'smaller_b14kG_g30k_E162W168.suf' should be used for SMACS 
setting in the next runs. 
It's already in the StandardSettings folder in the PC. 
 
Smaller HV value between the two values calculated using FNAL and 
TSUKUBA test stand data is used for each PMT after Gerry's 
suggestion. 
</pre>
<!-- Author: Koji -->


<!-- Date: Thu Jul 26 02:38:22 2001 -->
<pre>Smacs started running  
   setup file : smaller_b14kG_g30k_E162W168 
   Monitor file : cosmicRun_7_26_01   (rate 60 min) 
 
All channels work well 
 
Present version of iFix copied on server and fully working from control room. 
 
Quick training done to shift crew 
 
</pre>
<!-- Author: Daniele -->


<!-- Date: Thu Jul 26 14:56:27 2001 -->
<pre>Tof1 computer controlling the HV power supply shuts down due to main power cut in B0 hall. 
System restarted at 2:50 PM</pre>
<!-- Author: Daniele -->


<!-- Date: Fri Jul 27 23:38:51 2001 -->
<pre>The following changes done: 
-size of picture now is smaller 
-add button to reset trip 
-add button to refresh data base 
-Status messagenow show correct information both for smacs and magnet 
 
Program is running</pre>
<!-- Author: Daniele -->


<!-- Date: Sat Jul 28 11:15:07 2001 -->
<pre>Program still running in perfect way</pre>
<!-- Author: Daniele -->


<!-- Date: Sun Jul 29 00:14:13 2001 -->
<pre>Rolf emailed around YMON plots of some short data taking 
from earlier this evening. one east tube looks way too 
high, and one way too low. i've changed the SMACS voltages 
(and saved them in the default HV file). in particular 
east tube #65 was 1390 -&gt; 1440 and #66 1963-&gt;1863V. 
hopefully this will help equalize response</pre>
<!-- Author: bauer -->


<!-- Date: Sun Jul 29 07:46:35 2001 -->
<pre>Tsukuba version of HV setting file is now in StandardSetting 
folder. 
It's "tsukuba_b14kG_g30k_E162W168.suf". 
 
The main feature : 
   - using Tsukuba parameters. 
   - for tubes not checked in tsukuba, use Penn without-field 
       test in the way Fumi indicated us. 
   - not-yet installed channels are charged with 50V. 
</pre>
<!-- Author: Koji -->


<!-- Date: Mon Jul 30 21:05:45 2001 -->
<pre>change on color display done. Still under test.</pre>
<!-- Author: Daniele -->


<!-- Date: Wed Aug 1 20:14:57 2001 -->
<pre>Now the picture in control room shows the correct color. 
The vertical bars provide the correct information (spreds respected set values). 
I leave the program running with  set up file 
 
  smaller_b14kG_g30k_E162W168.suf 
 
Magnet in on  
  </pre>
<!-- Author: Daniele -->


<!-- Date: Thu Aug 2 09:57:35 2001 -->
<pre>Finished manual TAC calibration. The purpose of this include checking the electronics in WCAL07 which were replaced yesterday. 
It took about one hour and ten minutes. 
Taking a rough look at the output text files, data look OK. </pre>
<!-- Author: Koji -->


<!-- Date: Fri Aug 3 11:49:50 2001 -->
<pre>Discovered two PMTs were turned off...no one seems to know 
how or why. They were PMT 16 and 242. Turned them back on 
around the time of a flying wire. Run 122640 and Event 21511. 
****KEEP AN EYE ON OUR HVs**********</pre>
<!-- Author: bauer -->


<!-- Date: Sat Aug 4 03:21:37 2001 -->
<pre>At around 1:10, came up to the control room to check the HV. 
They were all OFF except for channel 229 and downstairs, 
SMACS looked like hanged up. 
 
As Daniele had put a sheet saying "don't touch the PC" and 
I couldn't connect to him on the phone, I took him here from his 
house (1:40) and worked with him. 
 
We restarted the PC and put the HV on. 
 
Looked into what happened: 
   Yesterday evening between 19:02 and 20:02 the HV were put off 
   except for ch 229. 
   I think this is due to the solenoid ramping which took place  
   around this time. 
   After that the software itself was working with only ch.229 
   on.  This continued working until 23:46 and sometime after  
   that hang up. 
</pre>
<!-- Author: Koji -->


<!-- Date: Sat Aug 4 13:39:25 2001 -->
<pre>Smacs is running. 
Magnet OFF. 
 
</pre>
<!-- Author: Daniele -->


<!-- Date: Sat Aug 4 17:49:22 2001 -->
<pre>Smacs running. 
Magnet On 
I switched all system voltage ON</pre>
<!-- Author: Daniele -->


<!-- Date: Sun Aug 5 17:22:27 2001 -->
<pre>Smacs is running. 
Magnet ON 
All channels ON</pre>
<!-- Author: Daniele -->


<!-- Date: Mon Aug 6 23:02:58 2001 -->
<pre>gave ADMEM 300 and 369 to Fred. 
Both fail QIE calibration with the message: 
"Fail self calibration" 
300 was taken out earlier, about 2 weeks ago. 
369 was taken out tonight, from b0wcal01 slot 10, 
and replaced by ADMEM 323</pre>
<!-- Author: rolf -->


<!-- Date: Tue Aug 7 13:38:31 2001 -->
<pre>Finished TOF installation yesterday.  Here is what was installed: 
 
 Crate   Slot  TOMAIN S/N  Penn S/N  PCI S/N  TOAD0  TOAD1  TOAD2 
b0wcal02   5     0x2e      5138      001225   1538   1639   1615 
           6     0x4b      5113      001204   1543   1552   1588 
           7     0x1d      5115      001178   1611   1607   1609 
           8     0x28      5118      001222   1604   1597   1606 
           9     0x44      5140      001198   1586   1571   1541 
          10     0x30      5144      001181   1501   1502   1632 
 
b0wcal06   5     0x42      5139      001210   1622   1602   1600 
           6     0x33      5137      001207   1623   1603   1647 
           7     0x34      5143      001220   1617   1599   1601 
           8     0x40      5136      001211   1657   1649   1626 
           9     0x47      5141      001190   1592   1664   1595 
          10     0x45      5135      001192   1653   1646   1638 
</pre>
<!-- Author: Gervasio,Rolf,Matthew -->


<!-- Date: Tue Aug 7 14:57:56 2001 -->
<pre>I checked Smacs computer at 1:30 PM and it was down. 
The logger.txt file shows an interruption this morning  
around 5:30 AM.  
Investigating on I discovered there was been a local power cut  
in our racks (1RR04D and 1RR04C) due to a wrong intervention by someone (technichens ?) on power switchs suppling those racks. 
 
I restart the system. </pre>
<!-- Author: Daniele -->


<!-- Date: Wed Aug 8 17:37:46 2001 -->
<pre>At 14:00 I switched off iFix to let Mark Knapp do the implementation that we needed to see the status and the current in the magnet. Now everything is running.</pre>
<!-- Author: Alessandro -->


<!-- Date: Thu Aug 9 01:14:10 2001 -->
<pre>Placed 'smaller_b14kG_g30k_all_chan_mod.suf' in "standardsettings" dir in HV PC. 
This file enables all channels taking minimum values between  
tsukuba and fnal. 
Also includes the change made manually one week ago. 
 
Checked this file can be loaded without any problem by SMACS. 
</pre>
<!-- Author: Koji and Daniele -->


<!-- Date: Thu Aug 9 03:17:33 2001 -->
<pre>New Smacs version installed and running. 
It allow to sort the TreeView in either "Crate" or "Group". 
The group defined in 'smaller_b14kG_g30k_all_chan_mod.suf'  fileare "East" and "West" according the pm position. 
 
Magnet OFF  
Progran running</pre>
<!-- Author: Daniele -->


<!-- Date: Thu Aug 9 11:03:13 2001 -->
<pre>Modified SMACS HV to try to make chan response a bit more 
uniform by adjusting HV's based on YMON plots of 8/3. 
Changes: 
East: 
Chan   old HV   new HV 
 16     1789 -&gt; 1779 
 40     1481    1501 
 42     1787    1747 
 55     2020    1980 
 64     1902    1872 
 66     1863    1813 
 67     1429    1449 
 71     1748    1718 
West: 
232     1449    1419 
235     1598    1578 
240     1613    1600 
296     1441    1421 
306     1988    1968 
307     1528    1503 
308     1999    1979 
363     1683    1643 
364     1795    1755 
365     1915    1875 
 
..voltages in SMACS were modified, and the "default" 
file was overwritten, ie: 
smaller_b14kg_g30k_all_chan_mod.suf 
 
changes completed before we get (hopefully) a store  
</pre>
<!-- Author: bauerg -->


<!-- Date: Thu Aug 9 17:38:55 2001 -->
<pre>The CO pointed out a completely missing cell in the SL6 YMon occupancy plot for run 123359 (8/9 13:51).  Looking in more detail, the COT actually has 4 bad cells, corresponding to ASD cables in SL2 (cells 100/101) and SL6 (cells 54/55).  An access is required to fix the problems - likely badly plugged flat cables.  A request has been made to the Ops managers.</pre>
<!-- Author: R. Wagner -->