From: John Mitchell (John.W.Mitchell_at_nasa.gov)
Date: Tue Mar 18 2003 - 18:33:05 EST
Frank,
Let me understand. I think you are saying that the BiRa is not
initialized when a run is restarted. If that is the case, then I
don't know that adding a BiRa initialization will do anything.
The critical question is what operation might be done in the
RunCommand Loop or at Run Start that would change the state of the
system. I am reluctant to think that it is clearing the TOFpDAQ busy
or sending the TOFpDAQ reset since these are done at the end of each
event processing.
John
At 3:02 PM -0600 3/18/03, Frank Geurts wrote:
>hi john,
> here's test 1: quickly starting the next run after the first one failed.
>
>Steve Gronsdal (the RTS operator on shift) was instructed to start a
>ran and then quickly after the run hanged stop it and start a new
>one.
>
>1) the first run hung right away: 0 events (maybe this was the first
>run after previous tests earlier this morning?)
>2) 2nd run started w/o any problems and lasted for ~16k evts after
>which the TOF TCD went 100%
>3) the 3rd run was started w/i 1min and happily ran for another 22k
>before the TCD went to 100% busy and STAR DAQ got hanged.
>
>-> typical actions done by TOFpDAQ in the so-called RunCommand Loop
>(i.e. the loop during which it waits for commands like RunStart):
>Clear TOFpDAQ busy, send TOFpDAQ Reset and Clear TOFpDAQ Busy again.
>-> after the Run Start Command: status info (#events, etc.) is
>cleared, camac interrupts are enabled and TOFpDAQ Busy is cleared
>(should have been cleared already) and TOFpDAQ Reset is strobed.
>
>.... so no Bira resets/re-inits are done during any of these stages.
>
>
>do we still want to include an auto-Bira init option to the tofpdaq
>software, i.e. continue with test 2?
>
>-frank
This archive was generated by hypermail 2.1.4 : Thu Jul 24 2003 - 00:39:38 EDT