From: W.J. Llope (llope_at_physics.rice.edu)
Date: Tue Mar 18 2003 - 16:25:05 EST
if i understood correctly, test 1 shows that the problem is
cleared (temporarily) during initialization "somewhere"....
this seems to rule out the possibility of intermittantly-connected
cabling...
if none of this initialization involves the BiRa at all
(as i took your msg to say) test 1 seems to rule out that
the bira is related... since bira (re)initialization is
apparently not being done at the beginning or in between
any two star runs, the bira cannot be the culprit. right?
so,,,
a) i don't think test #2 will make any difference... (tcd
will still go 100% busy at some point), since the bira
isn't invloved in this problem... re-init'ing every event
will only make more work for the code but won't stop
this problem from happening
b) in fact, i think this already localizes the problem
to the tcd. i.e. this problem is one caused by, but
cleared by reinitializing, the tcd, in whatever way
that gets done technically.....
as i understand, test 2 only gives double confirmation that its not
bira-related...
it would however strengthen our case that's its not the bira
when we present this info to the TRG group though...
so, your call on whether or not to do this test..
thanks for the update
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
--W.J. Llope, Ph.D. Res. Assoc. Professor T.W. Bonner Nuclear Laboratory phone: 713-348-4741 Rice University, MS-315 fax: 713-348-5215 6100 S. Main St. Houston, TX 77005-1892 e-mail: llope_at_physics.rice.edu WWW home: http://wjllope.rice.edu/default.html
--
This archive was generated by hypermail 2.1.4 : Thu Jul 24 2003 - 00:39:38 EDT