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

Thu Jan 18 12:42:32 CET 2024

Dear all,

attached please find these files.

Best greetings

Günter

________________________________
Von: subexp-daq <subexp-daq-bounces at lists.chalmers.se> im Auftrag von Håkan T Johansson <f96hajo at chalmers.se>
Gesendet: Donnerstag, 18. Januar 2024 12:21:17
An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.
Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated

Dear Günter,

I'm not sure what Hans will need to figure this one out, but these
configuration files might be helpful:

main.cfg
r3bfuser.cfg
vulom.trlo

Cheers,
Håkan

On Thu, 18 Jan 2024, Weber, Guenter Dr. wrote:

>
> Dear friends,
>
>
> I now started the DAQ and it looks like there is a problem with the VETAR2
> module. Attached please find the output once the DAQ is started on the RIO4.
>
>
> Here ist the error message:
>
>
> 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866)
> 11: a:1: .Gsi Etherbone init_slow {
> (module/gsi_etherbone/gsi_etherbone.c:110)
> 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No
> such file or directory.
>  (module/gsi_etherbone/gsi_etherbone.c:120)
> 5: a:1: ..Calling exit(EXIT_FAILURE)...
> (module/gsi_etherbone/gsi_etherbone.c:120)
>
> How to proceed?
>
>
>
> Many thanks and best greetings
> Günter
>
>
>
>
> ____________________________________________________________________________
> Von: subexp-daq <subexp-daq-bounces at lists.chalmers.se> im Auftrag von Håkan
> T Johansson <f96hajo at chalmers.se>
> Gesendet: Dienstag, 16. Januar 2024 19:20:54
> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.
> Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII,
> DRASI, etc. were updated
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chalmers.se/pipermail/subexp-daq/attachments/20240118/d621d8f4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vulom.trlo
Type: application/octet-stream
Size: 3064 bytes
Desc: vulom.trlo
URL: <http://lists.chalmers.se/pipermail/subexp-daq/attachments/20240118/d621d8f4/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.cfg
Type: application/octet-stream
Size: 4882 bytes
Desc: main.cfg
URL: <http://lists.chalmers.se/pipermail/subexp-daq/attachments/20240118/d621d8f4/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: r3bfuser.cfg
Type: application/octet-stream
Size: 194 bytes
Desc: r3bfuser.cfg
URL: <http://lists.chalmers.se/pipermail/subexp-daq/attachments/20240118/d621d8f4/attachment-0005.obj>