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

[Hans Toshihide Törnqvist]

Dear Günter,

It looks like either the Vetar driver failed, or the fw/driver is old 
and nurdlib expects a file that didn't exist a while back. If it's the 
latter I can add a switch to ignore this file, it's not critical for 
readout and is used to enter a faster readout mode.

Which version of nurdlib is this? The files and line numbers don't match 
with what I see in the source code, and the last time gsi_etherbone.c 
changed was early last year.

The message "Could not open so-and-so" should be for the device, e.g. 
/dev/pcie_wb0. This is used for the readout.

The dactl file should fail with "Failed dactl fopen".

To summarise, I would suggest to make sure that the correct nurdlib and 
r3bfuser are executed by the DAQ scripts. Meanwhile I will prepare a 
switch to ignore the dactl file which could anyhow be useful for old 
configurations, and to clean up the Etherbone error messages.

Best regards,
Hans

On 2024-01-18 11:29, 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 
> <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 
> <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 
> <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 
> <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
>