EEL Setup

Cob disposition

Bottom COB has dtm1, data dpm going from dpm0 to dpm6 and control dpm is dpm7. It is marked as "0" with a marker, but can also be seen from the ID tag ending in 0 on the front of the COB.
Top COB had dtm2, data dpm going from dpm8 to dpm14  and control dpm is dpm15. It is marked as "1" with a marker, but can also be identified from the ID barcod tag ending in 1 on the front of the COB.
The RTM C03-01 and C03-02 were placed in the bottom and top location, respectively.

Slow Controls and Data connections

Fibers were tested in fixed locations on the RTM.

To ensure that things are working as expected from this table, they should be placed in the same locations on the RTM according to the 2021 mapping.

Image of connection on the RTM Side.

Use connectors with yellow strip (they seem to work best). Slow control channels have been tested to be working if placed in this configuration

Image of connections on the RTM data side. The non-marked fiber is the type-B fiber which comes out from the breakout box.





We decided to avoid connections on the DPM6 as this particular RCE showed few errors during testing.
To do so we used a breakout box to re-map the data connections.

For the HALL-B set-up:
1) Take breakout box labelled as "DATA"
2) Connect fiber type B in MTP1
3) Connect the octopus cable to fiber H
4) Connect the single fibers in the following order (from 0 to 11)
black, red, yellow, grey, teal, pink, white, purple, brown, green, orange, blue
5) In this configuration the mapping should be (X means absent):
dpm   pgp
3          3
5          3
X          X
1           3
X          X
X          X
5           1 
X           X
4           2
5           0
4           0
4           1

TiPcie Card connection

• Use typeB fibers from the Ti VME crate to the Ti Card
• Connectors should be on slot #1 and slot #5

Flange board connections

This table shows the connections on the flange board

QA of Flange Board ↔ FE0Bs

This table shows a visual of the connections from the cooling plate to the flange, looking from the detector toward the flange. X indicates no connection.

Current Issues with Back-end.

List of issues we observed during local data taking relative to the Back - End.
NOTICE!!! The dpm numbers in the daq map after 7 are off by one. Example: DataDpm[13] in the DAQ Map is hostname dpm14.

1) dpm[6] seems like it has broken data channels => Removed connections via breakout box

2) daq-map sometimes shows "Not found" data links

• Try to reset the dpm1 (you can always check the which dpm is by ssh to dtm then minicom bayX.Y
• reset dpm1 → cob_rce_reset atca1/1/0/2

Back End setup in the EEL

Server machines: clonfarm1, clon10new

TiCrate: hdice1

COBS: dpm0 : dpm6,   dpm7,   dtm1
            dpm8 : dpm14, dpm15, dtm2

Connect to clonfarm1 as clasrun and change to bash shell

Software installation locations (11 Ago 2021)

SDK software installation to talk to the atca crate

source /usr/clas12/release/1.4.0/slac_svt_new/V3.4.0/i86-linux-64/tools/envs-sdk.sh

examples:
cob_dump --all atca1  => dumps the RCE status (booted is 0xea)
cob_rce_reset atca1 ==> resets all the RCEs
cob_rce_reset atca1/1/0/2  ==> resets a particular dpm (in this case dpm1)
cob_cold_data_reset atca1 ==> "power cycles" the RCEs (sometimes they do not come back up nicely so rce_reset might be needed after)

SVT software is installed in

/data/hps/slac_svt/
=> diskless is exported to the cobs via nfs (server hosted on clonfarm1, NFS has to be v2 !! important )
=> daq is exported to the cobs via nfs. Has been compiled on DTM1
=> server contains the current software installation

Start rogue servers

On clonfarm1 start the rogue server

source /usr/clas12/release/1.4.0/slac_svt_new/anaconda3/etc/profile.d/conda.sh
conda activate rogue_5.9.3
cd /data/hps/slac_svt/server/heavy-photon-daq/software/scripts/
python SvtCodaRun.py  --local --env JLAB

On clon10new start the dummy server

python SvtCodaDummy.py --local --env JLAB

Start data taking with Coda

Here are the instructions to how to start Coda with clasrun user

python SvtCodaDummy.py --local --env JLAB
1) Open a terminal on clonfarm1
> bash
> sconda    #setup conda
> crogue    #activates rogue environment
> startCodaRun    #starts Rogue Coda Run Gui

2) Open a terminal on clon10new
> bash
> sconda; crogue; startCodaDummy   #starts the dummy rogue server

3) Open a terminal on clonfarm1
> runcontrol -rocs

Then:

connectconfigure (hdice1_clonfarm1_clon10new to run with both cobs, hdice1_clonfarm1 to run with top cob, hdice1_clon10new to run with bottom cob)download (for both cobs use hps_v2_noThr.trg)PrestartGo

Coda informations:

We are using conda release 1.4.0, installed in

/usr/clas12/release/1.4.0

HPS trigger configurations are stored in 

/usr/clas12/release/1.4.0/parms/trigger/HPS/

Update Coda libraries

If event_builder or rogue_lite change, coda libraries need to be updates. Just run

sh /data/hps/slac_svt/copy_libraries.sh

Coda / Rogue Errors

1) RssiContributor::acceptFrame[X]: error mistatch in batcher sequence 000000dc : 00000000

This is in the event builder and indicates that we are dropping packets.

This is raised in RssiContributor.cc in the event_builder by acceptFrame thread

Effect:

rol BUSY

Causes: Dropped frames.

Fix: Reset COBs

2) ROL crashes during download→prestart phase showing readback errors on the FEBs

This usually indicates that the FEBs lost clock

Effect: not possible to run

Causes: FEBs lost clock

Fix: Recycle FEBs and run control