Taylan Akdogan wrote:
>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.
>
>
I'm not sure if that is possible. Scalers get their TTL signal from
this ribon cable which comes staright from the ABS rack 13 (lucky
number). To do what you are sugesting we need to make another scaler
channel (another epics channel is easy) , do we have an exra one.
>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.
>
I don't think that this is true. I have not noticed it. It is easy to
check, make a spin flip and start a new run.
>
>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.
>
>
I think that ADC channels are ok to begin with. In fact they were
not reset by software, since they come directly from you electronics ( I
remember that time). The problem is only that scaler. We use scaler to
count charge. Thus, charge was not counted properly and asymmetry was
not normalized correctly.
>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.
>
>
Good idea. We can use time stams. It is time consuming and I don't
envy anyone who has to go through this but in the words of George
Costanza it is doable.
>Not a big issue; all of the data should be recoverable.
>
>Cheers,
>Taylan
>
>
Cheers, Vitaliy
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:30 EST