Erik's note about "coming out and expressing thoughts and
worries" has prompted me to make a couple of comments.
I share Chris Walter's worries about making sure that the new
fast stop is properly implemented alongside the Stop Master so that we
can always understand offline what happened during a particular
event. Or as Erik mentioned, if we can't be sure what happened in 1
out of 1000 events, we better know which events to throw out.
Chris Walter says he wants the fast trigger latched by the
Stop Master. I *completely* agree. Even though we can tell by
looking at other equipments if a fast stop trigger occured, there is
extra information provided by the relative times latched in the Stop
Master. These times would provide a cross check against what is
recorded in the waveforms in case we believed that the stop master
screwed up somehow. Since the CSPAM is the only input to the Stop
Master that is not explicitly needed for readout, we should use the
CSPAM inputs into the Stop Master for the fast stop.
New Trigger? I think we should rethink the decision of NOT
defining a new trigger for the fast stop. I remind everyone that the
WFD is only resarted by the rising edge of the computer busy. This
means that if for some reason the fast stop fires spuriously so that
there is no real trigger to stop the acquisition then the WFDs will
*not* be restarted. It also means that the latches that Erik has
carefully resurrected and installed won't correspond to the event that
finally does trigger the acquisition, and it is not obvious to me how
one could deduce that this happened in an offline analysis.
In general I agree that we don't expect a fast trigger without
a real trigger. But in the spirit of healthy paranoia that Chris
W. has put forth here, I think we should implement this as a new
trigger. I think it will be much easier to ignore an event where the
fast trigger obviously fired spuriously than to infer the same thing
from Stop Master + Latch Data. The bottom line is that more
information can't hurt.
-Chris (Orth)