>So: is it necessary to plug in the CSPAM? No.
>Is it OK? Yes. Why did we do it? It is an extra piece of information
>(the time it took the CSPAM trigger to arrive relative to the other
>triggers). I thought this extra piece of information(and redundancy)
>would be useful. If people feel strongly that they want it unplugged
>OK I don't really feel that strongly about it.
I'd suggest unplugging CSPAM, just in case it may create problems on
subtle situtations not yet considered.
As far as I know, trigger timing (arrival) information is independently
provided by a TDC (in branch 1) which is read by equipment 11.
>I copied a recent file
>to Caltech today over the network to check this(run 10980). It took
>about 5 hours and tonight I found out there seems to be no good
>microvax 2 info in it.
>...
>What is going on?
Completely disregard runs 10968-10981. 4B07 went bad during the
night of last Sunday. As a result of that, all these MACRO runs
were filled (with 650,000 blocks of data) within 30 minutes with
useless WFD and PISA data all coming from this tank. The acquisistion
was eventually stopped at 7:00 in the morning because of lack of disk
space on VXMACA. This was the first time after installing the new
WFDs -i think- that something like that happened. Actually, this
has always been a fear with regards to the new WFDs. Although there
are/were plans to impose software and/or hardware vetos to super hot
tanks, let me mention how I've approached this problem, at least for now:
1) there is a spy disks job always running on VXMACB alerting whenever
certain disk criteria are not met. Various people are then e-mailed
(mostly here at GS); Kate Scholberg is the only one in the US that
is currently notified (during the night, for us here in GC).
2) there is a block rate deamon always running on VXMACB; it is currently
performed every 15 minutes and tries to establish if the rate of
collecting data is decreasing or increasing. It alerts only me at the
moment (I'll make it public this weekend). This may identify completely
stopped or partially paused MACRO RUNs and of course abnormal increases
in trigger rates. If these increases are due to a hot PMT, anyone can
login on VXMACB and turn-off its HV, thus saving the acquisition.
>Ill try to get another file to look at the
>2.5 usec thing. Eric send me the number of a good file before you
>unplugged the CSPAM.
Look at VXMACB::$1$DIA2:[SCRA.KATS.MON.STAT] for all the STAT_RUNxxxxx.TEXT
files. You can get a clear picture for each run before deciding to
analyze it. I have been running essential statistics/diagnostics
automatically at the end of each run.
Good MACRO RUNs before I unplugged CSPAM from the STOP MASTER (in SM4) are
10985-10990.
BTW, I just noticed that the SM3 CSPAM input to the STOP MASTER is actually
not connected to its other end...
So, you should never see any CSPAM latched into the SM3 stop master.
A presto,
--Erik