[subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version

Weber, Guenter Dr. g.weber at hi-jena.gsi.de
Tue Jan 9 15:58:04 CET 2024


Dear Håkan,


in the last step (DRASI compilation) I now get this problem:


make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwrocmon'
   CC    bld_ppc-linux_4.2.2/lwrocmon.o
   CC    bld_ppc-linux_4.2.2/lwroc_mon_basic.o
   CC    bld_ppc-linux_4.2.2/lwroc_mon_rate.o
   CC    bld_ppc-linux_4.2.2/lwroc_mon_detail.o
   CC    bld_ppc-linux_4.2.2/lwroc_mon_tree.o
lwroc_mon_tree.c: In function 'lwroc_draw_mon_tree_item':
lwroc_mon_tree.c:3116: warning: 'label._ambiguity' may be used uninitialized in this function
   CC    bld_ppc-linux_4.2.2/lwroc_mon_status.o
  LINK   bin_ppc-linux_4.2.2/lwrocmon
   CC    bld_ppc-linux_4.2.2/lwroclog.o
  LINK   bin_ppc-linux_4.2.2/lwroclog
   CC    bld_ppc-linux_4.2.2/lwrocctrl.o
  LINK   bin_ppc-linux_4.2.2/lwrocctrl
  LINK   bin_ppc-linux_4.2.2/lwrocmerge
DOWNLOAD https://www.ietf.org/timezones/data/leap-seconds.list
curl: (6) Couldn't resolve host 'www.ietf.org'
../scripts/download-leap-seconds.sh: line 67: wget: command not found
Failed to download download/leap-seconds.list from https://www.ietf.org/timezones/data/leap-seconds.list
Try on other platform, or manually, or use IGNORELEAPSECONDFILE=1
make[1]: *** [download/leap-seconds.list] Error 1
make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwrocmon'
make: *** [lwrocmon_dir] Error 2


Problem 1: the RIO has no connection to the web.

Problem 2: the links is no longer valid, see here: https://www.ietf.org/timezones/data/leap-seconds.list


Possible solution for problem 2: https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list

(But I have no idea if this file has an identical structure or just the same name.)


There is the possibility to set the variable "LEAPFILE" that is used in "~/mbsrun/rio4/2024_mcalstruck/drasi/scripts/download-leap-seconds.sh" to point to a local file. However, LEAPFILE is set in the following way:


LEAPFILE=$1


So, I would need to know where "download-leap-seconds.sh" is called to give it the right value. And then cross the fingers that leap-seconds.list that I found on the web is the right one.


I am really curious how Bastian managed to compile DRASI on our system without running into this problem.


Alternatively, should I download the most recent DRASI version and give it a try?




Best greetings

Günter


________________________________
Von: subexp-daq <subexp-daq-bounces at lists.chalmers.se> im Auftrag von Håkan T Johansson <f96hajo at chalmers.se>
Gesendet: Dienstag, 9. Januar 2024 14:56:41
An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.
Betreff: Re: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version


Dear Günter,

the 'make drasi' in the 'r3bfuser' directory actually does not compile
drasi itself (I suspect) but a readout which uses files from drasi (and
trloii).  One suspicion is that due to the directory change, some paths
have ended up being hard-coded in the actual 'drasi' and 'trloii'
directories.

Since you are working in a full copy anyhow, please try

cd $EXP_PATH
pwd                # make sure it is the new path
cd trloii
make clean
make
cd trloctrl
make fw_d96ffc88_trlo_build
make fw_d374466d_tridi_build

cd $EXP_PATH
pwd                # make sure it is the new path
cd drasi
make

and then the compilation in the 'r3bfuser' directory.

---

Let's see if that helps.

Cheers,
Håkan



On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote:

>
> P.S.
>
>
> I also checked what is in the folder "build_cc_ppc-linux_4.2.2_debug" of the previous version of NURDLIB:
>
>
> RIO4-MCAL-2 mbsdaq > ls -l
> total 2192
> drwxr-sr-x  2 mbsdaq daq    4096 Jun 28  2023 _ccd/
> drwx--S---  3 mbsdaq daq    4096 Jun 28  2023 _hconf/
> drwxr-sr-x  2 mbsdaq daq    4096 Jun 28  2023 config/
> drwxr-sr-x  2 mbsdaq daq    4096 Jun 28  2023 crate/
> drwxr-sr-x  2 mbsdaq daq    4096 Jun 28  2023 ctrl/
> drwxr-sr-x  5 mbsdaq daq    4096 Mar  1  2023 hconf/
> -rw-r--r--  1 mbsdaq daq    1749 Jun 28  2023 hconf.cache
> -rw-r--r--  1 mbsdaq daq      11 Jun 28  2023 hconf.cache.ccd
> -rw-r--r--  1 mbsdaq daq 2174826 Sep 11 12:19 libnurdlib.a
> -rwxr-xr-x  1 mbsdaq daq   19974 Jun 28  2023 md5summer*
> drwxr-sr-x 48 mbsdaq daq    4096 Sep 11 12:19 module/
> drwxr-sr-x  5 mbsdaq daq    4096 Mar  1  2023 replacements/
> drwxr-sr-x  2 mbsdaq daq    4096 Jun 28  2023 tools/
> drwxr-sr-x  2 mbsdaq daq    4096 Jun 28  2023 util/
>
> Obviously, there are quite some differences. Maybe this helps to understand what the problem with DRASI compilation is.
>
>
>
>
>
> Best greetings
>
> Günter
>
>
>
> ________________________________________________________________________________________________________________________________
> Von: subexp-daq <subexp-daq-bounces at lists.chalmers.se> im Auftrag von Weber, Guenter Dr. <g.weber at hi-jena.gsi.de>
> Gesendet: Dienstag, 9. Januar 2024 13:28:24
> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.
> Betreff: Re: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version
>
> Dear Hans,
>
>
> here is the result when I try to compile DRASI:
>
>
> RIO4-MCAL-2 mbsdaq > make drasi
> rm -f build_cc_ppc-linux_4.2.2_debug
> [ -d build_cc_ppc-linux_4.2.2_debug_drasi ] || mkdir -p build_cc_ppc-linux_4.2.2_debug_drasi
> ln -s build_cc_ppc-linux_4.2.2_debug_drasi build_cc_ppc-linux_4.2.2_debug
> make -f Makefile.drasi
> sed: can't read ../nurdlib/build_cc_ppc-linux_4.2.2_debug/hconf.cache: No such file or directory
> sed: can't read ../nurdlib/build_cc_ppc-linux_4.2.2_debug/hconf.cache: No such file or directory
> make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser'
> make -C ../nurdlib lib
> Could not figure out RFX1 firmware (8-xdigit number), skipping.
> TRIDI_FW=d374466d
> VULOM4_FW=d96ffc88
> RFX1_FW=
> make[2]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib'
> make[2]: Nothing to be done for `lib'.
> make[2]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib'
> make[1]: *** No rule to make target `../nurdlib/build_cc_ppc-linux_4.2.2_debug/hconf.cache', needed by
> `build_cc_ppc-linux_4.2.2_debug/hconf.cache'.  Stop.
> make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser'
> make: *** [drasi] Error 2
>
> As "hconf.cache" is not found, I had a look at the content of "nurdlib/build_cc_ppc-linux_4.2.2_debug":
>
> RIO4-MCAL-2 mbsdaq > ls -l
> total 8084
> drwxr-sr-x  2 mbsdaq daq    4096 Jan  8 14:27 config/
> drwxr-sr-x  2 mbsdaq daq    4096 Jan  8 14:27 crate/
> drwxr-sr-x  2 mbsdaq daq    4096 Jan  9 10:54 ctrl/
> -rw-r--r--  1 mbsdaq daq 2165210 Jan  9 10:54 libnurdlib.a
> -rwxr-xr-x  1 mbsdaq daq   19930 Jan  8 14:27 md5summer*
> drwxr-sr-x 54 mbsdaq daq    4096 Jan  8 14:28 module/
> drwx--S---  5 mbsdaq daq    4096 Jan  8 14:27 nconf/
> -rw-r--r--  1 mbsdaq daq     400 Jan  8 14:27 nconf.args
> -rw-r--r--  1 mbsdaq daq       4 Jan  8 14:27 nconf.args.1st
> -rwxr-xr-x  1 mbsdaq daq   27707 Jan  8 14:27 nconfer*
> drwx--S---  3 mbsdaq daq    4096 Jan  8 14:27 nconfing/
> drwxr-sr-x  3 mbsdaq daq    4096 Jan  8 14:29 ntest/
> -rwxr-xr-x  1 mbsdaq daq 1726034 Jan  9 10:54 nurdctrl*
> drwxr-sr-x  5 mbsdaq daq    4096 Jan  8 14:27 replacements/
> -rwxr-xr-x  1 mbsdaq daq 2381977 Jan  8 14:29 test*
> -rw-r--r--  1 mbsdaq daq  116999 Jan  9 10:54 test.log
> -rwxr-xr-x  1 mbsdaq daq 1724366 Jan  9 10:54 test_ctrl*
> -rw-r--r--  1 mbsdaq daq    3612 Jan  9 10:54 test_ctrl.log
> -rw-r--r--  1 mbsdaq daq       0 Jan  9 10:54 test_ctrl_ok
> -rwxr-xr-x  1 mbsdaq daq   42392 Jan  8 14:29 test_ntest*
> -rw-r--r--  1 mbsdaq daq    1217 Jan  8 14:29 test_ntest.log
> -rw-r--r--  1 mbsdaq daq       0 Jan  8 14:29 test_ntest_ok
> -rw-r--r--  1 mbsdaq daq       0 Jan  9 10:54 test_ok
> drwxr-sr-x  3 mbsdaq daq    4096 Jan  9 10:54 tests/
> drwxr-sr-x  2 mbsdaq daq    4096 Jan  9 10:55 tools/
> drwxr-sr-x  2 mbsdaq daq    4096 Jan  8 14:28 util/
>
>
> Do you have any idea what went wrong? Maybe the DRASI version that is on our machine is too old and compatible with the most
> recent NURDLIB version?
>
>
>
>
> Best greetings
>
> Günter
>
>
>
> ________________________________________________________________________________________________________________________________
> Von: subexp-daq <subexp-daq-bounces at lists.chalmers.se> im Auftrag von Hans Toshihide Törnqvist <hans.tornqvist at chalmers.se>
> Gesendet: Dienstag, 9. Januar 2024 11:31:34
> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr.
> Betreff: Re: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version
> Dear Günter,
>
> On 2024-01-09 11:18, Weber, Guenter Dr. wrote:
> > Dear Hans, dear Håkan,
> >
> > now the compilation was successful.
>
> *Thumbs up*
>
> > Side note:
> >
> > 'export VARIABLE_NAME=VARIABLE_VALUE' did not work on our RIO4. Instead
> > 'setenv VARIABLE_NAME VARIABLE_VALUE' needed to be used. Probably, this
> > due to not using bash but tcsh (for whatever reason).
>
> If I remember correctly, the historical reason was to easily have the
> .bashrc for normal systems and the .tcshrc for DAQ systems.
>
> > Now I updated the NURDLIB, right? To check if it actually works with the
> > hardware present, I would now need to run the DAQ and have a look at the
> > output data.
>
> You also need to rebuild the f-user. Nurdlib provides the library to
> read out hardware, the f-user is the piece of code between nurdlib and
> the DAQ backend, in this case drasi.
> So, something like:
>
> cp -r r3bfuser r3bfuser.20240109 # Backup!
> cd r3bfuser
> rm -rf build_*
> make drasi
>
> I'm pretty sure that r3bfuser looks for nurdlib in "../nurdlib/".
>
> > Will DRASI automatically work with the new NURDLIB or do I need to
> > compile it again?
>
> This would solved with the r3bfuser rebuild :)
> Eventually, once this nurdlib business is settled, you could consider
> updating drasi too. It's good practice, updating and backing things up.
>
> > Will also UCESB automatically adapt to the new NURDLIB or do I need to
> > compile it again?
>
> Should be fine as is.
>
> > (I am a bit puzzled by the fact that it is
> > '~/mbsrun/rio4/mcalstruck/ucesb/...' and not
> > '~/mbsrun/rio4/2023_mcalstruck/ucesb/...'. This seems to be inconsistent.)
>
> Feel free to play around, again once the nurdlib stuff is done!
>
> > Moreover, I found the following environment variables that (to my
> > understanding) tell the various parts of the DAQ software where it can
> > find some necessary stuff:
> >
> > TRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/trloii
> > TRIDI_CTRL=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/bin_ppc-linux_4.2.2/tridi_ctrl
> > TRIMI_CTRL=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/trloii/trimictrl/bin_ppc-linux_4.2.2/trimictrl
> > TRLOII_FLASH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/trloii/flash/bin_ppc-linux_4.2.2/vulomflash
> > VULOM4_CTRL=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/bin_ppc-linux_4.2.2/trlo_ctrl
> > EXP_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck
> > HTOOLS_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/htools
> >
> > As I copied the complete folder structure of '2023_mcalstruck' to
> > '2024_mcalstruck', to be consistent I will redefine all this variables
> > to point to the new folder.
>
> Good idea, and eventually you may want to automate this with a set of
> other scripts for future DAQ:s :)
>
> > Best greetings from Jena
> >
> > Günter
> Cheers,
> Hans
> --
> subexp-daq mailing list
> subexp-daq at lists.chalmers.se
> https://lists.chalmers.se/mailman/listinfo/subexp-daq
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chalmers.se/pipermail/subexp-daq/attachments/20240109/6166f4c4/attachment-0001.html>


More information about the subexp-daq mailing list