AIDA
GELINA
BRIKEN
nToF
CRIB
ISOLDE
CIRCE
nTOFCapture
DESPEC
DTAS
EDI_PSA
179Ta
CARME
StellarModelling
DCF
K40
AIDA
Draft saved at 00:00:00
Fields marked with
*
are required
Entry time:
Sat Mar 29 12:29:03 2025
Author
*
:
Subject
*
:
> 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.
Encoding
:
HTML
ELCode
plain
Suppress Email notification
Attachment 1:
Drop attachments here...
Draft saved at 00:00:00
ELOG V3.1.4-unknown