<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,</p>
<p><br>
</p>
<p>with the help of <font face="Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols" size="4" color="black">
<span id="x_divtagdefaultwrapper" style="font-size:14pt">Håkan</span></font>, I managed to get the VULOM running. So, we are back to starting the DRASI. There we encountered first the fact that in main.cfg a BARRIER is now required between the initialization
of all modules (before there was only a single BARRIER command in the whole main.cfg.</p>
<p><br>
</p>
<p>Now, we are again encounter the VETAR error message. See below:</p>
<p><br>
</p>
<p></p>
<div><span style="font-size:8pt">10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: 56583).</span><br>
<span style="font-size:8pt">Thread has no error buffer yet...</span><br>
<span style="font-size:8pt">CPUS: 1</span><br>
<span style="font-size:8pt">delay: 1</span><br>
<span style="font-size:8pt">10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: 56583).</span><br>
<span style="font-size:8pt">Thread has no error buffer yet...</span><br>
<span style="font-size:8pt">HOST: RIO4-MCAL-1</span><br>
<span style="font-size:8pt">Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal]</span><br>
<span style="font-size:8pt">10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 (eth1).</span><br>
<span style="font-size:8pt">10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = 0x19000000, 1 consumers.</span><br>
<span style="font-size:8pt">10: lwroc_triva_readout.c:66: Silence TRIVA (HALT)</span><br>
<span style="font-size:8pt">10: lwroc_net_io.c:167: Started server on port 56583 (data port 50126).</span><br>
<span style="font-size:8pt">client union size: 244 208 188 508 640 204 204 => 640</span><br>
<span style="font-size:8pt">10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583</span><br>
<span style="font-size:8pt">10: lwroc_main.c:706: Log message rate limit not in effect.</span><br>
<span style="font-size:8pt">10: lwroc_readout.c:112: call readout_init...</span><br>
<span style="font-size:8pt">10: lwroc_thread_util.c:117: This is the triva control thread!</span><br>
<span style="font-size:8pt">10: lwroc_thread_util.c:117: This is the net io thread!</span><br>
<span style="font-size:8pt">10: lwroc_thread_util.c:117: This is the slow_async thread!</span><br>
<span style="font-size:8pt">10: lwroc_thread_util.c:117: This is the data server thread!</span><br>
<span style="font-size:8pt">10: lwroc_message_internal.c:472: Message client connected!</span><br>
<span style="font-size:8pt">10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) [192.168.1.1].</span><br>
<span style="font-size:8pt">10: lwroc_triva_control.c:370: Setup TRIVA (DISBUS, HALT, MASTER, RESET)</span><br>
<span style="font-size:8pt">10: lwroc_triva_control.c:418: Minimum event time ctime(5000)+1*rd(688)+3*wr(634)+fctime(1000)=8590 ns (116.414 kHz)</span><br>
<span style="font-size:8pt">10: lwroc_triva_state.c:1486: (Re)send ident messages...</span><br>
<span style="font-size:8pt">10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1</span><br>
<span style="font-size:8pt">9: lwroc_triva_control.c:507: TEST: GO</span><br>
<span style="font-size:8pt">10: lwroc_triva_control.c:725: RUN: RESET</span><br>
<span style="font-size:8pt">10: lwroc_triva_control.c:729: RUN: MT=14</span><br>
<span style="font-size:8pt">9: lwroc_triva_control.c:737: GO (1 good test triggers done) (max 116.4 kHz)</span><br>
<span style="font-size:8pt">10: lwroc_triva_readout.c:376: Trigger 14 seen.</span><br>
<span style="font-size:8pt">10: config/config.c:181: Will try default cfg path='/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default', can be set with NURDLIB_DEF_PATH.</span><br>
<span style="font-size:8pt">10: config/parser.c:287: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' {</span><br>
<span style="font-size:8pt">10: config/parser.c:299: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' }</span><br>
<span style="font-size:8pt">8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1</span><br>
<span style="font-size:8pt">10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0.</span><br>
<span style="font-size:8pt">8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting...</span><br>
<span style="font-size:8pt">10: config/parser.c:287: Opened './main.cfg' {</span><br>
<span style="font-size:8pt">10: config/config.c:1299: .Global log level=verbose.</span><br>
<span style="font-size:8pt">10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' {</span><br>
<span style="font-size:8pt">10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' }</span><br>
<span style="font-size:8pt">10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' {</span><br>
<span style="font-size:8pt">10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' }</span><br>
<span style="font-size:8pt">10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' {</span><br>
<span style="font-size:8pt">10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' }</span><br>
<span style="font-size:8pt">10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vetar.cfg' {</span><br>
<span style="font-size:8pt">10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vetar.cfg' }</span><br>
<span style="font-size:8pt">10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' {</span><br>
<span style="font-size:8pt">10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' }</span><br>
<span style="font-size:8pt">10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' {</span><br>
<span style="font-size:8pt">10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' }</span><br>
<span style="font-size:8pt">10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' {</span><br>
<span style="font-size:8pt">10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' }</span><br>
<span style="font-size:8pt">10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' {</span><br>
<span style="font-size:8pt">10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' }</span><br>
<span style="font-size:8pt">10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' {</span><br>
<span style="font-size:8pt">10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' }</span><br>
<span style="font-size:8pt">10: config/parser.c:299: Closed './main.cfg' }</span><br>
<span style="font-size:8pt">10: crate/crate.c:347: crate_create {</span><br>
<span style="font-size:8pt">10: crate/crate.c:673: crate_create(MCAL) }</span><br>
<span style="font-size:8pt">10: crate/crate.c:899: crate_init(MCAL) {</span><br>
<span style="font-size:8pt">10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM.</span><br>
<span style="font-size:8pt">LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC)</span><br>
<span style="font-size:8pt">10: crate/crate.c:923: .Slow-init module[1]=GSI_VETAR.</span><br>
<span style="font-size:8pt">5: module/gsi_etherbone/gsi_etherbone.c:431: ..Gsi Etherbone /sys/class/vetar/vetar0/dactl: Failed dactl fopen: No such file or directory.</span><br>
<span style="font-size:8pt">5: module/gsi_etherbone/gsi_etherbone.c:431: ..Calling abort()...</span></div>
<br>
<p></p>
<p>We are sure that the right NURDLIB path is used and also DRASI is started in the correct folder.</p>
<p><br>
</p>
<p>What we found in the enironment variables are two lines, where 'white rabbit' is mentioned. As I understand, this is connected to the VETAR2 module.</p>
<p><br>
</p>
<p></p>
<div><span style="font-size:8pt">LD_LIBRARY_PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/lib:/mbsusr/mbsdaq/mbsrun/whiterabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib</span><br>
<span style="font-size:8pt">PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/bin:/bin:/bin/ces:/usr/bin:/mbsusr/mbsdaq/bin:/usr/local/bin:/usr/bin/X11:/etc:/usr/etc:.:/mbsusr/mbsdaq/tools</span></div>
<br>
<p></p>
<p>Maybe, it is necessary to update something there?</p>
<p><br>
</p>
<p>Anyway, if you have now a switch in NURDLIB to deal with old software for the VETAR, then we should proceed with removing NURDLIB and getting the newer version, right?</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>Many thanks and have a nice weekend!</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>Best greetings</p>
<p>Günter<br>
</p>
<p><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 Hans Toshihide Törnqvist <hans.tornqvist@chalmers.se><br>
<b>Gesendet:</b> Donnerstag, 18. Januar 2024 13:28:36<br>
<b>An:</b> Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr.<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">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 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>
> <<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>
> 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>
> <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>
> <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>
-- <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>
</div>
</span></font>
</body>
</html>