<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 <span>Håkan</span>, dear Hans,<br>
</p>
<p><br>
</p>
<p>ok, so the problem is that we would need to update the firmware of the VULOM to make it work with the new TRLOII software, which in turn is probably needed to avoid the problem when compiling R3BFUSER? Is this correct?</p>
<p>So, I will set up a system with identical hardware, copy the software from the present system and then the first step would be to update the VULOM firmware on the new system?</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>Best greetings</p>
<p>Günter<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> Håkan T Johansson <f96hajo@chalmers.se><br>
<b>Gesendet:</b> Donnerstag, 11. Januar 2024 08:15:14<br>
<b>An:</b> Weber, Guenter Dr.<br>
<b>Cc:</b> Hans Toshihide Törnqvist<br>
<b>Betreff:</b> Re: AW: AW: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
Dear Günter,<br>
<br>
thanks!<br>
<br>
1) may be the reason for that strange error in typedefs.h, since it may be <br>
that it picks up the mystdint.h from the trloii compile but uses it in the <br>
drasi header somehow - or vice versa.... (They are the same and typically <br>
kept in sync, but we may here have hit a snag with the different versions <br>
and an update I did a while ago...)<br>
<br>
2) Should be fine, is just an attempt at indenting the pre-processor <br>
directives, without having my editor unindent the code.<br>
<br>
<br>
It sounds like a very nice plan if you have the hardware to set up a <br>
second system from scratch. I have attached a short instruction on how to <br>
downloading and compiling the codes from scratch.<br>
<br>
It would not surprise me if there already exist something like that, but <br>
then we have two of them :-) If not, we can put this (with whatever fixes <br>
are needed) up somewhere (gitlab wiki or so).<br>
<br>
I did test it - but that does not guarantee much...<br>
<br>
Cheers,<br>
Håkan<br>
<br>
<br>
<br>
On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote:<br>
<br>
> <br>
> P.S. I looked a bit into the code that is compiled right before the error<br>
> appear.<br>
> <br>
> <br>
> I have no idea if this might causing problems, but in<br>
> <br>
> ../dtc_arch/acc_def/mystdint.h<br>
> I found two things:<br>
> <br>
> <br>
> 1) <br>
> <br>
> New version:<br>
> <br>
> #if ACC_DEF__MYSTDINT_stdint_h<br>
> # include <stdint.h><br>
> #endif<br>
> /* This is a local fall-back solution, so should be last. */<br>
> #if ACC_DEF__MYSTDINT_mystdint<br>
> <br>
> Old version:<br>
> <br>
> #if ACC_DEF_MYSTDINT_stdint_h<br>
> # include <stdint.h><br>
> #endif<br>
> /* This is a local fall-back solution, so should be last. */<br>
> #if ACC_DEF_MYSTDINT_mystdint<br>
> <br>
> (Note the double "_" before MYSTDINT.)<br>
> <br>
> <br>
> 2)<br>
> <br>
> In both versions there are strange blanks after "#" at two positions:<br>
> <br>
> # include "acc_auto_def/mystdint.h"<br>
> # define UINT64_C(v) v##ULL<br>
> <br>
> <br>
> <br>
> Best greetings<br>
> <br>
> Günter<br>
> <br>
> <br>
> ____________________________________________________________________________<br>
> Von: Weber, Guenter Dr.<br>
> Gesendet: Mittwoch, 10. Januar 2024 19:32:59<br>
> An: Hans Toshihide Törnqvist<br>
> Betreff: AW: AW: [subexp-daq] NURDLIB: - how to check which version is<br>
> installed and how to update to the most recent version <br>
> <br>
> Dear Hans,<br>
> <br>
> <br>
> I could not reproduce the error from two hours ago. Nurdlib was laready set<br>
> to the right branch and in a second try compiled without problems on the<br>
> RIO.<br>
> <br>
> <br>
> However, we are now back at square one:<br>
> <br>
> <br>
> RIO4-MCAL-2 mbsdaq > make drasi<br>
> rm -f build_cc_ppc-linux_4.2.2_debug<br>
> [ -d build_cc_ppc-linux_4.2.2_debug_drasi ] || mkdir -p<br>
> build_cc_ppc-linux_4.2.2_debug_drasi<br>
> ln -s build_cc_ppc-linux_4.2.2_debug_drasi build_cc_ppc-linux_4.2.2_debug<br>
> make -f Makefile.drasi<br>
> make[1]: Entering directory<br>
> `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser'<br>
> NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args<br>
> UDP:ARPA_INET_H<br>
> CC build_cc_ppc-linux_4.2.2_debug/f_user.o<br>
> CC build_cc_ppc-linux_4.2.2_debug/subevent.o<br>
> In file included from/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/<br>
> s_veshe.h:6,<br>
> from ./subevent.h:11,<br>
> from subevent.c:1:<br>
> /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/<br>
> typedefs.h:6: error: expected '=', ',', ';', 'asm' or '__attribute__'<br>
> before 'INTS8'<br>
> /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/<br>
> typedefs.h:7: error: expected '=', ',', ';', 'asm' or '__attribute__'<br>
> before 'INTU8'<br>
> /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/<br>
> typedefs.h:8: error: expected '=', ',', ';', 'asm' or '__attribute__'<br>
> before 'INTS4'<br>
> /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/<br>
> typedefs.h:9: error: expected '=', ',', ';', 'asm' or '__attribute__'<br>
> before 'INTU4'<br>
> /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/<br>
> typedefs.h:10: error: expected '=', ',', ';', 'asm' or '__attribute__'<br>
> before 'INTS2'<br>
> /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/<br>
> typedefs.h:11: error: expected '=', ',', ';', 'asm' or '__attribute__'<br>
> before 'INTU2'<br>
> /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/<br>
> typedefs.h:12: error: expected '=', ',', ';', 'asm' or '__attribute__'<br>
> before 'INTS1'<br>
> /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/<br>
> typedefs.h:13: error: expected '=', ',', ';', 'asm' or '__attribute__'<br>
> before 'INTU1'<br>
> In file included from ./subevent.h:11,<br>
> from subevent.c:1:<br>
> /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/<br>
> s_veshe.h:11: error: expected specifier-qualifier-list before 'INTS4'<br>
> subevent.c: In function 'begin_goosy_vme_subevent':<br>
> subevent.c:12: error: 's_veshe' has no member named 'l_dlen'<br>
> subevent.c: In function 'end_goosy_vme_subevent':<br>
> subevent.c:45: error: 's_veshe' has no member named 'l_dlen'<br>
> make[1]: *** [build_cc_ppc-linux_4.2.2_debug/subevent.o] Error 1<br>
> make[1]: Leaving directory<br>
> `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser'<br>
> make: *** [drasi] Error 2<br>
> RIO4-MCAL-2 mbsdaq ><br>
> <br>
> Thus, downloading and recompiling DRASI, NURDLIB, and R3BFUSER did not solve<br>
> the problem with the latter.<br>
> <br>
> <br>
> <br>
> 😞<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> Best greetings<br>
> <br>
> Günter<br>
> <br>
> <br>
> <br>
> <br>
> ____________________________________________________________________________<br>
> Von: Hans Toshihide Törnqvist <hans.tornqvist@chalmers.se><br>
> Gesendet: Mittwoch, 10. Januar 2024 18:24:21<br>
> An: Weber, Guenter Dr.<br>
> Betreff: Re: AW: [subexp-daq] NURDLIB: - how to check which version is<br>
> installed and how to update to the most recent version <br>
> Sorry I got held up.<br>
> <br>
> I compiled 'mcal_daq_merge' from Gitlab on a rio4 just fine, so I am<br>
> just as puzzled where those event buffer test errors come from...<br>
> <br>
> Any luck with a 'make clean && make'?<br>
> <br>
> Cheers,<br>
> <br>
> Hans<br>
> <br>
> On 2024-01-10 17:36, Weber, Guenter Dr. wrote:<br>
> > Dear Hans,<br>
> ><br>
> ><br>
> > now things really get weird.<br>
> ><br>
> ><br>
> > I again downloaded NURDLIB, DRASI, and R3BFUSER. DRASI compiled without<br>
> > problems (first on PC, then on RIO).<br>
> ><br>
> ><br>
> > Now NURDLIB compilation stops with an error:<br>
> ><br>
> ><br>
> > LD build_cc_ppc-linux_4.2.2_debug/test_ntest<br>
> > LD build_cc_ppc-linux_4.2.2_debug/test<br>
> > /bin/sh: line 1: 22504 Aborted <br>
> > ./build_cc_ppc-linux_4.2.2_debug/test ><br>
> > build_cc_ppc-linux_4.2.2_debug/test.log 2>&1<br>
> > [tests/argmatch.c:127: Shorts]<br>
> > [tests/argmatch.c:128: Longs]<br>
> > [tests/argmatch.c:129: Combos]<br>
> > [tests/argmatch.c:130: ShortsWithValues]<br>
> > [tests/argmatch.c:131: LongsWithValues]<br>
> > [tests/argmatch.c:132: MissingValue]<br>
> > [tests/base.c:110: MemoryCheck]<br>
> > [tests/base.c:111: EventBufferAdvance]<br>
> > 2024-02-10,19:58:33:ERRR: Invalid pointer to advance event buffer.<br>
> > [tests/base.c:47]<br>
> > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:47]<br>
> > 2024-02-10,19:58:33:ERRR: Invalid pointer to advance event buffer.<br>
> > [tests/base.c:56]<br>
> > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:56]<br>
> > 2024-02-10,19:58:33:ERRR: Tried to advance outside event buffer.<br>
> > [tests/base.c:72]<br>
> > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:72]<br>
> > [tests/base.c:112: EventBufferInvariant]<br>
> > 2024-02-10,19:58:33:ERRR: Event-buffer inconsistent (0x1080e008:11 !=<br>
> > 0x1080e008:10). [tests/base.c:87]<br>
> > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:87]<br>
> > 2024-02-10,19:58:33:ERRR: Event-buffer inconsistent (0x1080e008:9 !=<br>
> > 0x1080e008:10). [tests/base.c:91]<br>
> > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:91]<br>
> > 2024-02-10,19:58:33:ERRR: Event-buffer inconsistent (0x1080e009:10 !=<br>
> > 0x1080e008:10). [tests/base.c:95]<br>
> > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:95]<br>
> > 2024-02-10,19:58:33:ERRR: Event-buffer inconsistent (0x1080e007:10 !=<br>
> > 0x1080e008:10). [tests/base.c:99]<br>
> > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:99]<br>
> > [tests/bits.c:43: Gets]<br>
> > [tests/bits.c:44: CountLoops]<br>
> > [tests/caen_v1190.c:79: DefaultConfig]<br>
> > 2024-02-10,19:58:33:INFO: Will try default cfg<br>
> > path='/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg',<br>
> > can be set with NURDLIB_DEF_PATH. [config/config.c:181]<br>
> > 2024-02-10,19:58:33:INFO: Opened './tests/caen_v1190_empty.cfg' {<br>
> > [config/parser.c:287]<br>
> > 2024-02-10,19:58:33:ERRR: .Could not load default or user config<br>
> > 'caen_v1190.cfg'. [config/config.c:1483]<br>
> > 2024-02-10,19:58:33:ERRR: .Calling abort()... [config/config.c:1483]<br>
> > make: *** [build_cc_ppc-linux_4.2.2_debug/test_ok] Error 1<br>
> ><br>
> ><br>
> > Did you change anything in the GITLAB version between yesterday and 15<br>
> > minutes ago?<br>
> ><br>
> ><br>
> ><br>
> > Sorry, sorry, sorry 😞<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > Best greetings<br>
> ><br>
> > Günter<br>
> ><br>
> ><br>
> ><br>
> > P.S. Tomorrow or on Friday, I will set up a second DAQ system with<br>
> > identical hardware. Then we can play around with no limits, including<br>
> > flashing the firmware of the VULOM, without messing around with the<br>
> > already running system as it is the case now.<br>
> ><br>
> ><br>
> > ------------------------------------------------------------------------<br>
> > *Von:* Hans Toshihide Törnqvist <hans.tornqvist@chalmers.se><br>
> > *Gesendet:* Mittwoch, 10. Januar 2024 16:59:07<br>
> > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter<br>
> Dr.<br>
> > *Betreff:* Re: [subexp-daq] NURDLIB: - how to check which version is<br>
> > installed and how to update to the most recent version<br>
> > Dear Günter,<br>
> ><br>
> > Did you try to update r3bfuser? I cannot see this problem with new<br>
> > versions of drasi+nurdlib+r3bfuser that are on Gitlab, and the trloii<br>
> > version shouldn't matter much in this case.<br>
> ><br>
> > Cheers,<br>
> ><br>
> > Hans<br>
> ><br>
> > On 2024-01-10 16:54, Weber, Guenter Dr. wrote:<br>
> >> Dear Håkan,<br>
> >><br>
> >><br>
> >> I followed your suggestion and the result is this:<br>
> >><br>
> >><br>
> >> RIO4-MCAL-2 mbsdaq > make drasi<br>
> >> rm -f build_cc_ppc-linux_4.2.2_debug<br>
> >> [ -d build_cc_ppc-linux_4.2.2_debug_drasi ] || mkdir -p<br>
> >> build_cc_ppc-linux_4.2.2_debug_drasi<br>
> >> ln -s build_cc_ppc-linux_4.2.2_debug_drasi build_cc_ppc-linux_4.2.2_debug<br>
> >> make -f Makefile.drasi<br>
> >> make[1]: Entering directory<br>
> >> `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser'<br>
> >> CC build_cc_ppc-linux_4.2.2_debug/subevent.o<br>
> >> In file included from ./subevent.h:11,<br>
> >> from subevent.c:1:<br>
> >>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/<br>
> s_veshe.h:16: error: expected specifier-qualifier-list before 'CHARS'<br>
> >> make[1]: *** [build_cc_ppc-linux_4.2.2_debug/subevent.o] Error 1<br>
> >> make[1]: Leaving directory<br>
> >> `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser'<br>
> >> make: *** [drasi] Error 2<br>
> >><br>
> >><br>
> >> Best greetings<br>
> >><br>
> >> Günter<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:* Mittwoch, 10. Januar 2024 16:07:52<br>
> >> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.<br>
> >> *Betreff:* Re: [subexp-daq] NURDLIB: - how to check which version is<br>
> >> installed and how to update to the most recent version<br>
> >><br>
> >> Dear Günter,<br>
> >><br>
> >> those errors look strange to me. I am not able to reproduce on a similar<br>
> >> system.<br>
> >><br>
> >> As a workaround (to see how far we get), in subevent.h in the r3bfuser/<br>
> >> directory, could you uncomment these:<br>
> >><br>
> >> #define MBS_TYPEDEFS_H<br>
> >> typedef char CHARX;<br>
> >> typedef int short INTS2;<br>
> >> typedef int INTS4;<br>
> >><br>
> >> and comment out the "typedefs.h" in<br>
> >><br>
> >>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/<br>
> s_veshe.h<br>
> >><br>
> >> on line 6. And then try again.<br>
> >><br>
> >> Cheers,<br>
> >> Håkan<br>
> >><br>
> >><br>
> >> On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote:<br>
> >><br>
> >>><br>
> >>> Dear Hans,<br>
> >>><br>
> >>><br>
> >>> I now did rebuild NURDLIB and DRASI. Then I tried to compile R3BFUSER<br>
> and this is the result:<br>
> >>><br>
> >>><br>
> >>> RIO4-MCAL-2 mbsdaq > cd r3bfuser/<br>
> >>> RIO4-MCAL-2 mbsdaq > make drasi<br>
> >>> rm -f build_cc_ppc-linux_4.2.2_debug<br>
> >>> [ -d build_cc_ppc-linux_4.2.2_debug_drasi ] || mkdir -p<br>
> build_cc_ppc-linux_4.2.2_debug_drasi<br>
> >>> ln -s build_cc_ppc-linux_4.2.2_debug_drasi<br>
> build_cc_ppc-linux_4.2.2_debug<br>
> >>> make -f Makefile.drasi<br>
> >>> make[1]: Entering directory<br>
> `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser'<br>
> >>> NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args<br>
> >>> UDP:ARPA_INET_H<br>
> >>> CC build_cc_ppc-linux_4.2.2_debug/f_user.o<br>
> >>> CC build_cc_ppc-linux_4.2.2_debug/subevent.o<br>
> >>> In file included from/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/<br>
> s_veshe.h:6,<br>
> >>> from ./subevent.h:11,<br>
> >>> from subevent.c:1:<br>
> >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/<br>
> typedefs.h:6: error: expected '=', ',', ';', 'asm' or '__attribute__'<br>
> before 'INTS8'<br>
> >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/<br>
> typedefs.h:7: error: expected '=', ',', ';', 'asm' or '__attribute__'<br>
> before 'INTU8'<br>
> >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/<br>
> typedefs.h:8: error: expected '=', ',', ';', 'asm' or '__attribute__'<br>
> before 'INTS4'<br>
> >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/<br>
> typedefs.h:9: error: expected '=', ',', ';', 'asm' or '__attribute__'<br>
> before 'INTU4'<br>
> >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/<br>
> typedefs.h:10: error: expected '=', ',', ';', 'asm' or '__attribute__'<br>
> before 'INTS2'<br>
> >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/<br>
> typedefs.h:11: error: expected '=', ',', ';', 'asm' or '__attribute__'<br>
> before 'INTU2'<br>
> >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/<br>
> typedefs.h:12: error: expected '=', ',', ';', 'asm' or '__attribute__'<br>
> before 'INTS1'<br>
> >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/<br>
> typedefs.h:13: error: expected '=', ',', ';', 'asm' or '__attribute__'<br>
> before 'INTU1'<br>
> >>> In file included from ./subevent.h:11,<br>
> >>> from subevent.c:1:<br>
> >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/<br>
> s_veshe.h:11: error: expected specifier-qualifier-list before 'INTS4'<br>
> >>> subevent.c: In function 'begin_goosy_vme_subevent':<br>
> >>> subevent.c:12: error: 's_veshe' has no member named 'l_dlen'<br>
> >>> subevent.c: In function 'end_goosy_vme_subevent':<br>
> >>> subevent.c:45: error: 's_veshe' has no member named 'l_dlen'<br>
> >>> make[1]: *** [build_cc_ppc-linux_4.2.2_debug/subevent.o] Error 1<br>
> >>> make[1]: Leaving directory<br>
> `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser'<br>
> >>> make: *** [drasi] Error 2<br>
> >>><br>
> >>> Reminder: I am using the most recent versions of NURDLIB and DRASI, but<br>
> because of the incompatibility of the VULOM firmware I use the old version<br>
> of TRLOII. In addition,<br>
> >>> because of the leap seconds issue I compiled DRASI first on the PC and<br>
> then recompiled it on the RIO (without "make clean").<br>
> >>><br>
> >>><br>
> >>><br>
> >>><br>
> >>><br>
> >>><br>
> >>><br>
> >>> Best greetings<br>
> >>> Günter<br>
> >>><br>
> >>><br>
> >>>___________________________________________________________________________<br>
> __________________________________________________________________________<br>
> _____________________<br>
> >>> Von: Hans Toshihide Törnqvist <hans.tornqvist@chalmers.se><br>
> >>> Gesendet: Mittwoch, 10. Januar 2024 13:18:41<br>
> >>> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter<br>
> Dr.<br>
> >>> Betreff: Re: [subexp-daq] NURDLIB: - how to check which version is<br>
> installed and how to update to the most recent version<br>
> >>> Dear Günter,<br>
> >>><br>
> >>> I would suggest rebuilding nurdlib now that trlo2 has been rebuilt, and<br>
> >>> then also rebuild r3bfuser.<br>
> >>><br>
> >>> After that probably you can try to run the DAQ :)<br>
> >>><br>
> >>> Cheers,<br>
> >>> Hans<br>
> >>><br>
> >>> On 2024-01-10 13:15, Weber, Guenter Dr. wrote:<br>
> >>> > Dear Håkan,<br>
> >>> ><br>
> >>> ><br>
> >>> > using the old TRLOII folder and then recompiling was successfull.<br>
> >>> ><br>
> >>> ><br>
> >>> > Should I now give it a try to start the DAQ? Or is there something<br>
> else<br>
> >>> > I still need to adjust?<br>
> >>> ><br>
> >>> ><br>
> >>> ><br>
> >>> ><br>
> >>> > Best greetings<br>
> >>> ><br>
> >>> > Günter<br>
> >>> ><br>
> >>> ><br>
> >>> ><br>
> >>> ><br>
> >>> ><br>
> ------------------------------------------------------------------------<br>
> >>> > *Von:* subexp-daq <subexp-daq-bounces@lists.chalmers.se> im Auftrag<br>
> von<br>
> >>> > Håkan T Johansson <f96hajo@chalmers.se><br>
> >>> > *Gesendet:* Mittwoch, 10. Januar 2024 12:34:26<br>
> >>> > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.<br>
> >>> > *Betreff:* Re: [subexp-daq] NURDLIB: - how to check which version is<br>
> >>> > installed and how to update to the most recent version<br>
> >>> ><br>
> >>> > Hi Günter,<br>
> >>> ><br>
> >>> > On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote:<br>
> >>> ><br>
> >>> >><br>
> >>> >> Hi folks,<br>
> >>> >><br>
> >>> >><br>
> >>> >> the old "./find_firmware.pl" was working. This is the output:<br>
> >>> >><br>
> >>> >><br>
> >>> >> a1729cda ../ver/rimfaxe0_trlo/rfx0_defs.h<br>
> >>> >> 0866c243 ../ver/rimfaxe1_trlo/rfx1_defs.h<br>
> >>> >> 5e8f5ef4 ../ver/tridi1_trlo/tridi_defs.h<br>
> >>> >> 6e4ba1a9 ../ver/vulom4_trlo/trlo_defs.h<br>
> >>> >> 68f8955e ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h<br>
> >>> >> af33ed35 ../ver/vulom4_trlo_big/trlo_big_defs.h<br>
> >>> >> 1409285e ../ver/vulom4b_trlo/trlo_defs.h<br>
> >>> >> d374466d ../fw/tridi1_trlo/tridi_defs.h<br>
> >>> >> d96ffc88 ../fw/vulom4_trlo/trlo_defs.h<br>
> >>> >> 5b298165 ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h<br>
> >>> >> 6f28c0f8 ../fw/vulom4_trlo_big/trlo_big_defs.h<br>
> >>> >> fa5020ea ../fw/vulom4_trlo_led/trlo_defs.h<br>
> >>> >> 426cb99c ../fw/vulom4b_trlo/trlo_defs.h<br>
> >>> >> MKDIR fw_a1729cda_rfx0 # ../ver/rimfaxe0_trlo/rfx0_defs.h<br>
> >>> >> SYMLINK fw_a1729cda_rfx0/rfx0_defs.h -><br>
> ../../ver/rimfaxe0_trlo/rfx0_defs.h<br>
> >>> >> MKDIR fw_0866c243_rfx1 # ../ver/rimfaxe1_trlo/rfx1_defs.h<br>
> >>> >> SYMLINK fw_0866c243_rfx1/rfx1_defs.h -><br>
> ../../ver/rimfaxe1_trlo/rfx1_defs.h<br>
> >>> >> MKDIR fw_5e8f5ef4_tridi # ../ver/tridi1_trlo/tridi_defs.h<br>
> >>> >> SYMLINK fw_5e8f5ef4_tridi/tridi_defs.h -><br>
> ../../ver/tridi1_trlo/tridi_defs.h<br>
> >>> >> MKDIR fw_6e4ba1a9_trlo # ../ver/vulom4_trlo/trlo_defs.h<br>
> >>> >> SYMLINK fw_6e4ba1a9_trlo/trlo_defs.h -><br>
> ../../ver/vulom4_trlo/trlo_defs.h<br>
> >>> >> SYMLINK fw_1409285e_trlo -> fw_6e4ba1a9_trlo<br>
> >>> >> MKDIR fw_68f8955e_trlo_all_in #<br>
> ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h<br>
> >>> >> SYMLINK fw_68f8955e_trlo_all_in/trlo_all_in_defs.h -><br>
> ../../ver/vulom4_trlo_all_in/trlo_all_in_defs.h<br>
> >>> >> MKDIR fw_af33ed35_trlo_big #<br>
> ../ver/vulom4_trlo_big/trlo_big_defs.h<br>
> >>> >> SYMLINK fw_af33ed35_trlo_big/trlo_big_defs.h -><br>
> ../../ver/vulom4_trlo_big/trlo_big_defs.h<br>
> >>> >> MKDIR fw_d374466d_tridi # ../fw/tridi1_trlo/tridi_defs.h<br>
> >>> >> SYMLINK fw_d374466d_tridi/tridi_defs.h -><br>
> ../../fw/tridi1_trlo/tridi_defs.h<br>
> >>> >> MKDIR fw_d96ffc88_trlo # ../fw/vulom4_trlo/trlo_defs.h<br>
> >>> >> SYMLINK fw_d96ffc88_trlo/trlo_defs.h -><br>
> ../../fw/vulom4_trlo/trlo_defs.h<br>
> >>> >> SYMLINK fw_426cb99c_trlo -> fw_d96ffc88_trlo<br>
> >>> >> SYMLINK fw_fa5020ea_trlo -> fw_d96ffc88_trlo<br>
> >>> >> MKDIR fw_5b298165_trlo_all_in #<br>
> ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h<br>
> >>> >> SYMLINK fw_5b298165_trlo_all_in/trlo_all_in_defs.h -><br>
> ../../fw/vulom4_trlo_all_in/trlo_all_in_defs.h<br>
> >>> >> MKDIR fw_6f28c0f8_trlo_big # ../fw/vulom4_trlo_big/trlo_big_defs.h<br>
> >>> >> SYMLINK fw_6f28c0f8_trlo_big/trlo_big_defs.h -><br>
> ../../fw/vulom4_trlo_big/trlo_big_defs.h<br>
> >>> >><br>
> >>> >> However, the compilation did end with an error:<br>
> >>> >><br>
> >>> >><br>
> >>> >> make[1]: Entering directory`/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ff<br>
> c88_trlo'<br>
> >>> >> CC bld_ppc-linux_4.2.2/src/trlo_check_version.o<br>
> >>> >> CC bld_ppc-linux_4.2.2/src/trlo_functions.o<br>
> >>> >> ../trlolib/src/trlo_functions.c: In function 'trlo_clear_config':<br>
> >>> >> ../trlolib/src/trlo_functions.c:144: error: 'trlo_setup_map' has no<br>
> member named 'sync_check_start_mux'<br>
> >>> >> ../trlolib/src/trlo_functions.c:146: error: 'trlo_setup_map' has no<br>
> member named 'sync_check_stop_mux'<br>
> >>> >> ../trlolib/src/trlo_functions.c: In function 'trlo_print_config':<br>
> >>> >> ../trlolib/src/trlo_functions.c:825: error: 'trlo_setup_map' has no<br>
> member named 'sync_check_start_mux'<br>
> >>> >> ../trlolib/src/trlo_functions.c:829: error: 'trlo_setup_map' has no<br>
> member named 'sync_check_stop_mux'<br>
> >>> >> ../trlolib/src/trlo_functions.c: In function<br>
> 'trlo_print_trig_status':<br>
> >>> >> ../trlolib/src/trlo_functions.c:1155: error: 'trlo_output_map' has no<br>
> member named 'trig_sync_check'<br>
> >>> >> make[1]: *** [bld_ppc-linux_4.2.2/src/trlo_functions.o] Error 1<br>
> >>> >> make[1]: Leaving directory`/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ff<br>
> c88_trlo'<br>
> >>> >><br>
> >>> >> make[1]: Entering directory`/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d3744<br>
> 66d_tridi'<br>
> >>> >> CC bld_ppc-linux_4.2.2/src/tridi_check_version.o<br>
> >>> >> CC bld_ppc-linux_4.2.2/src/tridi_functions.o<br>
> >>> >> ../trlolib/src/trlo_functions.c: In function 'tridi_clear_config':<br>
> >>> >> ../trlolib/src/trlo_functions.c:144: error: 'tridi_setup_map' has no<br>
> member named 'sync_check_start_mux'<br>
> >>> >> ../trlolib/src/trlo_functions.c:146: error: 'tridi_setup_map' has no<br>
> member named 'sync_check_stop_mux'<br>
> >>> >> ../trlolib/src/trlo_functions.c: In function 'tridi_print_config':<br>
> >>> >> ../trlolib/src/trlo_functions.c:825: error: 'tridi_setup_map' has no<br>
> member named 'sync_check_start_mux'<br>
> >>> >> ../trlolib/src/trlo_functions.c:829: error: 'tridi_setup_map' has no<br>
> member named 'sync_check_stop_mux'<br>
> >>> >> ../trlolib/src/trlo_functions.c: In function<br>
> 'tridi_print_trig_status':<br>
> >>> >> ../trlolib/src/trlo_functions.c:1155: error: 'tridi_output_map' has<br>
> no member named 'trig_sync_check'<br>
> >>> >> make[1]: *** [bld_ppc-linux_4.2.2/src/tridi_functions.o] Error 1<br>
> >>> >> make[1]: Leaving directory`/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d3744<br>
> 66d_tridi'<br>
> >>> >> make: *** [fw_d374466d_tridi_build] Error 2<br>
> >>> ><br>
> >>> > That's what I feared. The new code want something (sync_check_...)<br>
> not in<br>
> >>> > the older firmware...<br>
> >>> ><br>
> >>> >> The fallback option is now to delete the new TRLOII folder and<br>
> replace it with old one and then repeat the following steps?<br>
> >>> >><br>
> >>> >><br>
> >>> >> cd trloii<br>
> >>> >> make clean<br>
> >>> >> make<br>
> >>> >> cd trloctrl<br>
> >>> >> make fw_d96ffc88_trlo_build<br>
> >>> >> make fw_d374466d_tridi_build<br>
> >>> >><br>
> >>> >><br>
> >>> >> Is this correct?<br>
> >>> ><br>
> >>> > Yes.<br>
> >>> ><br>
> >>> > There should then already be the trloii/fw/ directory, and the links<br>
> that<br>
> >>> > are created by find_firmware.pl<br>
> >>> ><br>
> >>> ><br>
> >>> >> I also looked for the "--addr=" and this is the result:<br>
> >>> ><br>
> >>> >> ...<br>
> >>> ><br>
> >>> > Ok. I was too optimistic here. I looked through the grep results,<br>
> but<br>
> >>> > nothing obvious. Should be figurable by checking the old scripts and<br>
> >>> > following them around. Is a good way to see how things are done<br>
> anyhow ;)<br>
> >>> ><br>
> >>> > Cheers,<br>
> >>> > Håkan<br>
> >>> ><br>
> >>> ><br>
> >>> >><br>
> >>> >><br>
> >>> >><br>
> >>> >> Best greetings<br>
> >>> >><br>
> >>> >> Günter<br>
> >>> ><br>
> >>><br>
> >>><br>
> >><br>
> <br>
></div>
</span></font>
</body>
</html>