<!-- Title: 13:53:00  Wed Jun  2 2004 -->
<!-- Crewchief: Dr ToF -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Fresh Log for the Summer</pre>


<!-- Date: Thu Jun 3 00:18:29 2004 -->
Smacs was hung. We killed and restarted it.
<!-- Author: Olga -->


<!-- Date: Fri Jun 4 00:21:01 2004 -->
The usual SMACS hang happened. I rebooted the TOF PC and restarted SMACS.
<!-- Author: Paul (monitoring ace) -->


<!-- Date: Sat Jun 5 01:44:57 2004 -->
<pre>Again the same problem with CAEN crate 1. 
System doesn't respond either to to caenet or  
front panel commands,  
HV doesen't come up for even number channels,  
even channels switched on but with HV ~100V  
below the nominal value. 
After powercycling the TOF PC and the crate 1 
(I leaved the crate off for ~5 minutes),  
everything worked again. 
TOF Smacs/Ifix restarted, def. setup file loaded. 
TOF HV full on now. 
 
I had no time to make extensive test to try to  
better understand the problem because we are taking  
good data now ... if the problem will presents again 
probably we'll have to decide to replace the crate.</pre>
<!-- Author: Stefano -->


<!-- Date: Wed Jun 9 14:58:05 2004 -->
<pre>Paged at 14:35. There was a problem to switch on 
the HV. &lt;a 
href='/cgi/elog/elog.pl?nb=2004&action=view&page=405&frame=2&anchor=14:40:12.732'&gt; 
Aces fixed it &lt;/a&gt;. The monitoring ace told me one of the two 
running smacs had the following error:"NO MAGNETIC FIELD".</pre>
<!-- Author: Luca -->
<!-- Comment: Wed Jun  9 15;10;45 comment by...Luca -->
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=405&frame=2&anchor=14:40:12.732'>
This is the link </a>


<!-- Date: Sat Jun 12 01:10:16 2004 -->
<pre>There was an heartbeat from TOF HV. Ace restarted the smacs but  
the problem was still there. When I arrived I found the smacs 
paused. I just clicked on the start button and now it looks fine. 
</pre>
<!-- Author: Luca -->


<!-- Date: Sun Jun 13 18:00:57 2004 -->
<pre>Heartbeat alarm. Found PC hung, restarted. See Eve shift, 6-13-04 for details.</pre>
<!-- Author: Bo (mon ACE) -->


<!-- Date: Fri Jun 18 03:17:33 2004 -->
<pre>Alarm from TOF HV at around 2am. Found PC hung, restarted. See owl log.</pre>
<!-- Author: Else (mon ace) -->


<!-- Date: Sun Jun 20 00:24:09 2004 -->
<pre>Heart beat alarm from TOF HV. Restarted smacs.</pre>
<!-- Author: Else (mon. ace) -->


<!-- Date: Sun Jun 27 08:12:06 2004 -->
<pre>We had again the problem with the CAEN crate 1. I tried just to 
powercicle the TOF PC but after restarting the smacs program I  
can not to turn on the HV for the crate 1 channels.  
I powercicled the crate 1 (~10 minutes off) and restated  
ifix and smacs programs. Now the system is working. 
 
 </pre>
<!-- Author: Luca -->


<!-- Date: Mon Jun 28 11:51:01 2004 -->
<pre>Channel 308 tripped twice this morning. Ace was able to recover it. 
 
</pre>
<!-- Author: Luca -->


<!-- Date: Wed Jun 30 00:26:45 2004 -->
<pre>HB alarm. Smacs restarted in TOF1.</pre>
<!-- Author: takashi -->


<!-- Date: Mon Jul 5 00:20:04 2004 -->
<pre>I restarted TOF1 since it froze. </pre>
<!-- Author: takashi -->


<!-- Date: Sat Jul 10 06:54:18 2004 -->
<pre>TOF PC crashed.  I had to hit the reset button and restart iFix.</pre>
<!-- Author: Adam Scott -->


<!-- Date: Tue Jul 27 00:31:04 2004 -->
<pre>Usual heartbeat alarm from TOF pc at 12:15. Restarted smacs.</pre>
<!-- Author: Else (monitoring ace) -->


<!-- Date: Sat Jul 31 15:34:39 2004 -->
<pre>TOF pc was hung. Reboot pc and start smacs.</pre>
<!-- Author: takashi -->


<!-- Date: Thu Aug 5 00:26:19 2004 -->
<pre>I can see that most aces have given up on reporting the TOF pc problems here ... it doesn't seem to have any effect anyway. 
But, since there is nothing else to do at the moment: As expected we had a heart beat alarm a few minutes after midnight tonight. Restarted smacs.</pre>
<!-- Author: Else -->


<!-- Date: Fri Aug 6 00:17:09 2004 -->
<pre>Restart Smacs.</pre>
<!-- Author: takashi  -->


<!-- Date: Sun Aug 8 00:24:43 2004 -->
Heartbeat alarm. Restarted Smacs.
<!-- Author: Takashi & Markus -->


<!-- Date: Sat Aug 14 00:18:32 2004 -->
<pre>Heartbeat alarm : restart smacs</pre>
<!-- Author: flanagan -->


<!-- Date: Sat Aug 14 12:41:41 2004 -->
We had  a problem with wcal01 during the TAC calibration this morning. See <a href= 
'/cgi/elog/elog.pl?nb=2004&action=view&page=603&frame=2&anchor=11:13:03.681'> 
here </a>
<!-- Author: Luca -->
<!-- Comment: Sat Aug 14 18;31;09 comment by...Luca -->
They took <a href='http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=604&frame=2&anchor=18:07:46.922'>
another tac  calibration </a> and this time it is good.


<!-- Date: Sun Aug 15 00:15:40 2004 -->
<pre>Heartbeat alarm.  Restarted SMACS.</pre>
<!-- Author: Pete McNamara -->


<!-- Date: Mon Aug 16 00:16:33 2004 -->
<pre>Heartbeat alarm.  Restarted SMACS.</pre>
<!-- Author: Pete McNamara -->


<!-- Date: Sun Aug 22 00:59:50 2004 -->
<pre>heart beat alarm just after midnight, smacs had hung. Another heartbeat alarm at 12:45. This time the PC had hung. Restarted it.</pre>
<!-- Author: Nicola -->


<!-- Date: Thu Aug 26 16:13:40 2004 -->
<pre>TOF PC hung. I rebooted it.</pre>
<!-- Author: Luca -->


<!-- Date: Sat Aug 28 08:34:38 2004 -->
<pre>Came in this morning to heartbeat alarm.  Restarted SMACS.</pre>
<!-- Author: Pete McNamara -->


<!-- Date: Mon Aug 30 08:23:08 2004 -->
<pre>Regular daily restart of SMACS.</pre>
<!-- Author: Pete McNamara -->


<!-- Date: Fri Sep 3 14:16:16 2004 -->
<pre>Replaced CAFE card on b0wcal02 slot 7 ch 16 with S/N 05196. 
This should fix the QIE calibration warning. 
 
Also inspected the VTT cable in b0wcal01... moved it to slot 6 
from slot 5 and the neon lamp on the supply seems to be on. 
I did not check whether it was on before the move. 
 
Also, the lamp on the VTT supply in b0wcal02 seems to be burned 
out.  Be careful...  you can check VTT in this crate by looking 
at the LED's on the TOMAIN boards or using 
$ readadc b0wcal02 &lt;n&gt; -get VTT 
and you can check the voltage at the enable input using a DMM.</pre>
<!-- Author: mjones -->
<!-- Comment: Fri Sep  3 14;18;45 comment by...mjones -->
<pre>The database is down so I can't run TAC or QIE calibrations.
The flash ram might need to be downloaded in this CAFE card.</pre>


<!-- Date: Fri Sep 3 15:17:15 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-240&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-240  width='300' align='top'></a></td><td>TAC calibration run 0x2da3a looks fine now that VTT in 
b0wcal01 is on again.  We should probably replace the 
VTT enable cable during this shutdown.</td></tr></table>
<!-- Author: mjones -->


<!-- Date: Sat Sep 4 19:45:38 2004 -->
<pre>TOF PC hung, restarted it</pre>
<!-- Author: Gene -->
<!-- Comment: Tue Sep  7 08;41;48 comment by...Markus -->
<pre>Daily smacs restart.</pre>


<!-- Date: Thu Sep 16 08:08:03 2004 -->
<pre>Restarted the TOF pc at 8am</pre>
<!-- Author: Gene -->


<!-- Date: Thu Sep 16 11:12:59 2004 -->
<pre> 
*************** WARNING ****************** 
 
  Today I just noticed that the HV pc says the magnet is 
"ON", this can't be...but it means we can over-voltage  
our tubes!! 
 
  Load in the 50V file to protect ourselves....then try 
to find out how this can be.</pre>
<!-- Author: bauerg -->


<!-- Date: Fri Sep 17 07:51:52 2004 -->
<pre>Restarted TOF pc</pre>
<!-- Author: gene -->


<!-- Date: Fri Sep 17 19:19:35 2004 -->
<pre>******************************************** 
***********                    ************* 
***********   PMT REPLACEMENT  ************* 
***********                    ************* 
******************************************** 
 
 
  This week I assembled PMT DA0859 to replace 
the PMT in channel 281. 
  DA0859 was assembed with preamp  ID P0167, 
and arbitrarily called this Assembly 601. 
  The endcap used was tested for 6hrs at 3kV, 
with no sign of defect. 
  Ran the tube at the test stand with cosmics. 
Pulses look reasonable, except for the rather 
bad reflections from the dual signal cables 
(another old tube from test stand days behaved 
the same). 
 
  So this evening Jeff and I made access to  
replace tube 281 (west side, a little before 
110 degrees). Dave Ambrose had already pulled 
COT microcoax mostly out of the way. However, 
to completely remove the tube assembly we had 
to cut the cable ties and partially pull back 
the cable tray cover to get a few more mm of 
clearance. 
  Otherwise tube swapping went pretty smoothly. 
the cookie disengaged by itself. We reused the 
same one for the new tube. (did not notice, based 
on historical memory, any discoloration of the 
cookie.) 
  Inserted the new tube, replaced oval board 
pretty easily. Afterwards we turned LV back on, 
checked in the control room that the west LV  
came back on ok (although Steve Hahn told us 
there was an "alarm" for some time, maybe one 
of the supplies was a little out of tolerance?) 
We also turn on HV to a few hundred volts to see 
reasoanble current draw....there was.  
  Have yet to check out the actual signals for 
the new tube!</pre>
<!-- Author: Bauer and Miles -->


<!-- Date: Sun Sep 19 21:30:04 2004 -->
<pre>Check out signal from newly installed PMT281. After fooling 
around some, see the signal, looks reasonable. Compared it 
to PMT278: both tubes give average pulse height on the scope 
of about 20mV when 278 is at 900V and 281 is at 999V.</pre>
<!-- Author: bauerg -->


<!-- Date: Mon Sep 20 08:47:50 2004 -->
<pre>Restarted the TOF pc at 8am.</pre>
<!-- Author: Pete McNamara -->


<!-- Date: Mon Sep 20 13:30:05 2004 -->
<pre>A few days after the last good TAC calibration (Sept 4th or thereabouts), b0wcal00 started suffering from VME bus problems 
and it had to be removed from all run configurations.  On 
Friday, Sept 17th, Steve Hahn and I found that the CCFM module 
was hanging the VME bus and that by unplugging this module the 
VME bus was fine but when it was plugged back in, the VME bus 
would hang.  So it appears that the VME intrface for the CCFM 
module is broken.  Something needs to be done about it before we 
can take any calibrations.</pre>
<!-- Author: M Jones -->


<!-- Date: Mon Sep 20 16:10:34 2004 -->
<pre>Heartbeat alarm - restarted smacs. Is anybody looking into the problem? We get about 5 heartbeat alarms a day.</pre>
<!-- Author: Markus -->


<!-- Date: Wed Sep 22 16:00:05 2004 -->
<pre>Came by to check on a tube, and found smacs has hung with 
message "Run-Time Error"!....restarted SMACS 
 
  Wanted to check on PMT105. Recall we had problems last year 
where we seemed to loose the HV connection *during* access, 
but once the plug was things seemed ok. Wanted to check on the 
status now. Put 500V on PMT105 and it drew reasonable currents. 
So I guess it is *still* OK! 
 
 
 
</pre>
<!-- Author: bauerg -->


<!-- Date: Thu Sep 23 22:08:38 2004 -->
<pre>Shut down TOF HV system for tomorrow's power outage!</pre>
<!-- Author: bauerg -->


<!-- Date: Wed Oct 27 18:08:33 2004 -->
Several weeks ago our clock modul apparently caused some 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=16&frame=2&anchor=13:30:05'>VME errors</a>. 
A replacement board arrived from Pisa, and we installed it 
this afternoon. There was a WCAL00 timeout occuring, a look 
by Bill Badget suggested it may be due to corrupted FPGA in 
the ADMEM in slot 5. With the help of ADMEM expert Kwangzoo  Chung we downloaded it. Now TAC seems to not complain, but 
we did not see anything showing up in DBAna..... 
<br>
<!-- Author: gerry and stephanie -->
<!-- Comment: Thu Oct 28 10;47;04 comment by...Luca -->
<pre>It looks like  there were not data processed:

*****
***** Opened output file: /data1/jslee/tacout/TacCalib.dat
*****

Entering APPConsumerInputModule::nextEvent
APPConsumerInputModule::nextEvent :about to request an event
APPConsumerInputModule::nextEvent :about to receive event
APPConsumerInputModule::nextEvent :Received message of length 684 bytes.
APPConsumerInputModule::nextEvent :
  headerWords=4, bufferLength (bytes)=540
inputDataFormat = e0e00
Outfile datarep code = 20200
   Format X Event size is 540 bytes
APPConsumerInputModule::nextEvent SUCCESS! :
   event count = 1,  byte count = 540
--------------------------------------------------------------------------------
ByteIn  Class Name              (ObjectId: Bank Info    ) Proc Name, Description
--------------------------------------------------------------------------------
129     LRIH_StorableBank       (1       : LRIH,1    ,0 ) RAW      ,
112     LRIH_StorableBank       (3       : LRIH,0    ,0 ) UNKN     ,
--------------------------------------------------------------------------------
Exit OK from APPConsumerInputModule::nextEvent


Also, it seems the calibration ended bad. Maybe it was aborted.
I will have a look this afternoon.



</pre>


<!-- Date: Thu Oct 28 16:18:01 2004 -->
<pre>I took a tof tac calibration to try and understand the problems we saw yesterday. I needed to take off wcal03 since it was not responding (shepered was unsucesfull, was some expert working on it?). I found the same problems as yesterday: data look not to arrive, even if rc says 7000 events have been taken. The output file on /data1/jslee/toftac is empty.</pre>
<!-- Author: Luca -->


<!-- Date: Thu Oct 28 19:47:41 2004 -->
<pre>Tried to check for clock signals with monitor patch panel. 
did not see anything (this was during a L2 torture run)..... 
they aren't there, or i did something 
stupid....take your pick!</pre>
<!-- Author: bauerg -->


<!-- Date: Thu Nov 4 12:15:04 2004 -->
Yesterday there was a  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=770&frame=2&anchor=10:59:18.906'>water accident</a>  
where SW-Bottom crate was sprayed with water. Yesterday electronics folks removed all ADMEM cards (including TOF) to 
inspect and clean. This morning Peter Wilson and I removed all 
the TOF transition cards. Generally looked ok, but some with 
water spots. Peter and I will look at them this afternoon and decide which ones to clean.
<!-- Author: bauerg -->


<!-- Date: Mon Nov 8 09:17:55 2004 -->
<pre>The CSL still does not seem to work but data can be sent to 
the look area by setting the CSLHost to b0dau32.  TAC 
calibration runs 2e11c and 2e2d0 together indicate that 
all channels were working at one time.  However, since all the 
cards are removed from b0wcal02 there is still room for disaster 
before the end of the shutdown.</pre>
<!-- Author: M Jones -->


<!-- Date: Mon Nov 8 09:21:25 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-245&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-245  width='300' align='top'></a></td><td>Here is calibration run 2e11c.</td></tr></table>
<!-- Author: M Jones -->


<!-- Date: Mon Nov 8 09:22:03 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-246&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-246  width='300' align='top'></a></td><td>Here is calibration run 2e2d0.</td></tr></table>
<!-- Author: M Jones -->


<!-- Date: Thu Nov 11 15:05:33 2004 -->
<pre>Yesterday i mounted CAFE/DECAF cards onto TOF ADMEMS 
that had been cleaned from the water incident. These were 
ADMEMs 329, 355, 379, and 195; ADMEMs 072, 218, 265 did  
NOT have CAFE/DECAF removed. 
  Today Sham & I remounted all ADMEMs in WCAL02 (but did NOT 
reconnect trigger cables, and transition cards remain out--peter 
wilson asks us to wait until he can check for bent pins). 
  So, as per data base, we installed: 
Slot5 ADMEM 329 
    6       335 
    7       265 
    8       218 
    9       195 
   10       379 
checked front panel voltages on ADMEMs -- all ok 
(did NOT yet reconnect enable cable for 2V supply)</pre>
<!-- Author: gerry & sham -->


<!-- Date: Thu Nov 11 21:38:38 2004 -->
<pre>After installing the ADMEMs, Bill Badgett helped us try to  
read out the ADMEMs. We had trouble with some of the cards 
not shoing up cuz not seated well enough, and even a bus  
error. But repeated re-seatings solved the problem. However 
QIE ped run did not succeed....looks like software problem 
with libraries? not up to date? notified luca....</pre>
<!-- Author: sham & gerry -->
<!-- Comment: Fri Nov 12 10;49;13 comment by...Luca -->
<pre>
I tried to take a ped run and I found this problem:

/cdf/people1/cdfdaq/consumers/code/QiePed/qieped.4.11.2.2003.09.08/bin/Linux2-KCC_4_0/QiePed:
error while loading shared libraries: libCore.so: cannot open shared object file: No such file or directory

I looked in the consumer script and I found a corrupted line:

   setup cdfsoft2 4.11.2ls

I changed it back to

   setup cdfsoft2 4.11.2

and I took another ped calibration. This time it worked (run 189454). I found this run in dbana. 

For the ped calibration we share the executable with calorimeter
guys. I saw they build a new executable in 5.3, so I think we
could switch to this new executable. 

</pre>
<!-- Date: Thu Nov 11 21:40:04 2004 -->
<pre>For posterity, this is the record of ADMEMs pulled out of 
WCAL02, and the CAFE/DECAF cards that were recorded: 
 
4 TOF ADMEMs had the CAFE/DECAF cards unloaded and potentially cleaned: 329, 355, 379, 195 
Cards in Chan 0-10 were apparently washed, 11-19 only inspected (at least, those were the 
instructions) 
 
            Washed ADMEMs             ||      Un-Washed ADMEMs 
                                      || 
ADMEM   329     335     379    195    ||   218    265 
Ch 				      || 
 0     01414   04822   00488   01712  ||  01436   02062 
 1D   000536  000209  000515  000532  || 000476  000470 
 2     03060   03736   00413   01774  ||  01227   01680 
 3D   000131  000485  000430  000185  || 000482  000535 
 4     01572   03049   03775   06375  ||  01368   01697 
 5D   000127  000261  000251  000088  || 000015  000181 
 6     01253   04506   02971   01672  ||  01236   05161 
 7D   000142  000421  000524  000271  || 000250  000469 
 8     01355   01118   01962   02089  ||  01419   04193 
 9D   000243  000259  000508  000196  || 000114  000244 
10     01488   01892   00490   06263  ||  01316   04527 
11D   000113  000100  000016  000446  || 000013  000458 
12     03092   01785   03788   06192  ||  06379   01501 
13D   000094  000246  000264  000258  || 000110  000096 
14     04622   04887   00474   04141  ||  03028   01791 
15D   000537  000252  000274  000544  || 000425  000483 
16     03274   01337   03695   06213  ||  02461   05196 
17D   000437  000530  000450  000451  || 000471  000439 
18     ---    ----     ----    ---    ||  ----    ---- 
19D   000311  000319  000193  000239  || 000306  000315 
                                      ||</pre>
<!-- Author: bauer -->



<!-- Date: Fri Nov 12 11:54:39 2004 -->
<pre>Re-installed transition cards, and completed recabling of 
WCAL02</pre>
<!-- Author: bauer & sumorok -->


<!-- Date: Fri Nov 12 13:12:07 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-247&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-247  width='300' align='top'></a></td><td>Finally it looks like things are back to normal. 
Reseated admems in wcal02 and took a TAC calibration 
run.  All channels look okay.</td></tr></table>
<!-- Author: M Jones -->


<!-- Date: Fri Nov 19 19:50:30 2004 -->
<pre>Here is some data from Youngdo Oh from their calibration records: 
 
PMT    alpha0   alpha 14  beta 0   beta 14   reduction factor 
 DA0050 8.9981    7.4959   5636.18   36.85     152.94 
 DA0859 9.4341    8.0014   6934.99   14.94     464.20 
 DA0901 9.0211   10.9121   4717.00    8.82     534.55 
 DA0931 9.1707   10.6044  28488.12  104.22     273.36 
 DA0933 9.2372   10.3978  14210.16   10.87    1307.11 
 DA0923 9.6206    8.4526  17112.82   36.44     469.68 
</pre>
<!-- Author: mjones -->
<!-- Comment: Fri Nov 19 20;08;59 comment by...mjones -->
<pre>I think that these parameters are used as follows:
log G(V) = log(G0/R) + alpha14 log(V/V0).
This implies that DA0859 operated at 1941.29 volts
will have a gain of 30e3.</pre>


<!-- Date: Mon Nov 22 17:22:11 2004 -->
<pre>HV Board 6, Crate 1 replaced, due to a faulty channel (Ch 2,  
PMT 49). 
 
New board serial # 575502 
Old (borken) board serial # 575521 
 
Smacs restareted, 60V standard HV setup file loaded,  
everything fine so far. 
 
All HV channels fully opertaional.</pre>
<!-- Author: Stefano -->


<!-- Date: Tue Nov 23 12:00:44 2004 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Current Smacs Status: 
 
There is a problem with the parallel port driver used by Smacs to read the magnetic field. 
The driver needs to be reinstalled. 
 
This means that the tof PC and smacs are not reading the parallel  
port and so the magnetic field --&gt; it is not possible to turn on  
the tof HV from iFix (***i.e. form upstairs***). 
For testing/study purposes is possible to turn off and on  
the HV directly from the Smacs console using the turn HV OFF and  
ON buttons. 
 
I'll do that tomorrow. 
 
Done that the TOF HV can be considered in "running" conditions.</pre></td></tr></td></table>
<!-- Author: Stefano -->
<!-- Comment: Tue Nov 23 12;02;29 comment by...Stefano -->
<pre>I'll do that tomorrow MEANS I'll reinstall the parallel port driver tomorrow.</pre>


<!-- Date: Tue Nov 23 16:15:49 2004 -->
<pre>Made exercise to explore new smacs. Made my own 500V file 
to test. Looks ok, except the V/I spread of the tubes seems 
to have more structure than i'd have hoped. See broad cluster 
around "10MOhm", two large spikes around 10.4 and 10.6(?), 
and a small spike around 11. Would be nice to have a scale that can be manipulated so one could identify which channels these 
are....i thought this was possible, but i couldn't do it. 
  Also found one of the current settings in the 50/60 v file 
was mis-saved as 50uA, changed back to 15uA and saved it.</pre>
<!-- Author: bauerg -->


<!-- Date: Sun Nov 28 20:23:14 2004 -->
Updating HV files... 
<br><br> 
Some time ago we 
<a href= 
'/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=16&frame=2&anchor=19:19:35'> 
replaced PMT 281</a> with DA0859. Matthew has estimated 
its new HV is 1941.29V.  
Have moved OLD DEFAULT:<br> 
>  DEFAULT040218_today_b14kG_g30k.suf <br> 
to the archive area as <br> 
>  DEFAULT040218_041128_b14kG_g30k.suf <br> 
AND copied a it into a NEW default version <br> 
>  DEFAULT041201_today_b14kG_g30k.suf<br> 
which includes changing the default/maxumum voltage for PMT281 FROM<br> 
  2096/2121 ====> 1841/1960 <br> 
where I have *intentionally* entered the voltage 100V lower 
than the expected setting.<br> 
  I wanted to try out the voltages, and maybe even get 
in on a cosmic run, but SMACS thinks the solenoid is OFF, 
and it isn't, but it will not let me turn things on. This is 
a known problem that Stefano is looking into, but as it stands 
I can not do anything more! Leave the 60V file as the active 
default, and the currently loaded file.! 
     
<!-- Author: bauer -->


<!-- Date: Mon Nov 29 13:54:54 2004 -->
<pre>I changed the version of the executable for tof qie calibrations from 4.11.2 to 5.3.0. New Executable has been tested successfully.</pre>
<!-- Author: Luca -->


<!-- Date: Mon Nov 29 14:56:54 2004 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Starting from this morning the Administrator privileges  
have been restored for the cdf-cap-tof1 account. 
These privileges are needed to correctly use the parallel  
port driver and to allow smacs to read the magnetic field  
status. 
 
For security reasons the following two actions have been also taken: 
 
1) an authomatic screen saver (password protected) will start  
   after 10 minutes of keyboard/mouse inactivity 
 
2) the account password has been erased from the instructions 
   near the PC 
 
So to enter the PC when the screen saver is active every TOF  
expert/pager have to know the right password which is: 
 
username: cdf-cap-tof1 
password: blue9notes$ 
</pre></td></tr></td></table>
<!-- Author: Stefano -->


<!-- Date: Mon Nov 29 14:57:55 2004 -->
<pre>Smacs is running with 60V HV setup file. 
Magnetic field is ON and correctly recognized. 
All the tests have been succesful. 
 
Ready to load running HV setup file.</pre>
<!-- Author: Stefano -->


<!-- Date: Sun Dec 5 22:14:44 2004 -->
<pre>we have some quite time --- load in REAL Hv file for full voltage</pre>
<!-- Author: bauerg -->


<!-- Date: Sun Dec 5 22:31:53 2004 -->
<pre>first attempt to turn on voltage ended in failure..smacs was 
sort of hung (task manager said: "not responding")...tried to stop smacs, crashed whole computer!</pre>
<!-- Author: bauer -->


<!-- Date: Sun Dec 5 22:58:41 2004 -->
<pre>SMACS hung cuz CAENs LOST POWER!....rack circuit break had 
tripped!....i can not swear they were on, but smacs started  
out looking ok, like it was raising voltages...so suspect 
it tripped on me as i was turning on HV!?</pre>
<!-- Author: bauerg -->


<!-- Date: Sun Dec 5 23:24:11 2004 -->
<pre>continue to have problems...try to load in 60V file, and seek 
Stefano's expertese to straighten out what is going on...</pre>
<!-- Author: bauer -->


<!-- Date: Mon Dec 6 00:06:21 2004 -->
<pre>because i can not seem to load the 60V file, and it seems like 
kilovolt settings have been remembered, i've powered OFF the 
caen crates to prevent any non-expert activities. also, i notice 
in the task manager that SMACS is often "not responding"...maybe 
this is normal, but its response, when it responds certainly seems very sluggish!</pre>
<!-- Author: bauerg -->


<!-- Date: Mon Dec 6 13:20:07 2004 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Full reset of the CAEN crates seems to have fixed the problem experienced by Gerry yesterday. 
The most likely cause of the massive failure seems to be related to the following two events (consequencial): 
 
1) one of the power lines tripped when Gerry tried to turn on the HV (NOTE: the tripped powerline was powerline A: giving power to  
crate 1, 3 and also the non tof crate in the same rack) 
 
2) due to the loss of power the caenet get stuck at the same  
time smacs was reading (or writing) in the crate number 2. 
For some obscure (yet) reasons (maybe a preliminary indication of possible hw problems with crate 2) the crate got completely blocked. Powering off and on the crate didn't fix the problem. 
 
Today after repowering the crate and asking smacs to download  
the HV setting, crate two suddenly exit from the coma. 
 
After the nice news, I tested te system with a new 1000V  
HV setup file and then using the DEFAULT HV setup file  
created yestarday by Gerry. 
 
In all cases everything worked fine but for one channel: 
PMT 288, crate 1, board 9, channel 1. 
For this channel the monitored current is always 0  
(I checked that the problem is not in the PMT but either in  
the monitoring hardware or in smacs (unplugging the HV cable  
and using the test load the IMON current is always 0). 
This is a probable indication that the PMT is OK and 
that the problem is in the monitoring harware or  
in Smacs, so for the moment, together with Gerry, we  
decided to keep the channel in ... (I'll post  
an entry on the general e-log explaining that to the  
ACEs). 
 
NOTE: running some test on crate 2 are also indicating that  
the crate is experiencing some (inital?) hadrware problems. 
To avoid irrecoverable problems please: 
 
********** DO NOT POWER OFF CRATE 2 !! ************  
 
I'll send to prep the spare crate to be fixed, so we'll have  
a replacement in case the situation will get worst. 
 
Now everything has been restarted (crates, PC, iFix and  
Smacs), DEFAULT HV file for running conditions loaded,  
and the system is ready to take data withh al channels enabled.</pre></td></tr></td></table>
<!-- Author: Stefano -->


<!-- Date: Tue Dec 7 18:49:06 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-248&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-248  width='300' align='top'></a></td><td>tof ave charge and time</td></tr></table>
<!-- Author: Dean -->


<!-- Date: Tue Dec 7 18:54:46 2004 -->
<table><tr><td><a href=/elog/notebooks/tof/Tue_Dec__7_2004_185439.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-251  align='top'></a></td><td>tof ave charge and time</td></tr></table>
<!-- Author: Dean -->
<!-- Comment: Tue Dec  7 19;41;43 comment by...bauer -->
<pre>TOF data from 1st Store!</pre>

<!-- Comment: Tue Dec  7 20;41;49 comment by...mjones -->
<pre>Note that channel 281 does not look so different from
the others...  not that I can see exactly which bin it
is, but at least there is no hot or cold channel there.</pre>


<!-- Date: Fri Dec 10 12:01:55 2004 -->
<pre>Studying new clock translator modules.  First, taking a TAC 
calibration run with original module.  This will be run 0x2e998.</pre>
<!-- Author: M Jones -->


<!-- Date: Fri Dec 10 13:45:35 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-252&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-252  width='300' align='top'></a></td><td>This is the result of the TAC calibration with the original 
clock translator module.</td></tr></table>
<!-- Author: M Jones -->


<!-- Date: Fri Dec 10 13:47:04 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-253&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-253  width='300' align='top'></a></td><td>This is the TAC calibration with the new clock translator 
module.  There are some small delay shifts that we do not 
expect to significantly change anything.</td></tr></table>
<!-- Author: M Jones -->


<!-- Date: Fri Dec 10 15:16:14 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-254&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-254  width='300' align='top'></a></td><td>Here are the clock edges on the NIM output of module s/n 1. 
Timing in these plots is not necessarily on the same clock 
edge so the jitter is overestimated.</td></tr></table>
<!-- Author: M Jones -->


<!-- Date: Fri Dec 10 15:24:33 2004 -->
<pre>Relative timing on the new clock translator module seems to be 
STOP0 = CAL + 382 ps 
STOP1 = CAL + 513 ps 
this is about what is expected for the extra propagation delay 
of the of the EL11 fanout chip and the extra 2 cm of copper to 
get to the stop1 output connector. 
Again, these were for module s/n 1.</pre>
<!-- Author: M Jones -->


<!-- Date: Fri Dec 10 15:27:23 2004 -->
<pre>There was some noise present on the NIM output when there was 
no ECL input present.  We might want to build a triaxial 
terminator to tie one of the inputs to ground.</pre>
<!-- Author: M Jones -->


<!-- Date: Wed Dec 15 20:10:06 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-255&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=tof&action=view&page=-255  width='300' align='top'></a></td><td>Channel 281 looks quite reasonable.  The MIP response is 
898 counts, which is quite typical.</td></tr></table>
<!-- Author: M Jones -->


<!-- Date: Mon Dec 20 16:04:59 2004 -->
<pre>From offline analysis Matthew notices a couple of log gain channels, we decide to raise the HV on these two channels 
by 100V: 
PMT129: was 1384/1409  ===&gt;  now 1484/1509 
PMT400: was 1832/1857  ===&gt;  now 1932/1957 
(first number is HV setting, second is HV *limit*) 
 
new HV file made smacs default, it is: 
 DEFAULT041220-today-b14kg_g30k.suf 
(old one put in archive folder) 
</pre>
<!-- Author: bauer -->


<!-- Date: Mon Dec 20 16:24:53 2004 -->
<pre>It has been some time (ie, years?) since we have downloaded 
the flash ram on the CAFE cards.  We may be seeing evidence that 
some ranges on some channels have drifted.  So, QIE calibration 
run 0x2ebad will be used to download the flash ram.  The only 
warning was from b0wcal02 slot 7, qie 16 which had a big sigma 
on cap 0 range 4 (1.1545).</pre>
<!-- Author: m jones -->


<!-- Date: Mon Dec 20 16:27:09 2004 -->
<pre>Next, we will take a TAC calibration run to verify that the 
pedestals still look reasonable.  This will be TAC calibration 
run 0x2ebb0.</pre>
<!-- Author: m jones -->
<!-- Comment: Mon Dec 20 16;39;51 comment by...M Jones -->
<pre>Pedestals look reasonable.  I don't think anything got corrupted.</pre>


<!-- Date: Mon Dec 20 22:53:16 2004 -->
<pre>PMT 288 set back out of monitor.</pre>
<!-- Author: Stefano -->
<!-- Comment: Mon Dec 20 22;59;16 comment by...S -->
<pre>DEFAULT HV setting file modifed accordingly</pre>


<!-- Date: Sat Dec 25 04:03:58 2004 -->
<pre>TOF HV Crate 1 crashed, w/o accepting commands  
both from caenet and from the front panel. 
Status led was off. 
I powered off the crate for 60 seconds and switched on again.  
The crate rebooted correctly w/o problems.  
SMACS restarted, default HV setting reloaded.  
TOF HV full ON now.  
</pre>
<!-- Author: Stefano -->


<!-- Date: Mon Dec 27 21:50:11 2004 -->
<pre>For future reference, here are the notes that I made a while 
ago for downloading the firmware on one of our admems.  This 
comes from the file ~cdf_tof/notes/download.d... 
 
b0dap30:/cdf/people2/cdf_tof/ more notes/download.d  
Notes on downloading firmware for TOF admems: 
 
$ vxlogin b0wcal04 
 
b0wcal04-&gt; cd "/cdf/code-common/cdfonline/fer/v3_15/VxWorks-5.3/PPC" 
b0wcal04-&gt; ld &lt; qietest 
b0wcal04-&gt; qietest 
--&gt; 1 (Select ADMEM) 
Enter 1 (only 1 admem) 
Enter 9 (only ADMEM in slot 9) 
--&gt; 11 (L1 trigger Menu) 
--&gt; 1 (ADMEM type) 
Enter 10 (TOF) 
Enter 3 (Configure ADMEM's FPGA) 
Enter 4 (Down load ET lookup table) 
Q 
Q 
b0wcal04-&gt; unld "qietest" 
b0wcal04-&gt; reboot 
 
however, the directory in which 'qietest' can be found does 
change so you might need to look for it.  Today, the most 
recent version was in 
 
/cdf/code-common/cdfonline/fer/v3_50/VxWorks-5.3/PPC/qietest 
</pre>
<!-- Author: M Jones -->