<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:14pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Dear friends,</p>
<p><br>
</p>
<p>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.</p>
<p><br>
</p>
<p>Here ist the error message:</p>
<p><br>
</p>
<p></p>
<div>
<div>11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866)<br>
11: a:1: .Gsi Etherbone init_slow { (module/gsi_etherbone/gsi_etherbone.c:110)<br>
5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No such file or directory.<br>
(module/gsi_etherbone/gsi_etherbone.c:120)<br>
5: a:1: ..Calling exit(EXIT_FAILURE)... (module/gsi_etherbone/gsi_etherbone.c:120)<br>
<br>
</div>
How to proceed?</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Many thanks and best greetings</div>
<div>Günter<br>
<br>
</div>
<br>
<p></p>
<p><br>
</p>
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> subexp-daq <subexp-daq-bounces@lists.chalmers.se> im Auftrag von Håkan T Johansson <f96hajo@chalmers.se><br>
<b>Gesendet:</b> Dienstag, 16. Januar 2024 19:20:54<br>
<b>An:</b> Discuss use of Nurdlib, TRLO II, drasi and UCESB.<br>
<b>Betreff:</b> Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote:<br>
<br>
> <br>
> Dear friends,<br>
> <br>
> <br>
> I am just trying to figure out how all the various scripts/commands work<br>
> together for setting up our DAQ system. Maybe, you can help to clearify some<br>
> things.<br>
> <br>
> <br>
> <br>
> - master.bash<br>
<br>
This would be intended to run on the readout board (RIO). The other <br>
scripts below is for the PC.<br>
<br>
> <br>
> source ../env/env.sh<br>
> ./trloii_setup.sh<br>
> # gdb --args \<br>
> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \<br>
> --label=MCAL1 \<br>
> --triva=master,fctime=10,ctime=50 \<br>
> --log-no-rate-limit \<br>
> --server=drasi,dest=lyserv \<br>
> --buf=size=400Mi \<br>
> --max-ev-size=0x1000000 \<br>
> --subev=crate=1,type=20,subtype=2,control=9,procid=1 \<br>
> --eb=lyserv \<br>
> "$@"<br>
> <br>
> In the first line some environment variables are set. The second line tells<br>
> the VULOM4 how to operate (i. e. selection from modes of operation defined<br>
> in vulom.trlo). Then DRASI is started with a bunch of parameters. Is there<br>
> somewhere an explanation of the purpose of all these settings?<br>
<br>
The drasi command line options should be described here:<br>
<br>
<a href="http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html">http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html</a><br>
<br>
(Note: 'lyserv' is the name of your PC, at least as seen from the RIO.)<br>
<br>
The TRLO II setup file (vulom.trlo) is worse in terms of documentation. <br>
The format as such is hopefully rather straightforward. A description is <br>
here: <a href="http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html">http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html</a> .<br>
The actual meaning is more complex, the TRLO II description can be found <br>
here:<br>
<br>
<a href="http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html">http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html</a><br>
<br>
(left pane), which just is a colourised version of this: <br>
<a href="http://fy.chalmers.se/~f96hajo/trloii/description.txt">http://fy.chalmers.se/~f96hajo/trloii/description.txt</a><br>
<br>
It does not describe the .trlo file as such, but what the gateware tries <br>
to achieve.<br>
<br>
> And what is in the last line? I never came accross "$@" before.<br>
<br>
That would be all the (non-shifted, i.e. not removed) options given to the <br>
script itself, i.e. master.bash.<br>
<br>
> - eb.bash<br>
> <br>
> ../drasi/bin/lwrocmerge \<br>
> <br>
> --label=MCAL_EB \<br>
> --merge-mode=event \<br>
> --server=trans,flush=1 \<br>
> --server=stream,flush=1 \<br>
> --buf=size=1600Mi \<br>
> --max-ev-size=20Mi \<br>
> --eb-master=rio4-mcal-1 \<br>
> --file-writer \<br>
> --drasi=rio4-mcal-1<br>
> <br>
> What is the purpose of this command?<br>
<br>
This runs an 'event builder' on the PC. Not strictly needed, but this <br>
way, the RIO only ever needs to send data once, to this event-builder <br>
(EB). File writing, and streaming of on-line data is then handled by this <br>
process. It is cheaper to have better network cards and so on in a plain <br>
PC.<br>
<br>
> Why are values for buffer size and max<br>
> event size different then in the command before?<br>
<br>
The nomenclaturure is unfortunately a bit convoluted below with ucesb <br>
regards 'buffer size'. The --buf in the two commands above give the size <br>
of the memory used to buffer data inside the process, and depends on how <br>
much memory each machine has. The --max-ev-size tells how large each .lmd <br>
event can be. The --max-ev-size configured in the event builder needs to <br>
be as large as the sum of all event sources it has. I.e. should be able <br>
to be the same as in your single source above.<br>
<br>
In the readout itself, any event that is read out cannot be larger than <br>
this. If it is, then the DAQ will report a fatal failure.<br>
<br>
> - fanout.bash<br>
> <br>
> #!/bin/bash<br>
> while :<br>
> do<br>
> ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \<br>
> stream://localhost \<br>
> --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001<br>
> sleep 5<br>
> done <br>
> <br>
> This looks like setting up a connection point to the outside world, right?<br>
<br>
Yes. It accepts connections and will serve them data for online analysis.<br>
<br>
stream://localhost tells it where to read data (here the PC itself where <br>
it is running). Using the 'stream' protocol, which esentially is just raw <br>
LMD events. (As is the 'transport protocol'.) That will be served on the <br>
default port used for the stream server set up by the EB above.<br>
<br>
--server is then the server that accepts connections, and serves data on <br>
another port (8001).<br>
<br>
> And we find the third (random?) value for a buffer size.<br>
<br>
That bufsize is actually the LMD buffer size used by the stream server. <br>
The corresponding value in the readout and EB is set implicitly from the <br>
maximum event size...<br>
<br>
> - rate.bash<br>
> <br>
> ../drasi/bin/lwrocmon --rate rio4-mcal-1<br>
> <br>
> Ok, this I understand. We can look the DAQ over the shoulder and see what<br>
> the thing is doing in terms of number of trigger events, transported data,<br>
> etc.<br>
<br>
> - log.bash<br>
> <br>
> ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost<br>
> <br>
> This is also easy to understand.<br>
<br>
:-)<br>
<br>
Then also try to do (on the PC)<br>
<br>
drasi/bin/lwrocmon --tree rio4-mcal-1 localhost<br>
<br>
which would show a 'tree-view' monitoring of the running system.<br>
<br>
<br>
Cheers,<br>
Håkan</div>
</span></font>
</body>
</html>