On Fri, 27 Feb 2004, vitaliy ziskin wrote:
> I don't believe that we are doing two flips, thus I think that it should
> stay in "flip odd" position untill the beam is done..... And I know
> what makes it change---> when target flips it resets this bit. It is
> reminence of the time when this bit was Nitrogen. I will change it
> now. Starting with run 5099. The previous data with flipper is still
> salvagable if we cut on current above 70 mA (before flip).
Hi Vitally,
It is most definite that we are NOT doing two flips. I was always
un-reluctant to use a software controled epics variable for this
kind of important information, because I was afraid of such a
thing may occur. I think I couldn't raise my voice high enough.
To this end, during the long shutdown period, we commissioned
three new PC-controlled Analog/Digital epics boards dedicated
just for Compton. I created the flipper_odd and flipper_active
epics channels, which are supplied directly by the "hardware"
signals. Thus, no other component of the blast can reset them
mistakenly (they are read-only - hardware input channels -
realtime!). Although, you fixed the problem, I think we should
replace the existing epics variables with those.
In addition to this; Tancredi had mentioned that when a run ends
in the middle of the fill and another one starts, the flip_odd
was not being preserved. I tried to "debug" this, and couldn't
find "any" problem. Tested "several" times. I think this should
be related to what was happening as you described, or something
similar.
For salvaging the last night's data: I believe we have "two"
more safe guards in addition to the "unreliable" software epics
channel;
1) We deliver the flipper_odd hardware signal (in addition to the
flipper inhibit, which inhibits the triggers/scalers) - remember
the time you and I spent in the D-tunnel. I thought you put it
into an ADC channel such that the events are tagged by it in an
event-by-event base. Correct me, if I am wrong.
2) There is "Compton-flip-events" in the data stream, which has
time stamp. There may me some time-sync problem between the
computers, but I believe it is at sub-second level, and the
inhibit duration "after" the flip is 10 seconds, which guarantees
its proper position in the data stream, even if there is a
sub-second sync problem in the time stamp. I'll add the necessary
additions to the blastlib to make this information available for
crunching the data.
Not a big issue; all of the data should be recoverable.
Cheers,
Taylan
---=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=---
Taylan Akdogan Massachusetts Institute of Technology
akdogan@mit.edu Department of Physics
Phn:+1-617-258-0801 Laboratory for Nuclear Science
Fax:+1-617-258-5440 Room 26-402b
---=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=---
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:30 EST