[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 14:49:33 CET 2024
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/f429f498/attachment-0001.html>
More information about the subexp-daq
mailing list