From: Frank Geurts (geurts_at_rice.edu)
Date: Fri Jan 24 2003 - 11:16:34 EST
tof folks ... please read the answers to Hank and Tonko's questions
below and send me any comments before I send them/the list the replies...
thanks,
frank
--->>Hello -- Fred has just given me this nice document describing the TCD. I > > have a > >>question for each subsystem - If we issue a Level0 trigger, but for some > > reason > >>do NOT issue either a Level2 accept or abort, what does your system do?
the system will time-out (and thus will be busy). Our understanding of last year's operation was that not sending data after an L2 accept is a capital crime. If we received an L0 but do not receive an L2 accept or abort within some time period the system will asume it actually missed the L2 altogether. Still having a valid L0, it decides to send the event to STAR as a good event.
> > -- > > I would like to expand this question: > > a) At which point in time (relative to L0 or L2 or ...) does your system > ship data to DAQ?
relative to L2-accept or in case an L2 gets lost, right after the time-out (which is now set at 100ms).
> > b) What are the points in time where a L2_ACCEPT or a L2_ABORT would > cause problems - either total lunacy or ignored/corrupted events?
- L2 Aborts: L2-Aborts are ignored if they are not related to the L0 token in the system. If we do have an associated L0 token then that event is discarded, the DAQ busy is cleared and the local trigger reset.
- L2 Accepts L2accepts are always served: * if there is an associated L0 event, then that data will be shipped to STAR-DAQ (the busy is cleared and local logic is reset) * if there is no L0 event (which means that it got lost otherwise we wouldn't be getting an L2-accept in the first place): an empty (filled w/ 0s, but similar sized) event is shipped to STAR-DAQ
> > c) At which points in time does your system need to be protected > by the internal TCD BUSY?
tofp combines two busy signals for the TCD busy: one busy signal is set by the local trigger logic upon receiving a pvpd coincedence. It triggers digitization and protects the tofp system against new coincidences before it received the L0 which is associated with this particular coincidence. For that the logic opens a window in which it expects the L0 command to arrive. A second busy signal is generated by the local DAQ system. It is raised in case a L0 token arrives. It will be lowered only in three cases: after the L2 accept, after the L2 abort and after an L2 time-out.
> > d) What about L1_ACCEPTS? Currently unused, but one never knows...
is not implemented and therefore ignored.
---
This archive was generated by hypermail 2.1.4 : Thu Jul 24 2003 - 00:39:33 EDT