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

[Håkan T Johansson]

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
> 
>