<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 Hans, dear <span>Hċkan</span>,</p>
<p><br>
</p>
<p>I now recompiled R3BFUSER, but still I get the same error message when starting DRASI.</p>
<p><br>
</p>
<p>This is how the beginning how the beginning of main.cfg looks like:</p>
<p><br>
</p>
<div><span style="font-size:8pt">log_level=verbose # info, verbose, debug, spam</span><br>
<span style="font-size:8pt">CRATE("MCAL") { </span><br>
<span style="font-size:8pt"> GSI_VULOM(0x03000000) {</span><br>
<span style="font-size:8pt"> timestamp = true # needed to get timestamps in the data output</span><br>
<span style="font-size:8pt"> }</span><br>
<span style="font-size:8pt"> BARRIER </span><br>
<span style="font-size:8pt"> GSI_VETAR {</span><br>
<span style="font-size:8pt"> dactl = false</span><br>
<span style="font-size:8pt"> direct = false</span><br>
<span style="font-size:8pt"> }</span><br>
<span style="font-size:8pt"> BARRIER</span><br>
<span style="font-size:8pt"> SIS_3316(0x30000000) {</span></div>
<div><span style="font-size:8pt">...</span><br>
</div>
<br>
<p></p>
<p>Do you have any idea why the dactl command is not find found? Maybe NURDLIB on GITLAB does not have the modified VETAR files yet? I have next to zero experience, so probably I am wrong. But if the last change in MODULE is from six days ago, it might not
be the most recent version, right?</p>
<p><br>
</p>
<p><img size="0" id="x_img906492" tabindex="0" style="max-width:99.9%" src="cid:5f466f60-98e4-492f-9be7-7b138bb94c72"><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> Montag, 22. Januar 2024 11:13:36<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>
yes, r3bfuser depends on all of them (nurdlib, trloii, drasi), so needs a <br>
recompile. nurdlib also needs recompile if trloii is updated.<br>
<br>
Cheers,<br>
Hċkan<br>
<br>
<br>
On Mon, 22 Jan 2024, Weber, Guenter Dr. wrote:<br>
<br>
> <br>
> Dear Hans,<br>
> <br>
> <br>
> I updated the NURDLIB, but the new flag is not recognized.<br>
> <br>
> <br>
> 10: config/parser.c:299: .Closed'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu<br>
> le_log_level.cfg' }<br>
> 5: config/keyword.c:20: .Invalid keyword "dactl".<br>
> 5: config/keyword.c:20: .Calling abort()...<br>
> <br>
> Do I also need to recompile DRASI or R3BFUSER?<br>
> <br>
> <br>
> <br>
> <br>
> Best greetings<br>
> <br>
> Günter<br>
> <br>
> <br>
> <br>
> ____________________________________________________________________________<br>
> Von: subexp-daq <subexp-daq-bounces@lists.chalmers.se> im Auftrag von Hans<br>
> Toshihide Törnqvist <hans.tornqvist@chalmers.se><br>
> Gesendet: Freitag, 19. Januar 2024 16:31:37<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>
> Dear Günter,<br>
> <br>
> I have implemented the dactl switch in 'mcal_daq_merge', so in main.cfg:<br>
> <br>
> GSI_VETAR {<br>
> dactl = false<br>
> direct = false<br>
> }<br>
> <br>
> I do not know how the names of the Etherbone libraries (e.g. cherry and<br>
> enigma) relate to the driver. If the dactl file is not available, we<br>
> just have to skip dactl accesses and not allow the direct readout path.<br>
> <br>
> Have a good weekend you too!<br>
> <br>
> Best regards,<br>
> Hans<br>
> <br>
> On 2024-01-19 15:22, Weber, Guenter Dr. wrote:<br>
> > Dear Hans,<br>
> ><br>
> ><br>
> > with the help of Hċkan, I managed to get the VULOM running. So, we are<br>
> > back to starting the DRASI. There we encountered first the fact that in<br>
> > main.cfg a BARRIER is now required between the initialization of all<br>
> > modules (before there was only a single BARRIER command in the whole<br>
> > main.cfg.<br>
> ><br>
> ><br>
> > Now, we are again encounter the VETAR error message. See below:<br>
> ><br>
> ><br>
> > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port:<br>
> > 56583).<br>
> > Thread has no error buffer yet...<br>
> > CPUS: 1<br>
> > delay: 1<br>
> > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port:<br>
> > 56583).<br>
> > Thread has no error buffer yet...<br>
> > HOST: RIO4-MCAL-1<br>
> > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal]<br>
> > 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0<br>
> > (eth1).<br>
> > 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 =<br>
> > 0x19000000, 1 consumers.<br>
> > 10: lwroc_triva_readout.c:66: Silence TRIVA (HALT)<br>
> > 10: lwroc_net_io.c:167: Started server on port 56583 (data port 50126).<br>
> > client union size: 244 208 188 508 640 204 204 => 640<br>
> > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file:<br>
> > /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583<br>
> > 10: lwroc_main.c:706: Log message rate limit not in effect.<br>
> > 10: lwroc_readout.c:112: call readout_init...<br>
> > 10: lwroc_thread_util.c:117: This is the triva control thread!<br>
> > 10: lwroc_thread_util.c:117: This is the net io thread!<br>
> > 10: lwroc_thread_util.c:117: This is the slow_async thread!<br>
> > 10: lwroc_thread_util.c:117: This is the data server thread!<br>
> > 10: lwroc_message_internal.c:472: Message client connected!<br>
> > 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data)<br>
> > [192.168.1.1].<br>
> > 10: lwroc_triva_control.c:370: Setup TRIVA (DISBUS, HALT, MASTER, RESET)<br>
> > 10: lwroc_triva_control.c:418: Minimum event time<br>
> > ctime(5000)+1*rd(688)+3*wr(634)+fctime(1000)=8590 ns (116.414 kHz)<br>
> > 10: lwroc_triva_state.c:1486: (Re)send ident messages...<br>
> > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1<br>
> > 9: lwroc_triva_control.c:507: TEST: GO<br>
> > 10: lwroc_triva_control.c:725: RUN: RESET<br>
> > 10: lwroc_triva_control.c:729: RUN: MT=14<br>
> > 9: lwroc_triva_control.c:737: GO (1 good test triggers done) (max<br>
> > 116.4 kHz)<br>
> > 10: lwroc_triva_readout.c:376: Trigger 14 seen.<br>
> > 10: config/config.c:181: Will try default cfg<br>
> >path='/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default<br>
> ', can be set with NURDLIB_DEF_PATH.<br>
> > 10: config/parser.c:287: Opened<br>
> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/glob<br>
> al.cfg' {<br>
> > 10: config/parser.c:299: Closed<br>
> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/glob<br>
> al.cfg' }<br>
> > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10<br>
> > (IN_READOUT). EC: 1<br>
> > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0.<br>
> > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting...<br>
> > 10: config/parser.c:287: Opened './main.cfg' {<br>
> > 10: config/config.c:1299: .Global log level=verbose.<br>
> > 10: config/parser.c:287: .Opened<br>
> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crat<br>
> e.cfg' {<br>
> > 10: config/parser.c:299: .Closed<br>
> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crat<br>
> e.cfg' }<br>
> > 10: config/parser.c:287: .Opened<br>
> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_<br>
> vulom.cfg' {<br>
> > 10: config/parser.c:299: .Closed<br>
> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_<br>
> vulom.cfg' }<br>
> > 10: config/parser.c:287: .Opened<br>
> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu<br>
> le_log_level.cfg' {<br>
> > 10: config/parser.c:299: .Closed<br>
> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu<br>
> le_log_level.cfg' }<br>
> > 10: config/parser.c:287: .Opened<br>
> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_<br>
> vetar.cfg' {<br>
> > 10: config/parser.c:299: .Closed<br>
> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_<br>
> vetar.cfg' }<br>
> > 10: config/parser.c:287: .Opened<br>
> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu<br>
> le_log_level.cfg' {<br>
> > 10: config/parser.c:299: .Closed<br>
> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu<br>
> le_log_level.cfg' }<br>
> > 10: config/parser.c:287: .Opened<br>
> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_<br>
> 3316.cfg' {<br>
> > 10: config/parser.c:299: .Closed<br>
> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_<br>
> 3316.cfg' }<br>
> > 10: config/parser.c:287: .Opened<br>
> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu<br>
> le_log_level.cfg' {<br>
> > 10: config/parser.c:299: .Closed<br>
> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu<br>
> le_log_level.cfg' }<br>
> > 10: config/parser.c:287: .Opened<br>
> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_<br>
> 3316.cfg' {<br>
> > 10: config/parser.c:299: .Closed<br>
> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_<br>
> 3316.cfg' }<br>
> > 10: config/parser.c:287: .Opened<br>
> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu<br>
> le_log_level.cfg' {<br>
> > 10: config/parser.c:299: .Closed<br>
> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu<br>
> le_log_level.cfg' }<br>
> > 10: config/parser.c:299: Closed './main.cfg' }<br>
> > 10: crate/crate.c:347: crate_create {<br>
> > 10: crate/crate.c:673: crate_create(MCAL) }<br>
> > 10: crate/crate.c:899: crate_init(MCAL) {<br>
> > 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM.<br>
> > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC)<br>
> > 10: crate/crate.c:923: .Slow-init module[1]=GSI_VETAR.<br>
> > 5: module/gsi_etherbone/gsi_etherbone.c:431: ..Gsi Etherbone<br>
> > /sys/class/vetar/vetar0/dactl: Failed dactl fopen: No such file or<br>
> > directory.<br>
> > 5: module/gsi_etherbone/gsi_etherbone.c:431: ..Calling abort()...<br>
> ><br>
> > We are sure that the right NURDLIB path is used and also DRASI is<br>
> > started in the correct folder.<br>
> ><br>
> ><br>
> > What we found in the enironment variables are two lines, where 'white<br>
> > rabbit' is mentioned. As I understand, this is connected to the VETAR2<br>
> > module.<br>
> ><br>
> ><br>
> >LD_LIBRARY_PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/li<br>
> b:/mbsusr/mbsdaq/mbsrun/whiterabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib<br>
> >PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/bin:/bin:/bin<br>
> /ces:/usr/bin:/mbsusr/mbsdaq/bin:/usr/local/bin:/usr/bin/X11:/etc:/usr/etc<br>
> :.:/mbsusr/mbsdaq/tools<br>
> ><br>
> > Maybe, it is necessary to update something there?<br>
> ><br>
> ><br>
> > Anyway, if you have now a switch in NURDLIB to deal with old software<br>
> > for the VETAR, then we should proceed with removing NURDLIB and getting<br>
> > the newer version, right?<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > Many thanks and have a nice weekend!<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > Best greetings<br>
> ><br>
> > Günter<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > ------------------------------------------------------------------------<br>
> > *Von:* subexp-daq <subexp-daq-bounces@lists.chalmers.se> im Auftrag von<br>
> > Hans Toshihide Törnqvist <hans.tornqvist@chalmers.se><br>
> > *Gesendet:* Donnerstag, 18. Januar 2024 13:28:36<br>
> > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter<br>
> Dr.<br>
> > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB,<br>
> > TRLOII, DRASI, etc. were updated<br>
> > Dear Günter,<br>
> ><br>
> > It looks like either the Vetar driver failed, or the fw/driver is old<br>
> > and nurdlib expects a file that didn't exist a while back. If it's the<br>
> > latter I can add a switch to ignore this file, it's not critical for<br>
> > readout and is used to enter a faster readout mode.<br>
> ><br>
> > Which version of nurdlib is this? The files and line numbers don't match<br>
> > with what I see in the source code, and the last time gsi_etherbone.c<br>
> > changed was early last year.<br>
> ><br>
> > The message "Could not open so-and-so" should be for the device, e.g.<br>
> > /dev/pcie_wb0. This is used for the readout.<br>
> ><br>
> > The dactl file should fail with "Failed dactl fopen".<br>
> ><br>
> > To summarise, I would suggest to make sure that the correct nurdlib and<br>
> > r3bfuser are executed by the DAQ scripts. Meanwhile I will prepare a<br>
> > switch to ignore the dactl file which could anyhow be useful for old<br>
> > configurations, and to clean up the Etherbone error messages.<br>
> ><br>
> > Best regards,<br>
> > Hans<br>
> ><br>
> > On 2024-01-18 11:29, Weber, Guenter Dr. wrote:<br>
> >> Dear friends,<br>
> >><br>
> >><br>
> >> I now started the DAQ and it looks like there is a problem with the<br>
> >> VETAR2 module. Attached please find the output once the DAQ is started<br>
> >> 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<br>
> >> Hċkan 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,<br>
> >> TRLOII, 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<br>
> defined<br>
> >>> in vulom.trlo). Then DRASI is started with a bunch of parameters. Is<br>
> 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>
> > <<a href="http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html">http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html</a>><br>
> >> <<a href=""></a>http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html<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>
> > <<a href="http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html">http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html</a>><br>
> >> <<a href=""></a>http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html<br>
> > <<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>
> > <<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>
> >> <<a href=""></a>http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html<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>
> > <<a href="http://fy.chalmers.se/~f96hajo/trloii/description.txt">http://fy.chalmers.se/~f96hajo/trloii/description.txt</a>><br>
> >> <<a href=""></a>http://fy.chalmers.se/~f96hajo/trloii/description.txt<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<br>
> 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<br>
> 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<br>
> .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,<br>
> right?<br>
> >><br>
> >> Yes. It accepts connections and will serve them data for online<br>
> 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<br>
> raw<br>
> >> LMD events. (As is the 'transport protocol'.) That will be served on<br>
> 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<br>
> what<br>
> >>> the thing is doing in terms of number of trigger events, transported<br>
> 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>
> > --<br>
> > subexp-daq mailing list<br>
> > subexp-daq@lists.chalmers.se<br>
> > <a href="https://lists.chalmers.se/mailman/listinfo/subexp-daq">https://lists.chalmers.se/mailman/listinfo/subexp-daq</a><br>
> > <<a href="https://lists.chalmers.se/mailman/listinfo/subexp-daq">https://lists.chalmers.se/mailman/listinfo/subexp-daq</a>><br>
> ><br>
> --<br>
> subexp-daq mailing list<br>
> subexp-daq@lists.chalmers.se<br>
> <a href="https://lists.chalmers.se/mailman/listinfo/subexp-daq">https://lists.chalmers.se/mailman/listinfo/subexp-daq</a><br>
> <br>
></div>
</span></font>
</body>
</html>