For BigRIPS run numbers, they are available online: http://bripscnt01.rarfadv.riken.jp/runsum/index.php

21:30 AIDA and BRIKEN are ready to go -- so we closed the door and asked the BigRIPS team to send the beam to
F11.  It will take about 30 minutes as they want to recalibrate one of the Faraday cups.

22:09: Beam is coming to F11.  AIDA sub-run R13_17 is running at 22:10 so nearly the same time.
     BigRIPS run number 0140
     BRIKEN file name 170329_2213_40Mg Run 0.  It is started at 22:13.  R13_18 for AIDA
     See attachment 1 for biases.


23:12:  We notice that BigRIPS began the run 0141 at 23:08
     AIDA subrun R13_36 began about or near 23:07 or 23:08
     BRIKEN run number 170329_2313_40Mg Run 1
     All system-wide checks passed (excepting nnaida6 clock status which is a known issue)
     Statistics rates look reasonable, except that the nnaida 16 23 24 are even higher than before when the beam
was off (~200k)
 
23:59 - AIDA crashed.  Merger stopped.  When attempting to stop the run, the following error is displayed:

STATE for nnaida1 returned with an error
error: SOAP http transport timed out after 20000 ms
NONE
error: SOAP http transport timed out after 20000 ms
    while executing
"$transport $procVarName $url $req"
    (procedure "::SOAP::invoke" line 18)
    invoked from within
"::SOAP::invoke ::SOAP::_DataAcquisitionControlClient__GetState"
    ("eval" body line 1)
    invoked from within
"eval ::SOAP::invoke ::SOAP::_DataAcquisitionControlClient__GetState $args"
    (procedure "DataAcquisitionControlClient__GetState" line 1)
    invoked from within
"DataAcquisitionControlClient__GetState"

We kill off the merge and tape server.

DAQ itself comes back after a reset.  Attempting to open the tape service, however, yields an error

Cannot issue more Access Tokens
 ClaimTapeServer returned:- 
3 Capability table is full.

30.3.2017

0:56 When attempting to bring AIDA back up, eventually nnaida10 was not showing merger data before enabling the
ASIC readout data.  On the run control, nnaida10 consistently showed that its data transfer was not enabled. 
Attempting to reset etc., then eventually issuing Go would drop all the data transfers.

After a power cycle by the standard method, essentially the problem persists, except that it is nnaida 7 8 9 10
(the whole block) which shows the problem where we cannot get the enabled data transfer to stick.