FAQ about DAQNOTE: This page is *always* under construction!
FAQ about DAQ
This document contains answers to some frequently asked questions about E852 DAQ system. Hopefully, it will serve as DAQ troubleshouting guide. If you don't find an answer to your problem in this FAQ feel free to submit your question using a form below. Enter your name in the form if you want an answer to be mailed to you. Otherwise, your question will be anonymous.
In case of message "Permission denied" check that your account is in e852online .rhosts file.
source /home/mpsdaq/e852/daq/setup
at the shell prompt or, alternatively, put this line in your .cshrc file. More detailed explanation is here
- daqlogd
- messaged
- killerd
- DAQio
- EventBuilder
- feedDispatcher
- Dispatcher
First, check that all of them are running either with UNIX ps command or
with Xlog. Second, look on status line of DAQcontrol. If you suspect that something is
wrong check daemons' logfiles displayed in Xlog.
DAQ -> System -> Restart DAQ. Keep an eye on
DAQ console window while restarting DAQ - all problems during restart are reported
in this window. Wait ~30 seconds and check with Xlog that all daemons are running and
"healthy".
Only in some severe cases you may try to start DAQ "from scratch". To do that: type
at the shell prompt /home/mpsdaq/e852/daq/bin/stop. Wait 2-3 minutes
(it's necessary beacause for a few minutes after termination of daqlogd its UNIX sockets
are present in the state of TT_CLOSE_WAIT. This can prevent succesfull restart).
After this pause restart DAQ as above.
1-byte address (0xN or 0xNN) is module's slot number if it's in
the crate with BBFC.
2-bytes address (0xmMM) is SSP's address 0xMM on SSP cable segment.
Computer reaches this cable segment over SSP in slot m in the main crate.
3-bytes address (0xmMMNN) is module's slot number 0xNN in the crate with
SSP 0xmMM.
4-bytes address (0xGGmmMMNN) is a special case for modules reachable over SI
cable segment (in our case these are LGD ADC's and SI's themself).
You can find more detailed explanation of Fastbus addresses here.
Information about CAMAC whereabouts is here
allocate_hardware_(&time_to_wait) and deallocate_hardware_()) helps
to avoid a danger of such interference between processes. In what situations the allocation is not required?
NOTE: allocation scheme can be easly abused. Please, enclose only a code actually dealing
with hardware inside the allocate/deallocate pair unless there is a necessity
to grab access for a longer period of time.
/home/mpsdaq/e852/daq/bin/overrideFBAlloc. Existing allocation
semaphores will be removed and a race for access will start anew.
CAUTION: a process which had access might be unaware of this trick. It continues to assume that
it holds access solely until the next call to allocate/deallocate.
RC. PA:0x7 SA:0x0 Error:0xD BSI: Operation:RC PA:0x7 SA:0x0 BSI: Primary address timeout BB: BBFC Address time out | EC:1008 VBBC:0x6084FFFF BBFC:0x00010010 BB: OP:RC PA:0x7 SA:0x0 Bytes: required 4 actually -4or
RC. PA:0x10407 SA:0x0 Error:0xD BSI: Operation:RC PA:0x10407 SA:0x0 BSI: Primary address timeoutor
RC. PA:0x10507 SA:0x0 Error:0x103 BSI: Operation:RC PA:0x10507 SA:0x0 BSI: Internal error of SSP along the route SSP: Primary address timeoutThe first line is a header describing operation. Next few lines provide all available information about an error. Errors with
BB:
prefix were detected inside BranchBus library. This prefix tells
that a source of error is somewhere along the chain mpsdaq <-> VME
crate <-> VBBC/BVI in this VME crate <-> Branch Bus <-> BBFC <-> Fastbus
crate with BBFC <-> module in this crate. For example, in the
first fragment above one is trying to access empty slot 0x7 in the
main crate (with BBFC).
Prefix BSI: designates errors detected inside Buffered
Segment Interconnect library build atop of BB library. This library
is used to reach modules which are NOT in the crate with BBFC with
the aid of software resident in SSP's. If there is no BB:
line in the message then origin of error is somewhere "below" SSP in
the main crate. If an error is caused by one of the SSP along the
route to a module being addressed then message contains line
BSI: Internal error of SSP along the route
as in the third fragment above (one is trying to access some module in slot 7 in a crate with non-existing SSP 0x105). If there is no reference to internal SSP error then an error was generated by the module being addressed (as in the second fragment: attempt to read empty slot 0x7 in the crate with SSP 0x104).
rc [pa] [sa] - Single word read from CSR space rd [pa] [sa] - Single word read from Data space rcb [pa] [sa] [nwords] - Block read from CSR space rdb [pa] [sa] [nwords] - Block read from Data space rc2b [pa] [sa] [nwords] - Block read from CSR space terminated on SS=2 rd2b [pa] [sa] [nwords] - Block read from Data space terminated on SS=2 rcm [brf] [sa] - Broadcast single word read from CSR space rdm [brf] [sa] - Broadcast single word read from Data space rcbm [brf] [sa] [nwords] - Broadcast block read from CSR space rdbm [brf] [sa] [nwords] - Broadcast block read from Data space wc [pa] [sa] [datum] - Single word write to CSR space wd [pa] [sa] [datum] - Single word write to Data space wcb [pa] [sa] [nwords] - Block write to CSR space wdb [pa] [sa] [nwords] - Block write to Data space wcm [brf] [sa] [datum] - Broadcast write to CSR space wdm [brf] [sa] [datum] - Broadcast write to Data space wcbm [brf] [sa] [nwords] - Broadcast block write to CSR space wdbm [brf] [sa] [nwords] - Broadcast block write to Data space wrb [pa] - Reset bus on segment with PA wrbg [pa] - Reset bus on and below segment with PA fbd [pa] [f] [c] [n] [a] - CAMAC operation FCNA over FBD at PA load [pa] [filename] - load SSP executable file into SSP si [ssp_pa] - initialize SI tree starting in a crate with SSP ssp_paBefore using these programs do
setenv BBFC 1 or setenv BBFC 2
to select BBFC either in the Fast Trailer or in the LGD Hut.
