[subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated

[Håkan T Johansson]

On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote:

> 
> Dear friends,
> 
> 
> I am just trying to figure out how all the various scripts/commands work
> together for setting up our DAQ system. Maybe, you can help to clearify some
> things.
> 
> 
> 
> - master.bash

This would be intended to run on the readout board (RIO).  The other 
scripts below is for the PC.

> 
> source ../env/env.sh
> ./trloii_setup.sh
> # gdb --args \
> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \
>         --label=MCAL1 \
>         --triva=master,fctime=10,ctime=50 \
>         --log-no-rate-limit \
>         --server=drasi,dest=lyserv \
>         --buf=size=400Mi \
>         --max-ev-size=0x1000000 \
>         --subev=crate=1,type=20,subtype=2,control=9,procid=1 \
>         --eb=lyserv \
>         "$@"
> 
> In the first line some environment variables are set. The second line tells
> the VULOM4 how to operate (i. e. selection from modes of operation defined
> in vulom.trlo). Then DRASI is started with a bunch of parameters. Is there
> somewhere an explanation of the purpose of all these settings?

The drasi command line options should be described here:

http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html

(Note: 'lyserv' is the name of your PC, at least as seen from the RIO.)

The TRLO II setup file (vulom.trlo) is worse in terms of documentation. 
The format as such is hopefully rather straightforward.  A description is 
here: http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html .
The actual meaning is more complex, the TRLO II description can be found 
here:

http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html

(left pane), which just is a colourised version of this: 
http://fy.chalmers.se/~f96hajo/trloii/description.txt

It does not describe the .trlo file as such, but what the gateware tries 
to achieve.

> And what is in the last line? I never came accross "$@" before.

That would be all the (non-shifted, i.e. not removed) options given to the 
script itself, i.e. master.bash.

> - eb.bash
> 
> ../drasi/bin/lwrocmerge \
> 
>     --label=MCAL_EB \
>     --merge-mode=event \
>     --server=trans,flush=1 \
>     --server=stream,flush=1 \
>     --buf=size=1600Mi \
>     --max-ev-size=20Mi \
>     --eb-master=rio4-mcal-1 \
>     --file-writer \
>     --drasi=rio4-mcal-1
> 
> What is the purpose of this command?

This runs an 'event builder' on the PC.  Not strictly needed, but this 
way, the RIO only ever needs to send data once, to this event-builder 
(EB).  File writing, and streaming of on-line data is then handled by this 
process.  It is cheaper to have better network cards and so on in a plain 
PC.

> Why are values for buffer size and max
> event size different then in the command before?

The nomenclaturure is unfortunately a bit convoluted below with ucesb 
regards 'buffer size'.  The --buf in the two commands above give the size 
of the memory used to buffer data inside the process, and depends on how 
much memory each machine has.  The --max-ev-size tells how large each .lmd 
event can be.  The --max-ev-size configured in the event builder needs to 
be as large as the sum of all event sources it has.  I.e. should be able 
to be the same as in your single source above.

In the readout itself, any event that is read out cannot be larger than 
this.  If it is, then the DAQ will report a fatal failure.

> - fanout.bash
> 
> #!/bin/bash
> while :
> do
> ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \
>     stream://localhost \
>     --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001
> sleep 5
> done    
> 
> This looks like setting up a connection point to the outside world, right?

Yes.  It accepts connections and will serve them data for online analysis.

stream://localhost  tells it where to read data (here the PC itself where 
it is running).  Using the 'stream' protocol, which esentially is just raw 
LMD events.  (As is the 'transport protocol'.)  That will be served on the 
default port used for the stream server set up by the EB above.

--server is then the server that accepts connections, and serves data on 
another port (8001).

> And we find the third (random?) value for a buffer size.

That bufsize is actually the LMD buffer size used by the stream server. 
The corresponding value in the readout and EB is set implicitly from the 
maximum event size...

> - rate.bash
> 
> ../drasi/bin/lwrocmon --rate rio4-mcal-1
> 
> Ok, this I understand. We can look the DAQ over the shoulder and see what
> the thing is doing in terms of number of trigger events, transported data,
> etc.

> - log.bash
> 
> ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost
> 
> This is also easy to understand.

:-)

Then also try to do (on the PC)

drasi/bin/lwrocmon --tree rio4-mcal-1 localhost

which would show a 'tree-view' monitoring of the running system.


Cheers,
Håkan