<!-- Title: 11:55:00  Tue Jan  1 2002 -->
<!-- Crewchief: Mr. T.O.F. -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>New File for the New Year</pre>


<!-- Date: Sun Jan 13 12:28:45 2002 -->
<P>The TOF HV crashed.  The ACE assured me that they were not successfully taking data at the moment, so I rebooted right away and restarted IFIX and SMACs.</P>
<!-- Author: mulhearn -->


<!-- Date: Tue Jan 15 02:48:03 2002 -->
<pre>TOF HV heartbeat lost, was called in to investigate..... 
 
---PC response was extremely sluggish, detector ring display  
was running and functioning, but took very long time for  
anything to happen. the main SMACs page was nowhere to be seen, 
although the task manager claimed the process was present!  
Also, as I moved the image of the ring display around the screen, 
ghost images persisted---something really bogus going on with 
the system! 
---I killed the processes with the task manager and restarted 
them. During the iFix startup i got message: 
"Alarm Area Database (ADD) file not found in config path 
F:\Dynamics\AADBACK.EXE" 
 ...i don't recall if this is normal or not..... 
also got error: 
 "Alarm queue "summary list" was over flowed" 
...have a feeling that is normal.... 
---I had the system resource monitor from the task manger feature 
running during part of this, and saw the CPU was 100% saturatued 
until I started killing processes---that did NOT look good 
---Now that i have everything running again, the CPU is STILL 
100% saturated. One of the aces on shift said they once had  
similar problems with SVX PC talking to iFix. They had TOO MANY 
VARIABLES and the communications overloaded the system or 
something. Maybe this is what is hanging the PC so often?? 
---Finally: I THOUGHT that when I restart the PC, and do NOT 
manually load in the HV file I could continue to run without 
tripping the HV. But once I got SMACS running I found the HV 
was off. I do not know if I tripped it, or it was already off. 
I either do NOT understand something, OR the start-up procedure 
has gotten overly automated so that it forced the reload and 
tripped the HV---a bad thing since we WERE taking data during 
all of this!!!</pre>
<!-- Author: bauerg -->


<!-- Date: Sat Jan 26 01:03:06 2002 -->
<pre>I got paged at 12:17 AM because the TOF heartbeat was lost. 
I came in and found that the PC was not hung but that the 
SmacsProject window was completely unresponsive and was using 
all the CPU.  Normally, the CPU usage is at 100% but dips down 
to 90% every few seconds but when I found it it was flat out 
at 100% continuously.  I killed the SmacsProject.exe process 
and restarted Smacs by clicking on the icon.  It came back up 
again and communication with iFix was restored.  I did not 
reboot the PC and did not restart any iFix processes on the 
PC.  The PC has been much more stable now that we don't run 
the iFix ring display locally but we still are having problems. 
 
So, doesn't this indicate that the problem is within Smacs? 
If it isn't the CAEN driver, wouldn't it have to be in the 
Smacs code?  Is there a race condition that puts it into an 
infinite loop? 
</pre>
<!-- Author: M Jones -->


<!-- Date: Sat Jan 26 12:04:25 2002 -->
<pre>At about 4:30 I got paged again because the CO couldn't turn 
on the TOF HV using iFix.  Sham was the SciCo and arranged for 
it to be turned on at the PC downstairs. 
 
At 9:30 I brought down the HV, rebooted the PC, started 
everything up again and the CO turned on the HV with iFix from 
upstairs.  This was during run 0x21b0a so it should eventually 
be marked as a bad run in the good-run database.  However, it 
was a lousy store with a luminosity of less than 1e30 so 
probably nobody will care. 
 
</pre>
<!-- Author: M Jones -->


<!-- Date: Sat Jan 26 12:08:19 2002 -->
<pre>One other thing...  after Smacs came up and loaded the 
configuration file, three channels in crate 0 immediately 
went into an alarm state.  I had to reset them but this 
had the undesirable effect of also turning them on.  So far, 
I have not seen a single instance of when we would want to 
reset a trip and actually turn the channel on.  So, I had to 
reset them and then turn them off after they started to ramp 
up.  Perhaps we can get this fixed some day?</pre>
<!-- Author: M Jones -->


<!-- Date: Sun Jan 27 14:35:44 2002 -->
<pre>I got paged regarding channel 20 not comming on at the start 
of store 931.  I found it in an 'undervoltage trip' state but 
'reset tripped channel' did not reset it.  Instead I had to 
turn it off (Smacs said that it was on) and then on again to 
get it to turn on.  I appears to be fine now. 
 
This all took place at about 10:50 during run 0x21b39.  We have 
no real record of which events had the HV off on this channel. 
It would be nice if we had Icicle recording this information for 
us.</pre>
<!-- Author: M Jones -->


<!-- Date: Wed Jan 30 09:37:07 2002 -->
<pre>The TOF PC hung again at about 9:00.  The ACE paged the TOF pager 
but got no response.  They phoned my office and I came in and 
had to reboot the pC.  This time it really was completely hung.</pre>
<!-- Author: M Jones -->


<!-- Date: Sat Feb 2 09:12:29 2002 -->
<pre>During the startup of store 948 I was paged due two  
HV channels not coming up when TOF HV was turned on. 
Cycling HV for this two channels fixed the problem.</pre>
<!-- Author: Stefano -->


<!-- Date: Thu Feb 7 14:18:51 2002 -->
At about 9:00 I got paged because the CO couldn't turn  
on the TOF HV using iFix.  
After rebooting the PC and restarted iFix & SMACS everything  
worked again. 
It seem to me that the problem is related to iFix comunication  
problems, in some circumstances (heavy load for the iFix servers  
in the control room) the comunication between TOF local iFix  
and the main iFix server take very long time (many minutes!) so  
that the tof1 PC will hang. I'll investigate that. 
 
 
 
At 9:30 I brought down the HV, rebooted the PC, started  
everything up again and the CO turned on the HV with iFix from  
upstairs.  This was during run 0x21b0a so it should eventually  
be marked as a bad run in the good-run database.  However, it  
was a lousy store with a luminosity of less than 1e30 so  
probably nobody will care.  
 
  
<!-- Author: Stefano -->
<!-- Comment: Thu Feb  7 14;21;18 comment by...Stefano -->
<pre>I dont know way but when I posted this message using html style 
I got together my message also a part of a previous message ..
so the correct part is the one from the start of message to 
the sentence " I'll investigate that ".

S.</pre>


<!-- Date: Sat Feb 9 07:50:35 2002 -->
<pre>Paged at 7:10 am because TOF had lost it's heartbeat. 
Found PC in a state where the CPU usage was at 100% all the time. 
Killed SMACS task, started a new one, and now it seems to be doing OK again.</pre>
<!-- Author: Gervasio -->
<!-- Comment: Sat Feb  9 07;58;26 comment by...Gervasio -->
<pre>No data loss (no collisions since yesterday morning)</pre>


<!-- Date: Sat Feb 9 07:59:29 2002 -->
<pre>TOF alarm: channel 66 tripped. 
Turning it off and on from control room didn't help. 
Resete this trip downstairs, seems to be fine now...</pre>
<!-- Author: Gervasio -->


<!-- Date: Sat Feb 9 08:57:38 2002 -->
<pre>Paged again about 8:40 am. Monitor ACE was not able to bring up the HV from the control room. Since there were still no collisions, exited SMACS, exited iFIX, and restarted the whole  
process. This seems to have fixed the problem. We are now ON and  
about to start recording data.</pre>
<!-- Author: Gervasio -->


<!-- Date: Mon Feb 11 10:18:00 2002 -->
<pre>   run#        L3 accepts     live lum (nb^-1)    TOF (YMON) 
 ========     ============   =================    ========== 
  
  138863        161759          30.66                OK 
  138864        190201          32.75                OK 
  138865         52591           9.48                OK 
  138868          8022           1.31                OK 
</pre>
<!-- Author: Gervasio -->


<!-- Date: Sat Feb 16 09:43:08 2002 -->
<pre>I was paged from the ACE because at 7:30/8:00AM the TOF HB  
was lost. I restarted the system and that fix the problem. 
It seem that something happen each monday morning that affect the TOF pc ... maybe the iFix backup/restore automatic procedure ? 
 
</pre>
<!-- Author: Stefano -->


<!-- Date: Wed Feb 20 12:25:39 2002 -->
<pre>TOF1 crashed due to the upgrade operation on the two iFix  
node servers. I restarted the system. Everithing fine now. 
</pre>
<!-- Author: Stefano -->


<!-- Date: Mon Feb 25 10:24:00 2002 -->
<pre>Saturday+Sunday: 
=============== 
 
Good data taken during the weekend: 
  
   run#        L3 accepts     live lum (nb^-1)      TOF 
 ========     ============   =================    ======= 
  
  139774         18542            4.35              OK 
  139775         14919            6.56            no YMON file 
  139776          7071            2.99            no YMon file 
  139778         18568            7.68              OK 
  139780          4180            1.65              OK 
  139781         27599           11.15              OK 
  139782         10057            4.00              OK 
  139783        101875           40.22              OK 
  139785         15524            5.71              OK 
  139786         68321           24.52              OK 
  139787         52576           18.08              OK 
  139788         39865           13.44              OK 
  139790 M.B.   102754            0.89          no YMon file 
  139798         66310           25.16              OK 
  139799        173093           52.22              OK 
  139800          3514            1.03              OK 
  139801          5791(& growing) 2.03(& growing)   OK 
</pre>
<!-- Author: Gervasio -->


<!-- Date: Tue Feb 26 10:46:16 2002 -->
<pre>   run#        L3 accepts     live lum (nb^-1)      TOF 
 ========     ============   =================     ===== 
  139801         62993           19.35               OK 
  139815          5281            1.38               OK 
  139817         15797            4.16               OK 
  139889         39538            2.25        BAD: empty, off?? 
  139891         60843           28.33               OK 
  139892         12484            5.69               OK 
  139893         14059            7.52               OK 
  139894         34922           14.84               OK 
  139895           597            0.27               OK 
  139897         39496           15.91  going on...  OK 
</pre>
<!-- Author: Gervasio -->


<!-- Date: Tue Feb 26 10:49:42 2002 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-109&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-109' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-110&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-110' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-111&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-111' width='300'></a></center>
<!-- Author: Gervasio -->
<!-- Comment: Tue Feb 26 10;50;42 comment by...Gervasio -->
<pre>These are YMon plots for the current run, 139897</pre>


<!-- Date: Tue Feb 26 10:53:33 2002 -->
<pre>Paged at 2 am. Channel 7 tripped 3 or 4 times, apparently its 
HV oscillated between nominal and 20 to 70 V lower than nominal. 
Had shifter turn it off and on and this seems to have fixed the problem. This did NOT affect any data as far as I can tell from 
YMon.</pre>
<!-- Author: Gervasio -->


<!-- Date: Tue Feb 26 18:04:15 2002 -->
<pre>Magnet is OFF, I take control of system for development. </pre>
<!-- Author: daniele -->


<!-- Date: Wed Feb 27 01:30:47 2002 -->
<pre>system hanguped. I reboot the system  
</pre>
<!-- Author: daniele -->


<!-- Date: Wed Feb 27 01:32:06 2002 -->
<pre>System put back to standard operation.</pre>
<!-- Author: daniele -->


<!-- Date: Wed Feb 27 16:19:59 2002 -->
<pre>   run#        L3 accepts     live lum (nb^-1)      TOF 
 ========     ============   =================     ===== 
  139897        129818           51.54               OK 
  139901         17383            6.42               OK 
  139906          2588            0.89            no YMon file 
</pre>
<!-- Author: Gervasio -->


<!-- Date: Wed Feb 27 20:13:57 2002 -->
<pre>since this morning, being the magnet OFF, I took the system for developments. 
Now, 8:15 PM, I leave a new version running. 
</pre>
<!-- Author: daniele -->


<!-- Date: Fri Mar 1 08:55:09 2002 -->
<pre>Paged at 8:00 because shift crew could not turn off the TOF from the control 
room. Had to force all system off from the PC. The magnetic field was on and 
so they dumped the beam with TOF on. Will page again when they need to turn 
on if needed. 
 
Good data taken: 
  
   run#        L3 accepts     live lum (nb^-1)      TOF 
 ========     ============   =================      ==== 
  140129        386453          179.51               OK 
  140131         58957           24.26               OK 
  140135         47054            7.44               OK 
</pre>
<!-- Author: Gervasio -->


<!-- Date: Fri Mar 1 11:29:23 2002 -->
<pre>No possible turn HV system ON from control room, 
We forced the ON from smacs.Now is Ok. More investigation when system available. 
 
Pm #7 sinks too much current, investigation convinced us due to cable or Pm problem. We put Hv=0 and out of monitoring.</pre>
<!-- Author: daniele -->


<!-- Date: Fri Mar 1 12:18:08 2002 -->
<pre>As an adition to the previous entry from Daniele, YMon plots for the COs and the shift crew in general have been updated to reflect the fact that Channel 7 is OFF for the next few stores.</pre>
<!-- Author: Gervasio -->


<!-- Date: Sat Mar 2 16:12:11 2002 -->
<pre>fixed the problem concerning the impossibility to switch On/Off the system by control room picture. 
It was due to a wrong backed up file. 
 
Some time, during my test, I observed a fault beaviour on Pm 230 and 250 .... please have anybody a look at them in next days. 
 
</pre>
<!-- Author: Daniele -->


<!-- Date: Mon Mar 4 11:58:28 2002 -->
<pre>Data: 
 
   run#        L3 accepts     live lum (nb^-1)      TOF  
 ========     ============   =================     ===== 
  
  140148         82715           45.14              OK (ch 7 off) 
  140149         39254           19.57              OK (ch 7 off) 
  140150         48216           22.04              OK (ch 7 off) 
  140151         15540            6.78              OK (ch 7 off) 
  140155         93372           40.46              OK (ch 7 off) 
  140156        244758          101.26              OK (ch 7 off) 
  140157        108899           40.21              OK (ch 7 off) 
  140160         23695            8.29              OK (ch 7 off) 
  140187         99311           45.20              OK (ch 7 off) 
  140215          6944            6.71              BAD: OFF 
  140217         71724           29.50              OK (ch 7 off) 
  140218        142657           61.37              OK (ch 7 off) 
  140219         21555           11.66              OK (ch 7 off) 
  140220        315733          125.90              OK (ch 7 off) 
  140223          9795            3.38              OK (ch 7 off) 
  140240         11384            5.82              BAD: OFF 
  140241        274189          125.13              OK (ch 7 off) 
  140242        306031          121.39              OK (ch 7 off) 
  140247         17279            5.97              OK (ch 7 off) 
</pre>
<!-- Author: Gervasio -->


<!-- Date: Mon Mar 4 12:00:45 2002 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-112&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-112' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-113&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-113' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-114&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-114' width='300'></a></center>
<!-- Author: Gervasio -->
<!-- Comment: Mon Mar  4 12;02;23 comment by...Gervasio -->
<pre>YMon plots for run 140242. Channel 7 is temporarily OFF.</pre>


<!-- Date: Tue Mar 5 19:53:38 2002 -->
<pre>I have add a new facility to Smacs : 
 at start time the splash form appears and on it you can choice to run with the present set up in Caen system, that is the program doesn't switch anymore all the channels OFF but it leaves them in their status. 
 
A warning !!! 
appears to me, if you use the internet explorer all the system slow down also after you close it.... may be some applet/cooky remain active in the system !!! more investigation needed. 
 
For test porpouse, now I restart from scratch leaving also ifix figure (two rings) running.</pre>
<!-- Author: daniele -->


<!-- Date: Wed Mar 6 09:58:45 2002 -->
<pre>   run#        L3 accepts     live lum (nb^-1)      TOF  
 ========     ============   =================     ===== 
  140315        329125          112.37              OK (ch 7 off) 
</pre>
<!-- Author: Gervasio -->


<!-- Date: Thu Mar 7 08:27:47 2002 -->
<pre>Gervasio and I will swap the cafe card in b0wcal02 slot 6 chan 8 
that has been giving us low slope warnings for quite some time 
now.  The new cafe card is S/N 01118.</pre>
<!-- Author: M Jones -->


<!-- Date: Thu Mar 7 09:01:34 2002 -->
<pre>Swapped CAFE card 06230 with 01118 in wcal02 slot 6 chan 8. 
Now we will swap the low slope CAFE card in b0wcal05 with 
CAFE card 01692.</pre>
<!-- Author: M Jones -->


<!-- Date: Thu Mar 7 09:23:42 2002 -->
<pre>Replaced CAFE card 00783 (wcal05 slot 7 channel 2) with  01692. 
There are no more warnings when we do the QIE calibration. 
Gervasio will now do a TAC calibration run.  We should probably 
use this (or later) TAC calibration results for future data 
calibration in case the pedestals changed on these channels.</pre>
<!-- Author: M Jones -->


<!-- Date: Thu Mar 7 14:09:16 2002 -->
<pre>This morning we investigated the HV breakdown problem on 
channel 7.  We first disconnected the cable at the top NE 
patch panel and applied 2200 volts from the CAEN supply. 
It did not break down.  Then swapped cables for channels 6 
and 7 at the HV patch panel and at the CAEN supply.  We ran 
both of these up to 700 volts (10^4 gain, field off) but did 
not find any breakdown on either channel. 
 
So, we leave the system in this configuration and see what 
happens when we try to take data next.  One of the following 
will happen: 
 
1.  Everything works just fine...  then we're puzzled but happy. 
2.  Channel 7 draws excessive current.  Then we know the problem 
    is probably inside the detector. 
3.  Channel 6 draws excessive current.  Then we know the problem 
    is probably associated with the RG58 cable. 
 
The pager person should pay attention when the next store goes 
in and the shift crew turns on the HV.</pre>
<!-- Author: M Jones -->


<!-- Date: Thu Mar 7 18:36:47 2002 -->
<pre>Thursday, March 7, 2002. 
------------------------ 
 
Some of the HV cables have been relabeled: 
 
South East Bottom 
================= 
 
Changes made behind HV PC in 1st floor: 
 
- Cable 53919, HV PMT 115, MF1 Mod4 Ch2, had no label. 
  It got the HV PMT 115 label from cable HV Spare 4, which had 
  two labels (spare 4 + PMT 155). This spare 4 cable is pressumed 
  dead. 
 
- Cable 53926, HV PMT 122, SE Bottom, was already unplugged and  
  replaced by cable HV Spare 5. 
 
Changes made in the collision hall: 
 
- NONE. Very little space between HV box and muon arches. 
   
 
South Bottom West 
================= 
 
Changes made in 1st floor: 
 
- Cable 54136, HV PMT 324, MF1 Mod3 Ch 9 had no label. 
  It got the HV PMT 324 label from cable HV Spare 12, which had 
  two labels (spare 12 + PMT 324). 
 
- Cable 54164, HV PMT 352, MF1 Mod7 Ch 1 had no label. 
  It got the HV PMT 352 label from cable HV Spare 13, which had 
  two labels (spare 13 + PMT 352). 
 
Changes made in the collision hall: 
 
- Cable HV Spare 12 had no label. It got its HV Spare 12 label 
  from cable HV PMT 324, which had two labels (PMT 324 + Spare      12). 
 
- Cable HV Spare 13 had no label. It got its HV Spare 13 label 
  from cable HV PMT 352, which had two labels (PMT 352 + Spare      13). 
 
North West Bottom 
================= 
 
Changes made in 1st floor: 
 
- Cable 54227, HV PMT 413, MF2 Mod4 Ch 11 had two labels, PMT 413 
  and Spare 15. Its Spare 15 label was moved to a disconnected      cable which had no labels (after a continuity test). 
 
- Cable 54233, HV PMT 419, MF2 Mod5 Ch 7 had no label. 
  It got the HV PMT 419 label from cable HV Spare 14, which had 
  two labels (spare 14 + PMT 419). 
 
Changes made in the collision hall: 
 
- Cable HV Spare 15 had no label. It got its HV Spare 15 label 
  from cable HV PMT 413, which had two labels (PMT 413 + Spare      15). 
 
- Cable HV Spare 14 had no label. It got its HV Spare 14 label 
  from cable HV PMT 419, which had two labels (PMT 419 + Spare      14). 
 
  Both spare cables 14 and 15 are suspected dead. 
</pre>
<!-- Author: Gervasio and Gerry -->


<!-- Date: Thu Mar 7 18:42:01 2002 -->
<pre>The SMACS configuration file has been saved with channel 7 set to "Active Monitor". Next time TOF is turned on for data taking, it is likely we will get an alarm either on Channel 7 or in Ch 6 
(see Matthews note above). If this is the case the pager person 
might have to take this channel out of monitor, perhaps turn it off, and save the configuration like this until a longer access allows to fix things. 
</pre>
<!-- Author: Gervasio -->


<!-- Date: Thu Mar 7 18:45:00 2002 -->
<pre>Channel 217 has a V/I ratio of 10.05 (804/80 with no B Voltages). All other channels have V/I approx. 10.5. Keep an eye on this channel.</pre>
<!-- Author: Gervasio -->


<!-- Date: Thu Mar 7 23:26:46 2002 -->
<pre>Paged about 3 trips while system was ALL OFF. I reset the trips. How can a PMT trip while off? 
The reset turned the HV on, so I turned these 3 channels off again and now the entire detector looks blue (off and OK).</pre>
<!-- Author: Gervasio -->


<!-- Date: Sat Mar 9 08:41:54 2002 -->
Joe told me that HV (both for chan 6 and 7) worked well yesterday 
when they took cosmics runs( 
<a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=199&frame=2&anchor=03:44:58'> 
CDF e-log </a> 
) after the cable swap. 
<BR> 
Well, we'll keep an eye on that. 
<BR> 
We're going to have a shot setup in a couple of hours.
<!-- Author: Koji -->


<!-- Date: Sun Mar 10 17:31:03 2002 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-116&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-116' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-117&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-117' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-118&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-118' width='300'></a></center>
<!-- Author: Koji -->
<!-- Comment: Sun Mar 10 17;31;44 comment by...Koji -->
YMon plots look OK since the beginning of store early this morning.



<!-- Date: Mon Mar 11 13:05:43 2002 -->
<pre>We are preparing to adjust the ADC gate width for the next 
series of stores.  Here is Rolf's handy table: 
 
GATE   t_calc    t_chan0   t_chan1   t_chan2 
  0    infinite  75.7 ns   75.4 ns   75.1 ns 
 20    47 ns     50.8 ns   50.2 ns   50.0 ns 
 40    34 ns     36.2 ns   35.7 ns   35.5 ns 
 60    26 ns     27.7 ns   27.3 ns   27.1 ns 
 80    21 ns     21.5 ns   21.1 ns   20.9 ns 
100    17 ns     16.8 ns   16.5 ns   16.3 ns 
120    13 ns     12.8 ns   12.5 ns   12.2 ns 
140    10 ns      9.6 ns    9.3 ns    9.1 ns 
160   7.7 ns      6.6 ns    6.4 ns    6.2 ns 
180   5.5 ns      4.3 ns    4.1 ns    4.0 ns 
200   3.5 ns      2.6 ns    2.5 ns    2.5 ns 
220   1.7 ns        -         -        - 
240     -           -         -        -   
 
We are currently operating at a gate width of 100 counts. 
The proposal is to first take data at 120 counts and then at 
140 counts.  I'll hilite the entries indicating when the 
gate widths were changed.</pre>
<!-- Author: M Jones -->


<!-- Date: Mon Mar 11 13:32:17 2002 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>ADC gate width changed from 100 to 120. 
TAC calibration run 0x225da taken before the change. 
TAC calibration run 0x225dc taken after the change.</pre></td></tr></td></table>
<!-- Author: M Jones -->


<!-- Date: Tue Mar 12 13:53:29 2002 -->
<pre>  This morning Daniele and I met with Jonathan to test the 
hardware trigger inhibit. All was ok except there was a  
"parity" reversal: Jonathan's inhibit logic wants a "high"  
signal for the inhibit not a "low" one as was set. This was 
trivially changed from the CAEN front panel controls. So  
Jonathan was going to activate the hardware inhibit.  
   We have yet to complete the iFix based software inhibit.  
Jonathan passed along the information on the tag name.</pre>
<!-- Author: bauerg -->


<!-- Date: Tue Mar 12 14:42:07 2002 -->
<pre>Stuffed Online Production Database with calibrations up to yesterday. This includes calibrations taken after the replacement of two CAFE cards during the last access (Thursday) and the calibrations taken before and after adjusting the ADC gates (see Matthew's highlighted entry just above).</pre>
<!-- Author: Gervasio -->


<!-- Date: Tue Mar 12 15:05:53 2002 -->
Got paged since they couldn't get the run started right after the shot because the 
TOF trigger inhibit introduced in the morning was alarming Run Control (So it's working!!).  
<BR> 
The problem was that channel 281 kept tripping. 
(Channel 281 is the channel which showed a gain degradation  
before October shutdown). 
<BR> 
Increased the maximum current for this channel from 250uA to 
270uA and the alarm went away. 
<BR> 
Daniele came in and we kept monitoring the current and voltage 
 for a while. 
At first the current was drifting between 230uA and 260uA, 
but after a while (probably about 30min.) it became stabler  
(just drift between 235 and 240uA). 
The voltage was stable with a drift of about 0.2V. 
For the moment the maximum current is kept at 270uA, but not saved. 
<BR> 
Normal channels don't show any drift at all. with either voltage 
or current. 
<BR> 
We'll keep an eye. 
  
<!-- Author: Koji -->
<!-- Comment: Tue Mar 12 15;58;54 comment by...Koji -->
Since successive HV alarms appeared, raised the maximum current 
for 281 to 300uA.
<BR>
I'll keep an eye and decide whether this change should be saved.



<!-- Comment: Tue Mar 12 23;24;05 comment by...Koji -->
<pre>Current for channel 281 has somewhat come down and it's
currently drifting between 215uA an 225uA.</pre>
<!-- Date: Tue Mar 12 16:10:41 2002 -->
<pre>I looked at V/I for channel 281 and 280.  The resistance of 
channel 281 is 8.9 MOhm and 280 is 10.5 Mohm.  So channel 281 
definitely has a dynode touch problem.</pre>
<!-- Author: M Jones -->



<!-- Date: Wed Mar 13 03:10:27 2002 -->
Got paged around 00:00 for missing heartbeat. 
Smacs was hung downstairs. 
<BR> 
Called Daniele. 
He came here and told me that it should be OK to run without  
Smacs until the end of the store because we now have the  
trigger inhibit. 
Also he showed me how to restart Smacs without turning off HV at all. 
<BR> 
Anyway this time we kept on running without Smacs and in the meanwhile Daniele worked at the PC to find out what caused the 
software problem. 
<BR> 
Daniele's entry follows. 
<BR>  
<!-- Author: Koji -->


<!-- Date: Wed Mar 13 03:37:47 2002 -->
<pre>I spent 3 hours to understand the reasons of this hangup. I do not have clear and exaustive results but: 
1) on Task manager smacs appears to run sharing the correct       resurses (60-80 %). 
2) a unknown process, called rtvScan.exe (may be "real time virus       scan" ??), was running taking 20-40% of cpu time. 
3) The system was continuesully accessing the hard disk. This is       not a standard beaviour of Smacs. 
4) Switching off, one after another, all the running tasks was not possible regain the control of system. 
 
I restarted the system by reboot and running in debug way. 
</pre>
<!-- Author: daniele -->


<!-- Date: Wed Mar 13 03:45:11 2002 -->
<pre>I reset the Imax for channel 281 at 300uA and I save the set up fle (.suf), so next load will be correct.</pre>
<!-- Author: daniele -->


<!-- Date: Wed Mar 13 06:17:09 2002 -->
<pre>Paged again due to trip of pm 271 but all tof was off. Reset trip on pm 271. 
 
I had a check for pm 281 that in the llast afternoon give problem, now the Imon=200uA and stable at that value.</pre>
<!-- Author: daniele -->


<!-- Date: Wed Mar 13 09:03:14 2002 -->
<pre>Again checked the current HV module was driving for channel 281. 
&lt;BR&gt; 
It's 200uA and very stable. 
</pre>
<!-- Author: Koji -->
<!-- Comment: Wed Mar 13 09;25;57 comment by...Koji -->
Also checked V/I like 
<a href=
'/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=7&frame=2&anchor=16:10:41'>
Matthew did </a> 
yesterday.
<PRE>  chan    V/I(MOhm)
    65    10.43
    66    10.47
   281    10.48
   282    10.46
</PRE>
So channel 281 looks normal now.
<BR>
Did this channel recover itself?

<!-- Date: Wed Mar 13 09:05:27 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-119&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-119  width='300' align='top'></td><td>Comparison of MIP peaks between store 1066 and 1070.</a></td></tr></table>
<!-- Author: Koji -->
<!-- Comment: Wed Mar 13 09;20;48 comment by...Koji -->
Since we observed a strange phenomenon with channel 281 at the
beginning of store 1070, tried a comparison with the previous 
store.
<BR>
Plotted is the ratio of MIP peaks from h-stream taken in
these two stores.
<PRE>   run 140741 (store 1066)
   data found in look area from runs between 140819 and 140836 (store 1070)
</PRE>
The ratio is not 1 because Matthew changed the gate width 
in the shutdown.
<BR>
This ratio is 0.73 +- 0.01 for channel 281 and is comparable to the other channels.
<BR>
Anyway, we didn't observe a gain drift of a factor of 2 or 3
(multiplied by the influence of the gate width change),
which was expected in the case of a dynode touching.
<BR>



<!-- Date: Thu Mar 14 09:23:03 2002 -->
Since I saw entries about TOF HV ( 
<a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=216&frame=2&anchor=16:21:18'> 
1</a>,  
<a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=216&frame=2&anchor=18:48:48'> 
2</a>) 
in shift e-log (they didn't page me), checked our PC. 
<BR> 
iFix was not switched to run. 
Switched it to run. 
<BR> 
The strange thing is that we didn't miss heartbeat upstairs  
although iFix was not running. 
Is this my misunderstanding? 
<BR> 
  
<!-- Author: Koji -->
<!-- Comment: Thu Mar 14 09;36;42 comment by...Koji -->
HV current for channel 281 was stable at 200uA.


<!-- Comment: Thu Mar 14 13;31;19 comment by...Koji -->
It was my misunderstanding.
<BR>
Just talked with Daniele and found out that iFix in our 
PC doesn't have to be running.
<BR>
And the problem in yesterday evening was that software 
again hung up and Daniele restarted it.

<!-- Date: Thu Mar 14 12:08:36 2002 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>ADC gate width changed from 120 to 140 counts (now 10 ns). 
TAC calibration run 0x22680 taken before the change. 
TAC calibration run 0x22681 taken after the change.</pre></td></tr></td></table>
<!-- Author: M Jones -->



<!-- Date: Fri Mar 15 14:39:23 2002 -->
Store 1080 was dumped. 
<BR> 
Renamed our default HV setting file from 
<PRE>   DEFAULT011220-today_data_b14kG_g30k_fix.suf  </PRE> 
to 
<PRE>   DEFAULT011220-today_data_b14kG_g30k_fix_100.suf  </PRE> 
so that this file can be sent to the online database. 
<BR> 
("_number" at the end is required to get this done). 
<BR> 
The file has been loaded in SMACS with the new file name. 
<BR>
<!-- Author: Koji -->


<!-- Date: Sun Mar 17 14:56:38 2002 -->
<pre>Data taken since Friday morning: 
 
   run#        L3 accepts     live lum (nb^-1)      TOF  
 ========     ============   =================     ===== 
  
  140973        526245          202.06              OK 
  140982        102872            0.77 (minbias)    OK 
  140999          4836            2.46              OK 
  141000          8799            3.78              OK 
  141002         61032           26.81              OK 
  141004          9270            3.79              OK 
  141007         10365            4.16              OK 
  141010          2754            0.24              OK 
  141011          1491            0.09              OK 
  141013        232495           88.32              OK 
  141017          6558            2.30              OK 
  141018          1845            0.71              OK 
  141036        110443            0.29 (0 bias)     No YMon file 
  141038         47107           20.21              OK 
  141039        232029           97.20              OK 
  141041          7654            2.84              OK 
  141042         40174           16.02              OK 
  141044         69899           26.03              OK 
  141045         12190            4.32              OK 
  141046         45070           18.36              OK 
  141048         24778            8.29              OK 
  141055          7937            2.49              OK 
</pre>
<!-- Author: Gervasio -->


<!-- Date: Mon Mar 18 09:45:35 2002 -->
<pre>This morning between 6:00 and 7:00 Am system hangs.  
Operating system not answer at cntr-alt-del combination. 
Investigation on logger bring suspicions is due to rtvscan.exe program (real time vires scan). 
 
Smacs restarter at 8:30 am. 
</pre>
<!-- Author: daniele -->


<!-- Date: Mon Mar 18 19:50:46 2002 -->
<pre>More data: 
 
   run#        L3 accepts     live lum (nb^-1)      TOF  
 ========     ============   =================     ===== 
  141088         31757           12.19              No YMon file 
  141090          4923            1.68              No YMon file 
  141092         94007           35.83              OK 
  141093         14499            5.21              OK 
  141094         30429           11.03              OK 
  141096         10783            4.00              OK 
  141097         52283           18.24              OK 
  141098         18355            6.17              OK 
  141099          4805            1.44              No YMon file 
  141100         31386           10.35              OK 
  141101          8998            2.96              OK 
  141135        101494            1.73 (0 bias)     No YMon file 
  141139          9017            1.29              OK 
  141140        125065           50.27              OK 
  141141        235873           87.00              OK 
  141143         55488           19.54              OK 
  141144         48467           16.35              OK 
  141146         57508           18.32              OK 
  141189         32253           13.39              OK 
  141190         46402           19.29              OK 
</pre>
<!-- Author: Gervasio -->


<!-- Date: Tue Mar 19 19:19:29 2002 -->
<pre>Data: 
 
   run#        L3 accepts     live lum (nb^-1)      TOF  
 ========     ============   =================     ===== 
  141191         99549           40.13              OK 
  141192        127829           50.64              OK 
  141197          4441            1.51              OK 
  141198          1054            0.20              OK 
  141199          5677            1.86              OK 
  141200         27156            7.26              OK 
  141212         13845            5.43              OK 
  141213        154064           62.23              OK 
  141215          7760            2.67              No YMon file 
  141216        106530           40.83              OK 
  141218         62409           22.90              OK 
</pre>
<!-- Author: Gervasio -->


<!-- Date: Wed Mar 20 21:46:44 2002 -->
<pre>This afternoon Daniele and I tested the "software" (iFix)  
trigger inhibit for TOF. Seems to  work. (Noted in main 
&lt;a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=237&frame=2&anchor=21:42:55'&gt;e-log&lt;/a&gt;. 
But in the process we discovered some oddities in smacs HV 
control: 
--Reloading HV file did NOT any longer switch off HV first, 
but whatever channels were on were put on with the new voltage 
(this has been fixed). 
--Turning off HV channels when loading HV file does not work 
for channels which are disabled from the monitoring...this needs 
to be changed...and will be 
</pre>
<!-- Author: bauerg -->


<!-- Date: Thu Mar 21 08:55:40 2002 -->
<pre>Preparing to change the ADC gate width changed from 140 to 80. 
The TAC calibration run 0x22867 is with 140 counts.  It is 
exceedingly slow right now...  did the configuration get changed?</pre>
<!-- Author: m jones -->


<!-- Date: Thu Mar 21 08:57:38 2002 -->
<pre>The TAC calibration ended in an error - rebooting b0puls01.</pre>
<!-- Author: M Jones -->


<!-- Date: Thu Mar 21 09:06:20 2002 -->
<pre>We won't change the gate width until b0puls01 is working again. 
It is dumping  a ton of debug output messages that I don't 
recongize.  Arnd is investigating.</pre>
<!-- Author: M Jones -->


<!-- Date: Fri Mar 22 08:23:22 2002 -->
<pre>Trying again to change the gate width... 
</pre>
<!-- Author: M Jones -->


<!-- Date: Fri Mar 22 08:27:09 2002 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>ADC gate width changed from 140 to 80 (now 21 ns). 
TAC calibration before was run 0x228b5. 
TAC calibration after is run 0x228b6.</pre></td></tr></td></table>
<!-- Author: M Jones -->


<!-- Date: Fri Mar 22 09:01:07 2002 -->
<pre>Data: 
 
   run#        L3 accepts     live lum (nb^-1)      TOF  
 ========     ============   =================     ===== 
  
  141433         64596            8.16              OK 
  141434         58641           19.93              OK 
  141435          3398            1.02              OK 
  141436         19864            6.23              OK 
  141437         14081            4.33   very few events in YMon 
  141438         59131           18.12              OK 
  141440         31121            7.77              OK 
  141442         34671            9.08              OK 
  141445         13958            3.52              OK 
  141446         46295           11.38              OK 
  141461         55146           12.11              OK 
</pre>
<!-- Author: Gervasio -->


<!-- Date: Sat Mar 23 20:44:50 2002 -->
<pre> 
Data:  
 
   run#        L3 accepts     live lum (nb^-1)      TOF   
 ========     ============   =================     =====  
 
  141471	  27653		 1.836		    OK 
  141501	   5940		 1.994		    No YMON files found 
  141506	   7416		 2.556		    OK 
  141507	  29375		10.923		    OK 
  141508	  34109		12.279		    OK 
  141509	 107723		36.119		    OK 
  141510	  52647		17.447		    OK 
  141518	  29447		 8.938		    OK 
  141524	 119511		34.291		    OK 
  141539	 132651		64.634		    OK 
  141540	 434299		17.938		    OK 
  141541	 166651		 6.932		    OK 
  141542	1189754		49.101		    OK 
  141543	 312721		12.945		    OK</pre>
<!-- Author: Koji -->


<!-- Date: Sun Mar 24 01:00:05 2002 -->
Get paged because PC was hung when shift crew tried to turn on  
HV. 
<BR> 
Power cycled the PC and restarted SMACS. 
<BR> 
In the meanwhile they took a run 141571 ignoring our trigger  
inhibit. 
<BR> 
I logged in as Administrator and didn't find an icon for new  
version of Smacs, so we are currently running with the old  
version. 
<BR>
<!-- Author: Koji -->


<!-- Date: Sun Mar 24 15:44:55 2002 -->
<pre>Data from the last two shifts (eve and owl):  
 
   run#        L3 accepts     live lum (nb^-1)      TOF   
 ========     ============   =================     =====  
 
  141544	98623		32.622		    OK 
  141546	21281		6.654		    OK 
  141549	13642		4.060		    OK 
  141571	20466		7.715		    HV off. 
  141572	187209		71.458		    OK 
  141576	160919		56.032		    OK 
</pre>
<!-- Author: Koji -->


<!-- Date: Mon Mar 25 06:43:54 2002 -->
<pre>Data from the last two shifts (eve and owl):   
 
   run#        L3 accepts     live lum (nb^-1)      TOF    
 ========     ============   =================     =====   
  141576	272278		93.025		    OK 
  141577	380951		15.381		    OK 
  141582	4660		1.329		    No YMon file 
  141597	406268		156.665		    OK 
  141598	119094		44.155		    OK</pre>
<!-- Author: Koji -->


<!-- Date: Mon Mar 25 17:38:42 2002 -->
Restarted SMACS with its new version. 
<BR> 
To do this I logged in "TOF1" by cdf-tof1 account instead of  
"Administrator".  
<!-- Author: Koji -->


<!-- Date: Tue Mar 26 07:51:54 2002 -->
<pre>data: 
   run#        L3 accepts     live lum (nb^-1)      TOF 
 ========     ============   =================     ===== 
  141601        272512          96.435              OK 
  141613        13671           4.350               No event in YMON 
  141618        253635          101.512             OK 
  141619        212521          80.564              OK 
  141621        47069           17.120              OK 
  141660        172294          64.125              OK 
</pre>
<!-- Author: Koji -->


<!-- Date: Tue Mar 26 13:51:16 2002 -->
<pre>modified SMACS HV trip delay time from 40 to 19 sec 
(a first step!)</pre>
<!-- Author: bauerg -->


<!-- Date: Wed Mar 27 12:29:13 2002 -->
<pre>I have cleaned the SmacsSettings folder link which is on  
the desktop. Now it point to the right position (old stuff  
and settings files are into the new folder in a separate  
sub-folder). 
I have also restarted the automatic daily bakup of all the  
settings SMACS files. </pre>
<!-- Author: Stefano -->


<!-- Date: Fri Mar 29 00:07:15 2002 -->
<pre>Runs from the last store 1137 : 
   run#        L3 accepts     live lum (nb^-1)      TOF 
 ========     ============   =================     ===== 
  141926        7009            2.869               OK 
  141927        4062            1.689               OK 
  141928        117277          46.990              OK 
  141931        359726          136.822             OK 
  141948        34199           12.293              OK 
  141950        56113           19.994              OK 
  141954        3810            1.226               OK 
 
</pre>
<!-- Author: Koji -->


<!-- Date: Fri Mar 29 17:01:44 2002 -->
<pre>Runs from the last store 1140 : 
   run#        L3 accepts     live lum (nb^-1)      TOF 
 ========     ============   =================     ===== 
  141984        208532          88.045              OK 
  141986        76457           31.465              OK 
  141989        98000           39.893              OK 
  141989        140382          55.775              OK 
  141999        18434           7.028               OK 
  142000        98452           6.615               OK 
  142005        41099           15.487              OK 
  142007        9500            3.591               OK 
  142009        131391          8.892               OK 
</pre>
<!-- Author: Koji -->


<!-- Date: Sun Mar 31 13:29:54 2002 -->
<pre>Runs from the last store 1142 : 
   run#        L3 accepts     live lum (nb^-1)      TOF 
 ========     ============   =================     ===== 
  142105        97515            33.436             OK 
  142106       181200            70.370             OK 
  142107        40303            15.117             OK 
  142108        56059            21.038             OK 
  142109        39314            14.323             OK 
  142110       352,452          124.477             OK 
  142111        56,385           18.876             OK 
  142130        82,717           33.061             OK 
  142131        92,478           36.197             OK 
</pre>
<!-- Author: Koji -->


<!-- Date: Mon Apr 1 07:34:12 2002 -->
<pre>Runs from the last store 1150 : 
   run#        L3 accepts     live lum (nb^-1)      TOF 
 ========     ============   =================     ===== 
  142168        390695          152.647             OK 
  142169        6483            1.878               OK 
  142170        92070           25.277              OK 
  142177        99365           33.522              OK</pre>
<!-- Author: Koji -->


<!-- Date: Mon Apr 1 11:48:10 2002 -->
<pre>Runs from the last store 1152 : 
   run#        L3 accepts     live lum (nb^-1)      TOF 
 ========     ============   =================     ===== 
  142202        507820          177.657             OK 
  142203        7412            1.970               OK 
  142204        11548           3.238               OK 
  142205        9499            2.605               OK 
  142206        12392           3.425               OK 
</pre>
<!-- Author: Koji -->