<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15">
<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 all,</p>
<p><br>
</p>
<p>attached please find these files.</p>
<p><br>
</p>
<p><br>
</p>
<p>Best greetings</p>
<p>Günter<br>
</p>
</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> Donnerstag, 18. Januar 2024 12:21:17<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>
Dear Günter,<br>
<br>
I'm not sure what Hans will need to figure this one out, but these <br>
configuration files might be helpful:<br>
<br>
main.cfg<br>
r3bfuser.cfg<br>
vulom.trlo<br>
<br>
Cheers,<br>
Håkan<br>
<br>
<br>
On Thu, 18 Jan 2024, Weber, Guenter Dr. wrote:<br>
<br>
> <br>
> Dear friends,<br>
> <br>
> <br>
> I now started the DAQ and it looks like there is a problem with the VETAR2<br>
> module. Attached please find the output once the DAQ is started on the RIO4.<br>
> <br>
> <br>
> Here ist the error message:<br>
> <br>
> <br>
> 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866)<br>
> 11: a:1: .Gsi Etherbone init_slow {<br>
> (module/gsi_etherbone/gsi_etherbone.c:110)<br>
> 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No<br>
> such file or directory.<br>
> (module/gsi_etherbone/gsi_etherbone.c:120)<br>
> 5: a:1: ..Calling exit(EXIT_FAILURE)...<br>
> (module/gsi_etherbone/gsi_etherbone.c:120)<br>
> <br>
> How to proceed?<br>
> <br>
> <br>
> <br>
> Many thanks and best greetings<br>
> Günter<br>
> <br>
> <br>
> <br>
> <br>
> ____________________________________________________________________________<br>
> Von: subexp-daq <subexp-daq-bounces@lists.chalmers.se> im Auftrag von Håkan<br>
> T Johansson <f96hajo@chalmers.se><br>
> Gesendet: Dienstag, 16. Januar 2024 19:20:54<br>
> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.<br>
> Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII,<br>
> DRASI, etc. were updated <br>
> <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<br>
> 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<br>
> 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<br>
> <br>
></div>
</span></font>
</body>
</html>