<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>
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper" style="font-size:14pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p>Sorry, please ignore my last e-mail.</p>
<p><br>
</p>
<p>Now the automatic setting of the folder works.</p>
<p><br>
</p>
<p>But there is a real problem after executing of the VULOM command.</p>
<p><br>
</p>
<p></p>
<div>hwmap_mapvme.c:398: LOG: Virtual address for TRLO II @ VME 0x03000000 is 0x3005e000.</div>
<div>LOG: TRLO: MD5SUM: 0x426cb99c (CT: 5bba6507 = 2018-10-07 19:56:55 UTC)</div>
<div>WARNING: Known firmware (alias): 0x6e4ba1a9.</div>
<div>WARNING: Known firmware (alias): 0x1409285e.</div>
<div>WARNING: Known firmware (alias): 0xa73c5093.</div>
<div>WARNING: Known firmware (alias): 0x6e4ba1a9.</div>
<div>WARNING: Known firmware (alias): 0x1409285e.</div>
<div>FATAL: TRLO firmware wrong: 0x426cb99c, expected 0x6e4ba1a9 or alias.</div>
<br>
<p></p>
<p><br>
</p>
<p><br>
</p>
<p>Best greetings</p>
<p>Günter</p>
<p><br>
</p>
<p><br>
</p>
<div id="Signature">
<div style="font-family:Tahoma; font-size:13px"></div>
</div>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Von:</b> subexp-daq <subexp-daq-bounces@lists.chalmers.se> im Auftrag von Weber, Guenter Dr. <g.weber@hi-jena.gsi.de><br>
<b>Gesendet:</b> Freitag, 19. Januar 2024 09:58:21<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>
<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 <span>Håkan</span>, dear Hans,</p>
<p><br>
</p>
<p>it looks like the FW number that is identified is the wrong one.</p>
<p><br>
</p>
<p></p>
<div><span style="font-size:8pt">vulom_fw=`cat ${TRLOII_PATH}/fw/vulom4b_trlo/trlo_defs.h 2>&1 | grep MD5SUM_STAMP | sed 's/.*0x//'`</span></div>
<div><span style="font-size:8pt">export VULOM4_CTRL=$trloiipath/trloctrl/fw_${VULOM4_FW}_trlo/bin_${machine}_${version}/trlo_ctrl</span></div>
<br>
<p></p>
<p>On my system this results in the following path:</p>
<p><br>
</p>
<p><span style="font-size:8pt">VULOM4_CTRL=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/bin_ppc-linux_4.2.2/trlo_ctrl</span><br>
</p>
<p><span><br>
</span></p>
<p><span>But it is the wrong one.</span></p>
<p><br>
</p>
<p><span style="font-size:8pt">$VULOM4_CTRL --addr=$addr --clear-setup --config=vulom.trlo standalone module_trigger</span><br>
</p>
<p><span style="font-size:8pt">./trloii_setup.sh: line 12: /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/bin_ppc-linux_4.2.2/trlo_ctrl: No such file or directory</span><br>
</p>
<p><br>
</p>
<p>The right one would be:</p>
<div id="x_Signature">
<div style="">
<div style="font-family:Tahoma; font-size:13px"><font size="2" style="font-family:Tahoma"><span style="font-size:10pt"><br>
</span></font></div>
<div style="font-family:Tahoma; font-size:13px"><font size="2" style="font-family:Tahoma"><span style="font-size:10pt"><span style="font-size:8pt">/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo/bin_ppc-linux_4.2.2/<span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size:10.6667px">trlo_ctrl</span></span><br>
</span></font></div>
<div style="font-family:Tahoma; font-size:13px"><font size="2" style="font-family:Tahoma"><span style="font-size:10pt"><br>
</span></font></div>
<div style="font-family:Tahoma; font-size:13px"><font size="2" style="font-family:Tahoma"><span style="font-size:10pt"><br>
</span></font></div>
<div style=""><span style="font-size:18.6667px">In the TRLO/TRLOCTRL folder there are also other firmware numbers (which redirect to 1409285e, as I understand), but d96ffc88 is not among them.</span></div>
<div style=""><span style="font-size:18.6667px"><br>
</span></div>
<div style=""><span style="font-size:18.6667px">Do you guys have an idea what the problem is?</span></div>
<div style=""><span style="font-size:18.6667px"><br>
</span></div>
<div style=""><span style="font-size:18.6667px">I know that this is a side issue and I could hard code the right path, but I would like to make the thing as convenient as possible before I hand it over to the students
<span>😊</span></span></div>
<div style=""><span style="font-size:18.6667px"><span><br>
</span></span></div>
<div style=""><span style="font-size:18.6667px"><span><br>
</span></span></div>
<div style=""><span style="font-size:18.6667px"><span><br>
</span></span></div>
<div style=""><span style="font-size:18.6667px"><span>Best greetings</span></span></div>
<div style=""><span style="font-size:18.6667px"><span>Günter</span></span></div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> subexp-daq <subexp-daq-bounces@lists.chalmers.se> im Auftrag von Håkan T Johansson <f96hajo@chalmers.se><br>
<b>Gesendet:</b> Donnerstag, 18. Januar 2024 22:39:31<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 Thu, 18 Jan 2024, Weber, Guenter Dr. wrote:<br>
<br>
> <br>
> Dear Hans,<br>
> <br>
> <br>
> there was some redirect burried in the script which executes scripts which<br>
> execute some more scripts ... and that made me start the DAQ in the old<br>
> folder, not the new one. Sorry for that.<br>
> <br>
> <br>
> I now came across the following line in the script which starts the VULOM:<br>
> <br>
> <br>
> $VULOM4_CTRL --addr=$addr --clear-setup --config=vulom.trlo standalone<br>
> module_trigger<br>
> <br>
> <br>
> Here I need to know the firmware number to define the path VULOM4_CTRL,<br>
> right? Is there a way to do this automatically? Somehow this works already<br>
> in the makefile of NURDLIB.<br>
<br>
It looks like this is done with this line in the nurdlib Makefile:<br>
<br>
VULOM4_FW:=$(shell cat $(TRLOII_PATH)/fw/vulom4b_trlo/trlo_defs.h 2>&1 | grep MD5SUM_STAMP | sed 's/.*0x//')<br>
<br>
such that something like<br>
<br>
VULOM4_FW=`cat $(TRLOII_PATH)/fw/vulom4b_trlo/trlo_defs.h 2>&1 | grep MD5SUM_STAMP | sed 's/.*0x//'`<br>
<br>
might work in a shell script, if TRLOII_PATH is set, and the fw/ directory <br>
exists and has the current gatewares.<br>
<br>
'Funfact': This general mess with the TRLO II version numbers is of my <br>
creation, however a proper fix has so far required too much effort. <br>
Basically, the gateware would have to give info on the offsets and sizes <br>
of various controllable items (fairly easy), and the trloctrl program and <br>
functions would need to use that (much more complex - that it at all works <br>
is thanks to generation of many structures from that trlo_defs.h header, <br>
where some of them also intermix with the .trlo lexer/parser).<br>
<br>
> I would like to avoid to hard code this into the environment settings if<br>
> there is a way to figure it out on the fly.<br>
<br>
Cheers,<br>
Håkan<br>
<br>
<br>
<br>
> <br>
> <br>
> <br>
> Thanks so much!<br>
> <br>
> <br>
> <br>
> Best greetings<br>
> <br>
> Günter<br>
> <br>
> <br>
> <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: Donnerstag, 18. Januar 2024 13:28:36<br>
> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr.<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>
> 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>
> ><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,<br>
> 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<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>
> <br>
></div>
</span></font></div>
</body>
</html>