<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 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.</p>
<p><br>
</p>
<p><br>
</p>
<p><b>- master.bash</b></p>
<p></p>
<div><span style="font-size:8pt">source ../env/env.sh</span><br>
<span style="font-size:8pt">./trloii_setup.sh</span><br>
<span style="font-size:8pt"># gdb --args \</span><br>
<span style="font-size:8pt">../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \</span><br>
<span style="font-size:8pt">        --label=MCAL1 \</span><br>
<span style="font-size:8pt">        --triva=master,fctime=10,ctime=50 \</span><br>
<span style="font-size:8pt">        --log-no-rate-limit \</span><br>
<span style="font-size:8pt">        --server=drasi,dest=lyserv \</span><br>
<span style="font-size:8pt">        --buf=size=400Mi \</span><br>
<span style="font-size:8pt">        --max-ev-size=0x1000000 \</span><br>
<span style="font-size:8pt">        --subev=crate=1,type=20,subtype=2,control=9,procid=1 \</span><br>
<span style="font-size:8pt">        --eb=lyserv \</span><br>
<span style="font-size:8pt">        "$@"</span></div>
<br>
<p></p>
<p>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?</p>
<p>And what is in the last line? I never came accross <span>"$@" before.</span></p>
<p><span><br>
</span></p>
<p><span><br>
</span></p>
<p><span><b>- eb.bash</b></span></p>
<p><span></span><span style="font-size:8pt">../drasi/bin/lwrocmerge \</span><span></p>
<div><span style="font-size:8pt">    --label=MCAL_EB \</span><br>
<span style="font-size:8pt">    --merge-mode=event \</span><br>
<span style="font-size:8pt">    --server=trans,flush=1 \</span><br>
<span style="font-size:8pt">    --server=stream,flush=1 \</span><br>
<span style="font-size:8pt">    --buf=size=1600Mi \</span><br>
<span style="font-size:8pt">    --max-ev-size=20Mi \</span><br>
<span style="font-size:8pt">    --eb-master=rio4-mcal-1 \</span><br>
<span style="font-size:8pt">    --file-writer \</span><br>
<span style="font-size:8pt">    --drasi=rio4-mcal-1</span></div>
<br>
</span>
<p></p>
<p>What is the purpose of this command? Why are values for buffer size and max event size different then in the command before?</p>
<p><br>
</p>
<p><br>
</p>
<p><b>- fanout.bash</b><br>
</p>
<div><span style="font-size:8pt">#!/bin/bash</span><br>
<span style="font-size:8pt">while :</span><br>
<span style="font-size:8pt">do</span><br>
<span style="font-size:8pt">~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \</span><br>
<span style="font-size:8pt">    stream://localhost \</span><br>
<span style="font-size:8pt">    --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001</span><br>
<span style="font-size:8pt">sleep 5</span><br>
<span style="font-size:8pt">done    </span></div>
<br>
<p></p>
<p>This looks like setting up a connection point to the outside world, right? And we find the third (random?) value for a buffer size.</p>
<p><br>
</p>
<p><br>
</p>
<p><b>- rate.bash</b><br>
</p>
<div><span style="font-size:8pt">../drasi/bin/lwrocmon --rate rio4-mcal-1</span></div>
<br>
<p></p>
<p>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.</p>
<p><br>
</p>
<p><br>
</p>
<p><b>- log.bash</b><br>
</p>
<div><span style="font-size:8pt">../drasi/bin/lwrocmon --log rio4-mcal-1 localhost</span></div>
<br>
<p></p>
<p>This is also easy to understand.<br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>Thank you very much!</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>Best greetings</p>
<p>Günter<br>
</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 12:25:42<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 Hakan,<br>
> <br>
> <br>
> thank you or your reply. Now I am bit lost because I thought that UPEXPS is<br>
> a central piece where important things happen. <br>
> <br>
> <br>
> Anyway, here is what GIT tells me about UPEXPS:<br>
> <br>
> mbsdaq@atpnbg011:~/mbsrun/rio4/2024_mcalstruck/upexps$ git log<br>
> commit 47db26b7743bf2676ebc2aa0a69e8cfae0e74ef4 (HEAD -> master)<br>
> Author: Bastian Loeher <b.loeher@gsi.de><br>
> Date:   Mon Mar 15 17:26:29 2021 +0100<br>
> <br>
> Therein is the folder MCAL_2019:<br>
> <br>
> mbsdaq@atpnbg011:~/mbsrun/rio4/2024_mcalstruck/upexps/mcal_2019$ ls -l<br>
> insgesamt 23052<br>
> -rw-r--r-- 1 mbsdaq users      137 Jan 12 13:41 control.hh<br>
> drwxr-sr-x 4 mbsdaq users     4096 Jan 12 13:37 gen_mcal<br>
> -rw-r--r-- 1 mbsdaq users      233 Jan 12 13:37 Makefile<br>
> -rw-r--r-- 1 mbsdaq users      102 Jan 12 13:41 makefile_additional.inc<br>
> -rw-r--r-- 1 mbsdaq users     1574 Jan 12 13:37 mapping.h<br>
> -rwxr-xr-x 1 mbsdaq users 12503880 Jan 12 13:41 mcal<br>
> -rw-r--r-- 1 mbsdaq users    24005 Jan 12 13:41 mcal.dep<br>
> -rw-r--r-- 1 mbsdaq users     1571 Jan 12 13:41 mcal.spec<br>
> -rw-r--r-- 1 mbsdaq users     2777 Jan 12 13:41 mcal_user.cc<br>
> -rwxr-xr-x 1 mbsdaq users 11020872 Jan 12 13:41 mcal.working<br>
> drwxr-sr-x 2 mbsdaq users     4096 Jan 12 13:41 mc_gen_mcal<br>
> drwxr-sr-x 2 mbsdaq users     4096 Jan 12 13:41 obj_mcal<br>
> -rw-r--r-- 1 mbsdaq users     6545 Jan 12 13:41 sis3316_mapping_macros.h<br>
> -rw-r--r-- 1 mbsdaq users     5082 Jan 12 13:41 vme_struck_sis3316.spec<br>
> <br>
> And my impression was that these files are somehow central to reading out<br>
> our DAQ system.<br>
<br>
True, for reading the data after the DAQ as such.<br>
<br>
> My understanding is that for initializing and readout of the modules by the<br>
> DAQ software, the following configuration files are used (they are in a<br>
> different directory):<br>
> <br>
> -rw-r--r-- 1 mbsdaq users        4883 Jan 12 13:44 main.cfg<br>
> <br>
> -rw-r--r-- 1 mbsdaq users         194 Jan 12 13:42 r3bfuser.cfg<br>
> <br>
> -rw-r--r-- 1 mbsdaq users        3065 Jan 12 13:42 vulom.trlo<br>
<br>
Yes.  Well outside upexps I hope.  ;)<br>
<br>
> But for telling UCESB what to find in the the LMD stream coming from the RIO<br>
> (which is a result of these configuration files), somehow a 'mapping' is<br>
> necessary. And this I associated with UPEXPS. But maybe my understanding was<br>
> wrong, if UPEXPS is not used by you guys.<br>
<br>
You are correct.<br>
<br>
Only distinction would that that ucesb / upexps are only involved to <br>
either read .lmd files, or to read live data streams (which is also on lmd <br>
format) from the DAQ.<br>
<br>
--<br>
<br>
With the git references above, we can hopefully try to figure out how deep <br>
into the other parts of upexps your directory has dependencies.<br>
<br>
But - as long as the data format has not changed - and the intention with <br>
the update to nurdlib etc was to not change any of those - the current <br>
unpacker specification and mapping should still work.  In fact - if it <br>
does not - then we do not want to fix the unpacking stages, but understand <br>
why the DAQ delivers different data.<br>
<br>
> After lunch, I will give it a try to simply start the DAQ.<br>
<br>
Cheers,<br>
Håkan</div>
</span></font>
</body>
</html>