<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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>for the first time the DAQ is not crashing. However, it keeps repeating an error message.</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 36192).</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(689)+3*wr(634)+fctime(1000)=8591 ns (116.401 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">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">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 '/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:205: ...eb_device_open: Opening device failed: system failure</span><br>
<span style="font-size:8pt">10: crate/crate.c:683: .crate_deinit(MCAL) {</span><br>
<span style="font-size:8pt">10: crate/crate.c:707: .crate_deinit(MCAL) }</span><br>
<span style="font-size:8pt">8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime.</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: 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:205: ...eb_device_open: Opening device failed: system failure</span><br>
<span style="font-size:8pt">10: crate/crate.c:683: .crate_deinit(MCAL) {</span><br>
<span style="font-size:8pt">10: crate/crate.c:707: .crate_deinit(MCAL) }</span><br>
<span style="font-size:8pt">8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime.</span><br>
<span style="font-size:8pt">8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1</span></div>
...<br>
<p></p>
<p><br>
</p>
<p>To me it looks like the VETAR still has a problem, right? I should note that at our lab in Jena we have nothing to connect the VETAR with. So, it is running stand-alone. Maybe this is relevant.</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> Hans Toshihide Törnqvist <hans.tornqvist@chalmers.se><br>
<b>Gesendet:</b> Montag, 22. Januar 2024 14:15:01<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">On 2024-01-22 13:16, Weber, Guenter Dr. wrote:<br>
> The next problem looks like this:<br>
> <br>
> 10: config/parser.c:299: Closed './main.cfg' }<br>
> 10: crate/crate.c:347: crate_create {<br>
> 5: config/config.c:376: ..Block 'GSI_VETAR' (./main.cfg:8:2) does not <br>
> have requested param [0].<br>
> 5: config/config.c:376: ..Calling abort()...<br>
> <br>
> Maybe, the interpreter for the main.cfg is now a bit more strict than <br>
> before? Is it maybe the module hardware address that is missing? But <br>
> this was not needed before for some weird reason (how does the software <br>
> know where to look for the VETAR then?).<br>
<br>
Aha, back then the Vetars we bought and the template implementations we <br>
received were always on address 0x50000000 (7 zeros) and that was <br>
hardcoded into nurdlib. Meanwhile I tried other addresses which worked, <br>
so the config now requires this. I would prefer to keep this explicit <br>
and update old config files, since it is rather useful information.<br>
<br>
So, please try GSI_VETAR(0x50000000) {...}<br>
<br>
> Best greetings and sorry for all these problems 😞<br>
<br>
Many problems are due to me not having been proactive enough, especially <br>
with external users to keep the software more up-to-date, for which I <br>
would like to apologise. This adventure has fixed a huge number things <br>
in my backlog, I appreciate your work and patience a lot! Your trials <br>
will benefit many other DAQ users who rely on these codes :)<br>
<br>
Best regards,<br>
Hans<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:* Montag, 22. Januar 2024 11:46:56<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>
> Dear Günter,<br>
> <br>
> I'm sorry, my discipline slipped and I forgot to push that commit also<br>
> to the public Gitlab... It's available there now.<br>
> <br>
> Best regards,<br>
> Hans<br>
> <br>
> On 2024-01-22 11:40, Weber, Guenter Dr. wrote:<br>
>> Dear Hans, dear Håkan,<br>
>> <br>
>> <br>
>> I now recompiled R3BFUSER, but still I get the same error message when <br>
>> starting DRASI.<br>
>> <br>
>> <br>
>> This is how the beginning how the beginning of main.cfg looks like:<br>
>> <br>
>> <br>
>> log_level=verbose # info, verbose, debug, spam<br>
>> CRATE("MCAL") {<br>
>> GSI_VULOM(0x03000000) {<br>
>> timestamp = true # needed to get timestamps in the data output<br>
>> }<br>
>> BARRIER<br>
>> GSI_VETAR {<br>
>> dactl = false<br>
>> direct = false<br>
>> }<br>
>> BARRIER<br>
>> SIS_3316(0x30000000) {<br>
>> ...<br>
>> <br>
>> Do you have any idea why the dactl command is not find found? Maybe <br>
>> NURDLIB on GITLAB does not have the modified VETAR files yet? I have <br>
>> next to zero experience, so probably I am wrong. But if the last change <br>
>> in MODULE is from six days ago, it might not be the most recent version, <br>
>> right?<br>
>> <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 <br>
>> Håkan T Johansson <f96hajo@chalmers.se><br>
>> *Gesendet:* Montag, 22. Januar 2024 11:13:36<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>
>> 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>
>>> > <<a href=""></a>http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html<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>
>>> >> <<a href=""></a>http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html<br>
>>> > <<a href=""></a>http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html<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>
>>> > <<a href=""></a>http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html<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>
>>> >> <<a href=""></a>http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html<br>
>>> > <<a href=""></a>http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html<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>
>>> > <<a href=""></a>http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html<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>
>>> >> <<a href=""></a>http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html<br>
>>> > <<a href=""></a>http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html<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>
>>> > <<a href=""></a>http://fy.chalmers.se/~f96hajo/trloii/description.txt<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>
>>> >> <<a href=""></a>http://fy.chalmers.se/~f96hajo/trloii/description.txt<br>
>>> > <<a href=""></a>http://fy.chalmers.se/~f96hajo/trloii/description.txt<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>
>> <<a href=""></a>https://lists.chalmers.se/mailman/listinfo/subexp-daq <br>
> <<a href="https://lists.chalmers.se/mailman/listinfo/subexp-daq">https://lists.chalmers.se/mailman/listinfo/subexp-daq</a>>><br>
>>> > <<a href=""></a>https://lists.chalmers.se/mailman/listinfo/subexp-daq<br>
>> <<a href=""></a>https://lists.chalmers.se/mailman/listinfo/subexp-daq <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>
> <<a href="https://lists.chalmers.se/mailman/listinfo/subexp-daq">https://lists.chalmers.se/mailman/listinfo/subexp-daq</a>><br>
>> <<a href=""></a>https://lists.chalmers.se/mailman/listinfo/subexp-daq <br>
> <<a href="https://lists.chalmers.se/mailman/listinfo/subexp-daq">https://lists.chalmers.se/mailman/listinfo/subexp-daq</a>>><br>
>>> <br>
>>><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>
</div>
</span></font>
</body>
</html>