From hans.tornqvist at chalmers.se Sun Jan 7 20:33:55 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Sun, 7 Jan 2024 20:33:55 +0100 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: <86a9c0739b034950b6f804472850d5f0@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <8dd03122-aeb6-4dd3-9005-fb09bc1991a3@chalmers.se> <86a9c0739b034950b6f804472850d5f0@hi-jena.gsi.de> Message-ID: Dear G?nter, I took a shot at merging the 'mcal_daq' branch that you have been using with the 'master' branch, you can find that merge in the branch 'mcal_daq_merge'. That version passes my soft tests, but they are weak compared to a real running DAQ :) So please give it a try and let me know how it goes. Best regards, Hans On 2023-12-22 19:32, Weber, Guenter Dr. wrote: > Dear Hans, > > > the command > > > ?> git remote -v > > > resulted in the following output: > > > bloeher bloeher at 140.181.60.97:/u/bloeher/git-bare/nurdlib-jena.git (fetch) > bloeher bloeher at 140.181.60.97:/u/bloeher/git-bare/nurdlib-jena.git (push) > maxs1 > ?atpnbg011:/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib > (fetch) > maxs1 > ?atpnbg011:/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib (push) > origin? /u/htoernqv/repos/nurdlib.git/ (fetch) > origin? /u/htoernqv/repos/nurdlib.git/ (push) > > I added the new git repository and executed the push?command as > explained in your e-mail. Looks like everything worked out fine. > > > > > Best greetings > > G?nter > > > > ------------------------------------------------------------------------ > *Von:* Hans Toshihide T?rnqvist > *Gesendet:* Freitag, 22. Dezember 2023 18:25:05 > *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 2023-12-22 17:55, Weber, Guenter Dr. wrote: >> Dear Hakan, >> >> thank you very much for the reply. >> >> On my system the output of the command is as follows: >> >> git describe --all --always --dirty --long >> ->?heads/mcal_daq-0-gb2bc721 >> >> How shall I interpret this output? > > It looks like your repository has the branch 'mcal_daq' active, and part > of the checksum is b2bc721. > > The very good news is that it doesn't say "-dirty" at the end, which > means that there are no uncommitted changes, yet :) > >> I guess I should compare it to something I can find under >> https://gitlab.com/chalmers-subexp > > > > It seems like the branch/commit are not in any of the "official" > repositories, I had a look. However, I did find 'mcal_daq' branches in > some private repositories at GSI by Bastii, but I cannot find the > b2bc721 commit. I also cannot find several of the commit messages. > > The safest way forward would be if you could push your version of > nurdlib to gitlab. It looks like you are currently a member of the > project, so try: > > ?> git remote -v > > If the gitlab repo is not listed there, do: > > ?> git remote add gitlab git at gitlab.com:chalmers-subexp/nurdlib.git > > Then: > > ?> git push gitlab mcal_daq > > I can then pull that and see how to get that into the main branch. Once > that's done, I will ask you to try the new version to make sure it still > runs correctly. And of course if there are problems with the above > commands, let us know. > > Best regards, > > Hans > >> But there I only can access the following projects: >> >> -?drasi >> -?egmwsort >> -?ucesb >> >> Best greetings >> G?nter >> >> >> ------------------------------------------------------------------------ >> *Von:* subexp-daq im Auftrag von >> H?kan T Johansson >> *Gesendet:* Freitag, 22. Dezember 2023 17:48:46 >> *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, >> >> On Fri, 22 Dec 2023, Weber, Guenter Dr. wrote: >> >>> >>> Dear all, >>> >>> >>> I would like to know how ... >>> >>> >>> 1) I can check which version of NURDLIB is installed on my system. >> >> Please somewhere under the nurdlib/ directory, run: >> >> git describe --all --always --dirty --long >> >>> 2) I can update to the most recent 'official' version. >> >> cd >> >> git clone git at gitlab.com:chalmers-subexp/nurdlib.git >> >> Then: >> >> cd nurdlib >> >> For that git clone to work, you'll first have to set up ssh keys with >> gitlab.? That would be useful also in order to upload code.? See: >> >> https://docs.gitlab.com/ee/user/ssh.html > >> > >> >> and please *do* use a passphrase for the ssh key. >> >> Cheers, >> H?kan >> >> >>> >>> >>> Thank you very much! >>> >>> >>> >>> Best greetings >>> >>> G?nter >>> >>> >>> >>> >> From g.weber at hi-jena.gsi.de Sun Jan 7 21:14:05 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Sun, 7 Jan 2024 20:14:05 +0000 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <8dd03122-aeb6-4dd3-9005-fb09bc1991a3@chalmers.se> <86a9c0739b034950b6f804472850d5f0@hi-jena.gsi.de>, Message-ID: Dear Hans, thank you very much and have a happy new year! Could you give me instructions on how to update NURDLIB in an already existing DAQ system? Would it be enough to replace the old files in the NURDLIB folder with the most recent ones and then somewhere type in "make"? And is compilation to be executed within the RIO system or on the server? Best greetings from Jena G?nter ________________________________ Von: Hans Toshihide T?rnqvist Gesendet: Sonntag, 7. Januar 2024 20:33:55 An: Weber, Guenter Dr.; Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: AW: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version Dear G?nter, I took a shot at merging the 'mcal_daq' branch that you have been using with the 'master' branch, you can find that merge in the branch 'mcal_daq_merge'. That version passes my soft tests, but they are weak compared to a real running DAQ :) So please give it a try and let me know how it goes. Best regards, Hans On 2023-12-22 19:32, Weber, Guenter Dr. wrote: > Dear Hans, > > > the command > > > > git remote -v > > > resulted in the following output: > > > bloeher bloeher at 140.181.60.97:/u/bloeher/git-bare/nurdlib-jena.git (fetch) > bloeher bloeher at 140.181.60.97:/u/bloeher/git-bare/nurdlib-jena.git (push) > maxs1 > atpnbg011:/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib > (fetch) > maxs1 > atpnbg011:/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib (push) > origin /u/htoernqv/repos/nurdlib.git/ (fetch) > origin /u/htoernqv/repos/nurdlib.git/ (push) > > I added the new git repository and executed the push command as > explained in your e-mail. Looks like everything worked out fine. > > > > > Best greetings > > G?nter > > > > ------------------------------------------------------------------------ > *Von:* Hans Toshihide T?rnqvist > *Gesendet:* Freitag, 22. Dezember 2023 18:25:05 > *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 2023-12-22 17:55, Weber, Guenter Dr. wrote: >> Dear Hakan, >> >> thank you very much for the reply. >> >> On my system the output of the command is as follows: >> >> git describe --all --always --dirty --long >> -> heads/mcal_daq-0-gb2bc721 >> >> How shall I interpret this output? > > It looks like your repository has the branch 'mcal_daq' active, and part > of the checksum is b2bc721. > > The very good news is that it doesn't say "-dirty" at the end, which > means that there are no uncommitted changes, yet :) > >> I guess I should compare it to something I can find under >> https://gitlab.com/chalmers-subexp > > > > It seems like the branch/commit are not in any of the "official" > repositories, I had a look. However, I did find 'mcal_daq' branches in > some private repositories at GSI by Bastii, but I cannot find the > b2bc721 commit. I also cannot find several of the commit messages. > > The safest way forward would be if you could push your version of > nurdlib to gitlab. It looks like you are currently a member of the > project, so try: > > > git remote -v > > If the gitlab repo is not listed there, do: > > > git remote add gitlab git at gitlab.com:chalmers-subexp/nurdlib.git > > Then: > > > git push gitlab mcal_daq > > I can then pull that and see how to get that into the main branch. Once > that's done, I will ask you to try the new version to make sure it still > runs correctly. And of course if there are problems with the above > commands, let us know. > > Best regards, > > Hans > >> But there I only can access the following projects: >> >> - drasi >> - egmwsort >> - ucesb >> >> Best greetings >> G?nter >> >> >> ------------------------------------------------------------------------ >> *Von:* subexp-daq im Auftrag von >> H?kan T Johansson >> *Gesendet:* Freitag, 22. Dezember 2023 17:48:46 >> *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, >> >> On Fri, 22 Dec 2023, Weber, Guenter Dr. wrote: >> >>> >>> Dear all, >>> >>> >>> I would like to know how ... >>> >>> >>> 1) I can check which version of NURDLIB is installed on my system. >> >> Please somewhere under the nurdlib/ directory, run: >> >> git describe --all --always --dirty --long >> >>> 2) I can update to the most recent 'official' version. >> >> cd >> >> git clone git at gitlab.com:chalmers-subexp/nurdlib.git >> >> Then: >> >> cd nurdlib >> >> For that git clone to work, you'll first have to set up ssh keys with >> gitlab. That would be useful also in order to upload code. See: >> >> https://docs.gitlab.com/ee/user/ssh.html > >> > >> >> and please *do* use a passphrase for the ssh key. >> >> Cheers, >> H?kan >> >> >>> >>> >>> Thank you very much! >>> >>> >>> >>> Best greetings >>> >>> G?nter >>> >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Sun Jan 7 21:48:21 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Sun, 7 Jan 2024 21:48:21 +0100 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <8dd03122-aeb6-4dd3-9005-fb09bc1991a3@chalmers.se> <86a9c0739b034950b6f804472850d5f0@hi-jena.gsi.de>, Message-ID: <35eb5fdf-6eea-32e2-fbdb-98ad2edc8d74@chalmers.se> Dear G?nter, I would very much suggest to do the 'update' in a copy of the directory tree that you are using, such that it is very easy to go back. (Or go between the systems.) For the update, something along the lines: git fetch origin # or instead of 'origin' the shorthand you have for the # remote repo git log --all --decorate --graph --oneline --color # just to see where # you are, and where you would go git checkout mcal_daq_merge # if that fails, try origin/mcal_daq_merge You would want to run the git commands etc on the PC, but compilations of code that runs on the RIO needs to be done on the RIO. A 'make clean' is probbaly a healthy start. But first - please make sure to work in copied directory tree. Cheers, H?kan On Sun, 7 Jan 2024, Weber, Guenter Dr. wrote: > > Dear Hans, > > > thank you very much and have a happy new year! > > > Could you give me instructions on?how to update NURDLIB in an already > existing DAQ system? > > > Would it be enough to replace the old files in the?NURDLIB folder with the > most recent ones and then somewhere?type in "make"? And is compilation to be > executed?within?the RIO system or on the server? > > > > > Best greetings from Jena > > G?nter > > > > > ____________________________________________________________________________ > Von: Hans Toshihide T?rnqvist > Gesendet: Sonntag, 7. Januar 2024 20:33:55 > An: Weber, Guenter Dr.; Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: AW: [subexp-daq] NURDLIB: - how to check which version is > installed and how to update to the most recent version ? > Dear G?nter, > > I took a shot at merging the 'mcal_daq' branch that you have been using > with the 'master' branch, you can find that merge in the branch > 'mcal_daq_merge'. > > That version passes my soft tests, but they are weak compared to a real > running DAQ :) So please give it a try and let me know how it goes. > > Best regards, > > Hans > > On 2023-12-22 19:32, Weber, Guenter Dr. wrote: > > Dear Hans, > > > > > > the command > > > > > >? ?> git remote -v > > > > > > resulted in the following output: > > > > > > bloeher bloeher at 140.181.60.97:/u/bloeher/git-bare/nurdlib-jena.git (fetch) > > bloeher bloeher at 140.181.60.97:/u/bloeher/git-bare/nurdlib-jena.git (push) > > maxs1? > >? ?atpnbg011:/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib > > (fetch) > > maxs1? > >? ?atpnbg011:/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib > (push) > > origin? /u/htoernqv/repos/nurdlib.git/ (fetch) > > origin? /u/htoernqv/repos/nurdlib.git/ (push) > > > > I added the new git repository and executed the push?command as > > explained in your e-mail. Looks like everything worked out fine. > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > > ------------------------------------------------------------------------ > > *Von:* Hans Toshihide T?rnqvist > > *Gesendet:* Freitag, 22. Dezember 2023 18:25:05 > > *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 2023-12-22 17:55, Weber, Guenter Dr. wrote: > >> Dear Hakan, > >> > >> thank you very much for the reply. > >> > >> On my system the output of the command is as follows: > >> > >> git describe --all --always --dirty --long > >> ->?heads/mcal_daq-0-gb2bc721 > >> > >> How shall I interpret this output? > > > > It looks like your repository has the branch 'mcal_daq' active, and part > > of the checksum is b2bc721. > > > > The very good news is that it doesn't say "-dirty" at the end, which > > means that there are no uncommitted changes, yet :) > > > >> I guess I should compare it to something I can find under > >> https://gitlab.com/chalmers-subexp > > > > > > > It seems like the branch/commit are not in any of the "official" > > repositories, I had a look. However, I did find 'mcal_daq' branches in > > some private repositories at GSI by Bastii, but I cannot find the > > b2bc721 commit. I also cannot find several of the commit messages. > > > > The safest way forward would be if you could push your version of > > nurdlib to gitlab. It looks like you are currently a member of the > > project, so try: > > > >? ?> git remote -v > > > > If the gitlab repo is not listed there, do: > > > >? ?> git remote add gitlab git at gitlab.com:chalmers-subexp/nurdlib.git > > > > Then: > > > >? ?> git push gitlab mcal_daq > > > > I can then pull that and see how to get that into the main branch. Once > > that's done, I will ask you to try the new version to make sure it still > > runs correctly. And of course if there are problems with the above > > commands, let us know. > > > > Best regards, > > > > Hans > > > >> But there I only can access the following projects: > >> > >> -?drasi > >> -?egmwsort > >> -?ucesb > >> > >> Best greetings > >> G?nter > >> > >> > >> ------------------------------------------------------------------------ > >> *Von:* subexp-daq im Auftrag von > >> H?kan T Johansson > >> *Gesendet:* Freitag, 22. Dezember 2023 17:48:46 > >> *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, > >> > >> On Fri, 22 Dec 2023, Weber, Guenter Dr. wrote: > >> > >>> > >>> Dear all, > >>> > >>> > >>> I would like to know how ... > >>> > >>> > >>> 1) I can check which version of NURDLIB is installed on my system. > >> > >> Please somewhere under the nurdlib/ directory, run: > >> > >> git describe --all --always --dirty --long > >> > >>> 2) I can update to the most recent 'official' version. > >> > >> cd > >> > >> git clone git at gitlab.com:chalmers-subexp/nurdlib.git > >> > >> Then: > >> > >> cd nurdlib > >> > >> For that git clone to work, you'll first have to set up ssh keys with > >> gitlab.? That would be useful also in order to upload code.? See: > >> > >> https://docs.gitlab.com/ee/user/ssh.html > > > >> > > > >> > >> and please *do* use a passphrase for the ssh key. > >> > >> Cheers, > >> H?kan > >> > >> > >>> > >>> > >>> Thank you very much! > >>> > >>> > >>> > >>> Best greetings > >>> > >>> G?nter > >>> > >>> > >>> > >>> > >> > > From g.weber at hi-jena.gsi.de Mon Jan 8 11:29:45 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Mon, 8 Jan 2024 10:29:45 +0000 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: <35eb5fdf-6eea-32e2-fbdb-98ad2edc8d74@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <8dd03122-aeb6-4dd3-9005-fb09bc1991a3@chalmers.se> <86a9c0739b034950b6f804472850d5f0@hi-jena.gsi.de>, , <35eb5fdf-6eea-32e2-fbdb-98ad2edc8d74@chalmers.se> Message-ID: <72c76512ca4c4e2fa4f39569b97a9e57@hi-jena.gsi.de> Dear Hans, I copied the directory of our existing DAQ system: > cp -r old_daq new_daq Then deleted the NURDLIB folder, downloaded the new one and switched to the mcal_daq_merge branch using > git checkout mcal_daq_merge Then I connected to the RIO and tried to compile in the folder of the new NURDLIB. This is the result: RIO4-MCAL-2 mbsdaq > make clean Could not figure out RFX1 firmware (8-xdigit number), skipping. TRIDI_FW=d374466d VULOM4_FW=d96ffc88 RFX1_FW= rm -rf build_cc_ppc-linux_4.2.2_debug No further message and a new folder build_cc_ppc-linux_4.2.2_debug is not created. When checking the Makefile, I noticed that in the old NURDLIB folder there is no /gmake, instead there is a file make.mk which probably does the same job. Probably there are some adjustment that I need to make, so that the new NURDLIB version can compile on our system. But I don't know where to look at, unfortunately. Could you give us advice? Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Sonntag, 7. Januar 2024 21:48:21 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, I would very much suggest to do the 'update' in a copy of the directory tree that you are using, such that it is very easy to go back. (Or go between the systems.) For the update, something along the lines: git fetch origin # or instead of 'origin' the shorthand you have for the # remote repo git log --all --decorate --graph --oneline --color # just to see where # you are, and where you would go git checkout mcal_daq_merge # if that fails, try origin/mcal_daq_merge You would want to run the git commands etc on the PC, but compilations of code that runs on the RIO needs to be done on the RIO. A 'make clean' is probbaly a healthy start. But first - please make sure to work in copied directory tree. Cheers, H?kan On Sun, 7 Jan 2024, Weber, Guenter Dr. wrote: > > Dear Hans, > > > thank you very much and have a happy new year! > > > Could you give me instructions on how to update NURDLIB in an already > existing DAQ system? > > > Would it be enough to replace the old files in the NURDLIB folder with the > most recent ones and then somewhere type in "make"? And is compilation to be > executed within the RIO system or on the server? > > > > > Best greetings from Jena > > G?nter > > > > > ____________________________________________________________________________ > Von: Hans Toshihide T?rnqvist > Gesendet: Sonntag, 7. Januar 2024 20:33:55 > An: Weber, Guenter Dr.; Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: AW: [subexp-daq] NURDLIB: - how to check which version is > installed and how to update to the most recent version > Dear G?nter, > > I took a shot at merging the 'mcal_daq' branch that you have been using > with the 'master' branch, you can find that merge in the branch > 'mcal_daq_merge'. > > That version passes my soft tests, but they are weak compared to a real > running DAQ :) So please give it a try and let me know how it goes. > > Best regards, > > Hans > > On 2023-12-22 19:32, Weber, Guenter Dr. wrote: > > Dear Hans, > > > > > > the command > > > > > > > git remote -v > > > > > > resulted in the following output: > > > > > > bloeher bloeher at 140.181.60.97:/u/bloeher/git-bare/nurdlib-jena.git (fetch) > > bloeher bloeher at 140.181.60.97:/u/bloeher/git-bare/nurdlib-jena.git (push) > > maxs1 > > atpnbg011:/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib > > (fetch) > > maxs1 > > atpnbg011:/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib > (push) > > origin /u/htoernqv/repos/nurdlib.git/ (fetch) > > origin /u/htoernqv/repos/nurdlib.git/ (push) > > > > I added the new git repository and executed the push command as > > explained in your e-mail. Looks like everything worked out fine. > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > > ------------------------------------------------------------------------ > > *Von:* Hans Toshihide T?rnqvist > > *Gesendet:* Freitag, 22. Dezember 2023 18:25:05 > > *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 2023-12-22 17:55, Weber, Guenter Dr. wrote: > >> Dear Hakan, > >> > >> thank you very much for the reply. > >> > >> On my system the output of the command is as follows: > >> > >> git describe --all --always --dirty --long > >> -> heads/mcal_daq-0-gb2bc721 > >> > >> How shall I interpret this output? > > > > It looks like your repository has the branch 'mcal_daq' active, and part > > of the checksum is b2bc721. > > > > The very good news is that it doesn't say "-dirty" at the end, which > > means that there are no uncommitted changes, yet :) > > > >> I guess I should compare it to something I can find under > >> https://gitlab.com/chalmers-subexp > > > > > > > It seems like the branch/commit are not in any of the "official" > > repositories, I had a look. However, I did find 'mcal_daq' branches in > > some private repositories at GSI by Bastii, but I cannot find the > > b2bc721 commit. I also cannot find several of the commit messages. > > > > The safest way forward would be if you could push your version of > > nurdlib to gitlab. It looks like you are currently a member of the > > project, so try: > > > > > git remote -v > > > > If the gitlab repo is not listed there, do: > > > > > git remote add gitlab git at gitlab.com:chalmers-subexp/nurdlib.git > > > > Then: > > > > > git push gitlab mcal_daq > > > > I can then pull that and see how to get that into the main branch. Once > > that's done, I will ask you to try the new version to make sure it still > > runs correctly. And of course if there are problems with the above > > commands, let us know. > > > > Best regards, > > > > Hans > > > >> But there I only can access the following projects: > >> > >> - drasi > >> - egmwsort > >> - ucesb > >> > >> Best greetings > >> G?nter > >> > >> > >> ------------------------------------------------------------------------ > >> *Von:* subexp-daq im Auftrag von > >> H?kan T Johansson > >> *Gesendet:* Freitag, 22. Dezember 2023 17:48:46 > >> *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, > >> > >> On Fri, 22 Dec 2023, Weber, Guenter Dr. wrote: > >> > >>> > >>> Dear all, > >>> > >>> > >>> I would like to know how ... > >>> > >>> > >>> 1) I can check which version of NURDLIB is installed on my system. > >> > >> Please somewhere under the nurdlib/ directory, run: > >> > >> git describe --all --always --dirty --long > >> > >>> 2) I can update to the most recent 'official' version. > >> > >> cd > >> > >> git clone git at gitlab.com:chalmers-subexp/nurdlib.git > >> > >> Then: > >> > >> cd nurdlib > >> > >> For that git clone to work, you'll first have to set up ssh keys with > >> gitlab. That would be useful also in order to upload code. See: > >> > >> https://docs.gitlab.com/ee/user/ssh.html > > > >> > > > >> > >> and please *do* use a passphrase for the ssh key. > >> > >> Cheers, > >> H?kan > >> > >> > >>> > >>> > >>> Thank you very much! > >>> > >>> > >>> > >>> Best greetings > >>> > >>> G?nter > >>> > >>> > >>> > >>> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.tornqvist at chalmers.se Mon Jan 8 11:38:23 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Mon, 8 Jan 2024 11:38:23 +0100 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: <72c76512ca4c4e2fa4f39569b97a9e57@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <8dd03122-aeb6-4dd3-9005-fb09bc1991a3@chalmers.se> <86a9c0739b034950b6f804472850d5f0@hi-jena.gsi.de> <35eb5fdf-6eea-32e2-fbdb-98ad2edc8d74@chalmers.se> <72c76512ca4c4e2fa4f39569b97a9e57@hi-jena.gsi.de> Message-ID: Dear G?nter, Aha, it looks like H?kan's instructions could be misinterpreted, what you are seeing is expected behaviour :) 'make clean' will clean the build directory, which it does with 'rm -rf build_...'. 'make' without additional arguments builds nurdlib which is what you want now. Cheers, Hans On 2024-01-08 11:29, Weber, Guenter Dr. wrote: > Dear Hans, > > > I copied the directory of our existing DAQ system: > > > cp -r old_daq new_daq > > > Then deleted the NURDLIB folder, downloaded the new one and switched to > the mcal_daq_merge branch using > > > git checkout mcal_daq_merge > > > Then I connected to the RIO and tried to compile in the folder of the > new NURDLIB. This is the result: > > RIO4-MCAL-2 mbsdaq > make clean > Could not figure out RFX1 firmware (8-xdigit number), skipping. > TRIDI_FW=d374466d > VULOM4_FW=d96ffc88 > RFX1_FW= > rm -rf build_cc_ppc-linux_4.2.2_debug > > > No further message and a new folder build_cc_ppc-linux_4.2.2_debug is > not created. > > > When checking the Makefile, I noticed that in the old NURDLIB folder > there is no /gmake, instead there is a file make.mk which probably does > the same job. > > > Probably there are some adjustment that I need to make, so that the new > NURDLIB version can compile on our system. But I don't know where to > look at, unfortunately. > > > Could you give us advice? > > > > > > Best greetings > > G?nter > > > > > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > H?kan T Johansson > *Gesendet:* Sonntag, 7. Januar 2024 21:48:21 > *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, > > I would very much suggest to do the 'update' in a copy of the directory > tree that you are using, such that it is very easy to go back.? (Or go > between the systems.) > > For the update, something along the lines: > > git fetch origin?? # or instead of 'origin' the shorthand you have for the > ??????????????????? # remote repo > > git log --all --decorate --graph --oneline --color?? # just to see where > ??????????????????????????????????????? # you are, and where you would go > > git checkout mcal_daq_merge??? # if that fails, try origin/mcal_daq_merge > > > You would want to run the git commands etc on the PC, but compilations of > code that runs on the RIO needs to be done on the RIO. > > A 'make clean' is probbaly a healthy start. > > But first - please make sure to work in copied directory tree. > > Cheers, > H?kan > > > > On Sun, 7 Jan 2024, Weber, Guenter Dr. wrote: > >> >> Dear Hans, >> >> >> thank you very much and have a happy new year! >> >> >> Could you give me instructions on?how to update NURDLIB in an already >> existing DAQ system? >> >> >> Would it be enough to replace the old files in the?NURDLIB folder with the >> most recent ones and then somewhere?type in "make"? And is compilation to be >> executed?within?the RIO system or on the server? >> >> >> >> >> Best greetings from Jena >> >> G?nter >> >> >> >> >> ____________________________________________________________________________ >> Von: Hans Toshihide T?rnqvist >> Gesendet: Sonntag, 7. Januar 2024 20:33:55 >> An: Weber, Guenter Dr.; Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> Betreff: Re: AW: [subexp-daq] NURDLIB: - how to check which version is >> installed and how to update to the most recent version >> Dear G?nter, >> >> I took a shot at merging the 'mcal_daq' branch that you have been using >> with the 'master' branch, you can find that merge in the branch >> 'mcal_daq_merge'. >> >> That version passes my soft tests, but they are weak compared to a real >> running DAQ :) So please give it a try and let me know how it goes. >> >> Best regards, >> >> Hans >> >> On 2023-12-22 19:32, Weber, Guenter Dr. wrote: >> > Dear Hans, >> > >> > >> > the command >> > >> > >> >? ?> git remote -v >> > >> > >> > resulted in the following output: >> > >> > >> > bloeher bloeher at 140.181.60.97:/u/bloeher/git-bare/nurdlib-jena.git (fetch) >> > bloeher bloeher at 140.181.60.97:/u/bloeher/git-bare/nurdlib-jena.git (push) >> > maxs1 >> >? ?atpnbg011:/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib >> > (fetch) >> > maxs1 >> >? ?atpnbg011:/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib >> (push) >> > origin? /u/htoernqv/repos/nurdlib.git/ (fetch) >> > origin? /u/htoernqv/repos/nurdlib.git/ (push) >> > >> > I added the new git repository and executed the push?command as >> > explained in your e-mail. Looks like everything worked out fine. >> > >> > >> > >> > >> > Best greetings >> > >> > G?nter >> > >> > >> > >> > ------------------------------------------------------------------------ >> > *Von:* Hans Toshihide T?rnqvist >> > *Gesendet:* Freitag, 22. Dezember 2023 18:25:05 >> > *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 2023-12-22 17:55, Weber, Guenter Dr. wrote: >> >> Dear Hakan, >> >> >> >> thank you very much for the reply. >> >> >> >> On my system the output of the command is as follows: >> >> >> >> git describe --all --always --dirty --long >> >> ->?heads/mcal_daq-0-gb2bc721 >> >> >> >> How shall I interpret this output? >> > >> > It looks like your repository has the branch 'mcal_daq' active, and part >> > of the checksum is b2bc721. >> > >> > The very good news is that it doesn't say "-dirty" at the end, which >> > means that there are no uncommitted changes, yet :) >> > >> >> I guess I should compare it to something I can find under >> >> https://gitlab.com/chalmers-subexp > > >> > >> >> > >> > It seems like the branch/commit are not in any of the "official" >> > repositories, I had a look. However, I did find 'mcal_daq' branches in >> > some private repositories at GSI by Bastii, but I cannot find the >> > b2bc721 commit. I also cannot find several of the commit messages. >> > >> > The safest way forward would be if you could push your version of >> > nurdlib to gitlab. It looks like you are currently a member of the >> > project, so try: >> > >> >? ?> git remote -v >> > >> > If the gitlab repo is not listed there, do: >> > >> >? ?> git remote add gitlab git at gitlab.com:chalmers-subexp/nurdlib.git >> > >> > Then: >> > >> >? ?> git push gitlab mcal_daq >> > >> > I can then pull that and see how to get that into the main branch. Once >> > that's done, I will ask you to try the new version to make sure it still >> > runs correctly. And of course if there are problems with the above >> > commands, let us know. >> > >> > Best regards, >> > >> > Hans >> > >> >> But there I only can access the following projects: >> >> >> >> -?drasi >> >> -?egmwsort >> >> -?ucesb >> >> >> >> Best greetings >> >> G?nter >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> *Von:* subexp-daq im Auftrag von >> >> H?kan T Johansson >> >> *Gesendet:* Freitag, 22. Dezember 2023 17:48:46 >> >> *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, >> >> >> >> On Fri, 22 Dec 2023, Weber, Guenter Dr. wrote: >> >> >> >>> >> >>> Dear all, >> >>> >> >>> >> >>> I would like to know how ... >> >>> >> >>> >> >>> 1) I can check which version of NURDLIB is installed on my system. >> >> >> >> Please somewhere under the nurdlib/ directory, run: >> >> >> >> git describe --all --always --dirty --long >> >> >> >>> 2) I can update to the most recent 'official' version. >> >> >> >> cd >> >> >> >> git clone git at gitlab.com:chalmers-subexp/nurdlib.git >> >> >> >> Then: >> >> >> >> cd nurdlib >> >> >> >> For that git clone to work, you'll first have to set up ssh keys with >> >> gitlab.? That would be useful also in order to upload code.? See: >> >> >> >> https://docs.gitlab.com/ee/user/ssh.html > >> > > >> >> > > >> >> >> >> >> and please *do* use a passphrase for the ssh key. >> >> >> >> Cheers, >> >> H?kan >> >> >> >> >> >>> >> >>> >> >>> Thank you very much! >> >>> >> >>> >> >>> >> >>> Best greetings >> >>> >> >>> G?nter >> >>> >> >>> >> >>> >> >>> >> >> >> >> > From g.weber at hi-jena.gsi.de Mon Jan 8 11:44:09 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Mon, 8 Jan 2024 10:44:09 +0000 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <8dd03122-aeb6-4dd3-9005-fb09bc1991a3@chalmers.se> <86a9c0739b034950b6f804472850d5f0@hi-jena.gsi.de> <35eb5fdf-6eea-32e2-fbdb-98ad2edc8d74@chalmers.se> <72c76512ca4c4e2fa4f39569b97a9e57@hi-jena.gsi.de>, Message-ID: Alright. Sorry for being stupid! With 'make' everything runs smoothly up to this point: ... SUITE build_cc_ppc-linux_4.2.2_debug/ntest/tests/fail.suite SUITE build_cc_ppc-linux_4.2.2_debug/ntest/tests/fixture.suite SUITE build_cc_ppc-linux_4.2.2_debug/ntest/tests/pass.suite SUITE build_cc_ppc-linux_4.2.2_debug/ntest/tests/signal.suite SUITE build_cc_ppc-linux_4.2.2_debug/ntest/tests/string.suite SUITE build_cc_ppc-linux_4.2.2_debug/ntest/tests/verbose.suite SUITS build_cc_ppc-linux_4.2.2_debug/ntest/tests/ntest_.suites NTEST build_cc_ppc-linux_4.2.2_debug/ntest/tests/ntest_.c CCGEN build_cc_ppc-linux_4.2.2_debug/ntest/tests/ntest_.o LD build_cc_ppc-linux_4.2.2_debug/test_ntest LD build_cc_ppc-linux_4.2.2_debug/test build_cc_ppc-linux_4.2.2_debug/tools/hwmap_error_internal.o:(.sdata+0x0): undefined reference to `trcom_hwmap_error_internal' collect2: ld returned 1 exit status make: *** [build_cc_ppc-linux_4.2.2_debug/test] Error 1 What should I do? Best greetings G?nter ________________________________ Von: Hans Toshihide T?rnqvist Gesendet: Montag, 8. Januar 2024 11:38:23 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, Aha, it looks like H?kan's instructions could be misinterpreted, what you are seeing is expected behaviour :) 'make clean' will clean the build directory, which it does with 'rm -rf build_...'. 'make' without additional arguments builds nurdlib which is what you want now. Cheers, Hans On 2024-01-08 11:29, Weber, Guenter Dr. wrote: > Dear Hans, > > > I copied the directory of our existing DAQ system: > > > cp -r old_daq new_daq > > > Then deleted the NURDLIB folder, downloaded the new one and switched to > the mcal_daq_merge branch using > > > git checkout mcal_daq_merge > > > Then I connected to the RIO and tried to compile in the folder of the > new NURDLIB. This is the result: > > RIO4-MCAL-2 mbsdaq > make clean > Could not figure out RFX1 firmware (8-xdigit number), skipping. > TRIDI_FW=d374466d > VULOM4_FW=d96ffc88 > RFX1_FW= > rm -rf build_cc_ppc-linux_4.2.2_debug > > > No further message and a new folder build_cc_ppc-linux_4.2.2_debug is > not created. > > > When checking the Makefile, I noticed that in the old NURDLIB folder > there is no /gmake, instead there is a file make.mk which probably does > the same job. > > > Probably there are some adjustment that I need to make, so that the new > NURDLIB version can compile on our system. But I don't know where to > look at, unfortunately. > > > Could you give us advice? > > > > > > Best greetings > > G?nter > > > > > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > H?kan T Johansson > *Gesendet:* Sonntag, 7. Januar 2024 21:48:21 > *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, > > I would very much suggest to do the 'update' in a copy of the directory > tree that you are using, such that it is very easy to go back. (Or go > between the systems.) > > For the update, something along the lines: > > git fetch origin # or instead of 'origin' the shorthand you have for the > # remote repo > > git log --all --decorate --graph --oneline --color # just to see where > # you are, and where you would go > > git checkout mcal_daq_merge # if that fails, try origin/mcal_daq_merge > > > You would want to run the git commands etc on the PC, but compilations of > code that runs on the RIO needs to be done on the RIO. > > A 'make clean' is probbaly a healthy start. > > But first - please make sure to work in copied directory tree. > > Cheers, > H?kan > > > > On Sun, 7 Jan 2024, Weber, Guenter Dr. wrote: > >> >> Dear Hans, >> >> >> thank you very much and have a happy new year! >> >> >> Could you give me instructions on how to update NURDLIB in an already >> existing DAQ system? >> >> >> Would it be enough to replace the old files in the NURDLIB folder with the >> most recent ones and then somewhere type in "make"? And is compilation to be >> executed within the RIO system or on the server? >> >> >> >> >> Best greetings from Jena >> >> G?nter >> >> >> >> >> ____________________________________________________________________________ >> Von: Hans Toshihide T?rnqvist >> Gesendet: Sonntag, 7. Januar 2024 20:33:55 >> An: Weber, Guenter Dr.; Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> Betreff: Re: AW: [subexp-daq] NURDLIB: - how to check which version is >> installed and how to update to the most recent version >> Dear G?nter, >> >> I took a shot at merging the 'mcal_daq' branch that you have been using >> with the 'master' branch, you can find that merge in the branch >> 'mcal_daq_merge'. >> >> That version passes my soft tests, but they are weak compared to a real >> running DAQ :) So please give it a try and let me know how it goes. >> >> Best regards, >> >> Hans >> >> On 2023-12-22 19:32, Weber, Guenter Dr. wrote: >> > Dear Hans, >> > >> > >> > the command >> > >> > >> > > git remote -v >> > >> > >> > resulted in the following output: >> > >> > >> > bloeher bloeher at 140.181.60.97:/u/bloeher/git-bare/nurdlib-jena.git (fetch) >> > bloeher bloeher at 140.181.60.97:/u/bloeher/git-bare/nurdlib-jena.git (push) >> > maxs1 >> > atpnbg011:/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib >> > (fetch) >> > maxs1 >> > atpnbg011:/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib >> (push) >> > origin /u/htoernqv/repos/nurdlib.git/ (fetch) >> > origin /u/htoernqv/repos/nurdlib.git/ (push) >> > >> > I added the new git repository and executed the push command as >> > explained in your e-mail. Looks like everything worked out fine. >> > >> > >> > >> > >> > Best greetings >> > >> > G?nter >> > >> > >> > >> > ------------------------------------------------------------------------ >> > *Von:* Hans Toshihide T?rnqvist >> > *Gesendet:* Freitag, 22. Dezember 2023 18:25:05 >> > *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 2023-12-22 17:55, Weber, Guenter Dr. wrote: >> >> Dear Hakan, >> >> >> >> thank you very much for the reply. >> >> >> >> On my system the output of the command is as follows: >> >> >> >> git describe --all --always --dirty --long >> >> -> heads/mcal_daq-0-gb2bc721 >> >> >> >> How shall I interpret this output? >> > >> > It looks like your repository has the branch 'mcal_daq' active, and part >> > of the checksum is b2bc721. >> > >> > The very good news is that it doesn't say "-dirty" at the end, which >> > means that there are no uncommitted changes, yet :) >> > >> >> I guess I should compare it to something I can find under >> >> https://gitlab.com/chalmers-subexp > > >> > >> >> > >> > It seems like the branch/commit are not in any of the "official" >> > repositories, I had a look. However, I did find 'mcal_daq' branches in >> > some private repositories at GSI by Bastii, but I cannot find the >> > b2bc721 commit. I also cannot find several of the commit messages. >> > >> > The safest way forward would be if you could push your version of >> > nurdlib to gitlab. It looks like you are currently a member of the >> > project, so try: >> > >> > > git remote -v >> > >> > If the gitlab repo is not listed there, do: >> > >> > > git remote add gitlab git at gitlab.com:chalmers-subexp/nurdlib.git >> > >> > Then: >> > >> > > git push gitlab mcal_daq >> > >> > I can then pull that and see how to get that into the main branch. Once >> > that's done, I will ask you to try the new version to make sure it still >> > runs correctly. And of course if there are problems with the above >> > commands, let us know. >> > >> > Best regards, >> > >> > Hans >> > >> >> But there I only can access the following projects: >> >> >> >> - drasi >> >> - egmwsort >> >> - ucesb >> >> >> >> Best greetings >> >> G?nter >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> *Von:* subexp-daq im Auftrag von >> >> H?kan T Johansson >> >> *Gesendet:* Freitag, 22. Dezember 2023 17:48:46 >> >> *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, >> >> >> >> On Fri, 22 Dec 2023, Weber, Guenter Dr. wrote: >> >> >> >>> >> >>> Dear all, >> >>> >> >>> >> >>> I would like to know how ... >> >>> >> >>> >> >>> 1) I can check which version of NURDLIB is installed on my system. >> >> >> >> Please somewhere under the nurdlib/ directory, run: >> >> >> >> git describe --all --always --dirty --long >> >> >> >>> 2) I can update to the most recent 'official' version. >> >> >> >> cd >> >> >> >> git clone git at gitlab.com:chalmers-subexp/nurdlib.git >> >> >> >> Then: >> >> >> >> cd nurdlib >> >> >> >> For that git clone to work, you'll first have to set up ssh keys with >> >> gitlab. That would be useful also in order to upload code. See: >> >> >> >> https://docs.gitlab.com/ee/user/ssh.html > >> > > >> >> > > >> >> >> >> >> and please *do* use a passphrase for the ssh key. >> >> >> >> Cheers, >> >> H?kan >> >> >> >> >> >>> >> >>> >> >>> Thank you very much! >> >>> >> >>> >> >>> >> >>> Best greetings >> >>> >> >>> G?nter >> >>> >> >>> >> >>> >> >>> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.tornqvist at chalmers.se Mon Jan 8 11:46:37 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Mon, 8 Jan 2024 11:46:37 +0100 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <8dd03122-aeb6-4dd3-9005-fb09bc1991a3@chalmers.se> <86a9c0739b034950b6f804472850d5f0@hi-jena.gsi.de> <35eb5fdf-6eea-32e2-fbdb-98ad2edc8d74@chalmers.se> <72c76512ca4c4e2fa4f39569b97a9e57@hi-jena.gsi.de> Message-ID: <123f76b2-bbdf-4188-a926-bd0966901336@chalmers.se> This is on me... Somehow I keep reintroducing this problem (: I will look for a similar running rio4 and build this myself and give you a new version. Cheers, Hans On 2024-01-08 11:44, Weber, Guenter Dr. wrote: > Alright. Sorry for being stupid! > > > With 'make' everything runs smoothly up to this point: > > > ... > > SUITE build_cc_ppc-linux_4.2.2_debug/ntest/tests/fail.suite > SUITE build_cc_ppc-linux_4.2.2_debug/ntest/tests/fixture.suite > SUITE build_cc_ppc-linux_4.2.2_debug/ntest/tests/pass.suite > SUITE build_cc_ppc-linux_4.2.2_debug/ntest/tests/signal.suite > SUITE build_cc_ppc-linux_4.2.2_debug/ntest/tests/string.suite > SUITE build_cc_ppc-linux_4.2.2_debug/ntest/tests/verbose.suite > SUITS build_cc_ppc-linux_4.2.2_debug/ntest/tests/ntest_.suites > NTEST build_cc_ppc-linux_4.2.2_debug/ntest/tests/ntest_.c > CCGEN build_cc_ppc-linux_4.2.2_debug/ntest/tests/ntest_.o > LD??? build_cc_ppc-linux_4.2.2_debug/test_ntest > LD??? build_cc_ppc-linux_4.2.2_debug/test > build_cc_ppc-linux_4.2.2_debug/tools/hwmap_error_internal.o:(.sdata+0x0): undefined reference to `trcom_hwmap_error_internal' > collect2: ld returned 1 exit status > make: *** [build_cc_ppc-linux_4.2.2_debug/test] Error 1 > > > > What should I do? > > > > > Best greetings > > G?nter > > > > ------------------------------------------------------------------------ > *Von:* Hans Toshihide T?rnqvist > *Gesendet:* Montag, 8. Januar 2024 11:38:23 > *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, > > Aha, it looks like H?kan's instructions could be misinterpreted, what > you are seeing is expected behaviour :) > > 'make clean' will clean the build directory, which it does with 'rm -rf > build_...'. > > 'make' without additional arguments builds nurdlib which is what you > want now. > > Cheers, > Hans > > On 2024-01-08 11:29, Weber, Guenter Dr. wrote: >> Dear Hans, >> >> >> I copied the directory of our existing DAQ system: >> >>? > cp -r old_daq new_daq >> >> >> Then deleted the NURDLIB folder, downloaded the new one and switched to >> the mcal_daq_merge branch using >> >>? > git checkout mcal_daq_merge >> >> >> Then I connected to the RIO and tried to compile in the folder of the >> new NURDLIB. This is the result: >> >> RIO4-MCAL-2 mbsdaq > make clean >> Could not figure out RFX1 firmware (8-xdigit number), skipping. >> TRIDI_FW=d374466d >> VULOM4_FW=d96ffc88 >> RFX1_FW= >> rm -rf build_cc_ppc-linux_4.2.2_debug >> >> >> No further message and a new folder build_cc_ppc-linux_4.2.2_debug is >> not created. >> >> >> When checking the Makefile, I noticed that in the old NURDLIB folder >> there is no /gmake, instead there is a file make.mk which probably does >> the same job. >> >> >> Probably there are some adjustment that I need to make, so that the new >> NURDLIB version can compile on our system. But I don't know where to >> look at, unfortunately. >> >> >> Could you give us advice? >> >> >> >> >> >> Best greetings >> >> G?nter >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> *Von:* subexp-daq im Auftrag von >> H?kan T Johansson >> *Gesendet:* Sonntag, 7. Januar 2024 21:48:21 >> *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, >> >> I would very much suggest to do the 'update' in a copy of the directory >> tree that you are using, such that it is very easy to go back.? (Or go >> between the systems.) >> >> For the update, something along the lines: >> >> git fetch origin?? # or instead of 'origin' the shorthand you have for the >>? ??????????????????? # remote repo >> >> git log --all --decorate --graph --oneline --color?? # just to see where >>? ??????????????????????????????????????? # you are, and where you would go >> >> git checkout mcal_daq_merge??? # if that fails, try origin/mcal_daq_merge >> >> >> You would want to run the git commands etc on the PC, but compilations of >> code that runs on the RIO needs to be done on the RIO. >> >> A 'make clean' is probbaly a healthy start. >> >> But first - please make sure to work in copied directory tree. >> >> Cheers, >> H?kan >> >> >> >> On Sun, 7 Jan 2024, Weber, Guenter Dr. wrote: >> >>> >>> Dear Hans, >>> >>> >>> thank you very much and have a happy new year! >>> >>> >>> Could you give me instructions on?how to update NURDLIB in an already >>> existing DAQ system? >>> >>> >>> Would it be enough to replace the old files in the?NURDLIB folder with the >>> most recent ones and then somewhere?type in "make"? And is compilation to be >>> executed?within?the RIO system or on the server? >>> >>> >>> >>> >>> Best greetings from Jena >>> >>> G?nter >>> >>> >>> >>> >>> ____________________________________________________________________________ >>> Von: Hans Toshihide T?rnqvist >>> Gesendet: Sonntag, 7. Januar 2024 20:33:55 >>> An: Weber, Guenter Dr.; Discuss use of Nurdlib, TRLO II, drasi and UCESB. >>> Betreff: Re: AW: [subexp-daq] NURDLIB: - how to check which version is >>> installed and how to update to the most recent version >>> Dear G?nter, >>> >>> I took a shot at merging the 'mcal_daq' branch that you have been using >>> with the 'master' branch, you can find that merge in the branch >>> 'mcal_daq_merge'. >>> >>> That version passes my soft tests, but they are weak compared to a real >>> running DAQ :) So please give it a try and let me know how it goes. >>> >>> Best regards, >>> >>> Hans >>> >>> On 2023-12-22 19:32, Weber, Guenter Dr. wrote: >>> > Dear Hans, >>> > >>> > >>> > the command >>> > >>> > >>> >? ?> git remote -v >>> > >>> > >>> > resulted in the following output: >>> > >>> > >>> > bloeher bloeher at 140.181.60.97:/u/bloeher/git-bare/nurdlib-jena.git (fetch) >>> > bloeher bloeher at 140.181.60.97:/u/bloeher/git-bare/nurdlib-jena.git (push) >>> > maxs1 >>> >? ?atpnbg011:/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib >>> > (fetch) >>> > maxs1 >>> >? ?atpnbg011:/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib >>> (push) >>> > origin? /u/htoernqv/repos/nurdlib.git/ (fetch) >>> > origin? /u/htoernqv/repos/nurdlib.git/ (push) >>> > >>> > I added the new git repository and executed the push?command as >>> > explained in your e-mail. Looks like everything worked out fine. >>> > >>> > >>> > >>> > >>> > Best greetings >>> > >>> > G?nter >>> > >>> > >>> > >>> > ------------------------------------------------------------------------ >>> > *Von:* Hans Toshihide T?rnqvist >>> > *Gesendet:* Freitag, 22. Dezember 2023 18:25:05 >>> > *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 2023-12-22 17:55, Weber, Guenter Dr. wrote: >>> >> Dear Hakan, >>> >> >>> >> thank you very much for the reply. >>> >> >>> >> On my system the output of the command is as follows: >>> >> >>> >> git describe --all --always --dirty --long >>> >> ->?heads/mcal_daq-0-gb2bc721 >>> >> >>> >> How shall I interpret this output? >>> > >>> > It looks like your repository has the branch 'mcal_daq' active, and part >>> > of the checksum is b2bc721. >>> > >>> > The very good news is that it doesn't say "-dirty" at the end, which >>> > means that there are no uncommitted changes, yet :) >>> > >>> >> I guess I should compare it to something I can find under >>> >> https://gitlab.com/chalmers-subexp > > >> >> >>> > > >>> >>> > >>> > It seems like the branch/commit are not in any of the "official" >>> > repositories, I had a look. However, I did find 'mcal_daq' branches in >>> > some private repositories at GSI by Bastii, but I cannot find the >>> > b2bc721 commit. I also cannot find several of the commit messages. >>> > >>> > The safest way forward would be if you could push your version of >>> > nurdlib to gitlab. It looks like you are currently a member of the >>> > project, so try: >>> > >>> >? ?> git remote -v >>> > >>> > If the gitlab repo is not listed there, do: >>> > >>> >? ?> git remote add gitlab git at gitlab.com:chalmers-subexp/nurdlib.git >>> > >>> > Then: >>> > >>> >? ?> git push gitlab mcal_daq >>> > >>> > I can then pull that and see how to get that into the main branch. Once >>> > that's done, I will ask you to try the new version to make sure it still >>> > runs correctly. And of course if there are problems with the above >>> > commands, let us know. >>> > >>> > Best regards, >>> > >>> > Hans >>> > >>> >> But there I only can access the following projects: >>> >> >>> >> -?drasi >>> >> -?egmwsort >>> >> -?ucesb >>> >> >>> >> Best greetings >>> >> G?nter >>> >> >>> >> >>> >> ------------------------------------------------------------------------ >>> >> *Von:* subexp-daq im Auftrag von >>> >> H?kan T Johansson >>> >> *Gesendet:* Freitag, 22. Dezember 2023 17:48:46 >>> >> *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, >>> >> >>> >> On Fri, 22 Dec 2023, Weber, Guenter Dr. wrote: >>> >> >>> >>> >>> >>> Dear all, >>> >>> >>> >>> >>> >>> I would like to know how ... >>> >>> >>> >>> >>> >>> 1) I can check which version of NURDLIB is installed on my system. >>> >> >>> >> Please somewhere under the nurdlib/ directory, run: >>> >> >>> >> git describe --all --always --dirty --long >>> >> >>> >>> 2) I can update to the most recent 'official' version. >>> >> >>> >> cd >>> >> >>> >> git clone git at gitlab.com:chalmers-subexp/nurdlib.git >>> >> >>> >> Then: >>> >> >>> >> cd nurdlib >>> >> >>> >> For that git clone to work, you'll first have to set up ssh keys with >>> >> gitlab.? That would be useful also in order to upload code.? See: >>> >> >>> >> https://docs.gitlab.com/ee/user/ssh.html > >> > >>> > > >> >>> >> >> > > >>> >>> >> >>> >> and please *do* use a passphrase for the ssh key. >>> >> >>> >> Cheers, >>> >> H?kan >>> >> >>> >> >>> >>> >>> >>> >>> >>> Thank you very much! >>> >>> >>> >>> >>> >>> >>> >>> Best greetings >>> >>> >>> >>> G?nter >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >>> >>> >> From hans.tornqvist at chalmers.se Mon Jan 8 14:19:41 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Mon, 8 Jan 2024 14:19:41 +0100 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: <123f76b2-bbdf-4188-a926-bd0966901336@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <8dd03122-aeb6-4dd3-9005-fb09bc1991a3@chalmers.se> <86a9c0739b034950b6f804472850d5f0@hi-jena.gsi.de> <35eb5fdf-6eea-32e2-fbdb-98ad2edc8d74@chalmers.se> <72c76512ca4c4e2fa4f39569b97a9e57@hi-jena.gsi.de> <123f76b2-bbdf-4188-a926-bd0966901336@chalmers.se> Message-ID: <2ea9c4c3-29ab-4569-aba1-30633b63608f@chalmers.se> I have pushed a new version to Gitlab that builds on a rio4 with the same mapping and trlo ii support. *Crossing fingers* Cheers, Hans On 2024-01-08 11:46, Hans Toshihide T?rnqvist wrote: > This is on me... Somehow I keep reintroducing this problem (: I will > look for a similar running rio4 and build this myself and give you a new > version. > > Cheers, > > Hans > > On 2024-01-08 11:44, Weber, Guenter Dr. wrote: >> Alright. Sorry for being stupid! >> >> >> With 'make' everything runs smoothly up to this point: >> >> >> ... >> >> SUITE build_cc_ppc-linux_4.2.2_debug/ntest/tests/fail.suite >> SUITE build_cc_ppc-linux_4.2.2_debug/ntest/tests/fixture.suite >> SUITE build_cc_ppc-linux_4.2.2_debug/ntest/tests/pass.suite >> SUITE build_cc_ppc-linux_4.2.2_debug/ntest/tests/signal.suite >> SUITE build_cc_ppc-linux_4.2.2_debug/ntest/tests/string.suite >> SUITE build_cc_ppc-linux_4.2.2_debug/ntest/tests/verbose.suite >> SUITS build_cc_ppc-linux_4.2.2_debug/ntest/tests/ntest_.suites >> NTEST build_cc_ppc-linux_4.2.2_debug/ntest/tests/ntest_.c >> CCGEN build_cc_ppc-linux_4.2.2_debug/ntest/tests/ntest_.o >> LD??? build_cc_ppc-linux_4.2.2_debug/test_ntest >> LD??? build_cc_ppc-linux_4.2.2_debug/test >> build_cc_ppc-linux_4.2.2_debug/tools/hwmap_error_internal.o:(.sdata+0x0): undefined reference to `trcom_hwmap_error_internal' >> collect2: ld returned 1 exit status >> make: *** [build_cc_ppc-linux_4.2.2_debug/test] Error 1 >> >> >> >> What should I do? >> >> >> >> >> Best greetings >> >> G?nter >> >> >> >> ------------------------------------------------------------------------ >> *Von:* Hans Toshihide T?rnqvist >> *Gesendet:* Montag, 8. Januar 2024 11:38:23 >> *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, >> >> Aha, it looks like H?kan's instructions could be misinterpreted, what >> you are seeing is expected behaviour :) >> >> 'make clean' will clean the build directory, which it does with 'rm -rf >> build_...'. >> >> 'make' without additional arguments builds nurdlib which is what you >> want now. >> >> Cheers, >> Hans >> >> On 2024-01-08 11:29, Weber, Guenter Dr. wrote: >>> Dear Hans, >>> >>> >>> I copied the directory of our existing DAQ system: >>> >>> ? > cp -r old_daq new_daq >>> >>> >>> Then deleted the NURDLIB folder, downloaded the new one and switched >>> to the mcal_daq_merge branch using >>> >>> ? > git checkout mcal_daq_merge >>> >>> >>> Then I connected to the RIO and tried to compile in the folder of the >>> new NURDLIB. This is the result: >>> >>> RIO4-MCAL-2 mbsdaq > make clean >>> Could not figure out RFX1 firmware (8-xdigit number), skipping. >>> TRIDI_FW=d374466d >>> VULOM4_FW=d96ffc88 >>> RFX1_FW= >>> rm -rf build_cc_ppc-linux_4.2.2_debug >>> >>> >>> No further message and a new folder build_cc_ppc-linux_4.2.2_debug is >>> not created. >>> >>> >>> When checking the Makefile, I noticed that in the old NURDLIB folder >>> there is no /gmake, instead there is a file make.mk which probably >>> does the same job. >>> >>> >>> Probably there are some adjustment that I need to make, so that the >>> new NURDLIB version can compile on our system. But I don't know where >>> to look at, unfortunately. >>> >>> >>> Could you give us advice? >>> >>> >>> >>> >>> >>> Best greetings >>> >>> G?nter >>> >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> *Von:* subexp-daq im Auftrag >>> von H?kan T Johansson >>> *Gesendet:* Sonntag, 7. Januar 2024 21:48:21 >>> *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, >>> >>> I would very much suggest to do the 'update' in a copy of the directory >>> tree that you are using, such that it is very easy to go back.? (Or go >>> between the systems.) >>> >>> For the update, something along the lines: >>> >>> git fetch origin?? # or instead of 'origin' the shorthand you have >>> for the >>> ? ??????????????????? # remote repo >>> >>> git log --all --decorate --graph --oneline --color?? # just to see where >>> ? ??????????????????????????????????????? # you are, and where you >>> would go >>> >>> git checkout mcal_daq_merge??? # if that fails, try >>> origin/mcal_daq_merge >>> >>> >>> You would want to run the git commands etc on the PC, but >>> compilations of >>> code that runs on the RIO needs to be done on the RIO. >>> >>> A 'make clean' is probbaly a healthy start. >>> >>> But first - please make sure to work in copied directory tree. >>> >>> Cheers, >>> H?kan >>> >>> >>> >>> On Sun, 7 Jan 2024, Weber, Guenter Dr. wrote: >>> >>>> >>>> Dear Hans, >>>> >>>> >>>> thank you very much and have a happy new year! >>>> >>>> >>>> Could you give me instructions on?how to update NURDLIB in an already >>>> existing DAQ system? >>>> >>>> >>>> Would it be enough to replace the old files in the?NURDLIB folder >>>> with the >>>> most recent ones and then somewhere?type in "make"? And is >>>> compilation to be >>>> executed?within?the RIO system or on the server? >>>> >>>> >>>> >>>> >>>> Best greetings from Jena >>>> >>>> G?nter >>>> >>>> >>>> >>>> >>>> ____________________________________________________________________________ >>>> Von: Hans Toshihide T?rnqvist >>>> Gesendet: Sonntag, 7. Januar 2024 20:33:55 >>>> An: Weber, Guenter Dr.; Discuss use of Nurdlib, TRLO II, drasi and >>>> UCESB. >>>> Betreff: Re: AW: [subexp-daq] NURDLIB: - how to check which version is >>>> installed and how to update to the most recent version Dear G?nter, >>>> >>>> I took a shot at merging the 'mcal_daq' branch that you have been using >>>> with the 'master' branch, you can find that merge in the branch >>>> 'mcal_daq_merge'. >>>> >>>> That version passes my soft tests, but they are weak compared to a real >>>> running DAQ :) So please give it a try and let me know how it goes. >>>> >>>> Best regards, >>>> >>>> Hans >>>> >>>> On 2023-12-22 19:32, Weber, Guenter Dr. wrote: >>>> > Dear Hans, >>>> > >>>> > >>>> > the command >>>> > >>>> > >>>> >? ?> git remote -v >>>> > >>>> > >>>> > resulted in the following output: >>>> > >>>> > >>>> > bloeher bloeher at 140.181.60.97:/u/bloeher/git-bare/nurdlib-jena.git >>>> (fetch) >>>> > bloeher bloeher at 140.181.60.97:/u/bloeher/git-bare/nurdlib-jena.git >>>> (push) >>>> > maxs1 > >>>> ?atpnbg011:/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib >>>> > (fetch) >>>> > maxs1 > >>>> ?atpnbg011:/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib >>>> (push) >>>> > origin? /u/htoernqv/repos/nurdlib.git/ (fetch) >>>> > origin? /u/htoernqv/repos/nurdlib.git/ (push) >>>> > >>>> > I added the new git repository and executed the push?command as >>>> > explained in your e-mail. Looks like everything worked out fine. >>>> > >>>> > >>>> > >>>> > >>>> > Best greetings >>>> > >>>> > G?nter >>>> > >>>> > >>>> > >>>> > >>>> ------------------------------------------------------------------------ >>>> > *Von:* Hans Toshihide T?rnqvist >>>> > *Gesendet:* Freitag, 22. Dezember 2023 18:25:05 >>>> > *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 2023-12-22 17:55, Weber, Guenter Dr. wrote: >>>> >> Dear Hakan, >>>> >> >>>> >> thank you very much for the reply. >>>> >> >>>> >> On my system the output of the command is as follows: >>>> >> >>>> >> git describe --all --always --dirty --long >>>> >> ->?heads/mcal_daq-0-gb2bc721 >>>> >> >>>> >> How shall I interpret this output? >>>> > >>>> > It looks like your repository has the branch 'mcal_daq' active, >>>> and part >>>> > of the checksum is b2bc721. >>>> > >>>> > The very good news is that it doesn't say "-dirty" at the end, which >>>> > means that there are no uncommitted changes, yet :) >>>> > >>>> >> I guess I should compare it to something I can find under >>>> >> https://gitlab.com/chalmers-subexp >>>> >> > >>> > >> >>>> > >>> >> >> >>> >>>> > >>>> > It seems like the branch/commit are not in any of the "official" >>>> > repositories, I had a look. However, I did find 'mcal_daq' >>>> branches in >>>> > some private repositories at GSI by Bastii, but I cannot find the >>>> > b2bc721 commit. I also cannot find several of the commit messages. >>>> > >>>> > The safest way forward would be if you could push your version of >>>> > nurdlib to gitlab. It looks like you are currently a member of the >>>> > project, so try: >>>> > >>>> >? ?> git remote -v >>>> > >>>> > If the gitlab repo is not listed there, do: >>>> > >>>> >? ?> git remote add gitlab git at gitlab.com:chalmers-subexp/nurdlib.git >>>> > >>>> > Then: >>>> > >>>> >? ?> git push gitlab mcal_daq >>>> > >>>> > I can then pull that and see how to get that into the main branch. >>>> Once >>>> > that's done, I will ask you to try the new version to make sure it >>>> still >>>> > runs correctly. And of course if there are problems with the above >>>> > commands, let us know. >>>> > >>>> > Best regards, >>>> > >>>> > Hans >>>> > >>>> >> But there I only can access the following projects: >>>> >> >>>> >> -?drasi >>>> >> -?egmwsort >>>> >> -?ucesb >>>> >> >>>> >> Best greetings >>>> >> G?nter >>>> >> >>>> >> >>>> >> >>>> ------------------------------------------------------------------------ >>>> >> *Von:* subexp-daq im >>>> Auftrag von >>>> >> H?kan T Johansson >>>> >> *Gesendet:* Freitag, 22. Dezember 2023 17:48:46 >>>> >> *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, >>>> >> >>>> >> On Fri, 22 Dec 2023, Weber, Guenter Dr. wrote: >>>> >> >>>> >>> >>>> >>> Dear all, >>>> >>> >>>> >>> >>>> >>> I would like to know how ... >>>> >>> >>>> >>> >>>> >>> 1) I can check which version of NURDLIB is installed on my system. >>>> >> >>>> >> Please somewhere under the nurdlib/ directory, run: >>>> >> >>>> >> git describe --all --always --dirty --long >>>> >> >>>> >>> 2) I can update to the most recent 'official' version. >>>> >> >>>> >> cd >>>> >> >>>> >> git clone git at gitlab.com:chalmers-subexp/nurdlib.git >>>> >> >>>> >> Then: >>>> >> >>>> >> cd nurdlib >>>> >> >>>> >> For that git clone to work, you'll first have to set up ssh keys >>>> with >>>> >> gitlab.? That would be useful also in order to upload code.? See: >>>> >> >>>> >> https://docs.gitlab.com/ee/user/ssh.html >> >>> > > >>>> > >> > >> >>>> >> >>> > >> > >>> >>>> >> >>>> >> and please *do* use a passphrase for the ssh key. >>>> >> >>>> >> Cheers, >>>> >> H?kan >>>> >> >>>> >> >>>> >>> >>>> >>> >>>> >>> Thank you very much! >>>> >>> >>>> >>> >>>> >>> >>>> >>> Best greetings >>>> >>> >>>> >>> G?nter >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >> >>>> >>>> >>> From g.weber at hi-jena.gsi.de Mon Jan 8 15:01:50 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Mon, 8 Jan 2024 14:01:50 +0000 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: <2ea9c4c3-29ab-4569-aba1-30633b63608f@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <8dd03122-aeb6-4dd3-9005-fb09bc1991a3@chalmers.se> <86a9c0739b034950b6f804472850d5f0@hi-jena.gsi.de> <35eb5fdf-6eea-32e2-fbdb-98ad2edc8d74@chalmers.se> <72c76512ca4c4e2fa4f39569b97a9e57@hi-jena.gsi.de> <123f76b2-bbdf-4188-a926-bd0966901336@chalmers.se>, <2ea9c4c3-29ab-4569-aba1-30633b63608f@chalmers.se> Message-ID: Dear Hans, thank you very much! It now dies at a later stage of the compilation process. ... [tests/caen_v792.c:73: IPEDConversion] [tests/caen_v820.c:32: DefaultConfig] 2024-02-08,16:59:58:INFO: Will try default cfg path='/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default', can be set with NURDLIB_DEF_PATH. [config/config.c:181] 2024-02-08,16:59:58:INFO: Opened './tests/caen_v820_empty.cfg' { [config/parser.c:287] 2024-02-08,16:59:58:INFO: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/caen_v820.cfg' { [config/parser.c:287] 2024-02-08,16:59:58:INFO: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/caen_v820.cfg' } [config/parser.c:299] 2024-02-08,16:59:58:INFO: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { [config/parser.c:287] 2024-02-08,16:59:58:INFO: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } [config/parser.c:299] 2024-02-08,16:59:58:INFO: Closed './tests/caen_v820_empty.cfg' } [config/parser.c:299] 2024-02-08,16:59:58:ERRR: Could not find keyword config 'paux'. [config/config.c:711] 2024-02-08,16:59:58:ERRR: Calling abort()... [config/config.c:711] make: *** [build_cc_ppc-linux_4.2.2_debug/test_ok] Error 1 The problem is that the environment variable NURDLIB_DEF_PATH is still set to the old directory ('2023_mcalstruck' instead of '2024_mcalstruck', which I created today). Of course, I can change this now. But is there a list of all the environment variables that need to be updated? Or is NURDLIB_DEF_PATH the only one? Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von Hans Toshihide T?rnqvist Gesendet: Montag, 8. Januar 2024 14:19:41 An: Weber, Guenter Dr.; 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 I have pushed a new version to Gitlab that builds on a rio4 with the same mapping and trlo ii support. *Crossing fingers* Cheers, Hans On 2024-01-08 11:46, Hans Toshihide T?rnqvist wrote: > This is on me... Somehow I keep reintroducing this problem (: I will > look for a similar running rio4 and build this myself and give you a new > version. > > Cheers, > > Hans > > On 2024-01-08 11:44, Weber, Guenter Dr. wrote: >> Alright. Sorry for being stupid! >> >> >> With 'make' everything runs smoothly up to this point: >> >> >> ... >> >> SUITE build_cc_ppc-linux_4.2.2_debug/ntest/tests/fail.suite >> SUITE build_cc_ppc-linux_4.2.2_debug/ntest/tests/fixture.suite >> SUITE build_cc_ppc-linux_4.2.2_debug/ntest/tests/pass.suite >> SUITE build_cc_ppc-linux_4.2.2_debug/ntest/tests/signal.suite >> SUITE build_cc_ppc-linux_4.2.2_debug/ntest/tests/string.suite >> SUITE build_cc_ppc-linux_4.2.2_debug/ntest/tests/verbose.suite >> SUITS build_cc_ppc-linux_4.2.2_debug/ntest/tests/ntest_.suites >> NTEST build_cc_ppc-linux_4.2.2_debug/ntest/tests/ntest_.c >> CCGEN build_cc_ppc-linux_4.2.2_debug/ntest/tests/ntest_.o >> LD build_cc_ppc-linux_4.2.2_debug/test_ntest >> LD build_cc_ppc-linux_4.2.2_debug/test >> build_cc_ppc-linux_4.2.2_debug/tools/hwmap_error_internal.o:(.sdata+0x0): undefined reference to `trcom_hwmap_error_internal' >> collect2: ld returned 1 exit status >> make: *** [build_cc_ppc-linux_4.2.2_debug/test] Error 1 >> >> >> >> What should I do? >> >> >> >> >> Best greetings >> >> G?nter >> >> >> >> ------------------------------------------------------------------------ >> *Von:* Hans Toshihide T?rnqvist >> *Gesendet:* Montag, 8. Januar 2024 11:38:23 >> *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, >> >> Aha, it looks like H?kan's instructions could be misinterpreted, what >> you are seeing is expected behaviour :) >> >> 'make clean' will clean the build directory, which it does with 'rm -rf >> build_...'. >> >> 'make' without additional arguments builds nurdlib which is what you >> want now. >> >> Cheers, >> Hans >> >> On 2024-01-08 11:29, Weber, Guenter Dr. wrote: >>> Dear Hans, >>> >>> >>> I copied the directory of our existing DAQ system: >>> >>> > cp -r old_daq new_daq >>> >>> >>> Then deleted the NURDLIB folder, downloaded the new one and switched >>> to the mcal_daq_merge branch using >>> >>> > git checkout mcal_daq_merge >>> >>> >>> Then I connected to the RIO and tried to compile in the folder of the >>> new NURDLIB. This is the result: >>> >>> RIO4-MCAL-2 mbsdaq > make clean >>> Could not figure out RFX1 firmware (8-xdigit number), skipping. >>> TRIDI_FW=d374466d >>> VULOM4_FW=d96ffc88 >>> RFX1_FW= >>> rm -rf build_cc_ppc-linux_4.2.2_debug >>> >>> >>> No further message and a new folder build_cc_ppc-linux_4.2.2_debug is >>> not created. >>> >>> >>> When checking the Makefile, I noticed that in the old NURDLIB folder >>> there is no /gmake, instead there is a file make.mk which probably >>> does the same job. >>> >>> >>> Probably there are some adjustment that I need to make, so that the >>> new NURDLIB version can compile on our system. But I don't know where >>> to look at, unfortunately. >>> >>> >>> Could you give us advice? >>> >>> >>> >>> >>> >>> Best greetings >>> >>> G?nter >>> >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> *Von:* subexp-daq im Auftrag >>> von H?kan T Johansson >>> *Gesendet:* Sonntag, 7. Januar 2024 21:48:21 >>> *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, >>> >>> I would very much suggest to do the 'update' in a copy of the directory >>> tree that you are using, such that it is very easy to go back. (Or go >>> between the systems.) >>> >>> For the update, something along the lines: >>> >>> git fetch origin # or instead of 'origin' the shorthand you have >>> for the >>> # remote repo >>> >>> git log --all --decorate --graph --oneline --color # just to see where >>> # you are, and where you >>> would go >>> >>> git checkout mcal_daq_merge # if that fails, try >>> origin/mcal_daq_merge >>> >>> >>> You would want to run the git commands etc on the PC, but >>> compilations of >>> code that runs on the RIO needs to be done on the RIO. >>> >>> A 'make clean' is probbaly a healthy start. >>> >>> But first - please make sure to work in copied directory tree. >>> >>> Cheers, >>> H?kan >>> >>> >>> >>> On Sun, 7 Jan 2024, Weber, Guenter Dr. wrote: >>> >>>> >>>> Dear Hans, >>>> >>>> >>>> thank you very much and have a happy new year! >>>> >>>> >>>> Could you give me instructions on how to update NURDLIB in an already >>>> existing DAQ system? >>>> >>>> >>>> Would it be enough to replace the old files in the NURDLIB folder >>>> with the >>>> most recent ones and then somewhere type in "make"? And is >>>> compilation to be >>>> executed within the RIO system or on the server? >>>> >>>> >>>> >>>> >>>> Best greetings from Jena >>>> >>>> G?nter >>>> >>>> >>>> >>>> >>>> ____________________________________________________________________________ >>>> Von: Hans Toshihide T?rnqvist >>>> Gesendet: Sonntag, 7. Januar 2024 20:33:55 >>>> An: Weber, Guenter Dr.; Discuss use of Nurdlib, TRLO II, drasi and >>>> UCESB. >>>> Betreff: Re: AW: [subexp-daq] NURDLIB: - how to check which version is >>>> installed and how to update to the most recent version Dear G?nter, >>>> >>>> I took a shot at merging the 'mcal_daq' branch that you have been using >>>> with the 'master' branch, you can find that merge in the branch >>>> 'mcal_daq_merge'. >>>> >>>> That version passes my soft tests, but they are weak compared to a real >>>> running DAQ :) So please give it a try and let me know how it goes. >>>> >>>> Best regards, >>>> >>>> Hans >>>> >>>> On 2023-12-22 19:32, Weber, Guenter Dr. wrote: >>>> > Dear Hans, >>>> > >>>> > >>>> > the command >>>> > >>>> > >>>> > > git remote -v >>>> > >>>> > >>>> > resulted in the following output: >>>> > >>>> > >>>> > bloeher bloeher at 140.181.60.97:/u/bloeher/git-bare/nurdlib-jena.git >>>> (fetch) >>>> > bloeher bloeher at 140.181.60.97:/u/bloeher/git-bare/nurdlib-jena.git >>>> (push) >>>> > maxs1 > >>>> atpnbg011:/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib >>>> > (fetch) >>>> > maxs1 > >>>> atpnbg011:/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib >>>> (push) >>>> > origin /u/htoernqv/repos/nurdlib.git/ (fetch) >>>> > origin /u/htoernqv/repos/nurdlib.git/ (push) >>>> > >>>> > I added the new git repository and executed the push command as >>>> > explained in your e-mail. Looks like everything worked out fine. >>>> > >>>> > >>>> > >>>> > >>>> > Best greetings >>>> > >>>> > G?nter >>>> > >>>> > >>>> > >>>> > >>>> ------------------------------------------------------------------------ >>>> > *Von:* Hans Toshihide T?rnqvist >>>> > *Gesendet:* Freitag, 22. Dezember 2023 18:25:05 >>>> > *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 2023-12-22 17:55, Weber, Guenter Dr. wrote: >>>> >> Dear Hakan, >>>> >> >>>> >> thank you very much for the reply. >>>> >> >>>> >> On my system the output of the command is as follows: >>>> >> >>>> >> git describe --all --always --dirty --long >>>> >> -> heads/mcal_daq-0-gb2bc721 >>>> >> >>>> >> How shall I interpret this output? >>>> > >>>> > It looks like your repository has the branch 'mcal_daq' active, >>>> and part >>>> > of the checksum is b2bc721. >>>> > >>>> > The very good news is that it doesn't say "-dirty" at the end, which >>>> > means that there are no uncommitted changes, yet :) >>>> > >>>> >> I guess I should compare it to something I can find under >>>> >> https://gitlab.com/chalmers-subexp >>>> >> > >>> > >> >>>> > >>> >> >> >>> >>>> > >>>> > It seems like the branch/commit are not in any of the "official" >>>> > repositories, I had a look. However, I did find 'mcal_daq' >>>> branches in >>>> > some private repositories at GSI by Bastii, but I cannot find the >>>> > b2bc721 commit. I also cannot find several of the commit messages. >>>> > >>>> > The safest way forward would be if you could push your version of >>>> > nurdlib to gitlab. It looks like you are currently a member of the >>>> > project, so try: >>>> > >>>> > > git remote -v >>>> > >>>> > If the gitlab repo is not listed there, do: >>>> > >>>> > > git remote add gitlab git at gitlab.com:chalmers-subexp/nurdlib.git >>>> > >>>> > Then: >>>> > >>>> > > git push gitlab mcal_daq >>>> > >>>> > I can then pull that and see how to get that into the main branch. >>>> Once >>>> > that's done, I will ask you to try the new version to make sure it >>>> still >>>> > runs correctly. And of course if there are problems with the above >>>> > commands, let us know. >>>> > >>>> > Best regards, >>>> > >>>> > Hans >>>> > >>>> >> But there I only can access the following projects: >>>> >> >>>> >> - drasi >>>> >> - egmwsort >>>> >> - ucesb >>>> >> >>>> >> Best greetings >>>> >> G?nter >>>> >> >>>> >> >>>> >> >>>> ------------------------------------------------------------------------ >>>> >> *Von:* subexp-daq im >>>> Auftrag von >>>> >> H?kan T Johansson >>>> >> *Gesendet:* Freitag, 22. Dezember 2023 17:48:46 >>>> >> *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, >>>> >> >>>> >> On Fri, 22 Dec 2023, Weber, Guenter Dr. wrote: >>>> >> >>>> >>> >>>> >>> Dear all, >>>> >>> >>>> >>> >>>> >>> I would like to know how ... >>>> >>> >>>> >>> >>>> >>> 1) I can check which version of NURDLIB is installed on my system. >>>> >> >>>> >> Please somewhere under the nurdlib/ directory, run: >>>> >> >>>> >> git describe --all --always --dirty --long >>>> >> >>>> >>> 2) I can update to the most recent 'official' version. >>>> >> >>>> >> cd >>>> >> >>>> >> git clone git at gitlab.com:chalmers-subexp/nurdlib.git >>>> >> >>>> >> Then: >>>> >> >>>> >> cd nurdlib >>>> >> >>>> >> For that git clone to work, you'll first have to set up ssh keys >>>> with >>>> >> gitlab. That would be useful also in order to upload code. See: >>>> >> >>>> >> https://docs.gitlab.com/ee/user/ssh.html >> >>> > > >>>> > >> > >> >>>> >> >>> > >> > >>> >>>> >> >>>> >> and please *do* use a passphrase for the ssh key. >>>> >> >>>> >> Cheers, >>>> >> H?kan >>>> >> >>>> >> >>>> >>> >>>> >>> >>>> >>> Thank you very much! >>>> >>> >>>> >>> >>>> >>> >>>> >>> Best greetings >>>> >>> >>>> >>> G?nter >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >> >>>> >>>> >>> -- 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: From f96hajo at chalmers.se Mon Jan 8 15:57:15 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Mon, 8 Jan 2024 15:57:15 +0100 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <8dd03122-aeb6-4dd3-9005-fb09bc1991a3@chalmers.se> <86a9c0739b034950b6f804472850d5f0@hi-jena.gsi.de> <35eb5fdf-6eea-32e2-fbdb-98ad2edc8d74@chalmers.se> <72c76512ca4c4e2fa4f39569b97a9e57@hi-jena.gsi.de> <123f76b2-bbdf-4188-a926-bd0966901336@chalmers.se>, <2ea9c4c3-29ab-4569-aba1-30633b63608f@chalmers.se> Message-ID: Dear G?nter, not a definate answer, but looking around for getend in the sources, I did not find further suspicious environment variables. You could try end | grep 2023_mcalstruck or with some other significant part of the path to see if there are any other. Cheers, H?kan On Mon, 8 Jan 2024, Weber, Guenter Dr. wrote: > > Dear Hans, > > > thank you very much! > > > It now dies at a later stage of the compilation process. > > > ... > > [tests/caen_v792.c:73: IPEDConversion] > [tests/caen_v820.c:32: DefaultConfig] > 2024-02-08,16:59:58:INFO: Will try default cfgpath='/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default > ', can be set with NURDLIB_DEF_PATH. [config/config.c:181] > 2024-02-08,16:59:58:INFO: Opened './tests/caen_v820_empty.cfg' { > [config/parser.c:287] > 2024-02-08,16:59:58:INFO: .Opened'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/caen > _v820.cfg' { [config/parser.c:287] > 2024-02-08,16:59:58:INFO: .Closed'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/caen > _v820.cfg' } [config/parser.c:299] > 2024-02-08,16:59:58:INFO: .Opened'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/modu > le_log_level.cfg' { [config/parser.c:287] > 2024-02-08,16:59:58:INFO: .Closed'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/modu > le_log_level.cfg' } [config/parser.c:299] > 2024-02-08,16:59:58:INFO: Closed './tests/caen_v820_empty.cfg' } > [config/parser.c:299] > 2024-02-08,16:59:58:ERRR: Could not find keyword config 'paux'. > [config/config.c:711] > 2024-02-08,16:59:58:ERRR: Calling abort()... [config/config.c:711] > make: *** [build_cc_ppc-linux_4.2.2_debug/test_ok] Error 1 > > The problem is that the environment variable NURDLIB_DEF_PATH is still set > to the old directory ('2023_mcalstruck' instead of '2024_mcalstruck', which > I created today). Of course, I can change this now. But is there a list of > all the environment variables that need to be updated? Or > is?NURDLIB_DEF_PATH the only one? > > > > Best greetings > > G?nter From hans.tornqvist at chalmers.se Mon Jan 8 16:20:24 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Mon, 8 Jan 2024 16:20:24 +0100 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <8dd03122-aeb6-4dd3-9005-fb09bc1991a3@chalmers.se> <86a9c0739b034950b6f804472850d5f0@hi-jena.gsi.de> <35eb5fdf-6eea-32e2-fbdb-98ad2edc8d74@chalmers.se> <72c76512ca4c4e2fa4f39569b97a9e57@hi-jena.gsi.de> <123f76b2-bbdf-4188-a926-bd0966901336@chalmers.se> <2ea9c4c3-29ab-4569-aba1-30633b63608f@chalmers.se> Message-ID: <2cb1927f-8c64-43f2-a0cb-bf501a5808b3@chalmers.se> Dear G?nter, I was on a late lunch break. That should be the only env-var. I'm adding the explanation to my docu-todo. Cheers, Hans On 2024-01-08 15:57, H?kan T Johansson wrote: > > Dear G?nter, > > not a definate answer, but looking around for getend in the sources, I > did not find further suspicious environment variables. > > You could try > > end | grep 2023_mcalstruck > > or with some other significant part of the path to see if there are any > other. > > Cheers, > H?kan > > > On Mon, 8 Jan 2024, Weber, Guenter Dr. wrote: > >> >> Dear Hans, >> >> >> thank you very much! >> >> >> It now dies at a later stage of the compilation process. >> >> >> ... >> >> [tests/caen_v792.c:73: IPEDConversion] >> [tests/caen_v820.c:32: DefaultConfig] >> 2024-02-08,16:59:58:INFO: Will try default >> cfgpath='/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default >> ', can be set with NURDLIB_DEF_PATH. [config/config.c:181] >> 2024-02-08,16:59:58:INFO: Opened './tests/caen_v820_empty.cfg' { >> [config/parser.c:287] >> 2024-02-08,16:59:58:INFO: >> .Opened'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/caen >> _v820.cfg' { [config/parser.c:287] >> 2024-02-08,16:59:58:INFO: >> .Closed'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/caen >> _v820.cfg' } [config/parser.c:299] >> 2024-02-08,16:59:58:INFO: >> .Opened'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/modu >> le_log_level.cfg' { [config/parser.c:287] >> 2024-02-08,16:59:58:INFO: >> .Closed'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/modu >> le_log_level.cfg' } [config/parser.c:299] >> 2024-02-08,16:59:58:INFO: Closed './tests/caen_v820_empty.cfg' } >> [config/parser.c:299] >> 2024-02-08,16:59:58:ERRR: Could not find keyword config 'paux'. >> [config/config.c:711] >> 2024-02-08,16:59:58:ERRR: Calling abort()... [config/config.c:711] >> make: *** [build_cc_ppc-linux_4.2.2_debug/test_ok] Error 1 >> >> The problem is that the environment variable NURDLIB_DEF_PATH is still >> set >> to the old directory ('2023_mcalstruck' instead of '2024_mcalstruck', >> which >> I created today). Of course, I can change this now. But is there a >> list of >> all the environment variables that need to be updated? Or >> is?NURDLIB_DEF_PATH the only one? >> >> >> >> Best greetings >> >> G?nter > From g.weber at hi-jena.gsi.de Tue Jan 9 11:18:49 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 9 Jan 2024 10:18:49 +0000 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: <2cb1927f-8c64-43f2-a0cb-bf501a5808b3@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <8dd03122-aeb6-4dd3-9005-fb09bc1991a3@chalmers.se> <86a9c0739b034950b6f804472850d5f0@hi-jena.gsi.de> <35eb5fdf-6eea-32e2-fbdb-98ad2edc8d74@chalmers.se> <72c76512ca4c4e2fa4f39569b97a9e57@hi-jena.gsi.de> <123f76b2-bbdf-4188-a926-bd0966901336@chalmers.se> <2ea9c4c3-29ab-4569-aba1-30633b63608f@chalmers.se> , <2cb1927f-8c64-43f2-a0cb-bf501a5808b3@chalmers.se> Message-ID: Dear Hans, dear H?kan, now the compilation was successful. RIO4-MCAL-2 mbsdaq > make Could not figure out RFX1 firmware (8-xdigit number), skipping. TRIDI_FW=d374466d VULOM4_FW=d96ffc88 RFX1_FW= CC build_cc_ppc-linux_4.2.2_debug/tests/test_ctrl/main.o LD build_cc_ppc-linux_4.2.2_debug/test_ctrl AR build_cc_ppc-linux_4.2.2_debug/./libnurdlib.a CC build_cc_ppc-linux_4.2.2_debug/tools/memtest.o LN bin/memtest LD build_cc_ppc-linux_4.2.2_debug/tools/memtest CC build_cc_ppc-linux_4.2.2_debug/ctrl/nurdctrl.o LN bin/nurdctrl LD build_cc_ppc-linux_4.2.2_debug/nurdctrl CC build_cc_ppc-linux_4.2.2_debug/tools/rwdump.o LN bin/rwdump LD build_cc_ppc-linux_4.2.2_debug/tools/rwdump CC build_cc_ppc-linux_4.2.2_debug/tools/wrslew.o LN bin/wrslew LD build_cc_ppc-linux_4.2.2_debug/tools/wrslew build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) 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). 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. To run the DAQ, Bastian provided us with a set of scripts. The main one looks like this: source ../env/env.sh ./trloii_setup.sh # gdb --args \ ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ --label=MCAL2 \ --triva=master,fctime=10,ctime=50 \ --log-no-rate-limit \ --server=drasi,dest=lyserv \ --buf=size=400Mi \ --max-ev-size=0x1000000 \ --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ --eb=lyserv \ "$@" Will DRASI automatically work with the new NURDLIB or do I need to compile it again? The output stream of the data produced by the DAQ is probably set up with this script: #!/bin/bash while : do ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ stream://localhost \ --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 sleep 5 done Will also UCESB automatically adapt to the new NURDLIB or do I need to compile it again? (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.) 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. Best greetings from Jena G?nter ________________________________ Von: subexp-daq im Auftrag von Hans Toshihide T?rnqvist Gesendet: Montag, 8. Januar 2024 16:20:24 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.; H?kan T Johansson Betreff: Re: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version Dear G?nter, I was on a late lunch break. That should be the only env-var. I'm adding the explanation to my docu-todo. Cheers, Hans On 2024-01-08 15:57, H?kan T Johansson wrote: > > Dear G?nter, > > not a definate answer, but looking around for getend in the sources, I > did not find further suspicious environment variables. > > You could try > > end | grep 2023_mcalstruck > > or with some other significant part of the path to see if there are any > other. > > Cheers, > H?kan > > > On Mon, 8 Jan 2024, Weber, Guenter Dr. wrote: > >> >> Dear Hans, >> >> >> thank you very much! >> >> >> It now dies at a later stage of the compilation process. >> >> >> ... >> >> [tests/caen_v792.c:73: IPEDConversion] >> [tests/caen_v820.c:32: DefaultConfig] >> 2024-02-08,16:59:58:INFO: Will try default >> cfgpath='/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default >> ', can be set with NURDLIB_DEF_PATH. [config/config.c:181] >> 2024-02-08,16:59:58:INFO: Opened './tests/caen_v820_empty.cfg' { >> [config/parser.c:287] >> 2024-02-08,16:59:58:INFO: >> .Opened'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/caen >> _v820.cfg' { [config/parser.c:287] >> 2024-02-08,16:59:58:INFO: >> .Closed'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/caen >> _v820.cfg' } [config/parser.c:299] >> 2024-02-08,16:59:58:INFO: >> .Opened'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/modu >> le_log_level.cfg' { [config/parser.c:287] >> 2024-02-08,16:59:58:INFO: >> .Closed'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/modu >> le_log_level.cfg' } [config/parser.c:299] >> 2024-02-08,16:59:58:INFO: Closed './tests/caen_v820_empty.cfg' } >> [config/parser.c:299] >> 2024-02-08,16:59:58:ERRR: Could not find keyword config 'paux'. >> [config/config.c:711] >> 2024-02-08,16:59:58:ERRR: Calling abort()... [config/config.c:711] >> make: *** [build_cc_ppc-linux_4.2.2_debug/test_ok] Error 1 >> >> The problem is that the environment variable NURDLIB_DEF_PATH is still >> set >> to the old directory ('2023_mcalstruck' instead of '2024_mcalstruck', >> which >> I created today). Of course, I can change this now. But is there a >> list of >> all the environment variables that need to be updated? Or >> is NURDLIB_DEF_PATH the only one? >> >> >> >> Best greetings >> >> G?nter > -- 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: From hans.tornqvist at chalmers.se Tue Jan 9 11:31:34 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Tue, 9 Jan 2024 11:31:34 +0100 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <8dd03122-aeb6-4dd3-9005-fb09bc1991a3@chalmers.se> <86a9c0739b034950b6f804472850d5f0@hi-jena.gsi.de> <35eb5fdf-6eea-32e2-fbdb-98ad2edc8d74@chalmers.se> <72c76512ca4c4e2fa4f39569b97a9e57@hi-jena.gsi.de> <123f76b2-bbdf-4188-a926-bd0966901336@chalmers.se> <2ea9c4c3-29ab-4569-aba1-30633b63608f@chalmers.se> <2cb1927f-8c64-43f2-a0cb-bf501a5808b3@chalmers.se> Message-ID: <08028286-f61a-475d-ab01-b579141e5762@chalmers.se> 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 From g.weber at hi-jena.gsi.de Tue Jan 9 13:28:24 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 9 Jan 2024 12:28:24 +0000 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: <08028286-f61a-475d-ab01-b579141e5762@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <8dd03122-aeb6-4dd3-9005-fb09bc1991a3@chalmers.se> <86a9c0739b034950b6f804472850d5f0@hi-jena.gsi.de> <35eb5fdf-6eea-32e2-fbdb-98ad2edc8d74@chalmers.se> <72c76512ca4c4e2fa4f39569b97a9e57@hi-jena.gsi.de> <123f76b2-bbdf-4188-a926-bd0966901336@chalmers.se> <2ea9c4c3-29ab-4569-aba1-30633b63608f@chalmers.se> <2cb1927f-8c64-43f2-a0cb-bf501a5808b3@chalmers.se> , <08028286-f61a-475d-ab01-b579141e5762@chalmers.se> Message-ID: <48cae3a127fe4666901bc49eacf69d3b@hi-jena.gsi.de> 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 im Auftrag von Hans Toshihide T?rnqvist 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: From g.weber at hi-jena.gsi.de Tue Jan 9 14:49:33 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 9 Jan 2024 13:49:33 +0000 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: <48cae3a127fe4666901bc49eacf69d3b@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <8dd03122-aeb6-4dd3-9005-fb09bc1991a3@chalmers.se> <86a9c0739b034950b6f804472850d5f0@hi-jena.gsi.de> <35eb5fdf-6eea-32e2-fbdb-98ad2edc8d74@chalmers.se> <72c76512ca4c4e2fa4f39569b97a9e57@hi-jena.gsi.de> <123f76b2-bbdf-4188-a926-bd0966901336@chalmers.se> <2ea9c4c3-29ab-4569-aba1-30633b63608f@chalmers.se> <2cb1927f-8c64-43f2-a0cb-bf501a5808b3@chalmers.se> , <08028286-f61a-475d-ab01-b579141e5762@chalmers.se>, <48cae3a127fe4666901bc49eacf69d3b@hi-jena.gsi.de> Message-ID: <81f59eb1bbc344bf8cf703c150a1796b@hi-jena.gsi.de> 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 im Auftrag von Weber, Guenter Dr. 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 im Auftrag von Hans Toshihide T?rnqvist 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: From f96hajo at chalmers.se Tue Jan 9 14:56:41 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Tue, 9 Jan 2024 14:56:41 +0100 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: <81f59eb1bbc344bf8cf703c150a1796b@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <8dd03122-aeb6-4dd3-9005-fb09bc1991a3@chalmers.se> <86a9c0739b034950b6f804472850d5f0@hi-jena.gsi.de> <35eb5fdf-6eea-32e2-fbdb-98ad2edc8d74@chalmers.se> <72c76512ca4c4e2fa4f39569b97a9e57@hi-jena.gsi.de> <123f76b2-bbdf-4188-a926-bd0966901336@chalmers.se> <2ea9c4c3-29ab-4569-aba1-30633b63608f@chalmers.se> <2cb1927f-8c64-43f2-a0cb-bf501a5808b3@chalmers.se> , <08028286-f61a-475d-ab01-b579141e5762@chalmers.se>, <48cae3a127fe4666901bc49eacf69d3b@hi-jena.gsi.de> <81f59eb1bbc344bf8cf703c150a1796b@hi-jena.gsi.de> Message-ID: 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 im Auftrag von Weber, Guenter Dr. > 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 im Auftrag von Hans Toshihide T?rnqvist > 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 > > From hans.tornqvist at chalmers.se Tue Jan 9 15:34:37 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Tue, 9 Jan 2024 15:34:37 +0100 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <8dd03122-aeb6-4dd3-9005-fb09bc1991a3@chalmers.se> <86a9c0739b034950b6f804472850d5f0@hi-jena.gsi.de> <35eb5fdf-6eea-32e2-fbdb-98ad2edc8d74@chalmers.se> <72c76512ca4c4e2fa4f39569b97a9e57@hi-jena.gsi.de> <123f76b2-bbdf-4188-a926-bd0966901336@chalmers.se> <2ea9c4c3-29ab-4569-aba1-30633b63608f@chalmers.se> <2cb1927f-8c64-43f2-a0cb-bf501a5808b3@chalmers.se> <08028286-f61a-475d-ab01-b579141e5762@chalmers.se> <48cae3a127fe4666901bc49eacf69d3b@hi-jena.gsi.de> <81f59eb1bbc344bf8cf703c150a1796b@hi-jena.gsi.de> Message-ID: <741faccc-abbc-4c5c-86af-ec865377f437@chalmers.se> Dear G?nter, To add to what H?kan said, it looks like that is a rather old version of r3bfuser with nurdlib features that are now gone. Is there a file called r3bfuser.cfg in directory where the DAQ node runs? If so, could you paste it into this thread? If it's mostly empty you could move to using the minimal built-in nurdlib f-user. But if you need some extra features (timestamps, tpat:s etc) you'll have to update the r3bfuser too. Here should be a rather new version if you'd like to go that route: https://gitlab.com/chalmers-subexp/r3bfuser I had a go at building it with a new version of nurdlib and it looked ok. Cheers, Hans On 2024-01-09 14:56, H?kan T Johansson wrote: > > 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 im Auftrag von >> Weber, Guenter Dr. >> 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 im Auftrag von >> Hans Toshihide T?rnqvist >> 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 >> >> > From g.weber at hi-jena.gsi.de Tue Jan 9 15:58:04 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 9 Jan 2024 14:58:04 +0000 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <8dd03122-aeb6-4dd3-9005-fb09bc1991a3@chalmers.se> <86a9c0739b034950b6f804472850d5f0@hi-jena.gsi.de> <35eb5fdf-6eea-32e2-fbdb-98ad2edc8d74@chalmers.se> <72c76512ca4c4e2fa4f39569b97a9e57@hi-jena.gsi.de> <123f76b2-bbdf-4188-a926-bd0966901336@chalmers.se> <2ea9c4c3-29ab-4569-aba1-30633b63608f@chalmers.se> <2cb1927f-8c64-43f2-a0cb-bf501a5808b3@chalmers.se> , <08028286-f61a-475d-ab01-b579141e5762@chalmers.se>, <48cae3a127fe4666901bc49eacf69d3b@hi-jena.gsi.de> <81f59eb1bbc344bf8cf703c150a1796b@hi-jena.gsi.de>, Message-ID: <128bdcbcdaad41b4be10ecae34715fb8@hi-jena.gsi.de> 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 im Auftrag von H?kan T Johansson 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 im Auftrag von Weber, Guenter Dr. > 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 im Auftrag von Hans Toshihide T?rnqvist > 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: From f96hajo at chalmers.se Tue Jan 9 16:05:19 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Tue, 9 Jan 2024 16:05:19 +0100 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: <128bdcbcdaad41b4be10ecae34715fb8@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <86a9c0739b034950b6f804472850d5f0@hi-jena.gsi.de> <35eb5fdf-6eea-32e2-fbdb-98ad2edc8d74@chalmers.se> <72c76512ca4c4e2fa4f39569b97a9e57@hi-jena.gsi.de> <123f76b2-bbdf-4188-a926-bd0966901336@chalmers.se> <2ea9c4c3-29ab-4569-aba1-30633b63608f@chalmers.se> <2cb1927f-8c64-43f2-a0cb-bf501a5808b3@chalmers.se> , <08028286-f61a-475d-ab01-b579141e5762@chalmers.se>, <48cae3a127fe4666901bc49eacf69d3b@hi-jena.gsi.de> <81f59eb1bbc344bf8cf703c150a1796b@hi-jena.gsi.de>, <128bdcbcdaad41b4be10ecae34715fb8@hi-jena.gsi.de> Message-ID: <8256e7a9-82b9-e8b9-2687-ef6b3156df57@chalmers.se> Dear G?nter, yes, please download the latest drasi. That should fix the broken link. ALso, compile it on the PC first. That will download the file, and then the RIO compile will use that. I'd suggest to also update trloii before compiling! Same trick there might be helpful, i.e. compile on PC first. Nothing to download, but some generated files are quicker made on a PC. Cheers, H?kan On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > 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 im Auftrag von H?kan T Johansson > 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 im Auftrag von Weber, Guenter Dr. > > 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 im Auftrag von Hans Toshihide T?rnqvist > > 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 > > > > > > From g.weber at hi-jena.gsi.de Tue Jan 9 16:28:47 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 9 Jan 2024 15:28:47 +0000 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: <8256e7a9-82b9-e8b9-2687-ef6b3156df57@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <86a9c0739b034950b6f804472850d5f0@hi-jena.gsi.de> <35eb5fdf-6eea-32e2-fbdb-98ad2edc8d74@chalmers.se> <72c76512ca4c4e2fa4f39569b97a9e57@hi-jena.gsi.de> <123f76b2-bbdf-4188-a926-bd0966901336@chalmers.se> <2ea9c4c3-29ab-4569-aba1-30633b63608f@chalmers.se> <2cb1927f-8c64-43f2-a0cb-bf501a5808b3@chalmers.se> , <08028286-f61a-475d-ab01-b579141e5762@chalmers.se>, <48cae3a127fe4666901bc49eacf69d3b@hi-jena.gsi.de> <81f59eb1bbc344bf8cf703c150a1796b@hi-jena.gsi.de>, <128bdcbcdaad41b4be10ecae34715fb8@hi-jena.gsi.de>, <8256e7a9-82b9-e8b9-2687-ef6b3156df57@chalmers.se> Message-ID: Dear friends, what I now did: 1) Deleting the folders of DRASI, TRLOII, and R3BFUSER 2) Downloading the most recent versions from Gitlab 3) Executing MAKE CLEAN, followed by MAKE in the folders TRLOII and DRASI on the PC (make fw_d96ffc88_trlo_build failed on the PC, make fw_d374466d_tridi_build I did not try) 4) Executing MAKE CLEAN, followed by MAKE on the RIO in the folder TRLOII. And there a new problem shows up: make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' CC bld_ppc-linux_4.2.2/align_analyse.o CC bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_parser.o gen_ppc-linux_4.2.2/align_parser.c:19: warning: 'align_growstack' declared 'static' but never defined CC bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o align_lexer.l: In function 'align_lex': align_lexer.l:28: error: 'align_lval' undeclared (first use in this function) align_lexer.l:28: error: (Each undeclared identifier is reported only once align_lexer.l:28: error: for each function it appears in.) align_lexer.l:29: error: 'INTEGER' undeclared (first use in this function) align_lexer.l:32: error: 'START' undeclared (first use in this function) align_lexer.l:33: error: 'END' undeclared (first use in this function) align_lexer.l:34: error: 'CH' undeclared (first use in this function) align_lexer.l:35: error: 'DELAY' undeclared (first use in this function) make[1]: *** [bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o] Error 1 make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' make: *** [trigalign_dir] Error 2 When I was compiling TRLOII with the old version, this error did not occur. I am really sorry for causing so much trouble ? Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Dienstag, 9. Januar 2024 16:05:19 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, yes, please download the latest drasi. That should fix the broken link. ALso, compile it on the PC first. That will download the file, and then the RIO compile will use that. I'd suggest to also update trloii before compiling! Same trick there might be helpful, i.e. compile on PC first. Nothing to download, but some generated files are quicker made on a PC. Cheers, H?kan On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > 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 im Auftrag von H?kan T Johansson > 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 im Auftrag von Weber, Guenter Dr. > > 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 im Auftrag von Hans Toshihide T?rnqvist > > 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: From f96hajo at chalmers.se Tue Jan 9 16:36:28 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Tue, 9 Jan 2024 16:36:28 +0100 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <35eb5fdf-6eea-32e2-fbdb-98ad2edc8d74@chalmers.se> <72c76512ca4c4e2fa4f39569b97a9e57@hi-jena.gsi.de> <123f76b2-bbdf-4188-a926-bd0966901336@chalmers.se> <2ea9c4c3-29ab-4569-aba1-30633b63608f@chalmers.se> <2cb1927f-8c64-43f2-a0cb-bf501a5808b3@chalmers.se> , <08028286-f61a-475d-ab01-b579141e5762@chalmers.se>, <48cae3a127fe4666901bc49eacf69d3b@hi-jena.gsi.de> <81f59eb1bbc344bf8cf703c150a1796b@hi-jena.gsi.de>, <128bdcbcdaad41b4be10ecae34715fb8@hi-jena.gsi.de>, <8256e7a9-82b9-e8b9-2687-ef6b3156df57@chalmers.se> Message-ID: <14184882-f21c-dbce-fa42-6d17901d086a@chalmers.se> Quick-fix for the trigalign: try compile with 'make -k', which tries to continue with other things. the trigger aligment you likely do not use, so we can solve that more slowly. You are not creating problems, we want/need to know what does not work so it can get fixed :) Cheers, H?kan On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > what I now did: > > > 1) Deleting the folders of DRASI, TRLOII, and R3BFUSER > > 2) Downloading the most recent versions from Gitlab > > 3) Executing MAKE CLEAN, followed by MAKE in the folders TRLOII and DRASI on the PC (make fw_d96ffc88_trlo_build failed on the PC, make > fw_d374466d_tridi_build I did not try) > > 4) Executing MAKE CLEAN, followed by MAKE on the RIO in the folder TRLOII. And there a new problem shows up: > > > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > ?? CC??? bld_ppc-linux_4.2.2/align_analyse.o > ?? CC??? bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_parser.o > gen_ppc-linux_4.2.2/align_parser.c:19: warning: 'align_growstack' declared 'static' but never defined > ?? CC??? bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o > align_lexer.l: In function 'align_lex': > align_lexer.l:28: error: 'align_lval' undeclared (first use in this function) > align_lexer.l:28: error: (Each undeclared identifier is reported only once > align_lexer.l:28: error: for each function it appears in.) > align_lexer.l:29: error: 'INTEGER' undeclared (first use in this function) > align_lexer.l:32: error: 'START' undeclared (first use in this function) > align_lexer.l:33: error: 'END' undeclared (first use in this function) > align_lexer.l:34: error: 'CH' undeclared (first use in this function) > align_lexer.l:35: error: 'DELAY' undeclared (first use in this function) > make[1]: *** [bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o] Error 1 > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > make: *** [trigalign_dir] Error 2 > > When I was compiling TRLOII with the old version, this error did not occur. > > > > I am really sorry for causing so much trouble ? > > > > > Best greetings > > G?nter > > > > _____________________________________________________________________________________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan T Johansson > Gesendet: Dienstag, 9. Januar 2024 16:05:19 > 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, > > yes, please download the latest drasi.? That should fix the broken link. > > ALso, compile it on the PC first.? That will download the file, and then > the RIO compile will use that. > > I'd suggest to also update trloii before compiling!? Same trick there > might be helpful, i.e. compile on PC first.? Nothing to download, but some > generated files are quicker made on a PC. > > Cheers, > H?kan > > > On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > > > > 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 im Auftrag von H?kan T Johansson > > 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 im Auftrag von Weber, Guenter Dr. > > > 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 im Auftrag von Hans Toshihide T?rnqvist > > > 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 > > > > > > > > > > > > From g.weber at hi-jena.gsi.de Tue Jan 9 16:39:45 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 9 Jan 2024 15:39:45 +0000 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: <14184882-f21c-dbce-fa42-6d17901d086a@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <35eb5fdf-6eea-32e2-fbdb-98ad2edc8d74@chalmers.se> <72c76512ca4c4e2fa4f39569b97a9e57@hi-jena.gsi.de> <123f76b2-bbdf-4188-a926-bd0966901336@chalmers.se> <2ea9c4c3-29ab-4569-aba1-30633b63608f@chalmers.se> <2cb1927f-8c64-43f2-a0cb-bf501a5808b3@chalmers.se> , <08028286-f61a-475d-ab01-b579141e5762@chalmers.se>, <48cae3a127fe4666901bc49eacf69d3b@hi-jena.gsi.de> <81f59eb1bbc344bf8cf703c150a1796b@hi-jena.gsi.de>, <128bdcbcdaad41b4be10ecae34715fb8@hi-jena.gsi.de>, <8256e7a9-82b9-e8b9-2687-ef6b3156df57@chalmers.se> , <14184882-f21c-dbce-fa42-6d17901d086a@chalmers.se> Message-ID: Unfortunately, "make -k" ends with the same result: ... make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' CC bld_ppc-linux_4.2.2/align_analyse.o CC bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_parser.o gen_ppc-linux_4.2.2/align_parser.c:19: warning: 'align_growstack' declared 'static' but never defined CC bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o align_lexer.l: In function 'align_lex': align_lexer.l:28: error: 'align_lval' undeclared (first use in this function) align_lexer.l:28: error: (Each undeclared identifier is reported only once align_lexer.l:28: error: for each function it appears in.) align_lexer.l:29: error: 'INTEGER' undeclared (first use in this function) align_lexer.l:32: error: 'START' undeclared (first use in this function) align_lexer.l:33: error: 'END' undeclared (first use in this function) align_lexer.l:34: error: 'CH' undeclared (first use in this function) align_lexer.l:35: error: 'DELAY' undeclared (first use in this function) make[1]: *** [bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o] Error 1 make[1]: Target `all' not remade because of errors. make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' make: *** [trigalign_dir] Error 2 make: Target `all' not remade because of errors. ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Dienstag, 9. Januar 2024 16:36:28 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 Quick-fix for the trigalign: try compile with 'make -k', which tries to continue with other things. the trigger aligment you likely do not use, so we can solve that more slowly. You are not creating problems, we want/need to know what does not work so it can get fixed :) Cheers, H?kan On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > what I now did: > > > 1) Deleting the folders of DRASI, TRLOII, and R3BFUSER > > 2) Downloading the most recent versions from Gitlab > > 3) Executing MAKE CLEAN, followed by MAKE in the folders TRLOII and DRASI on the PC (make fw_d96ffc88_trlo_build failed on the PC, make > fw_d374466d_tridi_build I did not try) > > 4) Executing MAKE CLEAN, followed by MAKE on the RIO in the folder TRLOII. And there a new problem shows up: > > > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > CC bld_ppc-linux_4.2.2/align_analyse.o > CC bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_parser.o > gen_ppc-linux_4.2.2/align_parser.c:19: warning: 'align_growstack' declared 'static' but never defined > CC bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o > align_lexer.l: In function 'align_lex': > align_lexer.l:28: error: 'align_lval' undeclared (first use in this function) > align_lexer.l:28: error: (Each undeclared identifier is reported only once > align_lexer.l:28: error: for each function it appears in.) > align_lexer.l:29: error: 'INTEGER' undeclared (first use in this function) > align_lexer.l:32: error: 'START' undeclared (first use in this function) > align_lexer.l:33: error: 'END' undeclared (first use in this function) > align_lexer.l:34: error: 'CH' undeclared (first use in this function) > align_lexer.l:35: error: 'DELAY' undeclared (first use in this function) > make[1]: *** [bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o] Error 1 > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > make: *** [trigalign_dir] Error 2 > > When I was compiling TRLOII with the old version, this error did not occur. > > > > I am really sorry for causing so much trouble ? > > > > > Best greetings > > G?nter > > > > _____________________________________________________________________________________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan T Johansson > Gesendet: Dienstag, 9. Januar 2024 16:05:19 > 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, > > yes, please download the latest drasi. That should fix the broken link. > > ALso, compile it on the PC first. That will download the file, and then > the RIO compile will use that. > > I'd suggest to also update trloii before compiling! Same trick there > might be helpful, i.e. compile on PC first. Nothing to download, but some > generated files are quicker made on a PC. > > Cheers, > H?kan > > > On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > > > > 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 im Auftrag von H?kan T Johansson > > 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 im Auftrag von Weber, Guenter Dr. > > > 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 im Auftrag von Hans Toshihide T?rnqvist > > > 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: From f96hajo at chalmers.se Tue Jan 9 16:59:07 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Tue, 9 Jan 2024 16:59:07 +0100 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <72c76512ca4c4e2fa4f39569b97a9e57@hi-jena.gsi.de> <123f76b2-bbdf-4188-a926-bd0966901336@chalmers.se> <2ea9c4c3-29ab-4569-aba1-30633b63608f@chalmers.se> <2cb1927f-8c64-43f2-a0cb-bf501a5808b3@chalmers.se> , <08028286-f61a-475d-ab01-b579141e5762@chalmers.se>, <48cae3a127fe4666901bc49eacf69d3b@hi-jena.gsi.de> <81f59eb1bbc344bf8cf703c150a1796b@hi-jena.gsi.de>, <128bdcbcdaad41b4be10ecae34715fb8@hi-jena.gsi.de>, <8256e7a9-82b9-e8b9-2687-ef6b3156df57@chalmers.se> , <14184882-f21c-dbce-fa42-6d17901d086a@chalmers.se> Message-ID: <6891db86-9945-74ce-5872-9f84afa855b7@chalmers.se> Quick-fix II: comment out trigalign_dir from the targets in trloii/Makefile: all: trimictrl_dir flash_dir \ proglinks # trigalign_dir Cheers, H?kan On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > Unfortunately, "make -k" ends with the same result: > > > ... > > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > ?? CC??? bld_ppc-linux_4.2.2/align_analyse.o > ?? CC??? bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_parser.o > gen_ppc-linux_4.2.2/align_parser.c:19: warning: 'align_growstack' declared 'static' but never defined > ?? CC??? bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o > align_lexer.l: In function 'align_lex': > align_lexer.l:28: error: 'align_lval' undeclared (first use in this function) > align_lexer.l:28: error: (Each undeclared identifier is reported only once > align_lexer.l:28: error: for each function it appears in.) > align_lexer.l:29: error: 'INTEGER' undeclared (first use in this function) > align_lexer.l:32: error: 'START' undeclared (first use in this function) > align_lexer.l:33: error: 'END' undeclared (first use in this function) > align_lexer.l:34: error: 'CH' undeclared (first use in this function) > align_lexer.l:35: error: 'DELAY' undeclared (first use in this function) > make[1]: *** [bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o] Error 1 > make[1]: Target `all' not remade because of errors. > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > make: *** [trigalign_dir] Error 2 > make: Target `all' not remade because of errors. > > > _____________________________________________________________________________________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan T Johansson > Gesendet: Dienstag, 9. Januar 2024 16:36:28 > 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 ? > > Quick-fix for the trigalign: > > try compile with 'make -k', which tries to continue with other things. > the trigger aligment you likely do not use, so we can solve that more slowly. > > You are not creating problems, we want/need to know what does not work so > it can get fixed :) > > Cheers, > H?kan > > > > On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > > > > Dear friends, > > > > > > what I now did: > > > > > > 1) Deleting the folders of DRASI, TRLOII, and R3BFUSER > > > > 2) Downloading the most recent versions from Gitlab > > > > 3) Executing MAKE CLEAN, followed by MAKE in the folders TRLOII and DRASI on the PC (make fw_d96ffc88_trlo_build failed on the PC, make > > fw_d374466d_tridi_build I did not try) > > > > 4) Executing MAKE CLEAN, followed by MAKE on the RIO in the folder TRLOII. And there a new problem shows up: > > > > > > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > > ?? CC??? bld_ppc-linux_4.2.2/align_analyse.o > > ?? CC??? bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_parser.o > > gen_ppc-linux_4.2.2/align_parser.c:19: warning: 'align_growstack' declared 'static' but never defined > > ?? CC??? bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o > > align_lexer.l: In function 'align_lex': > > align_lexer.l:28: error: 'align_lval' undeclared (first use in this function) > > align_lexer.l:28: error: (Each undeclared identifier is reported only once > > align_lexer.l:28: error: for each function it appears in.) > > align_lexer.l:29: error: 'INTEGER' undeclared (first use in this function) > > align_lexer.l:32: error: 'START' undeclared (first use in this function) > > align_lexer.l:33: error: 'END' undeclared (first use in this function) > > align_lexer.l:34: error: 'CH' undeclared (first use in this function) > > align_lexer.l:35: error: 'DELAY' undeclared (first use in this function) > > make[1]: *** [bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o] Error 1 > > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > > make: *** [trigalign_dir] Error 2 > > > > When I was compiling TRLOII with the old version, this error did not occur. > > > > > > > > I am really sorry for causing so much trouble ? > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > >____________________________________________________________________________________________________________________________________________________ > _ > > Von: subexp-daq im Auftrag von H?kan T Johansson > > Gesendet: Dienstag, 9. Januar 2024 16:05:19 > > 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, > > > > yes, please download the latest drasi.? That should fix the broken link. > > > > ALso, compile it on the PC first.? That will download the file, and then > > the RIO compile will use that. > > > > I'd suggest to also update trloii before compiling!? Same trick there > > might be helpful, i.e. compile on PC first.? Nothing to download, but some > > generated files are quicker made on a PC. > > > > Cheers, > > H?kan > > > > > > On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > > > > > > > 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 im Auftrag von H?kan T Johansson > > > 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 im Auftrag von Weber, Guenter Dr. > > > > 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 im Auftrag von Hans Toshihide T?rnqvist > > > > 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 > > > > > > > > > > > > > > > > > > > > From g.weber at hi-jena.gsi.de Tue Jan 9 22:11:28 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 9 Jan 2024 21:11:28 +0000 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: <6891db86-9945-74ce-5872-9f84afa855b7@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <72c76512ca4c4e2fa4f39569b97a9e57@hi-jena.gsi.de> <123f76b2-bbdf-4188-a926-bd0966901336@chalmers.se> <2ea9c4c3-29ab-4569-aba1-30633b63608f@chalmers.se> <2cb1927f-8c64-43f2-a0cb-bf501a5808b3@chalmers.se> , <08028286-f61a-475d-ab01-b579141e5762@chalmers.se>, <48cae3a127fe4666901bc49eacf69d3b@hi-jena.gsi.de> <81f59eb1bbc344bf8cf703c150a1796b@hi-jena.gsi.de>, <128bdcbcdaad41b4be10ecae34715fb8@hi-jena.gsi.de>, <8256e7a9-82b9-e8b9-2687-ef6b3156df57@chalmers.se> , <14184882-f21c-dbce-fa42-6d17901d086a@chalmers.se> , <6891db86-9945-74ce-5872-9f84afa855b7@chalmers.se> Message-ID: Ok, after this fix, the compilation in TRLOII finshes without problems. But in TRLOCTRL we have the following problem (as already noticed when I tried to compile on the PC). RIO4-MCAL-2 mbsdaq > pwd /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl RIO4-MCAL-2 mbsdaq > make fw_d96ffc88_trlo_build cat: firmwaredirs: No such file or directory make -C fw_d96ffc88_trlo -f ../trlolib/Makefile \ TRLOBASENAME=`cat fw_d96ffc88_trlo/trlobasename` FILTERSRC=1 cat: fw_d96ffc88_trlo/trlobasename: No such file or directory make: *** fw_d96ffc88_trlo: No such file or directory. Stop. make: *** [fw_d96ffc88_trlo_build] Error 2 RIO4-MCAL-2 mbsdaq > make fw_d374466d_tridi_build cat: firmwaredirs: No such file or directory make -C fw_d374466d_tridi -f ../trlolib/Makefile \ TRLOBASENAME=`cat fw_d374466d_tridi/trlobasename` FILTERSRC=1 cat: fw_d374466d_tridi/trlobasename: No such file or directory make: *** fw_d374466d_tridi: No such file or directory. Stop. make: *** [fw_d374466d_tridi_build] Error 2 After this I went ahead to DRASI and there the compilation finished without error. Thus, if the issue with TRLOCTRL could be solved, maybe our DAQ is good to go ? Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Dienstag, 9. Januar 2024 16:59:07 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 Quick-fix II: comment out trigalign_dir from the targets in trloii/Makefile: all: trimictrl_dir flash_dir \ proglinks # trigalign_dir Cheers, H?kan On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > Unfortunately, "make -k" ends with the same result: > > > ... > > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > CC bld_ppc-linux_4.2.2/align_analyse.o > CC bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_parser.o > gen_ppc-linux_4.2.2/align_parser.c:19: warning: 'align_growstack' declared 'static' but never defined > CC bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o > align_lexer.l: In function 'align_lex': > align_lexer.l:28: error: 'align_lval' undeclared (first use in this function) > align_lexer.l:28: error: (Each undeclared identifier is reported only once > align_lexer.l:28: error: for each function it appears in.) > align_lexer.l:29: error: 'INTEGER' undeclared (first use in this function) > align_lexer.l:32: error: 'START' undeclared (first use in this function) > align_lexer.l:33: error: 'END' undeclared (first use in this function) > align_lexer.l:34: error: 'CH' undeclared (first use in this function) > align_lexer.l:35: error: 'DELAY' undeclared (first use in this function) > make[1]: *** [bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o] Error 1 > make[1]: Target `all' not remade because of errors. > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > make: *** [trigalign_dir] Error 2 > make: Target `all' not remade because of errors. > > > _____________________________________________________________________________________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan T Johansson > Gesendet: Dienstag, 9. Januar 2024 16:36:28 > 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 > > Quick-fix for the trigalign: > > try compile with 'make -k', which tries to continue with other things. > the trigger aligment you likely do not use, so we can solve that more slowly. > > You are not creating problems, we want/need to know what does not work so > it can get fixed :) > > Cheers, > H?kan > > > > On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > > > > Dear friends, > > > > > > what I now did: > > > > > > 1) Deleting the folders of DRASI, TRLOII, and R3BFUSER > > > > 2) Downloading the most recent versions from Gitlab > > > > 3) Executing MAKE CLEAN, followed by MAKE in the folders TRLOII and DRASI on the PC (make fw_d96ffc88_trlo_build failed on the PC, make > > fw_d374466d_tridi_build I did not try) > > > > 4) Executing MAKE CLEAN, followed by MAKE on the RIO in the folder TRLOII. And there a new problem shows up: > > > > > > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > > CC bld_ppc-linux_4.2.2/align_analyse.o > > CC bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_parser.o > > gen_ppc-linux_4.2.2/align_parser.c:19: warning: 'align_growstack' declared 'static' but never defined > > CC bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o > > align_lexer.l: In function 'align_lex': > > align_lexer.l:28: error: 'align_lval' undeclared (first use in this function) > > align_lexer.l:28: error: (Each undeclared identifier is reported only once > > align_lexer.l:28: error: for each function it appears in.) > > align_lexer.l:29: error: 'INTEGER' undeclared (first use in this function) > > align_lexer.l:32: error: 'START' undeclared (first use in this function) > > align_lexer.l:33: error: 'END' undeclared (first use in this function) > > align_lexer.l:34: error: 'CH' undeclared (first use in this function) > > align_lexer.l:35: error: 'DELAY' undeclared (first use in this function) > > make[1]: *** [bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o] Error 1 > > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > > make: *** [trigalign_dir] Error 2 > > > > When I was compiling TRLOII with the old version, this error did not occur. > > > > > > > > I am really sorry for causing so much trouble ? > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > >____________________________________________________________________________________________________________________________________________________ > _ > > Von: subexp-daq im Auftrag von H?kan T Johansson > > Gesendet: Dienstag, 9. Januar 2024 16:05:19 > > 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, > > > > yes, please download the latest drasi. That should fix the broken link. > > > > ALso, compile it on the PC first. That will download the file, and then > > the RIO compile will use that. > > > > I'd suggest to also update trloii before compiling! Same trick there > > might be helpful, i.e. compile on PC first. Nothing to download, but some > > generated files are quicker made on a PC. > > > > Cheers, > > H?kan > > > > > > On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > > > > > > > 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 im Auftrag von H?kan T Johansson > > > 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 im Auftrag von Weber, Guenter Dr. > > > > 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 im Auftrag von Hans Toshihide T?rnqvist > > > > 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: From f96hajo at chalmers.se Tue Jan 9 22:28:24 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Tue, 9 Jan 2024 22:28:24 +0100 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <123f76b2-bbdf-4188-a926-bd0966901336@chalmers.se> <2ea9c4c3-29ab-4569-aba1-30633b63608f@chalmers.se> <2cb1927f-8c64-43f2-a0cb-bf501a5808b3@chalmers.se> , <08028286-f61a-475d-ab01-b579141e5762@chalmers.se>, <48cae3a127fe4666901bc49eacf69d3b@hi-jena.gsi.de> <81f59eb1bbc344bf8cf703c150a1796b@hi-jena.gsi.de>, <128bdcbcdaad41b4be10ecae34715fb8@hi-jena.gsi.de>, <8256e7a9-82b9-e8b9-2687-ef6b3156df57@chalmers.se> , <14184882-f21c-dbce-fa42-6d17901d086a@chalmers.se> , <6891db86-9945-74ce-5872-9f84afa855b7@chalmers.se> Message-ID: <1fc55deb-35fd-a0f1-cb56-c550e36feba8@chalmers.se> My mistake: in a new trloii directory, after cd trloctrl you need to do find_firmwares.pl before the make _build however, I suspect we'll then run into the next issue, namely that the TRLO II firmware that you have likely is old. I do not see d96ffc88 in the list of current ones http://fy.chalmers.se/~f96hajo/trloii/firmwares.html -- This is not needed, but might help to figure that: If you can run (new or old) $TRLOII_FLASH or just from trloii/ dir: bin/vulomflash --addr=X --readprogs where X needs to be the address of the vulom module, that would give a list. Do you know what the vulom address is? -- Hmmmm. To update that means to also update what runs on the VULOM4, which makes it more messy to go back-and-forth. Or to run another version of it but without changing its default. Doable, but I think we are getting a few too many loose variables here right now. I think it would be best if you for the moment copy over the old trloii/ directory and try to recompile that one in the new location. -- The other way is if you have a trloii_firmwares_XXX.tar.gz file, e.g. in the (old) trloii/ directory, and unp?ack that in the new trloii/, then find_firmwares.pl should also find those (old) headers, and hopefully produce a line also with d374466d. -- Sorry that this is becoming a bit too convoluted to be really pleasant. Cheers, H?kan On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > Ok, after this fix, the?compilation in TRLOII finshes without problems. > > > But in TRLOCTRL we have the following problem (as?already noticed?when I tried to compile on the > PC). > > > RIO4-MCAL-2 mbsdaq > pwd > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl > RIO4-MCAL-2 mbsdaq > make fw_d96ffc88_trlo_build > cat: firmwaredirs: No such file or directory > make? -C fw_d96ffc88_trlo -f ../trlolib/Makefile \ > ? ? ? ? ? TRLOBASENAME=`cat fw_d96ffc88_trlo/trlobasename` FILTERSRC=1 > cat: fw_d96ffc88_trlo/trlobasename: No such file or directory > make: *** fw_d96ffc88_trlo: No such file or directory.? Stop. > make: *** [fw_d96ffc88_trlo_build] Error 2 > RIO4-MCAL-2 mbsdaq > make fw_d374466d_tridi_build > cat: firmwaredirs: No such file or directory > make? -C fw_d374466d_tridi -f ../trlolib/Makefile \ > ? ? ? ? ? TRLOBASENAME=`cat fw_d374466d_tridi/trlobasename` FILTERSRC=1 > cat: fw_d374466d_tridi/trlobasename: No such file or directory > make: *** fw_d374466d_tridi: No such file or directory.? Stop. > make: *** [fw_d374466d_tridi_build] Error 2 > > After this I went ahead to DRASI and there the compilation finished without error. > > Thus, if the issue with?TRLOCTRL could be solved, maybe our DAQ is good to go ? > > > > Best greetings > G?nter > > > > _________________________________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan T Johansson > > Gesendet: Dienstag, 9. Januar 2024 16:59:07 > 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 ? > > Quick-fix II:? comment out trigalign_dir from the targets in trloii/Makefile: > > all: trimictrl_dir flash_dir \ > ???????? proglinks # trigalign_dir > > Cheers, > H?kan > > > > On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > > > > Unfortunately, "make -k" ends with the same result: > > > > > > ... > > > > make[1]: Entering directory > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > > ?? CC??? bld_ppc-linux_4.2.2/align_analyse.o > > ?? CC??? bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_parser.o > > gen_ppc-linux_4.2.2/align_parser.c:19: warning: 'align_growstack' declared 'static' but never > defined > > ?? CC??? bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o > > align_lexer.l: In function 'align_lex': > > align_lexer.l:28: error: 'align_lval' undeclared (first use in this function) > > align_lexer.l:28: error: (Each undeclared identifier is reported only once > > align_lexer.l:28: error: for each function it appears in.) > > align_lexer.l:29: error: 'INTEGER' undeclared (first use in this function) > > align_lexer.l:32: error: 'START' undeclared (first use in this function) > > align_lexer.l:33: error: 'END' undeclared (first use in this function) > > align_lexer.l:34: error: 'CH' undeclared (first use in this function) > > align_lexer.l:35: error: 'DELAY' undeclared (first use in this function) > > make[1]: *** [bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o] Error 1 > > make[1]: Target `all' not remade because of errors. > > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > > make: *** [trigalign_dir] Error 2 > > make: Target `all' not remade because of errors. > > > > > >________________________________________________________________________________________________ > _____________________________________________________ > > Von: subexp-daq im Auftrag von H?kan T Johansson > > > Gesendet: Dienstag, 9. Januar 2024 16:36:28 > > 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 ? > > > > Quick-fix for the trigalign: > > > > try compile with 'make -k', which tries to continue with other things. > > the trigger aligment you likely do not use, so we can solve that more slowly. > > > > You are not creating problems, we want/need to know what does not work so > > it can get fixed :) > > > > Cheers, > > H?kan > > > > > > > > On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > > > > > > > Dear friends, > > > > > > > > > what I now did: > > > > > > > > > 1) Deleting the folders of DRASI, TRLOII, and R3BFUSER > > > > > > 2) Downloading the most recent versions from Gitlab > > > > > > 3) Executing MAKE CLEAN, followed by MAKE in the folders TRLOII and DRASI on the PC (make > fw_d96ffc88_trlo_build failed on the PC, make > > > fw_d374466d_tridi_build I did not try) > > > > > > 4) Executing MAKE CLEAN, followed by MAKE on the RIO in the folder TRLOII. And there a new > problem shows up: > > > > > > > > > make[1]: Entering directory > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > > > ?? CC??? bld_ppc-linux_4.2.2/align_analyse.o > > > ?? CC??? bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_parser.o > > > gen_ppc-linux_4.2.2/align_parser.c:19: warning: 'align_growstack' declared 'static' but never > defined > > > ?? CC??? bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o > > > align_lexer.l: In function 'align_lex': > > > align_lexer.l:28: error: 'align_lval' undeclared (first use in this function) > > > align_lexer.l:28: error: (Each undeclared identifier is reported only once > > > align_lexer.l:28: error: for each function it appears in.) > > > align_lexer.l:29: error: 'INTEGER' undeclared (first use in this function) > > > align_lexer.l:32: error: 'START' undeclared (first use in this function) > > > align_lexer.l:33: error: 'END' undeclared (first use in this function) > > > align_lexer.l:34: error: 'CH' undeclared (first use in this function) > > > align_lexer.l:35: error: 'DELAY' undeclared (first use in this function) > > > make[1]: *** [bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o] Error 1 > > > make[1]: Leaving directory > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > > > make: *** [trigalign_dir] Error 2 > > > > > > When I was compiling TRLOII with the old version, this error did not occur. > > > > > > > > > > > > I am really sorry for causing so much trouble ? > > > > > > > > > > > > > > > Best greetings > > > > > > G?nter > > > > > > > > > > >>_______________________________________________________________________________________________ > _____________________________________________________ > > _ > > > Von: subexp-daq im Auftrag von H?kan T Johansson > > > > Gesendet: Dienstag, 9. Januar 2024 16:05:19 > > > 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, > > > > > > yes, please download the latest drasi.? That should fix the broken link. > > > > > > ALso, compile it on the PC first.? That will download the file, and then > > > the RIO compile will use that. > > > > > > I'd suggest to also update trloii before compiling!? Same trick there > > > might be helpful, i.e. compile on PC first.? Nothing to download, but some > > > generated files are quicker made on a PC. > > > > > > Cheers, > > > H?kan > > > > > > > > > On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > > > > > > > > > > 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 im Auftrag von H?kan T Johansson > > > > > 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 im Auftrag von Weber, Guenter Dr. > > > > > > 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 im Auftrag von Hans Toshihide > T?rnqvist > > > > > 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/b > in_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/b > in_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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From g.weber at hi-jena.gsi.de Tue Jan 9 22:45:24 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 9 Jan 2024 21:45:24 +0000 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: <1fc55deb-35fd-a0f1-cb56-c550e36feba8@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <123f76b2-bbdf-4188-a926-bd0966901336@chalmers.se> <2ea9c4c3-29ab-4569-aba1-30633b63608f@chalmers.se> <2cb1927f-8c64-43f2-a0cb-bf501a5808b3@chalmers.se> , <08028286-f61a-475d-ab01-b579141e5762@chalmers.se>, <48cae3a127fe4666901bc49eacf69d3b@hi-jena.gsi.de> <81f59eb1bbc344bf8cf703c150a1796b@hi-jena.gsi.de>, <128bdcbcdaad41b4be10ecae34715fb8@hi-jena.gsi.de>, <8256e7a9-82b9-e8b9-2687-ef6b3156df57@chalmers.se> , <14184882-f21c-dbce-fa42-6d17901d086a@chalmers.se> , <6891db86-9945-74ce-5872-9f84afa855b7@chalmers.se> , <1fc55deb-35fd-a0f1-cb56-c550e36feba8@chalmers.se> Message-ID: Dear H?kan, in the old directory I found "trloii_firmwares_c44f109.tar.gz". I should now delete the new TRLOII folder and replace it with the extracted archive, correct? Then just typing in "find_firmwares.pl" (or should it be "./find_firmwares.pl"?) in TRLOCTRL will, hopefully, do the trick, right? With VULOM address you mean the physical address that is set on the module? No, I do not know it. But tomorrow I can find out, of course. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Dienstag, 9. Januar 2024 22: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 My mistake: in a new trloii directory, after cd trloctrl you need to do find_firmwares.pl before the make _build however, I suspect we'll then run into the next issue, namely that the TRLO II firmware that you have likely is old. I do not see d96ffc88 in the list of current ones http://fy.chalmers.se/~f96hajo/trloii/firmwares.html -- This is not needed, but might help to figure that: If you can run (new or old) $TRLOII_FLASH or just from trloii/ dir: bin/vulomflash --addr=X --readprogs where X needs to be the address of the vulom module, that would give a list. Do you know what the vulom address is? -- Hmmmm. To update that means to also update what runs on the VULOM4, which makes it more messy to go back-and-forth. Or to run another version of it but without changing its default. Doable, but I think we are getting a few too many loose variables here right now. I think it would be best if you for the moment copy over the old trloii/ directory and try to recompile that one in the new location. -- The other way is if you have a trloii_firmwares_XXX.tar.gz file, e.g. in the (old) trloii/ directory, and unp?ack that in the new trloii/, then find_firmwares.pl should also find those (old) headers, and hopefully produce a line also with d374466d. -- Sorry that this is becoming a bit too convoluted to be really pleasant. Cheers, H?kan On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > Ok, after this fix, the compilation in TRLOII finshes without problems. > > > But in TRLOCTRL we have the following problem (as already noticed when I tried to compile on the > PC). > > > RIO4-MCAL-2 mbsdaq > pwd > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl > RIO4-MCAL-2 mbsdaq > make fw_d96ffc88_trlo_build > cat: firmwaredirs: No such file or directory > make -C fw_d96ffc88_trlo -f ../trlolib/Makefile \ > TRLOBASENAME=`cat fw_d96ffc88_trlo/trlobasename` FILTERSRC=1 > cat: fw_d96ffc88_trlo/trlobasename: No such file or directory > make: *** fw_d96ffc88_trlo: No such file or directory. Stop. > make: *** [fw_d96ffc88_trlo_build] Error 2 > RIO4-MCAL-2 mbsdaq > make fw_d374466d_tridi_build > cat: firmwaredirs: No such file or directory > make -C fw_d374466d_tridi -f ../trlolib/Makefile \ > TRLOBASENAME=`cat fw_d374466d_tridi/trlobasename` FILTERSRC=1 > cat: fw_d374466d_tridi/trlobasename: No such file or directory > make: *** fw_d374466d_tridi: No such file or directory. Stop. > make: *** [fw_d374466d_tridi_build] Error 2 > > After this I went ahead to DRASI and there the compilation finished without error. > > Thus, if the issue with TRLOCTRL could be solved, maybe our DAQ is good to go ? > > > > Best greetings > G?nter > > > > _________________________________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan T Johansson > > Gesendet: Dienstag, 9. Januar 2024 16:59:07 > 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 > > Quick-fix II: comment out trigalign_dir from the targets in trloii/Makefile: > > all: trimictrl_dir flash_dir \ > proglinks # trigalign_dir > > Cheers, > H?kan > > > > On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > > > > Unfortunately, "make -k" ends with the same result: > > > > > > ... > > > > make[1]: Entering directory > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > > CC bld_ppc-linux_4.2.2/align_analyse.o > > CC bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_parser.o > > gen_ppc-linux_4.2.2/align_parser.c:19: warning: 'align_growstack' declared 'static' but never > defined > > CC bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o > > align_lexer.l: In function 'align_lex': > > align_lexer.l:28: error: 'align_lval' undeclared (first use in this function) > > align_lexer.l:28: error: (Each undeclared identifier is reported only once > > align_lexer.l:28: error: for each function it appears in.) > > align_lexer.l:29: error: 'INTEGER' undeclared (first use in this function) > > align_lexer.l:32: error: 'START' undeclared (first use in this function) > > align_lexer.l:33: error: 'END' undeclared (first use in this function) > > align_lexer.l:34: error: 'CH' undeclared (first use in this function) > > align_lexer.l:35: error: 'DELAY' undeclared (first use in this function) > > make[1]: *** [bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o] Error 1 > > make[1]: Target `all' not remade because of errors. > > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > > make: *** [trigalign_dir] Error 2 > > make: Target `all' not remade because of errors. > > > > > >________________________________________________________________________________________________ > _____________________________________________________ > > Von: subexp-daq im Auftrag von H?kan T Johansson > > > Gesendet: Dienstag, 9. Januar 2024 16:36:28 > > 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 > > > > Quick-fix for the trigalign: > > > > try compile with 'make -k', which tries to continue with other things. > > the trigger aligment you likely do not use, so we can solve that more slowly. > > > > You are not creating problems, we want/need to know what does not work so > > it can get fixed :) > > > > Cheers, > > H?kan > > > > > > > > On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > > > > > > > Dear friends, > > > > > > > > > what I now did: > > > > > > > > > 1) Deleting the folders of DRASI, TRLOII, and R3BFUSER > > > > > > 2) Downloading the most recent versions from Gitlab > > > > > > 3) Executing MAKE CLEAN, followed by MAKE in the folders TRLOII and DRASI on the PC (make > fw_d96ffc88_trlo_build failed on the PC, make > > > fw_d374466d_tridi_build I did not try) > > > > > > 4) Executing MAKE CLEAN, followed by MAKE on the RIO in the folder TRLOII. And there a new > problem shows up: > > > > > > > > > make[1]: Entering directory > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > > > CC bld_ppc-linux_4.2.2/align_analyse.o > > > CC bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_parser.o > > > gen_ppc-linux_4.2.2/align_parser.c:19: warning: 'align_growstack' declared 'static' but never > defined > > > CC bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o > > > align_lexer.l: In function 'align_lex': > > > align_lexer.l:28: error: 'align_lval' undeclared (first use in this function) > > > align_lexer.l:28: error: (Each undeclared identifier is reported only once > > > align_lexer.l:28: error: for each function it appears in.) > > > align_lexer.l:29: error: 'INTEGER' undeclared (first use in this function) > > > align_lexer.l:32: error: 'START' undeclared (first use in this function) > > > align_lexer.l:33: error: 'END' undeclared (first use in this function) > > > align_lexer.l:34: error: 'CH' undeclared (first use in this function) > > > align_lexer.l:35: error: 'DELAY' undeclared (first use in this function) > > > make[1]: *** [bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o] Error 1 > > > make[1]: Leaving directory > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > > > make: *** [trigalign_dir] Error 2 > > > > > > When I was compiling TRLOII with the old version, this error did not occur. > > > > > > > > > > > > I am really sorry for causing so much trouble ? > > > > > > > > > > > > > > > Best greetings > > > > > > G?nter > > > > > > > > > > >>_______________________________________________________________________________________________ > _____________________________________________________ > > _ > > > Von: subexp-daq im Auftrag von H?kan T Johansson > > > > Gesendet: Dienstag, 9. Januar 2024 16:05:19 > > > 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, > > > > > > yes, please download the latest drasi. That should fix the broken link. > > > > > > ALso, compile it on the PC first. That will download the file, and then > > > the RIO compile will use that. > > > > > > I'd suggest to also update trloii before compiling! Same trick there > > > might be helpful, i.e. compile on PC first. Nothing to download, but some > > > generated files are quicker made on a PC. > > > > > > Cheers, > > > H?kan > > > > > > > > > On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > > > > > > > > > > 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 im Auftrag von H?kan T Johansson > > > > > 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 im Auftrag von Weber, Guenter Dr. > > > > > > 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 im Auftrag von Hans Toshihide > T?rnqvist > > > > > 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/b > in_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/b > in_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: From f96hajo at chalmers.se Tue Jan 9 23:21:08 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Tue, 9 Jan 2024 23:21:08 +0100 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <2ea9c4c3-29ab-4569-aba1-30633b63608f@chalmers.se> <2cb1927f-8c64-43f2-a0cb-bf501a5808b3@chalmers.se> , <08028286-f61a-475d-ab01-b579141e5762@chalmers.se>, <48cae3a127fe4666901bc49eacf69d3b@hi-jena.gsi.de> <81f59eb1bbc344bf8cf703c150a1796b@hi-jena.gsi.de>, <128bdcbcdaad41b4be10ecae34715fb8@hi-jena.gsi.de>, <8256e7a9-82b9-e8b9-2687-ef6b3156df57@chalmers.se> , <14184882-f21c-dbce-fa42-6d17901d086a@chalmers.se> , <6891db86-9945-74ce-5872-9f84afa855b7@chalmers.se> , <1fc55deb-35fd-a0f1-cb56-c550e36feba8@chalmers.se> Message-ID: <3bf5e24e-a8e4-242d-09f5-4be3198f65d2@chalmers.se> On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > Dear H?kan, > > > in the old directory I found "trloii_firmwares_c44f109.tar.gz". > > > I should?now delete the new TRLOII folder and replace it with the extracted archive, correct? No, extract the archive in the trloii/ folder. > Then just typing in "find_firmwares.pl" (or should it be "./find_firmwares.pl"?) in TRLOCTRL > will, hopefully, do the trick, right? Yes, "./find_firmwares.pl" in trloii/trloctrl/ And then we cross fingers that the newer code compiles with the older headers. (Likely, but no guarantee.) If not, then get the older trloii/ directory which presumably has the firmwares already unpacked in it. > With VULOM address you mean the physical address that is set on the module? No, I do not know it. > But tomorrow I can find out, of course. Or likely it is in some script somewhere. grep -r "--addr=" might reveal it :-) Cheers, H?kan > > > > > > Best greetings > > G?nter > > > > > _________________________________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan T Johansson > > Gesendet: Dienstag, 9. Januar 2024 22: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 ? > > My mistake: > > in a new trloii directory, > > after > > ? cd trloctrl > > you need to do > > ? find_firmwares.pl > > before the make _build > > however, I suspect we'll then run into the next issue, namely that the > TRLO II firmware that you have likely is old.? I do not see d96ffc88 in > the list of current ones > > http://fy.chalmers.se/~f96hajo/trloii/firmwares.html > > -- > > This is not needed, but might help to figure that: > > If you can run (new or old) $TRLOII_FLASH or just from trloii/ dir: > > ? bin/vulomflash --addr=X --readprogs > > where X needs to be the address of the vulom module, that would give a > list.? Do you know what the vulom address is? > > -- > > Hmmmm.? To update that means to also update what runs on the VULOM4, which > makes it more messy to go back-and-forth.? Or to run another version of it > but without changing its default.? Doable, but I think we are getting a > few too many loose variables here right now. > > I think it would be best if you for the moment copy over the old trloii/ > directory and try to recompile that one in the new location. > > -- > > The other way is if you have a > > ? trloii_firmwares_XXX.tar.gz > > file, e.g. in the (old) trloii/ directory, and unp?ack that in the new > trloii/, then find_firmwares.pl should also find those (old) headers, and > hopefully produce a line also with d374466d. > > -- > > Sorry that this is becoming a bit too convoluted to be really pleasant. > > Cheers, > H?kan > > > > > On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > > > > Ok, after this fix, the?compilation in TRLOII finshes without problems. > > > > > > But in TRLOCTRL we have the following problem (as?already noticed?when I tried to compile on > the > > PC). > > > > > > RIO4-MCAL-2 mbsdaq > pwd > > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl > > RIO4-MCAL-2 mbsdaq > make fw_d96ffc88_trlo_build > > cat: firmwaredirs: No such file or directory > > make? -C fw_d96ffc88_trlo -f ../trlolib/Makefile \ > > ? ? ? ? ? TRLOBASENAME=`cat fw_d96ffc88_trlo/trlobasename` FILTERSRC=1 > > cat: fw_d96ffc88_trlo/trlobasename: No such file or directory > > make: *** fw_d96ffc88_trlo: No such file or directory.? Stop. > > make: *** [fw_d96ffc88_trlo_build] Error 2 > > RIO4-MCAL-2 mbsdaq > make fw_d374466d_tridi_build > > cat: firmwaredirs: No such file or directory > > make? -C fw_d374466d_tridi -f ../trlolib/Makefile \ > > ? ? ? ? ? TRLOBASENAME=`cat fw_d374466d_tridi/trlobasename` FILTERSRC=1 > > cat: fw_d374466d_tridi/trlobasename: No such file or directory > > make: *** fw_d374466d_tridi: No such file or directory.? Stop. > > make: *** [fw_d374466d_tridi_build] Error 2 > > > > After this I went ahead to DRASI and there the compilation finished without error. > > > > Thus, if the issue with?TRLOCTRL could be solved, maybe our DAQ is good to go ? > > > > > > > > Best greetings > > G?nter > > > > > > > >________________________________________________________________________________________________ > _ > > Von: subexp-daq im Auftrag von H?kan T Johansson > > > > Gesendet: Dienstag, 9. Januar 2024 16:59:07 > > 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 ? > > > > Quick-fix II:? comment out trigalign_dir from the targets in trloii/Makefile: > > > > all: trimictrl_dir flash_dir \ > > ???????? proglinks # trigalign_dir > > > > Cheers, > > H?kan > > > > > > > > On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > > > > > > > Unfortunately, "make -k" ends with the same result: > > > > > > > > > ... > > > > > > make[1]: Entering directory > > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > > > ?? CC??? bld_ppc-linux_4.2.2/align_analyse.o > > > ?? CC??? bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_parser.o > > > gen_ppc-linux_4.2.2/align_parser.c:19: warning: 'align_growstack' declared 'static' but never > > defined > > > ?? CC??? bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o > > > align_lexer.l: In function 'align_lex': > > > align_lexer.l:28: error: 'align_lval' undeclared (first use in this function) > > > align_lexer.l:28: error: (Each undeclared identifier is reported only once > > > align_lexer.l:28: error: for each function it appears in.) > > > align_lexer.l:29: error: 'INTEGER' undeclared (first use in this function) > > > align_lexer.l:32: error: 'START' undeclared (first use in this function) > > > align_lexer.l:33: error: 'END' undeclared (first use in this function) > > > align_lexer.l:34: error: 'CH' undeclared (first use in this function) > > > align_lexer.l:35: error: 'DELAY' undeclared (first use in this function) > > > make[1]: *** [bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o] Error 1 > > > make[1]: Target `all' not remade because of errors. > > > make[1]: Leaving directory > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > > > make: *** [trigalign_dir] Error 2 > > > make: Target `all' not remade because of errors. > > > > > > > >>_______________________________________________________________________________________________ > _ > > _____________________________________________________ > > > Von: subexp-daq im Auftrag von H?kan T Johansson > > > > > Gesendet: Dienstag, 9. Januar 2024 16:36:28 > > > 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 ? > > > > > > Quick-fix for the trigalign: > > > > > > try compile with 'make -k', which tries to continue with other things. > > > the trigger aligment you likely do not use, so we can solve that more slowly. > > > > > > You are not creating problems, we want/need to know what does not work so > > > it can get fixed :) > > > > > > Cheers, > > > H?kan > > > > > > > > > > > > On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > > > > > > > > > > Dear friends, > > > > > > > > > > > > what I now did: > > > > > > > > > > > > 1) Deleting the folders of DRASI, TRLOII, and R3BFUSER > > > > > > > > 2) Downloading the most recent versions from Gitlab > > > > > > > > 3) Executing MAKE CLEAN, followed by MAKE in the folders TRLOII and DRASI on the PC (make > > fw_d96ffc88_trlo_build failed on the PC, make > > > > fw_d374466d_tridi_build I did not try) > > > > > > > > 4) Executing MAKE CLEAN, followed by MAKE on the RIO in the folder TRLOII. And there a new > > problem shows up: > > > > > > > > > > > > make[1]: Entering directory > > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > > > > ?? CC??? bld_ppc-linux_4.2.2/align_analyse.o > > > > ?? CC??? bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_parser.o > > > > gen_ppc-linux_4.2.2/align_parser.c:19: warning: 'align_growstack' declared 'static' but > never > > defined > > > > ?? CC??? bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o > > > > align_lexer.l: In function 'align_lex': > > > > align_lexer.l:28: error: 'align_lval' undeclared (first use in this function) > > > > align_lexer.l:28: error: (Each undeclared identifier is reported only once > > > > align_lexer.l:28: error: for each function it appears in.) > > > > align_lexer.l:29: error: 'INTEGER' undeclared (first use in this function) > > > > align_lexer.l:32: error: 'START' undeclared (first use in this function) > > > > align_lexer.l:33: error: 'END' undeclared (first use in this function) > > > > align_lexer.l:34: error: 'CH' undeclared (first use in this function) > > > > align_lexer.l:35: error: 'DELAY' undeclared (first use in this function) > > > > make[1]: *** [bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o] Error 1 > > > > make[1]: Leaving directory > > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > > > > make: *** [trigalign_dir] Error 2 > > > > > > > > When I was compiling TRLOII with the old version, this error did not occur. > > > > > > > > > > > > > > > > I am really sorry for causing so much trouble ? > > > > > > > > > > > > > > > > > > > > Best greetings > > > > > > > > G?nter > > > > > > > > > > > > > >>>______________________________________________________________________________________________ > _ > > _____________________________________________________ > > > _ > > > > Von: subexp-daq im Auftrag von H?kan T Johansson > > > > > > Gesendet: Dienstag, 9. Januar 2024 16:05:19 > > > > 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, > > > > > > > > yes, please download the latest drasi.? That should fix the broken link. > > > > > > > > ALso, compile it on the PC first.? That will download the file, and then > > > > the RIO compile will use that. > > > > > > > > I'd suggest to also update trloii before compiling!? Same trick there > > > > might be helpful, i.e. compile on PC first.? Nothing to download, but some > > > > generated files are quicker made on a PC. > > > > > > > > Cheers, > > > > H?kan > > > > > > > > > > > > On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > > > > > > > > > > > > > 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 im Auftrag von H?kan T Johansson > > > > > > > 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 im Auftrag von Weber, Guenter > Dr. > > > > > > > > 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 im Auftrag von Hans Toshihide > > T?rnqvist > > > > > > 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/ > b > > in_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/ > b > > in_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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From g.weber at hi-jena.gsi.de Wed Jan 10 10:30:35 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Wed, 10 Jan 2024 09:30:35 +0000 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: <3bf5e24e-a8e4-242d-09f5-4be3198f65d2@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <2ea9c4c3-29ab-4569-aba1-30633b63608f@chalmers.se> <2cb1927f-8c64-43f2-a0cb-bf501a5808b3@chalmers.se> , <08028286-f61a-475d-ab01-b579141e5762@chalmers.se>, <48cae3a127fe4666901bc49eacf69d3b@hi-jena.gsi.de> <81f59eb1bbc344bf8cf703c150a1796b@hi-jena.gsi.de>, <128bdcbcdaad41b4be10ecae34715fb8@hi-jena.gsi.de>, <8256e7a9-82b9-e8b9-2687-ef6b3156df57@chalmers.se> , <14184882-f21c-dbce-fa42-6d17901d086a@chalmers.se> , <6891db86-9945-74ce-5872-9f84afa855b7@chalmers.se> , <1fc55deb-35fd-a0f1-cb56-c550e36feba8@chalmers.se> , <3bf5e24e-a8e4-242d-09f5-4be3198f65d2@chalmers.se> Message-ID: <14e1aab1db454f5da272442151f66d56@hi-jena.gsi.de> Hi folks, the old "./find_firmware.pl" was working. This is the output: a1729cda ../ver/rimfaxe0_trlo/rfx0_defs.h 0866c243 ../ver/rimfaxe1_trlo/rfx1_defs.h 5e8f5ef4 ../ver/tridi1_trlo/tridi_defs.h 6e4ba1a9 ../ver/vulom4_trlo/trlo_defs.h 68f8955e ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h af33ed35 ../ver/vulom4_trlo_big/trlo_big_defs.h 1409285e ../ver/vulom4b_trlo/trlo_defs.h d374466d ../fw/tridi1_trlo/tridi_defs.h d96ffc88 ../fw/vulom4_trlo/trlo_defs.h 5b298165 ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h 6f28c0f8 ../fw/vulom4_trlo_big/trlo_big_defs.h fa5020ea ../fw/vulom4_trlo_led/trlo_defs.h 426cb99c ../fw/vulom4b_trlo/trlo_defs.h MKDIR fw_a1729cda_rfx0 # ../ver/rimfaxe0_trlo/rfx0_defs.h SYMLINK fw_a1729cda_rfx0/rfx0_defs.h -> ../../ver/rimfaxe0_trlo/rfx0_defs.h MKDIR fw_0866c243_rfx1 # ../ver/rimfaxe1_trlo/rfx1_defs.h SYMLINK fw_0866c243_rfx1/rfx1_defs.h -> ../../ver/rimfaxe1_trlo/rfx1_defs.h MKDIR fw_5e8f5ef4_tridi # ../ver/tridi1_trlo/tridi_defs.h SYMLINK fw_5e8f5ef4_tridi/tridi_defs.h -> ../../ver/tridi1_trlo/tridi_defs.h MKDIR fw_6e4ba1a9_trlo # ../ver/vulom4_trlo/trlo_defs.h SYMLINK fw_6e4ba1a9_trlo/trlo_defs.h -> ../../ver/vulom4_trlo/trlo_defs.h SYMLINK fw_1409285e_trlo -> fw_6e4ba1a9_trlo MKDIR fw_68f8955e_trlo_all_in # ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h SYMLINK fw_68f8955e_trlo_all_in/trlo_all_in_defs.h -> ../../ver/vulom4_trlo_all_in/trlo_all_in_defs.h MKDIR fw_af33ed35_trlo_big # ../ver/vulom4_trlo_big/trlo_big_defs.h SYMLINK fw_af33ed35_trlo_big/trlo_big_defs.h -> ../../ver/vulom4_trlo_big/trlo_big_defs.h MKDIR fw_d374466d_tridi # ../fw/tridi1_trlo/tridi_defs.h SYMLINK fw_d374466d_tridi/tridi_defs.h -> ../../fw/tridi1_trlo/tridi_defs.h MKDIR fw_d96ffc88_trlo # ../fw/vulom4_trlo/trlo_defs.h SYMLINK fw_d96ffc88_trlo/trlo_defs.h -> ../../fw/vulom4_trlo/trlo_defs.h SYMLINK fw_426cb99c_trlo -> fw_d96ffc88_trlo SYMLINK fw_fa5020ea_trlo -> fw_d96ffc88_trlo MKDIR fw_5b298165_trlo_all_in # ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h SYMLINK fw_5b298165_trlo_all_in/trlo_all_in_defs.h -> ../../fw/vulom4_trlo_all_in/trlo_all_in_defs.h MKDIR fw_6f28c0f8_trlo_big # ../fw/vulom4_trlo_big/trlo_big_defs.h SYMLINK fw_6f28c0f8_trlo_big/trlo_big_defs.h -> ../../fw/vulom4_trlo_big/trlo_big_defs.h However, the compilation did end with an error: make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo' CC bld_ppc-linux_4.2.2/src/trlo_check_version.o CC bld_ppc-linux_4.2.2/src/trlo_functions.o ../trlolib/src/trlo_functions.c: In function 'trlo_clear_config': ../trlolib/src/trlo_functions.c:144: error: 'trlo_setup_map' has no member named 'sync_check_start_mux' ../trlolib/src/trlo_functions.c:146: error: 'trlo_setup_map' has no member named 'sync_check_stop_mux' ../trlolib/src/trlo_functions.c: In function 'trlo_print_config': ../trlolib/src/trlo_functions.c:825: error: 'trlo_setup_map' has no member named 'sync_check_start_mux' ../trlolib/src/trlo_functions.c:829: error: 'trlo_setup_map' has no member named 'sync_check_stop_mux' ../trlolib/src/trlo_functions.c: In function 'trlo_print_trig_status': ../trlolib/src/trlo_functions.c:1155: error: 'trlo_output_map' has no member named 'trig_sync_check' make[1]: *** [bld_ppc-linux_4.2.2/src/trlo_functions.o] Error 1 make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo' make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi' CC bld_ppc-linux_4.2.2/src/tridi_check_version.o CC bld_ppc-linux_4.2.2/src/tridi_functions.o ../trlolib/src/trlo_functions.c: In function 'tridi_clear_config': ../trlolib/src/trlo_functions.c:144: error: 'tridi_setup_map' has no member named 'sync_check_start_mux' ../trlolib/src/trlo_functions.c:146: error: 'tridi_setup_map' has no member named 'sync_check_stop_mux' ../trlolib/src/trlo_functions.c: In function 'tridi_print_config': ../trlolib/src/trlo_functions.c:825: error: 'tridi_setup_map' has no member named 'sync_check_start_mux' ../trlolib/src/trlo_functions.c:829: error: 'tridi_setup_map' has no member named 'sync_check_stop_mux' ../trlolib/src/trlo_functions.c: In function 'tridi_print_trig_status': ../trlolib/src/trlo_functions.c:1155: error: 'tridi_output_map' has no member named 'trig_sync_check' make[1]: *** [bld_ppc-linux_4.2.2/src/tridi_functions.o] Error 1 make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi' make: *** [fw_d374466d_tridi_build] Error 2 The fallback option is now to delete the new TRLOII folder and replace it with old one and then repeat the following steps? cd trloii make clean make cd trloctrl make fw_d96ffc88_trlo_build make fw_d374466d_tridi_build Is this correct? I also looked for the "--addr=" and this is the result: nurdlib/tools/rwdump.c:52: fprintf(str, " -a, --addr=address VME hex address, e.g. " ?bereinstimmungen in Bin?rdatei nurdlib/build_cc_ppc-linux_4.2.2_debug/tools/rwdump.o ?bereinstimmungen in Bin?rdatei nurdlib/build_cc_ppc-linux_4.2.2_debug/tools/rwdump ?bereinstimmungen in Bin?rdatei nurdlib/build_cc_ppc-linux_4.2.2_debug/nurdctrl ?bereinstimmungen in Bin?rdatei nurdlib/build_cc_ppc-linux_4.2.2_debug/ctrl/nurdctrl.o nurdlib/ctrl/nurdctrl.c:214:" -a, --addr=host Talk to given host, default=localhost:" ?bereinstimmungen in Bin?rdatei trloii/flash/bin_ppc-linux_4.2.2/vulomflash trloii/flash/vulomflash.c:869: printf ("Usage %s --addr=A [command] [file.rbt[,comment.txt]]\n", argv0); trloii/flash/vulomflash.c:871: printf (" --addr=A Module address (HEX).\n"); trloii/flash/vulomflash.c:964: else if (strncmp(argv[i],"--addr=",7) == 0) ?bereinstimmungen in Bin?rdatei trloii/flash/bld_ppc-linux_4.2.2/vulomflash.o ?bereinstimmungen in Bin?rdatei trloii/flash/bin_x86_64-linux-gnu_7/vulomflash ?bereinstimmungen in Bin?rdatei trloii/flash/bld_x86_64-linux-gnu_7/vulomflash.o trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_ctrl.c:41: printf (" --addr=HEX Module address (HEX=dummy for dummy).\n"); trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_ctrl.c:201: if (argc > iarg && strncmp(argv[iarg],"--addr=",7) == 0) trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:1532: if (argc > iarg && strncmp(argv[iarg],"--addr=",7) == 0) trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2202:../flash/vulomflash --addr=2 --restart=4 trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2203:trlolib/trlo_ctrl --addr=2 --clear-setup trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2204:trlolib/trlo_ctrl --addr=2 "DEADTIME_IN(1)=TRIMI_TDT" trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2205:trlolib/trlo_ctrl --addr=2 fast_busy_len=100ns trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2206:trlolib/trlo_ctrl --addr=2 --print-config trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2208:../trimictrl/trimictrl_Linux_ppc --addr=2 encoded_in=TRLO_ENCODED_TRIG trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2209:../trimictrl/trimictrl_Linux_ppc --addr=2 --status trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2211:../trimictrl/trimictrl_RIO4 --addr=2 encoded_in=TRLO_ENCODED_TRIG trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2212:../trimictrl/trimictrl_RIO4 --addr=2 "serial_out=ECL_OUT(1)" trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2213:../trimictrl/trimictrl_RIO4 --addr=2 "dt_in=ECL_IN(1)" trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2214:../trimictrl/trimictrl_RIO4 --addr=2 "fast_dt=40" trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2215:../trimictrl/trimictrl_RIO4 --addr=2 "dt_out=ECL_OUT(3)" trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2216:../trimictrl/trimictrl_RIO4 --addr=2 "serial_in=ECL_IN(3)" trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2217:../trimictrl/trimictrl_RIO4 --addr=2 "link_period=8" trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2218:../trimictrl/trimictrl_RIO4 --addr=2 --status trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2223:../flash/vulomflash --addr=3 --restart=4 trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2224:trlolib/trlo_ctrl --addr=3 --clear-setup trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2225:trlolib/trlo_ctrl --addr=3 "DEADTIME_IN(1)=TRIMI_TDT" trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2226:trlolib/trlo_ctrl --addr=3 fast_busy_len=100ns trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2227:trlolib/trlo_ctrl --addr=3 --print-config trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2229:../trimictrl/trimictrl_Linux_ppc --addr=3 encoded_in=TRLO_ENCODED_TRIG trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2230:../trimictrl/trimictrl_Linux_ppc --addr=3 "dt_out=ECL_OUT(1)" trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2231:../trimictrl/trimictrl_Linux_ppc --addr=3 "serial_in=ECL_IN(1)" trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2232:../trimictrl/trimictrl_Linux_ppc --addr=3 "serial_out=ECL_OUT(3)" trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2233:../trimictrl/trimictrl_Linux_ppc --addr=3 "dt_in=ECL_IN(3)" trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2234:../trimictrl/trimictrl_Linux_ppc --addr=3 "fast_dt=40" trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2235:../trimictrl/trimictrl_Linux_ppc --addr=3 "link_period=8" trloii/trloctrl/fw_d96ffc88_trlo/src/trlo_trimi_test.c:2236:../trimictrl/trimictrl_Linux_ppc --addr=3 --status trloii/trloctrl/trlolib/src/trlo_ctrl.c:40: printf (" --addr=HEX Module address (HEX=dummy for dummy).\n"); trloii/trloctrl/trlolib/src/trlo_ctrl.c:200: if (argc > iarg && strncmp(argv[iarg],"--addr=",7) == 0) trloii/trloctrl/trlolib/src/trlo_trimi_test.c:1531: if (argc > iarg && strncmp(argv[iarg],"--addr=",7) == 0) trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2201:../flash/vulomflash --addr=2 --restart=4 trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2202:trlolib/trlo_ctrl --addr=2 --clear-setup trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2203:trlolib/trlo_ctrl --addr=2 "DEADTIME_IN(1)=TRIMI_TDT" trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2204:trlolib/trlo_ctrl --addr=2 fast_busy_len=100ns trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2205:trlolib/trlo_ctrl --addr=2 --print-config trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2207:../trimictrl/trimictrl_Linux_ppc --addr=2 encoded_in=TRLO_ENCODED_TRIG trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2208:../trimictrl/trimictrl_Linux_ppc --addr=2 --status trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2210:../trimictrl/trimictrl_RIO4 --addr=2 encoded_in=TRLO_ENCODED_TRIG trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2211:../trimictrl/trimictrl_RIO4 --addr=2 "serial_out=ECL_OUT(1)" trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2212:../trimictrl/trimictrl_RIO4 --addr=2 "dt_in=ECL_IN(1)" trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2213:../trimictrl/trimictrl_RIO4 --addr=2 "fast_dt=40" trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2214:../trimictrl/trimictrl_RIO4 --addr=2 "dt_out=ECL_OUT(3)" trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2215:../trimictrl/trimictrl_RIO4 --addr=2 "serial_in=ECL_IN(3)" trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2216:../trimictrl/trimictrl_RIO4 --addr=2 "link_period=8" trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2217:../trimictrl/trimictrl_RIO4 --addr=2 --status trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2222:../flash/vulomflash --addr=3 --restart=4 trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2223:trlolib/trlo_ctrl --addr=3 --clear-setup trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2224:trlolib/trlo_ctrl --addr=3 "DEADTIME_IN(1)=TRIMI_TDT" trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2225:trlolib/trlo_ctrl --addr=3 fast_busy_len=100ns trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2226:trlolib/trlo_ctrl --addr=3 --print-config trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2228:../trimictrl/trimictrl_Linux_ppc --addr=3 encoded_in=TRLO_ENCODED_TRIG trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2229:../trimictrl/trimictrl_Linux_ppc --addr=3 "dt_out=ECL_OUT(1)" trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2230:../trimictrl/trimictrl_Linux_ppc --addr=3 "serial_in=ECL_IN(1)" trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2231:../trimictrl/trimictrl_Linux_ppc --addr=3 "serial_out=ECL_OUT(3)" trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2232:../trimictrl/trimictrl_Linux_ppc --addr=3 "dt_in=ECL_IN(3)" trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2233:../trimictrl/trimictrl_Linux_ppc --addr=3 "fast_dt=40" trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2234:../trimictrl/trimictrl_Linux_ppc --addr=3 "link_period=8" trloii/trloctrl/trlolib/src/trlo_trimi_test.c:2235:../trimictrl/trimictrl_Linux_ppc --addr=3 --status trloii/trloctrl/examples/vulom_prienc.trlo:20: * trlo_ctrl --addr=X --clear-setup --config=vulom_prienc.trlo "basic" trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:1532: if (argc > iarg && strncmp(argv[iarg],"--addr=",7) == 0) trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2202:../flash/vulomflash --addr=2 --restart=4 trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2203:trlolib/tridi_ctrl --addr=2 --clear-setup trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2204:trlolib/tridi_ctrl --addr=2 "DEADTIME_IN(1)=TRIMI_TDT" trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2205:trlolib/tridi_ctrl --addr=2 fast_busy_len=100ns trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2206:trlolib/tridi_ctrl --addr=2 --print-config trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2208:../trimictrl/trimictrl_Linux_ppc --addr=2 encoded_in=TRIDI_ENCODED_TRIG trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2209:../trimictrl/trimictrl_Linux_ppc --addr=2 --status trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2211:../trimictrl/trimictrl_RIO4 --addr=2 encoded_in=TRIDI_ENCODED_TRIG trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2212:../trimictrl/trimictrl_RIO4 --addr=2 "serial_out=ECL_OUT(1)" trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2213:../trimictrl/trimictrl_RIO4 --addr=2 "dt_in=ECL_IN(1)" trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2214:../trimictrl/trimictrl_RIO4 --addr=2 "fast_dt=40" trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2215:../trimictrl/trimictrl_RIO4 --addr=2 "dt_out=ECL_OUT(3)" trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2216:../trimictrl/trimictrl_RIO4 --addr=2 "serial_in=ECL_IN(3)" trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2217:../trimictrl/trimictrl_RIO4 --addr=2 "link_period=8" trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2218:../trimictrl/trimictrl_RIO4 --addr=2 --status trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2223:../flash/vulomflash --addr=3 --restart=4 trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2224:trlolib/tridi_ctrl --addr=3 --clear-setup trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2225:trlolib/tridi_ctrl --addr=3 "DEADTIME_IN(1)=TRIMI_TDT" trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2226:trlolib/tridi_ctrl --addr=3 fast_busy_len=100ns trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2227:trlolib/tridi_ctrl --addr=3 --print-config trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2208:../trimictrl/trimictrl_Linux_ppc --addr=2 encoded_in=TRIDI_ENCODED_TRIG trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2209:../trimictrl/trimictrl_Linux_ppc --addr=2 --status trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2211:../trimictrl/trimictrl_RIO4 --addr=2 encoded_in=TRIDI_ENCODED_TRIG trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2212:../trimictrl/trimictrl_RIO4 --addr=2 "serial_out=ECL_OUT(1)" trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2213:../trimictrl/trimictrl_RIO4 --addr=2 "dt_in=ECL_IN(1)" trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2214:../trimictrl/trimictrl_RIO4 --addr=2 "fast_dt=40" trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2215:../trimictrl/trimictrl_RIO4 --addr=2 "dt_out=ECL_OUT(3)" trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2216:../trimictrl/trimictrl_RIO4 --addr=2 "serial_in=ECL_IN(3)" trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2217:../trimictrl/trimictrl_RIO4 --addr=2 "link_period=8" trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2218:../trimictrl/trimictrl_RIO4 --addr=2 --status trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2223:../flash/vulomflash --addr=3 --restart=4 trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2224:trlolib/tridi_ctrl --addr=3 --clear-setup trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2225:trlolib/tridi_ctrl --addr=3 "DEADTIME_IN(1)=TRIMI_TDT" trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2226:trlolib/tridi_ctrl --addr=3 fast_busy_len=100ns trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2227:trlolib/tridi_ctrl --addr=3 --print-config trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2229:../trimictrl/trimictrl_Linux_ppc --addr=3 encoded_in=TRIDI_ENCODED_TRIG trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2230:../trimictrl/trimictrl_Linux_ppc --addr=3 "dt_out=ECL_OUT(1)" trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2231:../trimictrl/trimictrl_Linux_ppc --addr=3 "serial_in=ECL_IN(1)" trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2232:../trimictrl/trimictrl_Linux_ppc --addr=3 "serial_out=ECL_OUT(3)" trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2233:../trimictrl/trimictrl_Linux_ppc --addr=3 "dt_in=ECL_IN(3)" trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2234:../trimictrl/trimictrl_Linux_ppc --addr=3 "fast_dt=40" trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2235:../trimictrl/trimictrl_Linux_ppc --addr=3 "link_period=8" trloii/trloctrl/fw_d374466d_tridi/src/tridi_trimi_test.c:2236:../trimictrl/trimictrl_Linux_ppc --addr=3 --status trloii/trloctrl/fw_d374466d_tridi/src/tridi_ctrl.c:41: printf (" --addr=HEX Module address (HEX=dummy for dummy).\n"); trloii/trloctrl/fw_d374466d_tridi/src/tridi_ctrl.c:201: if (argc > iarg && strncmp(argv[iarg],"--addr=",7) == 0) trloii/trloctrl/trloctrl.sh:35:$TRLOCTRL_BASE/$TRLOCTRL_PGM --addr=$TRLOCTRL_ADDRESS $@ ?bereinstimmungen in Bin?rdatei trloii/trimictrl/bin_ppc-linux_4.2.2/trimictrl ?bereinstimmungen in Bin?rdatei trloii/trimictrl/bld_ppc-linux_4.2.2/trimictrl.o ?bereinstimmungen in Bin?rdatei trloii/trimictrl/bin_x86_64-linux-gnu_7/trimictrl trloii/trimictrl/trimictrl.c:52: printf (" --addr=HEX Module address.\n"); trloii/trimictrl/trimictrl.c:852: if (argc > iarg && strncmp(argv[iarg],"--addr=",7) == 0) ?bereinstimmungen in Bin?rdatei trloii/trimictrl/bld_x86_64-linux-gnu_7/trimictrl.o trloii/scripts/makealiases.sh:46: ADDRESS=" --addr=$1" trloii/doc/man/man7/trloii-intro.7:107: alias trimictrl \fI/trloii-path\fB/trimictrl/bin_\fIARCH\fB/trimictrl --addr=\fIVA\fR trloii/doc/man/man7/trloii-intro.7:117: alias trimictrl=\(dq\fI/trloii-path\fB/trimictrl/bin_\fIARCH\fB/trimictrl --addr=\fIVA\fB\(dq\fR trloii/doc/man/man7/trloii-intro.7:144:\fBvulomflash --addr=7 --read\fR trloii/doc/man/man7/trloii-intro.7:180:\fBvulomflash --addr=7 --readprogs\fR trloii/doc/man/man7/trloii-intro.7:208:\fBvulomflash --addr=7 \fIX\fBlogic\fIY\fB.rbt --prog=\fI6\fR trloii/doc/man/man7/trloii-intro.7:236:\fBvulomflash --addr=7 --readprogs\fR trloii/doc/man/man7/trloii-intro.7:244:\fBvulomflash --addr=7 --restart=6\fR trloii/doc/man/man7/trloii-intro.7:248:\fBvulomflash --addr=7 --read\fR trloii/doc/man/man7/trloii-intro.7:276: --addr=\fIVA\fR trloii/doc/man/man7/trloii-intro.7:285: --addr=\fIVA\(dq\fR history_saves/rio4_mcal_1.history:6: 6 9:55 ./bin_ppc-linux_4.2.2/vulomflash --addr=4 history_saves/rio4_mcal_1.history:7: 7 9:55 ./bin_ppc-linux_4.2.2/vulomflash --addr=4 --readprogs history_saves/rio4_mcal_1.history:8: 8 9:56 ./bin_ppc-linux_4.2.2/vulomflash --addr=4 --help history_saves/rio4_mcal_1.history:9: 9 9:56 ./bin_ppc-linux_4.2.2/vulomflash --addr=4 --extract=0,vulom_fw_range0.readback history_saves/rio4_mcal_1.history:11: 11 9:57 ./bin_ppc-linux_4.2.2/vulomflash --addr=4 --help history_saves/rio4_mcal_1.history:12: 12 9:58 ./bin_ppc-linux_4.2.2/vulomflash --addr=4 --readprogs=full history_saves/rio4_mcal_1.history:21: 21 10:01 ./bin_ppc-linux_4.2.2/vulomflash --addr=4 --help history_saves/rio4_mcal_1.history:22: 22 10:01 ./bin_ppc-linux_4.2.2/vulomflash --addr=4 --prog=1 ../fw/vulom4b_trlo/vlogic_4b.rbt history_saves/rio4_mcal_1.history:23: 23 10:02 ./bin_ppc-linux_4.2.2/vulomflash --addr=4 --restart=1 history_saves/rio4_mcal_1.history:24: 24 10:02 ./bin_ppc-linux_4.2.2/vulomflash --addr=4 --readprogs history_saves/rio4_mcal_1.history:41: 41 10:12 $TRLOII_FLASH --addr=4 rio4-mcal-2/scaler.sh:2:$VULOM4_CTRL --addr=$addr --mux-src-scalers=ptn,$1 rio4-mcal-2/trloii_setup.sh:6:# $VULOM4_CTRL --addr=$addr --clear-setup --config=vulom.trlo standalone module_trigger pulser_to_channels rio4-mcal-2/trloii_setup.sh:9:# $VULOM4_CTRL --addr=$addr --clear-setup --config=vulom.trlo standalone module_trigger rio4-mcal-2/trloii_setup.sh:12:$VULOM4_CTRL --addr=$addr --clear-setup --config=vulom.trlo standalone module_trigger rio4-mcal-2/trloii_setup.sh:19:# $TRIMI_CTRL --addr=$addr encoded_in=TRLO_ENCODED_TRIG fast_dt=1000 rio4-mcal-2/rio4_mcal_1.history:6: 6 9:55 ./bin_ppc-linux_4.2.2/vulomflash --addr=4 rio4-mcal-2/rio4_mcal_1.history:7: 7 9:55 ./bin_ppc-linux_4.2.2/vulomflash --addr=4 --readprogs rio4-mcal-2/rio4_mcal_1.history:8: 8 9:56 ./bin_ppc-linux_4.2.2/vulomflash --addr=4 --help rio4-mcal-2/rio4_mcal_1.history:9: 9 9:56 ./bin_ppc-linux_4.2.2/vulomflash --addr=4 --extract=0,vulom_fw_range0.readback rio4-mcal-2/rio4_mcal_1.history:11: 11 9:57 ./bin_ppc-linux_4.2.2/vulomflash --addr=4 --help rio4-mcal-2/rio4_mcal_1.history:12: 12 9:58 ./bin_ppc-linux_4.2.2/vulomflash --addr=4 --readprogs=full rio4-mcal-2/rio4_mcal_1.history:21: 21 10:01 ./bin_ppc-linux_4.2.2/vulomflash --addr=4 --help rio4-mcal-2/rio4_mcal_1.history:22: 22 10:01 ./bin_ppc-linux_4.2.2/vulomflash --addr=4 --prog=1 ../fw/vulom4b_trlo/vlogic_4b.rbt rio4-mcal-2/rio4_mcal_1.history:23: 23 10:02 ./bin_ppc-linux_4.2.2/vulomflash --addr=4 --restart=1 rio4-mcal-2/rio4_mcal_1.history:24: 24 10:02 ./bin_ppc-linux_4.2.2/vulomflash --addr=4 --readprogs rio4-mcal-2/rio4_mcal_1.history:41: 41 10:12 $TRLOII_FLASH --addr=4 drasi/f_user_example/f_user_sync.c:197:${TRLOLIB_DIR}/bin_`bin/drasi-config.sh --arch-prefix`/trlo_ctrl --addr=3 \ drasi/f_user_example/f_user_sync.c:203:${TRLOLIB_DIR}/../../bin/trimictrl --addr=3 "encoded_in=TRLO_ENCODED_TRIG" drasi/f_user_example/f_user_sync.c:211:${TRLOLIB_DIR}/bin_`bin/drasi-config.sh --arch-prefix`/trlo_ctrl --addr=2 \ drasi/f_user_example/f_user_sync.c:217:${TRLOLIB_DIR}/../../bin/trimictrl --addr=2 "encoded_in=TRLO_ENCODED_TRIG" drasi/perf/readout/perf2.txt:1:# bin_ppc-linux_4.2.2/tridi_ctrl --addr=2 "TRIG_PENDING[1]=PULSER(1)" "period(1)=100ns" "TRIG_PENDING[2]=WIRED_ZERO" "TRIG_PENDING[3]=WIRED_ZERO" drasi/perf/readout/perf2.txt:2:# bin_ppc-linux_4.2.2/tridi_ctrl --addr=2 "TRIG_PENDING[1]=PULSER(1)" "period(1)=20000ns" "TRIG_PENDING[2]=PULSER(2)" "period(2)=19990ns" "TRIG_PENDING[3]=PULSER(3)" "period(3)=20030ns" drasi/perf/readout/perfplot.py:437:bin_ppc-linux_4.2.2/tridi_ctrl --addr=2 \ drasi/perf/readout/perfplot.py:441:bin_ppc-linux_4.2.2/tridi_ctrl --addr=2 \ drasi/perf/readout/perfplot.py:449:bin_ppc-linux_4.2.2/tridi_ctrl --addr=2 --print-config Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Dienstag, 9. Januar 2024 23:21:08 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 On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > Dear H?kan, > > > in the old directory I found "trloii_firmwares_c44f109.tar.gz". > > > I should now delete the new TRLOII folder and replace it with the extracted archive, correct? No, extract the archive in the trloii/ folder. > Then just typing in "find_firmwares.pl" (or should it be "./find_firmwares.pl"?) in TRLOCTRL > will, hopefully, do the trick, right? Yes, "./find_firmwares.pl" in trloii/trloctrl/ And then we cross fingers that the newer code compiles with the older headers. (Likely, but no guarantee.) If not, then get the older trloii/ directory which presumably has the firmwares already unpacked in it. > With VULOM address you mean the physical address that is set on the module? No, I do not know it. > But tomorrow I can find out, of course. Or likely it is in some script somewhere. grep -r "--addr=" might reveal it :-) Cheers, H?kan > > > > > > Best greetings > > G?nter > > > > > _________________________________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan T Johansson > > Gesendet: Dienstag, 9. Januar 2024 22: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 > > My mistake: > > in a new trloii directory, > > after > > cd trloctrl > > you need to do > > find_firmwares.pl > > before the make _build > > however, I suspect we'll then run into the next issue, namely that the > TRLO II firmware that you have likely is old. I do not see d96ffc88 in > the list of current ones > > http://fy.chalmers.se/~f96hajo/trloii/firmwares.html > > -- > > This is not needed, but might help to figure that: > > If you can run (new or old) $TRLOII_FLASH or just from trloii/ dir: > > bin/vulomflash --addr=X --readprogs > > where X needs to be the address of the vulom module, that would give a > list. Do you know what the vulom address is? > > -- > > Hmmmm. To update that means to also update what runs on the VULOM4, which > makes it more messy to go back-and-forth. Or to run another version of it > but without changing its default. Doable, but I think we are getting a > few too many loose variables here right now. > > I think it would be best if you for the moment copy over the old trloii/ > directory and try to recompile that one in the new location. > > -- > > The other way is if you have a > > trloii_firmwares_XXX.tar.gz > > file, e.g. in the (old) trloii/ directory, and unp?ack that in the new > trloii/, then find_firmwares.pl should also find those (old) headers, and > hopefully produce a line also with d374466d. > > -- > > Sorry that this is becoming a bit too convoluted to be really pleasant. > > Cheers, > H?kan > > > > > On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > > > > Ok, after this fix, the compilation in TRLOII finshes without problems. > > > > > > But in TRLOCTRL we have the following problem (as already noticed when I tried to compile on > the > > PC). > > > > > > RIO4-MCAL-2 mbsdaq > pwd > > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl > > RIO4-MCAL-2 mbsdaq > make fw_d96ffc88_trlo_build > > cat: firmwaredirs: No such file or directory > > make -C fw_d96ffc88_trlo -f ../trlolib/Makefile \ > > TRLOBASENAME=`cat fw_d96ffc88_trlo/trlobasename` FILTERSRC=1 > > cat: fw_d96ffc88_trlo/trlobasename: No such file or directory > > make: *** fw_d96ffc88_trlo: No such file or directory. Stop. > > make: *** [fw_d96ffc88_trlo_build] Error 2 > > RIO4-MCAL-2 mbsdaq > make fw_d374466d_tridi_build > > cat: firmwaredirs: No such file or directory > > make -C fw_d374466d_tridi -f ../trlolib/Makefile \ > > TRLOBASENAME=`cat fw_d374466d_tridi/trlobasename` FILTERSRC=1 > > cat: fw_d374466d_tridi/trlobasename: No such file or directory > > make: *** fw_d374466d_tridi: No such file or directory. Stop. > > make: *** [fw_d374466d_tridi_build] Error 2 > > > > After this I went ahead to DRASI and there the compilation finished without error. > > > > Thus, if the issue with TRLOCTRL could be solved, maybe our DAQ is good to go ?? > > > > > > > > Best greetings > > G?nter > > > > > > > >________________________________________________________________________________________________ > _ > > Von: subexp-daq im Auftrag von H?kan T Johansson > > > > Gesendet: Dienstag, 9. Januar 2024 16:59:07 > > 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 > > > > Quick-fix II: comment out trigalign_dir from the targets in trloii/Makefile: > > > > all: trimictrl_dir flash_dir \ > > proglinks # trigalign_dir > > > > Cheers, > > H?kan > > > > > > > > On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > > > > > > > Unfortunately, "make -k" ends with the same result: > > > > > > > > > ... > > > > > > make[1]: Entering directory > > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > > > CC bld_ppc-linux_4.2.2/align_analyse.o > > > CC bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_parser.o > > > gen_ppc-linux_4.2.2/align_parser.c:19: warning: 'align_growstack' declared 'static' but never > > defined > > > CC bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o > > > align_lexer.l: In function 'align_lex': > > > align_lexer.l:28: error: 'align_lval' undeclared (first use in this function) > > > align_lexer.l:28: error: (Each undeclared identifier is reported only once > > > align_lexer.l:28: error: for each function it appears in.) > > > align_lexer.l:29: error: 'INTEGER' undeclared (first use in this function) > > > align_lexer.l:32: error: 'START' undeclared (first use in this function) > > > align_lexer.l:33: error: 'END' undeclared (first use in this function) > > > align_lexer.l:34: error: 'CH' undeclared (first use in this function) > > > align_lexer.l:35: error: 'DELAY' undeclared (first use in this function) > > > make[1]: *** [bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o] Error 1 > > > make[1]: Target `all' not remade because of errors. > > > make[1]: Leaving directory > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > > > make: *** [trigalign_dir] Error 2 > > > make: Target `all' not remade because of errors. > > > > > > > >>_______________________________________________________________________________________________ > _ > > _____________________________________________________ > > > Von: subexp-daq im Auftrag von H?kan T Johansson > > > > > Gesendet: Dienstag, 9. Januar 2024 16:36:28 > > > 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 > > > > > > Quick-fix for the trigalign: > > > > > > try compile with 'make -k', which tries to continue with other things. > > > the trigger aligment you likely do not use, so we can solve that more slowly. > > > > > > You are not creating problems, we want/need to know what does not work so > > > it can get fixed :) > > > > > > Cheers, > > > H?kan > > > > > > > > > > > > On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > > > > > > > > > > Dear friends, > > > > > > > > > > > > what I now did: > > > > > > > > > > > > 1) Deleting the folders of DRASI, TRLOII, and R3BFUSER > > > > > > > > 2) Downloading the most recent versions from Gitlab > > > > > > > > 3) Executing MAKE CLEAN, followed by MAKE in the folders TRLOII and DRASI on the PC (make > > fw_d96ffc88_trlo_build failed on the PC, make > > > > fw_d374466d_tridi_build I did not try) > > > > > > > > 4) Executing MAKE CLEAN, followed by MAKE on the RIO in the folder TRLOII. And there a new > > problem shows up: > > > > > > > > > > > > make[1]: Entering directory > > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > > > > CC bld_ppc-linux_4.2.2/align_analyse.o > > > > CC bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_parser.o > > > > gen_ppc-linux_4.2.2/align_parser.c:19: warning: 'align_growstack' declared 'static' but > never > > defined > > > > CC bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o > > > > align_lexer.l: In function 'align_lex': > > > > align_lexer.l:28: error: 'align_lval' undeclared (first use in this function) > > > > align_lexer.l:28: error: (Each undeclared identifier is reported only once > > > > align_lexer.l:28: error: for each function it appears in.) > > > > align_lexer.l:29: error: 'INTEGER' undeclared (first use in this function) > > > > align_lexer.l:32: error: 'START' undeclared (first use in this function) > > > > align_lexer.l:33: error: 'END' undeclared (first use in this function) > > > > align_lexer.l:34: error: 'CH' undeclared (first use in this function) > > > > align_lexer.l:35: error: 'DELAY' undeclared (first use in this function) > > > > make[1]: *** [bld_ppc-linux_4.2.2/gen_ppc-linux_4.2.2/align_lexer.o] Error 1 > > > > make[1]: Leaving directory > > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trigalign' > > > > make: *** [trigalign_dir] Error 2 > > > > > > > > When I was compiling TRLOII with the old version, this error did not occur. > > > > > > > > > > > > > > > > I am really sorry for causing so much trouble ?? > > > > > > > > > > > > > > > > > > > > Best greetings > > > > > > > > G?nter > > > > > > > > > > > > > >>>______________________________________________________________________________________________ > _ > > _____________________________________________________ > > > _ > > > > Von: subexp-daq im Auftrag von H?kan T Johansson > > > > > > Gesendet: Dienstag, 9. Januar 2024 16:05:19 > > > > 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, > > > > > > > > yes, please download the latest drasi. That should fix the broken link. > > > > > > > > ALso, compile it on the PC first. That will download the file, and then > > > > the RIO compile will use that. > > > > > > > > I'd suggest to also update trloii before compiling! Same trick there > > > > might be helpful, i.e. compile on PC first. Nothing to download, but some > > > > generated files are quicker made on a PC. > > > > > > > > Cheers, > > > > H?kan > > > > > > > > > > > > On Tue, 9 Jan 2024, Weber, Guenter Dr. wrote: > > > > > > > > > > > > > > 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 im Auftrag von H?kan T Johansson > > > > > > > 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 im Auftrag von Weber, Guenter > Dr. > > > > > > > > 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 im Auftrag von Hans Toshihide > > T?rnqvist > > > > > > 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/ > b > > in_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/ > b > > in_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: From f96hajo at chalmers.se Wed Jan 10 12:34:26 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Wed, 10 Jan 2024 12:34:26 +0100 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: <14e1aab1db454f5da272442151f66d56@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <2cb1927f-8c64-43f2-a0cb-bf501a5808b3@chalmers.se> , <08028286-f61a-475d-ab01-b579141e5762@chalmers.se>, <48cae3a127fe4666901bc49eacf69d3b@hi-jena.gsi.de> <81f59eb1bbc344bf8cf703c150a1796b@hi-jena.gsi.de>, <128bdcbcdaad41b4be10ecae34715fb8@hi-jena.gsi.de>, <8256e7a9-82b9-e8b9-2687-ef6b3156df57@chalmers.se> , <14184882-f21c-dbce-fa42-6d17901d086a@chalmers.se> , <6891db86-9945-74ce-5872-9f84afa855b7@chalmers.se> , <1fc55deb-35fd-a0f1-cb56-c550e36feba8@chalmers.se> , <3bf5e24e-a8e4-242d-09f5-4be3198f65d2@chalmers.se> <14e1aab1db454f5da272442151f66d56@hi-jena.gsi.de> Message-ID: Hi G?nter, On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote: > > Hi folks, > > > the old "./find_firmware.pl" was working. This is the output: > > > a1729cda ../ver/rimfaxe0_trlo/rfx0_defs.h > 0866c243 ../ver/rimfaxe1_trlo/rfx1_defs.h > 5e8f5ef4 ../ver/tridi1_trlo/tridi_defs.h > 6e4ba1a9 ../ver/vulom4_trlo/trlo_defs.h > 68f8955e ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h > af33ed35 ../ver/vulom4_trlo_big/trlo_big_defs.h > 1409285e ../ver/vulom4b_trlo/trlo_defs.h > d374466d ../fw/tridi1_trlo/tridi_defs.h > d96ffc88 ../fw/vulom4_trlo/trlo_defs.h > 5b298165 ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h > 6f28c0f8 ../fw/vulom4_trlo_big/trlo_big_defs.h > fa5020ea ../fw/vulom4_trlo_led/trlo_defs.h > 426cb99c ../fw/vulom4b_trlo/trlo_defs.h > MKDIR?? fw_a1729cda_rfx0? # ../ver/rimfaxe0_trlo/rfx0_defs.h > SYMLINK fw_a1729cda_rfx0/rfx0_defs.h -> ../../ver/rimfaxe0_trlo/rfx0_defs.h > MKDIR?? fw_0866c243_rfx1? # ../ver/rimfaxe1_trlo/rfx1_defs.h > SYMLINK fw_0866c243_rfx1/rfx1_defs.h -> ../../ver/rimfaxe1_trlo/rfx1_defs.h > MKDIR?? fw_5e8f5ef4_tridi? # ../ver/tridi1_trlo/tridi_defs.h > SYMLINK fw_5e8f5ef4_tridi/tridi_defs.h -> ../../ver/tridi1_trlo/tridi_defs.h > MKDIR?? fw_6e4ba1a9_trlo? # ../ver/vulom4_trlo/trlo_defs.h > SYMLINK fw_6e4ba1a9_trlo/trlo_defs.h -> ../../ver/vulom4_trlo/trlo_defs.h > SYMLINK fw_1409285e_trlo -> fw_6e4ba1a9_trlo > MKDIR?? fw_68f8955e_trlo_all_in? # ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h > SYMLINK fw_68f8955e_trlo_all_in/trlo_all_in_defs.h -> ../../ver/vulom4_trlo_all_in/trlo_all_in_defs.h > MKDIR?? fw_af33ed35_trlo_big? # ../ver/vulom4_trlo_big/trlo_big_defs.h > SYMLINK fw_af33ed35_trlo_big/trlo_big_defs.h -> ../../ver/vulom4_trlo_big/trlo_big_defs.h > MKDIR?? fw_d374466d_tridi? # ../fw/tridi1_trlo/tridi_defs.h > SYMLINK fw_d374466d_tridi/tridi_defs.h -> ../../fw/tridi1_trlo/tridi_defs.h > MKDIR?? fw_d96ffc88_trlo? # ../fw/vulom4_trlo/trlo_defs.h > SYMLINK fw_d96ffc88_trlo/trlo_defs.h -> ../../fw/vulom4_trlo/trlo_defs.h > SYMLINK fw_426cb99c_trlo -> fw_d96ffc88_trlo > SYMLINK fw_fa5020ea_trlo -> fw_d96ffc88_trlo > MKDIR?? fw_5b298165_trlo_all_in? # ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h > SYMLINK fw_5b298165_trlo_all_in/trlo_all_in_defs.h -> ../../fw/vulom4_trlo_all_in/trlo_all_in_defs.h > MKDIR?? fw_6f28c0f8_trlo_big? # ../fw/vulom4_trlo_big/trlo_big_defs.h > SYMLINK fw_6f28c0f8_trlo_big/trlo_big_defs.h -> ../../fw/vulom4_trlo_big/trlo_big_defs.h > > However, the compilation did end with an error: > > > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo' > ?? CC??? bld_ppc-linux_4.2.2/src/trlo_check_version.o > ?? CC??? bld_ppc-linux_4.2.2/src/trlo_functions.o > ../trlolib/src/trlo_functions.c: In function 'trlo_clear_config': > ../trlolib/src/trlo_functions.c:144: error: 'trlo_setup_map' has no member named 'sync_check_start_mux' > ../trlolib/src/trlo_functions.c:146: error: 'trlo_setup_map' has no member named 'sync_check_stop_mux' > ../trlolib/src/trlo_functions.c: In function 'trlo_print_config': > ../trlolib/src/trlo_functions.c:825: error: 'trlo_setup_map' has no member named 'sync_check_start_mux' > ../trlolib/src/trlo_functions.c:829: error: 'trlo_setup_map' has no member named 'sync_check_stop_mux' > ../trlolib/src/trlo_functions.c: In function 'trlo_print_trig_status': > ../trlolib/src/trlo_functions.c:1155: error: 'trlo_output_map' has no member named 'trig_sync_check' > make[1]: *** [bld_ppc-linux_4.2.2/src/trlo_functions.o] Error 1 > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo' > > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi' > ?? CC??? bld_ppc-linux_4.2.2/src/tridi_check_version.o > ?? CC??? bld_ppc-linux_4.2.2/src/tridi_functions.o > ../trlolib/src/trlo_functions.c: In function 'tridi_clear_config': > ../trlolib/src/trlo_functions.c:144: error: 'tridi_setup_map' has no member named 'sync_check_start_mux' > ../trlolib/src/trlo_functions.c:146: error: 'tridi_setup_map' has no member named 'sync_check_stop_mux' > ../trlolib/src/trlo_functions.c: In function 'tridi_print_config': > ../trlolib/src/trlo_functions.c:825: error: 'tridi_setup_map' has no member named 'sync_check_start_mux' > ../trlolib/src/trlo_functions.c:829: error: 'tridi_setup_map' has no member named 'sync_check_stop_mux' > ../trlolib/src/trlo_functions.c: In function 'tridi_print_trig_status': > ../trlolib/src/trlo_functions.c:1155: error: 'tridi_output_map' has no member named 'trig_sync_check' > make[1]: *** [bld_ppc-linux_4.2.2/src/tridi_functions.o] Error 1 > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi' > make: *** [fw_d374466d_tridi_build] Error 2 That's what I feared. The new code want something (sync_check_...) not in the older firmware... > The fallback option is now to delete the new TRLOII folder and replace it with old one and then repeat the following steps? > > > cd trloii > make clean > make > cd trloctrl > make fw_d96ffc88_trlo_build > ?make fw_d374466d_tridi_build > > > Is this correct? Yes. There should then already be the trloii/fw/ directory, and the links that are created by find_firmware.pl > I also looked for the "--addr=" and this is the result: > ... Ok. I was too optimistic here. I looked through the grep results, but nothing obvious. Should be figurable by checking the old scripts and following them around. Is a good way to see how things are done anyhow ;) Cheers, H?kan > > > > Best greetings > > G?nter From g.weber at hi-jena.gsi.de Wed Jan 10 13:15:13 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Wed, 10 Jan 2024 12:15:13 +0000 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <2cb1927f-8c64-43f2-a0cb-bf501a5808b3@chalmers.se> , <08028286-f61a-475d-ab01-b579141e5762@chalmers.se>, <48cae3a127fe4666901bc49eacf69d3b@hi-jena.gsi.de> <81f59eb1bbc344bf8cf703c150a1796b@hi-jena.gsi.de>, <128bdcbcdaad41b4be10ecae34715fb8@hi-jena.gsi.de>, <8256e7a9-82b9-e8b9-2687-ef6b3156df57@chalmers.se> , <14184882-f21c-dbce-fa42-6d17901d086a@chalmers.se> , <6891db86-9945-74ce-5872-9f84afa855b7@chalmers.se> , <1fc55deb-35fd-a0f1-cb56-c550e36feba8@chalmers.se> , <3bf5e24e-a8e4-242d-09f5-4be3198f65d2@chalmers.se> <14e1aab1db454f5da272442151f66d56@hi-jena.gsi.de>, Message-ID: <43efd4d2fa684387b7839d88617c9e31@hi-jena.gsi.de> Dear H?kan, using the old TRLOII folder and then recompiling was successfull. Should I now give it a try to start the DAQ? Or is there something else I still need to adjust? Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Mittwoch, 10. Januar 2024 12:34:26 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 Hi G?nter, On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote: > > Hi folks, > > > the old "./find_firmware.pl" was working. This is the output: > > > a1729cda ../ver/rimfaxe0_trlo/rfx0_defs.h > 0866c243 ../ver/rimfaxe1_trlo/rfx1_defs.h > 5e8f5ef4 ../ver/tridi1_trlo/tridi_defs.h > 6e4ba1a9 ../ver/vulom4_trlo/trlo_defs.h > 68f8955e ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h > af33ed35 ../ver/vulom4_trlo_big/trlo_big_defs.h > 1409285e ../ver/vulom4b_trlo/trlo_defs.h > d374466d ../fw/tridi1_trlo/tridi_defs.h > d96ffc88 ../fw/vulom4_trlo/trlo_defs.h > 5b298165 ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h > 6f28c0f8 ../fw/vulom4_trlo_big/trlo_big_defs.h > fa5020ea ../fw/vulom4_trlo_led/trlo_defs.h > 426cb99c ../fw/vulom4b_trlo/trlo_defs.h > MKDIR fw_a1729cda_rfx0 # ../ver/rimfaxe0_trlo/rfx0_defs.h > SYMLINK fw_a1729cda_rfx0/rfx0_defs.h -> ../../ver/rimfaxe0_trlo/rfx0_defs.h > MKDIR fw_0866c243_rfx1 # ../ver/rimfaxe1_trlo/rfx1_defs.h > SYMLINK fw_0866c243_rfx1/rfx1_defs.h -> ../../ver/rimfaxe1_trlo/rfx1_defs.h > MKDIR fw_5e8f5ef4_tridi # ../ver/tridi1_trlo/tridi_defs.h > SYMLINK fw_5e8f5ef4_tridi/tridi_defs.h -> ../../ver/tridi1_trlo/tridi_defs.h > MKDIR fw_6e4ba1a9_trlo # ../ver/vulom4_trlo/trlo_defs.h > SYMLINK fw_6e4ba1a9_trlo/trlo_defs.h -> ../../ver/vulom4_trlo/trlo_defs.h > SYMLINK fw_1409285e_trlo -> fw_6e4ba1a9_trlo > MKDIR fw_68f8955e_trlo_all_in # ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h > SYMLINK fw_68f8955e_trlo_all_in/trlo_all_in_defs.h -> ../../ver/vulom4_trlo_all_in/trlo_all_in_defs.h > MKDIR fw_af33ed35_trlo_big # ../ver/vulom4_trlo_big/trlo_big_defs.h > SYMLINK fw_af33ed35_trlo_big/trlo_big_defs.h -> ../../ver/vulom4_trlo_big/trlo_big_defs.h > MKDIR fw_d374466d_tridi # ../fw/tridi1_trlo/tridi_defs.h > SYMLINK fw_d374466d_tridi/tridi_defs.h -> ../../fw/tridi1_trlo/tridi_defs.h > MKDIR fw_d96ffc88_trlo # ../fw/vulom4_trlo/trlo_defs.h > SYMLINK fw_d96ffc88_trlo/trlo_defs.h -> ../../fw/vulom4_trlo/trlo_defs.h > SYMLINK fw_426cb99c_trlo -> fw_d96ffc88_trlo > SYMLINK fw_fa5020ea_trlo -> fw_d96ffc88_trlo > MKDIR fw_5b298165_trlo_all_in # ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h > SYMLINK fw_5b298165_trlo_all_in/trlo_all_in_defs.h -> ../../fw/vulom4_trlo_all_in/trlo_all_in_defs.h > MKDIR fw_6f28c0f8_trlo_big # ../fw/vulom4_trlo_big/trlo_big_defs.h > SYMLINK fw_6f28c0f8_trlo_big/trlo_big_defs.h -> ../../fw/vulom4_trlo_big/trlo_big_defs.h > > However, the compilation did end with an error: > > > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo' > CC bld_ppc-linux_4.2.2/src/trlo_check_version.o > CC bld_ppc-linux_4.2.2/src/trlo_functions.o > ../trlolib/src/trlo_functions.c: In function 'trlo_clear_config': > ../trlolib/src/trlo_functions.c:144: error: 'trlo_setup_map' has no member named 'sync_check_start_mux' > ../trlolib/src/trlo_functions.c:146: error: 'trlo_setup_map' has no member named 'sync_check_stop_mux' > ../trlolib/src/trlo_functions.c: In function 'trlo_print_config': > ../trlolib/src/trlo_functions.c:825: error: 'trlo_setup_map' has no member named 'sync_check_start_mux' > ../trlolib/src/trlo_functions.c:829: error: 'trlo_setup_map' has no member named 'sync_check_stop_mux' > ../trlolib/src/trlo_functions.c: In function 'trlo_print_trig_status': > ../trlolib/src/trlo_functions.c:1155: error: 'trlo_output_map' has no member named 'trig_sync_check' > make[1]: *** [bld_ppc-linux_4.2.2/src/trlo_functions.o] Error 1 > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo' > > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi' > CC bld_ppc-linux_4.2.2/src/tridi_check_version.o > CC bld_ppc-linux_4.2.2/src/tridi_functions.o > ../trlolib/src/trlo_functions.c: In function 'tridi_clear_config': > ../trlolib/src/trlo_functions.c:144: error: 'tridi_setup_map' has no member named 'sync_check_start_mux' > ../trlolib/src/trlo_functions.c:146: error: 'tridi_setup_map' has no member named 'sync_check_stop_mux' > ../trlolib/src/trlo_functions.c: In function 'tridi_print_config': > ../trlolib/src/trlo_functions.c:825: error: 'tridi_setup_map' has no member named 'sync_check_start_mux' > ../trlolib/src/trlo_functions.c:829: error: 'tridi_setup_map' has no member named 'sync_check_stop_mux' > ../trlolib/src/trlo_functions.c: In function 'tridi_print_trig_status': > ../trlolib/src/trlo_functions.c:1155: error: 'tridi_output_map' has no member named 'trig_sync_check' > make[1]: *** [bld_ppc-linux_4.2.2/src/tridi_functions.o] Error 1 > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi' > make: *** [fw_d374466d_tridi_build] Error 2 That's what I feared. The new code want something (sync_check_...) not in the older firmware... > The fallback option is now to delete the new TRLOII folder and replace it with old one and then repeat the following steps? > > > cd trloii > make clean > make > cd trloctrl > make fw_d96ffc88_trlo_build > make fw_d374466d_tridi_build > > > Is this correct? Yes. There should then already be the trloii/fw/ directory, and the links that are created by find_firmware.pl > I also looked for the "--addr=" and this is the result: > ... Ok. I was too optimistic here. I looked through the grep results, but nothing obvious. Should be figurable by checking the old scripts and following them around. Is a good way to see how things are done anyhow ;) Cheers, H?kan > > > > Best greetings > > G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.tornqvist at chalmers.se Wed Jan 10 13:18:41 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Wed, 10 Jan 2024 13:18:41 +0100 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: <43efd4d2fa684387b7839d88617c9e31@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <08028286-f61a-475d-ab01-b579141e5762@chalmers.se> <48cae3a127fe4666901bc49eacf69d3b@hi-jena.gsi.de> <81f59eb1bbc344bf8cf703c150a1796b@hi-jena.gsi.de> <128bdcbcdaad41b4be10ecae34715fb8@hi-jena.gsi.de> <8256e7a9-82b9-e8b9-2687-ef6b3156df57@chalmers.se> <14184882-f21c-dbce-fa42-6d17901d086a@chalmers.se> <6891db86-9945-74ce-5872-9f84afa855b7@chalmers.se> <1fc55deb-35fd-a0f1-cb56-c550e36feba8@chalmers.se> <3bf5e24e-a8e4-242d-09f5-4be3198f65d2@chalmers.se> <14e1aab1db454f5da272442151f66d56@hi-jena.gsi.de> <43efd4d2fa684387b7839d88617c9e31@hi-jena.gsi.de> Message-ID: Dear G?nter, I would suggest rebuilding nurdlib now that trlo2 has been rebuilt, and then also rebuild r3bfuser. After that probably you can try to run the DAQ :) Cheers, Hans On 2024-01-10 13:15, Weber, Guenter Dr. wrote: > Dear H?kan, > > > using the old TRLOII folder and then recompiling was successfull. > > > Should I now give it a try to start the DAQ? Or is there something else > I still need to adjust? > > > > > Best greetings > > G?nter > > > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > H?kan T Johansson > *Gesendet:* Mittwoch, 10. Januar 2024 12:34:26 > *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 > > Hi G?nter, > > On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote: > >> >> Hi folks, >> >> >> the old "./find_firmware.pl" was working. This is the output: >> >> >> a1729cda ../ver/rimfaxe0_trlo/rfx0_defs.h >> 0866c243 ../ver/rimfaxe1_trlo/rfx1_defs.h >> 5e8f5ef4 ../ver/tridi1_trlo/tridi_defs.h >> 6e4ba1a9 ../ver/vulom4_trlo/trlo_defs.h >> 68f8955e ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h >> af33ed35 ../ver/vulom4_trlo_big/trlo_big_defs.h >> 1409285e ../ver/vulom4b_trlo/trlo_defs.h >> d374466d ../fw/tridi1_trlo/tridi_defs.h >> d96ffc88 ../fw/vulom4_trlo/trlo_defs.h >> 5b298165 ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h >> 6f28c0f8 ../fw/vulom4_trlo_big/trlo_big_defs.h >> fa5020ea ../fw/vulom4_trlo_led/trlo_defs.h >> 426cb99c ../fw/vulom4b_trlo/trlo_defs.h >> MKDIR?? fw_a1729cda_rfx0? # ../ver/rimfaxe0_trlo/rfx0_defs.h >> SYMLINK fw_a1729cda_rfx0/rfx0_defs.h -> ../../ver/rimfaxe0_trlo/rfx0_defs.h >> MKDIR?? fw_0866c243_rfx1? # ../ver/rimfaxe1_trlo/rfx1_defs.h >> SYMLINK fw_0866c243_rfx1/rfx1_defs.h -> ../../ver/rimfaxe1_trlo/rfx1_defs.h >> MKDIR?? fw_5e8f5ef4_tridi? # ../ver/tridi1_trlo/tridi_defs.h >> SYMLINK fw_5e8f5ef4_tridi/tridi_defs.h -> ../../ver/tridi1_trlo/tridi_defs.h >> MKDIR?? fw_6e4ba1a9_trlo? # ../ver/vulom4_trlo/trlo_defs.h >> SYMLINK fw_6e4ba1a9_trlo/trlo_defs.h -> ../../ver/vulom4_trlo/trlo_defs.h >> SYMLINK fw_1409285e_trlo -> fw_6e4ba1a9_trlo >> MKDIR?? fw_68f8955e_trlo_all_in? # ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h >> SYMLINK fw_68f8955e_trlo_all_in/trlo_all_in_defs.h -> ../../ver/vulom4_trlo_all_in/trlo_all_in_defs.h >> MKDIR?? fw_af33ed35_trlo_big? # ../ver/vulom4_trlo_big/trlo_big_defs.h >> SYMLINK fw_af33ed35_trlo_big/trlo_big_defs.h -> ../../ver/vulom4_trlo_big/trlo_big_defs.h >> MKDIR?? fw_d374466d_tridi? # ../fw/tridi1_trlo/tridi_defs.h >> SYMLINK fw_d374466d_tridi/tridi_defs.h -> ../../fw/tridi1_trlo/tridi_defs.h >> MKDIR?? fw_d96ffc88_trlo? # ../fw/vulom4_trlo/trlo_defs.h >> SYMLINK fw_d96ffc88_trlo/trlo_defs.h -> ../../fw/vulom4_trlo/trlo_defs.h >> SYMLINK fw_426cb99c_trlo -> fw_d96ffc88_trlo >> SYMLINK fw_fa5020ea_trlo -> fw_d96ffc88_trlo >> MKDIR?? fw_5b298165_trlo_all_in? # ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h >> SYMLINK fw_5b298165_trlo_all_in/trlo_all_in_defs.h -> ../../fw/vulom4_trlo_all_in/trlo_all_in_defs.h >> MKDIR?? fw_6f28c0f8_trlo_big? # ../fw/vulom4_trlo_big/trlo_big_defs.h >> SYMLINK fw_6f28c0f8_trlo_big/trlo_big_defs.h -> ../../fw/vulom4_trlo_big/trlo_big_defs.h >> >> However, the compilation did end with an error: >> >> >> make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo' >> ?? CC??? bld_ppc-linux_4.2.2/src/trlo_check_version.o >> ?? CC??? bld_ppc-linux_4.2.2/src/trlo_functions.o >> ../trlolib/src/trlo_functions.c: In function 'trlo_clear_config': >> ../trlolib/src/trlo_functions.c:144: error: 'trlo_setup_map' has no member named 'sync_check_start_mux' >> ../trlolib/src/trlo_functions.c:146: error: 'trlo_setup_map' has no member named 'sync_check_stop_mux' >> ../trlolib/src/trlo_functions.c: In function 'trlo_print_config': >> ../trlolib/src/trlo_functions.c:825: error: 'trlo_setup_map' has no member named 'sync_check_start_mux' >> ../trlolib/src/trlo_functions.c:829: error: 'trlo_setup_map' has no member named 'sync_check_stop_mux' >> ../trlolib/src/trlo_functions.c: In function 'trlo_print_trig_status': >> ../trlolib/src/trlo_functions.c:1155: error: 'trlo_output_map' has no member named 'trig_sync_check' >> make[1]: *** [bld_ppc-linux_4.2.2/src/trlo_functions.o] Error 1 >> make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo' >> >> make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi' >> ?? CC??? bld_ppc-linux_4.2.2/src/tridi_check_version.o >> ?? CC??? bld_ppc-linux_4.2.2/src/tridi_functions.o >> ../trlolib/src/trlo_functions.c: In function 'tridi_clear_config': >> ../trlolib/src/trlo_functions.c:144: error: 'tridi_setup_map' has no member named 'sync_check_start_mux' >> ../trlolib/src/trlo_functions.c:146: error: 'tridi_setup_map' has no member named 'sync_check_stop_mux' >> ../trlolib/src/trlo_functions.c: In function 'tridi_print_config': >> ../trlolib/src/trlo_functions.c:825: error: 'tridi_setup_map' has no member named 'sync_check_start_mux' >> ../trlolib/src/trlo_functions.c:829: error: 'tridi_setup_map' has no member named 'sync_check_stop_mux' >> ../trlolib/src/trlo_functions.c: In function 'tridi_print_trig_status': >> ../trlolib/src/trlo_functions.c:1155: error: 'tridi_output_map' has no member named 'trig_sync_check' >> make[1]: *** [bld_ppc-linux_4.2.2/src/tridi_functions.o] Error 1 >> make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi' >> make: *** [fw_d374466d_tridi_build] Error 2 > > That's what I feared.? The new code want something (sync_check_...) not in > the older firmware... > >> The fallback option is now to delete the new TRLOII folder and replace it with old one and then repeat the following steps? >> >> >> cd trloii >> make clean >> make >> cd trloctrl >> make fw_d96ffc88_trlo_build >> ?make fw_d374466d_tridi_build >> >> >> Is this correct? > > Yes. > > There should then already be the trloii/fw/ directory, and the links that > are created by find_firmware.pl > > >> I also looked for the "--addr=" and this is the result: > >> ... > > Ok.? I was too optimistic here.? I looked through the grep results, but > nothing obvious.? Should be figurable by checking the old scripts and > following them around.? Is a good way to see how things are done anyhow ;) > > Cheers, > H?kan > > >> >> >> >> Best greetings >> >> G?nter > From g.weber at hi-jena.gsi.de Wed Jan 10 13:46:06 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Wed, 10 Jan 2024 12:46:06 +0000 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <08028286-f61a-475d-ab01-b579141e5762@chalmers.se> <48cae3a127fe4666901bc49eacf69d3b@hi-jena.gsi.de> <81f59eb1bbc344bf8cf703c150a1796b@hi-jena.gsi.de> <128bdcbcdaad41b4be10ecae34715fb8@hi-jena.gsi.de> <8256e7a9-82b9-e8b9-2687-ef6b3156df57@chalmers.se> <14184882-f21c-dbce-fa42-6d17901d086a@chalmers.se> <6891db86-9945-74ce-5872-9f84afa855b7@chalmers.se> <1fc55deb-35fd-a0f1-cb56-c550e36feba8@chalmers.se> <3bf5e24e-a8e4-242d-09f5-4be3198f65d2@chalmers.se> <14e1aab1db454f5da272442151f66d56@hi-jena.gsi.de> <43efd4d2fa684387b7839d88617c9e31@hi-jena.gsi.de>, Message-ID: <299880b3f6984312aeb94a1b29c3f302@hi-jena.gsi.de> Dear Hans, I now did rebuild NURDLIB and DRASI. Then I tried to compile R3BFUSER and this is the result: RIO4-MCAL-2 mbsdaq > cd r3bfuser/ 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 make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args UDP:ARPA_INET_H CC build_cc_ppc-linux_4.2.2_debug/f_user.o CC build_cc_ppc-linux_4.2.2_debug/subevent.o In file included from /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/s_veshe.h:6, from ./subevent.h:11, from subevent.c:1: /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:6: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTS8' /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:7: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTU8' /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:8: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTS4' /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:9: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTU4' /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:10: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTS2' /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:11: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTU2' /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:12: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTS1' /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:13: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTU1' In file included from ./subevent.h:11, from subevent.c:1: /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/s_veshe.h:11: error: expected specifier-qualifier-list before 'INTS4' subevent.c: In function 'begin_goosy_vme_subevent': subevent.c:12: error: 's_veshe' has no member named 'l_dlen' subevent.c: In function 'end_goosy_vme_subevent': subevent.c:45: error: 's_veshe' has no member named 'l_dlen' make[1]: *** [build_cc_ppc-linux_4.2.2_debug/subevent.o] Error 1 make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' make: *** [drasi] Error 2 Reminder: I am using the most recent versions of NURDLIB and DRASI, but because of the incompatibility of the VULOM firmware I use the old version of TRLOII. In addition, because of the leap seconds issue I compiled DRASI first on the PC and then recompiled it on the RIO (without "make clean"). Best greetings G?nter ________________________________ Von: Hans Toshihide T?rnqvist Gesendet: Mittwoch, 10. Januar 2024 13:18:41 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, I would suggest rebuilding nurdlib now that trlo2 has been rebuilt, and then also rebuild r3bfuser. After that probably you can try to run the DAQ :) Cheers, Hans On 2024-01-10 13:15, Weber, Guenter Dr. wrote: > Dear H?kan, > > > using the old TRLOII folder and then recompiling was successfull. > > > Should I now give it a try to start the DAQ? Or is there something else > I still need to adjust? > > > > > Best greetings > > G?nter > > > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > H?kan T Johansson > *Gesendet:* Mittwoch, 10. Januar 2024 12:34:26 > *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 > > Hi G?nter, > > On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote: > >> >> Hi folks, >> >> >> the old "./find_firmware.pl" was working. This is the output: >> >> >> a1729cda ../ver/rimfaxe0_trlo/rfx0_defs.h >> 0866c243 ../ver/rimfaxe1_trlo/rfx1_defs.h >> 5e8f5ef4 ../ver/tridi1_trlo/tridi_defs.h >> 6e4ba1a9 ../ver/vulom4_trlo/trlo_defs.h >> 68f8955e ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h >> af33ed35 ../ver/vulom4_trlo_big/trlo_big_defs.h >> 1409285e ../ver/vulom4b_trlo/trlo_defs.h >> d374466d ../fw/tridi1_trlo/tridi_defs.h >> d96ffc88 ../fw/vulom4_trlo/trlo_defs.h >> 5b298165 ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h >> 6f28c0f8 ../fw/vulom4_trlo_big/trlo_big_defs.h >> fa5020ea ../fw/vulom4_trlo_led/trlo_defs.h >> 426cb99c ../fw/vulom4b_trlo/trlo_defs.h >> MKDIR fw_a1729cda_rfx0 # ../ver/rimfaxe0_trlo/rfx0_defs.h >> SYMLINK fw_a1729cda_rfx0/rfx0_defs.h -> ../../ver/rimfaxe0_trlo/rfx0_defs.h >> MKDIR fw_0866c243_rfx1 # ../ver/rimfaxe1_trlo/rfx1_defs.h >> SYMLINK fw_0866c243_rfx1/rfx1_defs.h -> ../../ver/rimfaxe1_trlo/rfx1_defs.h >> MKDIR fw_5e8f5ef4_tridi # ../ver/tridi1_trlo/tridi_defs.h >> SYMLINK fw_5e8f5ef4_tridi/tridi_defs.h -> ../../ver/tridi1_trlo/tridi_defs.h >> MKDIR fw_6e4ba1a9_trlo # ../ver/vulom4_trlo/trlo_defs.h >> SYMLINK fw_6e4ba1a9_trlo/trlo_defs.h -> ../../ver/vulom4_trlo/trlo_defs.h >> SYMLINK fw_1409285e_trlo -> fw_6e4ba1a9_trlo >> MKDIR fw_68f8955e_trlo_all_in # ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h >> SYMLINK fw_68f8955e_trlo_all_in/trlo_all_in_defs.h -> ../../ver/vulom4_trlo_all_in/trlo_all_in_defs.h >> MKDIR fw_af33ed35_trlo_big # ../ver/vulom4_trlo_big/trlo_big_defs.h >> SYMLINK fw_af33ed35_trlo_big/trlo_big_defs.h -> ../../ver/vulom4_trlo_big/trlo_big_defs.h >> MKDIR fw_d374466d_tridi # ../fw/tridi1_trlo/tridi_defs.h >> SYMLINK fw_d374466d_tridi/tridi_defs.h -> ../../fw/tridi1_trlo/tridi_defs.h >> MKDIR fw_d96ffc88_trlo # ../fw/vulom4_trlo/trlo_defs.h >> SYMLINK fw_d96ffc88_trlo/trlo_defs.h -> ../../fw/vulom4_trlo/trlo_defs.h >> SYMLINK fw_426cb99c_trlo -> fw_d96ffc88_trlo >> SYMLINK fw_fa5020ea_trlo -> fw_d96ffc88_trlo >> MKDIR fw_5b298165_trlo_all_in # ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h >> SYMLINK fw_5b298165_trlo_all_in/trlo_all_in_defs.h -> ../../fw/vulom4_trlo_all_in/trlo_all_in_defs.h >> MKDIR fw_6f28c0f8_trlo_big # ../fw/vulom4_trlo_big/trlo_big_defs.h >> SYMLINK fw_6f28c0f8_trlo_big/trlo_big_defs.h -> ../../fw/vulom4_trlo_big/trlo_big_defs.h >> >> However, the compilation did end with an error: >> >> >> make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo' >> CC bld_ppc-linux_4.2.2/src/trlo_check_version.o >> CC bld_ppc-linux_4.2.2/src/trlo_functions.o >> ../trlolib/src/trlo_functions.c: In function 'trlo_clear_config': >> ../trlolib/src/trlo_functions.c:144: error: 'trlo_setup_map' has no member named 'sync_check_start_mux' >> ../trlolib/src/trlo_functions.c:146: error: 'trlo_setup_map' has no member named 'sync_check_stop_mux' >> ../trlolib/src/trlo_functions.c: In function 'trlo_print_config': >> ../trlolib/src/trlo_functions.c:825: error: 'trlo_setup_map' has no member named 'sync_check_start_mux' >> ../trlolib/src/trlo_functions.c:829: error: 'trlo_setup_map' has no member named 'sync_check_stop_mux' >> ../trlolib/src/trlo_functions.c: In function 'trlo_print_trig_status': >> ../trlolib/src/trlo_functions.c:1155: error: 'trlo_output_map' has no member named 'trig_sync_check' >> make[1]: *** [bld_ppc-linux_4.2.2/src/trlo_functions.o] Error 1 >> make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo' >> >> make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi' >> CC bld_ppc-linux_4.2.2/src/tridi_check_version.o >> CC bld_ppc-linux_4.2.2/src/tridi_functions.o >> ../trlolib/src/trlo_functions.c: In function 'tridi_clear_config': >> ../trlolib/src/trlo_functions.c:144: error: 'tridi_setup_map' has no member named 'sync_check_start_mux' >> ../trlolib/src/trlo_functions.c:146: error: 'tridi_setup_map' has no member named 'sync_check_stop_mux' >> ../trlolib/src/trlo_functions.c: In function 'tridi_print_config': >> ../trlolib/src/trlo_functions.c:825: error: 'tridi_setup_map' has no member named 'sync_check_start_mux' >> ../trlolib/src/trlo_functions.c:829: error: 'tridi_setup_map' has no member named 'sync_check_stop_mux' >> ../trlolib/src/trlo_functions.c: In function 'tridi_print_trig_status': >> ../trlolib/src/trlo_functions.c:1155: error: 'tridi_output_map' has no member named 'trig_sync_check' >> make[1]: *** [bld_ppc-linux_4.2.2/src/tridi_functions.o] Error 1 >> make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi' >> make: *** [fw_d374466d_tridi_build] Error 2 > > That's what I feared. The new code want something (sync_check_...) not in > the older firmware... > >> The fallback option is now to delete the new TRLOII folder and replace it with old one and then repeat the following steps? >> >> >> cd trloii >> make clean >> make >> cd trloctrl >> make fw_d96ffc88_trlo_build >> make fw_d374466d_tridi_build >> >> >> Is this correct? > > Yes. > > There should then already be the trloii/fw/ directory, and the links that > are created by find_firmware.pl > > >> I also looked for the "--addr=" and this is the result: > >> ... > > Ok. I was too optimistic here. I looked through the grep results, but > nothing obvious. Should be figurable by checking the old scripts and > following them around. Is a good way to see how things are done anyhow ;) > > Cheers, > H?kan > > >> >> >> >> Best greetings >> >> G?nter > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Wed Jan 10 16:07:52 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Wed, 10 Jan 2024 16:07:52 +0100 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: <299880b3f6984312aeb94a1b29c3f302@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <48cae3a127fe4666901bc49eacf69d3b@hi-jena.gsi.de> <81f59eb1bbc344bf8cf703c150a1796b@hi-jena.gsi.de> <128bdcbcdaad41b4be10ecae34715fb8@hi-jena.gsi.de> <8256e7a9-82b9-e8b9-2687-ef6b3156df57@chalmers.se> <14184882-f21c-dbce-fa42-6d17901d086a@chalmers.se> <6891db86-9945-74ce-5872-9f84afa855b7@chalmers.se> <1fc55deb-35fd-a0f1-cb56-c550e36feba8@chalmers.se> <3bf5e24e-a8e4-242d-09f5-4be3198f65d2@chalmers.se> <14e1aab1db454f5da272442151f66d56@hi-jena.gsi.de> <43efd4d2fa684387b7839d88617c9e31@hi-jena.gsi.de>, <299880b3f6984312aeb94a1b29c3f302@hi-jena.gsi.de> Message-ID: <9f489cb1-234c-52a2-a657-761573313acb@chalmers.se> Dear G?nter, those errors look strange to me. I am not able to reproduce on a similar system. As a workaround (to see how far we get), in subevent.h in the r3bfuser/ directory, could you uncomment these: #define MBS_TYPEDEFS_H typedef char CHARX; typedef int short INTS2; typedef int INTS4; and comment out the "typedefs.h" in /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/s_veshe.h on line 6. And then try again. Cheers, H?kan On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote: > > Dear Hans, > > > I now did rebuild NURDLIB and DRASI. Then I tried to compile R3BFUSER and this is the result: > > > RIO4-MCAL-2 mbsdaq > cd r3bfuser/ > 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 > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > UDP:ARPA_INET_H > CC??? build_cc_ppc-linux_4.2.2_debug/f_user.o > CC??? build_cc_ppc-linux_4.2.2_debug/subevent.o > In file included from /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/s_veshe.h:6, > ???????????????? from ./subevent.h:11, > ???????????????? from subevent.c:1: > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:6: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTS8' > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:7: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTU8' > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:8: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTS4' > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:9: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTU4' > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:10: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTS2' > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:11: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTU2' > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:12: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTS1' > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:13: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTU1' > In file included from ./subevent.h:11, > ???????????????? from subevent.c:1: > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/s_veshe.h:11: error: expected specifier-qualifier-list before 'INTS4' > subevent.c: In function 'begin_goosy_vme_subevent': > subevent.c:12: error: 's_veshe' has no member named 'l_dlen' > subevent.c: In function 'end_goosy_vme_subevent': > subevent.c:45: error: 's_veshe' has no member named 'l_dlen' > make[1]: *** [build_cc_ppc-linux_4.2.2_debug/subevent.o] Error 1 > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' > make: *** [drasi] Error 2 > > Reminder: I am using the most recent versions of NURDLIB and DRASI, but because of the incompatibility of the VULOM firmware I use the old version of TRLOII. In addition, > because of the leap seconds issue I compiled DRASI first on the PC and then recompiled it on the RIO (without "make clean"). > > > > > > > > Best greetings > G?nter > > > __________________________________________________________________________________________________________________________________________________________________________ > Von: Hans Toshihide T?rnqvist > Gesendet: Mittwoch, 10. Januar 2024 13:18:41 > 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, > > I would suggest rebuilding nurdlib now that trlo2 has been rebuilt, and > then also rebuild r3bfuser. > > After that probably you can try to run the DAQ :) > > Cheers, > Hans > > On 2024-01-10 13:15, Weber, Guenter Dr. wrote: > > Dear H?kan, > > > > > > using the old TRLOII folder and then recompiling was successfull. > > > > > > Should I now give it a try to start the DAQ? Or is there something else > > I still need to adjust? > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > > > > ------------------------------------------------------------------------ > > *Von:* subexp-daq im Auftrag von > > H?kan T Johansson > > *Gesendet:* Mittwoch, 10. Januar 2024 12:34:26 > > *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 > > > > Hi G?nter, > > > > On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote: > > > >> > >> Hi folks, > >> > >> > >> the old "./find_firmware.pl" was working. This is the output: > >> > >> > >> a1729cda ../ver/rimfaxe0_trlo/rfx0_defs.h > >> 0866c243 ../ver/rimfaxe1_trlo/rfx1_defs.h > >> 5e8f5ef4 ../ver/tridi1_trlo/tridi_defs.h > >> 6e4ba1a9 ../ver/vulom4_trlo/trlo_defs.h > >> 68f8955e ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h > >> af33ed35 ../ver/vulom4_trlo_big/trlo_big_defs.h > >> 1409285e ../ver/vulom4b_trlo/trlo_defs.h > >> d374466d ../fw/tridi1_trlo/tridi_defs.h > >> d96ffc88 ../fw/vulom4_trlo/trlo_defs.h > >> 5b298165 ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h > >> 6f28c0f8 ../fw/vulom4_trlo_big/trlo_big_defs.h > >> fa5020ea ../fw/vulom4_trlo_led/trlo_defs.h > >> 426cb99c ../fw/vulom4b_trlo/trlo_defs.h > >> MKDIR?? fw_a1729cda_rfx0? # ../ver/rimfaxe0_trlo/rfx0_defs.h > >> SYMLINK fw_a1729cda_rfx0/rfx0_defs.h -> ../../ver/rimfaxe0_trlo/rfx0_defs.h > >> MKDIR?? fw_0866c243_rfx1? # ../ver/rimfaxe1_trlo/rfx1_defs.h > >> SYMLINK fw_0866c243_rfx1/rfx1_defs.h -> ../../ver/rimfaxe1_trlo/rfx1_defs.h > >> MKDIR?? fw_5e8f5ef4_tridi? # ../ver/tridi1_trlo/tridi_defs.h > >> SYMLINK fw_5e8f5ef4_tridi/tridi_defs.h -> ../../ver/tridi1_trlo/tridi_defs.h > >> MKDIR?? fw_6e4ba1a9_trlo? # ../ver/vulom4_trlo/trlo_defs.h > >> SYMLINK fw_6e4ba1a9_trlo/trlo_defs.h -> ../../ver/vulom4_trlo/trlo_defs.h > >> SYMLINK fw_1409285e_trlo -> fw_6e4ba1a9_trlo > >> MKDIR?? fw_68f8955e_trlo_all_in? # ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h > >> SYMLINK fw_68f8955e_trlo_all_in/trlo_all_in_defs.h -> ../../ver/vulom4_trlo_all_in/trlo_all_in_defs.h > >> MKDIR?? fw_af33ed35_trlo_big? # ../ver/vulom4_trlo_big/trlo_big_defs.h > >> SYMLINK fw_af33ed35_trlo_big/trlo_big_defs.h -> ../../ver/vulom4_trlo_big/trlo_big_defs.h > >> MKDIR?? fw_d374466d_tridi? # ../fw/tridi1_trlo/tridi_defs.h > >> SYMLINK fw_d374466d_tridi/tridi_defs.h -> ../../fw/tridi1_trlo/tridi_defs.h > >> MKDIR?? fw_d96ffc88_trlo? # ../fw/vulom4_trlo/trlo_defs.h > >> SYMLINK fw_d96ffc88_trlo/trlo_defs.h -> ../../fw/vulom4_trlo/trlo_defs.h > >> SYMLINK fw_426cb99c_trlo -> fw_d96ffc88_trlo > >> SYMLINK fw_fa5020ea_trlo -> fw_d96ffc88_trlo > >> MKDIR?? fw_5b298165_trlo_all_in? # ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h > >> SYMLINK fw_5b298165_trlo_all_in/trlo_all_in_defs.h -> ../../fw/vulom4_trlo_all_in/trlo_all_in_defs.h > >> MKDIR?? fw_6f28c0f8_trlo_big? # ../fw/vulom4_trlo_big/trlo_big_defs.h > >> SYMLINK fw_6f28c0f8_trlo_big/trlo_big_defs.h -> ../../fw/vulom4_trlo_big/trlo_big_defs.h > >> > >> However, the compilation did end with an error: > >> > >> > >> make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo' > >> ?? CC??? bld_ppc-linux_4.2.2/src/trlo_check_version.o > >> ?? CC??? bld_ppc-linux_4.2.2/src/trlo_functions.o > >> ../trlolib/src/trlo_functions.c: In function 'trlo_clear_config': > >> ../trlolib/src/trlo_functions.c:144: error: 'trlo_setup_map' has no member named 'sync_check_start_mux' > >> ../trlolib/src/trlo_functions.c:146: error: 'trlo_setup_map' has no member named 'sync_check_stop_mux' > >> ../trlolib/src/trlo_functions.c: In function 'trlo_print_config': > >> ../trlolib/src/trlo_functions.c:825: error: 'trlo_setup_map' has no member named 'sync_check_start_mux' > >> ../trlolib/src/trlo_functions.c:829: error: 'trlo_setup_map' has no member named 'sync_check_stop_mux' > >> ../trlolib/src/trlo_functions.c: In function 'trlo_print_trig_status': > >> ../trlolib/src/trlo_functions.c:1155: error: 'trlo_output_map' has no member named 'trig_sync_check' > >> make[1]: *** [bld_ppc-linux_4.2.2/src/trlo_functions.o] Error 1 > >> make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo' > >> > >> make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi' > >> ?? CC??? bld_ppc-linux_4.2.2/src/tridi_check_version.o > >> ?? CC??? bld_ppc-linux_4.2.2/src/tridi_functions.o > >> ../trlolib/src/trlo_functions.c: In function 'tridi_clear_config': > >> ../trlolib/src/trlo_functions.c:144: error: 'tridi_setup_map' has no member named 'sync_check_start_mux' > >> ../trlolib/src/trlo_functions.c:146: error: 'tridi_setup_map' has no member named 'sync_check_stop_mux' > >> ../trlolib/src/trlo_functions.c: In function 'tridi_print_config': > >> ../trlolib/src/trlo_functions.c:825: error: 'tridi_setup_map' has no member named 'sync_check_start_mux' > >> ../trlolib/src/trlo_functions.c:829: error: 'tridi_setup_map' has no member named 'sync_check_stop_mux' > >> ../trlolib/src/trlo_functions.c: In function 'tridi_print_trig_status': > >> ../trlolib/src/trlo_functions.c:1155: error: 'tridi_output_map' has no member named 'trig_sync_check' > >> make[1]: *** [bld_ppc-linux_4.2.2/src/tridi_functions.o] Error 1 > >> make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi' > >> make: *** [fw_d374466d_tridi_build] Error 2 > > > > That's what I feared.? The new code want something (sync_check_...) not in > > the older firmware... > > > >> The fallback option is now to delete the new TRLOII folder and replace it with old one and then repeat the following steps? > >> > >> > >> cd trloii > >> make clean > >> make > >> cd trloctrl > >> make fw_d96ffc88_trlo_build > >> ?make fw_d374466d_tridi_build > >> > >> > >> Is this correct? > > > > Yes. > > > > There should then already be the trloii/fw/ directory, and the links that > > are created by find_firmware.pl > > > > > >> I also looked for the "--addr=" and this is the result: > > > >> ... > > > > Ok.? I was too optimistic here.? I looked through the grep results, but > > nothing obvious.? Should be figurable by checking the old scripts and > > following them around.? Is a good way to see how things are done anyhow ;) > > > > Cheers, > > H?kan > > > > > >> > >> > >> > >> Best greetings > >> > >> G?nter > > > > From g.weber at hi-jena.gsi.de Wed Jan 10 16:54:39 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Wed, 10 Jan 2024 15:54:39 +0000 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: <9f489cb1-234c-52a2-a657-761573313acb@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <48cae3a127fe4666901bc49eacf69d3b@hi-jena.gsi.de> <81f59eb1bbc344bf8cf703c150a1796b@hi-jena.gsi.de> <128bdcbcdaad41b4be10ecae34715fb8@hi-jena.gsi.de> <8256e7a9-82b9-e8b9-2687-ef6b3156df57@chalmers.se> <14184882-f21c-dbce-fa42-6d17901d086a@chalmers.se> <6891db86-9945-74ce-5872-9f84afa855b7@chalmers.se> <1fc55deb-35fd-a0f1-cb56-c550e36feba8@chalmers.se> <3bf5e24e-a8e4-242d-09f5-4be3198f65d2@chalmers.se> <14e1aab1db454f5da272442151f66d56@hi-jena.gsi.de> <43efd4d2fa684387b7839d88617c9e31@hi-jena.gsi.de>, <299880b3f6984312aeb94a1b29c3f302@hi-jena.gsi.de>, <9f489cb1-234c-52a2-a657-761573313acb@chalmers.se> Message-ID: <72a9169e4d764d80a72988feaff91db3@hi-jena.gsi.de> Dear H?kan, I followed your suggestion and the result is this: 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 make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' CC build_cc_ppc-linux_4.2.2_debug/subevent.o In file included from ./subevent.h:11, from subevent.c:1: /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/s_veshe.h:16: error: expected specifier-qualifier-list before 'CHARS' make[1]: *** [build_cc_ppc-linux_4.2.2_debug/subevent.o] Error 1 make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' make: *** [drasi] Error 2 Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Mittwoch, 10. Januar 2024 16:07:52 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, those errors look strange to me. I am not able to reproduce on a similar system. As a workaround (to see how far we get), in subevent.h in the r3bfuser/ directory, could you uncomment these: #define MBS_TYPEDEFS_H typedef char CHARX; typedef int short INTS2; typedef int INTS4; and comment out the "typedefs.h" in /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/s_veshe.h on line 6. And then try again. Cheers, H?kan On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote: > > Dear Hans, > > > I now did rebuild NURDLIB and DRASI. Then I tried to compile R3BFUSER and this is the result: > > > RIO4-MCAL-2 mbsdaq > cd r3bfuser/ > 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 > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > UDP:ARPA_INET_H > CC build_cc_ppc-linux_4.2.2_debug/f_user.o > CC build_cc_ppc-linux_4.2.2_debug/subevent.o > In file included from /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/s_veshe.h:6, > from ./subevent.h:11, > from subevent.c:1: > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:6: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTS8' > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:7: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTU8' > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:8: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTS4' > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:9: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTU4' > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:10: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTS2' > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:11: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTU2' > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:12: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTS1' > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:13: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTU1' > In file included from ./subevent.h:11, > from subevent.c:1: > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/s_veshe.h:11: error: expected specifier-qualifier-list before 'INTS4' > subevent.c: In function 'begin_goosy_vme_subevent': > subevent.c:12: error: 's_veshe' has no member named 'l_dlen' > subevent.c: In function 'end_goosy_vme_subevent': > subevent.c:45: error: 's_veshe' has no member named 'l_dlen' > make[1]: *** [build_cc_ppc-linux_4.2.2_debug/subevent.o] Error 1 > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' > make: *** [drasi] Error 2 > > Reminder: I am using the most recent versions of NURDLIB and DRASI, but because of the incompatibility of the VULOM firmware I use the old version of TRLOII. In addition, > because of the leap seconds issue I compiled DRASI first on the PC and then recompiled it on the RIO (without "make clean"). > > > > > > > > Best greetings > G?nter > > > __________________________________________________________________________________________________________________________________________________________________________ > Von: Hans Toshihide T?rnqvist > Gesendet: Mittwoch, 10. Januar 2024 13:18:41 > 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, > > I would suggest rebuilding nurdlib now that trlo2 has been rebuilt, and > then also rebuild r3bfuser. > > After that probably you can try to run the DAQ :) > > Cheers, > Hans > > On 2024-01-10 13:15, Weber, Guenter Dr. wrote: > > Dear H?kan, > > > > > > using the old TRLOII folder and then recompiling was successfull. > > > > > > Should I now give it a try to start the DAQ? Or is there something else > > I still need to adjust? > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > > > > ------------------------------------------------------------------------ > > *Von:* subexp-daq im Auftrag von > > H?kan T Johansson > > *Gesendet:* Mittwoch, 10. Januar 2024 12:34:26 > > *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 > > > > Hi G?nter, > > > > On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote: > > > >> > >> Hi folks, > >> > >> > >> the old "./find_firmware.pl" was working. This is the output: > >> > >> > >> a1729cda ../ver/rimfaxe0_trlo/rfx0_defs.h > >> 0866c243 ../ver/rimfaxe1_trlo/rfx1_defs.h > >> 5e8f5ef4 ../ver/tridi1_trlo/tridi_defs.h > >> 6e4ba1a9 ../ver/vulom4_trlo/trlo_defs.h > >> 68f8955e ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h > >> af33ed35 ../ver/vulom4_trlo_big/trlo_big_defs.h > >> 1409285e ../ver/vulom4b_trlo/trlo_defs.h > >> d374466d ../fw/tridi1_trlo/tridi_defs.h > >> d96ffc88 ../fw/vulom4_trlo/trlo_defs.h > >> 5b298165 ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h > >> 6f28c0f8 ../fw/vulom4_trlo_big/trlo_big_defs.h > >> fa5020ea ../fw/vulom4_trlo_led/trlo_defs.h > >> 426cb99c ../fw/vulom4b_trlo/trlo_defs.h > >> MKDIR fw_a1729cda_rfx0 # ../ver/rimfaxe0_trlo/rfx0_defs.h > >> SYMLINK fw_a1729cda_rfx0/rfx0_defs.h -> ../../ver/rimfaxe0_trlo/rfx0_defs.h > >> MKDIR fw_0866c243_rfx1 # ../ver/rimfaxe1_trlo/rfx1_defs.h > >> SYMLINK fw_0866c243_rfx1/rfx1_defs.h -> ../../ver/rimfaxe1_trlo/rfx1_defs.h > >> MKDIR fw_5e8f5ef4_tridi # ../ver/tridi1_trlo/tridi_defs.h > >> SYMLINK fw_5e8f5ef4_tridi/tridi_defs.h -> ../../ver/tridi1_trlo/tridi_defs.h > >> MKDIR fw_6e4ba1a9_trlo # ../ver/vulom4_trlo/trlo_defs.h > >> SYMLINK fw_6e4ba1a9_trlo/trlo_defs.h -> ../../ver/vulom4_trlo/trlo_defs.h > >> SYMLINK fw_1409285e_trlo -> fw_6e4ba1a9_trlo > >> MKDIR fw_68f8955e_trlo_all_in # ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h > >> SYMLINK fw_68f8955e_trlo_all_in/trlo_all_in_defs.h -> ../../ver/vulom4_trlo_all_in/trlo_all_in_defs.h > >> MKDIR fw_af33ed35_trlo_big # ../ver/vulom4_trlo_big/trlo_big_defs.h > >> SYMLINK fw_af33ed35_trlo_big/trlo_big_defs.h -> ../../ver/vulom4_trlo_big/trlo_big_defs.h > >> MKDIR fw_d374466d_tridi # ../fw/tridi1_trlo/tridi_defs.h > >> SYMLINK fw_d374466d_tridi/tridi_defs.h -> ../../fw/tridi1_trlo/tridi_defs.h > >> MKDIR fw_d96ffc88_trlo # ../fw/vulom4_trlo/trlo_defs.h > >> SYMLINK fw_d96ffc88_trlo/trlo_defs.h -> ../../fw/vulom4_trlo/trlo_defs.h > >> SYMLINK fw_426cb99c_trlo -> fw_d96ffc88_trlo > >> SYMLINK fw_fa5020ea_trlo -> fw_d96ffc88_trlo > >> MKDIR fw_5b298165_trlo_all_in # ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h > >> SYMLINK fw_5b298165_trlo_all_in/trlo_all_in_defs.h -> ../../fw/vulom4_trlo_all_in/trlo_all_in_defs.h > >> MKDIR fw_6f28c0f8_trlo_big # ../fw/vulom4_trlo_big/trlo_big_defs.h > >> SYMLINK fw_6f28c0f8_trlo_big/trlo_big_defs.h -> ../../fw/vulom4_trlo_big/trlo_big_defs.h > >> > >> However, the compilation did end with an error: > >> > >> > >> make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo' > >> CC bld_ppc-linux_4.2.2/src/trlo_check_version.o > >> CC bld_ppc-linux_4.2.2/src/trlo_functions.o > >> ../trlolib/src/trlo_functions.c: In function 'trlo_clear_config': > >> ../trlolib/src/trlo_functions.c:144: error: 'trlo_setup_map' has no member named 'sync_check_start_mux' > >> ../trlolib/src/trlo_functions.c:146: error: 'trlo_setup_map' has no member named 'sync_check_stop_mux' > >> ../trlolib/src/trlo_functions.c: In function 'trlo_print_config': > >> ../trlolib/src/trlo_functions.c:825: error: 'trlo_setup_map' has no member named 'sync_check_start_mux' > >> ../trlolib/src/trlo_functions.c:829: error: 'trlo_setup_map' has no member named 'sync_check_stop_mux' > >> ../trlolib/src/trlo_functions.c: In function 'trlo_print_trig_status': > >> ../trlolib/src/trlo_functions.c:1155: error: 'trlo_output_map' has no member named 'trig_sync_check' > >> make[1]: *** [bld_ppc-linux_4.2.2/src/trlo_functions.o] Error 1 > >> make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo' > >> > >> make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi' > >> CC bld_ppc-linux_4.2.2/src/tridi_check_version.o > >> CC bld_ppc-linux_4.2.2/src/tridi_functions.o > >> ../trlolib/src/trlo_functions.c: In function 'tridi_clear_config': > >> ../trlolib/src/trlo_functions.c:144: error: 'tridi_setup_map' has no member named 'sync_check_start_mux' > >> ../trlolib/src/trlo_functions.c:146: error: 'tridi_setup_map' has no member named 'sync_check_stop_mux' > >> ../trlolib/src/trlo_functions.c: In function 'tridi_print_config': > >> ../trlolib/src/trlo_functions.c:825: error: 'tridi_setup_map' has no member named 'sync_check_start_mux' > >> ../trlolib/src/trlo_functions.c:829: error: 'tridi_setup_map' has no member named 'sync_check_stop_mux' > >> ../trlolib/src/trlo_functions.c: In function 'tridi_print_trig_status': > >> ../trlolib/src/trlo_functions.c:1155: error: 'tridi_output_map' has no member named 'trig_sync_check' > >> make[1]: *** [bld_ppc-linux_4.2.2/src/tridi_functions.o] Error 1 > >> make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi' > >> make: *** [fw_d374466d_tridi_build] Error 2 > > > > That's what I feared. The new code want something (sync_check_...) not in > > the older firmware... > > > >> The fallback option is now to delete the new TRLOII folder and replace it with old one and then repeat the following steps? > >> > >> > >> cd trloii > >> make clean > >> make > >> cd trloctrl > >> make fw_d96ffc88_trlo_build > >> make fw_d374466d_tridi_build > >> > >> > >> Is this correct? > > > > Yes. > > > > There should then already be the trloii/fw/ directory, and the links that > > are created by find_firmware.pl > > > > > >> I also looked for the "--addr=" and this is the result: > > > >> ... > > > > Ok. I was too optimistic here. I looked through the grep results, but > > nothing obvious. Should be figurable by checking the old scripts and > > following them around. Is a good way to see how things are done anyhow ;) > > > > Cheers, > > H?kan > > > > > >> > >> > >> > >> Best greetings > >> > >> G?nter > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.tornqvist at chalmers.se Wed Jan 10 16:59:07 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Wed, 10 Jan 2024 16:59:07 +0100 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: <72a9169e4d764d80a72988feaff91db3@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <128bdcbcdaad41b4be10ecae34715fb8@hi-jena.gsi.de> <8256e7a9-82b9-e8b9-2687-ef6b3156df57@chalmers.se> <14184882-f21c-dbce-fa42-6d17901d086a@chalmers.se> <6891db86-9945-74ce-5872-9f84afa855b7@chalmers.se> <1fc55deb-35fd-a0f1-cb56-c550e36feba8@chalmers.se> <3bf5e24e-a8e4-242d-09f5-4be3198f65d2@chalmers.se> <14e1aab1db454f5da272442151f66d56@hi-jena.gsi.de> <43efd4d2fa684387b7839d88617c9e31@hi-jena.gsi.de> <299880b3f6984312aeb94a1b29c3f302@hi-jena.gsi.de> <9f489cb1-234c-52a2-a657-761573313acb@chalmers.se> <72a9169e4d764d80a72988feaff91db3@hi-jena.gsi.de> Message-ID: <2019a2ea-9480-449b-a0da-4bbed3e6a7e7@chalmers.se> Dear G?nter, Did you try to update r3bfuser? I cannot see this problem with new versions of drasi+nurdlib+r3bfuser that are on Gitlab, and the trloii version shouldn't matter much in this case. Cheers, Hans On 2024-01-10 16:54, Weber, Guenter Dr. wrote: > Dear H?kan, > > > I followed your suggestion and the result is this: > > > 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 > make[1]: Entering directory > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' > CC??? build_cc_ppc-linux_4.2.2_debug/subevent.o > In file included from ./subevent.h:11, > ???????????????? from subevent.c:1: > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/s_veshe.h:16: error: expected specifier-qualifier-list before 'CHARS' > make[1]: *** [build_cc_ppc-linux_4.2.2_debug/subevent.o] Error 1 > make[1]: Leaving directory > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' > make: *** [drasi] Error 2 > > > Best greetings > > G?nter > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > H?kan T Johansson > *Gesendet:* Mittwoch, 10. Januar 2024 16:07:52 > *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, > > those errors look strange to me.? I am not able to reproduce on a similar > system. > > As a workaround (to see how far we get), in subevent.h in the r3bfuser/ > directory, could you uncomment these: > > #define MBS_TYPEDEFS_H > typedef char CHARX; > typedef int short INTS2; > typedef int INTS4; > > and comment out the "typedefs.h" in > > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/s_veshe.h > > on line 6.? And then try again. > > Cheers, > H?kan > > > On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote: > >> >> Dear Hans, >> >> >> I now did rebuild NURDLIB and DRASI. Then I tried to compile R3BFUSER and this is the result: >> >> >> RIO4-MCAL-2 mbsdaq > cd r3bfuser/ >> 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 >> make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >> NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args >> UDP:ARPA_INET_H >> CC??? build_cc_ppc-linux_4.2.2_debug/f_user.o >> CC??? build_cc_ppc-linux_4.2.2_debug/subevent.o >> In file included from /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/s_veshe.h:6, >> ???????????????? from ./subevent.h:11, >> ???????????????? from subevent.c:1: >> /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:6: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTS8' >> /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:7: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTU8' >> /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:8: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTS4' >> /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:9: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTU4' >> /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:10: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTS2' >> /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:11: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTU2' >> /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:12: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTS1' >> /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/typedefs.h:13: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INTU1' >> In file included from ./subevent.h:11, >> ???????????????? from subevent.c:1: >> /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/s_veshe.h:11: error: expected specifier-qualifier-list before 'INTS4' >> subevent.c: In function 'begin_goosy_vme_subevent': >> subevent.c:12: error: 's_veshe' has no member named 'l_dlen' >> subevent.c: In function 'end_goosy_vme_subevent': >> subevent.c:45: error: 's_veshe' has no member named 'l_dlen' >> make[1]: *** [build_cc_ppc-linux_4.2.2_debug/subevent.o] Error 1 >> make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >> make: *** [drasi] Error 2 >> >> Reminder: I am using the most recent versions of NURDLIB and DRASI, but because of the incompatibility of the VULOM firmware I use the old version of TRLOII. In addition, >> because of the leap seconds issue I compiled DRASI first on the PC and then recompiled it on the RIO (without "make clean"). >> >> >> >> >> >> >> >> Best greetings >> G?nter >> >> >> __________________________________________________________________________________________________________________________________________________________________________ >> Von: Hans Toshihide T?rnqvist >> Gesendet: Mittwoch, 10. Januar 2024 13:18:41 >> 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, >> >> I would suggest rebuilding nurdlib now that trlo2 has been rebuilt, and >> then also rebuild r3bfuser. >> >> After that probably you can try to run the DAQ :) >> >> Cheers, >> Hans >> >> On 2024-01-10 13:15, Weber, Guenter Dr. wrote: >> > Dear H?kan, >> > >> > >> > using the old TRLOII folder and then recompiling was successfull. >> > >> > >> > Should I now give it a try to start the DAQ? Or is there something else >> > I still need to adjust? >> > >> > >> > >> > >> > Best greetings >> > >> > G?nter >> > >> > >> > >> > >> > ------------------------------------------------------------------------ >> > *Von:* subexp-daq im Auftrag von >> > H?kan T Johansson >> > *Gesendet:* Mittwoch, 10. Januar 2024 12:34:26 >> > *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 >> > >> > Hi G?nter, >> > >> > On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote: >> > >> >> >> >> Hi folks, >> >> >> >> >> >> the old "./find_firmware.pl" was working. This is the output: >> >> >> >> >> >> a1729cda ../ver/rimfaxe0_trlo/rfx0_defs.h >> >> 0866c243 ../ver/rimfaxe1_trlo/rfx1_defs.h >> >> 5e8f5ef4 ../ver/tridi1_trlo/tridi_defs.h >> >> 6e4ba1a9 ../ver/vulom4_trlo/trlo_defs.h >> >> 68f8955e ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h >> >> af33ed35 ../ver/vulom4_trlo_big/trlo_big_defs.h >> >> 1409285e ../ver/vulom4b_trlo/trlo_defs.h >> >> d374466d ../fw/tridi1_trlo/tridi_defs.h >> >> d96ffc88 ../fw/vulom4_trlo/trlo_defs.h >> >> 5b298165 ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h >> >> 6f28c0f8 ../fw/vulom4_trlo_big/trlo_big_defs.h >> >> fa5020ea ../fw/vulom4_trlo_led/trlo_defs.h >> >> 426cb99c ../fw/vulom4b_trlo/trlo_defs.h >> >> MKDIR?? fw_a1729cda_rfx0? # ../ver/rimfaxe0_trlo/rfx0_defs.h >> >> SYMLINK fw_a1729cda_rfx0/rfx0_defs.h -> ../../ver/rimfaxe0_trlo/rfx0_defs.h >> >> MKDIR?? fw_0866c243_rfx1? # ../ver/rimfaxe1_trlo/rfx1_defs.h >> >> SYMLINK fw_0866c243_rfx1/rfx1_defs.h -> ../../ver/rimfaxe1_trlo/rfx1_defs.h >> >> MKDIR?? fw_5e8f5ef4_tridi? # ../ver/tridi1_trlo/tridi_defs.h >> >> SYMLINK fw_5e8f5ef4_tridi/tridi_defs.h -> ../../ver/tridi1_trlo/tridi_defs.h >> >> MKDIR?? fw_6e4ba1a9_trlo? # ../ver/vulom4_trlo/trlo_defs.h >> >> SYMLINK fw_6e4ba1a9_trlo/trlo_defs.h -> ../../ver/vulom4_trlo/trlo_defs.h >> >> SYMLINK fw_1409285e_trlo -> fw_6e4ba1a9_trlo >> >> MKDIR?? fw_68f8955e_trlo_all_in? # ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h >> >> SYMLINK fw_68f8955e_trlo_all_in/trlo_all_in_defs.h -> ../../ver/vulom4_trlo_all_in/trlo_all_in_defs.h >> >> MKDIR?? fw_af33ed35_trlo_big? # ../ver/vulom4_trlo_big/trlo_big_defs.h >> >> SYMLINK fw_af33ed35_trlo_big/trlo_big_defs.h -> ../../ver/vulom4_trlo_big/trlo_big_defs.h >> >> MKDIR?? fw_d374466d_tridi? # ../fw/tridi1_trlo/tridi_defs.h >> >> SYMLINK fw_d374466d_tridi/tridi_defs.h -> ../../fw/tridi1_trlo/tridi_defs.h >> >> MKDIR?? fw_d96ffc88_trlo? # ../fw/vulom4_trlo/trlo_defs.h >> >> SYMLINK fw_d96ffc88_trlo/trlo_defs.h -> ../../fw/vulom4_trlo/trlo_defs.h >> >> SYMLINK fw_426cb99c_trlo -> fw_d96ffc88_trlo >> >> SYMLINK fw_fa5020ea_trlo -> fw_d96ffc88_trlo >> >> MKDIR?? fw_5b298165_trlo_all_in? # ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h >> >> SYMLINK fw_5b298165_trlo_all_in/trlo_all_in_defs.h -> ../../fw/vulom4_trlo_all_in/trlo_all_in_defs.h >> >> MKDIR?? fw_6f28c0f8_trlo_big? # ../fw/vulom4_trlo_big/trlo_big_defs.h >> >> SYMLINK fw_6f28c0f8_trlo_big/trlo_big_defs.h -> ../../fw/vulom4_trlo_big/trlo_big_defs.h >> >> >> >> However, the compilation did end with an error: >> >> >> >> >> >> make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo' >> >> ?? CC??? bld_ppc-linux_4.2.2/src/trlo_check_version.o >> >> ?? CC??? bld_ppc-linux_4.2.2/src/trlo_functions.o >> >> ../trlolib/src/trlo_functions.c: In function 'trlo_clear_config': >> >> ../trlolib/src/trlo_functions.c:144: error: 'trlo_setup_map' has no member named 'sync_check_start_mux' >> >> ../trlolib/src/trlo_functions.c:146: error: 'trlo_setup_map' has no member named 'sync_check_stop_mux' >> >> ../trlolib/src/trlo_functions.c: In function 'trlo_print_config': >> >> ../trlolib/src/trlo_functions.c:825: error: 'trlo_setup_map' has no member named 'sync_check_start_mux' >> >> ../trlolib/src/trlo_functions.c:829: error: 'trlo_setup_map' has no member named 'sync_check_stop_mux' >> >> ../trlolib/src/trlo_functions.c: In function 'trlo_print_trig_status': >> >> ../trlolib/src/trlo_functions.c:1155: error: 'trlo_output_map' has no member named 'trig_sync_check' >> >> make[1]: *** [bld_ppc-linux_4.2.2/src/trlo_functions.o] Error 1 >> >> make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo' >> >> >> >> make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi' >> >> ?? CC??? bld_ppc-linux_4.2.2/src/tridi_check_version.o >> >> ?? CC??? bld_ppc-linux_4.2.2/src/tridi_functions.o >> >> ../trlolib/src/trlo_functions.c: In function 'tridi_clear_config': >> >> ../trlolib/src/trlo_functions.c:144: error: 'tridi_setup_map' has no member named 'sync_check_start_mux' >> >> ../trlolib/src/trlo_functions.c:146: error: 'tridi_setup_map' has no member named 'sync_check_stop_mux' >> >> ../trlolib/src/trlo_functions.c: In function 'tridi_print_config': >> >> ../trlolib/src/trlo_functions.c:825: error: 'tridi_setup_map' has no member named 'sync_check_start_mux' >> >> ../trlolib/src/trlo_functions.c:829: error: 'tridi_setup_map' has no member named 'sync_check_stop_mux' >> >> ../trlolib/src/trlo_functions.c: In function 'tridi_print_trig_status': >> >> ../trlolib/src/trlo_functions.c:1155: error: 'tridi_output_map' has no member named 'trig_sync_check' >> >> make[1]: *** [bld_ppc-linux_4.2.2/src/tridi_functions.o] Error 1 >> >> make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi' >> >> make: *** [fw_d374466d_tridi_build] Error 2 >> > >> > That's what I feared.? The new code want something (sync_check_...) not in >> > the older firmware... >> > >> >> The fallback option is now to delete the new TRLOII folder and replace it with old one and then repeat the following steps? >> >> >> >> >> >> cd trloii >> >> make clean >> >> make >> >> cd trloctrl >> >> make fw_d96ffc88_trlo_build >> >> ?make fw_d374466d_tridi_build >> >> >> >> >> >> Is this correct? >> > >> > Yes. >> > >> > There should then already be the trloii/fw/ directory, and the links that >> > are created by find_firmware.pl >> > >> > >> >> I also looked for the "--addr=" and this is the result: >> > >> >> ... >> > >> > Ok.? I was too optimistic here.? I looked through the grep results, but >> > nothing obvious.? Should be figurable by checking the old scripts and >> > following them around.? Is a good way to see how things are done anyhow ;) >> > >> > Cheers, >> > H?kan >> > >> > >> >> >> >> >> >> >> >> Best greetings >> >> >> >> G?nter >> > >> >> > From f96hajo at chalmers.se Thu Jan 11 08:27:18 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Thu, 11 Jan 2024 08:27:18 +0100 Subject: [subexp-daq] DAQ compile from scratch Message-ID: (Meant to sent to the full list...) Dear G?nter, It sounds like a very nice plan if you have the hardware to set up a second system from scratch. I have attached a short instruction on how to downloading and compiling the codes from scratch. It would not surprise me if there already exist something like that, but then we have two of them :-) If not, we can put this (with whatever fixes are needed) up somewhere (gitlab wiki or so). I did test it - but that does not guarantee much... Cheers, H?kan From g.weber at hi-jena.gsi.de Thu Jan 11 11:23:50 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Thu, 11 Jan 2024 10:23:50 +0000 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: <47cf2d4c-f59c-6ea7-86ea-f5ec88eabb5c@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <6891db86-9945-74ce-5872-9f84afa855b7@chalmers.se> <1fc55deb-35fd-a0f1-cb56-c550e36feba8@chalmers.se> <3bf5e24e-a8e4-242d-09f5-4be3198f65d2@chalmers.se> <14e1aab1db454f5da272442151f66d56@hi-jena.gsi.de> <43efd4d2fa684387b7839d88617c9e31@hi-jena.gsi.de> <299880b3f6984312aeb94a1b29c3f302@hi-jena.gsi.de> <9f489cb1-234c-52a2-a657-761573313acb@chalmers.se> <72a9169e4d764d80a72988feaff91db3@hi-jena.gsi.de> <2019a2ea-9480-449b-a0da-4bbed3e6a7e7@chalmers.se> <34e673ef4a3f4664989b3167b6a6c335@hi-jena.gsi.de>, <26dc0c59-5ac1-4073-bc26-aaf081dc8eb6@chalmers.se>, <35fc1cdfa4484b298214067c37448ffb@hi-jena.gsi.de> , <47cf2d4c-f59c-6ea7-86ea-f5ec88eabb5c@chalmers.se> Message-ID: <9365f778400b435e9b3211fed00e8e49@hi-jena.gsi.de> Dear H?kan, dear Hans, 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? 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? Best greetings G?nter ________________________________ Von: H?kan T Johansson Gesendet: Donnerstag, 11. Januar 2024 08:15:14 An: Weber, Guenter Dr. Cc: Hans Toshihide T?rnqvist Betreff: Re: AW: AW: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version Dear G?nter, thanks! 1) may be the reason for that strange error in typedefs.h, since it may be that it picks up the mystdint.h from the trloii compile but uses it in the drasi header somehow - or vice versa.... (They are the same and typically kept in sync, but we may here have hit a snag with the different versions and an update I did a while ago...) 2) Should be fine, is just an attempt at indenting the pre-processor directives, without having my editor unindent the code. It sounds like a very nice plan if you have the hardware to set up a second system from scratch. I have attached a short instruction on how to downloading and compiling the codes from scratch. It would not surprise me if there already exist something like that, but then we have two of them :-) If not, we can put this (with whatever fixes are needed) up somewhere (gitlab wiki or so). I did test it - but that does not guarantee much... Cheers, H?kan On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote: > > P.S. I looked a bit into the code that is compiled right before the error > appear. > > > I have no idea if this might causing problems, but in > > ../dtc_arch/acc_def/mystdint.h > I found two things: > > > 1) > > New version: > > #if ACC_DEF__MYSTDINT_stdint_h > # include > #endif > /* This is a local fall-back solution, so should be last. */ > #if ACC_DEF__MYSTDINT_mystdint > > Old version: > > #if ACC_DEF_MYSTDINT_stdint_h > # include > #endif > /* This is a local fall-back solution, so should be last. */ > #if ACC_DEF_MYSTDINT_mystdint > > (Note the double "_" before MYSTDINT.) > > > 2) > > In both versions there are strange blanks after "#" at two positions: > > # include "acc_auto_def/mystdint.h" > # define UINT64_C(v) v##ULL > > > > Best greetings > > G?nter > > > ____________________________________________________________________________ > Von: Weber, Guenter Dr. > Gesendet: Mittwoch, 10. Januar 2024 19:32:59 > An: Hans Toshihide T?rnqvist > Betreff: AW: AW: [subexp-daq] NURDLIB: - how to check which version is > installed and how to update to the most recent version > > Dear Hans, > > > I could not reproduce the error from two hours ago. Nurdlib was laready set > to the right branch and in a second try compiled without problems on the > RIO. > > > However, we are now back at square one: > > > 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 > make[1]: Entering directory > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > UDP:ARPA_INET_H > CC build_cc_ppc-linux_4.2.2_debug/f_user.o > CC build_cc_ppc-linux_4.2.2_debug/subevent.o > In file included from/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ > s_veshe.h:6, > from ./subevent.h:11, > from subevent.c:1: > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ > typedefs.h:6: error: expected '=', ',', ';', 'asm' or '__attribute__' > before 'INTS8' > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ > typedefs.h:7: error: expected '=', ',', ';', 'asm' or '__attribute__' > before 'INTU8' > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ > typedefs.h:8: error: expected '=', ',', ';', 'asm' or '__attribute__' > before 'INTS4' > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ > typedefs.h:9: error: expected '=', ',', ';', 'asm' or '__attribute__' > before 'INTU4' > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ > typedefs.h:10: error: expected '=', ',', ';', 'asm' or '__attribute__' > before 'INTS2' > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ > typedefs.h:11: error: expected '=', ',', ';', 'asm' or '__attribute__' > before 'INTU2' > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ > typedefs.h:12: error: expected '=', ',', ';', 'asm' or '__attribute__' > before 'INTS1' > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ > typedefs.h:13: error: expected '=', ',', ';', 'asm' or '__attribute__' > before 'INTU1' > In file included from ./subevent.h:11, > from subevent.c:1: > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ > s_veshe.h:11: error: expected specifier-qualifier-list before 'INTS4' > subevent.c: In function 'begin_goosy_vme_subevent': > subevent.c:12: error: 's_veshe' has no member named 'l_dlen' > subevent.c: In function 'end_goosy_vme_subevent': > subevent.c:45: error: 's_veshe' has no member named 'l_dlen' > make[1]: *** [build_cc_ppc-linux_4.2.2_debug/subevent.o] Error 1 > make[1]: Leaving directory > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' > make: *** [drasi] Error 2 > RIO4-MCAL-2 mbsdaq > > > Thus, downloading and recompiling DRASI, NURDLIB, and R3BFUSER did not solve > the problem with the latter. > > > > ? > > > > > > > Best greetings > > G?nter > > > > > ____________________________________________________________________________ > Von: Hans Toshihide T?rnqvist > Gesendet: Mittwoch, 10. Januar 2024 18:24:21 > An: Weber, Guenter Dr. > Betreff: Re: AW: [subexp-daq] NURDLIB: - how to check which version is > installed and how to update to the most recent version > Sorry I got held up. > > I compiled 'mcal_daq_merge' from Gitlab on a rio4 just fine, so I am > just as puzzled where those event buffer test errors come from... > > Any luck with a 'make clean && make'? > > Cheers, > > Hans > > On 2024-01-10 17:36, Weber, Guenter Dr. wrote: > > Dear Hans, > > > > > > now things really get weird. > > > > > > I again downloaded NURDLIB, DRASI, and R3BFUSER. DRASI compiled without > > problems (first on PC, then on RIO). > > > > > > Now NURDLIB compilation stops with an error: > > > > > > LD build_cc_ppc-linux_4.2.2_debug/test_ntest > > LD build_cc_ppc-linux_4.2.2_debug/test > > /bin/sh: line 1: 22504 Aborted > > ./build_cc_ppc-linux_4.2.2_debug/test > > > build_cc_ppc-linux_4.2.2_debug/test.log 2>&1 > > [tests/argmatch.c:127: Shorts] > > [tests/argmatch.c:128: Longs] > > [tests/argmatch.c:129: Combos] > > [tests/argmatch.c:130: ShortsWithValues] > > [tests/argmatch.c:131: LongsWithValues] > > [tests/argmatch.c:132: MissingValue] > > [tests/base.c:110: MemoryCheck] > > [tests/base.c:111: EventBufferAdvance] > > 2024-02-10,19:58:33:ERRR: Invalid pointer to advance event buffer. > > [tests/base.c:47] > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:47] > > 2024-02-10,19:58:33:ERRR: Invalid pointer to advance event buffer. > > [tests/base.c:56] > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:56] > > 2024-02-10,19:58:33:ERRR: Tried to advance outside event buffer. > > [tests/base.c:72] > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:72] > > [tests/base.c:112: EventBufferInvariant] > > 2024-02-10,19:58:33:ERRR: Event-buffer inconsistent (0x1080e008:11 != > > 0x1080e008:10). [tests/base.c:87] > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:87] > > 2024-02-10,19:58:33:ERRR: Event-buffer inconsistent (0x1080e008:9 != > > 0x1080e008:10). [tests/base.c:91] > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:91] > > 2024-02-10,19:58:33:ERRR: Event-buffer inconsistent (0x1080e009:10 != > > 0x1080e008:10). [tests/base.c:95] > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:95] > > 2024-02-10,19:58:33:ERRR: Event-buffer inconsistent (0x1080e007:10 != > > 0x1080e008:10). [tests/base.c:99] > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:99] > > [tests/bits.c:43: Gets] > > [tests/bits.c:44: CountLoops] > > [tests/caen_v1190.c:79: DefaultConfig] > > 2024-02-10,19:58:33:INFO: Will try default cfg > > path='/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg', > > can be set with NURDLIB_DEF_PATH. [config/config.c:181] > > 2024-02-10,19:58:33:INFO: Opened './tests/caen_v1190_empty.cfg' { > > [config/parser.c:287] > > 2024-02-10,19:58:33:ERRR: .Could not load default or user config > > 'caen_v1190.cfg'. [config/config.c:1483] > > 2024-02-10,19:58:33:ERRR: .Calling abort()... [config/config.c:1483] > > make: *** [build_cc_ppc-linux_4.2.2_debug/test_ok] Error 1 > > > > > > Did you change anything in the GITLAB version between yesterday and 15 > > minutes ago? > > > > > > > > Sorry, sorry, sorry ? > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > > P.S. Tomorrow or on Friday, I will set up a second DAQ system with > > identical hardware. Then we can play around with no limits, including > > flashing the firmware of the VULOM, without messing around with the > > already running system as it is the case now. > > > > > > ------------------------------------------------------------------------ > > *Von:* Hans Toshihide T?rnqvist > > *Gesendet:* Mittwoch, 10. Januar 2024 16:59:07 > > *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, > > > > Did you try to update r3bfuser? I cannot see this problem with new > > versions of drasi+nurdlib+r3bfuser that are on Gitlab, and the trloii > > version shouldn't matter much in this case. > > > > Cheers, > > > > Hans > > > > On 2024-01-10 16:54, Weber, Guenter Dr. wrote: > >> Dear H?kan, > >> > >> > >> I followed your suggestion and the result is this: > >> > >> > >> 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 > >> make[1]: Entering directory > >> `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' > >> CC build_cc_ppc-linux_4.2.2_debug/subevent.o > >> In file included from ./subevent.h:11, > >> from subevent.c:1: > >>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ > s_veshe.h:16: error: expected specifier-qualifier-list before 'CHARS' > >> make[1]: *** [build_cc_ppc-linux_4.2.2_debug/subevent.o] Error 1 > >> make[1]: Leaving directory > >> `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' > >> make: *** [drasi] Error 2 > >> > >> > >> Best greetings > >> > >> G?nter > >> > >> > >> ------------------------------------------------------------------------ > >> *Von:* subexp-daq im Auftrag von > >> H?kan T Johansson > >> *Gesendet:* Mittwoch, 10. Januar 2024 16:07:52 > >> *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, > >> > >> those errors look strange to me. I am not able to reproduce on a similar > >> system. > >> > >> As a workaround (to see how far we get), in subevent.h in the r3bfuser/ > >> directory, could you uncomment these: > >> > >> #define MBS_TYPEDEFS_H > >> typedef char CHARX; > >> typedef int short INTS2; > >> typedef int INTS4; > >> > >> and comment out the "typedefs.h" in > >> > >>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ > s_veshe.h > >> > >> on line 6. And then try again. > >> > >> Cheers, > >> H?kan > >> > >> > >> On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote: > >> > >>> > >>> Dear Hans, > >>> > >>> > >>> I now did rebuild NURDLIB and DRASI. Then I tried to compile R3BFUSER > and this is the result: > >>> > >>> > >>> RIO4-MCAL-2 mbsdaq > cd r3bfuser/ > >>> 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 > >>> make[1]: Entering directory > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' > >>> NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > >>> UDP:ARPA_INET_H > >>> CC build_cc_ppc-linux_4.2.2_debug/f_user.o > >>> CC build_cc_ppc-linux_4.2.2_debug/subevent.o > >>> In file included from/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ > s_veshe.h:6, > >>> from ./subevent.h:11, > >>> from subevent.c:1: > >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ > typedefs.h:6: error: expected '=', ',', ';', 'asm' or '__attribute__' > before 'INTS8' > >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ > typedefs.h:7: error: expected '=', ',', ';', 'asm' or '__attribute__' > before 'INTU8' > >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ > typedefs.h:8: error: expected '=', ',', ';', 'asm' or '__attribute__' > before 'INTS4' > >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ > typedefs.h:9: error: expected '=', ',', ';', 'asm' or '__attribute__' > before 'INTU4' > >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ > typedefs.h:10: error: expected '=', ',', ';', 'asm' or '__attribute__' > before 'INTS2' > >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ > typedefs.h:11: error: expected '=', ',', ';', 'asm' or '__attribute__' > before 'INTU2' > >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ > typedefs.h:12: error: expected '=', ',', ';', 'asm' or '__attribute__' > before 'INTS1' > >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ > typedefs.h:13: error: expected '=', ',', ';', 'asm' or '__attribute__' > before 'INTU1' > >>> In file included from ./subevent.h:11, > >>> from subevent.c:1: > >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ > s_veshe.h:11: error: expected specifier-qualifier-list before 'INTS4' > >>> subevent.c: In function 'begin_goosy_vme_subevent': > >>> subevent.c:12: error: 's_veshe' has no member named 'l_dlen' > >>> subevent.c: In function 'end_goosy_vme_subevent': > >>> subevent.c:45: error: 's_veshe' has no member named 'l_dlen' > >>> make[1]: *** [build_cc_ppc-linux_4.2.2_debug/subevent.o] Error 1 > >>> make[1]: Leaving directory > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' > >>> make: *** [drasi] Error 2 > >>> > >>> Reminder: I am using the most recent versions of NURDLIB and DRASI, but > because of the incompatibility of the VULOM firmware I use the old version > of TRLOII. In addition, > >>> because of the leap seconds issue I compiled DRASI first on the PC and > then recompiled it on the RIO (without "make clean"). > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Best greetings > >>> G?nter > >>> > >>> > >>>___________________________________________________________________________ > __________________________________________________________________________ > _____________________ > >>> Von: Hans Toshihide T?rnqvist > >>> Gesendet: Mittwoch, 10. Januar 2024 13:18:41 > >>> 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, > >>> > >>> I would suggest rebuilding nurdlib now that trlo2 has been rebuilt, and > >>> then also rebuild r3bfuser. > >>> > >>> After that probably you can try to run the DAQ :) > >>> > >>> Cheers, > >>> Hans > >>> > >>> On 2024-01-10 13:15, Weber, Guenter Dr. wrote: > >>> > Dear H?kan, > >>> > > >>> > > >>> > using the old TRLOII folder and then recompiling was successfull. > >>> > > >>> > > >>> > Should I now give it a try to start the DAQ? Or is there something > else > >>> > I still need to adjust? > >>> > > >>> > > >>> > > >>> > > >>> > Best greetings > >>> > > >>> > G?nter > >>> > > >>> > > >>> > > >>> > > >>> > > ------------------------------------------------------------------------ > >>> > *Von:* subexp-daq im Auftrag > von > >>> > H?kan T Johansson > >>> > *Gesendet:* Mittwoch, 10. Januar 2024 12:34:26 > >>> > *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 > >>> > > >>> > Hi G?nter, > >>> > > >>> > On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote: > >>> > > >>> >> > >>> >> Hi folks, > >>> >> > >>> >> > >>> >> the old "./find_firmware.pl" was working. This is the output: > >>> >> > >>> >> > >>> >> a1729cda ../ver/rimfaxe0_trlo/rfx0_defs.h > >>> >> 0866c243 ../ver/rimfaxe1_trlo/rfx1_defs.h > >>> >> 5e8f5ef4 ../ver/tridi1_trlo/tridi_defs.h > >>> >> 6e4ba1a9 ../ver/vulom4_trlo/trlo_defs.h > >>> >> 68f8955e ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h > >>> >> af33ed35 ../ver/vulom4_trlo_big/trlo_big_defs.h > >>> >> 1409285e ../ver/vulom4b_trlo/trlo_defs.h > >>> >> d374466d ../fw/tridi1_trlo/tridi_defs.h > >>> >> d96ffc88 ../fw/vulom4_trlo/trlo_defs.h > >>> >> 5b298165 ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h > >>> >> 6f28c0f8 ../fw/vulom4_trlo_big/trlo_big_defs.h > >>> >> fa5020ea ../fw/vulom4_trlo_led/trlo_defs.h > >>> >> 426cb99c ../fw/vulom4b_trlo/trlo_defs.h > >>> >> MKDIR fw_a1729cda_rfx0 # ../ver/rimfaxe0_trlo/rfx0_defs.h > >>> >> SYMLINK fw_a1729cda_rfx0/rfx0_defs.h -> > ../../ver/rimfaxe0_trlo/rfx0_defs.h > >>> >> MKDIR fw_0866c243_rfx1 # ../ver/rimfaxe1_trlo/rfx1_defs.h > >>> >> SYMLINK fw_0866c243_rfx1/rfx1_defs.h -> > ../../ver/rimfaxe1_trlo/rfx1_defs.h > >>> >> MKDIR fw_5e8f5ef4_tridi # ../ver/tridi1_trlo/tridi_defs.h > >>> >> SYMLINK fw_5e8f5ef4_tridi/tridi_defs.h -> > ../../ver/tridi1_trlo/tridi_defs.h > >>> >> MKDIR fw_6e4ba1a9_trlo # ../ver/vulom4_trlo/trlo_defs.h > >>> >> SYMLINK fw_6e4ba1a9_trlo/trlo_defs.h -> > ../../ver/vulom4_trlo/trlo_defs.h > >>> >> SYMLINK fw_1409285e_trlo -> fw_6e4ba1a9_trlo > >>> >> MKDIR fw_68f8955e_trlo_all_in # > ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h > >>> >> SYMLINK fw_68f8955e_trlo_all_in/trlo_all_in_defs.h -> > ../../ver/vulom4_trlo_all_in/trlo_all_in_defs.h > >>> >> MKDIR fw_af33ed35_trlo_big # > ../ver/vulom4_trlo_big/trlo_big_defs.h > >>> >> SYMLINK fw_af33ed35_trlo_big/trlo_big_defs.h -> > ../../ver/vulom4_trlo_big/trlo_big_defs.h > >>> >> MKDIR fw_d374466d_tridi # ../fw/tridi1_trlo/tridi_defs.h > >>> >> SYMLINK fw_d374466d_tridi/tridi_defs.h -> > ../../fw/tridi1_trlo/tridi_defs.h > >>> >> MKDIR fw_d96ffc88_trlo # ../fw/vulom4_trlo/trlo_defs.h > >>> >> SYMLINK fw_d96ffc88_trlo/trlo_defs.h -> > ../../fw/vulom4_trlo/trlo_defs.h > >>> >> SYMLINK fw_426cb99c_trlo -> fw_d96ffc88_trlo > >>> >> SYMLINK fw_fa5020ea_trlo -> fw_d96ffc88_trlo > >>> >> MKDIR fw_5b298165_trlo_all_in # > ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h > >>> >> SYMLINK fw_5b298165_trlo_all_in/trlo_all_in_defs.h -> > ../../fw/vulom4_trlo_all_in/trlo_all_in_defs.h > >>> >> MKDIR fw_6f28c0f8_trlo_big # ../fw/vulom4_trlo_big/trlo_big_defs.h > >>> >> SYMLINK fw_6f28c0f8_trlo_big/trlo_big_defs.h -> > ../../fw/vulom4_trlo_big/trlo_big_defs.h > >>> >> > >>> >> However, the compilation did end with an error: > >>> >> > >>> >> > >>> >> make[1]: Entering directory`/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ff > c88_trlo' > >>> >> CC bld_ppc-linux_4.2.2/src/trlo_check_version.o > >>> >> CC bld_ppc-linux_4.2.2/src/trlo_functions.o > >>> >> ../trlolib/src/trlo_functions.c: In function 'trlo_clear_config': > >>> >> ../trlolib/src/trlo_functions.c:144: error: 'trlo_setup_map' has no > member named 'sync_check_start_mux' > >>> >> ../trlolib/src/trlo_functions.c:146: error: 'trlo_setup_map' has no > member named 'sync_check_stop_mux' > >>> >> ../trlolib/src/trlo_functions.c: In function 'trlo_print_config': > >>> >> ../trlolib/src/trlo_functions.c:825: error: 'trlo_setup_map' has no > member named 'sync_check_start_mux' > >>> >> ../trlolib/src/trlo_functions.c:829: error: 'trlo_setup_map' has no > member named 'sync_check_stop_mux' > >>> >> ../trlolib/src/trlo_functions.c: In function > 'trlo_print_trig_status': > >>> >> ../trlolib/src/trlo_functions.c:1155: error: 'trlo_output_map' has no > member named 'trig_sync_check' > >>> >> make[1]: *** [bld_ppc-linux_4.2.2/src/trlo_functions.o] Error 1 > >>> >> make[1]: Leaving directory`/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ff > c88_trlo' > >>> >> > >>> >> make[1]: Entering directory`/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d3744 > 66d_tridi' > >>> >> CC bld_ppc-linux_4.2.2/src/tridi_check_version.o > >>> >> CC bld_ppc-linux_4.2.2/src/tridi_functions.o > >>> >> ../trlolib/src/trlo_functions.c: In function 'tridi_clear_config': > >>> >> ../trlolib/src/trlo_functions.c:144: error: 'tridi_setup_map' has no > member named 'sync_check_start_mux' > >>> >> ../trlolib/src/trlo_functions.c:146: error: 'tridi_setup_map' has no > member named 'sync_check_stop_mux' > >>> >> ../trlolib/src/trlo_functions.c: In function 'tridi_print_config': > >>> >> ../trlolib/src/trlo_functions.c:825: error: 'tridi_setup_map' has no > member named 'sync_check_start_mux' > >>> >> ../trlolib/src/trlo_functions.c:829: error: 'tridi_setup_map' has no > member named 'sync_check_stop_mux' > >>> >> ../trlolib/src/trlo_functions.c: In function > 'tridi_print_trig_status': > >>> >> ../trlolib/src/trlo_functions.c:1155: error: 'tridi_output_map' has > no member named 'trig_sync_check' > >>> >> make[1]: *** [bld_ppc-linux_4.2.2/src/tridi_functions.o] Error 1 > >>> >> make[1]: Leaving directory`/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d3744 > 66d_tridi' > >>> >> make: *** [fw_d374466d_tridi_build] Error 2 > >>> > > >>> > That's what I feared. The new code want something (sync_check_...) > not in > >>> > the older firmware... > >>> > > >>> >> The fallback option is now to delete the new TRLOII folder and > replace it with old one and then repeat the following steps? > >>> >> > >>> >> > >>> >> cd trloii > >>> >> make clean > >>> >> make > >>> >> cd trloctrl > >>> >> make fw_d96ffc88_trlo_build > >>> >> make fw_d374466d_tridi_build > >>> >> > >>> >> > >>> >> Is this correct? > >>> > > >>> > Yes. > >>> > > >>> > There should then already be the trloii/fw/ directory, and the links > that > >>> > are created by find_firmware.pl > >>> > > >>> > > >>> >> I also looked for the "--addr=" and this is the result: > >>> > > >>> >> ... > >>> > > >>> > Ok. I was too optimistic here. I looked through the grep results, > but > >>> > nothing obvious. Should be figurable by checking the old scripts and > >>> > following them around. Is a good way to see how things are done > anyhow ;) > >>> > > >>> > Cheers, > >>> > H?kan > >>> > > >>> > > >>> >> > >>> >> > >>> >> > >>> >> Best greetings > >>> >> > >>> >> G?nter > >>> > > >>> > >>> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Thu Jan 11 14:11:31 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Thu, 11 Jan 2024 14:11:31 +0100 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: <9365f778400b435e9b3211fed00e8e49@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <1fc55deb-35fd-a0f1-cb56-c550e36feba8@chalmers.se> <3bf5e24e-a8e4-242d-09f5-4be3198f65d2@chalmers.se> <14e1aab1db454f5da272442151f66d56@hi-jena.gsi.de> <43efd4d2fa684387b7839d88617c9e31@hi-jena.gsi.de> <299880b3f6984312aeb94a1b29c3f302@hi-jena.gsi.de> <9f489cb1-234c-52a2-a657-761573313acb@chalmers.se> <72a9169e4d764d80a72988feaff91db3@hi-jena.gsi.de> <2019a2ea-9480-449b-a0da-4bbed3e6a7e7@chalmers.se> <34e673ef4a3f4664989b3167b6a6c335@hi-jena.gsi.de>, <26dc0c59-5ac1-4073-bc26-aaf081dc8eb6@chalmers.se>, <35fc1cdfa4484b298214067c37448ffb@hi-jena.gsi.de> , <47cf2d4c-f59c-6ea7-86ea-f5ec88eabb5c@chalmers.se> <9365f778400b435e9b3211fed00e8e49@hi-jena.gsi.de> Message-ID: On Thu, 11 Jan 2024, Weber, Guenter Dr. wrote: > > Dear H?kan, dear Hans, > > > 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? Agree, sounds likely. > 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? Yes. Will hopefully be a more pleasant experience. Cheers, H?kan > Best greetings > > G?nter > > > ____________________________________________________________________________ > Von: H?kan T Johansson > Gesendet: Donnerstag, 11. Januar 2024 08:15:14 > An: Weber, Guenter Dr. > Cc: Hans Toshihide T?rnqvist > Betreff: Re: AW: AW: [subexp-daq] NURDLIB: - how to check which version is > installed and how to update to the most recent version ? > > Dear G?nter, > > thanks! > > 1) may be the reason for that strange error in typedefs.h, since it may be > that it picks up the mystdint.h from the trloii compile but uses it in the > drasi header somehow - or vice versa....? (They are the same and typically > kept in sync, but we may here have hit a snag with the different versions > and an update I did a while ago...) > > 2) Should be fine, is just an attempt at indenting the pre-processor > directives, without having my editor unindent the code. > > > It sounds like a very nice plan if you have the hardware to set up a > second system from scratch.? I have attached a short instruction on how to > downloading and compiling the codes from scratch. > > It would not surprise me if there already exist something like that, but > then we have two of them :-)? If not, we can put this (with whatever fixes > are needed) up somewhere (gitlab wiki or so). > > I did test it - but that does not guarantee much... > > Cheers, > H?kan From g.weber at hi-jena.gsi.de Fri Jan 12 15:33:54 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Fri, 12 Jan 2024 14:33:54 +0000 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: <52af1da7-5486-420b-b6af-b67693bdc213@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <3bf5e24e-a8e4-242d-09f5-4be3198f65d2@chalmers.se> <14e1aab1db454f5da272442151f66d56@hi-jena.gsi.de> <43efd4d2fa684387b7839d88617c9e31@hi-jena.gsi.de> <299880b3f6984312aeb94a1b29c3f302@hi-jena.gsi.de> <9f489cb1-234c-52a2-a657-761573313acb@chalmers.se> <72a9169e4d764d80a72988feaff91db3@hi-jena.gsi.de> <2019a2ea-9480-449b-a0da-4bbed3e6a7e7@chalmers.se> <34e673ef4a3f4664989b3167b6a6c335@hi-jena.gsi.de> <26dc0c59-5ac1-4073-bc26-aaf081dc8eb6@chalmers.se> <35fc1cdfa4484b298214067c37448ffb@hi-jena.gsi.de> <47cf2d4c-f59c-6ea7-86ea-f5ec88eabb5c@chalmers.se> <77f957cf-d6cc-d9d7-c96f-5c0dbb8a16d9@chalmers.se> , <52af1da7-5486-420b-b6af-b67693bdc213@chalmers.se> Message-ID: Dear friends, I did set up a second DAQ system and followed the instructions provided by Everything goes smoothly (I had to use the workaround in TRLOII) until compilation of R3DFUSER. This is the output (compilation done on the RIO): RIO4-MCAL-1 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 make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args udp.h: Could not configure module UDP, build_cc_ppc-linux_4.2.2_debug/nconf/udp.h.log: === UDP:ARPA_INET_H === run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mUDP=1 -DDRASI -I. -Ibuild_cc_ppc-linux_4.2.2_debug -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.bin build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -DDRASI -I. -Ibuild_cc_ppc-linux_4.2.2_debug -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames -L../nurdlib/build_cc_ppc-linux_4.2.2_debug /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -lnurdlib -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/lib_ppc-linux_4.2.2 -llwroc_mbscompat -llwroc_main -llwroc_readout -llwroc_nofilter -llwroc -llwroc_netutil -llwroc_parseutil -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -lpthread -lrt -lm -lcesXpcLib -lncurses -llwroc_hwmap_error cc: /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a: No such file or directory cc: /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a: No such file or directory Failed. === UDP:NETINET_IN_H === run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mUDP=1 -DDRASI -I. -Ibuild_cc_ppc-linux_4.2.2_debug -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.bin build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -DDRASI -I. -Ibuild_cc_ppc-linux_4.2.2_debug -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames -L../nurdlib/build_cc_ppc-linux_4.2.2_debug /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -lnurdlib -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/lib_ppc-linux_4.2.2 -llwroc_mbscompat -llwroc_main -llwroc_readout -llwroc_nofilter -llwroc -llwroc_netutil -llwroc_parseutil -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -lpthread -lrt -lm -lcesXpcLib -lncurses -llwroc_hwmap_error cc: /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a: No such file or directory cc: /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a: No such file or directory Failed. === UDP:BSD_IN_H === run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mUDP=1 -DDRASI -I. -Ibuild_cc_ppc-linux_4.2.2_debug -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.bin build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -DDRASI -I. -Ibuild_cc_ppc-linux_4.2.2_debug -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames -L../nurdlib/build_cc_ppc-linux_4.2.2_debug /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -lnurdlib -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/lib_ppc-linux_4.2.2 -llwroc_mbscompat -llwroc_main -llwroc_readout -llwroc_nofilter -llwroc -llwroc_netutil -llwroc_parseutil -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -lpthread -lrt -lm -lcesXpcLib -lncurses -llwroc_hwmap_error cc: /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a: No such file or directory cc: /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a: No such file or directory Failed. make[1]: *** [build_cc_ppc-linux_4.2.2_debug/nconf.args] Error 1 make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' make: *** [drasi] Error 2 I had a look at the environment variables which I took over from the already existing system and I guess, I would need to modify some of these lines: VULOM4_CTRL=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/bin_ppc-linux_4.2.2/trlo_ctrl TRIDI_CTRL=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/bin_ppc-linux_4.2.2/tridi_ctrl This is the content of the folder on the new system: mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl$ ls -l insgesamt 52 drwxr-sr-x 2 mbsdaq users 4096 Jan 12 13:57 examples -rwxr-xr-x 1 mbsdaq users 7389 Jan 12 13:57 find_firmwares.pl -rw-r--r-- 1 mbsdaq users 114 Jan 12 15:02 firmwaredirs drwxr-sr-x 2 mbsdaq users 4096 Jan 12 15:00 fw_0866c243_rfx1 lrwxrwxrwx 1 mbsdaq users 16 Jan 12 15:00 fw_1409285e_trlo -> fw_6e4ba1a9_trlo drwxr-sr-x 2 mbsdaq users 4096 Jan 12 15:00 fw_5e8f5ef4_tridi drwxr-sr-x 2 mbsdaq users 4096 Jan 12 15:00 fw_68f8955e_trlo_all_in drwxr-sr-x 14 mbsdaq users 4096 Jan 12 15:02 fw_6e4ba1a9_trlo drwxr-sr-x 2 mbsdaq users 4096 Jan 12 15:00 fw_a1729cda_rfx0 lrwxrwxrwx 1 mbsdaq users 16 Jan 12 15:00 fw_a73c5093_trlo -> fw_6e4ba1a9_trlo drwxr-sr-x 2 mbsdaq users 4096 Jan 12 15:00 fw_af33ed35_trlo_big -rw-r--r-- 1 mbsdaq users 994 Jan 12 13:57 Makefile -rwxr-xr-x 1 mbsdaq users 662 Jan 12 13:57 trloctrl.sh drwxr-sr-x 5 mbsdaq users 4096 Jan 12 13:57 trlolib I also had a look at the output at the beginning of the NURDLIB compilation and if I understand correctly, it looks like the VULOM in the new system has the same firmware as the one in the old system: TRIDI_FW=d374466d VULOM4_FW=d96ffc88 What to do now? Thank you very much! Best greetings G?nter ________________________________ Von: Hans Toshihide T?rnqvist Gesendet: Freitag, 12. Januar 2024 14:34:24 An: Weber, Guenter Dr.; H?kan T Johansson Betreff: Re: AW: AW: AW: AW: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version It looks to be mirrored from git.chalmers.se, so should work. Cheers, Hans On 2024-01-12 14:22, Weber, Guenter Dr. wrote: > Is the UCESB version on GITLAB also a mirror? Then I could download > everything from GITLAB? > > > ------------------------------------------------------------------------ > *Von:* H?kan T Johansson > *Gesendet:* Freitag, 12. Januar 2024 14:19:23 > *An:* Weber, Guenter Dr. > *Cc:* Hans Toshihide T?rnqvist > *Betreff:* Re: AW: AW: AW: [subexp-daq] NURDLIB: - how to check which > version is installed and how to update to the most recent version > > Ahh, sorry about that, please try with > > https://git.chalmers.se/expsubphys/drasi.git > > https://git.chalmers.se/expsubphys/ucesb.git > > > and the drasi varsion on gitlab.com is a mirror so should work equally > well. > > Cheers, > H?kan > > > > On Fri, 12 Jan 2024, Weber, Guenter Dr. wrote: > >> >> Dear H?kan, >> >> >> I encountered the following issue(s): >> >> >> git clone git at git.chalmers.se:expsubphys/drasi.git >> git clone git at git.chalmers.se:expsubphys/ucesb.git >> >> 1) I don't have access to git.chalmers.se, only to gitlab.com. >> 2) There is a DRASI also on gitlab.com, that I was using so far. But is it >> the same as on git.chalmers.se? >> >> >> Best greetings >> G?nter >> >> >> >> ____________________________________________________________________________ >> Von: H?kan T Johansson >> Gesendet: Donnerstag, 11. Januar 2024 08:15 >> An: Weber, Guenter Dr. >> Cc: Hans Toshihide T?rnqvist >> Betreff: Re: AW: AW: [subexp-daq] NURDLIB: - how to check which version is >> installed and how to update to the most recent version >> >> Dear G?nter, >> >> thanks! >> >> 1) may be the reason for that strange error in typedefs.h, since it may be >> that it picks up the mystdint.h from the trloii compile but uses it in the >> drasi header somehow - or vice versa.... (They are the same and typically >> kept in sync, but we may here have hit a snag with the different versions >> and an update I did a while ago...) >> >> 2) Should be fine, is just an attempt at indenting the pre-processor >> directives, without having my editor unindent the code. >> >> >> It sounds like a very nice plan if you have the hardware to set up a >> second system from scratch. I have attached a short instruction on how to >> downloading and compiling the codes from scratch. >> >> It would not surprise me if there already exist something like that, but >> then we have two of them :-) If not, we can put this (with whatever fixes >> are needed) up somewhere (gitlab wiki or so). >> >> I did test it - but that does not guarantee much... >> >> Cheers, >> H?kan >> >> >> >> On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote: >> >> > >> > P.S. I looked a bit into the code that is compiled right before the error >> > appear. >> > >> > >> > I have no idea if this might causing problems, but in >> > >> > ../dtc_arch/acc_def/mystdint.h >> > I found two things: >> > >> > >> > 1) >> > >> > New version: >> > >> > #if ACC_DEF__MYSTDINT_stdint_h >> > # include >> > #endif >> > /* This is a local fall-back solution, so should be last. */ >> > #if ACC_DEF__MYSTDINT_mystdint >> > >> > Old version: >> > >> > #if ACC_DEF_MYSTDINT_stdint_h >> > # include >> > #endif >> > /* This is a local fall-back solution, so should be last. */ >> > #if ACC_DEF_MYSTDINT_mystdint >> > >> > (Note the double "_" before MYSTDINT.) >> > >> > >> > 2) >> > >> > In both versions there are strange blanks after "#" at two positions: >> > >> > # include "acc_auto_def/mystdint.h" >> > # define UINT64_C(v) v##ULL >> > >> > >> > >> > Best greetings >> > >> > G?nter >> > >> > >> >___________________________________________________________________________ >> _ >> > Von: Weber, Guenter Dr. >> > Gesendet: Mittwoch, 10. Januar 2024 19:32:59 >> > An: Hans Toshihide T?rnqvist >> > Betreff: AW: AW: [subexp-daq] NURDLIB: - how to check which version is >> > installed and how to update to the most recent version >> > >> > Dear Hans, >> > >> > >> > I could not reproduce the error from two hours ago. Nurdlib was laready >> set >> > to the right branch and in a second try compiled without problems on the >> > RIO. >> > >> > >> > However, we are now back at square one: >> > >> > >> > 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 >> > make[1]: Entering directory >> > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >> > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args >> > UDP:ARPA_INET_H >> > CC build_cc_ppc-linux_4.2.2_debug/f_user.o >> > CC build_cc_ppc-linux_4.2.2_debug/subevent.o >> > In file includedfrom/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscom >> pat/ >> > s_veshe.h:6, >> > from ./subevent.h:11, >> > from subevent.c:1: >> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >> >> > typedefs.h:6: error: expected '=', ',', ';', 'asm' or '__attribute__' >> > before 'INTS8' >> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >> >> > typedefs.h:7: error: expected '=', ',', ';', 'asm' or '__attribute__' >> > before 'INTU8' >> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >> >> > typedefs.h:8: error: expected '=', ',', ';', 'asm' or '__attribute__' >> > before 'INTS4' >> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >> >> > typedefs.h:9: error: expected '=', ',', ';', 'asm' or '__attribute__' >> > before 'INTU4' >> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >> >> > typedefs.h:10: error: expected '=', ',', ';', 'asm' or '__attribute__' >> > before 'INTS2' >> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >> >> > typedefs.h:11: error: expected '=', ',', ';', 'asm' or '__attribute__' >> > before 'INTU2' >> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >> >> > typedefs.h:12: error: expected '=', ',', ';', 'asm' or '__attribute__' >> > before 'INTS1' >> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >> >> > typedefs.h:13: error: expected '=', ',', ';', 'asm' or '__attribute__' >> > before 'INTU1' >> > In file included from ./subevent.h:11, >> > from subevent.c:1: >> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >> >> > s_veshe.h:11: error: expected specifier-qualifier-list before 'INTS4' >> > subevent.c: In function 'begin_goosy_vme_subevent': >> > subevent.c:12: error: 's_veshe' has no member named 'l_dlen' >> > subevent.c: In function 'end_goosy_vme_subevent': >> > subevent.c:45: error: 's_veshe' has no member named 'l_dlen' >> > make[1]: *** [build_cc_ppc-linux_4.2.2_debug/subevent.o] Error 1 >> > make[1]: Leaving directory >> > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >> > make: *** [drasi] Error 2 >> > RIO4-MCAL-2 mbsdaq > >> > >> > Thus, downloading and recompiling DRASI, NURDLIB, and R3BFUSER did not >> solve >> > the problem with the latter. >> > >> > >> > >> > ?? >> > >> > >> > >> > >> > >> > >> > Best greetings >> > >> > G?nter >> > >> > >> > >> > >> >___________________________________________________________________________ >> _ >> > Von: Hans Toshihide T?rnqvist >> > Gesendet: Mittwoch, 10. Januar 2024 18:24:21 >> > An: Weber, Guenter Dr. >> > Betreff: Re: AW: [subexp-daq] NURDLIB: - how to check which version is >> > installed and how to update to the most recent version >> > Sorry I got held up. >> > >> > I compiled 'mcal_daq_merge' from Gitlab on a rio4 just fine, so I am >> > just as puzzled where those event buffer test errors come from... >> > >> > Any luck with a 'make clean && make'? >> > >> > Cheers, >> > >> > Hans >> > >> > On 2024-01-10 17:36, Weber, Guenter Dr. wrote: >> > > Dear Hans, >> > > >> > > >> > > now things really get weird. >> > > >> > > >> > > I again downloaded NURDLIB, DRASI, and R3BFUSER. DRASI compiled without >> > > problems (first on PC, then on RIO). >> > > >> > > >> > > Now NURDLIB compilation stops with an error: >> > > >> > > >> > > LD build_cc_ppc-linux_4.2.2_debug/test_ntest >> > > LD build_cc_ppc-linux_4.2.2_debug/test >> > > /bin/sh: line 1: 22504 Aborted >> > > ./build_cc_ppc-linux_4.2.2_debug/test > >> > > build_cc_ppc-linux_4.2.2_debug/test.log 2>&1 >> > > [tests/argmatch.c:127: Shorts] >> > > [tests/argmatch.c:128: Longs] >> > > [tests/argmatch.c:129: Combos] >> > > [tests/argmatch.c:130: ShortsWithValues] >> > > [tests/argmatch.c:131: LongsWithValues] >> > > [tests/argmatch.c:132: MissingValue] >> > > [tests/base.c:110: MemoryCheck] >> > > [tests/base.c:111: EventBufferAdvance] >> > > 2024-02-10,19:58:33:ERRR: Invalid pointer to advance event buffer. >> > > [tests/base.c:47] >> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:47] >> > > 2024-02-10,19:58:33:ERRR: Invalid pointer to advance event buffer. >> > > [tests/base.c:56] >> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:56] >> > > 2024-02-10,19:58:33:ERRR: Tried to advance outside event buffer. >> > > [tests/base.c:72] >> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:72] >> > > [tests/base.c:112: EventBufferInvariant] >> > > 2024-02-10,19:58:33:ERRR: Event-buffer inconsistent (0x1080e008:11 != >> > > 0x1080e008:10). [tests/base.c:87] >> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:87] >> > > 2024-02-10,19:58:33:ERRR: Event-buffer inconsistent (0x1080e008:9 != >> > > 0x1080e008:10). [tests/base.c:91] >> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:91] >> > > 2024-02-10,19:58:33:ERRR: Event-buffer inconsistent (0x1080e009:10 != >> > > 0x1080e008:10). [tests/base.c:95] >> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:95] >> > > 2024-02-10,19:58:33:ERRR: Event-buffer inconsistent (0x1080e007:10 != >> > > 0x1080e008:10). [tests/base.c:99] >> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:99] >> > > [tests/bits.c:43: Gets] >> > > [tests/bits.c:44: CountLoops] >> > > [tests/caen_v1190.c:79: DefaultConfig] >> > > 2024-02-10,19:58:33:INFO: Will try default cfg >> > > path='/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg', >> > > can be set with NURDLIB_DEF_PATH. [config/config.c:181] >> > > 2024-02-10,19:58:33:INFO: Opened './tests/caen_v1190_empty.cfg' { >> > > [config/parser.c:287] >> > > 2024-02-10,19:58:33:ERRR: .Could not load default or user config >> > > 'caen_v1190.cfg'. [config/config.c:1483] >> > > 2024-02-10,19:58:33:ERRR: .Calling abort()... [config/config.c:1483] >> > > make: *** [build_cc_ppc-linux_4.2.2_debug/test_ok] Error 1 >> > > >> > > >> > > Did you change anything in the GITLAB version between yesterday and 15 >> > > minutes ago? >> > > >> > > >> > > >> > > Sorry, sorry, sorry ?? >> > > >> > > >> > > >> > > >> > > Best greetings >> > > >> > > G?nter >> > > >> > > >> > > >> > > P.S. Tomorrow or on Friday, I will set up a second DAQ system with >> > > identical hardware. Then we can play around with no limits, including >> > > flashing the firmware of the VULOM, without messing around with the >> > > already running system as it is the case now. >> > > >> > > >> > > ------------------------------------------------------------------------ >> > > *Von:* Hans Toshihide T?rnqvist >> > > *Gesendet:* Mittwoch, 10. Januar 2024 16:59:07 >> > > *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, >> > > >> > > Did you try to update r3bfuser? I cannot see this problem with new >> > > versions of drasi+nurdlib+r3bfuser that are on Gitlab, and the trloii >> > > version shouldn't matter much in this case. >> > > >> > > Cheers, >> > > >> > > Hans >> > > >> > > On 2024-01-10 16:54, Weber, Guenter Dr. wrote: >> > >> Dear H?kan, >> > >> >> > >> >> > >> I followed your suggestion and the result is this: >> > >> >> > >> >> > >> 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 >> > >> make[1]: Entering directory >> > >> `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >> > >> CC build_cc_ppc-linux_4.2.2_debug/subevent.o >> > >> In file included from ./subevent.h:11, >> > >> from subevent.c:1: >> >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompa >> t/ >> > s_veshe.h:16: error: expected specifier-qualifier-list before 'CHARS' >> > >> make[1]: *** [build_cc_ppc-linux_4.2.2_debug/subevent.o] Error 1 >> > >> make[1]: Leaving directory >> > >> `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >> > >> make: *** [drasi] Error 2 >> > >> >> > >> >> > >> Best greetings >> > >> >> > >> G?nter >> > >> >> > >> >> > >> >> ------------------------------------------------------------------------ >> > >> *Von:* subexp-daq im Auftrag von >> > >> H?kan T Johansson >> > >> *Gesendet:* Mittwoch, 10. Januar 2024 16:07:52 >> > >> *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, >> > >> >> > >> those errors look strange to me. I am not able to reproduce on a >> similar >> > >> system. >> > >> >> > >> As a workaround (to see how far we get), in subevent.h in the r3bfuser/ >> > >> directory, could you uncomment these: >> > >> >> > >> #define MBS_TYPEDEFS_H >> > >> typedef char CHARX; >> > >> typedef int short INTS2; >> > >> typedef int INTS4; >> > >> >> > >> and comment out the "typedefs.h" in >> > >> >> >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompa >> t/ >> > s_veshe.h >> > >> >> > >> on line 6. And then try again. >> > >> >> > >> Cheers, >> > >> H?kan >> > >> >> > >> >> > >> On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote: >> > >> >> > >>> >> > >>> Dear Hans, >> > >>> >> > >>> >> > >>> I now did rebuild NURDLIB and DRASI. Then I tried to compile R3BFUSER >> > and this is the result: >> > >>> >> > >>> >> > >>> RIO4-MCAL-2 mbsdaq > cd r3bfuser/ >> > >>> 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 >> > >>> make[1]: Entering directory >> > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >> > >>> NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args >> > >>> UDP:ARPA_INET_H >> > >>> CC build_cc_ppc-linux_4.2.2_debug/f_user.o >> > >>> CC build_cc_ppc-linux_4.2.2_debug/subevent.o >> > >>> In file includedfrom/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscom >> pat/ >> > s_veshe.h:6, >> > >>> from ./subevent.h:11, >> > >>> from subevent.c:1: >> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >> at/ >> > typedefs.h:6: error: expected '=', ',', ';', 'asm' or '__attribute__' >> > before 'INTS8' >> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >> at/ >> > typedefs.h:7: error: expected '=', ',', ';', 'asm' or '__attribute__' >> > before 'INTU8' >> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >> at/ >> > typedefs.h:8: error: expected '=', ',', ';', 'asm' or '__attribute__' >> > before 'INTS4' >> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >> at/ >> > typedefs.h:9: error: expected '=', ',', ';', 'asm' or '__attribute__' >> > before 'INTU4' >> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >> at/ >> > typedefs.h:10: error: expected '=', ',', ';', 'asm' or '__attribute__' >> > before 'INTS2' >> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >> at/ >> > typedefs.h:11: error: expected '=', ',', ';', 'asm' or '__attribute__' >> > before 'INTU2' >> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >> at/ >> > typedefs.h:12: error: expected '=', ',', ';', 'asm' or '__attribute__' >> > before 'INTS1' >> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >> at/ >> > typedefs.h:13: error: expected '=', ',', ';', 'asm' or '__attribute__' >> > before 'INTU1' >> > >>> In file included from ./subevent.h:11, >> > >>> from subevent.c:1: >> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >> at/ >> > s_veshe.h:11: error: expected specifier-qualifier-list before 'INTS4' >> > >>> subevent.c: In function 'begin_goosy_vme_subevent': >> > >>> subevent.c:12: error: 's_veshe' has no member named 'l_dlen' >> > >>> subevent.c: In function 'end_goosy_vme_subevent': >> > >>> subevent.c:45: error: 's_veshe' has no member named 'l_dlen' >> > >>> make[1]: *** [build_cc_ppc-linux_4.2.2_debug/subevent.o] Error 1 >> > >>> make[1]: Leaving directory >> > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >> > >>> make: *** [drasi] Error 2 >> > >>> >> > >>> Reminder: I am using the most recent versions of NURDLIB and DRASI, >> but >> > because of the incompatibility of the VULOM firmware I use the old version >> > of TRLOII. In addition, >> > >>> because of the leap seconds issue I compiled DRASI first on the PC and >> > then recompiled it on the RIO (without "make clean"). >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> Best greetings >> > >>> G?nter >> > >>> >> > >>> >> >>>>________________________________________________________________________ >> ___ >> > __________________________________________________________________________ >> > _____________________ >> > >>> Von: Hans Toshihide T?rnqvist >> > >>> Gesendet: Mittwoch, 10. Januar 2024 13:18:41 >> > >>> 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, >> > >>> >> > >>> I would suggest rebuilding nurdlib now that trlo2 has been rebuilt, >> and >> > >>> then also rebuild r3bfuser. >> > >>> >> > >>> After that probably you can try to run the DAQ :) >> > >>> >> > >>> Cheers, >> > >>> Hans >> > >>> >> > >>> On 2024-01-10 13:15, Weber, Guenter Dr. wrote: >> > >>> > Dear H?kan, >> > >>> > >> > >>> > >> > >>> > using the old TRLOII folder and then recompiling was successfull. >> > >>> > >> > >>> > >> > >>> > Should I now give it a try to start the DAQ? Or is there something >> > else >> > >>> > I still need to adjust? >> > >>> > >> > >>> > >> > >>> > >> > >>> > >> > >>> > Best greetings >> > >>> > >> > >>> > G?nter >> > >>> > >> > >>> > >> > >>> > >> > >>> > >> > >>> > >> > ------------------------------------------------------------------------ >> > >>> > *Von:* subexp-daq im Auftrag >> > von >> > >>> > H?kan T Johansson >> > >>> > *Gesendet:* Mittwoch, 10. Januar 2024 12:34:26 >> > >>> > *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 >> > >>> > >> > >>> > Hi G?nter, >> > >>> > >> > >>> > On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote: >> > >>> > >> > >>> >> >> > >>> >> Hi folks, >> > >>> >> >> > >>> >> >> > >>> >> the old "./find_firmware.pl" was working. This is the output: >> > >>> >> >> > >>> >> >> > >>> >> a1729cda ../ver/rimfaxe0_trlo/rfx0_defs.h >> > >>> >> 0866c243 ../ver/rimfaxe1_trlo/rfx1_defs.h >> > >>> >> 5e8f5ef4 ../ver/tridi1_trlo/tridi_defs.h >> > >>> >> 6e4ba1a9 ../ver/vulom4_trlo/trlo_defs.h >> > >>> >> 68f8955e ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h >> > >>> >> af33ed35 ../ver/vulom4_trlo_big/trlo_big_defs.h >> > >>> >> 1409285e ../ver/vulom4b_trlo/trlo_defs.h >> > >>> >> d374466d ../fw/tridi1_trlo/tridi_defs.h >> > >>> >> d96ffc88 ../fw/vulom4_trlo/trlo_defs.h >> > >>> >> 5b298165 ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h >> > >>> >> 6f28c0f8 ../fw/vulom4_trlo_big/trlo_big_defs.h >> > >>> >> fa5020ea ../fw/vulom4_trlo_led/trlo_defs.h >> > >>> >> 426cb99c ../fw/vulom4b_trlo/trlo_defs.h >> > >>> >> MKDIR fw_a1729cda_rfx0 # ../ver/rimfaxe0_trlo/rfx0_defs.h >> > >>> >> SYMLINK fw_a1729cda_rfx0/rfx0_defs.h -> >> > ../../ver/rimfaxe0_trlo/rfx0_defs.h >> > >>> >> MKDIR fw_0866c243_rfx1 # ../ver/rimfaxe1_trlo/rfx1_defs.h >> > >>> >> SYMLINK fw_0866c243_rfx1/rfx1_defs.h -> >> > ../../ver/rimfaxe1_trlo/rfx1_defs.h >> > >>> >> MKDIR fw_5e8f5ef4_tridi # ../ver/tridi1_trlo/tridi_defs.h >> > >>> >> SYMLINK fw_5e8f5ef4_tridi/tridi_defs.h -> >> > ../../ver/tridi1_trlo/tridi_defs.h >> > >>> >> MKDIR fw_6e4ba1a9_trlo # ../ver/vulom4_trlo/trlo_defs.h >> > >>> >> SYMLINK fw_6e4ba1a9_trlo/trlo_defs.h -> >> > ../../ver/vulom4_trlo/trlo_defs.h >> > >>> >> SYMLINK fw_1409285e_trlo -> fw_6e4ba1a9_trlo >> > >>> >> MKDIR fw_68f8955e_trlo_all_in # >> > ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h >> > >>> >> SYMLINK fw_68f8955e_trlo_all_in/trlo_all_in_defs.h -> >> > ../../ver/vulom4_trlo_all_in/trlo_all_in_defs.h >> > >>> >> MKDIR fw_af33ed35_trlo_big # >> > ../ver/vulom4_trlo_big/trlo_big_defs.h >> > >>> >> SYMLINK fw_af33ed35_trlo_big/trlo_big_defs.h -> >> > ../../ver/vulom4_trlo_big/trlo_big_defs.h >> > >>> >> MKDIR fw_d374466d_tridi # ../fw/tridi1_trlo/tridi_defs.h >> > >>> >> SYMLINK fw_d374466d_tridi/tridi_defs.h -> >> > ../../fw/tridi1_trlo/tridi_defs.h >> > >>> >> MKDIR fw_d96ffc88_trlo # ../fw/vulom4_trlo/trlo_defs.h >> > >>> >> SYMLINK fw_d96ffc88_trlo/trlo_defs.h -> >> > ../../fw/vulom4_trlo/trlo_defs.h >> > >>> >> SYMLINK fw_426cb99c_trlo -> fw_d96ffc88_trlo >> > >>> >> SYMLINK fw_fa5020ea_trlo -> fw_d96ffc88_trlo >> > >>> >> MKDIR fw_5b298165_trlo_all_in # >> > ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h >> > >>> >> SYMLINK fw_5b298165_trlo_all_in/trlo_all_in_defs.h -> >> > ../../fw/vulom4_trlo_all_in/trlo_all_in_defs.h >> > >>> >> MKDIR fw_6f28c0f8_trlo_big # >> ../fw/vulom4_trlo_big/trlo_big_defs.h >> > >>> >> SYMLINK fw_6f28c0f8_trlo_big/trlo_big_defs.h -> >> > ../../fw/vulom4_trlo_big/trlo_big_defs.h >> > >>> >> >> > >>> >> However, the compilation did end with an error: >> > >>> >> >> > >>> >> >> > >>> >> make[1]: Enteringdirectory`/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl >> /fw_d96ff >> > c88_trlo' >> > >>> >> CC bld_ppc-linux_4.2.2/src/trlo_check_version.o >> > >>> >> CC bld_ppc-linux_4.2.2/src/trlo_functions.o >> > >>> >> ../trlolib/src/trlo_functions.c: In function 'trlo_clear_config': >> > >>> >> ../trlolib/src/trlo_functions.c:144: error: 'trlo_setup_map' has no >> > member named 'sync_check_start_mux' >> > >>> >> ../trlolib/src/trlo_functions.c:146: error: 'trlo_setup_map' has no >> > member named 'sync_check_stop_mux' >> > >>> >> ../trlolib/src/trlo_functions.c: In function 'trlo_print_config': >> > >>> >> ../trlolib/src/trlo_functions.c:825: error: 'trlo_setup_map' has no >> > member named 'sync_check_start_mux' >> > >>> >> ../trlolib/src/trlo_functions.c:829: error: 'trlo_setup_map' has no >> > member named 'sync_check_stop_mux' >> > >>> >> ../trlolib/src/trlo_functions.c: In function >> > 'trlo_print_trig_status': >> > >>> >> ../trlolib/src/trlo_functions.c:1155: error: 'trlo_output_map' has >> no >> > member named 'trig_sync_check' >> > >>> >> make[1]: *** [bld_ppc-linux_4.2.2/src/trlo_functions.o] Error 1 >> > >>> >> make[1]: Leavingdirectory`/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl >> /fw_d96ff >> > c88_trlo' >> > >>> >> >> > >>> >> make[1]: Enteringdirectory`/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl >> /fw_d3744 >> > 66d_tridi' >> > >>> >> CC bld_ppc-linux_4.2.2/src/tridi_check_version.o >> > >>> >> CC bld_ppc-linux_4.2.2/src/tridi_functions.o >> > >>> >> ../trlolib/src/trlo_functions.c: In function 'tridi_clear_config': >> > >>> >> ../trlolib/src/trlo_functions.c:144: error: 'tridi_setup_map' has >> no >> > member named 'sync_check_start_mux' >> > >>> >> ../trlolib/src/trlo_functions.c:146: error: 'tridi_setup_map' has >> no >> > member named 'sync_check_stop_mux' >> > >>> >> ../trlolib/src/trlo_functions.c: In function 'tridi_print_config': >> > >>> >> ../trlolib/src/trlo_functions.c:825: error: 'tridi_setup_map' has >> no >> > member named 'sync_check_start_mux' >> > >>> >> ../trlolib/src/trlo_functions.c:829: error: 'tridi_setup_map' has >> no >> > member named 'sync_check_stop_mux' >> > >>> >> ../trlolib/src/trlo_functions.c: In function >> > 'tridi_print_trig_status': >> > >>> >> ../trlolib/src/trlo_functions.c:1155: error: 'tridi_output_map' has >> > no member named 'trig_sync_check' >> > >>> >> make[1]: *** [bld_ppc-linux_4.2.2/src/tridi_functions.o] Error 1 >> > >>> >> make[1]: Leavingdirectory`/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl >> /fw_d3744 >> > 66d_tridi' >> > >>> >> make: *** [fw_d374466d_tridi_build] Error 2 >> > >>> > >> > >>> > That's what I feared. The new code want something (sync_check_...) >> > not in >> > >>> > the older firmware... >> > >>> > >> > >>> >> The fallback option is now to delete the new TRLOII folder and >> > replace it with old one and then repeat the following steps? >> > >>> >> >> > >>> >> >> > >>> >> cd trloii >> > >>> >> make clean >> > >>> >> make >> > >>> >> cd trloctrl >> > >>> >> make fw_d96ffc88_trlo_build >> > >>> >> make fw_d374466d_tridi_build >> > >>> >> >> > >>> >> >> > >>> >> Is this correct? >> > >>> > >> > >>> > Yes. >> > >>> > >> > >>> > There should then already be the trloii/fw/ directory, and the links >> > that >> > >>> > are created by find_firmware.pl >> > >>> > >> > >>> > >> > >>> >> I also looked for the "--addr=" and this is the result: >> > >>> > >> > >>> >> ... >> > >>> > >> > >>> > Ok. I was too optimistic here. I looked through the grep results, >> > but >> > >>> > nothing obvious. Should be figurable by checking the old scripts >> and >> > >>> > following them around. Is a good way to see how things are done >> > anyhow ;) >> > >>> > >> > >>> > Cheers, >> > >>> > H?kan >> > >>> > >> > >>> > >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> Best greetings >> > >>> >> >> > >>> >> G?nter >> > >>> > >> > >>> >> > >>> >> > >> >> > >> > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.tornqvist at chalmers.se Fri Jan 12 16:16:54 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Fri, 12 Jan 2024 16:16:54 +0100 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <14e1aab1db454f5da272442151f66d56@hi-jena.gsi.de> <43efd4d2fa684387b7839d88617c9e31@hi-jena.gsi.de> <299880b3f6984312aeb94a1b29c3f302@hi-jena.gsi.de> <9f489cb1-234c-52a2-a657-761573313acb@chalmers.se> <72a9169e4d764d80a72988feaff91db3@hi-jena.gsi.de> <2019a2ea-9480-449b-a0da-4bbed3e6a7e7@chalmers.se> <34e673ef4a3f4664989b3167b6a6c335@hi-jena.gsi.de> <26dc0c59-5ac1-4073-bc26-aaf081dc8eb6@chalmers.se> <35fc1cdfa4484b298214067c37448ffb@hi-jena.gsi.de> <47cf2d4c-f59c-6ea7-86ea-f5ec88eabb5c@chalmers.se> <77f957cf-d6cc-d9d7-c96f-5c0dbb8a16d9@chalmers.se> <52af1da7-5486-420b-b6af-b67693bdc213@chalmers.se> Message-ID: <50174d78-cb5d-440b-bb6d-08e5a11919b8@chalmers.se> Dear G?nter, --- Let's start with the nurdlib build: The *_FW env vars are selected by nurdlib/Makefile by looking at the available $TRLOII_PATH/trloctrl/fw_* directories. Except, if they were already set! This lets the user control exactly (some of) the decisions made by nurdlib, otherwise the machines will take over. Probably there are some lines in ~/.tcshrc or a similar file which sets them. Try commenting them out, log out of the Rio4, log back in, "make clean" and already then you should see which firmwares are selected. Then run "make". You could also set *_FW explicitly to the new firmware if you prefer or the auto-selection doesn't work. I am working on the nurdlib documentation, actually even on the enviroment variable section right now, so I'll add this in :) So, for nurdlib, please check the env vars: - TRLOII_PATH - TRIDI_FW - VULOM4_FW --- r3bfuser build: I am guessing that this is related to mismatching firmware numbers, the build pulls data from what nurdlib decided. If nurdlib builds with the correct numbers as described above, I hope r3bfuser will "just work" (crossing all my fingers). --- The *_CTRL variables are not used by nurdlib and r3bfuser, and are only convenient on the cmd-line by for example: $TRIDI_CTRL --addr=n --print-config But they should point to the correct trloctrl builds for your new firmware or they will complain when they talk to the hardware! --- Cheers, Hans On 2024-01-12 15:33, Weber, Guenter Dr. wrote: > Dear friends, > > > I did set up a second DAQ system and followed the instructions provided by > > > Everything goes smoothly (I had to use the workaround in TRLOII) until > compilation of R3DFUSER. This is the output (compilation done on the RIO): > > > RIO4-MCAL-1 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 > make[1]: Entering directory > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > udp.h: Could not configure module UDP, > build_cc_ppc-linux_4.2.2_debug/nconf/udp.h.log: > === UDP:ARPA_INET_H === > run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o > build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.c -I. -I > build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mUDP=1 -DDRASI > -I. -Ibuild_cc_ppc-linux_4.2.2_debug > -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii > -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames > run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.bin > build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o -I. -I > build_cc_ppc-linux_4.2.2_debug/nconfing/ -DDRASI -I. > -Ibuild_cc_ppc-linux_4.2.2_debug > -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii > -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames -L../nurdlib/build_cc_ppc-linux_4.2.2_debug /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -lnurdlib -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/lib_ppc-linux_4.2.2 -llwroc_mbscompat -llwroc_main -llwroc_readout -llwroc_nofilter -llwroc -llwroc_netutil -llwroc_parseutil -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -lpthread -lrt -lm -lcesXpcLib -lncurses -llwroc_hwmap_error > cc: > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a: No such file or directory > cc: > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a: No such file or directory > Failed. > === UDP:NETINET_IN_H === > run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o > build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.c -I. -I > build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mUDP=1 -DDRASI > -I. -Ibuild_cc_ppc-linux_4.2.2_debug > -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii > -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames > run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.bin > build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o -I. -I > build_cc_ppc-linux_4.2.2_debug/nconfing/ -DDRASI -I. > -Ibuild_cc_ppc-linux_4.2.2_debug > -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii > -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames -L../nurdlib/build_cc_ppc-linux_4.2.2_debug /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -lnurdlib -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/lib_ppc-linux_4.2.2 -llwroc_mbscompat -llwroc_main -llwroc_readout -llwroc_nofilter -llwroc -llwroc_netutil -llwroc_parseutil -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -lpthread -lrt -lm -lcesXpcLib -lncurses -llwroc_hwmap_error > cc: > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a: No such file or directory > cc: > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a: No such file or directory > Failed. > === UDP:BSD_IN_H === > run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o > build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.c -I. -I > build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mUDP=1 -DDRASI > -I. -Ibuild_cc_ppc-linux_4.2.2_debug > -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii > -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames > run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.bin > build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o -I. -I > build_cc_ppc-linux_4.2.2_debug/nconfing/ -DDRASI -I. > -Ibuild_cc_ppc-linux_4.2.2_debug > -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii > -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames -L../nurdlib/build_cc_ppc-linux_4.2.2_debug /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -lnurdlib -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/lib_ppc-linux_4.2.2 -llwroc_mbscompat -llwroc_main -llwroc_readout -llwroc_nofilter -llwroc -llwroc_netutil -llwroc_parseutil -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -lpthread -lrt -lm -lcesXpcLib -lncurses -llwroc_hwmap_error > cc: > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a: No such file or directory > cc: > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a: No such file or directory > Failed. > make[1]: *** [build_cc_ppc-linux_4.2.2_debug/nconf.args] Error 1 > make[1]: Leaving directory > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' > make: *** [drasi] Error 2 > > I had a look at the environment variables which I took over from the > already existing system and I guess, I would need to modify some of > these lines: > > > VULOM4_CTRL=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/bin_ppc-linux_4.2.2/trlo_ctrl > > TRIDI_CTRL=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/bin_ppc-linux_4.2.2/tridi_ctrl > > > This is the content of the folder on the new system: > > > mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl$ ls -l > insgesamt 52 > drwxr-sr-x? 2 mbsdaq users 4096 Jan 12 13:57 examples > -rwxr-xr-x? 1 mbsdaq users 7389 Jan 12 13:57 find_firmwares.pl > -rw-r--r--? 1 mbsdaq users? 114 Jan 12 15:02 firmwaredirs > drwxr-sr-x? 2 mbsdaq users 4096 Jan 12 15:00 fw_0866c243_rfx1 > lrwxrwxrwx? 1 mbsdaq users? ?16 Jan 12 15:00 fw_1409285e_trlo -> > fw_6e4ba1a9_trlo > drwxr-sr-x? 2 mbsdaq users 4096 Jan 12 15:00 fw_5e8f5ef4_tridi > drwxr-sr-x? 2 mbsdaq users 4096 Jan 12 15:00 fw_68f8955e_trlo_all_in > drwxr-sr-x 14 mbsdaq users 4096 Jan 12 15:02 fw_6e4ba1a9_trlo > drwxr-sr-x? 2 mbsdaq users 4096 Jan 12 15:00 fw_a1729cda_rfx0 > lrwxrwxrwx? 1 mbsdaq users? ?16 Jan 12 15:00 fw_a73c5093_trlo -> > fw_6e4ba1a9_trlo > drwxr-sr-x? 2 mbsdaq users 4096 Jan 12 15:00 fw_af33ed35_trlo_big > -rw-r--r--? 1 mbsdaq users? 994 Jan 12 13:57 Makefile > -rwxr-xr-x? 1 mbsdaq users? 662 Jan 12 13:57 trloctrl.sh > drwxr-sr-x? 5 mbsdaq users 4096 Jan 12 13:57 trlolib > > I also had a look at the output at the beginning of the NURDLIB > compilation and if I understand correctly, it looks like the VULOM in > the new system has the same firmware as the one in the old system: > > > TRIDI_FW=d374466d > VULOM4_FW=d96ffc88 > > What to do now? > > > > > Thank you very much! > > > > > Best greetings > > G?nter > > > > ------------------------------------------------------------------------ > *Von:* Hans Toshihide T?rnqvist > *Gesendet:* Freitag, 12. Januar 2024 14:34:24 > *An:* Weber, Guenter Dr.; H?kan T Johansson > *Betreff:* Re: AW: AW: AW: AW: [subexp-daq] NURDLIB: - how to check > which version is installed and how to update to the most recent version > It looks to be mirrored from git.chalmers.se, so should work. > > Cheers, > Hans > > On 2024-01-12 14:22, Weber, Guenter Dr. wrote: >> Is the UCESB version on GITLAB also a mirror? Then I could download >> everything from GITLAB? >> >> >> ------------------------------------------------------------------------ >> *Von:* H?kan T Johansson >> *Gesendet:* Freitag, 12. Januar 2024 14:19:23 >> *An:* Weber, Guenter Dr. >> *Cc:* Hans Toshihide T?rnqvist >> *Betreff:* Re: AW: AW: AW: [subexp-daq] NURDLIB: - how to check which >> version is installed and how to update to the most recent version >> >> Ahh, sorry about that, please try with >> >> https://git.chalmers.se/expsubphys/drasi.git > >> > >> https://git.chalmers.se/expsubphys/ucesb.git > >> > >> >> and the drasi varsion on gitlab.com is a mirror so should work equally >> well. >> >> Cheers, >> H?kan >> >> >> >> On Fri, 12 Jan 2024, Weber, Guenter Dr. wrote: >> >>> >>> Dear?H?kan, >>> >>> >>> I encountered the following issue(s): >>> >>> >>> git clone git at git.chalmers.se:expsubphys/drasi.git >>> git clone git at git.chalmers.se:expsubphys/ucesb.git >>> >>> 1) I don't have access to git.chalmers.se, only to?gitlab.com. >>> 2) There is a DRASI also on gitlab.com, that I was using so far. But is it >>> the same as on?git.chalmers.se? >>> >>> >>> Best greetings >>> G?nter >>> >>> >>> >>> ____________________________________________________________________________ >>> Von: H?kan T Johansson >>> Gesendet: Donnerstag, 11. Januar 2024 08:15 >>> An: Weber, Guenter Dr. >>> Cc: Hans Toshihide T?rnqvist >>> Betreff: Re: AW: AW: [subexp-daq] NURDLIB: - how to check which version is >>> installed and how to update to the most recent version >>> >>> Dear G?nter, >>> >>> thanks! >>> >>> 1) may be the reason for that strange error in typedefs.h, since it may be >>> that it picks up the mystdint.h from the trloii compile but uses it in the >>> drasi header somehow - or vice versa....? (They are the same and typically >>> kept in sync, but we may here have hit a snag with the different versions >>> and an update I did a while ago...) >>> >>> 2) Should be fine, is just an attempt at indenting the pre-processor >>> directives, without having my editor unindent the code. >>> >>> >>> It sounds like a very nice plan if you have the hardware to set up a >>> second system from scratch.? I have attached a short instruction on how to >>> downloading and compiling the codes from scratch. >>> >>> It would not surprise me if there already exist something like that, but >>> then we have two of them :-)? If not, we can put this (with whatever fixes >>> are needed) up somewhere (gitlab wiki or so). >>> >>> I did test it - but that does not guarantee much... >>> >>> Cheers, >>> H?kan >>> >>> >>> >>> On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote: >>> >>> > >>> > P.S. I looked a bit into the code that is compiled right before the error >>> > appear. >>> > >>> > >>> > I have no idea if this might causing problems, but in >>> > >>> > ../dtc_arch/acc_def/mystdint.h >>> > I found two things: >>> > >>> > >>> > 1) >>> > >>> > New?version: >>> > >>> > #if ACC_DEF__MYSTDINT_stdint_h >>> > # include >>> > #endif >>> > /* This is a local fall-back solution, so should be last. */ >>> > #if ACC_DEF__MYSTDINT_mystdint >>> > >>> > Old version: >>> > >>> > #if ACC_DEF_MYSTDINT_stdint_h >>> > # include >>> > #endif >>> > /* This is a local fall-back solution, so should be last. */ >>> > #if ACC_DEF_MYSTDINT_mystdint >>> > >>> > (Note the double "_" before MYSTDINT.) >>> > >>> > >>> > 2) >>> > >>> > In both versions there are strange blanks after "#"?at two positions: >>> > >>> > # include "acc_auto_def/mystdint.h" >>> > # define UINT64_C(v) v##ULL >>> > >>> > >>> > >>> > Best greetings >>> > >>> > G?nter >>> > >>> > >>> >___________________________________________________________________________ >>> _ >>> > Von: Weber, Guenter Dr. >>> > Gesendet: Mittwoch, 10. Januar 2024 19:32:59 >>> > An: Hans Toshihide T?rnqvist >>> > Betreff: AW: AW: [subexp-daq] NURDLIB: - how to check which version is >>> > installed and how to update to the most recent version >>> > >>> > Dear Hans, >>> > >>> > >>> > I could not reproduce the error from two hours ago. Nurdlib was laready >>> set >>> > to the right branch and in a second try compiled without problems on the >>> > RIO. >>> > >>> > >>> > However, we are now back at square one: >>> > >>> > >>> > 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 >>> > make[1]: Entering directory >>> > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >>> > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args >>> > UDP:ARPA_INET_H >>> > CC? ? build_cc_ppc-linux_4.2.2_debug/f_user.o >>> > CC? ? build_cc_ppc-linux_4.2.2_debug/subevent.o >>> > In file includedfrom/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscom >>> pat/ >>> > s_veshe.h:6, >>> > ? ? ? ? ? ? ? ? ?from ./subevent.h:11, >>> > ? ? ? ? ? ? ? ? ?from subevent.c:1: >>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>> >>> > typedefs.h:6: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTS8' >>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>> >>> > typedefs.h:7: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTU8' >>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>> >>> > typedefs.h:8: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTS4' >>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>> >>> > typedefs.h:9: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTU4' >>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>> >>> > typedefs.h:10: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTS2' >>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>> >>> > typedefs.h:11: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTU2' >>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>> >>> > typedefs.h:12: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTS1' >>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>> >>> > typedefs.h:13: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTU1' >>> > In file included from ./subevent.h:11, >>> > ? ? ? ? ? ? ? ? ?from subevent.c:1: >>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>> >>> > s_veshe.h:11: error: expected specifier-qualifier-list before 'INTS4' >>> > subevent.c: In function 'begin_goosy_vme_subevent': >>> > subevent.c:12: error: 's_veshe' has no member named 'l_dlen' >>> > subevent.c: In function 'end_goosy_vme_subevent': >>> > subevent.c:45: error: 's_veshe' has no member named 'l_dlen' >>> > make[1]: *** [build_cc_ppc-linux_4.2.2_debug/subevent.o] Error 1 >>> > make[1]: Leaving directory >>> > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >>> > make: *** [drasi] Error 2 >>> > RIO4-MCAL-2 mbsdaq > >>> > >>> > Thus, downloading and recompiling DRASI, NURDLIB, and R3BFUSER did not >>> solve >>> > the problem with the latter. >>> > >>> > >>> > >>> > ?? >>> > >>> > >>> > >>> > >>> > >>> > >>> > Best greetings >>> > >>> > G?nter >>> > >>> > >>> > >>> > >>> >___________________________________________________________________________ >>> _ >>> > Von: Hans Toshihide T?rnqvist >>> > Gesendet: Mittwoch, 10. Januar 2024 18:24:21 >>> > An: Weber, Guenter Dr. >>> > Betreff: Re: AW: [subexp-daq] NURDLIB: - how to check which version is >>> > installed and how to update to the most recent version >>> > Sorry I got held up. >>> > >>> > I compiled 'mcal_daq_merge' from Gitlab on a rio4 just fine, so I am >>> > just as puzzled where those event buffer test errors come from... >>> > >>> > Any luck with a 'make clean && make'? >>> > >>> > Cheers, >>> > >>> > Hans >>> > >>> > On 2024-01-10 17:36, Weber, Guenter Dr. wrote: >>> > > Dear Hans, >>> > > >>> > > >>> > > now things really get weird. >>> > > >>> > > >>> > > I again downloaded NURDLIB, DRASI, and R3BFUSER. DRASI compiled without >>> > > problems (first on PC, then on RIO). >>> > > >>> > > >>> > > Now NURDLIB compilation stops with an error: >>> > > >>> > > >>> > > LD??? build_cc_ppc-linux_4.2.2_debug/test_ntest >>> > > LD??? build_cc_ppc-linux_4.2.2_debug/test >>> > > /bin/sh: line 1: 22504 Aborted >>> > > ./build_cc_ppc-linux_4.2.2_debug/test > >>> > > build_cc_ppc-linux_4.2.2_debug/test.log 2>&1 >>> > > [tests/argmatch.c:127: Shorts] >>> > > [tests/argmatch.c:128: Longs] >>> > > [tests/argmatch.c:129: Combos] >>> > > [tests/argmatch.c:130: ShortsWithValues] >>> > > [tests/argmatch.c:131: LongsWithValues] >>> > > [tests/argmatch.c:132: MissingValue] >>> > > [tests/base.c:110: MemoryCheck] >>> > > [tests/base.c:111: EventBufferAdvance] >>> > > 2024-02-10,19:58:33:ERRR: Invalid pointer to advance event buffer. >>> > > [tests/base.c:47] >>> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:47] >>> > > 2024-02-10,19:58:33:ERRR: Invalid pointer to advance event buffer. >>> > > [tests/base.c:56] >>> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:56] >>> > > 2024-02-10,19:58:33:ERRR: Tried to advance outside event buffer. >>> > > [tests/base.c:72] >>> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:72] >>> > > [tests/base.c:112: EventBufferInvariant] >>> > > 2024-02-10,19:58:33:ERRR: Event-buffer inconsistent (0x1080e008:11 != >>> > > 0x1080e008:10). [tests/base.c:87] >>> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:87] >>> > > 2024-02-10,19:58:33:ERRR: Event-buffer inconsistent (0x1080e008:9 != >>> > > 0x1080e008:10). [tests/base.c:91] >>> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:91] >>> > > 2024-02-10,19:58:33:ERRR: Event-buffer inconsistent (0x1080e009:10 != >>> > > 0x1080e008:10). [tests/base.c:95] >>> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:95] >>> > > 2024-02-10,19:58:33:ERRR: Event-buffer inconsistent (0x1080e007:10 != >>> > > 0x1080e008:10). [tests/base.c:99] >>> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:99] >>> > > [tests/bits.c:43: Gets] >>> > > [tests/bits.c:44: CountLoops] >>> > > [tests/caen_v1190.c:79: DefaultConfig] >>> > > 2024-02-10,19:58:33:INFO: Will try default cfg >>> > > path='/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg', >>> > > can be set with NURDLIB_DEF_PATH. [config/config.c:181] >>> > > 2024-02-10,19:58:33:INFO: Opened './tests/caen_v1190_empty.cfg' { >>> > > [config/parser.c:287] >>> > > 2024-02-10,19:58:33:ERRR: .Could not load default or user config >>> > > 'caen_v1190.cfg'. [config/config.c:1483] >>> > > 2024-02-10,19:58:33:ERRR: .Calling abort()... [config/config.c:1483] >>> > > make: *** [build_cc_ppc-linux_4.2.2_debug/test_ok] Error 1 >>> > > >>> > > >>> > > Did you change anything in the GITLAB version between yesterday and 15 >>> > > minutes ago? >>> > > >>> > > >>> > > >>> > > Sorry, sorry, sorry ?? >>> > > >>> > > >>> > > >>> > > >>> > > Best greetings >>> > > >>> > > G?nter >>> > > >>> > > >>> > > >>> > > P.S. Tomorrow or on Friday, I will set up a second DAQ system with >>> > > identical hardware. Then we can play around with no limits, including >>> > > flashing the firmware of the VULOM, without messing around with the >>> > > already running system as it is the case now. >>> > > >>> > > >>> > > ------------------------------------------------------------------------ >>> > > *Von:* Hans Toshihide T?rnqvist >>> > > *Gesendet:* Mittwoch, 10. Januar 2024 16:59:07 >>> > > *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, >>> > > >>> > > Did you try to update r3bfuser? I cannot see this problem with new >>> > > versions of drasi+nurdlib+r3bfuser that are on Gitlab, and the trloii >>> > > version shouldn't matter much in this case. >>> > > >>> > > Cheers, >>> > > >>> > > Hans >>> > > >>> > > On 2024-01-10 16:54, Weber, Guenter Dr. wrote: >>> > >> Dear H?kan, >>> > >> >>> > >> >>> > >> I followed your suggestion and the result is this: >>> > >> >>> > >> >>> > >> 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 >>> > >> make[1]: Entering directory >>> > >> `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >>> > >> CC??? build_cc_ppc-linux_4.2.2_debug/subevent.o >>> > >> In file included from ./subevent.h:11, >>> > >>? ???????????????? from subevent.c:1: >>> >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompa >>> t/ >>> > s_veshe.h:16: error: expected specifier-qualifier-list before 'CHARS' >>> > >> make[1]: *** [build_cc_ppc-linux_4.2.2_debug/subevent.o] Error 1 >>> > >> make[1]: Leaving directory >>> > >> `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >>> > >> make: *** [drasi] Error 2 >>> > >> >>> > >> >>> > >> Best greetings >>> > >> >>> > >> G?nter >>> > >> >>> > >> >>> > >> >>> ------------------------------------------------------------------------ >>> > >> *Von:* subexp-daq im Auftrag von >>> > >> H?kan T Johansson >>> > >> *Gesendet:* Mittwoch, 10. Januar 2024 16:07:52 >>> > >> *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, >>> > >> >>> > >> those errors look strange to me.? I am not able to reproduce on a >>> similar >>> > >> system. >>> > >> >>> > >> As a workaround (to see how far we get), in subevent.h in the r3bfuser/ >>> > >> directory, could you uncomment these: >>> > >> >>> > >> #define MBS_TYPEDEFS_H >>> > >> typedef char CHARX; >>> > >> typedef int short INTS2; >>> > >> typedef int INTS4; >>> > >> >>> > >> and comment out the "typedefs.h" in >>> > >> >>> >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompa >>> t/ >>> > s_veshe.h >>> > >> >>> > >> on line 6.? And then try again. >>> > >> >>> > >> Cheers, >>> > >> H?kan >>> > >> >>> > >> >>> > >> On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote: >>> > >> >>> > >>> >>> > >>> Dear Hans, >>> > >>> >>> > >>> >>> > >>> I now did rebuild NURDLIB and DRASI. Then I tried to compile R3BFUSER >>> > and this is the result: >>> > >>> >>> > >>> >>> > >>> RIO4-MCAL-2 mbsdaq > cd r3bfuser/ >>> > >>> 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 >>> > >>> make[1]: Entering directory >>> > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >>> > >>> NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args >>> > >>> UDP:ARPA_INET_H >>> > >>> CC??? build_cc_ppc-linux_4.2.2_debug/f_user.o >>> > >>> CC??? build_cc_ppc-linux_4.2.2_debug/subevent.o >>> > >>> In file includedfrom/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscom >>> pat/ >>> > s_veshe.h:6, >>> > >>> ???????????????? from ./subevent.h:11, >>> > >>> ???????????????? from subevent.c:1: >>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>> at/ >>> > typedefs.h:6: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTS8' >>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>> at/ >>> > typedefs.h:7: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTU8' >>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>> at/ >>> > typedefs.h:8: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTS4' >>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>> at/ >>> > typedefs.h:9: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTU4' >>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>> at/ >>> > typedefs.h:10: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTS2' >>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>> at/ >>> > typedefs.h:11: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTU2' >>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>> at/ >>> > typedefs.h:12: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTS1' >>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>> at/ >>> > typedefs.h:13: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTU1' >>> > >>> In file included from ./subevent.h:11, >>> > >>> ???????????????? from subevent.c:1: >>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>> at/ >>> > s_veshe.h:11: error: expected specifier-qualifier-list before 'INTS4' >>> > >>> subevent.c: In function 'begin_goosy_vme_subevent': >>> > >>> subevent.c:12: error: 's_veshe' has no member named 'l_dlen' >>> > >>> subevent.c: In function 'end_goosy_vme_subevent': >>> > >>> subevent.c:45: error: 's_veshe' has no member named 'l_dlen' >>> > >>> make[1]: *** [build_cc_ppc-linux_4.2.2_debug/subevent.o] Error 1 >>> > >>> make[1]: Leaving directory >>> > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >>> > >>> make: *** [drasi] Error 2 >>> > >>> >>> > >>> Reminder: I am using the most recent versions of NURDLIB and DRASI, >>> but >>> > because of the incompatibility of the VULOM firmware I use the old version >>> > of TRLOII. In addition, >>> > >>> because of the leap seconds issue I compiled DRASI first on the PC and >>> > then recompiled it on the RIO (without "make clean"). >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> Best greetings >>> > >>> G?nter >>> > >>> >>> > >>> >>> >>>>________________________________________________________________________ >>> ___ >>> > __________________________________________________________________________ >>> > _____________________ >>> > >>> Von: Hans Toshihide T?rnqvist >>> > >>> Gesendet: Mittwoch, 10. Januar 2024 13:18:41 >>> > >>> 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, >>> > >>> >>> > >>> I would suggest rebuilding nurdlib now that trlo2 has been rebuilt, >>> and >>> > >>> then also rebuild r3bfuser. >>> > >>> >>> > >>> After that probably you can try to run the DAQ :) >>> > >>> >>> > >>> Cheers, >>> > >>> Hans >>> > >>> >>> > >>> On 2024-01-10 13:15, Weber, Guenter Dr. wrote: >>> > >>> > Dear H?kan, >>> > >>> > >>> > >>> > >>> > >>> > using the old TRLOII folder and then recompiling was successfull. >>> > >>> > >>> > >>> > >>> > >>> > Should I now give it a try to start the DAQ? Or is there something >>> > else >>> > >>> > I still need to adjust? >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > Best greetings >>> > >>> > >>> > >>> > G?nter >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > ------------------------------------------------------------------------ >>> > >>> > *Von:* subexp-daq im Auftrag >>> > von >>> > >>> > H?kan T Johansson >>> > >>> > *Gesendet:* Mittwoch, 10. Januar 2024 12:34:26 >>> > >>> > *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 >>> > >>> > >>> > >>> > Hi G?nter, >>> > >>> > >>> > >>> > On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote: >>> > >>> > >>> > >>> >> >>> > >>> >> Hi folks, >>> > >>> >> >>> > >>> >> >>> > >>> >> the old "./find_firmware.pl" was working. This is the output: >>> > >>> >> >>> > >>> >> >>> > >>> >> a1729cda ../ver/rimfaxe0_trlo/rfx0_defs.h >>> > >>> >> 0866c243 ../ver/rimfaxe1_trlo/rfx1_defs.h >>> > >>> >> 5e8f5ef4 ../ver/tridi1_trlo/tridi_defs.h >>> > >>> >> 6e4ba1a9 ../ver/vulom4_trlo/trlo_defs.h >>> > >>> >> 68f8955e ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h >>> > >>> >> af33ed35 ../ver/vulom4_trlo_big/trlo_big_defs.h >>> > >>> >> 1409285e ../ver/vulom4b_trlo/trlo_defs.h >>> > >>> >> d374466d ../fw/tridi1_trlo/tridi_defs.h >>> > >>> >> d96ffc88 ../fw/vulom4_trlo/trlo_defs.h >>> > >>> >> 5b298165 ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h >>> > >>> >> 6f28c0f8 ../fw/vulom4_trlo_big/trlo_big_defs.h >>> > >>> >> fa5020ea ../fw/vulom4_trlo_led/trlo_defs.h >>> > >>> >> 426cb99c ../fw/vulom4b_trlo/trlo_defs.h >>> > >>> >> MKDIR?? fw_a1729cda_rfx0? # ../ver/rimfaxe0_trlo/rfx0_defs.h >>> > >>> >> SYMLINK fw_a1729cda_rfx0/rfx0_defs.h -> >>> > ../../ver/rimfaxe0_trlo/rfx0_defs.h >>> > >>> >> MKDIR?? fw_0866c243_rfx1? # ../ver/rimfaxe1_trlo/rfx1_defs.h >>> > >>> >> SYMLINK fw_0866c243_rfx1/rfx1_defs.h -> >>> > ../../ver/rimfaxe1_trlo/rfx1_defs.h >>> > >>> >> MKDIR?? fw_5e8f5ef4_tridi? # ../ver/tridi1_trlo/tridi_defs.h >>> > >>> >> SYMLINK fw_5e8f5ef4_tridi/tridi_defs.h -> >>> > ../../ver/tridi1_trlo/tridi_defs.h >>> > >>> >> MKDIR?? fw_6e4ba1a9_trlo? # ../ver/vulom4_trlo/trlo_defs.h >>> > >>> >> SYMLINK fw_6e4ba1a9_trlo/trlo_defs.h -> >>> > ../../ver/vulom4_trlo/trlo_defs.h >>> > >>> >> SYMLINK fw_1409285e_trlo -> fw_6e4ba1a9_trlo >>> > >>> >> MKDIR?? fw_68f8955e_trlo_all_in? # >>> > ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h >>> > >>> >> SYMLINK fw_68f8955e_trlo_all_in/trlo_all_in_defs.h -> >>> > ../../ver/vulom4_trlo_all_in/trlo_all_in_defs.h >>> > >>> >> MKDIR?? fw_af33ed35_trlo_big? # >>> > ../ver/vulom4_trlo_big/trlo_big_defs.h >>> > >>> >> SYMLINK fw_af33ed35_trlo_big/trlo_big_defs.h -> >>> > ../../ver/vulom4_trlo_big/trlo_big_defs.h >>> > >>> >> MKDIR?? fw_d374466d_tridi? # ../fw/tridi1_trlo/tridi_defs.h >>> > >>> >> SYMLINK fw_d374466d_tridi/tridi_defs.h -> >>> > ../../fw/tridi1_trlo/tridi_defs.h >>> > >>> >> MKDIR?? fw_d96ffc88_trlo? # ../fw/vulom4_trlo/trlo_defs.h >>> > >>> >> SYMLINK fw_d96ffc88_trlo/trlo_defs.h -> >>> > ../../fw/vulom4_trlo/trlo_defs.h >>> > >>> >> SYMLINK fw_426cb99c_trlo -> fw_d96ffc88_trlo >>> > >>> >> SYMLINK fw_fa5020ea_trlo -> fw_d96ffc88_trlo >>> > >>> >> MKDIR?? fw_5b298165_trlo_all_in? # >>> > ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h >>> > >>> >> SYMLINK fw_5b298165_trlo_all_in/trlo_all_in_defs.h -> >>> > ../../fw/vulom4_trlo_all_in/trlo_all_in_defs.h >>> > >>> >> MKDIR?? fw_6f28c0f8_trlo_big? # >>> ../fw/vulom4_trlo_big/trlo_big_defs.h >>> > >>> >> SYMLINK fw_6f28c0f8_trlo_big/trlo_big_defs.h -> >>> > ../../fw/vulom4_trlo_big/trlo_big_defs.h >>> > >>> >> >>> > >>> >> However, the compilation did end with an error: >>> > >>> >> >>> > >>> >> >>> > >>> >> make[1]: Enteringdirectory`/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl >>> /fw_d96ff >>> > c88_trlo' >>> > >>> >> ?? CC??? bld_ppc-linux_4.2.2/src/trlo_check_version.o >>> > >>> >> ?? CC??? bld_ppc-linux_4.2.2/src/trlo_functions.o >>> > >>> >> ../trlolib/src/trlo_functions.c: In function 'trlo_clear_config': >>> > >>> >> ../trlolib/src/trlo_functions.c:144: error: 'trlo_setup_map' has no >>> > member named 'sync_check_start_mux' >>> > >>> >> ../trlolib/src/trlo_functions.c:146: error: 'trlo_setup_map' has no >>> > member named 'sync_check_stop_mux' >>> > >>> >> ../trlolib/src/trlo_functions.c: In function 'trlo_print_config': >>> > >>> >> ../trlolib/src/trlo_functions.c:825: error: 'trlo_setup_map' has no >>> > member named 'sync_check_start_mux' >>> > >>> >> ../trlolib/src/trlo_functions.c:829: error: 'trlo_setup_map' has no >>> > member named 'sync_check_stop_mux' >>> > >>> >> ../trlolib/src/trlo_functions.c: In function >>> > 'trlo_print_trig_status': >>> > >>> >> ../trlolib/src/trlo_functions.c:1155: error: 'trlo_output_map' has >>> no >>> > member named 'trig_sync_check' >>> > >>> >> make[1]: *** [bld_ppc-linux_4.2.2/src/trlo_functions.o] Error 1 >>> > >>> >> make[1]: Leavingdirectory`/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl >>> /fw_d96ff >>> > c88_trlo' >>> > >>> >> >>> > >>> >> make[1]: Enteringdirectory`/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl >>> /fw_d3744 >>> > 66d_tridi' >>> > >>> >> ?? CC??? bld_ppc-linux_4.2.2/src/tridi_check_version.o >>> > >>> >> ?? CC??? bld_ppc-linux_4.2.2/src/tridi_functions.o >>> > >>> >> ../trlolib/src/trlo_functions.c: In function 'tridi_clear_config': >>> > >>> >> ../trlolib/src/trlo_functions.c:144: error: 'tridi_setup_map' has >>> no >>> > member named 'sync_check_start_mux' >>> > >>> >> ../trlolib/src/trlo_functions.c:146: error: 'tridi_setup_map' has >>> no >>> > member named 'sync_check_stop_mux' >>> > >>> >> ../trlolib/src/trlo_functions.c: In function 'tridi_print_config': >>> > >>> >> ../trlolib/src/trlo_functions.c:825: error: 'tridi_setup_map' has >>> no >>> > member named 'sync_check_start_mux' >>> > >>> >> ../trlolib/src/trlo_functions.c:829: error: 'tridi_setup_map' has >>> no >>> > member named 'sync_check_stop_mux' >>> > >>> >> ../trlolib/src/trlo_functions.c: In function >>> > 'tridi_print_trig_status': >>> > >>> >> ../trlolib/src/trlo_functions.c:1155: error: 'tridi_output_map' has >>> > no member named 'trig_sync_check' >>> > >>> >> make[1]: *** [bld_ppc-linux_4.2.2/src/tridi_functions.o] Error 1 >>> > >>> >> make[1]: Leavingdirectory`/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl >>> /fw_d3744 >>> > 66d_tridi' >>> > >>> >> make: *** [fw_d374466d_tridi_build] Error 2 >>> > >>> > >>> > >>> > That's what I feared.? The new code want something (sync_check_...) >>> > not in >>> > >>> > the older firmware... >>> > >>> > >>> > >>> >> The fallback option is now to delete the new TRLOII folder and >>> > replace it with old one and then repeat the following steps? >>> > >>> >> >>> > >>> >> >>> > >>> >> cd trloii >>> > >>> >> make clean >>> > >>> >> make >>> > >>> >> cd trloctrl >>> > >>> >> make fw_d96ffc88_trlo_build >>> > >>> >> ?make fw_d374466d_tridi_build >>> > >>> >> >>> > >>> >> >>> > >>> >> Is this correct? >>> > >>> > >>> > >>> > Yes. >>> > >>> > >>> > >>> > There should then already be the trloii/fw/ directory, and the links >>> > that >>> > >>> > are created by find_firmware.pl >>> > >>> > >>> > >>> > >>> > >>> >> I also looked for the "--addr=" and this is the result: >>> > >>> > >>> > >>> >> ... >>> > >>> > >>> > >>> > Ok.? I was too optimistic here.? I looked through the grep results, >>> > but >>> > >>> > nothing obvious.? Should be figurable by checking the old scripts >>> and >>> > >>> > following them around.? Is a good way to see how things are done >>> > anyhow ;) >>> > >>> > >>> > >>> > Cheers, >>> > >>> > H?kan >>> > >>> > >>> > >>> > >>> > >>> >> >>> > >>> >> >>> > >>> >> >>> > >>> >> Best greetings >>> > >>> >> >>> > >>> >> G?nter >>> > >>> > >>> > >>> >>> > >>> >>> > >> >>> > >>> > >>> >>> > From g.weber at hi-jena.gsi.de Fri Jan 12 20:21:54 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Fri, 12 Jan 2024 19:21:54 +0000 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: <50174d78-cb5d-440b-bb6d-08e5a11919b8@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <14e1aab1db454f5da272442151f66d56@hi-jena.gsi.de> <43efd4d2fa684387b7839d88617c9e31@hi-jena.gsi.de> <299880b3f6984312aeb94a1b29c3f302@hi-jena.gsi.de> <9f489cb1-234c-52a2-a657-761573313acb@chalmers.se> <72a9169e4d764d80a72988feaff91db3@hi-jena.gsi.de> <2019a2ea-9480-449b-a0da-4bbed3e6a7e7@chalmers.se> <34e673ef4a3f4664989b3167b6a6c335@hi-jena.gsi.de> <26dc0c59-5ac1-4073-bc26-aaf081dc8eb6@chalmers.se> <35fc1cdfa4484b298214067c37448ffb@hi-jena.gsi.de> <47cf2d4c-f59c-6ea7-86ea-f5ec88eabb5c@chalmers.se> <77f957cf-d6cc-d9d7-c96f-5c0dbb8a16d9@chalmers.se> <52af1da7-5486-420b-b6af-b67693bdc213@chalmers.se> , <50174d78-cb5d-440b-bb6d-08e5a11919b8@chalmers.se> Message-ID: Dear Hans, I unset the paths as you suggested. Then I compiled NURDLIB again (this time it showed me different firmware numbers at the start). And then something went wrong with R3DFSUSER compilation: RIO4-MCAL-1 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 make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args udp.h: Could not configure module UDP, build_cc_ppc-linux_4.2.2_debug/nconf/udp.h.log: === UDP:ARPA_INET_H === run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mUDP=1 -DDRASI -I. -Ibuild_cc_ppc-linux_4.2.2_debug -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/dtc_arch -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/hwmap -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo/gen_ppc-linux_4.2.2 -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.bin build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -DDRASI -I. -Ibuild_cc_ppc-linux_4.2.2_debug -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/dtc_arch -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/hwmap -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo/gen_ppc-linux_4.2.2 -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames -L../nurdlib/build_cc_ppc-linux_4.2.2_debug -L/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/hwmap/lib_ppc-linux_4.2.2 /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a -lhwmap /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -lnurdlib -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/lib_ppc-linux_4.2.2 -llwroc_mbscompat -llwroc_main -llwroc_readout -llwroc_nofilter -llwroc -llwroc_netutil -llwroc_parseutil -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -lpthread -lrt -lm -lcesXpcLib -lncurses -llwroc_hwmap_error cc: /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a: No such file or directory cc: /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a: No such file or directory Failed. === UDP:NETINET_IN_H === run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mUDP=1 -DDRASI -I. -Ibuild_cc_ppc-linux_4.2.2_debug -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/dtc_arch -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/hwmap -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo/gen_ppc-linux_4.2.2 -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.bin build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -DDRASI -I. -Ibuild_cc_ppc-linux_4.2.2_debug -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/dtc_arch -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/hwmap -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo/gen_ppc-linux_4.2.2 -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames -L../nurdlib/build_cc_ppc-linux_4.2.2_debug -L/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/hwmap/lib_ppc-linux_4.2.2 /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a -lhwmap /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -lnurdlib -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/lib_ppc-linux_4.2.2 -llwroc_mbscompat -llwroc_main -llwroc_readout -llwroc_nofilter -llwroc -llwroc_netutil -llwroc_parseutil -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -lpthread -lrt -lm -lcesXpcLib -lncurses -llwroc_hwmap_error cc: /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a: No such file or directory cc: /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a: No such file or directory Failed. === UDP:BSD_IN_H === run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mUDP=1 -DDRASI -I. -Ibuild_cc_ppc-linux_4.2.2_debug -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/dtc_arch -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/hwmap -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo/gen_ppc-linux_4.2.2 -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.bin build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -DDRASI -I. -Ibuild_cc_ppc-linux_4.2.2_debug -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/dtc_arch -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/hwmap -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo/gen_ppc-linux_4.2.2 -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames -L../nurdlib/build_cc_ppc-linux_4.2.2_debug -L/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/hwmap/lib_ppc-linux_4.2.2 /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a -lhwmap /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -lnurdlib -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/lib_ppc-linux_4.2.2 -llwroc_mbscompat -llwroc_main -llwroc_readout -llwroc_nofilter -llwroc -llwroc_netutil -llwroc_parseutil -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -lpthread -lrt -lm -lcesXpcLib -lncurses -llwroc_hwmap_error cc: /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a: No such file or directory cc: /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a: No such file or directory Failed. make[1]: *** [build_cc_ppc-linux_4.2.2_debug/nconf.args] Error 1 make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' make: *** [drasi] Error 2 To me it looks like the firmware variable is empty now, right? Best greetings and have a nice weekend G?nter ________________________________ Von: Hans Toshihide T?rnqvist Gesendet: Freitag, 12. Januar 2024 16:16:54 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, --- Let's start with the nurdlib build: The *_FW env vars are selected by nurdlib/Makefile by looking at the available $TRLOII_PATH/trloctrl/fw_* directories. Except, if they were already set! This lets the user control exactly (some of) the decisions made by nurdlib, otherwise the machines will take over. Probably there are some lines in ~/.tcshrc or a similar file which sets them. Try commenting them out, log out of the Rio4, log back in, "make clean" and already then you should see which firmwares are selected. Then run "make". You could also set *_FW explicitly to the new firmware if you prefer or the auto-selection doesn't work. I am working on the nurdlib documentation, actually even on the enviroment variable section right now, so I'll add this in :) So, for nurdlib, please check the env vars: - TRLOII_PATH - TRIDI_FW - VULOM4_FW --- r3bfuser build: I am guessing that this is related to mismatching firmware numbers, the build pulls data from what nurdlib decided. If nurdlib builds with the correct numbers as described above, I hope r3bfuser will "just work" (crossing all my fingers). --- The *_CTRL variables are not used by nurdlib and r3bfuser, and are only convenient on the cmd-line by for example: $TRIDI_CTRL --addr=n --print-config But they should point to the correct trloctrl builds for your new firmware or they will complain when they talk to the hardware! --- Cheers, Hans On 2024-01-12 15:33, Weber, Guenter Dr. wrote: > Dear friends, > > > I did set up a second DAQ system and followed the instructions provided by > > > Everything goes smoothly (I had to use the workaround in TRLOII) until > compilation of R3DFUSER. This is the output (compilation done on the RIO): > > > RIO4-MCAL-1 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 > make[1]: Entering directory > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > udp.h: Could not configure module UDP, > build_cc_ppc-linux_4.2.2_debug/nconf/udp.h.log: > === UDP:ARPA_INET_H === > run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o > build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.c -I. -I > build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mUDP=1 -DDRASI > -I. -Ibuild_cc_ppc-linux_4.2.2_debug > -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii > -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames > run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.bin > build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o -I. -I > build_cc_ppc-linux_4.2.2_debug/nconfing/ -DDRASI -I. > -Ibuild_cc_ppc-linux_4.2.2_debug > -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii > -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames -L../nurdlib/build_cc_ppc-linux_4.2.2_debug /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -lnurdlib -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/lib_ppc-linux_4.2.2 -llwroc_mbscompat -llwroc_main -llwroc_readout -llwroc_nofilter -llwroc -llwroc_netutil -llwroc_parseutil -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -lpthread -lrt -lm -lcesXpcLib -lncurses -llwroc_hwmap_error > cc: > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a: No such file or directory > cc: > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a: No such file or directory > Failed. > === UDP:NETINET_IN_H === > run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o > build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.c -I. -I > build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mUDP=1 -DDRASI > -I. -Ibuild_cc_ppc-linux_4.2.2_debug > -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii > -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames > run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.bin > build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o -I. -I > build_cc_ppc-linux_4.2.2_debug/nconfing/ -DDRASI -I. > -Ibuild_cc_ppc-linux_4.2.2_debug > -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii > -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames -L../nurdlib/build_cc_ppc-linux_4.2.2_debug /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -lnurdlib -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/lib_ppc-linux_4.2.2 -llwroc_mbscompat -llwroc_main -llwroc_readout -llwroc_nofilter -llwroc -llwroc_netutil -llwroc_parseutil -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -lpthread -lrt -lm -lcesXpcLib -lncurses -llwroc_hwmap_error > cc: > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a: No such file or directory > cc: > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a: No such file or directory > Failed. > === UDP:BSD_IN_H === > run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o > build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.c -I. -I > build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mUDP=1 -DDRASI > -I. -Ibuild_cc_ppc-linux_4.2.2_debug > -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii > -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames > run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.bin > build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o -I. -I > build_cc_ppc-linux_4.2.2_debug/nconfing/ -DDRASI -I. > -Ibuild_cc_ppc-linux_4.2.2_debug > -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii > -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames -L../nurdlib/build_cc_ppc-linux_4.2.2_debug /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -lnurdlib -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/lib_ppc-linux_4.2.2 -llwroc_mbscompat -llwroc_main -llwroc_readout -llwroc_nofilter -llwroc -llwroc_netutil -llwroc_parseutil -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -lpthread -lrt -lm -lcesXpcLib -lncurses -llwroc_hwmap_error > cc: > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a: No such file or directory > cc: > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a: No such file or directory > Failed. > make[1]: *** [build_cc_ppc-linux_4.2.2_debug/nconf.args] Error 1 > make[1]: Leaving directory > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' > make: *** [drasi] Error 2 > > I had a look at the environment variables which I took over from the > already existing system and I guess, I would need to modify some of > these lines: > > > VULOM4_CTRL=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/bin_ppc-linux_4.2.2/trlo_ctrl > > TRIDI_CTRL=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/bin_ppc-linux_4.2.2/tridi_ctrl > > > This is the content of the folder on the new system: > > > mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl$ ls -l > insgesamt 52 > drwxr-sr-x 2 mbsdaq users 4096 Jan 12 13:57 examples > -rwxr-xr-x 1 mbsdaq users 7389 Jan 12 13:57 find_firmwares.pl > -rw-r--r-- 1 mbsdaq users 114 Jan 12 15:02 firmwaredirs > drwxr-sr-x 2 mbsdaq users 4096 Jan 12 15:00 fw_0866c243_rfx1 > lrwxrwxrwx 1 mbsdaq users 16 Jan 12 15:00 fw_1409285e_trlo -> > fw_6e4ba1a9_trlo > drwxr-sr-x 2 mbsdaq users 4096 Jan 12 15:00 fw_5e8f5ef4_tridi > drwxr-sr-x 2 mbsdaq users 4096 Jan 12 15:00 fw_68f8955e_trlo_all_in > drwxr-sr-x 14 mbsdaq users 4096 Jan 12 15:02 fw_6e4ba1a9_trlo > drwxr-sr-x 2 mbsdaq users 4096 Jan 12 15:00 fw_a1729cda_rfx0 > lrwxrwxrwx 1 mbsdaq users 16 Jan 12 15:00 fw_a73c5093_trlo -> > fw_6e4ba1a9_trlo > drwxr-sr-x 2 mbsdaq users 4096 Jan 12 15:00 fw_af33ed35_trlo_big > -rw-r--r-- 1 mbsdaq users 994 Jan 12 13:57 Makefile > -rwxr-xr-x 1 mbsdaq users 662 Jan 12 13:57 trloctrl.sh > drwxr-sr-x 5 mbsdaq users 4096 Jan 12 13:57 trlolib > > I also had a look at the output at the beginning of the NURDLIB > compilation and if I understand correctly, it looks like the VULOM in > the new system has the same firmware as the one in the old system: > > > TRIDI_FW=d374466d > VULOM4_FW=d96ffc88 > > What to do now? > > > > > Thank you very much! > > > > > Best greetings > > G?nter > > > > ------------------------------------------------------------------------ > *Von:* Hans Toshihide T?rnqvist > *Gesendet:* Freitag, 12. Januar 2024 14:34:24 > *An:* Weber, Guenter Dr.; H?kan T Johansson > *Betreff:* Re: AW: AW: AW: AW: [subexp-daq] NURDLIB: - how to check > which version is installed and how to update to the most recent version > It looks to be mirrored from git.chalmers.se, so should work. > > Cheers, > Hans > > On 2024-01-12 14:22, Weber, Guenter Dr. wrote: >> Is the UCESB version on GITLAB also a mirror? Then I could download >> everything from GITLAB? >> >> >> ------------------------------------------------------------------------ >> *Von:* H?kan T Johansson >> *Gesendet:* Freitag, 12. Januar 2024 14:19:23 >> *An:* Weber, Guenter Dr. >> *Cc:* Hans Toshihide T?rnqvist >> *Betreff:* Re: AW: AW: AW: [subexp-daq] NURDLIB: - how to check which >> version is installed and how to update to the most recent version >> >> Ahh, sorry about that, please try with >> >> https://git.chalmers.se/expsubphys/drasi.git > >> > >> https://git.chalmers.se/expsubphys/ucesb.git > >> > >> >> and the drasi varsion on gitlab.com is a mirror so should work equally >> well. >> >> Cheers, >> H?kan >> >> >> >> On Fri, 12 Jan 2024, Weber, Guenter Dr. wrote: >> >>> >>> Dear H?kan, >>> >>> >>> I encountered the following issue(s): >>> >>> >>> git clone git at git.chalmers.se:expsubphys/drasi.git >>> git clone git at git.chalmers.se:expsubphys/ucesb.git >>> >>> 1) I don't have access to git.chalmers.se, only to gitlab.com. >>> 2) There is a DRASI also on gitlab.com, that I was using so far. But is it >>> the same as on git.chalmers.se? >>> >>> >>> Best greetings >>> G?nter >>> >>> >>> >>> ____________________________________________________________________________ >>> Von: H?kan T Johansson >>> Gesendet: Donnerstag, 11. Januar 2024 08:15 >>> An: Weber, Guenter Dr. >>> Cc: Hans Toshihide T?rnqvist >>> Betreff: Re: AW: AW: [subexp-daq] NURDLIB: - how to check which version is >>> installed and how to update to the most recent version >>> >>> Dear G?nter, >>> >>> thanks! >>> >>> 1) may be the reason for that strange error in typedefs.h, since it may be >>> that it picks up the mystdint.h from the trloii compile but uses it in the >>> drasi header somehow - or vice versa.... (They are the same and typically >>> kept in sync, but we may here have hit a snag with the different versions >>> and an update I did a while ago...) >>> >>> 2) Should be fine, is just an attempt at indenting the pre-processor >>> directives, without having my editor unindent the code. >>> >>> >>> It sounds like a very nice plan if you have the hardware to set up a >>> second system from scratch. I have attached a short instruction on how to >>> downloading and compiling the codes from scratch. >>> >>> It would not surprise me if there already exist something like that, but >>> then we have two of them :-) If not, we can put this (with whatever fixes >>> are needed) up somewhere (gitlab wiki or so). >>> >>> I did test it - but that does not guarantee much... >>> >>> Cheers, >>> H?kan >>> >>> >>> >>> On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote: >>> >>> > >>> > P.S. I looked a bit into the code that is compiled right before the error >>> > appear. >>> > >>> > >>> > I have no idea if this might causing problems, but in >>> > >>> > ../dtc_arch/acc_def/mystdint.h >>> > I found two things: >>> > >>> > >>> > 1) >>> > >>> > New version: >>> > >>> > #if ACC_DEF__MYSTDINT_stdint_h >>> > # include >>> > #endif >>> > /* This is a local fall-back solution, so should be last. */ >>> > #if ACC_DEF__MYSTDINT_mystdint >>> > >>> > Old version: >>> > >>> > #if ACC_DEF_MYSTDINT_stdint_h >>> > # include >>> > #endif >>> > /* This is a local fall-back solution, so should be last. */ >>> > #if ACC_DEF_MYSTDINT_mystdint >>> > >>> > (Note the double "_" before MYSTDINT.) >>> > >>> > >>> > 2) >>> > >>> > In both versions there are strange blanks after "#" at two positions: >>> > >>> > # include "acc_auto_def/mystdint.h" >>> > # define UINT64_C(v) v##ULL >>> > >>> > >>> > >>> > Best greetings >>> > >>> > G?nter >>> > >>> > >>> >___________________________________________________________________________ >>> _ >>> > Von: Weber, Guenter Dr. >>> > Gesendet: Mittwoch, 10. Januar 2024 19:32:59 >>> > An: Hans Toshihide T?rnqvist >>> > Betreff: AW: AW: [subexp-daq] NURDLIB: - how to check which version is >>> > installed and how to update to the most recent version >>> > >>> > Dear Hans, >>> > >>> > >>> > I could not reproduce the error from two hours ago. Nurdlib was laready >>> set >>> > to the right branch and in a second try compiled without problems on the >>> > RIO. >>> > >>> > >>> > However, we are now back at square one: >>> > >>> > >>> > 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 >>> > make[1]: Entering directory >>> > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >>> > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args >>> > UDP:ARPA_INET_H >>> > CC build_cc_ppc-linux_4.2.2_debug/f_user.o >>> > CC build_cc_ppc-linux_4.2.2_debug/subevent.o >>> > In file includedfrom/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscom >>> pat/ >>> > s_veshe.h:6, >>> > from ./subevent.h:11, >>> > from subevent.c:1: >>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>> >>> > typedefs.h:6: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTS8' >>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>> >>> > typedefs.h:7: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTU8' >>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>> >>> > typedefs.h:8: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTS4' >>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>> >>> > typedefs.h:9: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTU4' >>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>> >>> > typedefs.h:10: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTS2' >>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>> >>> > typedefs.h:11: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTU2' >>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>> >>> > typedefs.h:12: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTS1' >>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>> >>> > typedefs.h:13: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTU1' >>> > In file included from ./subevent.h:11, >>> > from subevent.c:1: >>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>> >>> > s_veshe.h:11: error: expected specifier-qualifier-list before 'INTS4' >>> > subevent.c: In function 'begin_goosy_vme_subevent': >>> > subevent.c:12: error: 's_veshe' has no member named 'l_dlen' >>> > subevent.c: In function 'end_goosy_vme_subevent': >>> > subevent.c:45: error: 's_veshe' has no member named 'l_dlen' >>> > make[1]: *** [build_cc_ppc-linux_4.2.2_debug/subevent.o] Error 1 >>> > make[1]: Leaving directory >>> > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >>> > make: *** [drasi] Error 2 >>> > RIO4-MCAL-2 mbsdaq > >>> > >>> > Thus, downloading and recompiling DRASI, NURDLIB, and R3BFUSER did not >>> solve >>> > the problem with the latter. >>> > >>> > >>> > >>> > ?? >>> > >>> > >>> > >>> > >>> > >>> > >>> > Best greetings >>> > >>> > G?nter >>> > >>> > >>> > >>> > >>> >___________________________________________________________________________ >>> _ >>> > Von: Hans Toshihide T?rnqvist >>> > Gesendet: Mittwoch, 10. Januar 2024 18:24:21 >>> > An: Weber, Guenter Dr. >>> > Betreff: Re: AW: [subexp-daq] NURDLIB: - how to check which version is >>> > installed and how to update to the most recent version >>> > Sorry I got held up. >>> > >>> > I compiled 'mcal_daq_merge' from Gitlab on a rio4 just fine, so I am >>> > just as puzzled where those event buffer test errors come from... >>> > >>> > Any luck with a 'make clean && make'? >>> > >>> > Cheers, >>> > >>> > Hans >>> > >>> > On 2024-01-10 17:36, Weber, Guenter Dr. wrote: >>> > > Dear Hans, >>> > > >>> > > >>> > > now things really get weird. >>> > > >>> > > >>> > > I again downloaded NURDLIB, DRASI, and R3BFUSER. DRASI compiled without >>> > > problems (first on PC, then on RIO). >>> > > >>> > > >>> > > Now NURDLIB compilation stops with an error: >>> > > >>> > > >>> > > LD build_cc_ppc-linux_4.2.2_debug/test_ntest >>> > > LD build_cc_ppc-linux_4.2.2_debug/test >>> > > /bin/sh: line 1: 22504 Aborted >>> > > ./build_cc_ppc-linux_4.2.2_debug/test > >>> > > build_cc_ppc-linux_4.2.2_debug/test.log 2>&1 >>> > > [tests/argmatch.c:127: Shorts] >>> > > [tests/argmatch.c:128: Longs] >>> > > [tests/argmatch.c:129: Combos] >>> > > [tests/argmatch.c:130: ShortsWithValues] >>> > > [tests/argmatch.c:131: LongsWithValues] >>> > > [tests/argmatch.c:132: MissingValue] >>> > > [tests/base.c:110: MemoryCheck] >>> > > [tests/base.c:111: EventBufferAdvance] >>> > > 2024-02-10,19:58:33:ERRR: Invalid pointer to advance event buffer. >>> > > [tests/base.c:47] >>> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:47] >>> > > 2024-02-10,19:58:33:ERRR: Invalid pointer to advance event buffer. >>> > > [tests/base.c:56] >>> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:56] >>> > > 2024-02-10,19:58:33:ERRR: Tried to advance outside event buffer. >>> > > [tests/base.c:72] >>> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:72] >>> > > [tests/base.c:112: EventBufferInvariant] >>> > > 2024-02-10,19:58:33:ERRR: Event-buffer inconsistent (0x1080e008:11 != >>> > > 0x1080e008:10). [tests/base.c:87] >>> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:87] >>> > > 2024-02-10,19:58:33:ERRR: Event-buffer inconsistent (0x1080e008:9 != >>> > > 0x1080e008:10). [tests/base.c:91] >>> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:91] >>> > > 2024-02-10,19:58:33:ERRR: Event-buffer inconsistent (0x1080e009:10 != >>> > > 0x1080e008:10). [tests/base.c:95] >>> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:95] >>> > > 2024-02-10,19:58:33:ERRR: Event-buffer inconsistent (0x1080e007:10 != >>> > > 0x1080e008:10). [tests/base.c:99] >>> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:99] >>> > > [tests/bits.c:43: Gets] >>> > > [tests/bits.c:44: CountLoops] >>> > > [tests/caen_v1190.c:79: DefaultConfig] >>> > > 2024-02-10,19:58:33:INFO: Will try default cfg >>> > > path='/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg', >>> > > can be set with NURDLIB_DEF_PATH. [config/config.c:181] >>> > > 2024-02-10,19:58:33:INFO: Opened './tests/caen_v1190_empty.cfg' { >>> > > [config/parser.c:287] >>> > > 2024-02-10,19:58:33:ERRR: .Could not load default or user config >>> > > 'caen_v1190.cfg'. [config/config.c:1483] >>> > > 2024-02-10,19:58:33:ERRR: .Calling abort()... [config/config.c:1483] >>> > > make: *** [build_cc_ppc-linux_4.2.2_debug/test_ok] Error 1 >>> > > >>> > > >>> > > Did you change anything in the GITLAB version between yesterday and 15 >>> > > minutes ago? >>> > > >>> > > >>> > > >>> > > Sorry, sorry, sorry ?? >>> > > >>> > > >>> > > >>> > > >>> > > Best greetings >>> > > >>> > > G?nter >>> > > >>> > > >>> > > >>> > > P.S. Tomorrow or on Friday, I will set up a second DAQ system with >>> > > identical hardware. Then we can play around with no limits, including >>> > > flashing the firmware of the VULOM, without messing around with the >>> > > already running system as it is the case now. >>> > > >>> > > >>> > > ------------------------------------------------------------------------ >>> > > *Von:* Hans Toshihide T?rnqvist >>> > > *Gesendet:* Mittwoch, 10. Januar 2024 16:59:07 >>> > > *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, >>> > > >>> > > Did you try to update r3bfuser? I cannot see this problem with new >>> > > versions of drasi+nurdlib+r3bfuser that are on Gitlab, and the trloii >>> > > version shouldn't matter much in this case. >>> > > >>> > > Cheers, >>> > > >>> > > Hans >>> > > >>> > > On 2024-01-10 16:54, Weber, Guenter Dr. wrote: >>> > >> Dear H?kan, >>> > >> >>> > >> >>> > >> I followed your suggestion and the result is this: >>> > >> >>> > >> >>> > >> 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 >>> > >> make[1]: Entering directory >>> > >> `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >>> > >> CC build_cc_ppc-linux_4.2.2_debug/subevent.o >>> > >> In file included from ./subevent.h:11, >>> > >> from subevent.c:1: >>> >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompa >>> t/ >>> > s_veshe.h:16: error: expected specifier-qualifier-list before 'CHARS' >>> > >> make[1]: *** [build_cc_ppc-linux_4.2.2_debug/subevent.o] Error 1 >>> > >> make[1]: Leaving directory >>> > >> `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >>> > >> make: *** [drasi] Error 2 >>> > >> >>> > >> >>> > >> Best greetings >>> > >> >>> > >> G?nter >>> > >> >>> > >> >>> > >> >>> ------------------------------------------------------------------------ >>> > >> *Von:* subexp-daq im Auftrag von >>> > >> H?kan T Johansson >>> > >> *Gesendet:* Mittwoch, 10. Januar 2024 16:07:52 >>> > >> *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, >>> > >> >>> > >> those errors look strange to me. I am not able to reproduce on a >>> similar >>> > >> system. >>> > >> >>> > >> As a workaround (to see how far we get), in subevent.h in the r3bfuser/ >>> > >> directory, could you uncomment these: >>> > >> >>> > >> #define MBS_TYPEDEFS_H >>> > >> typedef char CHARX; >>> > >> typedef int short INTS2; >>> > >> typedef int INTS4; >>> > >> >>> > >> and comment out the "typedefs.h" in >>> > >> >>> >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompa >>> t/ >>> > s_veshe.h >>> > >> >>> > >> on line 6. And then try again. >>> > >> >>> > >> Cheers, >>> > >> H?kan >>> > >> >>> > >> >>> > >> On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote: >>> > >> >>> > >>> >>> > >>> Dear Hans, >>> > >>> >>> > >>> >>> > >>> I now did rebuild NURDLIB and DRASI. Then I tried to compile R3BFUSER >>> > and this is the result: >>> > >>> >>> > >>> >>> > >>> RIO4-MCAL-2 mbsdaq > cd r3bfuser/ >>> > >>> 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 >>> > >>> make[1]: Entering directory >>> > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >>> > >>> NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args >>> > >>> UDP:ARPA_INET_H >>> > >>> CC build_cc_ppc-linux_4.2.2_debug/f_user.o >>> > >>> CC build_cc_ppc-linux_4.2.2_debug/subevent.o >>> > >>> In file includedfrom/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscom >>> pat/ >>> > s_veshe.h:6, >>> > >>> from ./subevent.h:11, >>> > >>> from subevent.c:1: >>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>> at/ >>> > typedefs.h:6: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTS8' >>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>> at/ >>> > typedefs.h:7: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTU8' >>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>> at/ >>> > typedefs.h:8: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTS4' >>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>> at/ >>> > typedefs.h:9: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTU4' >>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>> at/ >>> > typedefs.h:10: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTS2' >>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>> at/ >>> > typedefs.h:11: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTU2' >>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>> at/ >>> > typedefs.h:12: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTS1' >>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>> at/ >>> > typedefs.h:13: error: expected '=', ',', ';', 'asm' or '__attribute__' >>> > before 'INTU1' >>> > >>> In file included from ./subevent.h:11, >>> > >>> from subevent.c:1: >>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>> at/ >>> > s_veshe.h:11: error: expected specifier-qualifier-list before 'INTS4' >>> > >>> subevent.c: In function 'begin_goosy_vme_subevent': >>> > >>> subevent.c:12: error: 's_veshe' has no member named 'l_dlen' >>> > >>> subevent.c: In function 'end_goosy_vme_subevent': >>> > >>> subevent.c:45: error: 's_veshe' has no member named 'l_dlen' >>> > >>> make[1]: *** [build_cc_ppc-linux_4.2.2_debug/subevent.o] Error 1 >>> > >>> make[1]: Leaving directory >>> > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >>> > >>> make: *** [drasi] Error 2 >>> > >>> >>> > >>> Reminder: I am using the most recent versions of NURDLIB and DRASI, >>> but >>> > because of the incompatibility of the VULOM firmware I use the old version >>> > of TRLOII. In addition, >>> > >>> because of the leap seconds issue I compiled DRASI first on the PC and >>> > then recompiled it on the RIO (without "make clean"). >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> Best greetings >>> > >>> G?nter >>> > >>> >>> > >>> >>> >>>>________________________________________________________________________ >>> ___ >>> > __________________________________________________________________________ >>> > _____________________ >>> > >>> Von: Hans Toshihide T?rnqvist >>> > >>> Gesendet: Mittwoch, 10. Januar 2024 13:18:41 >>> > >>> 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, >>> > >>> >>> > >>> I would suggest rebuilding nurdlib now that trlo2 has been rebuilt, >>> and >>> > >>> then also rebuild r3bfuser. >>> > >>> >>> > >>> After that probably you can try to run the DAQ :) >>> > >>> >>> > >>> Cheers, >>> > >>> Hans >>> > >>> >>> > >>> On 2024-01-10 13:15, Weber, Guenter Dr. wrote: >>> > >>> > Dear H?kan, >>> > >>> > >>> > >>> > >>> > >>> > using the old TRLOII folder and then recompiling was successfull. >>> > >>> > >>> > >>> > >>> > >>> > Should I now give it a try to start the DAQ? Or is there something >>> > else >>> > >>> > I still need to adjust? >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > Best greetings >>> > >>> > >>> > >>> > G?nter >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > ------------------------------------------------------------------------ >>> > >>> > *Von:* subexp-daq im Auftrag >>> > von >>> > >>> > H?kan T Johansson >>> > >>> > *Gesendet:* Mittwoch, 10. Januar 2024 12:34:26 >>> > >>> > *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 >>> > >>> > >>> > >>> > Hi G?nter, >>> > >>> > >>> > >>> > On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote: >>> > >>> > >>> > >>> >> >>> > >>> >> Hi folks, >>> > >>> >> >>> > >>> >> >>> > >>> >> the old "./find_firmware.pl" was working. This is the output: >>> > >>> >> >>> > >>> >> >>> > >>> >> a1729cda ../ver/rimfaxe0_trlo/rfx0_defs.h >>> > >>> >> 0866c243 ../ver/rimfaxe1_trlo/rfx1_defs.h >>> > >>> >> 5e8f5ef4 ../ver/tridi1_trlo/tridi_defs.h >>> > >>> >> 6e4ba1a9 ../ver/vulom4_trlo/trlo_defs.h >>> > >>> >> 68f8955e ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h >>> > >>> >> af33ed35 ../ver/vulom4_trlo_big/trlo_big_defs.h >>> > >>> >> 1409285e ../ver/vulom4b_trlo/trlo_defs.h >>> > >>> >> d374466d ../fw/tridi1_trlo/tridi_defs.h >>> > >>> >> d96ffc88 ../fw/vulom4_trlo/trlo_defs.h >>> > >>> >> 5b298165 ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h >>> > >>> >> 6f28c0f8 ../fw/vulom4_trlo_big/trlo_big_defs.h >>> > >>> >> fa5020ea ../fw/vulom4_trlo_led/trlo_defs.h >>> > >>> >> 426cb99c ../fw/vulom4b_trlo/trlo_defs.h >>> > >>> >> MKDIR fw_a1729cda_rfx0 # ../ver/rimfaxe0_trlo/rfx0_defs.h >>> > >>> >> SYMLINK fw_a1729cda_rfx0/rfx0_defs.h -> >>> > ../../ver/rimfaxe0_trlo/rfx0_defs.h >>> > >>> >> MKDIR fw_0866c243_rfx1 # ../ver/rimfaxe1_trlo/rfx1_defs.h >>> > >>> >> SYMLINK fw_0866c243_rfx1/rfx1_defs.h -> >>> > ../../ver/rimfaxe1_trlo/rfx1_defs.h >>> > >>> >> MKDIR fw_5e8f5ef4_tridi # ../ver/tridi1_trlo/tridi_defs.h >>> > >>> >> SYMLINK fw_5e8f5ef4_tridi/tridi_defs.h -> >>> > ../../ver/tridi1_trlo/tridi_defs.h >>> > >>> >> MKDIR fw_6e4ba1a9_trlo # ../ver/vulom4_trlo/trlo_defs.h >>> > >>> >> SYMLINK fw_6e4ba1a9_trlo/trlo_defs.h -> >>> > ../../ver/vulom4_trlo/trlo_defs.h >>> > >>> >> SYMLINK fw_1409285e_trlo -> fw_6e4ba1a9_trlo >>> > >>> >> MKDIR fw_68f8955e_trlo_all_in # >>> > ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h >>> > >>> >> SYMLINK fw_68f8955e_trlo_all_in/trlo_all_in_defs.h -> >>> > ../../ver/vulom4_trlo_all_in/trlo_all_in_defs.h >>> > >>> >> MKDIR fw_af33ed35_trlo_big # >>> > ../ver/vulom4_trlo_big/trlo_big_defs.h >>> > >>> >> SYMLINK fw_af33ed35_trlo_big/trlo_big_defs.h -> >>> > ../../ver/vulom4_trlo_big/trlo_big_defs.h >>> > >>> >> MKDIR fw_d374466d_tridi # ../fw/tridi1_trlo/tridi_defs.h >>> > >>> >> SYMLINK fw_d374466d_tridi/tridi_defs.h -> >>> > ../../fw/tridi1_trlo/tridi_defs.h >>> > >>> >> MKDIR fw_d96ffc88_trlo # ../fw/vulom4_trlo/trlo_defs.h >>> > >>> >> SYMLINK fw_d96ffc88_trlo/trlo_defs.h -> >>> > ../../fw/vulom4_trlo/trlo_defs.h >>> > >>> >> SYMLINK fw_426cb99c_trlo -> fw_d96ffc88_trlo >>> > >>> >> SYMLINK fw_fa5020ea_trlo -> fw_d96ffc88_trlo >>> > >>> >> MKDIR fw_5b298165_trlo_all_in # >>> > ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h >>> > >>> >> SYMLINK fw_5b298165_trlo_all_in/trlo_all_in_defs.h -> >>> > ../../fw/vulom4_trlo_all_in/trlo_all_in_defs.h >>> > >>> >> MKDIR fw_6f28c0f8_trlo_big # >>> ../fw/vulom4_trlo_big/trlo_big_defs.h >>> > >>> >> SYMLINK fw_6f28c0f8_trlo_big/trlo_big_defs.h -> >>> > ../../fw/vulom4_trlo_big/trlo_big_defs.h >>> > >>> >> >>> > >>> >> However, the compilation did end with an error: >>> > >>> >> >>> > >>> >> >>> > >>> >> make[1]: Enteringdirectory`/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl >>> /fw_d96ff >>> > c88_trlo' >>> > >>> >> CC bld_ppc-linux_4.2.2/src/trlo_check_version.o >>> > >>> >> CC bld_ppc-linux_4.2.2/src/trlo_functions.o >>> > >>> >> ../trlolib/src/trlo_functions.c: In function 'trlo_clear_config': >>> > >>> >> ../trlolib/src/trlo_functions.c:144: error: 'trlo_setup_map' has no >>> > member named 'sync_check_start_mux' >>> > >>> >> ../trlolib/src/trlo_functions.c:146: error: 'trlo_setup_map' has no >>> > member named 'sync_check_stop_mux' >>> > >>> >> ../trlolib/src/trlo_functions.c: In function 'trlo_print_config': >>> > >>> >> ../trlolib/src/trlo_functions.c:825: error: 'trlo_setup_map' has no >>> > member named 'sync_check_start_mux' >>> > >>> >> ../trlolib/src/trlo_functions.c:829: error: 'trlo_setup_map' has no >>> > member named 'sync_check_stop_mux' >>> > >>> >> ../trlolib/src/trlo_functions.c: In function >>> > 'trlo_print_trig_status': >>> > >>> >> ../trlolib/src/trlo_functions.c:1155: error: 'trlo_output_map' has >>> no >>> > member named 'trig_sync_check' >>> > >>> >> make[1]: *** [bld_ppc-linux_4.2.2/src/trlo_functions.o] Error 1 >>> > >>> >> make[1]: Leavingdirectory`/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl >>> /fw_d96ff >>> > c88_trlo' >>> > >>> >> >>> > >>> >> make[1]: Enteringdirectory`/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl >>> /fw_d3744 >>> > 66d_tridi' >>> > >>> >> CC bld_ppc-linux_4.2.2/src/tridi_check_version.o >>> > >>> >> CC bld_ppc-linux_4.2.2/src/tridi_functions.o >>> > >>> >> ../trlolib/src/trlo_functions.c: In function 'tridi_clear_config': >>> > >>> >> ../trlolib/src/trlo_functions.c:144: error: 'tridi_setup_map' has >>> no >>> > member named 'sync_check_start_mux' >>> > >>> >> ../trlolib/src/trlo_functions.c:146: error: 'tridi_setup_map' has >>> no >>> > member named 'sync_check_stop_mux' >>> > >>> >> ../trlolib/src/trlo_functions.c: In function 'tridi_print_config': >>> > >>> >> ../trlolib/src/trlo_functions.c:825: error: 'tridi_setup_map' has >>> no >>> > member named 'sync_check_start_mux' >>> > >>> >> ../trlolib/src/trlo_functions.c:829: error: 'tridi_setup_map' has >>> no >>> > member named 'sync_check_stop_mux' >>> > >>> >> ../trlolib/src/trlo_functions.c: In function >>> > 'tridi_print_trig_status': >>> > >>> >> ../trlolib/src/trlo_functions.c:1155: error: 'tridi_output_map' has >>> > no member named 'trig_sync_check' >>> > >>> >> make[1]: *** [bld_ppc-linux_4.2.2/src/tridi_functions.o] Error 1 >>> > >>> >> make[1]: Leavingdirectory`/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl >>> /fw_d3744 >>> > 66d_tridi' >>> > >>> >> make: *** [fw_d374466d_tridi_build] Error 2 >>> > >>> > >>> > >>> > That's what I feared. The new code want something (sync_check_...) >>> > not in >>> > >>> > the older firmware... >>> > >>> > >>> > >>> >> The fallback option is now to delete the new TRLOII folder and >>> > replace it with old one and then repeat the following steps? >>> > >>> >> >>> > >>> >> >>> > >>> >> cd trloii >>> > >>> >> make clean >>> > >>> >> make >>> > >>> >> cd trloctrl >>> > >>> >> make fw_d96ffc88_trlo_build >>> > >>> >> make fw_d374466d_tridi_build >>> > >>> >> >>> > >>> >> >>> > >>> >> Is this correct? >>> > >>> > >>> > >>> > Yes. >>> > >>> > >>> > >>> > There should then already be the trloii/fw/ directory, and the links >>> > that >>> > >>> > are created by find_firmware.pl >>> > >>> > >>> > >>> > >>> > >>> >> I also looked for the "--addr=" and this is the result: >>> > >>> > >>> > >>> >> ... >>> > >>> > >>> > >>> > Ok. I was too optimistic here. I looked through the grep results, >>> > but >>> > >>> > nothing obvious. Should be figurable by checking the old scripts >>> and >>> > >>> > following them around. Is a good way to see how things are done >>> > anyhow ;) >>> > >>> > >>> > >>> > Cheers, >>> > >>> > H?kan >>> > >>> > >>> > >>> > >>> > >>> >> >>> > >>> >> >>> > >>> >> >>> > >>> >> Best greetings >>> > >>> >> >>> > >>> >> G?nter >>> > >>> > >>> > >>> >>> > >>> >>> > >> >>> > >>> > >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.tornqvist at chalmers.se Fri Jan 12 20:57:28 2024 From: hans.tornqvist at chalmers.se (=?ISO-8859-1?Q?Hans_Toshihide_T=F6rnqvist?=) Date: Fri, 12 Jan 2024 20:57:28 +0100 Subject: [subexp-daq] NURDLIB: - how to check which version is installed and how to update to the most recent version In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <43efd4d2fa684387b7839d88617c9e31@hi-jena.gsi.de> <299880b3f6984312aeb94a1b29c3f302@hi-jena.gsi.de> <9f489cb1-234c-52a2-a657-761573313acb@chalmers.se> <72a9169e4d764d80a72988feaff91db3@hi-jena.gsi.de> <2019a2ea-9480-449b-a0da-4bbed3e6a7e7@chalmers.se> <34e673ef4a3f4664989b3167b6a6c335@hi-jena.gsi.de> <26dc0c59-5ac1-4073-bc26-aaf081dc8eb6@chalmers.se> <35fc1cdfa4484b298214067c37448ffb@hi-jena.gsi.de> <47cf2d4c-f59c-6ea7-86ea-f5ec88eabb5c@chalmers.se> <77f957cf-d6cc-d9d7-c96f-5c0dbb8a16d9@chalmers.se> <52af1da7-5486-420b-b6af-b67693bdc213@chalmers.se> , <50174d78-cb5d-440b-bb6d-08e5a11919b8@chalmers.se> Message-ID: Dear G?nter, Those command lines executed for the compilation are really long, and have several mentions of trloii with various versions (ie both empty and with a number). Silly question, but did you run a make clean before rebuilding both nurdlib and r3bfuser? Have a good weekend, Hans "Weber, Guenter Dr." skrev: (12 januari 2024 20:21:54 CET) >Dear Hans, > > >I unset the paths as you suggested. Then I compiled NURDLIB again (this time it showed me different firmware numbers at the start). > > >And then something went wrong with R3DFSUSER compilation: > > >RIO4-MCAL-1 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 >make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args >udp.h: Could not configure module UDP, build_cc_ppc-linux_4.2.2_debug/nconf/udp.h.log: >=== UDP:ARPA_INET_H === >run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mUDP=1 -DDRASI -I. -Ibuild_cc_ppc-linux_4.2.2_debug -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/dtc_arch -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/hwmap -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo/gen_ppc-linux_4.2.2 -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames >run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.bin build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -DDRASI -I. -Ibuild_cc_ppc-linux_4.2.2_debug -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/dtc_arch -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/hwmap -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo/gen_ppc-linux_4.2.2 -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames -L../nurdlib/build_cc_ppc-linux_4.2.2_debug -L/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/hwmap/lib_ppc-linux_4.2.2 /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a -lhwmap /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -lnurdlib -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/lib_ppc-linux_4.2.2 -llwroc_mbscompat -llwroc_main -llwroc_readout -llwroc_nofilter -llwroc -llwroc_netutil -llwroc_parseutil -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -lpthread -lrt -lm -lcesXpcLib -lncurses -llwroc_hwmap_error >cc: /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a: No such file or directory >cc: /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a: No such file or directory >Failed. >=== UDP:NETINET_IN_H === >run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mUDP=1 -DDRASI -I. -Ibuild_cc_ppc-linux_4.2.2_debug -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/dtc_arch -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/hwmap -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo/gen_ppc-linux_4.2.2 -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames >run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.bin build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -DDRASI -I. -Ibuild_cc_ppc-linux_4.2.2_debug -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/dtc_arch -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/hwmap -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo/gen_ppc-linux_4.2.2 -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames -L../nurdlib/build_cc_ppc-linux_4.2.2_debug -L/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/hwmap/lib_ppc-linux_4.2.2 /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a -lhwmap /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -lnurdlib -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/lib_ppc-linux_4.2.2 -llwroc_mbscompat -llwroc_main -llwroc_readout -llwroc_nofilter -llwroc -llwroc_netutil -llwroc_parseutil -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -lpthread -lrt -lm -lcesXpcLib -lncurses -llwroc_hwmap_error >cc: /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a: No such file or directory >cc: /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a: No such file or directory >Failed. >=== UDP:BSD_IN_H === >run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mUDP=1 -DDRASI -I. -Ibuild_cc_ppc-linux_4.2.2_debug -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/dtc_arch -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/hwmap -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo/gen_ppc-linux_4.2.2 -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames >run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.bin build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -DDRASI -I. -Ibuild_cc_ppc-linux_4.2.2_debug -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/dtc_arch -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/hwmap -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo/gen_ppc-linux_4.2.2 -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames -L../nurdlib/build_cc_ppc-linux_4.2.2_debug -L/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/hwmap/lib_ppc-linux_4.2.2 /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a -lhwmap /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -lnurdlib -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/lib_ppc-linux_4.2.2 -llwroc_mbscompat -llwroc_main -llwroc_readout -llwroc_nofilter -llwroc -llwroc_netutil -llwroc_parseutil -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -lpthread -lrt -lm -lcesXpcLib -lncurses -llwroc_hwmap_error >cc: /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a: No such file or directory >cc: /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw__trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a: No such file or directory >Failed. >make[1]: *** [build_cc_ppc-linux_4.2.2_debug/nconf.args] Error 1 >make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >make: *** [drasi] Error 2 > > > >To me it looks like the firmware variable is empty now, right? > > > > >Best greetings and have a nice weekend > >G?nter > > > >________________________________ >Von: Hans Toshihide T?rnqvist >Gesendet: Freitag, 12. Januar 2024 16:16:54 >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, > >--- > >Let's start with the nurdlib build: > >The *_FW env vars are selected by nurdlib/Makefile by looking at the >available $TRLOII_PATH/trloctrl/fw_* directories. Except, if they were >already set! >This lets the user control exactly (some of) the decisions made by >nurdlib, otherwise the machines will take over. > >Probably there are some lines in ~/.tcshrc or a similar file which sets >them. Try commenting them out, log out of the Rio4, log back in, "make >clean" and already then you should see which firmwares are selected. >Then run "make". You could also set *_FW explicitly to the new firmware >if you prefer or the auto-selection doesn't work. > >I am working on the nurdlib documentation, actually even on the >enviroment variable section right now, so I'll add this in :) > >So, for nurdlib, please check the env vars: >- TRLOII_PATH >- TRIDI_FW >- VULOM4_FW > >--- > >r3bfuser build: > >I am guessing that this is related to mismatching firmware numbers, the >build pulls data from what nurdlib decided. If nurdlib builds with the >correct numbers as described above, I hope r3bfuser will "just work" >(crossing all my fingers). > >--- > >The *_CTRL variables are not used by nurdlib and r3bfuser, and are only >convenient on the cmd-line by for example: > >$TRIDI_CTRL --addr=n --print-config > >But they should point to the correct trloctrl builds for your new >firmware or they will complain when they talk to the hardware! > >--- > >Cheers, > >Hans > >On 2024-01-12 15:33, Weber, Guenter Dr. wrote: >> Dear friends, >> >> >> I did set up a second DAQ system and followed the instructions provided by >> >> >> Everything goes smoothly (I had to use the workaround in TRLOII) until >> compilation of R3DFUSER. This is the output (compilation done on the RIO): >> >> >> RIO4-MCAL-1 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 >> make[1]: Entering directory >> `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >> NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args >> udp.h: Could not configure module UDP, >> build_cc_ppc-linux_4.2.2_debug/nconf/udp.h.log: >> === UDP:ARPA_INET_H === >> run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o >> build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.c -I. -I >> build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mUDP=1 -DDRASI >> -I. -Ibuild_cc_ppc-linux_4.2.2_debug >> -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii >> -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames >> run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.bin >> build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o -I. -I >> build_cc_ppc-linux_4.2.2_debug/nconfing/ -DDRASI -I. >> -Ibuild_cc_ppc-linux_4.2.2_debug >> -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii >> -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames -L../nurdlib/build_cc_ppc-linux_4.2.2_debug /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -lnurdlib -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/lib_ppc-linux_4.2.2 -llwroc_mbscompat -llwroc_main -llwroc_readout -llwroc_nofilter -llwroc -llwroc_netutil -llwroc_parseutil -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -lpthread -lrt -lm -lcesXpcLib -lncurses -llwroc_hwmap_error >> cc: >> /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a: No such file or directory >> cc: >> /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a: No such file or directory >> Failed. >> === UDP:NETINET_IN_H === >> run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o >> build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.c -I. -I >> build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mUDP=1 -DDRASI >> -I. -Ibuild_cc_ppc-linux_4.2.2_debug >> -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii >> -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames >> run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.bin >> build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o -I. -I >> build_cc_ppc-linux_4.2.2_debug/nconfing/ -DDRASI -I. >> -Ibuild_cc_ppc-linux_4.2.2_debug >> -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii >> -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames -L../nurdlib/build_cc_ppc-linux_4.2.2_debug /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -lnurdlib -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/lib_ppc-linux_4.2.2 -llwroc_mbscompat -llwroc_main -llwroc_readout -llwroc_nofilter -llwroc -llwroc_netutil -llwroc_parseutil -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -lpthread -lrt -lm -lcesXpcLib -lncurses -llwroc_hwmap_error >> cc: >> /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a: No such file or directory >> cc: >> /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a: No such file or directory >> Failed. >> === UDP:BSD_IN_H === >> run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o >> build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.c -I. -I >> build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mUDP=1 -DDRASI >> -I. -Ibuild_cc_ppc-linux_4.2.2_debug >> -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii >> -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames >> run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.bin >> build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/udp.h.o -I. -I >> build_cc_ppc-linux_4.2.2_debug/nconfing/ -DDRASI -I. >> -Ibuild_cc_ppc-linux_4.2.2_debug >> -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii >> -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo -I/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/gen_gen_ppc-linux_4.2.2 -I../nurdlib -I../nurdlib/include -I../nurdlib/build_cc_ppc-linux_4.2.2_debug -I../nurdlib/build_cc_ppc-linux_4.2.2_debug/replacements -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../f_user_daq -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809 -pthread -I/usr/include/ces/cesXpcLib -I/usr/include/ces/cesOsApi -I/usr/include/ces/cesDma -I/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/include -ggdb -Wextra -fstrict-aliasing -Wstrict-aliasing -Wstrict-overflow -maltivec -mregnames -L../nurdlib/build_cc_ppc-linux_4.2.2_debug /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -lnurdlib -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/lib_ppc-linux_4.2.2 -llwroc_mbscompat -llwroc_main -llwroc_readout -llwroc_nofilter -llwroc -llwroc_netutil -llwroc_parseutil -L/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -lpthread -lrt -lm -lcesXpcLib -lncurses -llwroc_hwmap_error >> cc: >> /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/lib_ppc-linux_4.2.2/tridi_ctrllib.a: No such file or directory >> cc: >> /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a: No such file or directory >> Failed. >> make[1]: *** [build_cc_ppc-linux_4.2.2_debug/nconf.args] Error 1 >> make[1]: Leaving directory >> `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >> make: *** [drasi] Error 2 >> >> I had a look at the environment variables which I took over from the >> already existing system and I guess, I would need to modify some of >> these lines: >> >> >> VULOM4_CTRL=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/bin_ppc-linux_4.2.2/trlo_ctrl >> >> TRIDI_CTRL=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d374466d_tridi/bin_ppc-linux_4.2.2/tridi_ctrl >> >> >> This is the content of the folder on the new system: >> >> >> mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl$ ls -l >> insgesamt 52 >> drwxr-sr-x 2 mbsdaq users 4096 Jan 12 13:57 examples >> -rwxr-xr-x 1 mbsdaq users 7389 Jan 12 13:57 find_firmwares.pl >> -rw-r--r-- 1 mbsdaq users 114 Jan 12 15:02 firmwaredirs >> drwxr-sr-x 2 mbsdaq users 4096 Jan 12 15:00 fw_0866c243_rfx1 >> lrwxrwxrwx 1 mbsdaq users 16 Jan 12 15:00 fw_1409285e_trlo -> >> fw_6e4ba1a9_trlo >> drwxr-sr-x 2 mbsdaq users 4096 Jan 12 15:00 fw_5e8f5ef4_tridi >> drwxr-sr-x 2 mbsdaq users 4096 Jan 12 15:00 fw_68f8955e_trlo_all_in >> drwxr-sr-x 14 mbsdaq users 4096 Jan 12 15:02 fw_6e4ba1a9_trlo >> drwxr-sr-x 2 mbsdaq users 4096 Jan 12 15:00 fw_a1729cda_rfx0 >> lrwxrwxrwx 1 mbsdaq users 16 Jan 12 15:00 fw_a73c5093_trlo -> >> fw_6e4ba1a9_trlo >> drwxr-sr-x 2 mbsdaq users 4096 Jan 12 15:00 fw_af33ed35_trlo_big >> -rw-r--r-- 1 mbsdaq users 994 Jan 12 13:57 Makefile >> -rwxr-xr-x 1 mbsdaq users 662 Jan 12 13:57 trloctrl.sh >> drwxr-sr-x 5 mbsdaq users 4096 Jan 12 13:57 trlolib >> >> I also had a look at the output at the beginning of the NURDLIB >> compilation and if I understand correctly, it looks like the VULOM in >> the new system has the same firmware as the one in the old system: >> >> >> TRIDI_FW=d374466d >> VULOM4_FW=d96ffc88 >> >> What to do now? >> >> >> >> >> Thank you very much! >> >> >> >> >> Best greetings >> >> G?nter >> >> >> >> ------------------------------------------------------------------------ >> *Von:* Hans Toshihide T?rnqvist >> *Gesendet:* Freitag, 12. Januar 2024 14:34:24 >> *An:* Weber, Guenter Dr.; H?kan T Johansson >> *Betreff:* Re: AW: AW: AW: AW: [subexp-daq] NURDLIB: - how to check >> which version is installed and how to update to the most recent version >> It looks to be mirrored from git.chalmers.se, so should work. >> >> Cheers, >> Hans >> >> On 2024-01-12 14:22, Weber, Guenter Dr. wrote: >>> Is the UCESB version on GITLAB also a mirror? Then I could download >>> everything from GITLAB? >>> >>> >>> ------------------------------------------------------------------------ >>> *Von:* H?kan T Johansson >>> *Gesendet:* Freitag, 12. Januar 2024 14:19:23 >>> *An:* Weber, Guenter Dr. >>> *Cc:* Hans Toshihide T?rnqvist >>> *Betreff:* Re: AW: AW: AW: [subexp-daq] NURDLIB: - how to check which >>> version is installed and how to update to the most recent version >>> >>> Ahh, sorry about that, please try with >>> >>> https://git.chalmers.se/expsubphys/drasi.git >> >>> > > >>> https://git.chalmers.se/expsubphys/ucesb.git >> >>> > > >>> >>> and the drasi varsion on gitlab.com is a mirror so should work equally >>> well. >>> >>> Cheers, >>> H?kan >>> >>> >>> >>> On Fri, 12 Jan 2024, Weber, Guenter Dr. wrote: >>> >>>> >>>> Dear H?kan, >>>> >>>> >>>> I encountered the following issue(s): >>>> >>>> >>>> git clone git at git.chalmers.se:expsubphys/drasi.git >>>> git clone git at git.chalmers.se:expsubphys/ucesb.git >>>> >>>> 1) I don't have access to git.chalmers.se, only to gitlab.com. >>>> 2) There is a DRASI also on gitlab.com, that I was using so far. But is it >>>> the same as on git.chalmers.se? >>>> >>>> >>>> Best greetings >>>> G?nter >>>> >>>> >>>> >>>> ____________________________________________________________________________ >>>> Von: H?kan T Johansson >>>> Gesendet: Donnerstag, 11. Januar 2024 08:15 >>>> An: Weber, Guenter Dr. >>>> Cc: Hans Toshihide T?rnqvist >>>> Betreff: Re: AW: AW: [subexp-daq] NURDLIB: - how to check which version is >>>> installed and how to update to the most recent version >>>> >>>> Dear G?nter, >>>> >>>> thanks! >>>> >>>> 1) may be the reason for that strange error in typedefs.h, since it may be >>>> that it picks up the mystdint.h from the trloii compile but uses it in the >>>> drasi header somehow - or vice versa.... (They are the same and typically >>>> kept in sync, but we may here have hit a snag with the different versions >>>> and an update I did a while ago...) >>>> >>>> 2) Should be fine, is just an attempt at indenting the pre-processor >>>> directives, without having my editor unindent the code. >>>> >>>> >>>> It sounds like a very nice plan if you have the hardware to set up a >>>> second system from scratch. I have attached a short instruction on how to >>>> downloading and compiling the codes from scratch. >>>> >>>> It would not surprise me if there already exist something like that, but >>>> then we have two of them :-) If not, we can put this (with whatever fixes >>>> are needed) up somewhere (gitlab wiki or so). >>>> >>>> I did test it - but that does not guarantee much... >>>> >>>> Cheers, >>>> H?kan >>>> >>>> >>>> >>>> On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote: >>>> >>>> > >>>> > P.S. I looked a bit into the code that is compiled right before the error >>>> > appear. >>>> > >>>> > >>>> > I have no idea if this might causing problems, but in >>>> > >>>> > ../dtc_arch/acc_def/mystdint.h >>>> > I found two things: >>>> > >>>> > >>>> > 1) >>>> > >>>> > New version: >>>> > >>>> > #if ACC_DEF__MYSTDINT_stdint_h >>>> > # include >>>> > #endif >>>> > /* This is a local fall-back solution, so should be last. */ >>>> > #if ACC_DEF__MYSTDINT_mystdint >>>> > >>>> > Old version: >>>> > >>>> > #if ACC_DEF_MYSTDINT_stdint_h >>>> > # include >>>> > #endif >>>> > /* This is a local fall-back solution, so should be last. */ >>>> > #if ACC_DEF_MYSTDINT_mystdint >>>> > >>>> > (Note the double "_" before MYSTDINT.) >>>> > >>>> > >>>> > 2) >>>> > >>>> > In both versions there are strange blanks after "#" at two positions: >>>> > >>>> > # include "acc_auto_def/mystdint.h" >>>> > # define UINT64_C(v) v##ULL >>>> > >>>> > >>>> > >>>> > Best greetings >>>> > >>>> > G?nter >>>> > >>>> > >>>> >___________________________________________________________________________ >>>> _ >>>> > Von: Weber, Guenter Dr. >>>> > Gesendet: Mittwoch, 10. Januar 2024 19:32:59 >>>> > An: Hans Toshihide T?rnqvist >>>> > Betreff: AW: AW: [subexp-daq] NURDLIB: - how to check which version is >>>> > installed and how to update to the most recent version >>>> > >>>> > Dear Hans, >>>> > >>>> > >>>> > I could not reproduce the error from two hours ago. Nurdlib was laready >>>> set >>>> > to the right branch and in a second try compiled without problems on the >>>> > RIO. >>>> > >>>> > >>>> > However, we are now back at square one: >>>> > >>>> > >>>> > 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 >>>> > make[1]: Entering directory >>>> > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >>>> > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args >>>> > UDP:ARPA_INET_H >>>> > CC build_cc_ppc-linux_4.2.2_debug/f_user.o >>>> > CC build_cc_ppc-linux_4.2.2_debug/subevent.o >>>> > In file includedfrom/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscom >>>> pat/ >>>> > s_veshe.h:6, >>>> > from ./subevent.h:11, >>>> > from subevent.c:1: >>>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>>> >>>> > typedefs.h:6: error: expected '=', ',', ';', 'asm' or '__attribute__' >>>> > before 'INTS8' >>>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>>> >>>> > typedefs.h:7: error: expected '=', ',', ';', 'asm' or '__attribute__' >>>> > before 'INTU8' >>>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>>> >>>> > typedefs.h:8: error: expected '=', ',', ';', 'asm' or '__attribute__' >>>> > before 'INTS4' >>>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>>> >>>> > typedefs.h:9: error: expected '=', ',', ';', 'asm' or '__attribute__' >>>> > before 'INTU4' >>>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>>> >>>> > typedefs.h:10: error: expected '=', ',', ';', 'asm' or '__attribute__' >>>> > before 'INTS2' >>>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>>> >>>> > typedefs.h:11: error: expected '=', ',', ';', 'asm' or '__attribute__' >>>> > before 'INTU2' >>>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>>> >>>> > typedefs.h:12: error: expected '=', ',', ';', 'asm' or '__attribute__' >>>> > before 'INTS1' >>>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>>> >>>> > typedefs.h:13: error: expected '=', ',', ';', 'asm' or '__attribute__' >>>> > before 'INTU1' >>>> > In file included from ./subevent.h:11, >>>> > from subevent.c:1: >>>> >/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompat/ >>>> >>>> > s_veshe.h:11: error: expected specifier-qualifier-list before 'INTS4' >>>> > subevent.c: In function 'begin_goosy_vme_subevent': >>>> > subevent.c:12: error: 's_veshe' has no member named 'l_dlen' >>>> > subevent.c: In function 'end_goosy_vme_subevent': >>>> > subevent.c:45: error: 's_veshe' has no member named 'l_dlen' >>>> > make[1]: *** [build_cc_ppc-linux_4.2.2_debug/subevent.o] Error 1 >>>> > make[1]: Leaving directory >>>> > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >>>> > make: *** [drasi] Error 2 >>>> > RIO4-MCAL-2 mbsdaq > >>>> > >>>> > Thus, downloading and recompiling DRASI, NURDLIB, and R3BFUSER did not >>>> solve >>>> > the problem with the latter. >>>> > >>>> > >>>> > >>>> > ?? >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > Best greetings >>>> > >>>> > G?nter >>>> > >>>> > >>>> > >>>> > >>>> >___________________________________________________________________________ >>>> _ >>>> > Von: Hans Toshihide T?rnqvist >>>> > Gesendet: Mittwoch, 10. Januar 2024 18:24:21 >>>> > An: Weber, Guenter Dr. >>>> > Betreff: Re: AW: [subexp-daq] NURDLIB: - how to check which version is >>>> > installed and how to update to the most recent version >>>> > Sorry I got held up. >>>> > >>>> > I compiled 'mcal_daq_merge' from Gitlab on a rio4 just fine, so I am >>>> > just as puzzled where those event buffer test errors come from... >>>> > >>>> > Any luck with a 'make clean && make'? >>>> > >>>> > Cheers, >>>> > >>>> > Hans >>>> > >>>> > On 2024-01-10 17:36, Weber, Guenter Dr. wrote: >>>> > > Dear Hans, >>>> > > >>>> > > >>>> > > now things really get weird. >>>> > > >>>> > > >>>> > > I again downloaded NURDLIB, DRASI, and R3BFUSER. DRASI compiled without >>>> > > problems (first on PC, then on RIO). >>>> > > >>>> > > >>>> > > Now NURDLIB compilation stops with an error: >>>> > > >>>> > > >>>> > > LD build_cc_ppc-linux_4.2.2_debug/test_ntest >>>> > > LD build_cc_ppc-linux_4.2.2_debug/test >>>> > > /bin/sh: line 1: 22504 Aborted >>>> > > ./build_cc_ppc-linux_4.2.2_debug/test > >>>> > > build_cc_ppc-linux_4.2.2_debug/test.log 2>&1 >>>> > > [tests/argmatch.c:127: Shorts] >>>> > > [tests/argmatch.c:128: Longs] >>>> > > [tests/argmatch.c:129: Combos] >>>> > > [tests/argmatch.c:130: ShortsWithValues] >>>> > > [tests/argmatch.c:131: LongsWithValues] >>>> > > [tests/argmatch.c:132: MissingValue] >>>> > > [tests/base.c:110: MemoryCheck] >>>> > > [tests/base.c:111: EventBufferAdvance] >>>> > > 2024-02-10,19:58:33:ERRR: Invalid pointer to advance event buffer. >>>> > > [tests/base.c:47] >>>> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:47] >>>> > > 2024-02-10,19:58:33:ERRR: Invalid pointer to advance event buffer. >>>> > > [tests/base.c:56] >>>> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:56] >>>> > > 2024-02-10,19:58:33:ERRR: Tried to advance outside event buffer. >>>> > > [tests/base.c:72] >>>> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:72] >>>> > > [tests/base.c:112: EventBufferInvariant] >>>> > > 2024-02-10,19:58:33:ERRR: Event-buffer inconsistent (0x1080e008:11 != >>>> > > 0x1080e008:10). [tests/base.c:87] >>>> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:87] >>>> > > 2024-02-10,19:58:33:ERRR: Event-buffer inconsistent (0x1080e008:9 != >>>> > > 0x1080e008:10). [tests/base.c:91] >>>> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:91] >>>> > > 2024-02-10,19:58:33:ERRR: Event-buffer inconsistent (0x1080e009:10 != >>>> > > 0x1080e008:10). [tests/base.c:95] >>>> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:95] >>>> > > 2024-02-10,19:58:33:ERRR: Event-buffer inconsistent (0x1080e007:10 != >>>> > > 0x1080e008:10). [tests/base.c:99] >>>> > > 2024-02-10,19:58:33:ERRR: Calling abort()... [tests/base.c:99] >>>> > > [tests/bits.c:43: Gets] >>>> > > [tests/bits.c:44: CountLoops] >>>> > > [tests/caen_v1190.c:79: DefaultConfig] >>>> > > 2024-02-10,19:58:33:INFO: Will try default cfg >>>> > > path='/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg', >>>> > > can be set with NURDLIB_DEF_PATH. [config/config.c:181] >>>> > > 2024-02-10,19:58:33:INFO: Opened './tests/caen_v1190_empty.cfg' { >>>> > > [config/parser.c:287] >>>> > > 2024-02-10,19:58:33:ERRR: .Could not load default or user config >>>> > > 'caen_v1190.cfg'. [config/config.c:1483] >>>> > > 2024-02-10,19:58:33:ERRR: .Calling abort()... [config/config.c:1483] >>>> > > make: *** [build_cc_ppc-linux_4.2.2_debug/test_ok] Error 1 >>>> > > >>>> > > >>>> > > Did you change anything in the GITLAB version between yesterday and 15 >>>> > > minutes ago? >>>> > > >>>> > > >>>> > > >>>> > > Sorry, sorry, sorry ?? >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > Best greetings >>>> > > >>>> > > G?nter >>>> > > >>>> > > >>>> > > >>>> > > P.S. Tomorrow or on Friday, I will set up a second DAQ system with >>>> > > identical hardware. Then we can play around with no limits, including >>>> > > flashing the firmware of the VULOM, without messing around with the >>>> > > already running system as it is the case now. >>>> > > >>>> > > >>>> > > ------------------------------------------------------------------------ >>>> > > *Von:* Hans Toshihide T?rnqvist >>>> > > *Gesendet:* Mittwoch, 10. Januar 2024 16:59:07 >>>> > > *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, >>>> > > >>>> > > Did you try to update r3bfuser? I cannot see this problem with new >>>> > > versions of drasi+nurdlib+r3bfuser that are on Gitlab, and the trloii >>>> > > version shouldn't matter much in this case. >>>> > > >>>> > > Cheers, >>>> > > >>>> > > Hans >>>> > > >>>> > > On 2024-01-10 16:54, Weber, Guenter Dr. wrote: >>>> > >> Dear H?kan, >>>> > >> >>>> > >> >>>> > >> I followed your suggestion and the result is this: >>>> > >> >>>> > >> >>>> > >> 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 >>>> > >> make[1]: Entering directory >>>> > >> `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >>>> > >> CC build_cc_ppc-linux_4.2.2_debug/subevent.o >>>> > >> In file included from ./subevent.h:11, >>>> > >> from subevent.c:1: >>>> >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompa >>>> t/ >>>> > s_veshe.h:16: error: expected specifier-qualifier-list before 'CHARS' >>>> > >> make[1]: *** [build_cc_ppc-linux_4.2.2_debug/subevent.o] Error 1 >>>> > >> make[1]: Leaving directory >>>> > >> `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >>>> > >> make: *** [drasi] Error 2 >>>> > >> >>>> > >> >>>> > >> Best greetings >>>> > >> >>>> > >> G?nter >>>> > >> >>>> > >> >>>> > >> >>>> ------------------------------------------------------------------------ >>>> > >> *Von:* subexp-daq im Auftrag von >>>> > >> H?kan T Johansson >>>> > >> *Gesendet:* Mittwoch, 10. Januar 2024 16:07:52 >>>> > >> *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, >>>> > >> >>>> > >> those errors look strange to me. I am not able to reproduce on a >>>> similar >>>> > >> system. >>>> > >> >>>> > >> As a workaround (to see how far we get), in subevent.h in the r3bfuser/ >>>> > >> directory, could you uncomment these: >>>> > >> >>>> > >> #define MBS_TYPEDEFS_H >>>> > >> typedef char CHARX; >>>> > >> typedef int short INTS2; >>>> > >> typedef int INTS4; >>>> > >> >>>> > >> and comment out the "typedefs.h" in >>>> > >> >>>> >>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscompa >>>> t/ >>>> > s_veshe.h >>>> > >> >>>> > >> on line 6. And then try again. >>>> > >> >>>> > >> Cheers, >>>> > >> H?kan >>>> > >> >>>> > >> >>>> > >> On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote: >>>> > >> >>>> > >>> >>>> > >>> Dear Hans, >>>> > >>> >>>> > >>> >>>> > >>> I now did rebuild NURDLIB and DRASI. Then I tried to compile R3BFUSER >>>> > and this is the result: >>>> > >>> >>>> > >>> >>>> > >>> RIO4-MCAL-2 mbsdaq > cd r3bfuser/ >>>> > >>> 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 >>>> > >>> make[1]: Entering directory >>>> > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >>>> > >>> NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args >>>> > >>> UDP:ARPA_INET_H >>>> > >>> CC build_cc_ppc-linux_4.2.2_debug/f_user.o >>>> > >>> CC build_cc_ppc-linux_4.2.2_debug/subevent.o >>>> > >>> In file includedfrom/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscom >>>> pat/ >>>> > s_veshe.h:6, >>>> > >>> from ./subevent.h:11, >>>> > >>> from subevent.c:1: >>>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>>> at/ >>>> > typedefs.h:6: error: expected '=', ',', ';', 'asm' or '__attribute__' >>>> > before 'INTS8' >>>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>>> at/ >>>> > typedefs.h:7: error: expected '=', ',', ';', 'asm' or '__attribute__' >>>> > before 'INTU8' >>>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>>> at/ >>>> > typedefs.h:8: error: expected '=', ',', ';', 'asm' or '__attribute__' >>>> > before 'INTS4' >>>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>>> at/ >>>> > typedefs.h:9: error: expected '=', ',', ';', 'asm' or '__attribute__' >>>> > before 'INTU4' >>>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>>> at/ >>>> > typedefs.h:10: error: expected '=', ',', ';', 'asm' or '__attribute__' >>>> > before 'INTS2' >>>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>>> at/ >>>> > typedefs.h:11: error: expected '=', ',', ';', 'asm' or '__attribute__' >>>> > before 'INTU2' >>>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>>> at/ >>>> > typedefs.h:12: error: expected '=', ',', ';', 'asm' or '__attribute__' >>>> > before 'INTS1' >>>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>>> at/ >>>> > typedefs.h:13: error: expected '=', ',', ';', 'asm' or '__attribute__' >>>> > before 'INTU1' >>>> > >>> In file included from ./subevent.h:11, >>>> > >>> from subevent.c:1: >>>> >>>>/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/bin/../lwroc/../mbscomp >>>> at/ >>>> > s_veshe.h:11: error: expected specifier-qualifier-list before 'INTS4' >>>> > >>> subevent.c: In function 'begin_goosy_vme_subevent': >>>> > >>> subevent.c:12: error: 's_veshe' has no member named 'l_dlen' >>>> > >>> subevent.c: In function 'end_goosy_vme_subevent': >>>> > >>> subevent.c:45: error: 's_veshe' has no member named 'l_dlen' >>>> > >>> make[1]: *** [build_cc_ppc-linux_4.2.2_debug/subevent.o] Error 1 >>>> > >>> make[1]: Leaving directory >>>> > `/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser' >>>> > >>> make: *** [drasi] Error 2 >>>> > >>> >>>> > >>> Reminder: I am using the most recent versions of NURDLIB and DRASI, >>>> but >>>> > because of the incompatibility of the VULOM firmware I use the old version >>>> > of TRLOII. In addition, >>>> > >>> because of the leap seconds issue I compiled DRASI first on the PC and >>>> > then recompiled it on the RIO (without "make clean"). >>>> > >>> >>>> > >>> >>>> > >>> >>>> > >>> >>>> > >>> >>>> > >>> >>>> > >>> >>>> > >>> Best greetings >>>> > >>> G?nter >>>> > >>> >>>> > >>> >>>> >>>>________________________________________________________________________ >>>> ___ >>>> > __________________________________________________________________________ >>>> > _____________________ >>>> > >>> Von: Hans Toshihide T?rnqvist >>>> > >>> Gesendet: Mittwoch, 10. Januar 2024 13:18:41 >>>> > >>> 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, >>>> > >>> >>>> > >>> I would suggest rebuilding nurdlib now that trlo2 has been rebuilt, >>>> and >>>> > >>> then also rebuild r3bfuser. >>>> > >>> >>>> > >>> After that probably you can try to run the DAQ :) >>>> > >>> >>>> > >>> Cheers, >>>> > >>> Hans >>>> > >>> >>>> > >>> On 2024-01-10 13:15, Weber, Guenter Dr. wrote: >>>> > >>> > Dear H?kan, >>>> > >>> > >>>> > >>> > >>>> > >>> > using the old TRLOII folder and then recompiling was successfull. >>>> > >>> > >>>> > >>> > >>>> > >>> > Should I now give it a try to start the DAQ? Or is there something >>>> > else >>>> > >>> > I still need to adjust? >>>> > >>> > >>>> > >>> > >>>> > >>> > >>>> > >>> > >>>> > >>> > Best greetings >>>> > >>> > >>>> > >>> > G?nter >>>> > >>> > >>>> > >>> > >>>> > >>> > >>>> > >>> > >>>> > >>> > >>>> > ------------------------------------------------------------------------ >>>> > >>> > *Von:* subexp-daq im Auftrag >>>> > von >>>> > >>> > H?kan T Johansson >>>> > >>> > *Gesendet:* Mittwoch, 10. Januar 2024 12:34:26 >>>> > >>> > *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 >>>> > >>> > >>>> > >>> > Hi G?nter, >>>> > >>> > >>>> > >>> > On Wed, 10 Jan 2024, Weber, Guenter Dr. wrote: >>>> > >>> > >>>> > >>> >> >>>> > >>> >> Hi folks, >>>> > >>> >> >>>> > >>> >> >>>> > >>> >> the old "./find_firmware.pl" was working. This is the output: >>>> > >>> >> >>>> > >>> >> >>>> > >>> >> a1729cda ../ver/rimfaxe0_trlo/rfx0_defs.h >>>> > >>> >> 0866c243 ../ver/rimfaxe1_trlo/rfx1_defs.h >>>> > >>> >> 5e8f5ef4 ../ver/tridi1_trlo/tridi_defs.h >>>> > >>> >> 6e4ba1a9 ../ver/vulom4_trlo/trlo_defs.h >>>> > >>> >> 68f8955e ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h >>>> > >>> >> af33ed35 ../ver/vulom4_trlo_big/trlo_big_defs.h >>>> > >>> >> 1409285e ../ver/vulom4b_trlo/trlo_defs.h >>>> > >>> >> d374466d ../fw/tridi1_trlo/tridi_defs.h >>>> > >>> >> d96ffc88 ../fw/vulom4_trlo/trlo_defs.h >>>> > >>> >> 5b298165 ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h >>>> > >>> >> 6f28c0f8 ../fw/vulom4_trlo_big/trlo_big_defs.h >>>> > >>> >> fa5020ea ../fw/vulom4_trlo_led/trlo_defs.h >>>> > >>> >> 426cb99c ../fw/vulom4b_trlo/trlo_defs.h >>>> > >>> >> MKDIR fw_a1729cda_rfx0 # ../ver/rimfaxe0_trlo/rfx0_defs.h >>>> > >>> >> SYMLINK fw_a1729cda_rfx0/rfx0_defs.h -> >>>> > ../../ver/rimfaxe0_trlo/rfx0_defs.h >>>> > >>> >> MKDIR fw_0866c243_rfx1 # ../ver/rimfaxe1_trlo/rfx1_defs.h >>>> > >>> >> SYMLINK fw_0866c243_rfx1/rfx1_defs.h -> >>>> > ../../ver/rimfaxe1_trlo/rfx1_defs.h >>>> > >>> >> MKDIR fw_5e8f5ef4_tridi # ../ver/tridi1_trlo/tridi_defs.h >>>> > >>> >> SYMLINK fw_5e8f5ef4_tridi/tridi_defs.h -> >>>> > ../../ver/tridi1_trlo/tridi_defs.h >>>> > >>> >> MKDIR fw_6e4ba1a9_trlo # ../ver/vulom4_trlo/trlo_defs.h >>>> > >>> >> SYMLINK fw_6e4ba1a9_trlo/trlo_defs.h -> >>>> > ../../ver/vulom4_trlo/trlo_defs.h >>>> > >>> >> SYMLINK fw_1409285e_trlo -> fw_6e4ba1a9_trlo >>>> > >>> >> MKDIR fw_68f8955e_trlo_all_in # >>>> > ../ver/vulom4_trlo_all_in/trlo_all_in_defs.h >>>> > >>> >> SYMLINK fw_68f8955e_trlo_all_in/trlo_all_in_defs.h -> >>>> > ../../ver/vulom4_trlo_all_in/trlo_all_in_defs.h >>>> > >>> >> MKDIR fw_af33ed35_trlo_big # >>>> > ../ver/vulom4_trlo_big/trlo_big_defs.h >>>> > >>> >> SYMLINK fw_af33ed35_trlo_big/trlo_big_defs.h -> >>>> > ../../ver/vulom4_trlo_big/trlo_big_defs.h >>>> > >>> >> MKDIR fw_d374466d_tridi # ../fw/tridi1_trlo/tridi_defs.h >>>> > >>> >> SYMLINK fw_d374466d_tridi/tridi_defs.h -> >>>> > ../../fw/tridi1_trlo/tridi_defs.h >>>> > >>> >> MKDIR fw_d96ffc88_trlo # ../fw/vulom4_trlo/trlo_defs.h >>>> > >>> >> SYMLINK fw_d96ffc88_trlo/trlo_defs.h -> >>>> > ../../fw/vulom4_trlo/trlo_defs.h >>>> > >>> >> SYMLINK fw_426cb99c_trlo -> fw_d96ffc88_trlo >>>> > >>> >> SYMLINK fw_fa5020ea_trlo -> fw_d96ffc88_trlo >>>> > >>> >> MKDIR fw_5b298165_trlo_all_in # >>>> > ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h >>>> > >>> >> SYMLINK fw_5b298165_trlo_all_in/trlo_all_in_defs.h -> >>>> > ../../fw/vulom4_trlo_all_in/trlo_all_in_defs.h >>>> > >>> >> MKDIR fw_6f28c0f8_trlo_big # >>>> ../fw/vulom4_trlo_big/trlo_big_defs.h >>>> > >>> >> SYMLINK fw_6f28c0f8_trlo_big/trlo_big_defs.h -> >>>> > ../../fw/vulom4_trlo_big/trlo_big_defs.h >>>> > >>> >> >>>> > >>> >> However, the compilation did end with an error: >>>> > >>> >> >>>> > >>> >> >>>> > >>> >> make[1]: Enteringdirectory`/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl >>>> /fw_d96ff >>>> > c88_trlo' >>>> > >>> >> CC bld_ppc-linux_4.2.2/src/trlo_check_version.o >>>> > >>> >> CC bld_ppc-linux_4.2.2/src/trlo_functions.o >>>> > >>> >> ../trlolib/src/trlo_functions.c: In function 'trlo_clear_config': >>>> > >>> >> ../trlolib/src/trlo_functions.c:144: error: 'trlo_setup_map' has no >>>> > member named 'sync_check_start_mux' >>>> > >>> >> ../trlolib/src/trlo_functions.c:146: error: 'trlo_setup_map' has no >>>> > member named 'sync_check_stop_mux' >>>> > >>> >> ../trlolib/src/trlo_functions.c: In function 'trlo_print_config': >>>> > >>> >> ../trlolib/src/trlo_functions.c:825: error: 'trlo_setup_map' has no >>>> > member named 'sync_check_start_mux' >>>> > >>> >> ../trlolib/src/trlo_functions.c:829: error: 'trlo_setup_map' has no >>>> > member named 'sync_check_stop_mux' >>>> > >>> >> ../trlolib/src/trlo_functions.c: In function >>>> > 'trlo_print_trig_status': >>>> > >>> >> ../trlolib/src/trlo_functions.c:1155: error: 'trlo_output_map' has >>>> no >>>> > member named 'trig_sync_check' >>>> > >>> >> make[1]: *** [bld_ppc-linux_4.2.2/src/trlo_functions.o] Error 1 >>>> > >>> >> make[1]: Leavingdirectory`/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl >>>> /fw_d96ff >>>> > c88_trlo' >>>> > >>> >> >>>> > >>> >> make[1]: Enteringdirectory`/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl >>>> /fw_d3744 >>>> > 66d_tridi' >>>> > >>> >> CC bld_ppc-linux_4.2.2/src/tridi_check_version.o >>>> > >>> >> CC bld_ppc-linux_4.2.2/src/tridi_functions.o >>>> > >>> >> ../trlolib/src/trlo_functions.c: In function 'tridi_clear_config': >>>> > >>> >> ../trlolib/src/trlo_functions.c:144: error: 'tridi_setup_map' has >>>> no >>>> > member named 'sync_check_start_mux' >>>> > >>> >> ../trlolib/src/trlo_functions.c:146: error: 'tridi_setup_map' has >>>> no >>>> > member named 'sync_check_stop_mux' >>>> > >>> >> ../trlolib/src/trlo_functions.c: In function 'tridi_print_config': >>>> > >>> >> ../trlolib/src/trlo_functions.c:825: error: 'tridi_setup_map' has >>>> no >>>> > member named 'sync_check_start_mux' >>>> > >>> >> ../trlolib/src/trlo_functions.c:829: error: 'tridi_setup_map' has >>>> no >>>> > member named 'sync_check_stop_mux' >>>> > >>> >> ../trlolib/src/trlo_functions.c: In function >>>> > 'tridi_print_trig_status': >>>> > >>> >> ../trlolib/src/trlo_functions.c:1155: error: 'tridi_output_map' has >>>> > no member named 'trig_sync_check' >>>> > >>> >> make[1]: *** [bld_ppc-linux_4.2.2/src/tridi_functions.o] Error 1 >>>> > >>> >> make[1]: Leavingdirectory`/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl >>>> /fw_d3744 >>>> > 66d_tridi' >>>> > >>> >> make: *** [fw_d374466d_tridi_build] Error 2 >>>> > >>> > >>>> > >>> > That's what I feared. The new code want something (sync_check_...) >>>> > not in >>>> > >>> > the older firmware... >>>> > >>> > >>>> > >>> >> The fallback option is now to delete the new TRLOII folder and >>>> > replace it with old one and then repeat the following steps? >>>> > >>> >> >>>> > >>> >> >>>> > >>> >> cd trloii >>>> > >>> >> make clean >>>> > >>> >> make >>>> > >>> >> cd trloctrl >>>> > >>> >> make fw_d96ffc88_trlo_build >>>> > >>> >> make fw_d374466d_tridi_build >>>> > >>> >> >>>> > >>> >> >>>> > >>> >> Is this correct? >>>> > >>> > >>>> > >>> > Yes. >>>> > >>> > >>>> > >>> > There should then already be the trloii/fw/ directory, and the links >>>> > that >>>> > >>> > are created by find_firmware.pl >>>> > >>> > >>>> > >>> > >>>> > >>> >> I also looked for the "--addr=" and this is the result: >>>> > >>> > >>>> > >>> >> ... >>>> > >>> > >>>> > >>> > Ok. I was too optimistic here. I looked through the grep results, >>>> > but >>>> > >>> > nothing obvious. Should be figurable by checking the old scripts >>>> and >>>> > >>> > following them around. Is a good way to see how things are done >>>> > anyhow ;) >>>> > >>> > >>>> > >>> > Cheers, >>>> > >>> > H?kan >>>> > >>> > >>>> > >>> > >>>> > >>> >> >>>> > >>> >> >>>> > >>> >> >>>> > >>> >> Best greetings >>>> > >>> >> >>>> > >>> >> G?nter >>>> > >>> > >>>> > >>> >>>> > >>> >>>> > >> >>>> > >>>> > >>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.weber at hi-jena.gsi.de Tue Jan 16 10:50:46 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 16 Jan 2024 09:50:46 +0000 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <77f957cf-d6cc-d9d7-c96f-5c0dbb8a16d9@chalmers.se> <52af1da7-5486-420b-b6af-b67693bdc213@chalmers.se> <50174d78-cb5d-440b-bb6d-08e5a11919b8@chalmers.se> <831905AE-5B53-45DA-81DD-756DED9EE76E@chalmers.se> <438345a1684c413e8678a1a2ac928bc2@hi-jena.gsi.de> <222475cb-2ab6-4f4c-9bc0-d08a8b20a3cc@chalmers.se> <4e1e90ee-e985-42b2-a4e8-83f02d1c56b8@chalmers.se> <5b0a058d-b58c-4e73-a59b-24a40d59a3f1@chalmers.se> <68c6e7a91d354a35a08a6a89d181b9b6@hi-jena.gsi.de> , <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> Message-ID: <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de> Dear Hans, dear H?kan, would it be possible to modify the Makefiles in such a way that basics checks (e.g. NURDLIB_DEF_PATH and TRLOII_PATH are set to a path that exsists) are done right in the beginning? Also maybe the outcomes logged in files like trloii.h.log could be more clearly communicated on the command line. This would have helped a great deal. I now also compiled UCESB (on PC). What now? There is the folder UPEXPS, in which (to my limited understanding) it is defined what the DAQ actually does with the various modules. Unfortunately, I have no idea how exactly this works. Do I have to recompile here after TRLOII, DRASI, NURDLIB, etc. were replaced by new versions? Thank you very much! Best greetings G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Tue Jan 16 11:36:03 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Tue, 16 Jan 2024 11:36:03 +0100 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <52af1da7-5486-420b-b6af-b67693bdc213@chalmers.se> <50174d78-cb5d-440b-bb6d-08e5a11919b8@chalmers.se> <831905AE-5B53-45DA-81DD-756DED9EE76E@chalmers.se> <438345a1684c413e8678a1a2ac928bc2@hi-jena.gsi.de> <222475cb-2ab6-4f4c-9bc0-d08a8b20a3cc@chalmers.se> <4e1e90ee-e985-42b2-a4e8-83f02d1c56b8@chalmers.se> <5b0a058d-b58c-4e73-a59b-24a40d59a3f1@chalmers.se> <68c6e7a91d354a35a08a6a89d181b9b6@hi-jena.gsi.de> , <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de> Message-ID: <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> Dear G?nter, On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: > > Dear Hans, dear H?kan, > > > would it be possible to modify the Makefiles in such a way that basics > checks (e.g. NURDLIB_DEF_PATH and TRLOII_PATH are set to a path that > exsists) are done right in the beginning? Also maybe the outcomes logged in > files like trloii.h.log could be more clearly communicated on the command > line. This would have helped a great deal. Agree. Something(s) needs to be done. Fail early is a good strategy! One could have some 'make checkconfig' target which could try to check especially externally set variables that can affect the compile flow in a tool. And have it run early always, especially if it is quiet by default. And some VERBOSE=1 flag that would print useful info (as well as make that 'make checkconfig' tell more what it is doing. Since there already is the QUIET= option that starts to print everything which is done, verbose might not be the rigth name. Not thinking of printing everything here, which is just unreadable, but some actually useful debug info. PRETTY_VERBOSE=1 ? :-) (drasi and trloii has 'make showconfig' which tells what internal configurations it has come up with internally, but that is not what we are after here.) > I now also compiled UCESB (on PC). > > > What now? Try to run the DAQ. ;) > There is the folder UPEXPS, in which (to my limited understanding) it is > defined what the DAQ actually does with the various modules. Unfortunately, > I have no idea how exactly this works. Do I have to recompile here after > TRLOII, DRASI, NURDLIB, etc. were replaced by new versions? The upexps presumably if 'just' unpacking, i.e. not involved in the DAQ as such, only in the data unpacking. That should only depend on ucesb, not on the other DAQ tools, and the DAQ should not depend on it. Except if your normal file writing goes via ucesb, which I hope not... upexps is a repository which ... needs help (it is not being properly maintained). Could you tell which commit you are using in that? > Thank you very much! Thank you for all the feedback! Cheers, H?kan From g.weber at hi-jena.gsi.de Tue Jan 16 12:13:52 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 16 Jan 2024 11:13:52 +0000 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <52af1da7-5486-420b-b6af-b67693bdc213@chalmers.se> <50174d78-cb5d-440b-bb6d-08e5a11919b8@chalmers.se> <831905AE-5B53-45DA-81DD-756DED9EE76E@chalmers.se> <438345a1684c413e8678a1a2ac928bc2@hi-jena.gsi.de> <222475cb-2ab6-4f4c-9bc0-d08a8b20a3cc@chalmers.se> <4e1e90ee-e985-42b2-a4e8-83f02d1c56b8@chalmers.se> <5b0a058d-b58c-4e73-a59b-24a40d59a3f1@chalmers.se> <68c6e7a91d354a35a08a6a89d181b9b6@hi-jena.gsi.de> , <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de>, <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> Message-ID: Dear Hakan, thank you or your reply. Now I am bit lost because I thought that UPEXPS is a central piece where important things happen. Anyway, here is what GIT tells me about UPEXPS: mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/upexps$ git log commit 47db26b7743bf2676ebc2aa0a69e8cfae0e74ef4 (HEAD -> master) Author: Bastian Loeher Date: Mon Mar 15 17:26:29 2021 +0100 Therein is the folder MCAL_2019: mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/upexps/mcal_2019$ ls -l insgesamt 23052 -rw-r--r-- 1 mbsdaq users 137 Jan 12 13:41 control.hh drwxr-sr-x 4 mbsdaq users 4096 Jan 12 13:37 gen_mcal -rw-r--r-- 1 mbsdaq users 233 Jan 12 13:37 Makefile -rw-r--r-- 1 mbsdaq users 102 Jan 12 13:41 makefile_additional.inc -rw-r--r-- 1 mbsdaq users 1574 Jan 12 13:37 mapping.h -rwxr-xr-x 1 mbsdaq users 12503880 Jan 12 13:41 mcal -rw-r--r-- 1 mbsdaq users 24005 Jan 12 13:41 mcal.dep -rw-r--r-- 1 mbsdaq users 1571 Jan 12 13:41 mcal.spec -rw-r--r-- 1 mbsdaq users 2777 Jan 12 13:41 mcal_user.cc -rwxr-xr-x 1 mbsdaq users 11020872 Jan 12 13:41 mcal.working drwxr-sr-x 2 mbsdaq users 4096 Jan 12 13:41 mc_gen_mcal drwxr-sr-x 2 mbsdaq users 4096 Jan 12 13:41 obj_mcal -rw-r--r-- 1 mbsdaq users 6545 Jan 12 13:41 sis3316_mapping_macros.h -rw-r--r-- 1 mbsdaq users 5082 Jan 12 13:41 vme_struck_sis3316.spec And my impression was that these files are somehow central to reading out our DAQ system. My understanding is that for initializing and readout of the modules by the DAQ software, the following configuration files are used (they are in a different directory): -rw-r--r-- 1 mbsdaq users 4883 Jan 12 13:44 main.cfg -rw-r--r-- 1 mbsdaq users 194 Jan 12 13:42 r3bfuser.cfg -rw-r--r-- 1 mbsdaq users 3065 Jan 12 13:42 vulom.trlo But for telling UCESB what to find in the the LMD stream coming from the RIO (which is a result of these configuration files), somehow a 'mapping' is necessary. And this I associated with UPEXPS. But maybe my understanding was wrong, if UPEXPS is not used by you guys. After lunch, I will give it a try to simply start the DAQ. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Dienstag, 16. Januar 2024 11:36:03 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated Dear G?nter, On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: > > Dear Hans, dear H?kan, > > > would it be possible to modify the Makefiles in such a way that basics > checks (e.g. NURDLIB_DEF_PATH and TRLOII_PATH are set to a path that > exsists) are done right in the beginning? Also maybe the outcomes logged in > files like trloii.h.log could be more clearly communicated on the command > line. This would have helped a great deal. Agree. Something(s) needs to be done. Fail early is a good strategy! One could have some 'make checkconfig' target which could try to check especially externally set variables that can affect the compile flow in a tool. And have it run early always, especially if it is quiet by default. And some VERBOSE=1 flag that would print useful info (as well as make that 'make checkconfig' tell more what it is doing. Since there already is the QUIET= option that starts to print everything which is done, verbose might not be the rigth name. Not thinking of printing everything here, which is just unreadable, but some actually useful debug info. PRETTY_VERBOSE=1 ? :-) (drasi and trloii has 'make showconfig' which tells what internal configurations it has come up with internally, but that is not what we are after here.) > I now also compiled UCESB (on PC). > > > What now? Try to run the DAQ. ;) > There is the folder UPEXPS, in which (to my limited understanding) it is > defined what the DAQ actually does with the various modules. Unfortunately, > I have no idea how exactly this works. Do I have to recompile here after > TRLOII, DRASI, NURDLIB, etc. were replaced by new versions? The upexps presumably if 'just' unpacking, i.e. not involved in the DAQ as such, only in the data unpacking. That should only depend on ucesb, not on the other DAQ tools, and the DAQ should not depend on it. Except if your normal file writing goes via ucesb, which I hope not... upexps is a repository which ... needs help (it is not being properly maintained). Could you tell which commit you are using in that? > Thank you very much! Thank you for all the feedback! Cheers, H?kan -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Tue Jan 16 12:25:42 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Tue, 16 Jan 2024 12:25:42 +0100 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <50174d78-cb5d-440b-bb6d-08e5a11919b8@chalmers.se> <831905AE-5B53-45DA-81DD-756DED9EE76E@chalmers.se> <438345a1684c413e8678a1a2ac928bc2@hi-jena.gsi.de> <222475cb-2ab6-4f4c-9bc0-d08a8b20a3cc@chalmers.se> <4e1e90ee-e985-42b2-a4e8-83f02d1c56b8@chalmers.se> <5b0a058d-b58c-4e73-a59b-24a40d59a3f1@chalmers.se> <68c6e7a91d354a35a08a6a89d181b9b6@hi-jena.gsi.de> , <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de>, <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> Message-ID: On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: > > Dear Hakan, > > > thank you or your reply. Now I am bit lost because I thought that UPEXPS is > a central piece where important things happen.? > > > Anyway, here is what GIT tells me about UPEXPS: > > mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/upexps$ git log > commit 47db26b7743bf2676ebc2aa0a69e8cfae0e74ef4 (HEAD -> master) > Author: Bastian Loeher > Date:?? Mon Mar 15 17:26:29 2021 +0100 > > Therein is the folder MCAL_2019: > > mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/upexps/mcal_2019$ ls -l > insgesamt 23052 > -rw-r--r-- 1 mbsdaq users????? 137 Jan 12 13:41 control.hh > drwxr-sr-x 4 mbsdaq users???? 4096 Jan 12 13:37 gen_mcal > -rw-r--r-- 1 mbsdaq users????? 233 Jan 12 13:37 Makefile > -rw-r--r-- 1 mbsdaq users????? 102 Jan 12 13:41 makefile_additional.inc > -rw-r--r-- 1 mbsdaq users???? 1574 Jan 12 13:37 mapping.h > -rwxr-xr-x 1 mbsdaq users 12503880 Jan 12 13:41 mcal > -rw-r--r-- 1 mbsdaq users??? 24005 Jan 12 13:41 mcal.dep > -rw-r--r-- 1 mbsdaq users???? 1571 Jan 12 13:41 mcal.spec > -rw-r--r-- 1 mbsdaq users???? 2777 Jan 12 13:41 mcal_user.cc > -rwxr-xr-x 1 mbsdaq users 11020872 Jan 12 13:41 mcal.working > drwxr-sr-x 2 mbsdaq users???? 4096 Jan 12 13:41 mc_gen_mcal > drwxr-sr-x 2 mbsdaq users???? 4096 Jan 12 13:41 obj_mcal > -rw-r--r-- 1 mbsdaq users???? 6545 Jan 12 13:41 sis3316_mapping_macros.h > -rw-r--r-- 1 mbsdaq users???? 5082 Jan 12 13:41 vme_struck_sis3316.spec > > And my impression was that these files are somehow central to reading out > our DAQ system. True, for reading the data after the DAQ as such. > My understanding is that for initializing and readout of the modules by the > DAQ software, the following configuration files are used (they are in a > different directory): > > -rw-r--r-- 1 mbsdaq users??????? 4883 Jan 12 13:44 main.cfg > > -rw-r--r-- 1 mbsdaq users???????? 194 Jan 12 13:42 r3bfuser.cfg > > -rw-r--r-- 1 mbsdaq users??????? 3065 Jan 12 13:42 vulom.trlo Yes. Well outside upexps I hope. ;) > But for telling UCESB what to find in the the LMD stream coming from the RIO > (which is a result of these configuration files), somehow a 'mapping' is > necessary. And this I associated with UPEXPS. But maybe my understanding was > wrong, if UPEXPS is not used by you guys. You are correct. Only distinction would that that ucesb / upexps are only involved to either read .lmd files, or to read live data streams (which is also on lmd format) from the DAQ. -- With the git references above, we can hopefully try to figure out how deep into the other parts of upexps your directory has dependencies. But - as long as the data format has not changed - and the intention with the update to nurdlib etc was to not change any of those - the current unpacker specification and mapping should still work. In fact - if it does not - then we do not want to fix the unpacking stages, but understand why the DAQ delivers different data. > After lunch, I will give it a try to simply start the DAQ. Cheers, H?kan From g.weber at hi-jena.gsi.de Tue Jan 16 16:44:39 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 16 Jan 2024 15:44:39 +0000 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <50174d78-cb5d-440b-bb6d-08e5a11919b8@chalmers.se> <831905AE-5B53-45DA-81DD-756DED9EE76E@chalmers.se> <438345a1684c413e8678a1a2ac928bc2@hi-jena.gsi.de> <222475cb-2ab6-4f4c-9bc0-d08a8b20a3cc@chalmers.se> <4e1e90ee-e985-42b2-a4e8-83f02d1c56b8@chalmers.se> <5b0a058d-b58c-4e73-a59b-24a40d59a3f1@chalmers.se> <68c6e7a91d354a35a08a6a89d181b9b6@hi-jena.gsi.de> , <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de>, <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> , Message-ID: <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> Dear friends, I am just trying to figure out how all the various scripts/commands work together for setting up our DAQ system. Maybe, you can help to clearify some things. - master.bash source ../env/env.sh ./trloii_setup.sh # gdb --args \ ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ --label=MCAL1 \ --triva=master,fctime=10,ctime=50 \ --log-no-rate-limit \ --server=drasi,dest=lyserv \ --buf=size=400Mi \ --max-ev-size=0x1000000 \ --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ --eb=lyserv \ "$@" In the first line some environment variables are set. The second line tells the VULOM4 how to operate (i. e. selection from modes of operation defined in vulom.trlo). Then DRASI is started with a bunch of parameters. Is there somewhere an explanation of the purpose of all these settings? And what is in the last line? I never came accross "$@" before. - eb.bash ../drasi/bin/lwrocmerge \ --label=MCAL_EB \ --merge-mode=event \ --server=trans,flush=1 \ --server=stream,flush=1 \ --buf=size=1600Mi \ --max-ev-size=20Mi \ --eb-master=rio4-mcal-1 \ --file-writer \ --drasi=rio4-mcal-1 What is the purpose of this command? Why are values for buffer size and max event size different then in the command before? - fanout.bash #!/bin/bash while : do ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ stream://localhost \ --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 sleep 5 done This looks like setting up a connection point to the outside world, right? And we find the third (random?) value for a buffer size. - rate.bash ../drasi/bin/lwrocmon --rate rio4-mcal-1 Ok, this I understand. We can look the DAQ over the shoulder and see what the thing is doing in terms of number of trigger events, transported data, etc. - log.bash ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost This is also easy to understand. Thank you very much! Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Dienstag, 16. Januar 2024 12:25:42 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: > > Dear Hakan, > > > thank you or your reply. Now I am bit lost because I thought that UPEXPS is > a central piece where important things happen. > > > Anyway, here is what GIT tells me about UPEXPS: > > mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/upexps$ git log > commit 47db26b7743bf2676ebc2aa0a69e8cfae0e74ef4 (HEAD -> master) > Author: Bastian Loeher > Date: Mon Mar 15 17:26:29 2021 +0100 > > Therein is the folder MCAL_2019: > > mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/upexps/mcal_2019$ ls -l > insgesamt 23052 > -rw-r--r-- 1 mbsdaq users 137 Jan 12 13:41 control.hh > drwxr-sr-x 4 mbsdaq users 4096 Jan 12 13:37 gen_mcal > -rw-r--r-- 1 mbsdaq users 233 Jan 12 13:37 Makefile > -rw-r--r-- 1 mbsdaq users 102 Jan 12 13:41 makefile_additional.inc > -rw-r--r-- 1 mbsdaq users 1574 Jan 12 13:37 mapping.h > -rwxr-xr-x 1 mbsdaq users 12503880 Jan 12 13:41 mcal > -rw-r--r-- 1 mbsdaq users 24005 Jan 12 13:41 mcal.dep > -rw-r--r-- 1 mbsdaq users 1571 Jan 12 13:41 mcal.spec > -rw-r--r-- 1 mbsdaq users 2777 Jan 12 13:41 mcal_user.cc > -rwxr-xr-x 1 mbsdaq users 11020872 Jan 12 13:41 mcal.working > drwxr-sr-x 2 mbsdaq users 4096 Jan 12 13:41 mc_gen_mcal > drwxr-sr-x 2 mbsdaq users 4096 Jan 12 13:41 obj_mcal > -rw-r--r-- 1 mbsdaq users 6545 Jan 12 13:41 sis3316_mapping_macros.h > -rw-r--r-- 1 mbsdaq users 5082 Jan 12 13:41 vme_struck_sis3316.spec > > And my impression was that these files are somehow central to reading out > our DAQ system. True, for reading the data after the DAQ as such. > My understanding is that for initializing and readout of the modules by the > DAQ software, the following configuration files are used (they are in a > different directory): > > -rw-r--r-- 1 mbsdaq users 4883 Jan 12 13:44 main.cfg > > -rw-r--r-- 1 mbsdaq users 194 Jan 12 13:42 r3bfuser.cfg > > -rw-r--r-- 1 mbsdaq users 3065 Jan 12 13:42 vulom.trlo Yes. Well outside upexps I hope. ;) > But for telling UCESB what to find in the the LMD stream coming from the RIO > (which is a result of these configuration files), somehow a 'mapping' is > necessary. And this I associated with UPEXPS. But maybe my understanding was > wrong, if UPEXPS is not used by you guys. You are correct. Only distinction would that that ucesb / upexps are only involved to either read .lmd files, or to read live data streams (which is also on lmd format) from the DAQ. -- With the git references above, we can hopefully try to figure out how deep into the other parts of upexps your directory has dependencies. But - as long as the data format has not changed - and the intention with the update to nurdlib etc was to not change any of those - the current unpacker specification and mapping should still work. In fact - if it does not - then we do not want to fix the unpacking stages, but understand why the DAQ delivers different data. > After lunch, I will give it a try to simply start the DAQ. Cheers, H?kan -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Tue Jan 16 19:20:54 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Tue, 16 Jan 2024 19:20:54 +0100 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <831905AE-5B53-45DA-81DD-756DED9EE76E@chalmers.se> <438345a1684c413e8678a1a2ac928bc2@hi-jena.gsi.de> <222475cb-2ab6-4f4c-9bc0-d08a8b20a3cc@chalmers.se> <4e1e90ee-e985-42b2-a4e8-83f02d1c56b8@chalmers.se> <5b0a058d-b58c-4e73-a59b-24a40d59a3f1@chalmers.se> <68c6e7a91d354a35a08a6a89d181b9b6@hi-jena.gsi.de> , <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de>, <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> , <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> Message-ID: On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > I am just trying to figure out how all the various scripts/commands work > together for setting up our DAQ system. Maybe, you can help to clearify some > things. > > > > - master.bash This would be intended to run on the readout board (RIO). The other scripts below is for the PC. > > source ../env/env.sh > ./trloii_setup.sh > # gdb --args \ > ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ > ? ? ? ? --label=MCAL1 \ > ? ? ? ? --triva=master,fctime=10,ctime=50 \ > ? ? ? ? --log-no-rate-limit \ > ? ? ? ? --server=drasi,dest=lyserv \ > ? ? ? ? --buf=size=400Mi \ > ? ? ? ? --max-ev-size=0x1000000 \ > ? ? ? ? --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ > ? ? ? ? --eb=lyserv \ > ? ? ? ? "$@" > > In the first line some environment variables are set. The second line tells > the VULOM4 how to operate (i. e. selection from modes of operation defined > in vulom.trlo). Then DRASI is started with a bunch of parameters. Is there > somewhere an explanation of the purpose of all these settings? The drasi command line options should be described here: http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html (Note: 'lyserv' is the name of your PC, at least as seen from the RIO.) The TRLO II setup file (vulom.trlo) is worse in terms of documentation. The format as such is hopefully rather straightforward. A description is here: http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html . The actual meaning is more complex, the TRLO II description can be found here: http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html (left pane), which just is a colourised version of this: http://fy.chalmers.se/~f96hajo/trloii/description.txt It does not describe the .trlo file as such, but what the gateware tries to achieve. > And what is in the last line? I never came accross "$@" before. That would be all the (non-shifted, i.e. not removed) options given to the script itself, i.e. master.bash. > - eb.bash > > ../drasi/bin/lwrocmerge \ > > ? ? --label=MCAL_EB \ > ? ? --merge-mode=event \ > ? ? --server=trans,flush=1 \ > ? ? --server=stream,flush=1 \ > ? ? --buf=size=1600Mi \ > ? ? --max-ev-size=20Mi \ > ? ? --eb-master=rio4-mcal-1 \ > ? ? --file-writer \ > ? ? --drasi=rio4-mcal-1 > > What is the purpose of this command? This runs an 'event builder' on the PC. Not strictly needed, but this way, the RIO only ever needs to send data once, to this event-builder (EB). File writing, and streaming of on-line data is then handled by this process. It is cheaper to have better network cards and so on in a plain PC. > Why are values for buffer size and max > event size different then in the command before? The nomenclaturure is unfortunately a bit convoluted below with ucesb regards 'buffer size'. The --buf in the two commands above give the size of the memory used to buffer data inside the process, and depends on how much memory each machine has. The --max-ev-size tells how large each .lmd event can be. The --max-ev-size configured in the event builder needs to be as large as the sum of all event sources it has. I.e. should be able to be the same as in your single source above. In the readout itself, any event that is read out cannot be larger than this. If it is, then the DAQ will report a fatal failure. > - fanout.bash > > #!/bin/bash > while : > do > ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ > ? ? stream://localhost \ > ? ? --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 > sleep 5 > done ? ? > > This looks like setting up a connection point to the outside world, right? Yes. It accepts connections and will serve them data for online analysis. stream://localhost tells it where to read data (here the PC itself where it is running). Using the 'stream' protocol, which esentially is just raw LMD events. (As is the 'transport protocol'.) That will be served on the default port used for the stream server set up by the EB above. --server is then the server that accepts connections, and serves data on another port (8001). > And we find the third (random?) value for a buffer size. That bufsize is actually the LMD buffer size used by the stream server. The corresponding value in the readout and EB is set implicitly from the maximum event size... > - rate.bash > > ../drasi/bin/lwrocmon --rate rio4-mcal-1 > > Ok, this I understand. We can look the DAQ over the shoulder and see what > the thing is doing in terms of number of trigger events, transported data, > etc. > - log.bash > > ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost > > This is also easy to understand. :-) Then also try to do (on the PC) drasi/bin/lwrocmon --tree rio4-mcal-1 localhost which would show a 'tree-view' monitoring of the running system. Cheers, H?kan From g.weber at hi-jena.gsi.de Thu Jan 18 11:29:39 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Thu, 18 Jan 2024 10:29:39 +0000 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <831905AE-5B53-45DA-81DD-756DED9EE76E@chalmers.se> <438345a1684c413e8678a1a2ac928bc2@hi-jena.gsi.de> <222475cb-2ab6-4f4c-9bc0-d08a8b20a3cc@chalmers.se> <4e1e90ee-e985-42b2-a4e8-83f02d1c56b8@chalmers.se> <5b0a058d-b58c-4e73-a59b-24a40d59a3f1@chalmers.se> <68c6e7a91d354a35a08a6a89d181b9b6@hi-jena.gsi.de> , <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de>, <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> , <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de>, Message-ID: <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> Dear friends, I now started the DAQ and it looks like there is a problem with the VETAR2 module. Attached please find the output once the DAQ is started on the RIO4. Here ist the error message: 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866) 11: a:1: .Gsi Etherbone init_slow { (module/gsi_etherbone/gsi_etherbone.c:110) 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No such file or directory. (module/gsi_etherbone/gsi_etherbone.c:120) 5: a:1: ..Calling exit(EXIT_FAILURE)... (module/gsi_etherbone/gsi_etherbone.c:120) How to proceed? Many thanks and best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Dienstag, 16. Januar 2024 19:20:54 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > I am just trying to figure out how all the various scripts/commands work > together for setting up our DAQ system. Maybe, you can help to clearify some > things. > > > > - master.bash This would be intended to run on the readout board (RIO). The other scripts below is for the PC. > > source ../env/env.sh > ./trloii_setup.sh > # gdb --args \ > ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ > --label=MCAL1 \ > --triva=master,fctime=10,ctime=50 \ > --log-no-rate-limit \ > --server=drasi,dest=lyserv \ > --buf=size=400Mi \ > --max-ev-size=0x1000000 \ > --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ > --eb=lyserv \ > "$@" > > In the first line some environment variables are set. The second line tells > the VULOM4 how to operate (i. e. selection from modes of operation defined > in vulom.trlo). Then DRASI is started with a bunch of parameters. Is there > somewhere an explanation of the purpose of all these settings? The drasi command line options should be described here: http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html (Note: 'lyserv' is the name of your PC, at least as seen from the RIO.) The TRLO II setup file (vulom.trlo) is worse in terms of documentation. The format as such is hopefully rather straightforward. A description is here: http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html . The actual meaning is more complex, the TRLO II description can be found here: http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html (left pane), which just is a colourised version of this: http://fy.chalmers.se/~f96hajo/trloii/description.txt It does not describe the .trlo file as such, but what the gateware tries to achieve. > And what is in the last line? I never came accross "$@" before. That would be all the (non-shifted, i.e. not removed) options given to the script itself, i.e. master.bash. > - eb.bash > > ../drasi/bin/lwrocmerge \ > > --label=MCAL_EB \ > --merge-mode=event \ > --server=trans,flush=1 \ > --server=stream,flush=1 \ > --buf=size=1600Mi \ > --max-ev-size=20Mi \ > --eb-master=rio4-mcal-1 \ > --file-writer \ > --drasi=rio4-mcal-1 > > What is the purpose of this command? This runs an 'event builder' on the PC. Not strictly needed, but this way, the RIO only ever needs to send data once, to this event-builder (EB). File writing, and streaming of on-line data is then handled by this process. It is cheaper to have better network cards and so on in a plain PC. > Why are values for buffer size and max > event size different then in the command before? The nomenclaturure is unfortunately a bit convoluted below with ucesb regards 'buffer size'. The --buf in the two commands above give the size of the memory used to buffer data inside the process, and depends on how much memory each machine has. The --max-ev-size tells how large each .lmd event can be. The --max-ev-size configured in the event builder needs to be as large as the sum of all event sources it has. I.e. should be able to be the same as in your single source above. In the readout itself, any event that is read out cannot be larger than this. If it is, then the DAQ will report a fatal failure. > - fanout.bash > > #!/bin/bash > while : > do > ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ > stream://localhost \ > --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 > sleep 5 > done > > This looks like setting up a connection point to the outside world, right? Yes. It accepts connections and will serve them data for online analysis. stream://localhost tells it where to read data (here the PC itself where it is running). Using the 'stream' protocol, which esentially is just raw LMD events. (As is the 'transport protocol'.) That will be served on the default port used for the stream server set up by the EB above. --server is then the server that accepts connections, and serves data on another port (8001). > And we find the third (random?) value for a buffer size. That bufsize is actually the LMD buffer size used by the stream server. The corresponding value in the readout and EB is set implicitly from the maximum event size... > - rate.bash > > ../drasi/bin/lwrocmon --rate rio4-mcal-1 > > Ok, this I understand. We can look the DAQ over the shoulder and see what > the thing is doing in terms of number of trigger events, transported data, > etc. > - log.bash > > ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost > > This is also easy to understand. :-) Then also try to do (on the PC) drasi/bin/lwrocmon --tree rio4-mcal-1 localhost which would show a 'tree-view' monitoring of the running system. Cheers, H?kan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- RIO4-MCAL-1 mbsdaq > ./master.bash hwmap_mapvme.c:240: LOG: Virtual address for TRLO II @ VME 0x03000000 is 0x3005e000. LOG: TRLO: MD5SUM: 0x426cb99c (CT: 5bba6507 = 2018-10-07 19:56:55 UTC) Clear module setup. Loading config file 'vulom.trlo'. Executing 'standalone'. Executing 'module_trigger'. 10: lwroc_hostname_util.c:105: Host 'lyserv' known as 192.168.1.1 (port: 56583). Thread has no error buffer yet... CPUS: 1 delay: 1 10: lwroc_hostname_util.c:105: Host 'lyserv' known as 192.168.1.1 (port: 56583). Thread has no error buffer yet... HOST: RIO4-MCAL-1 Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] 10: lwroc_data_pipe.c:122: Data buffer READOUT_PIPE, size 209715200 = 0x0c800000, 1 consumers. 11: lwroc_triva_readout.c:53: TRIVA: master,fctime=10,ctime=50 11: lwroc_triva_readout.c:210: TRIVA mode: master=1 11: lwroc_triva_readout.c:222: TRIVA VME map (addr=0x02000000) 11: hwmap_mapvme.c:240: Virtual address for TRIVA @ VME 0x02000000 is 0x30025000. 11: lwroc_triva_readout.c:264: TRIVA off 0x00 = 00001f20 10: lwroc_triva_readout.c:66: Silence TRIVA (HALT) 10: lwroc_net_io.c:164: Started server on port 56583 (data port 46671). client union size: 244 192 184 508 640 3048 204 => 3048 10: lwroc_readout.c:100: call readout_init... 10: lwroc_thread_util.c:105: This is the triva control thread! 10: lwroc_thread_util.c:105: This is the net io thread! 10: lwroc_thread_util.c:105: This is the data server thread! 10: lwroc_net_trans.c:1073: [drasi] Transport client connected (data) [192.168.1.1]. network client -> data network thread using blocking writes 10: lwroc_message_internal.c:418: Message client connected! 11: lwroc_triva_readout.c:606: Readout thread waiting for inject request... 11: lwroc_triva_control.c:350: TRIVA control: startup (wait for init request). move to data server thread... 11: lwroc_net_message.c:192: [msgclnt: 192.168.1.1] Connected. 10: lwroc_triva_control.c:370: Setup TRIVA (DISBUS, HALT, MASTER, RESET) 11: lwroc_triva_control.c:397: Set FCAtime to 10 and Ctime to 50... 10: lwroc_triva_control.c:418: Minimum event time ctime(5000)+1*rd(690)+3*wr(633)+fctime(1000)=8589 ns (116.428 kHz) 11: lwroc_triva_control.c:420: Clearing TRIVA... (HALT, DIS_IRQ, CLEAR=RESET) 10: lwroc_triva_state.c:1412: (Re)send ident messages... 11: lwroc_triva_readout.c:628: Readout thread injecting ID message! 11: lwroc_triva_control.c:478: TRIVA control: initialised (wait for test request). 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 9: lwroc_triva_control.c:507: TEST: GO 11: lwroc_triva_control.c:522: status = 0x00008021 11: lwroc_triva_control.c:670: TRIVA control: initialised (going for run). 11: lwroc_triva_control.c:679: status = 0x00000021 10: lwroc_triva_control.c:700: RUN: RESET 10: lwroc_triva_control.c:704: RUN: MT=14 9: lwroc_triva_control.c:712: GO (1 good test triggers done) (max 116.4 kHz) 11: lwroc_triva_readout.c:683: Readout thread loop active! 10: lwroc_triva_readout.c:369: Trigger 14 seen. 11: lwroc_triva_control.c:745: TRIVA control: running... 10: a:1: Global log level=verbose. (config/config.c:1292) 11: a:1: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib/cfg/default/crate.cfg'. (config/parser.c:286) 11: a:1: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib/cfg/default/crate.cfg'. (config/parser.c:298) 8: lwroc_triva_state.c:2322: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 10: lwroc_triva_state.c:2351: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2411: Node(s) busy in readout, waiting... 11: a:1: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg'. (config/parser.c:286) 11: a:1: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg'. (config/parser.c:298) 11: a:1: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib/cfg/default/module_log_level.cfg'. (config/parser.c:286) 11: a:1: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib/cfg/default/module_log_level.cfg'. (config/parser.c:298) 11: a:1: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib/cfg/default/gsi_vetar.cfg'. (config/parser.c:286) 11: a:1: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib/cfg/default/gsi_vetar.cfg'. (config/parser.c:298) 11: a:1: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib/cfg/default/module_log_level.cfg'. (config/parser.c:286) 11: a:1: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib/cfg/default/module_log_level.cfg'. (config/parser.c:298) 11: a:1: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib/cfg/default/sis_3316.cfg'. (config/parser.c:286) 11: a:1: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib/cfg/default/sis_3316.cfg'. (config/parser.c:298) 11: a:1: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib/cfg/default/module_log_level.cfg'. (config/parser.c:286) 11: a:1: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib/cfg/default/module_log_level.cfg'. (config/parser.c:298) 11: a:1: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib/cfg/default/sis_3316.cfg'. (config/parser.c:286) 11: a:1: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib/cfg/default/sis_3316.cfg'. (config/parser.c:298) 11: a:1: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib/cfg/default/module_log_level.cfg'. (config/parser.c:286) 11: a:1: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib/cfg/default/module_log_level.cfg'. (config/parser.c:298) 11: a:1: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib/cfg/default/sis_3316.cfg'. (config/parser.c:286) 11: a:1: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib/cfg/default/sis_3316.cfg'. (config/parser.c:298) 11: a:1: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib/cfg/default/module_log_level.cfg'. (config/parser.c:286) 11: a:1: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/nurdlib/cfg/default/module_log_level.cfg'. (config/parser.c:298) 11: a:1: Closed './main.cfg'. (config/parser.c:298) 10: a:1: crate_create { (crate/crate.c:301) 11: a:1: .Crate="MCAL". (crate/crate.c:316) 11: a:1: .Adaptive CVT=no. (crate/crate.c:321) 11: a:1: .Shadow readout disabled. (crate/crate.c:332) 11: a:1: .Early deadtime release=no. (crate/crate.c:337) 11: a:1: .event_max override=0. (crate/crate.c:342) 11: a:1: .Re-init sleep=1s. (crate/crate.c:347) 11: a:1: .Gsi Siderem crate_create { (module/gsi_siderem/gsi_siderem.c:51) 11: a:1: .Gsi Siderem crate_create } (module/gsi_siderem/gsi_siderem.c:55) 11: a:1: .Gsi Tacquila crate_create { (module/gsi_tacquila/gsi_tacquila.c:103) 11: a:1: .Gsi Tacquila crate_create } (module/gsi_tacquila/gsi_tacquila.c:106) 11: a:1: .Pnpi Cros3 crate_create { (module/pnpi_cros3/pnpi_cros3.c:216) 11: a:1: .Pnpi Cros3 crate_create } (module/pnpi_cros3/pnpi_cros3.c:219) 11: a:1: .Gsi Vulom create { (module/gsi_vulom/gsi_vulom.c:5) 11: a:1: ..TRLO II create { (module/trloii/trloii.c:300) 11: a:1: ...Address=03000000. (module/trloii/trloii.c:303) 11: a:1: ...Has timestamps. (module/trloii/trloii.c:307) 11: a:1: ..TRLO II create } (module/trloii/trloii.c:329) 11: a:1: .Gsi Vulom create } (module/gsi_vulom/gsi_vulom.c:5) 11: a:1: .module[0]=GSI_VULOM. (crate/crate.c:468) 11: a:1: .Gsi Etherbone create { (module/gsi_etherbone/gsi_etherbone.c:72) 11: a:1: ..Mode=etherbone. (module/gsi_etherbone/gsi_etherbone.c:82) 11: a:1: ..Address=0x50000000. (module/gsi_etherbone/gsi_etherbone.c:87) 11: a:1: .Gsi Etherbone create } (module/gsi_etherbone/gsi_etherbone.c:90) 11: a:1: .module[1]=GSI_VETAR. (crate/crate.c:468) 11: a:1: .Gsi Vulom are_distinguishable. (module/gsi_vulom/gsi_vulom.c:5) 11: a:1: .sis3316 create { (module/sis_3316/sis_3316.c:225) 11: a:1: ..Address = 30000000 (module/sis_3316/sis_3316.c:236) 11: a:1: ..sis3316 get_config { (module/sis_3316/sis_3316.c:3106) 11: a:1: ...channels_to_read = mask 0x0000ffff (module/sis_3316/sis_3316.c:3116) 11: a:1: ...use_tau_correction = mask 0x00000000 (module/sis_3316/sis_3316.c:3128) 11: a:1: ...use_external_trigger = mask 0x0000ffff (module/sis_3316/sis_3316.c:3134) 11: a:1: ...use_internal_trigger = mask 0x00000000 (module/sis_3316/sis_3316.c:3140) 11: a:1: ...trigger_output = mask 0x0000ffff (module/sis_3316/sis_3316.c:3146) ... a few pages of SIS3316 stuff that seems to work fine ... 11: a:1: ...sample_length_maw_e[0] = 2048. (module/sis_3316/sis_3316.c:3594) 11: a:1: ...sample_length_maw_e[1] = 2048. (module/sis_3316/sis_3316.c:3594) 11: a:1: ...sample_length_maw_e[2] = 2048. (module/sis_3316/sis_3316.c:3594) 11: a:1: ...sample_length_maw_e[3] = 2048. (module/sis_3316/sis_3316.c:3594) 11: a:1: ...pretrigger_delay_maw_e[0] = 100. (module/sis_3316/sis_3316.c:3603) 11: a:1: ...pretrigger_delay_maw_e[1] = 100. (module/sis_3316/sis_3316.c:3603) 11: a:1: ...pretrigger_delay_maw_e[2] = 100. (module/sis_3316/sis_3316.c:3603) 11: a:1: ...pretrigger_delay_maw_e[3] = 100. (module/sis_3316/sis_3316.c:3603) 11: a:1: ...gate[0].delay = 0 ns. (module/sis_3316/sis_3316.c:3621) 11: a:1: ...gate[0].width = 30 ns. (module/sis_3316/sis_3316.c:3629) 11: a:1: ...gate[1].delay = 40 ns. (module/sis_3316/sis_3316.c:3621) 11: a:1: ...gate[1].width = 30 ns. (module/sis_3316/sis_3316.c:3629) 11: a:1: ...gate[2].delay = 40 ns. (module/sis_3316/sis_3316.c:3621) 11: a:1: ...gate[2].width = 60 ns. (module/sis_3316/sis_3316.c:3629) 11: a:1: ...gate[3].delay = 0 ns. (module/sis_3316/sis_3316.c:3621) 11: a:1: ...gate[3].width = 100 ns. (module/sis_3316/sis_3316.c:3629) 11: a:1: ...gate[4].delay = 0 ns. (module/sis_3316/sis_3316.c:3621) 11: a:1: ...gate[4].width = 200 ns. (module/sis_3316/sis_3316.c:3629) 11: a:1: ...gate[5].delay = 0 ns. (module/sis_3316/sis_3316.c:3621) 11: a:1: ...gate[5].width = 500 ns. (module/sis_3316/sis_3316.c:3629) 11: a:1: ...gate[6].delay = 0 ns. (module/sis_3316/sis_3316.c:3621) 11: a:1: ...gate[6].width = 500 ns. (module/sis_3316/sis_3316.c:3629) 11: a:1: ...gate[7].delay = 0 ns. (module/sis_3316/sis_3316.c:3621) 11: a:1: ...gate[7].width = 500 ns. (module/sis_3316/sis_3316.c:3629) 11: a:1: ..sis3316 get_config } (module/sis_3316/sis_3316.c:3636) 11: a:1: .sis3316 create } (module/sis_3316/sis_3316.c:247) 11: a:1: .module[4]=SIS_3316. (crate/crate.c:468) 11: a:1: .Counter=auto:Default. (crate/crate.c:572) 10: a:1: crate_create(MCAL) } (crate/crate.c:622) 10: a:1: crate_init(MCAL) { (crate/crate.c:841) 11: a:1: .map_setup { (module/map/map.c:183) 11: a:1: ..sicy_setup { (module/map/map_xpc_3310.c:82) 11: a:1: ...bridge_setup { (module/map/map_xpc_3310.c:52) 11: a:1: ...bridge_setup } (module/map/map_xpc_3310.c:60) 11: a:1: ..sicy_setup } (module/map/map_xpc_3310.c:84) 11: a:1: ..blt_setup { (module/map/map_xpc_3310.c:126) 11: a:1: ...bridge_setup { (module/map/map_xpc_3310.c:52) 11: a:1: ...bridge_setup } (module/map/map_xpc_3310.c:60) 11: a:1: ..blt_setup } (module/map/map_xpc_3310.c:136) 11: a:1: ..Broken BLT return val = yes. (module/map/map.c:186) 11: a:1: .map_setup } (module/map/map.c:193) 11: a:1: .Slow module[0]=GSI_VULOM. (crate/crate.c:866) 11: a:1: .Gsi Vulom init_slow { (module/gsi_vulom/gsi_vulom.c:5) 11: a:1: ..TRLO II init_slow { (module/trloii/trloii.c:404) 11: a:1: ...map_map(addr=0x03000000,size=0x00016000,mode=noblt,poke=0x0000000c/32) { (module/map/map.c:127) 11: a:1: ....map_poke { (module/map/map.c:171) 11: a:1: .....sicy_map(addr=0x0300000c,size=0x4) { (module/map/map.c:255) 11: a:1: .....sicy_map(mapped=0x3001f00c) } (module/map/map.c:267) 11: a:1: .....Poke reading 0x3001f00c... (module/map/map_sicy_common.c:38) 11: a:1: .....sicy_unmap { (module/map/map.c:275) 11: a:1: .....sicy_unmap } (module/map/map.c:277) 11: a:1: ....map_poke } (module/map/map.c:177) 11: a:1: ....sicy_map(addr=0x03000000,size=0x16000) { (module/map/map.c:255) 11: a:1: ....sicy_map(mapped=0x30036000) } (module/map/map.c:267) 11: a:1: ...map_map(mapped=0x30036000) } (module/map/map.c:156) 11: a:1: ..TRLO II init_slow } (module/trloii/trloii.c:442) 11: a:1: .Gsi Vulom init_slow } (module/gsi_vulom/gsi_vulom.c:5) 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866) 11: a:1: .Gsi Etherbone init_slow { (module/gsi_etherbone/gsi_etherbone.c:110) 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No such file or directory. (module/gsi_etherbone/gsi_etherbone.c:120) 5: a:1: ..Calling exit(EXIT_FAILURE)... (module/gsi_etherbone/gsi_etherbone.c:120) Performing hardware cleanup (TRIVA HALT, RESET)... From f96hajo at chalmers.se Thu Jan 18 12:21:17 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Thu, 18 Jan 2024 12:21:17 +0100 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <831905AE-5B53-45DA-81DD-756DED9EE76E@chalmers.se> <438345a1684c413e8678a1a2ac928bc2@hi-jena.gsi.de> <222475cb-2ab6-4f4c-9bc0-d08a8b20a3cc@chalmers.se> <4e1e90ee-e985-42b2-a4e8-83f02d1c56b8@chalmers.se> <5b0a058d-b58c-4e73-a59b-24a40d59a3f1@chalmers.se> <68c6e7a91d354a35a08a6a89d181b9b6@hi-jena.gsi.de> , <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de>, <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> , <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de>, <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> Message-ID: <3857d3b7-77ea-348d-0174-c9e52e5b4492@chalmers.se> Dear G?nter, I'm not sure what Hans will need to figure this one out, but these configuration files might be helpful: main.cfg r3bfuser.cfg vulom.trlo Cheers, H?kan On Thu, 18 Jan 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > I now started the DAQ and it looks like there is a problem with the VETAR2 > module. Attached please find the output once the DAQ is started on the RIO4. > > > Here ist the error message: > > > 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866) > 11: a:1: .Gsi Etherbone init_slow { > (module/gsi_etherbone/gsi_etherbone.c:110) > 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No > such file or directory. > ?(module/gsi_etherbone/gsi_etherbone.c:120) > 5: a:1: ..Calling exit(EXIT_FAILURE)... > (module/gsi_etherbone/gsi_etherbone.c:120) > > How to proceed? > > > > Many thanks and best greetings > G?nter > > > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan > T Johansson > Gesendet: Dienstag, 16. Januar 2024 19:20:54 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, > DRASI, etc. were updated ? > > On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: > > > > > Dear friends, > > > > > > I am just trying to figure out how all the various scripts/commands work > > together for setting up our DAQ system. Maybe, you can help to clearify > some > > things. > > > > > > > > - master.bash > > This would be intended to run on the readout board (RIO).? The other > scripts below is for the PC. > > > > > source ../env/env.sh > > ./trloii_setup.sh > > # gdb --args \ > > ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ > > ? ? ? ? --label=MCAL1 \ > > ? ? ? ? --triva=master,fctime=10,ctime=50 \ > > ? ? ? ? --log-no-rate-limit \ > > ? ? ? ? --server=drasi,dest=lyserv \ > > ? ? ? ? --buf=size=400Mi \ > > ? ? ? ? --max-ev-size=0x1000000 \ > > ? ? ? ? --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ > > ? ? ? ? --eb=lyserv \ > > ? ? ? ? "$@" > > > > In the first line some environment variables are set. The second line > tells > > the VULOM4 how to operate (i. e. selection from modes of operation defined > > in vulom.trlo). Then DRASI is started with a bunch of parameters. Is there > > somewhere an explanation of the purpose of all these settings? > > The drasi command line options should be described here: > > http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html > > (Note: 'lyserv' is the name of your PC, at least as seen from the RIO.) > > The TRLO II setup file (vulom.trlo) is worse in terms of documentation. > The format as such is hopefully rather straightforward.? A description is > here: http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html . > The actual meaning is more complex, the TRLO II description can be found > here: > > http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html > > (left pane), which just is a colourised version of this: > http://fy.chalmers.se/~f96hajo/trloii/description.txt > > It does not describe the .trlo file as such, but what the gateware tries > to achieve. > > > And what is in the last line? I never came accross "$@" before. > > That would be all the (non-shifted, i.e. not removed) options given to the > script itself, i.e. master.bash. > > > - eb.bash > > > > ../drasi/bin/lwrocmerge \ > > > > ? ? --label=MCAL_EB \ > > ? ? --merge-mode=event \ > > ? ? --server=trans,flush=1 \ > > ? ? --server=stream,flush=1 \ > > ? ? --buf=size=1600Mi \ > > ? ? --max-ev-size=20Mi \ > > ? ? --eb-master=rio4-mcal-1 \ > > ? ? --file-writer \ > > ? ? --drasi=rio4-mcal-1 > > > > What is the purpose of this command? > > This runs an 'event builder' on the PC.? Not strictly needed, but this > way, the RIO only ever needs to send data once, to this event-builder > (EB).? File writing, and streaming of on-line data is then handled by this > process.? It is cheaper to have better network cards and so on in a plain > PC. > > > Why are values for buffer size and max > > event size different then in the command before? > > The nomenclaturure is unfortunately a bit convoluted below with ucesb > regards 'buffer size'.? The --buf in the two commands above give the size > of the memory used to buffer data inside the process, and depends on how > much memory each machine has.? The --max-ev-size tells how large each .lmd > event can be.? The --max-ev-size configured in the event builder needs to > be as large as the sum of all event sources it has.? I.e. should be able > to be the same as in your single source above. > > In the readout itself, any event that is read out cannot be larger than > this.? If it is, then the DAQ will report a fatal failure. > > > - fanout.bash > > > > #!/bin/bash > > while : > > do > > ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ > > ? ? stream://localhost \ > > ? ? --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 > > sleep 5 > > done ? ? > > > > This looks like setting up a connection point to the outside world, right? > > Yes.? It accepts connections and will serve them data for online analysis. > > stream://localhost? tells it where to read data (here the PC itself where > it is running).? Using the 'stream' protocol, which esentially is just raw > LMD events.? (As is the 'transport protocol'.)? That will be served on the > default port used for the stream server set up by the EB above. > > --server is then the server that accepts connections, and serves data on > another port (8001). > > > And we find the third (random?) value for a buffer size. > > That bufsize is actually the LMD buffer size used by the stream server. > The corresponding value in the readout and EB is set implicitly from the > maximum event size... > > > - rate.bash > > > > ../drasi/bin/lwrocmon --rate rio4-mcal-1 > > > > Ok, this I understand. We can look the DAQ over the shoulder and see what > > the thing is doing in terms of number of trigger events, transported data, > > etc. > > > - log.bash > > > > ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost > > > > This is also easy to understand. > > :-) > > Then also try to do (on the PC) > > drasi/bin/lwrocmon --tree rio4-mcal-1 localhost > > which would show a 'tree-view' monitoring of the running system. > > > Cheers, > H?kan > > From g.weber at hi-jena.gsi.de Thu Jan 18 12:42:32 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Thu, 18 Jan 2024 11:42:32 +0000 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <3857d3b7-77ea-348d-0174-c9e52e5b4492@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <831905AE-5B53-45DA-81DD-756DED9EE76E@chalmers.se> <438345a1684c413e8678a1a2ac928bc2@hi-jena.gsi.de> <222475cb-2ab6-4f4c-9bc0-d08a8b20a3cc@chalmers.se> <4e1e90ee-e985-42b2-a4e8-83f02d1c56b8@chalmers.se> <5b0a058d-b58c-4e73-a59b-24a40d59a3f1@chalmers.se> <68c6e7a91d354a35a08a6a89d181b9b6@hi-jena.gsi.de> , <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de>, <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> , <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de>, <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de>, <3857d3b7-77ea-348d-0174-c9e52e5b4492@chalmers.se> Message-ID: <392edff8f82c4047ab8911f52ed2d363@hi-jena.gsi.de> Dear all, attached please find these files. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Donnerstag, 18. Januar 2024 12:21:17 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated Dear G?nter, I'm not sure what Hans will need to figure this one out, but these configuration files might be helpful: main.cfg r3bfuser.cfg vulom.trlo Cheers, H?kan On Thu, 18 Jan 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > I now started the DAQ and it looks like there is a problem with the VETAR2 > module. Attached please find the output once the DAQ is started on the RIO4. > > > Here ist the error message: > > > 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866) > 11: a:1: .Gsi Etherbone init_slow { > (module/gsi_etherbone/gsi_etherbone.c:110) > 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No > such file or directory. > (module/gsi_etherbone/gsi_etherbone.c:120) > 5: a:1: ..Calling exit(EXIT_FAILURE)... > (module/gsi_etherbone/gsi_etherbone.c:120) > > How to proceed? > > > > Many thanks and best greetings > G?nter > > > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan > T Johansson > Gesendet: Dienstag, 16. Januar 2024 19:20:54 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, > DRASI, etc. were updated > > On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: > > > > > Dear friends, > > > > > > I am just trying to figure out how all the various scripts/commands work > > together for setting up our DAQ system. Maybe, you can help to clearify > some > > things. > > > > > > > > - master.bash > > This would be intended to run on the readout board (RIO). The other > scripts below is for the PC. > > > > > source ../env/env.sh > > ./trloii_setup.sh > > # gdb --args \ > > ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ > > --label=MCAL1 \ > > --triva=master,fctime=10,ctime=50 \ > > --log-no-rate-limit \ > > --server=drasi,dest=lyserv \ > > --buf=size=400Mi \ > > --max-ev-size=0x1000000 \ > > --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ > > --eb=lyserv \ > > "$@" > > > > In the first line some environment variables are set. The second line > tells > > the VULOM4 how to operate (i. e. selection from modes of operation defined > > in vulom.trlo). Then DRASI is started with a bunch of parameters. Is there > > somewhere an explanation of the purpose of all these settings? > > The drasi command line options should be described here: > > http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html > > (Note: 'lyserv' is the name of your PC, at least as seen from the RIO.) > > The TRLO II setup file (vulom.trlo) is worse in terms of documentation. > The format as such is hopefully rather straightforward. A description is > here: http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html . > The actual meaning is more complex, the TRLO II description can be found > here: > > http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html > > (left pane), which just is a colourised version of this: > http://fy.chalmers.se/~f96hajo/trloii/description.txt > > It does not describe the .trlo file as such, but what the gateware tries > to achieve. > > > And what is in the last line? I never came accross "$@" before. > > That would be all the (non-shifted, i.e. not removed) options given to the > script itself, i.e. master.bash. > > > - eb.bash > > > > ../drasi/bin/lwrocmerge \ > > > > --label=MCAL_EB \ > > --merge-mode=event \ > > --server=trans,flush=1 \ > > --server=stream,flush=1 \ > > --buf=size=1600Mi \ > > --max-ev-size=20Mi \ > > --eb-master=rio4-mcal-1 \ > > --file-writer \ > > --drasi=rio4-mcal-1 > > > > What is the purpose of this command? > > This runs an 'event builder' on the PC. Not strictly needed, but this > way, the RIO only ever needs to send data once, to this event-builder > (EB). File writing, and streaming of on-line data is then handled by this > process. It is cheaper to have better network cards and so on in a plain > PC. > > > Why are values for buffer size and max > > event size different then in the command before? > > The nomenclaturure is unfortunately a bit convoluted below with ucesb > regards 'buffer size'. The --buf in the two commands above give the size > of the memory used to buffer data inside the process, and depends on how > much memory each machine has. The --max-ev-size tells how large each .lmd > event can be. The --max-ev-size configured in the event builder needs to > be as large as the sum of all event sources it has. I.e. should be able > to be the same as in your single source above. > > In the readout itself, any event that is read out cannot be larger than > this. If it is, then the DAQ will report a fatal failure. > > > - fanout.bash > > > > #!/bin/bash > > while : > > do > > ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ > > stream://localhost \ > > --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 > > sleep 5 > > done > > > > This looks like setting up a connection point to the outside world, right? > > Yes. It accepts connections and will serve them data for online analysis. > > stream://localhost tells it where to read data (here the PC itself where > it is running). Using the 'stream' protocol, which esentially is just raw > LMD events. (As is the 'transport protocol'.) That will be served on the > default port used for the stream server set up by the EB above. > > --server is then the server that accepts connections, and serves data on > another port (8001). > > > And we find the third (random?) value for a buffer size. > > That bufsize is actually the LMD buffer size used by the stream server. > The corresponding value in the readout and EB is set implicitly from the > maximum event size... > > > - rate.bash > > > > ../drasi/bin/lwrocmon --rate rio4-mcal-1 > > > > Ok, this I understand. We can look the DAQ over the shoulder and see what > > the thing is doing in terms of number of trigger events, transported data, > > etc. > > > - log.bash > > > > ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost > > > > This is also easy to understand. > > :-) > > Then also try to do (on the PC) > > drasi/bin/lwrocmon --tree rio4-mcal-1 localhost > > which would show a 'tree-view' monitoring of the running system. > > > Cheers, > H?kan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vulom.trlo Type: application/octet-stream Size: 3064 bytes Desc: vulom.trlo URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: main.cfg Type: application/octet-stream Size: 4882 bytes Desc: main.cfg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: r3bfuser.cfg Type: application/octet-stream Size: 194 bytes Desc: r3bfuser.cfg URL: From hans.tornqvist at chalmers.se Thu Jan 18 13:28:36 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Thu, 18 Jan 2024 13:28:36 +0100 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <831905AE-5B53-45DA-81DD-756DED9EE76E@chalmers.se> <438345a1684c413e8678a1a2ac928bc2@hi-jena.gsi.de> <222475cb-2ab6-4f4c-9bc0-d08a8b20a3cc@chalmers.se> <4e1e90ee-e985-42b2-a4e8-83f02d1c56b8@chalmers.se> <5b0a058d-b58c-4e73-a59b-24a40d59a3f1@chalmers.se> <68c6e7a91d354a35a08a6a89d181b9b6@hi-jena.gsi.de> <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de> <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> Message-ID: <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> Dear G?nter, It looks like either the Vetar driver failed, or the fw/driver is old and nurdlib expects a file that didn't exist a while back. If it's the latter I can add a switch to ignore this file, it's not critical for readout and is used to enter a faster readout mode. Which version of nurdlib is this? The files and line numbers don't match with what I see in the source code, and the last time gsi_etherbone.c changed was early last year. The message "Could not open so-and-so" should be for the device, e.g. /dev/pcie_wb0. This is used for the readout. The dactl file should fail with "Failed dactl fopen". To summarise, I would suggest to make sure that the correct nurdlib and r3bfuser are executed by the DAQ scripts. Meanwhile I will prepare a switch to ignore the dactl file which could anyhow be useful for old configurations, and to clean up the Etherbone error messages. Best regards, Hans On 2024-01-18 11:29, Weber, Guenter Dr. wrote: > Dear friends, > > > I now started the DAQ and it looks like there is a problem with the > VETAR2 module. Attached please find the output once the DAQ is started > on the RIO4. > > > Here ist the error message: > > > 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866) > 11: a:1: .Gsi Etherbone init_slow { > (module/gsi_etherbone/gsi_etherbone.c:110) > 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No > such file or directory. > ?(module/gsi_etherbone/gsi_etherbone.c:120) > 5: a:1: ..Calling exit(EXIT_FAILURE)... > (module/gsi_etherbone/gsi_etherbone.c:120) > > How to proceed? > > > > Many thanks and best greetings > G?nter > > > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > H?kan T Johansson > *Gesendet:* Dienstag, 16. Januar 2024 19:20:54 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > TRLOII, DRASI, etc. were updated > > On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: > >> >> Dear friends, >> >> >> I am just trying to figure out how all the various scripts/commands work >> together for setting up our DAQ system. Maybe, you can help to clearify some >> things. >> >> >> >> - master.bash > > This would be intended to run on the readout board (RIO).? The other > scripts below is for the PC. > >> >> source ../env/env.sh >> ./trloii_setup.sh >> # gdb --args \ >> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ >> ? ? ? ? --label=MCAL1 \ >> ? ? ? ? --triva=master,fctime=10,ctime=50 \ >> ? ? ? ? --log-no-rate-limit \ >> ? ? ? ? --server=drasi,dest=lyserv \ >> ? ? ? ? --buf=size=400Mi \ >> ? ? ? ? --max-ev-size=0x1000000 \ >> ? ? ? ? --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ >> ? ? ? ? --eb=lyserv \ >> ? ? ? ? "$@" >> >> In the first line some environment variables are set. The second line tells >> the VULOM4 how to operate (i. e. selection from modes of operation defined >> in vulom.trlo). Then DRASI is started with a bunch of parameters. Is there >> somewhere an explanation of the purpose of all these settings? > > The drasi command line options should be described here: > > http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html > > > (Note: 'lyserv' is the name of your PC, at least as seen from the RIO.) > > The TRLO II setup file (vulom.trlo) is worse in terms of documentation. > The format as such is hopefully rather straightforward.? A description is > here: http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html > . > The actual meaning is more complex, the TRLO II description can be found > here: > > http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html > > > (left pane), which just is a colourised version of this: > http://fy.chalmers.se/~f96hajo/trloii/description.txt > > > It does not describe the .trlo file as such, but what the gateware tries > to achieve. > >> And what is in the last line? I never came accross "$@" before. > > That would be all the (non-shifted, i.e. not removed) options given to the > script itself, i.e. master.bash. > >> - eb.bash >> >> ../drasi/bin/lwrocmerge \ >> >> ? ? --label=MCAL_EB \ >> ? ? --merge-mode=event \ >> ? ? --server=trans,flush=1 \ >> ? ? --server=stream,flush=1 \ >> ? ? --buf=size=1600Mi \ >> ? ? --max-ev-size=20Mi \ >> ? ? --eb-master=rio4-mcal-1 \ >> ? ? --file-writer \ >> ? ? --drasi=rio4-mcal-1 >> >> What is the purpose of this command? > > This runs an 'event builder' on the PC.? Not strictly needed, but this > way, the RIO only ever needs to send data once, to this event-builder > (EB).? File writing, and streaming of on-line data is then handled by this > process.? It is cheaper to have better network cards and so on in a plain > PC. > >> Why are values for buffer size and max >> event size different then in the command before? > > The nomenclaturure is unfortunately a bit convoluted below with ucesb > regards 'buffer size'.? The --buf in the two commands above give the size > of the memory used to buffer data inside the process, and depends on how > much memory each machine has.? The --max-ev-size tells how large each .lmd > event can be.? The --max-ev-size configured in the event builder needs to > be as large as the sum of all event sources it has.? I.e. should be able > to be the same as in your single source above. > > In the readout itself, any event that is read out cannot be larger than > this.? If it is, then the DAQ will report a fatal failure. > >> - fanout.bash >> >> #!/bin/bash >> while : >> do >> ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ >> ? ? stream://localhost \ >> ? ? --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 >> sleep 5 >> done >> >> This looks like setting up a connection point to the outside world, right? > > Yes.? It accepts connections and will serve them data for online analysis. > > stream://localhost? tells it where to read data (here the PC itself where > it is running).? Using the 'stream' protocol, which esentially is just raw > LMD events.? (As is the 'transport protocol'.)? That will be served on the > default port used for the stream server set up by the EB above. > > --server is then the server that accepts connections, and serves data on > another port (8001). > >> And we find the third (random?) value for a buffer size. > > That bufsize is actually the LMD buffer size used by the stream server. > The corresponding value in the readout and EB is set implicitly from the > maximum event size... > >> - rate.bash >> >> ../drasi/bin/lwrocmon --rate rio4-mcal-1 >> >> Ok, this I understand. We can look the DAQ over the shoulder and see what >> the thing is doing in terms of number of trigger events, transported data, >> etc. > >> - log.bash >> >> ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost >> >> This is also easy to understand. > > :-) > > Then also try to do (on the PC) > > drasi/bin/lwrocmon --tree rio4-mcal-1 localhost > > which would show a 'tree-view' monitoring of the running system. > > > Cheers, > H?kan > From g.weber at hi-jena.gsi.de Thu Jan 18 21:43:04 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Thu, 18 Jan 2024 20:43:04 +0000 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <831905AE-5B53-45DA-81DD-756DED9EE76E@chalmers.se> <438345a1684c413e8678a1a2ac928bc2@hi-jena.gsi.de> <222475cb-2ab6-4f4c-9bc0-d08a8b20a3cc@chalmers.se> <4e1e90ee-e985-42b2-a4e8-83f02d1c56b8@chalmers.se> <5b0a058d-b58c-4e73-a59b-24a40d59a3f1@chalmers.se> <68c6e7a91d354a35a08a6a89d181b9b6@hi-jena.gsi.de> <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de> <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de>, <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> Message-ID: <6265a341aaa846559fc5932f9c0e0829@hi-jena.gsi.de> Dear Hans, there was some redirect burried in the script which executes scripts which execute some more scripts ... and that made me start the DAQ in the old folder, not the new one. Sorry for that. I now came across the following line in the script which starts the VULOM: $VULOM4_CTRL --addr=$addr --clear-setup --config=vulom.trlo standalone module_trigger Here I need to know the firmware number to define the path VULOM4_CTRL, right? Is there a way to do this automatically? Somehow this works already in the makefile of NURDLIB. I would like to avoid to hard code this into the environment settings if there is a way to figure it out on the fly. Thanks so much! Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von Hans Toshihide T?rnqvist Gesendet: Donnerstag, 18. Januar 2024 13:28:36 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated Dear G?nter, It looks like either the Vetar driver failed, or the fw/driver is old and nurdlib expects a file that didn't exist a while back. If it's the latter I can add a switch to ignore this file, it's not critical for readout and is used to enter a faster readout mode. Which version of nurdlib is this? The files and line numbers don't match with what I see in the source code, and the last time gsi_etherbone.c changed was early last year. The message "Could not open so-and-so" should be for the device, e.g. /dev/pcie_wb0. This is used for the readout. The dactl file should fail with "Failed dactl fopen". To summarise, I would suggest to make sure that the correct nurdlib and r3bfuser are executed by the DAQ scripts. Meanwhile I will prepare a switch to ignore the dactl file which could anyhow be useful for old configurations, and to clean up the Etherbone error messages. Best regards, Hans On 2024-01-18 11:29, Weber, Guenter Dr. wrote: > Dear friends, > > > I now started the DAQ and it looks like there is a problem with the > VETAR2 module. Attached please find the output once the DAQ is started > on the RIO4. > > > Here ist the error message: > > > 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866) > 11: a:1: .Gsi Etherbone init_slow { > (module/gsi_etherbone/gsi_etherbone.c:110) > 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No > such file or directory. > (module/gsi_etherbone/gsi_etherbone.c:120) > 5: a:1: ..Calling exit(EXIT_FAILURE)... > (module/gsi_etherbone/gsi_etherbone.c:120) > > How to proceed? > > > > Many thanks and best greetings > G?nter > > > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > H?kan T Johansson > *Gesendet:* Dienstag, 16. Januar 2024 19:20:54 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > TRLOII, DRASI, etc. were updated > > On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: > >> >> Dear friends, >> >> >> I am just trying to figure out how all the various scripts/commands work >> together for setting up our DAQ system. Maybe, you can help to clearify some >> things. >> >> >> >> - master.bash > > This would be intended to run on the readout board (RIO). The other > scripts below is for the PC. > >> >> source ../env/env.sh >> ./trloii_setup.sh >> # gdb --args \ >> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ >> --label=MCAL1 \ >> --triva=master,fctime=10,ctime=50 \ >> --log-no-rate-limit \ >> --server=drasi,dest=lyserv \ >> --buf=size=400Mi \ >> --max-ev-size=0x1000000 \ >> --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ >> --eb=lyserv \ >> "$@" >> >> In the first line some environment variables are set. The second line tells >> the VULOM4 how to operate (i. e. selection from modes of operation defined >> in vulom.trlo). Then DRASI is started with a bunch of parameters. Is there >> somewhere an explanation of the purpose of all these settings? > > The drasi command line options should be described here: > > http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html > > > (Note: 'lyserv' is the name of your PC, at least as seen from the RIO.) > > The TRLO II setup file (vulom.trlo) is worse in terms of documentation. > The format as such is hopefully rather straightforward. A description is > here: http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html > . > The actual meaning is more complex, the TRLO II description can be found > here: > > http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html > > > (left pane), which just is a colourised version of this: > http://fy.chalmers.se/~f96hajo/trloii/description.txt > > > It does not describe the .trlo file as such, but what the gateware tries > to achieve. > >> And what is in the last line? I never came accross "$@" before. > > That would be all the (non-shifted, i.e. not removed) options given to the > script itself, i.e. master.bash. > >> - eb.bash >> >> ../drasi/bin/lwrocmerge \ >> >> --label=MCAL_EB \ >> --merge-mode=event \ >> --server=trans,flush=1 \ >> --server=stream,flush=1 \ >> --buf=size=1600Mi \ >> --max-ev-size=20Mi \ >> --eb-master=rio4-mcal-1 \ >> --file-writer \ >> --drasi=rio4-mcal-1 >> >> What is the purpose of this command? > > This runs an 'event builder' on the PC. Not strictly needed, but this > way, the RIO only ever needs to send data once, to this event-builder > (EB). File writing, and streaming of on-line data is then handled by this > process. It is cheaper to have better network cards and so on in a plain > PC. > >> Why are values for buffer size and max >> event size different then in the command before? > > The nomenclaturure is unfortunately a bit convoluted below with ucesb > regards 'buffer size'. The --buf in the two commands above give the size > of the memory used to buffer data inside the process, and depends on how > much memory each machine has. The --max-ev-size tells how large each .lmd > event can be. The --max-ev-size configured in the event builder needs to > be as large as the sum of all event sources it has. I.e. should be able > to be the same as in your single source above. > > In the readout itself, any event that is read out cannot be larger than > this. If it is, then the DAQ will report a fatal failure. > >> - fanout.bash >> >> #!/bin/bash >> while : >> do >> ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ >> stream://localhost \ >> --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 >> sleep 5 >> done >> >> This looks like setting up a connection point to the outside world, right? > > Yes. It accepts connections and will serve them data for online analysis. > > stream://localhost tells it where to read data (here the PC itself where > it is running). Using the 'stream' protocol, which esentially is just raw > LMD events. (As is the 'transport protocol'.) That will be served on the > default port used for the stream server set up by the EB above. > > --server is then the server that accepts connections, and serves data on > another port (8001). > >> And we find the third (random?) value for a buffer size. > > That bufsize is actually the LMD buffer size used by the stream server. > The corresponding value in the readout and EB is set implicitly from the > maximum event size... > >> - rate.bash >> >> ../drasi/bin/lwrocmon --rate rio4-mcal-1 >> >> Ok, this I understand. We can look the DAQ over the shoulder and see what >> the thing is doing in terms of number of trigger events, transported data, >> etc. > >> - log.bash >> >> ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost >> >> This is also easy to understand. > > :-) > > Then also try to do (on the PC) > > drasi/bin/lwrocmon --tree rio4-mcal-1 localhost > > which would show a 'tree-view' monitoring of the running system. > > > Cheers, > H?kan > -- 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: From f96hajo at chalmers.se Thu Jan 18 22:39:31 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Thu, 18 Jan 2024 22:39:31 +0100 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <6265a341aaa846559fc5932f9c0e0829@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <222475cb-2ab6-4f4c-9bc0-d08a8b20a3cc@chalmers.se> <4e1e90ee-e985-42b2-a4e8-83f02d1c56b8@chalmers.se> <5b0a058d-b58c-4e73-a59b-24a40d59a3f1@chalmers.se> <68c6e7a91d354a35a08a6a89d181b9b6@hi-jena.gsi.de> <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de> <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de>, <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <6265a341aaa846559fc5932f9c0e0829@hi-jena.gsi.de> Message-ID: On Thu, 18 Jan 2024, Weber, Guenter Dr. wrote: > > Dear Hans, > > > there was some redirect burried in the script which executes scripts which > execute some more scripts?... and that made me start the DAQ in the old > folder, not the new one. Sorry for that. > > > I now came across the following line in the script which starts the VULOM: > > > $VULOM4_CTRL --addr=$addr --clear-setup --config=vulom.trlo standalone > module_trigger > > > Here I need to know the firmware number to define the path VULOM4_CTRL, > right? Is there a way to do this automatically? Somehow this works already > in the makefile of NURDLIB. It looks like this is done with this line in the nurdlib Makefile: VULOM4_FW:=$(shell cat $(TRLOII_PATH)/fw/vulom4b_trlo/trlo_defs.h 2>&1 | grep MD5SUM_STAMP | sed 's/.*0x//') such that something like VULOM4_FW=`cat $(TRLOII_PATH)/fw/vulom4b_trlo/trlo_defs.h 2>&1 | grep MD5SUM_STAMP | sed 's/.*0x//'` might work in a shell script, if TRLOII_PATH is set, and the fw/ directory exists and has the current gatewares. 'Funfact': This general mess with the TRLO II version numbers is of my creation, however a proper fix has so far required too much effort. Basically, the gateware would have to give info on the offsets and sizes of various controllable items (fairly easy), and the trloctrl program and functions would need to use that (much more complex - that it at all works is thanks to generation of many structures from that trlo_defs.h header, where some of them also intermix with the .trlo lexer/parser). > I would like to avoid to hard code this into the environment settings if > there is a way to figure it out on the fly. Cheers, H?kan > > > > Thanks so much! > > > > Best greetings > > G?nter > > > > > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von Hans > Toshihide T?rnqvist > Gesendet: Donnerstag, 18. Januar 2024 13:28:36 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr. > Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, > DRASI, etc. were updated ? > Dear G?nter, > > It looks like either the Vetar driver failed, or the fw/driver is old > and nurdlib expects a file that didn't exist a while back. If it's the > latter I can add a switch to ignore this file, it's not critical for > readout and is used to enter a faster readout mode. > > Which version of nurdlib is this? The files and line numbers don't match > with what I see in the source code, and the last time gsi_etherbone.c > changed was early last year. > > The message "Could not open so-and-so" should be for the device, e.g. > /dev/pcie_wb0. This is used for the readout. > > The dactl file should fail with "Failed dactl fopen". > > To summarise, I would suggest to make sure that the correct nurdlib and > r3bfuser are executed by the DAQ scripts. Meanwhile I will prepare a > switch to ignore the dactl file which could anyhow be useful for old > configurations, and to clean up the Etherbone error messages. > > Best regards, > Hans > > On 2024-01-18 11:29, Weber, Guenter Dr. wrote: > > Dear friends, > > > > > > I now started the DAQ and it looks like there is a problem with the > > VETAR2 module. Attached please find the output once the DAQ is started > > on the RIO4. > > > > > > Here ist the error message: > > > > > > 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866) > > 11: a:1: .Gsi Etherbone init_slow { > > (module/gsi_etherbone/gsi_etherbone.c:110) > > 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No > > such file or directory. > >? ?(module/gsi_etherbone/gsi_etherbone.c:120) > > 5: a:1: ..Calling exit(EXIT_FAILURE)... > > (module/gsi_etherbone/gsi_etherbone.c:120) > > > > How to proceed? > > > > > > > > Many thanks and best greetings > > G?nter > > > > > > > > > > ------------------------------------------------------------------------ > > *Von:* subexp-daq im Auftrag von > > H?kan T Johansson > > *Gesendet:* Dienstag, 16. Januar 2024 19:20:54 > > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > > TRLOII, DRASI, etc. were updated > > > > On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: > > > >> > >> Dear friends, > >> > >> > >> I am just trying to figure out how all the various scripts/commands work > >> together for setting up our DAQ system. Maybe, you can help to clearify > some > >> things. > >> > >> > >> > >> - master.bash > > > > This would be intended to run on the readout board (RIO).? The other > > scripts below is for the PC. > > > >> > >> source ../env/env.sh > >> ./trloii_setup.sh > >> # gdb --args \ > >> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ > >> ? ? ? ? --label=MCAL1 \ > >> ? ? ? ? --triva=master,fctime=10,ctime=50 \ > >> ? ? ? ? --log-no-rate-limit \ > >> ? ? ? ? --server=drasi,dest=lyserv \ > >> ? ? ? ? --buf=size=400Mi \ > >> ? ? ? ? --max-ev-size=0x1000000 \ > >> ? ? ? ? --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ > >> ? ? ? ? --eb=lyserv \ > >> ? ? ? ? "$@" > >> > >> In the first line some environment variables are set. The second line > tells > >> the VULOM4 how to operate (i. e. selection from modes of operation > defined > >> in vulom.trlo). Then DRASI is started with a bunch of parameters. Is > there > >> somewhere an explanation of the purpose of all these settings? > > > > The drasi command line options should be described here: > > > > http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html > > > > > > (Note: 'lyserv' is the name of your PC, at least as seen from the RIO.) > > > > The TRLO II setup file (vulom.trlo) is worse in terms of documentation. > > The format as such is hopefully rather straightforward.? A description is > > here: http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html > > . > > The actual meaning is more complex, the TRLO II description can be found > > here: > > > > http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html > > > > > > (left pane), which just is a colourised version of this: > > http://fy.chalmers.se/~f96hajo/trloii/description.txt > > > > > > It does not describe the .trlo file as such, but what the gateware tries > > to achieve. > > > >> And what is in the last line? I never came accross "$@" before. > > > > That would be all the (non-shifted, i.e. not removed) options given to the > > script itself, i.e. master.bash. > > > >> - eb.bash > >> > >> ../drasi/bin/lwrocmerge \ > >> > >> ? ? --label=MCAL_EB \ > >> ? ? --merge-mode=event \ > >> ? ? --server=trans,flush=1 \ > >> ? ? --server=stream,flush=1 \ > >> ? ? --buf=size=1600Mi \ > >> ? ? --max-ev-size=20Mi \ > >> ? ? --eb-master=rio4-mcal-1 \ > >> ? ? --file-writer \ > >> ? ? --drasi=rio4-mcal-1 > >> > >> What is the purpose of this command? > > > > This runs an 'event builder' on the PC.? Not strictly needed, but this > > way, the RIO only ever needs to send data once, to this event-builder > > (EB).? File writing, and streaming of on-line data is then handled by this > > process.? It is cheaper to have better network cards and so on in a plain > > PC. > > > >> Why are values for buffer size and max > >> event size different then in the command before? > > > > The nomenclaturure is unfortunately a bit convoluted below with ucesb > > regards 'buffer size'.? The --buf in the two commands above give the size > > of the memory used to buffer data inside the process, and depends on how > > much memory each machine has.? The --max-ev-size tells how large each .lmd > > event can be.? The --max-ev-size configured in the event builder needs to > > be as large as the sum of all event sources it has.? I.e. should be able > > to be the same as in your single source above. > > > > In the readout itself, any event that is read out cannot be larger than > > this.? If it is, then the DAQ will report a fatal failure. > > > >> - fanout.bash > >> > >> #!/bin/bash > >> while : > >> do > >> ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ > >> ? ? stream://localhost \ > >> ? ? --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 > >> sleep 5 > >> done??? > >> > >> This looks like setting up a connection point to the outside world, > right? > > > > Yes.? It accepts connections and will serve them data for online analysis. > > > > stream://localhost? tells it where to read data (here the PC itself where > > it is running).? Using the 'stream' protocol, which esentially is just raw > > LMD events.? (As is the 'transport protocol'.)? That will be served on the > > default port used for the stream server set up by the EB above. > > > > --server is then the server that accepts connections, and serves data on > > another port (8001). > > > >> And we find the third (random?) value for a buffer size. > > > > That bufsize is actually the LMD buffer size used by the stream server. > > The corresponding value in the readout and EB is set implicitly from the > > maximum event size... > > > >> - rate.bash > >> > >> ../drasi/bin/lwrocmon --rate rio4-mcal-1 > >> > >> Ok, this I understand. We can look the DAQ over the shoulder and see what > >> the thing is doing in terms of number of trigger events, transported > data, > >> etc. > > > >> - log.bash > >> > >> ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost > >> > >> This is also easy to understand. > > > > :-) > > > > Then also try to do (on the PC) > > > > drasi/bin/lwrocmon --tree rio4-mcal-1 localhost > > > > which would show a 'tree-view' monitoring of the running system. > > > > > > Cheers, > > H?kan > > > -- > subexp-daq mailing list > subexp-daq at lists.chalmers.se > https://lists.chalmers.se/mailman/listinfo/subexp-daq > > From g.weber at hi-jena.gsi.de Fri Jan 19 09:58:21 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Fri, 19 Jan 2024 08:58:21 +0000 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <222475cb-2ab6-4f4c-9bc0-d08a8b20a3cc@chalmers.se> <4e1e90ee-e985-42b2-a4e8-83f02d1c56b8@chalmers.se> <5b0a058d-b58c-4e73-a59b-24a40d59a3f1@chalmers.se> <68c6e7a91d354a35a08a6a89d181b9b6@hi-jena.gsi.de> <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de> <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de>, <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <6265a341aaa846559fc5932f9c0e0829@hi-jena.gsi.de>, Message-ID: Dear H?kan, dear Hans, it looks like the FW number that is identified is the wrong one. vulom_fw=`cat ${TRLOII_PATH}/fw/vulom4b_trlo/trlo_defs.h 2>&1 | grep MD5SUM_STAMP | sed 's/.*0x//'` export VULOM4_CTRL=$trloiipath/trloctrl/fw_${VULOM4_FW}_trlo/bin_${machine}_${version}/trlo_ctrl On my system this results in the following path: VULOM4_CTRL=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/bin_ppc-linux_4.2.2/trlo_ctrl But it is the wrong one. $VULOM4_CTRL --addr=$addr --clear-setup --config=vulom.trlo standalone module_trigger ./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 The right one would be: /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo/bin_ppc-linux_4.2.2/trlo_ctrl In the TRLO/TRLOCTRL folder there are also other firmware numbers (which redirect to 1409285e, as I understand), but d96ffc88 is not among them. Do you guys have an idea what the problem is? 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 ? Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Donnerstag, 18. Januar 2024 22:39:31 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated On Thu, 18 Jan 2024, Weber, Guenter Dr. wrote: > > Dear Hans, > > > there was some redirect burried in the script which executes scripts which > execute some more scripts ... and that made me start the DAQ in the old > folder, not the new one. Sorry for that. > > > I now came across the following line in the script which starts the VULOM: > > > $VULOM4_CTRL --addr=$addr --clear-setup --config=vulom.trlo standalone > module_trigger > > > Here I need to know the firmware number to define the path VULOM4_CTRL, > right? Is there a way to do this automatically? Somehow this works already > in the makefile of NURDLIB. It looks like this is done with this line in the nurdlib Makefile: VULOM4_FW:=$(shell cat $(TRLOII_PATH)/fw/vulom4b_trlo/trlo_defs.h 2>&1 | grep MD5SUM_STAMP | sed 's/.*0x//') such that something like VULOM4_FW=`cat $(TRLOII_PATH)/fw/vulom4b_trlo/trlo_defs.h 2>&1 | grep MD5SUM_STAMP | sed 's/.*0x//'` might work in a shell script, if TRLOII_PATH is set, and the fw/ directory exists and has the current gatewares. 'Funfact': This general mess with the TRLO II version numbers is of my creation, however a proper fix has so far required too much effort. Basically, the gateware would have to give info on the offsets and sizes of various controllable items (fairly easy), and the trloctrl program and functions would need to use that (much more complex - that it at all works is thanks to generation of many structures from that trlo_defs.h header, where some of them also intermix with the .trlo lexer/parser). > I would like to avoid to hard code this into the environment settings if > there is a way to figure it out on the fly. Cheers, H?kan > > > > Thanks so much! > > > > Best greetings > > G?nter > > > > > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von Hans > Toshihide T?rnqvist > Gesendet: Donnerstag, 18. Januar 2024 13:28:36 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr. > Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, > DRASI, etc. were updated > Dear G?nter, > > It looks like either the Vetar driver failed, or the fw/driver is old > and nurdlib expects a file that didn't exist a while back. If it's the > latter I can add a switch to ignore this file, it's not critical for > readout and is used to enter a faster readout mode. > > Which version of nurdlib is this? The files and line numbers don't match > with what I see in the source code, and the last time gsi_etherbone.c > changed was early last year. > > The message "Could not open so-and-so" should be for the device, e.g. > /dev/pcie_wb0. This is used for the readout. > > The dactl file should fail with "Failed dactl fopen". > > To summarise, I would suggest to make sure that the correct nurdlib and > r3bfuser are executed by the DAQ scripts. Meanwhile I will prepare a > switch to ignore the dactl file which could anyhow be useful for old > configurations, and to clean up the Etherbone error messages. > > Best regards, > Hans > > On 2024-01-18 11:29, Weber, Guenter Dr. wrote: > > Dear friends, > > > > > > I now started the DAQ and it looks like there is a problem with the > > VETAR2 module. Attached please find the output once the DAQ is started > > on the RIO4. > > > > > > Here ist the error message: > > > > > > 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866) > > 11: a:1: .Gsi Etherbone init_slow { > > (module/gsi_etherbone/gsi_etherbone.c:110) > > 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No > > such file or directory. > > (module/gsi_etherbone/gsi_etherbone.c:120) > > 5: a:1: ..Calling exit(EXIT_FAILURE)... > > (module/gsi_etherbone/gsi_etherbone.c:120) > > > > How to proceed? > > > > > > > > Many thanks and best greetings > > G?nter > > > > > > > > > > ------------------------------------------------------------------------ > > *Von:* subexp-daq im Auftrag von > > H?kan T Johansson > > *Gesendet:* Dienstag, 16. Januar 2024 19:20:54 > > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > > TRLOII, DRASI, etc. were updated > > > > On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: > > > >> > >> Dear friends, > >> > >> > >> I am just trying to figure out how all the various scripts/commands work > >> together for setting up our DAQ system. Maybe, you can help to clearify > some > >> things. > >> > >> > >> > >> - master.bash > > > > This would be intended to run on the readout board (RIO). The other > > scripts below is for the PC. > > > >> > >> source ../env/env.sh > >> ./trloii_setup.sh > >> # gdb --args \ > >> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ > >> --label=MCAL1 \ > >> --triva=master,fctime=10,ctime=50 \ > >> --log-no-rate-limit \ > >> --server=drasi,dest=lyserv \ > >> --buf=size=400Mi \ > >> --max-ev-size=0x1000000 \ > >> --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ > >> --eb=lyserv \ > >> "$@" > >> > >> In the first line some environment variables are set. The second line > tells > >> the VULOM4 how to operate (i. e. selection from modes of operation > defined > >> in vulom.trlo). Then DRASI is started with a bunch of parameters. Is > there > >> somewhere an explanation of the purpose of all these settings? > > > > The drasi command line options should be described here: > > > > http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html > > > > > > (Note: 'lyserv' is the name of your PC, at least as seen from the RIO.) > > > > The TRLO II setup file (vulom.trlo) is worse in terms of documentation. > > The format as such is hopefully rather straightforward. A description is > > here: http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html > > . > > The actual meaning is more complex, the TRLO II description can be found > > here: > > > > http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html > > > > > > (left pane), which just is a colourised version of this: > > http://fy.chalmers.se/~f96hajo/trloii/description.txt > > > > > > It does not describe the .trlo file as such, but what the gateware tries > > to achieve. > > > >> And what is in the last line? I never came accross "$@" before. > > > > That would be all the (non-shifted, i.e. not removed) options given to the > > script itself, i.e. master.bash. > > > >> - eb.bash > >> > >> ../drasi/bin/lwrocmerge \ > >> > >> --label=MCAL_EB \ > >> --merge-mode=event \ > >> --server=trans,flush=1 \ > >> --server=stream,flush=1 \ > >> --buf=size=1600Mi \ > >> --max-ev-size=20Mi \ > >> --eb-master=rio4-mcal-1 \ > >> --file-writer \ > >> --drasi=rio4-mcal-1 > >> > >> What is the purpose of this command? > > > > This runs an 'event builder' on the PC. Not strictly needed, but this > > way, the RIO only ever needs to send data once, to this event-builder > > (EB). File writing, and streaming of on-line data is then handled by this > > process. It is cheaper to have better network cards and so on in a plain > > PC. > > > >> Why are values for buffer size and max > >> event size different then in the command before? > > > > The nomenclaturure is unfortunately a bit convoluted below with ucesb > > regards 'buffer size'. The --buf in the two commands above give the size > > of the memory used to buffer data inside the process, and depends on how > > much memory each machine has. The --max-ev-size tells how large each .lmd > > event can be. The --max-ev-size configured in the event builder needs to > > be as large as the sum of all event sources it has. I.e. should be able > > to be the same as in your single source above. > > > > In the readout itself, any event that is read out cannot be larger than > > this. If it is, then the DAQ will report a fatal failure. > > > >> - fanout.bash > >> > >> #!/bin/bash > >> while : > >> do > >> ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ > >> stream://localhost \ > >> --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 > >> sleep 5 > >> done > >> > >> This looks like setting up a connection point to the outside world, > right? > > > > Yes. It accepts connections and will serve them data for online analysis. > > > > stream://localhost tells it where to read data (here the PC itself where > > it is running). Using the 'stream' protocol, which esentially is just raw > > LMD events. (As is the 'transport protocol'.) That will be served on the > > default port used for the stream server set up by the EB above. > > > > --server is then the server that accepts connections, and serves data on > > another port (8001). > > > >> And we find the third (random?) value for a buffer size. > > > > That bufsize is actually the LMD buffer size used by the stream server. > > The corresponding value in the readout and EB is set implicitly from the > > maximum event size... > > > >> - rate.bash > >> > >> ../drasi/bin/lwrocmon --rate rio4-mcal-1 > >> > >> Ok, this I understand. We can look the DAQ over the shoulder and see what > >> the thing is doing in terms of number of trigger events, transported > data, > >> etc. > > > >> - log.bash > >> > >> ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost > >> > >> This is also easy to understand. > > > > :-) > > > > Then also try to do (on the PC) > > > > drasi/bin/lwrocmon --tree rio4-mcal-1 localhost > > > > which would show a 'tree-view' monitoring of the running system. > > > > > > Cheers, > > H?kan > > > -- > 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: From g.weber at hi-jena.gsi.de Fri Jan 19 10:16:03 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Fri, 19 Jan 2024 09:16:03 +0000 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <222475cb-2ab6-4f4c-9bc0-d08a8b20a3cc@chalmers.se> <4e1e90ee-e985-42b2-a4e8-83f02d1c56b8@chalmers.se> <5b0a058d-b58c-4e73-a59b-24a40d59a3f1@chalmers.se> <68c6e7a91d354a35a08a6a89d181b9b6@hi-jena.gsi.de> <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de> <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de>, <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <6265a341aaa846559fc5932f9c0e0829@hi-jena.gsi.de>, , Message-ID: <7690a3d966894858981d085d7ddddd32@hi-jena.gsi.de> Sorry, please ignore my last e-mail. Now the automatic setting of the folder works. But there is a real problem after executing of the VULOM command. hwmap_mapvme.c:398: LOG: Virtual address for TRLO II @ VME 0x03000000 is 0x3005e000. LOG: TRLO: MD5SUM: 0x426cb99c (CT: 5bba6507 = 2018-10-07 19:56:55 UTC) WARNING: Known firmware (alias): 0x6e4ba1a9. WARNING: Known firmware (alias): 0x1409285e. WARNING: Known firmware (alias): 0xa73c5093. WARNING: Known firmware (alias): 0x6e4ba1a9. WARNING: Known firmware (alias): 0x1409285e. FATAL: TRLO firmware wrong: 0x426cb99c, expected 0x6e4ba1a9 or alias. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von Weber, Guenter Dr. Gesendet: Freitag, 19. Januar 2024 09:58:21 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated Dear H?kan, dear Hans, it looks like the FW number that is identified is the wrong one. vulom_fw=`cat ${TRLOII_PATH}/fw/vulom4b_trlo/trlo_defs.h 2>&1 | grep MD5SUM_STAMP | sed 's/.*0x//'` export VULOM4_CTRL=$trloiipath/trloctrl/fw_${VULOM4_FW}_trlo/bin_${machine}_${version}/trlo_ctrl On my system this results in the following path: VULOM4_CTRL=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/bin_ppc-linux_4.2.2/trlo_ctrl But it is the wrong one. $VULOM4_CTRL --addr=$addr --clear-setup --config=vulom.trlo standalone module_trigger ./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 The right one would be: /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo/bin_ppc-linux_4.2.2/trlo_ctrl In the TRLO/TRLOCTRL folder there are also other firmware numbers (which redirect to 1409285e, as I understand), but d96ffc88 is not among them. Do you guys have an idea what the problem is? 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 ? Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Donnerstag, 18. Januar 2024 22:39:31 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated On Thu, 18 Jan 2024, Weber, Guenter Dr. wrote: > > Dear Hans, > > > there was some redirect burried in the script which executes scripts which > execute some more scripts ... and that made me start the DAQ in the old > folder, not the new one. Sorry for that. > > > I now came across the following line in the script which starts the VULOM: > > > $VULOM4_CTRL --addr=$addr --clear-setup --config=vulom.trlo standalone > module_trigger > > > Here I need to know the firmware number to define the path VULOM4_CTRL, > right? Is there a way to do this automatically? Somehow this works already > in the makefile of NURDLIB. It looks like this is done with this line in the nurdlib Makefile: VULOM4_FW:=$(shell cat $(TRLOII_PATH)/fw/vulom4b_trlo/trlo_defs.h 2>&1 | grep MD5SUM_STAMP | sed 's/.*0x//') such that something like VULOM4_FW=`cat $(TRLOII_PATH)/fw/vulom4b_trlo/trlo_defs.h 2>&1 | grep MD5SUM_STAMP | sed 's/.*0x//'` might work in a shell script, if TRLOII_PATH is set, and the fw/ directory exists and has the current gatewares. 'Funfact': This general mess with the TRLO II version numbers is of my creation, however a proper fix has so far required too much effort. Basically, the gateware would have to give info on the offsets and sizes of various controllable items (fairly easy), and the trloctrl program and functions would need to use that (much more complex - that it at all works is thanks to generation of many structures from that trlo_defs.h header, where some of them also intermix with the .trlo lexer/parser). > I would like to avoid to hard code this into the environment settings if > there is a way to figure it out on the fly. Cheers, H?kan > > > > Thanks so much! > > > > Best greetings > > G?nter > > > > > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von Hans > Toshihide T?rnqvist > Gesendet: Donnerstag, 18. Januar 2024 13:28:36 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr. > Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, > DRASI, etc. were updated > Dear G?nter, > > It looks like either the Vetar driver failed, or the fw/driver is old > and nurdlib expects a file that didn't exist a while back. If it's the > latter I can add a switch to ignore this file, it's not critical for > readout and is used to enter a faster readout mode. > > Which version of nurdlib is this? The files and line numbers don't match > with what I see in the source code, and the last time gsi_etherbone.c > changed was early last year. > > The message "Could not open so-and-so" should be for the device, e.g. > /dev/pcie_wb0. This is used for the readout. > > The dactl file should fail with "Failed dactl fopen". > > To summarise, I would suggest to make sure that the correct nurdlib and > r3bfuser are executed by the DAQ scripts. Meanwhile I will prepare a > switch to ignore the dactl file which could anyhow be useful for old > configurations, and to clean up the Etherbone error messages. > > Best regards, > Hans > > On 2024-01-18 11:29, Weber, Guenter Dr. wrote: > > Dear friends, > > > > > > I now started the DAQ and it looks like there is a problem with the > > VETAR2 module. Attached please find the output once the DAQ is started > > on the RIO4. > > > > > > Here ist the error message: > > > > > > 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866) > > 11: a:1: .Gsi Etherbone init_slow { > > (module/gsi_etherbone/gsi_etherbone.c:110) > > 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No > > such file or directory. > > (module/gsi_etherbone/gsi_etherbone.c:120) > > 5: a:1: ..Calling exit(EXIT_FAILURE)... > > (module/gsi_etherbone/gsi_etherbone.c:120) > > > > How to proceed? > > > > > > > > Many thanks and best greetings > > G?nter > > > > > > > > > > ------------------------------------------------------------------------ > > *Von:* subexp-daq im Auftrag von > > H?kan T Johansson > > *Gesendet:* Dienstag, 16. Januar 2024 19:20:54 > > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > > TRLOII, DRASI, etc. were updated > > > > On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: > > > >> > >> Dear friends, > >> > >> > >> I am just trying to figure out how all the various scripts/commands work > >> together for setting up our DAQ system. Maybe, you can help to clearify > some > >> things. > >> > >> > >> > >> - master.bash > > > > This would be intended to run on the readout board (RIO). The other > > scripts below is for the PC. > > > >> > >> source ../env/env.sh > >> ./trloii_setup.sh > >> # gdb --args \ > >> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ > >> --label=MCAL1 \ > >> --triva=master,fctime=10,ctime=50 \ > >> --log-no-rate-limit \ > >> --server=drasi,dest=lyserv \ > >> --buf=size=400Mi \ > >> --max-ev-size=0x1000000 \ > >> --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ > >> --eb=lyserv \ > >> "$@" > >> > >> In the first line some environment variables are set. The second line > tells > >> the VULOM4 how to operate (i. e. selection from modes of operation > defined > >> in vulom.trlo). Then DRASI is started with a bunch of parameters. Is > there > >> somewhere an explanation of the purpose of all these settings? > > > > The drasi command line options should be described here: > > > > http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html > > > > > > (Note: 'lyserv' is the name of your PC, at least as seen from the RIO.) > > > > The TRLO II setup file (vulom.trlo) is worse in terms of documentation. > > The format as such is hopefully rather straightforward. A description is > > here: http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html > > . > > The actual meaning is more complex, the TRLO II description can be found > > here: > > > > http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html > > > > > > (left pane), which just is a colourised version of this: > > http://fy.chalmers.se/~f96hajo/trloii/description.txt > > > > > > It does not describe the .trlo file as such, but what the gateware tries > > to achieve. > > > >> And what is in the last line? I never came accross "$@" before. > > > > That would be all the (non-shifted, i.e. not removed) options given to the > > script itself, i.e. master.bash. > > > >> - eb.bash > >> > >> ../drasi/bin/lwrocmerge \ > >> > >> --label=MCAL_EB \ > >> --merge-mode=event \ > >> --server=trans,flush=1 \ > >> --server=stream,flush=1 \ > >> --buf=size=1600Mi \ > >> --max-ev-size=20Mi \ > >> --eb-master=rio4-mcal-1 \ > >> --file-writer \ > >> --drasi=rio4-mcal-1 > >> > >> What is the purpose of this command? > > > > This runs an 'event builder' on the PC. Not strictly needed, but this > > way, the RIO only ever needs to send data once, to this event-builder > > (EB). File writing, and streaming of on-line data is then handled by this > > process. It is cheaper to have better network cards and so on in a plain > > PC. > > > >> Why are values for buffer size and max > >> event size different then in the command before? > > > > The nomenclaturure is unfortunately a bit convoluted below with ucesb > > regards 'buffer size'. The --buf in the two commands above give the size > > of the memory used to buffer data inside the process, and depends on how > > much memory each machine has. The --max-ev-size tells how large each .lmd > > event can be. The --max-ev-size configured in the event builder needs to > > be as large as the sum of all event sources it has. I.e. should be able > > to be the same as in your single source above. > > > > In the readout itself, any event that is read out cannot be larger than > > this. If it is, then the DAQ will report a fatal failure. > > > >> - fanout.bash > >> > >> #!/bin/bash > >> while : > >> do > >> ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ > >> stream://localhost \ > >> --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 > >> sleep 5 > >> done > >> > >> This looks like setting up a connection point to the outside world, > right? > > > > Yes. It accepts connections and will serve them data for online analysis. > > > > stream://localhost tells it where to read data (here the PC itself where > > it is running). Using the 'stream' protocol, which esentially is just raw > > LMD events. (As is the 'transport protocol'.) That will be served on the > > default port used for the stream server set up by the EB above. > > > > --server is then the server that accepts connections, and serves data on > > another port (8001). > > > >> And we find the third (random?) value for a buffer size. > > > > That bufsize is actually the LMD buffer size used by the stream server. > > The corresponding value in the readout and EB is set implicitly from the > > maximum event size... > > > >> - rate.bash > >> > >> ../drasi/bin/lwrocmon --rate rio4-mcal-1 > >> > >> Ok, this I understand. We can look the DAQ over the shoulder and see what > >> the thing is doing in terms of number of trigger events, transported > data, > >> etc. > > > >> - log.bash > >> > >> ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost > >> > >> This is also easy to understand. > > > > :-) > > > > Then also try to do (on the PC) > > > > drasi/bin/lwrocmon --tree rio4-mcal-1 localhost > > > > which would show a 'tree-view' monitoring of the running system. > > > > > > Cheers, > > H?kan > > > -- > 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: From g.weber at hi-jena.gsi.de Fri Jan 19 10:34:49 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Fri, 19 Jan 2024 09:34:49 +0000 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <7690a3d966894858981d085d7ddddd32@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <222475cb-2ab6-4f4c-9bc0-d08a8b20a3cc@chalmers.se> <4e1e90ee-e985-42b2-a4e8-83f02d1c56b8@chalmers.se> <5b0a058d-b58c-4e73-a59b-24a40d59a3f1@chalmers.se> <68c6e7a91d354a35a08a6a89d181b9b6@hi-jena.gsi.de> <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de> <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de>, <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <6265a341aaa846559fc5932f9c0e0829@hi-jena.gsi.de>, , , <7690a3d966894858981d085d7ddddd32@hi-jena.gsi.de> Message-ID: <094c7f8eaf4c48d295594e7afdfa3f45@hi-jena.gsi.de> P.S. Maybe this information helps: RIO4-MCAL-1 mbsdaq > vulomflash --addr=3 --readprogs VULOM base address: 0x03000000 hwmap_mapvme.c:398: LOG: Virtual address for VULOM/TRIDI @ VME 0x03000000 is 0x3005e000. Performing command 'readprogs'... ========================================================================= Rng 0: TRLO II ver/vulom4b_trlo 2018-10-07 21:56:55 ( 9.486ns) 426cb99c Rng 1: TRLO II ver/vulom4b_trlo 2018-10-07 21:56:55 ( 9.486ns) 426cb99c Rng 2: N/A Rng 3: N/A Rng 4: N/A Rng 5: N/A Rng 6: N/A Rng 7: N/A ========================================================================= Released vme ptr. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von Weber, Guenter Dr. Gesendet: Freitag, 19. Januar 2024 10:16:03 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated Sorry, please ignore my last e-mail. Now the automatic setting of the folder works. But there is a real problem after executing of the VULOM command. hwmap_mapvme.c:398: LOG: Virtual address for TRLO II @ VME 0x03000000 is 0x3005e000. LOG: TRLO: MD5SUM: 0x426cb99c (CT: 5bba6507 = 2018-10-07 19:56:55 UTC) WARNING: Known firmware (alias): 0x6e4ba1a9. WARNING: Known firmware (alias): 0x1409285e. WARNING: Known firmware (alias): 0xa73c5093. WARNING: Known firmware (alias): 0x6e4ba1a9. WARNING: Known firmware (alias): 0x1409285e. FATAL: TRLO firmware wrong: 0x426cb99c, expected 0x6e4ba1a9 or alias. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von Weber, Guenter Dr. Gesendet: Freitag, 19. Januar 2024 09:58:21 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated Dear H?kan, dear Hans, it looks like the FW number that is identified is the wrong one. vulom_fw=`cat ${TRLOII_PATH}/fw/vulom4b_trlo/trlo_defs.h 2>&1 | grep MD5SUM_STAMP | sed 's/.*0x//'` export VULOM4_CTRL=$trloiipath/trloctrl/fw_${VULOM4_FW}_trlo/bin_${machine}_${version}/trlo_ctrl On my system this results in the following path: VULOM4_CTRL=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc88_trlo/bin_ppc-linux_4.2.2/trlo_ctrl But it is the wrong one. $VULOM4_CTRL --addr=$addr --clear-setup --config=vulom.trlo standalone module_trigger ./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 The right one would be: /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_1409285e_trlo/bin_ppc-linux_4.2.2/trlo_ctrl In the TRLO/TRLOCTRL folder there are also other firmware numbers (which redirect to 1409285e, as I understand), but d96ffc88 is not among them. Do you guys have an idea what the problem is? 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 ? Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Donnerstag, 18. Januar 2024 22:39:31 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated On Thu, 18 Jan 2024, Weber, Guenter Dr. wrote: > > Dear Hans, > > > there was some redirect burried in the script which executes scripts which > execute some more scripts ... and that made me start the DAQ in the old > folder, not the new one. Sorry for that. > > > I now came across the following line in the script which starts the VULOM: > > > $VULOM4_CTRL --addr=$addr --clear-setup --config=vulom.trlo standalone > module_trigger > > > Here I need to know the firmware number to define the path VULOM4_CTRL, > right? Is there a way to do this automatically? Somehow this works already > in the makefile of NURDLIB. It looks like this is done with this line in the nurdlib Makefile: VULOM4_FW:=$(shell cat $(TRLOII_PATH)/fw/vulom4b_trlo/trlo_defs.h 2>&1 | grep MD5SUM_STAMP | sed 's/.*0x//') such that something like VULOM4_FW=`cat $(TRLOII_PATH)/fw/vulom4b_trlo/trlo_defs.h 2>&1 | grep MD5SUM_STAMP | sed 's/.*0x//'` might work in a shell script, if TRLOII_PATH is set, and the fw/ directory exists and has the current gatewares. 'Funfact': This general mess with the TRLO II version numbers is of my creation, however a proper fix has so far required too much effort. Basically, the gateware would have to give info on the offsets and sizes of various controllable items (fairly easy), and the trloctrl program and functions would need to use that (much more complex - that it at all works is thanks to generation of many structures from that trlo_defs.h header, where some of them also intermix with the .trlo lexer/parser). > I would like to avoid to hard code this into the environment settings if > there is a way to figure it out on the fly. Cheers, H?kan > > > > Thanks so much! > > > > Best greetings > > G?nter > > > > > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von Hans > Toshihide T?rnqvist > Gesendet: Donnerstag, 18. Januar 2024 13:28:36 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr. > Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, > DRASI, etc. were updated > Dear G?nter, > > It looks like either the Vetar driver failed, or the fw/driver is old > and nurdlib expects a file that didn't exist a while back. If it's the > latter I can add a switch to ignore this file, it's not critical for > readout and is used to enter a faster readout mode. > > Which version of nurdlib is this? The files and line numbers don't match > with what I see in the source code, and the last time gsi_etherbone.c > changed was early last year. > > The message "Could not open so-and-so" should be for the device, e.g. > /dev/pcie_wb0. This is used for the readout. > > The dactl file should fail with "Failed dactl fopen". > > To summarise, I would suggest to make sure that the correct nurdlib and > r3bfuser are executed by the DAQ scripts. Meanwhile I will prepare a > switch to ignore the dactl file which could anyhow be useful for old > configurations, and to clean up the Etherbone error messages. > > Best regards, > Hans > > On 2024-01-18 11:29, Weber, Guenter Dr. wrote: > > Dear friends, > > > > > > I now started the DAQ and it looks like there is a problem with the > > VETAR2 module. Attached please find the output once the DAQ is started > > on the RIO4. > > > > > > Here ist the error message: > > > > > > 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866) > > 11: a:1: .Gsi Etherbone init_slow { > > (module/gsi_etherbone/gsi_etherbone.c:110) > > 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No > > such file or directory. > > (module/gsi_etherbone/gsi_etherbone.c:120) > > 5: a:1: ..Calling exit(EXIT_FAILURE)... > > (module/gsi_etherbone/gsi_etherbone.c:120) > > > > How to proceed? > > > > > > > > Many thanks and best greetings > > G?nter > > > > > > > > > > ------------------------------------------------------------------------ > > *Von:* subexp-daq im Auftrag von > > H?kan T Johansson > > *Gesendet:* Dienstag, 16. Januar 2024 19:20:54 > > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > > TRLOII, DRASI, etc. were updated > > > > On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: > > > >> > >> Dear friends, > >> > >> > >> I am just trying to figure out how all the various scripts/commands work > >> together for setting up our DAQ system. Maybe, you can help to clearify > some > >> things. > >> > >> > >> > >> - master.bash > > > > This would be intended to run on the readout board (RIO). The other > > scripts below is for the PC. > > > >> > >> source ../env/env.sh > >> ./trloii_setup.sh > >> # gdb --args \ > >> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ > >> --label=MCAL1 \ > >> --triva=master,fctime=10,ctime=50 \ > >> --log-no-rate-limit \ > >> --server=drasi,dest=lyserv \ > >> --buf=size=400Mi \ > >> --max-ev-size=0x1000000 \ > >> --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ > >> --eb=lyserv \ > >> "$@" > >> > >> In the first line some environment variables are set. The second line > tells > >> the VULOM4 how to operate (i. e. selection from modes of operation > defined > >> in vulom.trlo). Then DRASI is started with a bunch of parameters. Is > there > >> somewhere an explanation of the purpose of all these settings? > > > > The drasi command line options should be described here: > > > > http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html > > > > > > (Note: 'lyserv' is the name of your PC, at least as seen from the RIO.) > > > > The TRLO II setup file (vulom.trlo) is worse in terms of documentation. > > The format as such is hopefully rather straightforward. A description is > > here: http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html > > . > > The actual meaning is more complex, the TRLO II description can be found > > here: > > > > http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html > > > > > > (left pane), which just is a colourised version of this: > > http://fy.chalmers.se/~f96hajo/trloii/description.txt > > > > > > It does not describe the .trlo file as such, but what the gateware tries > > to achieve. > > > >> And what is in the last line? I never came accross "$@" before. > > > > That would be all the (non-shifted, i.e. not removed) options given to the > > script itself, i.e. master.bash. > > > >> - eb.bash > >> > >> ../drasi/bin/lwrocmerge \ > >> > >> --label=MCAL_EB \ > >> --merge-mode=event \ > >> --server=trans,flush=1 \ > >> --server=stream,flush=1 \ > >> --buf=size=1600Mi \ > >> --max-ev-size=20Mi \ > >> --eb-master=rio4-mcal-1 \ > >> --file-writer \ > >> --drasi=rio4-mcal-1 > >> > >> What is the purpose of this command? > > > > This runs an 'event builder' on the PC. Not strictly needed, but this > > way, the RIO only ever needs to send data once, to this event-builder > > (EB). File writing, and streaming of on-line data is then handled by this > > process. It is cheaper to have better network cards and so on in a plain > > PC. > > > >> Why are values for buffer size and max > >> event size different then in the command before? > > > > The nomenclaturure is unfortunately a bit convoluted below with ucesb > > regards 'buffer size'. The --buf in the two commands above give the size > > of the memory used to buffer data inside the process, and depends on how > > much memory each machine has. The --max-ev-size tells how large each .lmd > > event can be. The --max-ev-size configured in the event builder needs to > > be as large as the sum of all event sources it has. I.e. should be able > > to be the same as in your single source above. > > > > In the readout itself, any event that is read out cannot be larger than > > this. If it is, then the DAQ will report a fatal failure. > > > >> - fanout.bash > >> > >> #!/bin/bash > >> while : > >> do > >> ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ > >> stream://localhost \ > >> --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 > >> sleep 5 > >> done > >> > >> This looks like setting up a connection point to the outside world, > right? > > > > Yes. It accepts connections and will serve them data for online analysis. > > > > stream://localhost tells it where to read data (here the PC itself where > > it is running). Using the 'stream' protocol, which esentially is just raw > > LMD events. (As is the 'transport protocol'.) That will be served on the > > default port used for the stream server set up by the EB above. > > > > --server is then the server that accepts connections, and serves data on > > another port (8001). > > > >> And we find the third (random?) value for a buffer size. > > > > That bufsize is actually the LMD buffer size used by the stream server. > > The corresponding value in the readout and EB is set implicitly from the > > maximum event size... > > > >> - rate.bash > >> > >> ../drasi/bin/lwrocmon --rate rio4-mcal-1 > >> > >> Ok, this I understand. We can look the DAQ over the shoulder and see what > >> the thing is doing in terms of number of trigger events, transported > data, > >> etc. > > > >> - log.bash > >> > >> ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost > >> > >> This is also easy to understand. > > > > :-) > > > > Then also try to do (on the PC) > > > > drasi/bin/lwrocmon --tree rio4-mcal-1 localhost > > > > which would show a 'tree-view' monitoring of the running system. > > > > > > Cheers, > > H?kan > > > -- > 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: From f96hajo at chalmers.se Fri Jan 19 11:29:14 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Fri, 19 Jan 2024 11:29:14 +0100 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <094c7f8eaf4c48d295594e7afdfa3f45@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <5b0a058d-b58c-4e73-a59b-24a40d59a3f1@chalmers.se> <68c6e7a91d354a35a08a6a89d181b9b6@hi-jena.gsi.de> <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de> <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de>, <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <6265a341aaa846559fc5932f9c0e0829@hi-jena.gsi.de>, , , <7690a3d966894858981d085d7ddddd32@hi-jena.gsi.de> <094c7f8eaf4c48d295594e7afdfa3f45@hi-jena.gsi.de> Message-ID: Dear G?nter, yes, the gateware running on the VULOM is an older version, so not the one that trloctrl etc. has now been compiled with. Could you use vulomflash to --prog the new firmware e.g. to range 2, and then restart from that. See the instructions at the end of the attached file. Cheers, H?kan On Fri, 19 Jan 2024, Weber, Guenter Dr. wrote: > > P.S. > > > Maybe this information helps: > > > RIO4-MCAL-1 mbsdaq > vulomflash --addr=3 --readprogs > VULOM base address: 0x03000000 > hwmap_mapvme.c:398: LOG: Virtual address for VULOM/TRIDI @ VME 0x03000000 is > 0x3005e000. > Performing command 'readprogs'... > ========================================================================= > Rng 0: TRLO II? ver/vulom4b_trlo? ? ? ? 2018-10-07 21:56:55 ( 9.486ns) > 426cb99c > Rng 1: TRLO II? ver/vulom4b_trlo? ? ? ? 2018-10-07 21:56:55 ( 9.486ns) > 426cb99c > Rng 2: N/A > Rng 3: N/A > Rng 4: N/A > Rng 5: N/A > Rng 6: N/A > Rng 7: N/A > ========================================================================= > Released vme ptr. > > > Best greetings > > G?nter > > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von Weber, > Guenter Dr. > Gesendet: Freitag, 19. Januar 2024 10:16:03 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, > DRASI, etc. were updated ? > > Sorry, please ignore my last e-mail. > > > Now the automatic setting of the folder works. > > > But ?there is a real problem after executing of the VULOM command. > > > hwmap_mapvme.c:398: LOG: Virtual address for TRLO II @ VME 0x03000000 is > 0x3005e000. > LOG: TRLO: MD5SUM: 0x426cb99c (CT: 5bba6507 = 2018-10-07 19:56:55 UTC) > WARNING: Known firmware (alias): 0x6e4ba1a9. > WARNING: Known firmware (alias): 0x1409285e. > WARNING: Known firmware (alias): 0xa73c5093. > WARNING: Known firmware (alias): 0x6e4ba1a9. > WARNING: Known firmware (alias): 0x1409285e. > FATAL: TRLO firmware wrong: 0x426cb99c, expected 0x6e4ba1a9 or alias. > > > > Best greetings > > G?nter > > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von Weber, > Guenter Dr. > Gesendet: Freitag, 19. Januar 2024 09:58:21 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, > DRASI, etc. were updated ? > > Dear?H?kan, dear Hans, > > > it looks like the FW number that is identified is the wrong one. > > > vulom_fw=`cat ${TRLOII_PATH}/fw/vulom4b_trlo/trlo_defs.h 2>&1 | grep > MD5SUM_STAMP | sed 's/.*0x//'` > exportVULOM4_CTRL=$trloiipath/trloctrl/fw_${VULOM4_FW}_trlo/bin_${machine}_${vers > ion}/trlo_ctrl > > On my system this results in the following path: > > > VULOM4_CTRL=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloct > rl/fw_d96ffc88_trlo/bin_ppc-linux_4.2.2/trlo_ctrl > > > But it is the wrong one. > > > $VULOM4_CTRL --addr=$addr --clear-setup --config=vulom.trlo standalone > module_trigger > > ./trloii_setup.sh: line 12:/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc > 88_trlo/bin_ppc-linux_4.2.2/trlo_ctrl: No such file or directory > > > The right one would be: > > > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_140928 > 5e_trlo/bin_ppc-linux_4.2.2/trlo_ctrl > > > In the TRLO/TRLOCTRL folder there are also other firmware numbers (which > redirect to 1409285e, as I understand), but d96ffc88 is not among them. > > Do you guys have an idea what the problem is? > > 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 ? > > > > Best greetings > G?nter > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan > T Johansson > Gesendet: Donnerstag, 18. Januar 2024 22:39:31 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, > DRASI, etc. were updated ? > > On Thu, 18 Jan 2024, Weber, Guenter Dr. wrote: > > > > > Dear Hans, > > > > > > there was some redirect burried in the script which executes scripts which > > execute some more scripts?... and that made me start the DAQ in the old > > folder, not the new one. Sorry for that. > > > > > > I now came across the following line in the script which starts the VULOM: > > > > > > $VULOM4_CTRL --addr=$addr --clear-setup --config=vulom.trlo standalone > > module_trigger > > > > > > Here I need to know the firmware number to define the path VULOM4_CTRL, > > right? Is there a way to do this automatically? Somehow this works already > > in the makefile of NURDLIB. > > It looks like this is done with this line in the nurdlib Makefile: > > ??? VULOM4_FW:=$(shell cat $(TRLOII_PATH)/fw/vulom4b_trlo/trlo_defs.h 2>&1 | > grep MD5SUM_STAMP | sed 's/.*0x//') > > such that something like > > ??? VULOM4_FW=`cat $(TRLOII_PATH)/fw/vulom4b_trlo/trlo_defs.h 2>&1 | grep > MD5SUM_STAMP | sed 's/.*0x//'` > > might work in a shell script, if TRLOII_PATH is set, and the fw/ directory > exists and has the current gatewares. > > 'Funfact': This general mess with the TRLO II version numbers is of my > creation, however a proper fix has so far required too much effort. > Basically, the gateware would have to give info on the offsets and sizes > of various controllable items (fairly easy), and the trloctrl program and > functions would need to use that (much more complex - that it at all works > is thanks to generation of many structures from that trlo_defs.h header, > where some of them also intermix with the .trlo lexer/parser). > > > I would like to avoid to hard code this into the environment settings if > > there is a way to figure it out on the fly. > > Cheers, > H?kan > > > > > > > > > > > Thanks so much! > > > > > > > > Best greetings > > > > G?nter > > > > > > > > > > > > > >___________________________________________________________________________ > _ > > Von: subexp-daq im Auftrag von Hans > > Toshihide T?rnqvist > > Gesendet: Donnerstag, 18. Januar 2024 13:28:36 > > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr. > > Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, > > DRASI, etc. were updated ? > > Dear G?nter, > > > > It looks like either the Vetar driver failed, or the fw/driver is old > > and nurdlib expects a file that didn't exist a while back. If it's the > > latter I can add a switch to ignore this file, it's not critical for > > readout and is used to enter a faster readout mode. > > > > Which version of nurdlib is this? The files and line numbers don't match > > with what I see in the source code, and the last time gsi_etherbone.c > > changed was early last year. > > > > The message "Could not open so-and-so" should be for the device, e.g. > > /dev/pcie_wb0. This is used for the readout. > > > > The dactl file should fail with "Failed dactl fopen". > > > > To summarise, I would suggest to make sure that the correct nurdlib and > > r3bfuser are executed by the DAQ scripts. Meanwhile I will prepare a > > switch to ignore the dactl file which could anyhow be useful for old > > configurations, and to clean up the Etherbone error messages. > > > > Best regards, > > Hans > > > > On 2024-01-18 11:29, Weber, Guenter Dr. wrote: > > > Dear friends, > > > > > > > > > I now started the DAQ and it looks like there is a problem with the > > > VETAR2 module. Attached please find the output once the DAQ is started > > > on the RIO4. > > > > > > > > > Here ist the error message: > > > > > > > > > 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866) > > > 11: a:1: .Gsi Etherbone init_slow { > > > (module/gsi_etherbone/gsi_etherbone.c:110) > > > 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No > > > such file or directory. > > >? ?(module/gsi_etherbone/gsi_etherbone.c:120) > > > 5: a:1: ..Calling exit(EXIT_FAILURE)... > > > (module/gsi_etherbone/gsi_etherbone.c:120) > > > > > > How to proceed? > > > > > > > > > > > > Many thanks and best greetings > > > G?nter > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > *Von:* subexp-daq im Auftrag von > > > H?kan T Johansson > > > *Gesendet:* Dienstag, 16. Januar 2024 19:20:54 > > > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > > > TRLOII, DRASI, etc. were updated > > > > > > On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: > > > > > >> > > >> Dear friends, > > >> > > >> > > >> I am just trying to figure out how all the various scripts/commands > work > > >> together for setting up our DAQ system. Maybe, you can help to clearify > > some > > >> things. > > >> > > >> > > >> > > >> - master.bash > > > > > > This would be intended to run on the readout board (RIO).? The other > > > scripts below is for the PC. > > > > > >> > > >> source ../env/env.sh > > >> ./trloii_setup.sh > > >> # gdb --args \ > > >> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ > > >> ? ? ? ? --label=MCAL1 \ > > >> ? ? ? ? --triva=master,fctime=10,ctime=50 \ > > >> ? ? ? ? --log-no-rate-limit \ > > >> ? ? ? ? --server=drasi,dest=lyserv \ > > >> ? ? ? ? --buf=size=400Mi \ > > >> ? ? ? ? --max-ev-size=0x1000000 \ > > >> ? ? ? ? --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ > > >> ? ? ? ? --eb=lyserv \ > > >> ? ? ? ? "$@" > > >> > > >> In the first line some environment variables are set. The second line > > tells > > >> the VULOM4 how to operate (i. e. selection from modes of operation > > defined > > >> in vulom.trlo). Then DRASI is started with a bunch of parameters. Is > > there > > >> somewhere an explanation of the purpose of all these settings? > > > > > > The drasi command line options should be described here: > > > > > > http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html > > > > > > > > > (Note: 'lyserv' is the name of your PC, at least as seen from the RIO.) > > > > > > The TRLO II setup file (vulom.trlo) is worse in terms of documentation. > > > The format as such is hopefully rather straightforward.? A description > is > > > here: http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html > > > . > > > The actual meaning is more complex, the TRLO II description can be found > > > here: > > > > > > http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html > > > > > > > > > > (left pane), which just is a colourised version of this: > > > http://fy.chalmers.se/~f96hajo/trloii/description.txt > > > > > > > > > It does not describe the .trlo file as such, but what the gateware tries > > > to achieve. > > > > > >> And what is in the last line? I never came accross "$@" before. > > > > > > That would be all the (non-shifted, i.e. not removed) options given to > the > > > script itself, i.e. master.bash. > > > > > >> - eb.bash > > >> > > >> ../drasi/bin/lwrocmerge \ > > >> > > >> ? ? --label=MCAL_EB \ > > >> ? ? --merge-mode=event \ > > >> ? ? --server=trans,flush=1 \ > > >> ? ? --server=stream,flush=1 \ > > >> ? ? --buf=size=1600Mi \ > > >> ? ? --max-ev-size=20Mi \ > > >> ? ? --eb-master=rio4-mcal-1 \ > > >> ? ? --file-writer \ > > >> ? ? --drasi=rio4-mcal-1 > > >> > > >> What is the purpose of this command? > > > > > > This runs an 'event builder' on the PC.? Not strictly needed, but this > > > way, the RIO only ever needs to send data once, to this event-builder > > > (EB).? File writing, and streaming of on-line data is then handled by > this > > > process.? It is cheaper to have better network cards and so on in a > plain > > > PC. > > > > > >> Why are values for buffer size and max > > >> event size different then in the command before? > > > > > > The nomenclaturure is unfortunately a bit convoluted below with ucesb > > > regards 'buffer size'.? The --buf in the two commands above give the > size > > > of the memory used to buffer data inside the process, and depends on how > > > much memory each machine has.? The --max-ev-size tells how large each > .lmd > > > event can be.? The --max-ev-size configured in the event builder needs > to > > > be as large as the sum of all event sources it has.? I.e. should be able > > > to be the same as in your single source above. > > > > > > In the readout itself, any event that is read out cannot be larger than > > > this.? If it is, then the DAQ will report a fatal failure. > > > > > >> - fanout.bash > > >> > > >> #!/bin/bash > > >> while : > > >> do > > >> ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ > > >> ? ? stream://localhost \ > > >> ? ? --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 > > >> sleep 5 > > >> done??? > > >> > > >> This looks like setting up a connection point to the outside world, > > right? > > > > > > Yes.? It accepts connections and will serve them data for online > analysis. > > > > > > stream://localhost? tells it where to read data (here the PC itself > where > > > it is running).? Using the 'stream' protocol, which esentially is just > raw > > > LMD events.? (As is the 'transport protocol'.)? That will be served on > the > > > default port used for the stream server set up by the EB above. > > > > > > --server is then the server that accepts connections, and serves data on > > > another port (8001). > > > > > >> And we find the third (random?) value for a buffer size. > > > > > > That bufsize is actually the LMD buffer size used by the stream server. > > > The corresponding value in the readout and EB is set implicitly from the > > > maximum event size... > > > > > >> - rate.bash > > >> > > >> ../drasi/bin/lwrocmon --rate rio4-mcal-1 > > >> > > >> Ok, this I understand. We can look the DAQ over the shoulder and see > what > > >> the thing is doing in terms of number of trigger events, transported > > data, > > >> etc. > > > > > >> - log.bash > > >> > > >> ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost > > >> > > >> This is also easy to understand. > > > > > > :-) > > > > > > Then also try to do (on the PC) > > > > > > drasi/bin/lwrocmon --tree rio4-mcal-1 localhost > > > > > > which would show a 'tree-view' monitoring of the running system. > > > > > > > > > Cheers, > > > H?kan > > > > > -- > > subexp-daq mailing list > > subexp-daq at lists.chalmers.se > > https://lists.chalmers.se/mailman/listinfo/subexp-daq > > > > > > -------------- next part -------------- ###################################################################### MYDAQ=/path/to/daq mkdir -p $MYDAQ cd $MYDAQ git clone git at gitlab.com:chalmers-subexp/nurdlib.git git clone git at gitlab.com:chalmers-subexp/trloii.git git clone git at gitlab.com:chalmers-subexp/r3bfuser.git git clone git at git.chalmers.se:expsubphys/drasi.git git clone git at git.chalmers.se:expsubphys/ucesb.git ###################################################################### # Download TRLO II gatewares and unpack (on PC): cd $MYDAQ/trloii wget http://fy.chalmers.se/~f96hajo/trloii/trloii_firmwares_f13d071c.tar.gz tar -zxvf trloii_firmwares_f13d071c.tar.gz ###################################################################### cd $MYDAQ/trloii # Workarounds (in case of compile issues below): # In trloii/Makefile: Partially comment out line 3: proglinks # trigalign_dir # In trloii/trloctrl/trlolib/src/trlo_setup_parser.y: Comment out line 60: /* %define parse.error verbose */ ###################################################################### # Build (PC, then VME board). cd $MYDAQ/trloii make cd trloctrl ./find_firmwares.pl make fw_1409285e_trlo_build # choose the vulom4b trlo ## cd $MYDAQ/drasi make ## cd $MYDAQ/nurdlib make ## cd $MYDAQ/r3bfuser make drasi ###################################################################### ## Build (PC only). cd $MYDAQ/ucesb make empty ###################################################################### # Testing and upgrading TRLO II gateware (on VME board): ADDR=XX # Address selectors on VULOM4(b) board cd $MYDAQ/trloii # List gatewares in the 8 flash regions: bin/vulomflash --addr=$ADDR --readprogs # See which gateware is currently running (Look for output on line # VOLUM+0 => 0xZZZZ1f20, ZZZZ is four first hex digits of identifier.) bin/vulomflash --addr=$ADDR --read # Restart FPGA with gateware from region N: bin/vulomflash --addr=$ADDR --restart=N # Write a (new) gateware image to region N, N _not_ 0: bin/vulomflash --addr=$ADDR --prog=N fw/vulom4b_trlo/vlogic_4b.rbt # Then check that it works: bin/vulomflash --addr=$ADDR --restart=N bin/vulomflash --addr=$ADDR --read # Also use with a DAQ before writing to region 0, which is loaded on # cold start. If region 0 image is bad, it may jam the VME bus and # prevent re-programming. (--restart=N can be used after cold start.) ## # Just using the trlo_ctrl to talk to the module. # Without any argument, shall respond with two lines, second # contain identifier and gateware synthesis time. trloctrl/fw_1409285e_trlo/bin_ppc-.../trlo_ctrl --addr=$ADDR ###################################################################### From g.weber at hi-jena.gsi.de Fri Jan 19 12:03:11 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Fri, 19 Jan 2024 11:03:11 +0000 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <5b0a058d-b58c-4e73-a59b-24a40d59a3f1@chalmers.se> <68c6e7a91d354a35a08a6a89d181b9b6@hi-jena.gsi.de> <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de> <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de>, <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <6265a341aaa846559fc5932f9c0e0829@hi-jena.gsi.de>, , , <7690a3d966894858981d085d7ddddd32@hi-jena.gsi.de> <094c7f8eaf4c48d295594e7afdfa3f45@hi-jena.gsi.de>, Message-ID: Dear , looks like the firmware is now updated: RIO4-MCAL-1 mbsdaq > vulomflash --addr=3 --read VULOM base address: 0x03000000 hwmap_mapvme.c:398: LOG: Virtual address for VULOM/TRIDI @ VME 0x03000000 is 0x3005e000. Performing command 'read'... VOLUM+0 => 0x14091f20 VOLUM+RANGE_REG(0x800000) => 0x0000006a Released vme ptr. RIO4-MCAL-1 mbsdaq > vulomflash --addr=3 --readprogs VULOM base address: 0x03000000 hwmap_mapvme.c:398: LOG: Virtual address for VULOM/TRIDI @ VME 0x03000000 is 0x3005e000. Performing command 'readprogs'... ========================================================================= Rng 0: TRLO II ver/vulom4b_trlo 2018-10-07 21:56:55 ( 9.486ns) 426cb99c Rng 1: TRLO II ver/vulom4b_trlo 2018-10-07 21:56:55 ( 9.486ns) 426cb99c Rng 2: TRLO II ver/vulom4b_trlo 2023-01-08 20:45:08 ( 9.499ns) 1409285e Rng 3: N/A Rng 4: N/A Rng 5: N/A Rng 6: N/A Rng 7: N/A ========================================================================= Released vme ptr. Now starting the VULOM does work, but there seems to be an incompatibility with the vulom.trlo file, right? hwmap_mapvme.c:398: LOG: Virtual address for TRLO II @ VME 0x03000000 is 0x3005e000. LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) Clear module setup. Loading config file 'vulom.trlo'. vulom.trlo:15: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:16: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:17: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:23: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:24: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:31: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:33: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:34: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:39: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:40: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:41: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:47: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:50: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:51: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:52: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:53: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:57: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:59: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:64: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:66: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:77: WARNING: Use of deprecated signal assignment '=', use '=>'. vulom.trlo:80: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:81: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:84: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:87: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:99: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:104: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:109: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:110: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:122: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:128: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:129: WARNING: Use of deprecated signal assignment '=', use '<='. Executing 'standalone'. vulom.trlo:41: FATAL: MUX dest 'FRONT_LED' index (3) out of bounds (<= 2). I think, I have send you the file yesterday. Could you have a look at it? Thank you so much! Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Freitag, 19. Januar 2024 11:29:14 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated Dear G?nter, yes, the gateware running on the VULOM is an older version, so not the one that trloctrl etc. has now been compiled with. Could you use vulomflash to --prog the new firmware e.g. to range 2, and then restart from that. See the instructions at the end of the attached file. Cheers, H?kan On Fri, 19 Jan 2024, Weber, Guenter Dr. wrote: > > P.S. > > > Maybe this information helps: > > > RIO4-MCAL-1 mbsdaq > vulomflash --addr=3 --readprogs > VULOM base address: 0x03000000 > hwmap_mapvme.c:398: LOG: Virtual address for VULOM/TRIDI @ VME 0x03000000 is > 0x3005e000. > Performing command 'readprogs'... > ========================================================================= > Rng 0: TRLO II ver/vulom4b_trlo 2018-10-07 21:56:55 ( 9.486ns) > 426cb99c > Rng 1: TRLO II ver/vulom4b_trlo 2018-10-07 21:56:55 ( 9.486ns) > 426cb99c > Rng 2: N/A > Rng 3: N/A > Rng 4: N/A > Rng 5: N/A > Rng 6: N/A > Rng 7: N/A > ========================================================================= > Released vme ptr. > > > Best greetings > > G?nter > > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von Weber, > Guenter Dr. > Gesendet: Freitag, 19. Januar 2024 10:16:03 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, > DRASI, etc. were updated > > Sorry, please ignore my last e-mail. > > > Now the automatic setting of the folder works. > > > But there is a real problem after executing of the VULOM command. > > > hwmap_mapvme.c:398: LOG: Virtual address for TRLO II @ VME 0x03000000 is > 0x3005e000. > LOG: TRLO: MD5SUM: 0x426cb99c (CT: 5bba6507 = 2018-10-07 19:56:55 UTC) > WARNING: Known firmware (alias): 0x6e4ba1a9. > WARNING: Known firmware (alias): 0x1409285e. > WARNING: Known firmware (alias): 0xa73c5093. > WARNING: Known firmware (alias): 0x6e4ba1a9. > WARNING: Known firmware (alias): 0x1409285e. > FATAL: TRLO firmware wrong: 0x426cb99c, expected 0x6e4ba1a9 or alias. > > > > Best greetings > > G?nter > > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von Weber, > Guenter Dr. > Gesendet: Freitag, 19. Januar 2024 09:58:21 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, > DRASI, etc. were updated > > Dear H?kan, dear Hans, > > > it looks like the FW number that is identified is the wrong one. > > > vulom_fw=`cat ${TRLOII_PATH}/fw/vulom4b_trlo/trlo_defs.h 2>&1 | grep > MD5SUM_STAMP | sed 's/.*0x//'` > exportVULOM4_CTRL=$trloiipath/trloctrl/fw_${VULOM4_FW}_trlo/bin_${machine}_${vers > ion}/trlo_ctrl > > On my system this results in the following path: > > > VULOM4_CTRL=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloct > rl/fw_d96ffc88_trlo/bin_ppc-linux_4.2.2/trlo_ctrl > > > But it is the wrong one. > > > $VULOM4_CTRL --addr=$addr --clear-setup --config=vulom.trlo standalone > module_trigger > > ./trloii_setup.sh: line 12:/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc > 88_trlo/bin_ppc-linux_4.2.2/trlo_ctrl: No such file or directory > > > The right one would be: > > > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_140928 > 5e_trlo/bin_ppc-linux_4.2.2/trlo_ctrl > > > In the TRLO/TRLOCTRL folder there are also other firmware numbers (which > redirect to 1409285e, as I understand), but d96ffc88 is not among them. > > Do you guys have an idea what the problem is? > > 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 ? > > > > Best greetings > G?nter > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan > T Johansson > Gesendet: Donnerstag, 18. Januar 2024 22:39:31 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, > DRASI, etc. were updated > > On Thu, 18 Jan 2024, Weber, Guenter Dr. wrote: > > > > > Dear Hans, > > > > > > there was some redirect burried in the script which executes scripts which > > execute some more scripts ... and that made me start the DAQ in the old > > folder, not the new one. Sorry for that. > > > > > > I now came across the following line in the script which starts the VULOM: > > > > > > $VULOM4_CTRL --addr=$addr --clear-setup --config=vulom.trlo standalone > > module_trigger > > > > > > Here I need to know the firmware number to define the path VULOM4_CTRL, > > right? Is there a way to do this automatically? Somehow this works already > > in the makefile of NURDLIB. > > It looks like this is done with this line in the nurdlib Makefile: > > VULOM4_FW:=$(shell cat $(TRLOII_PATH)/fw/vulom4b_trlo/trlo_defs.h 2>&1 | > grep MD5SUM_STAMP | sed 's/.*0x//') > > such that something like > > VULOM4_FW=`cat $(TRLOII_PATH)/fw/vulom4b_trlo/trlo_defs.h 2>&1 | grep > MD5SUM_STAMP | sed 's/.*0x//'` > > might work in a shell script, if TRLOII_PATH is set, and the fw/ directory > exists and has the current gatewares. > > 'Funfact': This general mess with the TRLO II version numbers is of my > creation, however a proper fix has so far required too much effort. > Basically, the gateware would have to give info on the offsets and sizes > of various controllable items (fairly easy), and the trloctrl program and > functions would need to use that (much more complex - that it at all works > is thanks to generation of many structures from that trlo_defs.h header, > where some of them also intermix with the .trlo lexer/parser). > > > I would like to avoid to hard code this into the environment settings if > > there is a way to figure it out on the fly. > > Cheers, > H?kan > > > > > > > > > > > Thanks so much! > > > > > > > > Best greetings > > > > G?nter > > > > > > > > > > > > > >___________________________________________________________________________ > _ > > Von: subexp-daq im Auftrag von Hans > > Toshihide T?rnqvist > > Gesendet: Donnerstag, 18. Januar 2024 13:28:36 > > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr. > > Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, > > DRASI, etc. were updated > > Dear G?nter, > > > > It looks like either the Vetar driver failed, or the fw/driver is old > > and nurdlib expects a file that didn't exist a while back. If it's the > > latter I can add a switch to ignore this file, it's not critical for > > readout and is used to enter a faster readout mode. > > > > Which version of nurdlib is this? The files and line numbers don't match > > with what I see in the source code, and the last time gsi_etherbone.c > > changed was early last year. > > > > The message "Could not open so-and-so" should be for the device, e.g. > > /dev/pcie_wb0. This is used for the readout. > > > > The dactl file should fail with "Failed dactl fopen". > > > > To summarise, I would suggest to make sure that the correct nurdlib and > > r3bfuser are executed by the DAQ scripts. Meanwhile I will prepare a > > switch to ignore the dactl file which could anyhow be useful for old > > configurations, and to clean up the Etherbone error messages. > > > > Best regards, > > Hans > > > > On 2024-01-18 11:29, Weber, Guenter Dr. wrote: > > > Dear friends, > > > > > > > > > I now started the DAQ and it looks like there is a problem with the > > > VETAR2 module. Attached please find the output once the DAQ is started > > > on the RIO4. > > > > > > > > > Here ist the error message: > > > > > > > > > 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866) > > > 11: a:1: .Gsi Etherbone init_slow { > > > (module/gsi_etherbone/gsi_etherbone.c:110) > > > 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No > > > such file or directory. > > > (module/gsi_etherbone/gsi_etherbone.c:120) > > > 5: a:1: ..Calling exit(EXIT_FAILURE)... > > > (module/gsi_etherbone/gsi_etherbone.c:120) > > > > > > How to proceed? > > > > > > > > > > > > Many thanks and best greetings > > > G?nter > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > *Von:* subexp-daq im Auftrag von > > > H?kan T Johansson > > > *Gesendet:* Dienstag, 16. Januar 2024 19:20:54 > > > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > > > TRLOII, DRASI, etc. were updated > > > > > > On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: > > > > > >> > > >> Dear friends, > > >> > > >> > > >> I am just trying to figure out how all the various scripts/commands > work > > >> together for setting up our DAQ system. Maybe, you can help to clearify > > some > > >> things. > > >> > > >> > > >> > > >> - master.bash > > > > > > This would be intended to run on the readout board (RIO). The other > > > scripts below is for the PC. > > > > > >> > > >> source ../env/env.sh > > >> ./trloii_setup.sh > > >> # gdb --args \ > > >> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ > > >> --label=MCAL1 \ > > >> --triva=master,fctime=10,ctime=50 \ > > >> --log-no-rate-limit \ > > >> --server=drasi,dest=lyserv \ > > >> --buf=size=400Mi \ > > >> --max-ev-size=0x1000000 \ > > >> --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ > > >> --eb=lyserv \ > > >> "$@" > > >> > > >> In the first line some environment variables are set. The second line > > tells > > >> the VULOM4 how to operate (i. e. selection from modes of operation > > defined > > >> in vulom.trlo). Then DRASI is started with a bunch of parameters. Is > > there > > >> somewhere an explanation of the purpose of all these settings? > > > > > > The drasi command line options should be described here: > > > > > > http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html > > > > > > > > > (Note: 'lyserv' is the name of your PC, at least as seen from the RIO.) > > > > > > The TRLO II setup file (vulom.trlo) is worse in terms of documentation. > > > The format as such is hopefully rather straightforward. A description > is > > > here: http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html > > > . > > > The actual meaning is more complex, the TRLO II description can be found > > > here: > > > > > > http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html > > > > > > > > > > (left pane), which just is a colourised version of this: > > > http://fy.chalmers.se/~f96hajo/trloii/description.txt > > > > > > > > > It does not describe the .trlo file as such, but what the gateware tries > > > to achieve. > > > > > >> And what is in the last line? I never came accross "$@" before. > > > > > > That would be all the (non-shifted, i.e. not removed) options given to > the > > > script itself, i.e. master.bash. > > > > > >> - eb.bash > > >> > > >> ../drasi/bin/lwrocmerge \ > > >> > > >> --label=MCAL_EB \ > > >> --merge-mode=event \ > > >> --server=trans,flush=1 \ > > >> --server=stream,flush=1 \ > > >> --buf=size=1600Mi \ > > >> --max-ev-size=20Mi \ > > >> --eb-master=rio4-mcal-1 \ > > >> --file-writer \ > > >> --drasi=rio4-mcal-1 > > >> > > >> What is the purpose of this command? > > > > > > This runs an 'event builder' on the PC. Not strictly needed, but this > > > way, the RIO only ever needs to send data once, to this event-builder > > > (EB). File writing, and streaming of on-line data is then handled by > this > > > process. It is cheaper to have better network cards and so on in a > plain > > > PC. > > > > > >> Why are values for buffer size and max > > >> event size different then in the command before? > > > > > > The nomenclaturure is unfortunately a bit convoluted below with ucesb > > > regards 'buffer size'. The --buf in the two commands above give the > size > > > of the memory used to buffer data inside the process, and depends on how > > > much memory each machine has. The --max-ev-size tells how large each > .lmd > > > event can be. The --max-ev-size configured in the event builder needs > to > > > be as large as the sum of all event sources it has. I.e. should be able > > > to be the same as in your single source above. > > > > > > In the readout itself, any event that is read out cannot be larger than > > > this. If it is, then the DAQ will report a fatal failure. > > > > > >> - fanout.bash > > >> > > >> #!/bin/bash > > >> while : > > >> do > > >> ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ > > >> stream://localhost \ > > >> --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 > > >> sleep 5 > > >> done > > >> > > >> This looks like setting up a connection point to the outside world, > > right? > > > > > > Yes. It accepts connections and will serve them data for online > analysis. > > > > > > stream://localhost tells it where to read data (here the PC itself > where > > > it is running). Using the 'stream' protocol, which esentially is just > raw > > > LMD events. (As is the 'transport protocol'.) That will be served on > the > > > default port used for the stream server set up by the EB above. > > > > > > --server is then the server that accepts connections, and serves data on > > > another port (8001). > > > > > >> And we find the third (random?) value for a buffer size. > > > > > > That bufsize is actually the LMD buffer size used by the stream server. > > > The corresponding value in the readout and EB is set implicitly from the > > > maximum event size... > > > > > >> - rate.bash > > >> > > >> ../drasi/bin/lwrocmon --rate rio4-mcal-1 > > >> > > >> Ok, this I understand. We can look the DAQ over the shoulder and see > what > > >> the thing is doing in terms of number of trigger events, transported > > data, > > >> etc. > > > > > >> - log.bash > > >> > > >> ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost > > >> > > >> This is also easy to understand. > > > > > > :-) > > > > > > Then also try to do (on the PC) > > > > > > drasi/bin/lwrocmon --tree rio4-mcal-1 localhost > > > > > > which would show a 'tree-view' monitoring of the running system. > > > > > > > > > Cheers, > > > H?kan > > > > > -- > > 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: From hans.tornqvist at chalmers.se Fri Jan 19 12:21:24 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Fri, 19 Jan 2024 12:21:24 +0100 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de> <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <6265a341aaa846559fc5932f9c0e0829@hi-jena.gsi.de> <7690a3d966894858981d085d7ddddd32@hi-jena.gsi.de> <094c7f8eaf4c48d295594e7afdfa3f45@hi-jena.gsi.de> Message-ID: <08471ed7-3fa4-4277-95c5-4cca7bd5a66e@chalmers.se> Dear G?nter, It looks like the *.trlo files just need to be synced according to updates in recent years. The change from '=' to '<=' was done to differentiate the kinds of assignments in the config. From a quick look at the first three errors, "a = b" would simply be "a <= b" instead and I'm guessing it's the same for the rest. At some point the vulom gateware had support for more front LED's. Comment one out and keep the LED index in the range [1,2]. Best regards, Hans On 2024-01-19 12:03, Weber, Guenter Dr. wrote: > Dear , > > > looks like the firmware is now updated: > > > RIO4-MCAL-1 mbsdaq > vulomflash --addr=3 --read > VULOM base address: 0x03000000 > hwmap_mapvme.c:398: LOG: Virtual address for VULOM/TRIDI @ VME > 0x03000000 is 0x3005e000. > Performing command 'read'... > VOLUM+0 => 0x14091f20 > VOLUM+RANGE_REG(0x800000) => 0x0000006a > Released vme ptr. > RIO4-MCAL-1 mbsdaq > vulomflash --addr=3 --readprogs > VULOM base address: 0x03000000 > hwmap_mapvme.c:398: LOG: Virtual address for VULOM/TRIDI @ VME > 0x03000000 is 0x3005e000. > Performing command 'readprogs'... > ========================================================================= > Rng 0: TRLO II? ver/vulom4b_trlo? ? ? ? 2018-10-07 21:56:55 ( 9.486ns) > 426cb99c > Rng 1: TRLO II? ver/vulom4b_trlo? ? ? ? 2018-10-07 21:56:55 ( 9.486ns) > 426cb99c > Rng 2: TRLO II? ver/vulom4b_trlo? ? ? ? 2023-01-08 20:45:08 ( 9.499ns) > 1409285e > Rng 3: N/A > Rng 4: N/A > Rng 5: N/A > Rng 6: N/A > Rng 7: N/A > ========================================================================= > Released vme ptr. > > Now starting the VULOM does work, but there seems to be an > incompatibility with the vulom.trlo file, right? > > > hwmap_mapvme.c:398: LOG: Virtual address for TRLO II @ VME 0x03000000 is > 0x3005e000. > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) > Clear module setup. > Loading config file 'vulom.trlo'. > vulom.trlo:15: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:16: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:17: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:23: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:24: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:31: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:33: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:34: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:39: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:40: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:41: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:47: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:50: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:51: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:52: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:53: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:57: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:59: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:64: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:66: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:77: WARNING: Use of deprecated signal assignment '=', use '=>'. > vulom.trlo:80: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:81: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:84: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:87: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:99: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:104: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:109: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:110: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:122: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:128: WARNING: Use of deprecated signal assignment '=', use '<='. > vulom.trlo:129: WARNING: Use of deprecated signal assignment '=', use '<='. > Executing 'standalone'. > vulom.trlo:41: FATAL: MUX dest 'FRONT_LED' index (3) out of bounds (<= 2). > > > I think, I have send you the file yesterday. Could you have a look at it? > > > > Thank you so much! > > > > > Best greetings > > G?nter > > > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > H?kan T Johansson > *Gesendet:* Freitag, 19. Januar 2024 11:29:14 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > TRLOII, DRASI, etc. were updated > > Dear G?nter, > > yes, the gateware running on the VULOM is an older version, so not the one > that trloctrl etc. has now been compiled with.? Could you use vulomflash > to --prog the new firmware e.g. to range 2, and then restart from that. > See the instructions at the end of the attached file. > > Cheers, > H?kan > > > > > On Fri, 19 Jan 2024, Weber, Guenter Dr. wrote: > >> >> P.S. >> >> >> Maybe this information helps: >> >> >> RIO4-MCAL-1 mbsdaq > vulomflash --addr=3 --readprogs >> VULOM base address: 0x03000000 >> hwmap_mapvme.c:398: LOG: Virtual address for VULOM/TRIDI @ VME 0x03000000 is >> 0x3005e000. >> Performing command 'readprogs'... >> ========================================================================= >> Rng 0: TRLO II? ver/vulom4b_trlo? ? ? ? 2018-10-07 21:56:55 ( 9.486ns) >> 426cb99c >> Rng 1: TRLO II? ver/vulom4b_trlo? ? ? ? 2018-10-07 21:56:55 ( 9.486ns) >> 426cb99c >> Rng 2: N/A >> Rng 3: N/A >> Rng 4: N/A >> Rng 5: N/A >> Rng 6: N/A >> Rng 7: N/A >> ========================================================================= >> Released vme ptr. >> >> >> Best greetings >> >> G?nter >> >> >> >> ____________________________________________________________________________ >> Von: subexp-daq im Auftrag von Weber, >> Guenter Dr. >> Gesendet: Freitag, 19. Januar 2024 10:16:03 >> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, >> DRASI, etc. were updated >> >> Sorry, please ignore my last e-mail. >> >> >> Now the automatic setting of the folder works. >> >> >> But ?there is a real problem after executing of the VULOM command. >> >> >> hwmap_mapvme.c:398: LOG: Virtual address for TRLO II @ VME 0x03000000 is >> 0x3005e000. >> LOG: TRLO: MD5SUM: 0x426cb99c (CT: 5bba6507 = 2018-10-07 19:56:55 UTC) >> WARNING: Known firmware (alias): 0x6e4ba1a9. >> WARNING: Known firmware (alias): 0x1409285e. >> WARNING: Known firmware (alias): 0xa73c5093. >> WARNING: Known firmware (alias): 0x6e4ba1a9. >> WARNING: Known firmware (alias): 0x1409285e. >> FATAL: TRLO firmware wrong: 0x426cb99c, expected 0x6e4ba1a9 or alias. >> >> >> >> Best greetings >> >> G?nter >> >> >> >> ____________________________________________________________________________ >> Von: subexp-daq im Auftrag von Weber, >> Guenter Dr. >> Gesendet: Freitag, 19. Januar 2024 09:58:21 >> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, >> DRASI, etc. were updated >> >> Dear?H?kan, dear Hans, >> >> >> it looks like the FW number that is identified is the wrong one. >> >> >> vulom_fw=`cat ${TRLOII_PATH}/fw/vulom4b_trlo/trlo_defs.h 2>&1 | grep >> MD5SUM_STAMP | sed 's/.*0x//'` >> exportVULOM4_CTRL=$trloiipath/trloctrl/fw_${VULOM4_FW}_trlo/bin_${machine}_${vers >> ion}/trlo_ctrl >> >> On my system this results in the following path: >> >> >> VULOM4_CTRL=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloct >> rl/fw_d96ffc88_trlo/bin_ppc-linux_4.2.2/trlo_ctrl >> >> >> But it is the wrong one. >> >> >> $VULOM4_CTRL --addr=$addr --clear-setup --config=vulom.trlo standalone >> module_trigger >> >> ./trloii_setup.sh: line 12:/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc >> 88_trlo/bin_ppc-linux_4.2.2/trlo_ctrl: No such file or directory >> >> >> The right one would be: >> >> >> /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_140928 >> 5e_trlo/bin_ppc-linux_4.2.2/trlo_ctrl >> >> >> In the TRLO/TRLOCTRL folder there are also other firmware numbers (which >> redirect to 1409285e, as I understand), but d96ffc88 is not among them. >> >> Do you guys have an idea what the problem is? >> >> 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 ? >> >> >> >> Best greetings >> G?nter >> >> ____________________________________________________________________________ >> Von: subexp-daq im Auftrag von H?kan >> T Johansson >> Gesendet: Donnerstag, 18. Januar 2024 22:39:31 >> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, >> DRASI, etc. were updated >> >> On Thu, 18 Jan 2024, Weber, Guenter Dr. wrote: >> >> > >> > Dear Hans, >> > >> > >> > there was some redirect burried in the script which executes scripts which >> > execute some more scripts?... and that made me start the DAQ in the old >> > folder, not the new one. Sorry for that. >> > >> > >> > I now came across the following line in the script which starts the VULOM: >> > >> > >> > $VULOM4_CTRL --addr=$addr --clear-setup --config=vulom.trlo standalone >> > module_trigger >> > >> > >> > Here I need to know the firmware number to define the path VULOM4_CTRL, >> > right? Is there a way to do this automatically? Somehow this works already >> > in the makefile of NURDLIB. >> >> It looks like this is done with this line in the nurdlib Makefile: >> >> ??? VULOM4_FW:=$(shell cat $(TRLOII_PATH)/fw/vulom4b_trlo/trlo_defs.h 2>&1 | >> grep MD5SUM_STAMP | sed 's/.*0x//') >> >> such that something like >> >> ??? VULOM4_FW=`cat $(TRLOII_PATH)/fw/vulom4b_trlo/trlo_defs.h 2>&1 | grep >> MD5SUM_STAMP | sed 's/.*0x//'` >> >> might work in a shell script, if TRLOII_PATH is set, and the fw/ directory >> exists and has the current gatewares. >> >> 'Funfact': This general mess with the TRLO II version numbers is of my >> creation, however a proper fix has so far required too much effort. >> Basically, the gateware would have to give info on the offsets and sizes >> of various controllable items (fairly easy), and the trloctrl program and >> functions would need to use that (much more complex - that it at all works >> is thanks to generation of many structures from that trlo_defs.h header, >> where some of them also intermix with the .trlo lexer/parser). >> >> > I would like to avoid to hard code this into the environment settings if >> > there is a way to figure it out on the fly. >> >> Cheers, >> H?kan >> >> >> >> > >> > >> > >> > Thanks so much! >> > >> > >> > >> > Best greetings >> > >> > G?nter >> > >> > >> > >> > >> > >> > >> >___________________________________________________________________________ >> _ >> > Von: subexp-daq im Auftrag von Hans >> > Toshihide T?rnqvist >> > Gesendet: Donnerstag, 18. Januar 2024 13:28:36 >> > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr. >> > Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, >> > DRASI, etc. were updated >> > Dear G?nter, >> > >> > It looks like either the Vetar driver failed, or the fw/driver is old >> > and nurdlib expects a file that didn't exist a while back. If it's the >> > latter I can add a switch to ignore this file, it's not critical for >> > readout and is used to enter a faster readout mode. >> > >> > Which version of nurdlib is this? The files and line numbers don't match >> > with what I see in the source code, and the last time gsi_etherbone.c >> > changed was early last year. >> > >> > The message "Could not open so-and-so" should be for the device, e.g. >> > /dev/pcie_wb0. This is used for the readout. >> > >> > The dactl file should fail with "Failed dactl fopen". >> > >> > To summarise, I would suggest to make sure that the correct nurdlib and >> > r3bfuser are executed by the DAQ scripts. Meanwhile I will prepare a >> > switch to ignore the dactl file which could anyhow be useful for old >> > configurations, and to clean up the Etherbone error messages. >> > >> > Best regards, >> > Hans >> > >> > On 2024-01-18 11:29, Weber, Guenter Dr. wrote: >> > > Dear friends, >> > > >> > > >> > > I now started the DAQ and it looks like there is a problem with the >> > > VETAR2 module. Attached please find the output once the DAQ is started >> > > on the RIO4. >> > > >> > > >> > > Here ist the error message: >> > > >> > > >> > > 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866) >> > > 11: a:1: .Gsi Etherbone init_slow { >> > > (module/gsi_etherbone/gsi_etherbone.c:110) >> > > 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No >> > > such file or directory. >> > >? ?(module/gsi_etherbone/gsi_etherbone.c:120) >> > > 5: a:1: ..Calling exit(EXIT_FAILURE)... >> > > (module/gsi_etherbone/gsi_etherbone.c:120) >> > > >> > > How to proceed? >> > > >> > > >> > > >> > > Many thanks and best greetings >> > > G?nter >> > > >> > > >> > > >> > > >> > > ------------------------------------------------------------------------ >> > > *Von:* subexp-daq im Auftrag von >> > > H?kan T Johansson >> > > *Gesendet:* Dienstag, 16. Januar 2024 19:20:54 >> > > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> > > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >> > > TRLOII, DRASI, etc. were updated >> > > >> > > On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: >> > > >> > >> >> > >> Dear friends, >> > >> >> > >> >> > >> I am just trying to figure out how all the various scripts/commands >> work >> > >> together for setting up our DAQ system. Maybe, you can help to clearify >> > some >> > >> things. >> > >> >> > >> >> > >> >> > >> - master.bash >> > > >> > > This would be intended to run on the readout board (RIO).? The other >> > > scripts below is for the PC. >> > > >> > >> >> > >> source ../env/env.sh >> > >> ./trloii_setup.sh >> > >> # gdb --args \ >> > >> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ >> > >> ? ? ? ? --label=MCAL1 \ >> > >> ? ? ? ? --triva=master,fctime=10,ctime=50 \ >> > >> ? ? ? ? --log-no-rate-limit \ >> > >> ? ? ? ? --server=drasi,dest=lyserv \ >> > >> ? ? ? ? --buf=size=400Mi \ >> > >> ? ? ? ? --max-ev-size=0x1000000 \ >> > >> ? ? ? ? --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ >> > >> ? ? ? ? --eb=lyserv \ >> > >> ? ? ? ? "$@" >> > >> >> > >> In the first line some environment variables are set. The second line >> > tells >> > >> the VULOM4 how to operate (i. e. selection from modes of operation >> > defined >> > >> in vulom.trlo). Then DRASI is started with a bunch of parameters. Is >> > there >> > >> somewhere an explanation of the purpose of all these settings? >> > > >> > > The drasi command line options should be described here: >> > > >> > > http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html > >> > > > >> > > >> > > (Note: 'lyserv' is the name of your PC, at least as seen from the RIO.) >> > > >> > > The TRLO II setup file (vulom.trlo) is worse in terms of documentation. >> > > The format as such is hopefully rather straightforward.? A description >> is >> > > here: http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html > >> > > > . >> > > The actual meaning is more complex, the TRLO II description can be found >> > > here: >> > > >> > > http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html > >> > > >> > >> > > >> > > (left pane), which just is a colourised version of this: >> > > http://fy.chalmers.se/~f96hajo/trloii/description.txt > >> > > > >> > > >> > > It does not describe the .trlo file as such, but what the gateware tries >> > > to achieve. >> > > >> > >> And what is in the last line? I never came accross "$@" before. >> > > >> > > That would be all the (non-shifted, i.e. not removed) options given to >> the >> > > script itself, i.e. master.bash. >> > > >> > >> - eb.bash >> > >> >> > >> ../drasi/bin/lwrocmerge \ >> > >> >> > >> ? ? --label=MCAL_EB \ >> > >> ? ? --merge-mode=event \ >> > >> ? ? --server=trans,flush=1 \ >> > >> ? ? --server=stream,flush=1 \ >> > >> ? ? --buf=size=1600Mi \ >> > >> ? ? --max-ev-size=20Mi \ >> > >> ? ? --eb-master=rio4-mcal-1 \ >> > >> ? ? --file-writer \ >> > >> ? ? --drasi=rio4-mcal-1 >> > >> >> > >> What is the purpose of this command? >> > > >> > > This runs an 'event builder' on the PC.? Not strictly needed, but this >> > > way, the RIO only ever needs to send data once, to this event-builder >> > > (EB).? File writing, and streaming of on-line data is then handled by >> this >> > > process.? It is cheaper to have better network cards and so on in a >> plain >> > > PC. >> > > >> > >> Why are values for buffer size and max >> > >> event size different then in the command before? >> > > >> > > The nomenclaturure is unfortunately a bit convoluted below with ucesb >> > > regards 'buffer size'.? The --buf in the two commands above give the >> size >> > > of the memory used to buffer data inside the process, and depends on how >> > > much memory each machine has.? The --max-ev-size tells how large each >> .lmd >> > > event can be.? The --max-ev-size configured in the event builder needs >> to >> > > be as large as the sum of all event sources it has.? I.e. should be able >> > > to be the same as in your single source above. >> > > >> > > In the readout itself, any event that is read out cannot be larger than >> > > this.? If it is, then the DAQ will report a fatal failure. >> > > >> > >> - fanout.bash >> > >> >> > >> #!/bin/bash >> > >> while : >> > >> do >> > >> ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ >> > >> ? ? stream://localhost \ >> > >> ? ? --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 >> > >> sleep 5 >> > >> done >> > >> >> > >> This looks like setting up a connection point to the outside world, >> > right? >> > > >> > > Yes.? It accepts connections and will serve them data for online >> analysis. >> > > >> > > stream://localhost? tells it where to read data (here the PC itself >> where >> > > it is running).? Using the 'stream' protocol, which esentially is just >> raw >> > > LMD events.? (As is the 'transport protocol'.)? That will be served on >> the >> > > default port used for the stream server set up by the EB above. >> > > >> > > --server is then the server that accepts connections, and serves data on >> > > another port (8001). >> > > >> > >> And we find the third (random?) value for a buffer size. >> > > >> > > That bufsize is actually the LMD buffer size used by the stream server. >> > > The corresponding value in the readout and EB is set implicitly from the >> > > maximum event size... >> > > >> > >> - rate.bash >> > >> >> > >> ../drasi/bin/lwrocmon --rate rio4-mcal-1 >> > >> >> > >> Ok, this I understand. We can look the DAQ over the shoulder and see >> what >> > >> the thing is doing in terms of number of trigger events, transported >> > data, >> > >> etc. >> > > >> > >> - log.bash >> > >> >> > >> ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost >> > >> >> > >> This is also easy to understand. >> > > >> > > :-) >> > > >> > > Then also try to do (on the PC) >> > > >> > > drasi/bin/lwrocmon --tree rio4-mcal-1 localhost >> > > >> > > which would show a 'tree-view' monitoring of the running system. >> > > >> > > >> > > Cheers, >> > > H?kan >> > > >> > -- >> > subexp-daq mailing list >> > subexp-daq at lists.chalmers.se >> > https://lists.chalmers.se/mailman/listinfo/subexp-daq > >> > >> > >> >> > From f96hajo at chalmers.se Fri Jan 19 12:25:22 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Fri, 19 Jan 2024 12:25:22 +0100 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <08471ed7-3fa4-4277-95c5-4cca7bd5a66e@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de> <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <6265a341aaa846559fc5932f9c0e0829@hi-jena.gsi.de> <7690a3d966894858981d085d7ddddd32@hi-jena.gsi.de> <094c7f8eaf4c48d295594e7afdfa3f45@hi-jena.gsi.de> <08471ed7-3fa4-4277-95c5-4cca7bd5a66e@chalmers.se> Message-ID: <331b70bb-5881-2132-222c-ff711eb69b61@chalmers.se> Dear G?nter, please find attached a new version of your .trlo file with the assignments modified to not generate warnings, and the setting of FRONT_LED(3) commented out (it is only for diagnostics, so would not make a difference). Best regards, H?kan On Fri, 19 Jan 2024, Hans Toshihide T?rnqvist wrote: > Dear G?nter, > > It looks like the *.trlo files just need to be synced according to > updates in recent years. > > The change from '=' to '<=' was done to differentiate the kinds of > assignments in the config. From a quick look at the first three errors, > "a = b" would simply be "a <= b" instead and I'm guessing it's the same > for the rest. > > At some point the vulom gateware had support for more front LED's. > Comment one out and keep the LED index in the range [1,2]. > > Best regards, > > Hans > > On 2024-01-19 12:03, Weber, Guenter Dr. wrote: >> Dear , >> >> >> looks like the firmware is now updated: >> >> >> RIO4-MCAL-1 mbsdaq > vulomflash --addr=3 --read >> VULOM base address: 0x03000000 >> hwmap_mapvme.c:398: LOG: Virtual address for VULOM/TRIDI @ VME >> 0x03000000 is 0x3005e000. >> Performing command 'read'... >> VOLUM+0 => 0x14091f20 >> VOLUM+RANGE_REG(0x800000) => 0x0000006a >> Released vme ptr. >> RIO4-MCAL-1 mbsdaq > vulomflash --addr=3 --readprogs >> VULOM base address: 0x03000000 >> hwmap_mapvme.c:398: LOG: Virtual address for VULOM/TRIDI @ VME >> 0x03000000 is 0x3005e000. >> Performing command 'readprogs'... >> ========================================================================= >> Rng 0: TRLO II? ver/vulom4b_trlo? ? ? ? 2018-10-07 21:56:55 ( 9.486ns) >> 426cb99c >> Rng 1: TRLO II? ver/vulom4b_trlo? ? ? ? 2018-10-07 21:56:55 ( 9.486ns) >> 426cb99c >> Rng 2: TRLO II? ver/vulom4b_trlo? ? ? ? 2023-01-08 20:45:08 ( 9.499ns) >> 1409285e >> Rng 3: N/A >> Rng 4: N/A >> Rng 5: N/A >> Rng 6: N/A >> Rng 7: N/A >> ========================================================================= >> Released vme ptr. >> >> Now starting the VULOM does work, but there seems to be an >> incompatibility with the vulom.trlo file, right? >> >> >> hwmap_mapvme.c:398: LOG: Virtual address for TRLO II @ VME 0x03000000 is >> 0x3005e000. >> LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) >> Clear module setup. >> Loading config file 'vulom.trlo'. >> vulom.trlo:15: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:16: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:17: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:23: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:24: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:31: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:33: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:34: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:39: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:40: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:41: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:47: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:50: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:51: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:52: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:53: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:57: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:59: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:64: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:66: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:77: WARNING: Use of deprecated signal assignment '=', use '=>'. >> vulom.trlo:80: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:81: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:84: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:87: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:99: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:104: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:109: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:110: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:122: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:128: WARNING: Use of deprecated signal assignment '=', use '<='. >> vulom.trlo:129: WARNING: Use of deprecated signal assignment '=', use '<='. >> Executing 'standalone'. >> vulom.trlo:41: FATAL: MUX dest 'FRONT_LED' index (3) out of bounds (<= 2). >> >> >> I think, I have send you the file yesterday. Could you have a look at it? >> >> >> >> Thank you so much! >> >> >> >> >> Best greetings >> >> G?nter >> >> >> >> >> ------------------------------------------------------------------------ >> *Von:* subexp-daq im Auftrag von >> H?kan T Johansson >> *Gesendet:* Freitag, 19. Januar 2024 11:29:14 >> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >> TRLOII, DRASI, etc. were updated >> >> Dear G?nter, >> >> yes, the gateware running on the VULOM is an older version, so not the one >> that trloctrl etc. has now been compiled with.? Could you use vulomflash >> to --prog the new firmware e.g. to range 2, and then restart from that. >> See the instructions at the end of the attached file. >> >> Cheers, >> H?kan >> >> >> >> >> On Fri, 19 Jan 2024, Weber, Guenter Dr. wrote: >> >>> >>> P.S. >>> >>> >>> Maybe this information helps: >>> >>> >>> RIO4-MCAL-1 mbsdaq > vulomflash --addr=3 --readprogs >>> VULOM base address: 0x03000000 >>> hwmap_mapvme.c:398: LOG: Virtual address for VULOM/TRIDI @ VME 0x03000000 > is >>> 0x3005e000. >>> Performing command 'readprogs'... >>> ========================================================================= >>> Rng 0: TRLO II? ver/vulom4b_trlo? ? ? ? 2018-10-07 21:56:55 ( 9.486ns) >>> 426cb99c >>> Rng 1: TRLO II? ver/vulom4b_trlo? ? ? ? 2018-10-07 21:56:55 ( 9.486ns) >>> 426cb99c >>> Rng 2: N/A >>> Rng 3: N/A >>> Rng 4: N/A >>> Rng 5: N/A >>> Rng 6: N/A >>> Rng 7: N/A >>> ========================================================================= >>> Released vme ptr. >>> >>> >>> Best greetings >>> >>> G?nter >>> >>> >>> >>> > ____________________________________________________________________________ >>> Von: subexp-daq im Auftrag von > Weber, >>> Guenter Dr. >>> Gesendet: Freitag, 19. Januar 2024 10:16:03 >>> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >>> Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, >>> DRASI, etc. were updated >>> >>> Sorry, please ignore my last e-mail. >>> >>> >>> Now the automatic setting of the folder works. >>> >>> >>> But ?there is a real problem after executing of the VULOM command. >>> >>> >>> hwmap_mapvme.c:398: LOG: Virtual address for TRLO II @ VME 0x03000000 is >>> 0x3005e000. >>> LOG: TRLO: MD5SUM: 0x426cb99c (CT: 5bba6507 = 2018-10-07 19:56:55 UTC) >>> WARNING: Known firmware (alias): 0x6e4ba1a9. >>> WARNING: Known firmware (alias): 0x1409285e. >>> WARNING: Known firmware (alias): 0xa73c5093. >>> WARNING: Known firmware (alias): 0x6e4ba1a9. >>> WARNING: Known firmware (alias): 0x1409285e. >>> FATAL: TRLO firmware wrong: 0x426cb99c, expected 0x6e4ba1a9 or alias. >>> >>> >>> >>> Best greetings >>> >>> G?nter >>> >>> >>> >>> > ____________________________________________________________________________ >>> Von: subexp-daq im Auftrag von > Weber, >>> Guenter Dr. >>> Gesendet: Freitag, 19. Januar 2024 09:58:21 >>> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >>> Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, >>> DRASI, etc. were updated >>> >>> Dear?H?kan, dear Hans, >>> >>> >>> it looks like the FW number that is identified is the wrong one. >>> >>> >>> vulom_fw=`cat ${TRLOII_PATH}/fw/vulom4b_trlo/trlo_defs.h 2>&1 | grep >>> MD5SUM_STAMP | sed 's/.*0x//'` >>> > exportVULOM4_CTRL=$trloiipath/trloctrl/fw_${VULOM4_FW}_trlo/bin_${machine}_${vers >>> ion}/trlo_ctrl >>> >>> On my system this results in the following path: >>> >>> >>> > VULOM4_CTRL=/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloct >>> rl/fw_d96ffc88_trlo/bin_ppc-linux_4.2.2/trlo_ctrl >>> >>> >>> But it is the wrong one. >>> >>> >>> $VULOM4_CTRL --addr=$addr --clear-setup --config=vulom.trlo standalone >>> module_trigger >>> >>> ./trloii_setup.sh: line > 12:/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_d96ffc >>> 88_trlo/bin_ppc-linux_4.2.2/trlo_ctrl: No such file or directory >>> >>> >>> The right one would be: >>> >>> >>> > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/trloii/trloctrl/fw_140928 >>> 5e_trlo/bin_ppc-linux_4.2.2/trlo_ctrl >>> >>> >>> In the TRLO/TRLOCTRL folder there are also other firmware numbers (which >>> redirect to 1409285e, as I understand), but d96ffc88 is not among them. >>> >>> Do you guys have an idea what the problem is? >>> >>> 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 ? >>> >>> >>> >>> Best greetings >>> G?nter >>> >>> > ____________________________________________________________________________ >>> Von: subexp-daq im Auftrag von > H?kan >>> T Johansson >>> Gesendet: Donnerstag, 18. Januar 2024 22:39:31 >>> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >>> Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, >>> DRASI, etc. were updated >>> >>> On Thu, 18 Jan 2024, Weber, Guenter Dr. wrote: >>> >>> > >>> > Dear Hans, >>> > >>> > >>> > there was some redirect burried in the script which executes scripts > which >>> > execute some more scripts?... and that made me start the DAQ in the old >>> > folder, not the new one. Sorry for that. >>> > >>> > >>> > I now came across the following line in the script which starts the > VULOM: >>> > >>> > >>> > $VULOM4_CTRL --addr=$addr --clear-setup --config=vulom.trlo standalone >>> > module_trigger >>> > >>> > >>> > Here I need to know the firmware number to define the path VULOM4_CTRL, >>> > right? Is there a way to do this automatically? Somehow this works > already >>> > in the makefile of NURDLIB. >>> >>> It looks like this is done with this line in the nurdlib Makefile: >>> >>> ??? VULOM4_FW:=$(shell cat $(TRLOII_PATH)/fw/vulom4b_trlo/trlo_defs.h 2>&1 > | >>> grep MD5SUM_STAMP | sed 's/.*0x//') >>> >>> such that something like >>> >>> ??? VULOM4_FW=`cat $(TRLOII_PATH)/fw/vulom4b_trlo/trlo_defs.h 2>&1 | grep >>> MD5SUM_STAMP | sed 's/.*0x//'` >>> >>> might work in a shell script, if TRLOII_PATH is set, and the fw/ directory >>> exists and has the current gatewares. >>> >>> 'Funfact': This general mess with the TRLO II version numbers is of my >>> creation, however a proper fix has so far required too much effort. >>> Basically, the gateware would have to give info on the offsets and sizes >>> of various controllable items (fairly easy), and the trloctrl program and >>> functions would need to use that (much more complex - that it at all works >>> is thanks to generation of many structures from that trlo_defs.h header, >>> where some of them also intermix with the .trlo lexer/parser). >>> >>> > I would like to avoid to hard code this into the environment settings if >>> > there is a way to figure it out on the fly. >>> >>> Cheers, >>> H?kan >>> >>> >>> >>> > >>> > >>> > >>> > Thanks so much! >>> > >>> > >>> > >>> > Best greetings >>> > >>> > G?nter >>> > >>> > >>> > >>> > >>> > >>> > >>> >> ___________________________________________________________________________ >>> _ >>> > Von: subexp-daq im Auftrag von > Hans >>> > Toshihide T?rnqvist >>> > Gesendet: Donnerstag, 18. Januar 2024 13:28:36 >>> > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter > Dr. >>> > Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, > TRLOII, >>> > DRASI, etc. were updated >>> > Dear G?nter, >>> > >>> > It looks like either the Vetar driver failed, or the fw/driver is old >>> > and nurdlib expects a file that didn't exist a while back. If it's the >>> > latter I can add a switch to ignore this file, it's not critical for >>> > readout and is used to enter a faster readout mode. >>> > >>> > Which version of nurdlib is this? The files and line numbers don't match >>> > with what I see in the source code, and the last time gsi_etherbone.c >>> > changed was early last year. >>> > >>> > The message "Could not open so-and-so" should be for the device, e.g. >>> > /dev/pcie_wb0. This is used for the readout. >>> > >>> > The dactl file should fail with "Failed dactl fopen". >>> > >>> > To summarise, I would suggest to make sure that the correct nurdlib and >>> > r3bfuser are executed by the DAQ scripts. Meanwhile I will prepare a >>> > switch to ignore the dactl file which could anyhow be useful for old >>> > configurations, and to clean up the Etherbone error messages. >>> > >>> > Best regards, >>> > Hans >>> > >>> > On 2024-01-18 11:29, Weber, Guenter Dr. wrote: >>> > > Dear friends, >>> > > >>> > > >>> > > I now started the DAQ and it looks like there is a problem with the >>> > > VETAR2 module. Attached please find the output once the DAQ is started >>> > > on the RIO4. >>> > > >>> > > >>> > > Here ist the error message: >>> > > >>> > > >>> > > 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866) >>> > > 11: a:1: .Gsi Etherbone init_slow { >>> > > (module/gsi_etherbone/gsi_etherbone.c:110) >>> > > 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: > No >>> > > such file or directory. >>> > >? ?(module/gsi_etherbone/gsi_etherbone.c:120) >>> > > 5: a:1: ..Calling exit(EXIT_FAILURE)... >>> > > (module/gsi_etherbone/gsi_etherbone.c:120) >>> > > >>> > > How to proceed? >>> > > >>> > > >>> > > >>> > > Many thanks and best greetings >>> > > G?nter >>> > > >>> > > >>> > > >>> > > >>> > > > ------------------------------------------------------------------------ >>> > > *Von:* subexp-daq im Auftrag > von >>> > > H?kan T Johansson >>> > > *Gesendet:* Dienstag, 16. Januar 2024 19:20:54 >>> > > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. >>> > > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >>> > > TRLOII, DRASI, etc. were updated >>> > > >>> > > On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: >>> > > >>> > >> >>> > >> Dear friends, >>> > >> >>> > >> >>> > >> I am just trying to figure out how all the various scripts/commands >>> work >>> > >> together for setting up our DAQ system. Maybe, you can help to > clearify >>> > some >>> > >> things. >>> > >> >>> > >> >>> > >> >>> > >> - master.bash >>> > > >>> > > This would be intended to run on the readout board (RIO).? The other >>> > > scripts below is for the PC. >>> > > >>> > >> >>> > >> source ../env/env.sh >>> > >> ./trloii_setup.sh >>> > >> # gdb --args \ >>> > >> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ >>> > >> ? ? ? ? --label=MCAL1 \ >>> > >> ? ? ? ? --triva=master,fctime=10,ctime=50 \ >>> > >> ? ? ? ? --log-no-rate-limit \ >>> > >> ? ? ? ? --server=drasi,dest=lyserv \ >>> > >> ? ? ? ? --buf=size=400Mi \ >>> > >> ? ? ? ? --max-ev-size=0x1000000 \ >>> > >> ? ? ? ? --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ >>> > >> ? ? ? ? --eb=lyserv \ >>> > >> ? ? ? ? "$@" >>> > >> >>> > >> In the first line some environment variables are set. The second line >>> > tells >>> > >> the VULOM4 how to operate (i. e. selection from modes of operation >>> > defined >>> > >> in vulom.trlo). Then DRASI is started with a bunch of parameters. Is >>> > there >>> > >> somewhere an explanation of the purpose of all these settings? >>> > > >>> > > The drasi command line options should be described here: >>> > > >>> > > http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html >> >>> > > > > >>> > > >>> > > (Note: 'lyserv' is the name of your PC, at least as seen from the > RIO.) >>> > > >>> > > The TRLO II setup file (vulom.trlo) is worse in terms of > documentation. >>> > > The format as such is hopefully rather straightforward.? A description >>> is >>> > > here: http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html >> >>> > > > > . >>> > > The actual meaning is more complex, the TRLO II description can be > found >>> > > here: >>> > > >>> > > > http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html >> >>> > > >>> > > >>> > > >>> > > (left pane), which just is a colourised version of this: >>> > > http://fy.chalmers.se/~f96hajo/trloii/description.txt >> >>> > > > > >>> > > >>> > > It does not describe the .trlo file as such, but what the gateware > tries >>> > > to achieve. >>> > > >>> > >> And what is in the last line? I never came accross "$@" before. >>> > > >>> > > That would be all the (non-shifted, i.e. not removed) options given to >>> the >>> > > script itself, i.e. master.bash. >>> > > >>> > >> - eb.bash >>> > >> >>> > >> ../drasi/bin/lwrocmerge \ >>> > >> >>> > >> ? ? --label=MCAL_EB \ >>> > >> ? ? --merge-mode=event \ >>> > >> ? ? --server=trans,flush=1 \ >>> > >> ? ? --server=stream,flush=1 \ >>> > >> ? ? --buf=size=1600Mi \ >>> > >> ? ? --max-ev-size=20Mi \ >>> > >> ? ? --eb-master=rio4-mcal-1 \ >>> > >> ? ? --file-writer \ >>> > >> ? ? --drasi=rio4-mcal-1 >>> > >> >>> > >> What is the purpose of this command? >>> > > >>> > > This runs an 'event builder' on the PC.? Not strictly needed, but this >>> > > way, the RIO only ever needs to send data once, to this event-builder >>> > > (EB).? File writing, and streaming of on-line data is then handled by >>> this >>> > > process.? It is cheaper to have better network cards and so on in a >>> plain >>> > > PC. >>> > > >>> > >> Why are values for buffer size and max >>> > >> event size different then in the command before? >>> > > >>> > > The nomenclaturure is unfortunately a bit convoluted below with ucesb >>> > > regards 'buffer size'.? The --buf in the two commands above give the >>> size >>> > > of the memory used to buffer data inside the process, and depends on > how >>> > > much memory each machine has.? The --max-ev-size tells how large each >>> .lmd >>> > > event can be.? The --max-ev-size configured in the event builder needs >>> to >>> > > be as large as the sum of all event sources it has.? I.e. should be > able >>> > > to be the same as in your single source above. >>> > > >>> > > In the readout itself, any event that is read out cannot be larger > than >>> > > this.? If it is, then the DAQ will report a fatal failure. >>> > > >>> > >> - fanout.bash >>> > >> >>> > >> #!/bin/bash >>> > >> while : >>> > >> do >>> > >> ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ >>> > >> ? ? stream://localhost \ >>> > >> ? ? --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 >>> > >> sleep 5 >>> > >> done >>> > >> >>> > >> This looks like setting up a connection point to the outside world, >>> > right? >>> > > >>> > > Yes.? It accepts connections and will serve them data for online >>> analysis. >>> > > >>> > > stream://localhost? tells it where to read data (here the PC itself >>> where >>> > > it is running).? Using the 'stream' protocol, which esentially is just >>> raw >>> > > LMD events.? (As is the 'transport protocol'.)? That will be served on >>> the >>> > > default port used for the stream server set up by the EB above. >>> > > >>> > > --server is then the server that accepts connections, and serves data > on >>> > > another port (8001). >>> > > >>> > >> And we find the third (random?) value for a buffer size. >>> > > >>> > > That bufsize is actually the LMD buffer size used by the stream > server. >>> > > The corresponding value in the readout and EB is set implicitly from > the >>> > > maximum event size... >>> > > >>> > >> - rate.bash >>> > >> >>> > >> ../drasi/bin/lwrocmon --rate rio4-mcal-1 >>> > >> >>> > >> Ok, this I understand. We can look the DAQ over the shoulder and see >>> what >>> > >> the thing is doing in terms of number of trigger events, transported >>> > data, >>> > >> etc. >>> > > >>> > >> - log.bash >>> > >> >>> > >> ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost >>> > >> >>> > >> This is also easy to understand. >>> > > >>> > > :-) >>> > > >>> > > Then also try to do (on the PC) >>> > > >>> > > drasi/bin/lwrocmon --tree rio4-mcal-1 localhost >>> > > >>> > > which would show a 'tree-view' monitoring of the running system. >>> > > >>> > > >>> > > Cheers, >>> > > H?kan >>> > > >>> > -- >>> > subexp-daq mailing list >>> > subexp-daq at lists.chalmers.se >>> > https://lists.chalmers.se/mailman/listinfo/subexp-daq >> >>> > >>> > >>> >>> >> > -- > subexp-daq mailing list > subexp-daq at lists.chalmers.se > https://lists.chalmers.se/mailman/listinfo/subexp-daq > -------------- next part -------------- /* vim: set filetype=cpp: */ /* * This setup is for the sis3316 (Struck ADC) * * ECL_IN 1-5 <- trigger output of sis 0-4 * ECL_OUT 1-5 -> trigger input of sis 0-4 * ECL_OUT 7-8 -> pulser going to channel 1 of all sis modules (via fanout module) * LEMO_OUT 1 -> clock signal to CI on first sis module (12.5 MHz) * LEMO_OUT 2 -> clock signal for scope, compare with sis module CO signal */ SECTION(module_trigger) { all_or_mask(1) <= ECL_IN(1) | ECL_IN(2) | ECL_IN(3) | ECL_IN(4) | ECL_IN(5); TRIG_LMU_AUX(1) <= ALL_OR(1); TRIG_LMU_OUT(1) <= TRIG_LMU_AUX(1); } SECTION(pulser_trigger) { period(4) = 1000 ms; TRIG_LMU_AUX(1) <= PULSER(4); TRIG_LMU_OUT(1) <= TRIG_LMU_AUX(1); } SECTION(pulser_to_channels) { /* Pulser for channels */ period(1) = 100 us; GATE_DELAY(1) <= PULSER(1); stretch(1) = 100 ns; ECL_OUT(7) <= GATE_DELAY(1); ECL_OUT(8) <= GATE_DELAY(1); } SECTION(standalone) { FRONT_LED(1) <= ECL_IO_IN(4); FRONT_LED(2) <= MASTER_START; /* FRONT_LED(3) <= ACCEPT_PULSE; */ /* Deadtime is received from TRIMI. */ /* DEADTIME_IN(1) <= TRIMI_TDT; */ /* Deadtime is received from TRIVA. */ DEADTIME_IN(1) <= ECL_IO_IN(4); /* Encoded trigger is sent to TRIVA. */ ECL_IO_OUT(1) <= ENCODED_TRIG(1); ECL_IO_OUT(2) <= ENCODED_TRIG(2); ECL_IO_OUT(3) <= ENCODED_TRIG(3); ECL_IO_OUT(4) <= ENCODED_TRIG(4); /* 12.5 MHz Pulser (common clock) */ period(3) = 80 ns; GATE_DELAY(2) <= PULSER(3); stretch(2) = 10 ns; /* 10 ns = 50% duty cycle */ LEMO_OUT(1) <= GATE_DELAY(2); /* 10 Hz Pulser (for minimum trigger rate) */ period(4) = 100 ms; GATE_DELAY(3) <= PULSER(4); stretch(3) = 1 us; LEMO_OUT(2) <= GATE_DELAY(3); /* Trigger setup */ tpat_trig(1) = 1; tpat_enable = 1; trig_stretch(1) = 100 ns; /* Master start generation */ fast_busy_len = 1000ns; accept_window_len = 100 ns; sum_out_stretch = 100 ns; sum_out_mask => ECL_OUT(1), ECL_OUT(2), ECL_OUT(3), ECL_OUT(4), ECL_OUT(5); /* Serial timestamp sender */ SERIAL_TSTAMP_IN <= SERIAL_TSTAMP_OUT; SERIAL_TSTAMP_LATCH <= ACCEPT_PULSE; slew_counter_add = 0x1000000; /* in 16 clock cycles */ slew_counter_add = 0xa00000; /* in ns */ ECL_OUT(16) <= SERIAL_TSTAMP_OUT; /* Send Heimtime */ ECL_OUT(15) <= HEIMTIME_OUT; } SECTION(auto_bank_switch) { /* * For automatic bank switching, one needs to connect UO to UI. * One may consider using an edge to pulse conversion here. * On UO, the addr threshold flag is transmitted. * A signal on UI triggers a bank switch in the module. */ ECL_OUT(10) <= ECL_IN(2); /* * Produce an OR of the inputs. */ all_or_mask(1) <= ECL_IN(2); /* * And use the inputs as trigger. */ TRIG_PENDING[1] <= ALL_OR(1); TRIG_LMU_OUT(1) <= TRIG_LMU_AUX(1); /* * In automatic mode we cannot have so high trigger rates * coming in. The second bank must not fill up before we've * read out the first. */ /* Pulser 1 */ period(1) = 10 us; /* Pulser 2 */ period(2) = 100 us; GATE_DELAY(1) <= PULSER(2); stretch(1) = 1000 ns; /* * Send pulsers to module. */ ECL_OUT(11) <= GATE_DELAY(1); ECL_OUT(12) <= GATE_DELAY(1); } From g.weber at hi-jena.gsi.de Fri Jan 19 15:22:41 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Fri, 19 Jan 2024 14:22:41 +0000 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <831905AE-5B53-45DA-81DD-756DED9EE76E@chalmers.se> <438345a1684c413e8678a1a2ac928bc2@hi-jena.gsi.de> <222475cb-2ab6-4f4c-9bc0-d08a8b20a3cc@chalmers.se> <4e1e90ee-e985-42b2-a4e8-83f02d1c56b8@chalmers.se> <5b0a058d-b58c-4e73-a59b-24a40d59a3f1@chalmers.se> <68c6e7a91d354a35a08a6a89d181b9b6@hi-jena.gsi.de> <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de> <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de>, <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> Message-ID: <1aa0afb1bf1e4f91b5d2ab58eb0c62bb@hi-jena.gsi.de> Dear Hans, with the help of H?kan, I managed to get the VULOM running. So, we are back to starting the DRASI. There we encountered first the fact that in main.cfg a BARRIER is now required between the initialization of all modules (before there was only a single BARRIER command in the whole main.cfg. Now, we are again encounter the VETAR error message. See below: 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: 56583). Thread has no error buffer yet... CPUS: 1 delay: 1 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: 56583). Thread has no error buffer yet... HOST: RIO4-MCAL-1 Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 (eth1). 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = 0x19000000, 1 consumers. 10: lwroc_triva_readout.c:66: Silence TRIVA (HALT) 10: lwroc_net_io.c:167: Started server on port 56583 (data port 50126). client union size: 244 208 188 508 640 204 204 => 640 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 10: lwroc_main.c:706: Log message rate limit not in effect. 10: lwroc_readout.c:112: call readout_init... 10: lwroc_thread_util.c:117: This is the triva control thread! 10: lwroc_thread_util.c:117: This is the net io thread! 10: lwroc_thread_util.c:117: This is the slow_async thread! 10: lwroc_thread_util.c:117: This is the data server thread! 10: lwroc_message_internal.c:472: Message client connected! 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) [192.168.1.1]. 10: lwroc_triva_control.c:370: Setup TRIVA (DISBUS, HALT, MASTER, RESET) 10: lwroc_triva_control.c:418: Minimum event time ctime(5000)+1*rd(688)+3*wr(634)+fctime(1000)=8590 ns (116.414 kHz) 10: lwroc_triva_state.c:1486: (Re)send ident messages... 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 9: lwroc_triva_control.c:507: TEST: GO 10: lwroc_triva_control.c:725: RUN: RESET 10: lwroc_triva_control.c:729: RUN: MT=14 9: lwroc_triva_control.c:737: GO (1 good test triggers done) (max 116.4 kHz) 10: lwroc_triva_readout.c:376: Trigger 14 seen. 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. 10: config/parser.c:287: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { 10: config/parser.c:299: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 10: config/parser.c:287: Opened './main.cfg' { 10: config/config.c:1299: .Global log level=verbose. 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vetar.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vetar.cfg' } 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } 10: config/parser.c:299: Closed './main.cfg' } 10: crate/crate.c:347: crate_create { 10: crate/crate.c:673: crate_create(MCAL) } 10: crate/crate.c:899: crate_init(MCAL) { 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) 10: crate/crate.c:923: .Slow-init module[1]=GSI_VETAR. 5: module/gsi_etherbone/gsi_etherbone.c:431: ..Gsi Etherbone /sys/class/vetar/vetar0/dactl: Failed dactl fopen: No such file or directory. 5: module/gsi_etherbone/gsi_etherbone.c:431: ..Calling abort()... We are sure that the right NURDLIB path is used and also DRASI is started in the correct folder. What we found in the enironment variables are two lines, where 'white rabbit' is mentioned. As I understand, this is connected to the VETAR2 module. LD_LIBRARY_PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/lib:/mbsusr/mbsdaq/mbsrun/whiterabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/bin:/bin:/bin/ces:/usr/bin:/mbsusr/mbsdaq/bin:/usr/local/bin:/usr/bin/X11:/etc:/usr/etc:.:/mbsusr/mbsdaq/tools Maybe, it is necessary to update something there? Anyway, if you have now a switch in NURDLIB to deal with old software for the VETAR, then we should proceed with removing NURDLIB and getting the newer version, right? Many thanks and have a nice weekend! Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von Hans Toshihide T?rnqvist Gesendet: Donnerstag, 18. Januar 2024 13:28:36 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated Dear G?nter, It looks like either the Vetar driver failed, or the fw/driver is old and nurdlib expects a file that didn't exist a while back. If it's the latter I can add a switch to ignore this file, it's not critical for readout and is used to enter a faster readout mode. Which version of nurdlib is this? The files and line numbers don't match with what I see in the source code, and the last time gsi_etherbone.c changed was early last year. The message "Could not open so-and-so" should be for the device, e.g. /dev/pcie_wb0. This is used for the readout. The dactl file should fail with "Failed dactl fopen". To summarise, I would suggest to make sure that the correct nurdlib and r3bfuser are executed by the DAQ scripts. Meanwhile I will prepare a switch to ignore the dactl file which could anyhow be useful for old configurations, and to clean up the Etherbone error messages. Best regards, Hans On 2024-01-18 11:29, Weber, Guenter Dr. wrote: > Dear friends, > > > I now started the DAQ and it looks like there is a problem with the > VETAR2 module. Attached please find the output once the DAQ is started > on the RIO4. > > > Here ist the error message: > > > 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866) > 11: a:1: .Gsi Etherbone init_slow { > (module/gsi_etherbone/gsi_etherbone.c:110) > 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No > such file or directory. > (module/gsi_etherbone/gsi_etherbone.c:120) > 5: a:1: ..Calling exit(EXIT_FAILURE)... > (module/gsi_etherbone/gsi_etherbone.c:120) > > How to proceed? > > > > Many thanks and best greetings > G?nter > > > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > H?kan T Johansson > *Gesendet:* Dienstag, 16. Januar 2024 19:20:54 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > TRLOII, DRASI, etc. were updated > > On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: > >> >> Dear friends, >> >> >> I am just trying to figure out how all the various scripts/commands work >> together for setting up our DAQ system. Maybe, you can help to clearify some >> things. >> >> >> >> - master.bash > > This would be intended to run on the readout board (RIO). The other > scripts below is for the PC. > >> >> source ../env/env.sh >> ./trloii_setup.sh >> # gdb --args \ >> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ >> --label=MCAL1 \ >> --triva=master,fctime=10,ctime=50 \ >> --log-no-rate-limit \ >> --server=drasi,dest=lyserv \ >> --buf=size=400Mi \ >> --max-ev-size=0x1000000 \ >> --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ >> --eb=lyserv \ >> "$@" >> >> In the first line some environment variables are set. The second line tells >> the VULOM4 how to operate (i. e. selection from modes of operation defined >> in vulom.trlo). Then DRASI is started with a bunch of parameters. Is there >> somewhere an explanation of the purpose of all these settings? > > The drasi command line options should be described here: > > http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html > > > (Note: 'lyserv' is the name of your PC, at least as seen from the RIO.) > > The TRLO II setup file (vulom.trlo) is worse in terms of documentation. > The format as such is hopefully rather straightforward. A description is > here: http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html > . > The actual meaning is more complex, the TRLO II description can be found > here: > > http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html > > > (left pane), which just is a colourised version of this: > http://fy.chalmers.se/~f96hajo/trloii/description.txt > > > It does not describe the .trlo file as such, but what the gateware tries > to achieve. > >> And what is in the last line? I never came accross "$@" before. > > That would be all the (non-shifted, i.e. not removed) options given to the > script itself, i.e. master.bash. > >> - eb.bash >> >> ../drasi/bin/lwrocmerge \ >> >> --label=MCAL_EB \ >> --merge-mode=event \ >> --server=trans,flush=1 \ >> --server=stream,flush=1 \ >> --buf=size=1600Mi \ >> --max-ev-size=20Mi \ >> --eb-master=rio4-mcal-1 \ >> --file-writer \ >> --drasi=rio4-mcal-1 >> >> What is the purpose of this command? > > This runs an 'event builder' on the PC. Not strictly needed, but this > way, the RIO only ever needs to send data once, to this event-builder > (EB). File writing, and streaming of on-line data is then handled by this > process. It is cheaper to have better network cards and so on in a plain > PC. > >> Why are values for buffer size and max >> event size different then in the command before? > > The nomenclaturure is unfortunately a bit convoluted below with ucesb > regards 'buffer size'. The --buf in the two commands above give the size > of the memory used to buffer data inside the process, and depends on how > much memory each machine has. The --max-ev-size tells how large each .lmd > event can be. The --max-ev-size configured in the event builder needs to > be as large as the sum of all event sources it has. I.e. should be able > to be the same as in your single source above. > > In the readout itself, any event that is read out cannot be larger than > this. If it is, then the DAQ will report a fatal failure. > >> - fanout.bash >> >> #!/bin/bash >> while : >> do >> ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ >> stream://localhost \ >> --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 >> sleep 5 >> done >> >> This looks like setting up a connection point to the outside world, right? > > Yes. It accepts connections and will serve them data for online analysis. > > stream://localhost tells it where to read data (here the PC itself where > it is running). Using the 'stream' protocol, which esentially is just raw > LMD events. (As is the 'transport protocol'.) That will be served on the > default port used for the stream server set up by the EB above. > > --server is then the server that accepts connections, and serves data on > another port (8001). > >> And we find the third (random?) value for a buffer size. > > That bufsize is actually the LMD buffer size used by the stream server. > The corresponding value in the readout and EB is set implicitly from the > maximum event size... > >> - rate.bash >> >> ../drasi/bin/lwrocmon --rate rio4-mcal-1 >> >> Ok, this I understand. We can look the DAQ over the shoulder and see what >> the thing is doing in terms of number of trigger events, transported data, >> etc. > >> - log.bash >> >> ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost >> >> This is also easy to understand. > > :-) > > Then also try to do (on the PC) > > drasi/bin/lwrocmon --tree rio4-mcal-1 localhost > > which would show a 'tree-view' monitoring of the running system. > > > Cheers, > H?kan > -- 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: From hans.tornqvist at chalmers.se Fri Jan 19 16:31:37 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Fri, 19 Jan 2024 16:31:37 +0100 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <1aa0afb1bf1e4f91b5d2ab58eb0c62bb@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <222475cb-2ab6-4f4c-9bc0-d08a8b20a3cc@chalmers.se> <4e1e90ee-e985-42b2-a4e8-83f02d1c56b8@chalmers.se> <5b0a058d-b58c-4e73-a59b-24a40d59a3f1@chalmers.se> <68c6e7a91d354a35a08a6a89d181b9b6@hi-jena.gsi.de> <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de> <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <1aa0afb1bf1e4f91b5d2ab58eb0c62bb@hi-jena.gsi.de> Message-ID: <810ed751-3a8a-43d7-b9b1-7d7c08f8fdf4@chalmers.se> Dear G?nter, I have implemented the dactl switch in 'mcal_daq_merge', so in main.cfg: GSI_VETAR { dactl = false direct = false } I do not know how the names of the Etherbone libraries (e.g. cherry and enigma) relate to the driver. If the dactl file is not available, we just have to skip dactl accesses and not allow the direct readout path. Have a good weekend you too! Best regards, Hans On 2024-01-19 15:22, Weber, Guenter Dr. wrote: > Dear Hans, > > > with the help of H?kan, I managed to get the VULOM running. So, we are > back to starting the DRASI. There we encountered first the fact that in > main.cfg a BARRIER is now required between the initialization of all > modules (before there was only a single BARRIER command in the whole > main.cfg. > > > Now, we are again encounter the VETAR error message. See below: > > > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: > 56583). > Thread has no error buffer yet... > CPUS: 1 > delay: 1 > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: > 56583). > Thread has no error buffer yet... > HOST: RIO4-MCAL-1 > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] > 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 > (eth1). > 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = > 0x19000000, 1 consumers. > 10: lwroc_triva_readout.c:66: Silence TRIVA? (HALT) > 10: lwroc_net_io.c:167: Started server on port 56583 (data port 50126). > client union size: 244 208 188 508 640 204 204? => 640 > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: > /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 > 10: lwroc_main.c:706: Log message rate limit not in effect. > 10: lwroc_readout.c:112: call readout_init... > 10: lwroc_thread_util.c:117: This is the triva control thread! > 10: lwroc_thread_util.c:117: This is the net io thread! > 10: lwroc_thread_util.c:117: This is the slow_async thread! > 10: lwroc_thread_util.c:117: This is the data server thread! > 10: lwroc_message_internal.c:472: Message client connected! > 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) > [192.168.1.1]. > 10: lwroc_triva_control.c:370: Setup TRIVA? (DISBUS, HALT, MASTER, RESET) > 10: lwroc_triva_control.c:418: Minimum event time > ctime(5000)+1*rd(688)+3*wr(634)+fctime(1000)=8590 ns (116.414 kHz) > 10: lwroc_triva_state.c:1486: (Re)send ident messages... > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 > 9: lwroc_triva_control.c:507: TEST: GO > 10: lwroc_triva_control.c:725: RUN: RESET > 10: lwroc_triva_control.c:729: RUN: MT=14 > 9: lwroc_triva_control.c:737:?? GO (1 good test triggers done) (max > 116.4 kHz) > 10: lwroc_triva_readout.c:376: Trigger 14 seen. > 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. > 10: config/parser.c:287: Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { > 10: config/parser.c:299: Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 > (IN_READOUT).? EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: config/parser.c:287: Opened './main.cfg' { > 10: config/config.c:1299: .Global log level=verbose. > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vetar.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vetar.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:299: Closed './main.cfg' } > 10: crate/crate.c:347: crate_create { > 10: crate/crate.c:673: crate_create(MCAL) } > 10: crate/crate.c:899: crate_init(MCAL) { > 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) > 10: crate/crate.c:923: .Slow-init module[1]=GSI_VETAR. > 5: module/gsi_etherbone/gsi_etherbone.c:431: ..Gsi Etherbone > /sys/class/vetar/vetar0/dactl: Failed dactl fopen: No such file or > directory. > 5: module/gsi_etherbone/gsi_etherbone.c:431: ..Calling abort()... > > We are sure that the right NURDLIB path is used and also DRASI is > started in the correct folder. > > > What we found in the enironment variables are two lines, where 'white > rabbit' is mentioned. As I understand, this is connected to the VETAR2 > module. > > > LD_LIBRARY_PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/lib:/mbsusr/mbsdaq/mbsrun/whiterabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib > PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/bin:/bin:/bin/ces:/usr/bin:/mbsusr/mbsdaq/bin:/usr/local/bin:/usr/bin/X11:/etc:/usr/etc:.:/mbsusr/mbsdaq/tools > > Maybe, it is necessary to update something there? > > > Anyway, if you have now a switch in NURDLIB to deal with old software > for the VETAR, then we should proceed with removing NURDLIB and getting > the newer version, right? > > > > > Many thanks and have a nice weekend! > > > > > Best greetings > > G?nter > > > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > Hans Toshihide T?rnqvist > *Gesendet:* Donnerstag, 18. Januar 2024 13:28:36 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr. > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > TRLOII, DRASI, etc. were updated > Dear G?nter, > > It looks like either the Vetar driver failed, or the fw/driver is old > and nurdlib expects a file that didn't exist a while back. If it's the > latter I can add a switch to ignore this file, it's not critical for > readout and is used to enter a faster readout mode. > > Which version of nurdlib is this? The files and line numbers don't match > with what I see in the source code, and the last time gsi_etherbone.c > changed was early last year. > > The message "Could not open so-and-so" should be for the device, e.g. > /dev/pcie_wb0. This is used for the readout. > > The dactl file should fail with "Failed dactl fopen". > > To summarise, I would suggest to make sure that the correct nurdlib and > r3bfuser are executed by the DAQ scripts. Meanwhile I will prepare a > switch to ignore the dactl file which could anyhow be useful for old > configurations, and to clean up the Etherbone error messages. > > Best regards, > Hans > > On 2024-01-18 11:29, Weber, Guenter Dr. wrote: >> Dear friends, >> >> >> I now started the DAQ and it looks like there is a problem with the >> VETAR2 module. Attached please find the output once the DAQ is started >> on the RIO4. >> >> >> Here ist the error message: >> >> >> 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866) >> 11: a:1: .Gsi Etherbone init_slow { >> (module/gsi_etherbone/gsi_etherbone.c:110) >> 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No >> such file or directory. >>? ?(module/gsi_etherbone/gsi_etherbone.c:120) >> 5: a:1: ..Calling exit(EXIT_FAILURE)... >> (module/gsi_etherbone/gsi_etherbone.c:120) >> >> How to proceed? >> >> >> >> Many thanks and best greetings >> G?nter >> >> >> >> >> ------------------------------------------------------------------------ >> *Von:* subexp-daq im Auftrag von >> H?kan T Johansson >> *Gesendet:* Dienstag, 16. Januar 2024 19:20:54 >> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >> TRLOII, DRASI, etc. were updated >> >> On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: >> >>> >>> Dear friends, >>> >>> >>> I am just trying to figure out how all the various scripts/commands work >>> together for setting up our DAQ system. Maybe, you can help to clearify some >>> things. >>> >>> >>> >>> - master.bash >> >> This would be intended to run on the readout board (RIO).? The other >> scripts below is for the PC. >> >>> >>> source ../env/env.sh >>> ./trloii_setup.sh >>> # gdb --args \ >>> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ >>> ? ? ? ? --label=MCAL1 \ >>> ? ? ? ? --triva=master,fctime=10,ctime=50 \ >>> ? ? ? ? --log-no-rate-limit \ >>> ? ? ? ? --server=drasi,dest=lyserv \ >>> ? ? ? ? --buf=size=400Mi \ >>> ? ? ? ? --max-ev-size=0x1000000 \ >>> ? ? ? ? --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ >>> ? ? ? ? --eb=lyserv \ >>> ? ? ? ? "$@" >>> >>> In the first line some environment variables are set. The second line tells >>> the VULOM4 how to operate (i. e. selection from modes of operation defined >>> in vulom.trlo). Then DRASI is started with a bunch of parameters. Is there >>> somewhere an explanation of the purpose of all these settings? >> >> The drasi command line options should be described here: >> >> http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html > >> > >> >> (Note: 'lyserv' is the name of your PC, at least as seen from the RIO.) >> >> The TRLO II setup file (vulom.trlo) is worse in terms of documentation. >> The format as such is hopefully rather straightforward.? A description is >> here: http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html > >> > . >> The actual meaning is more complex, the TRLO II description can be found >> here: >> >> http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html > >> > >> >> (left pane), which just is a colourised version of this: >> http://fy.chalmers.se/~f96hajo/trloii/description.txt > >> > >> >> It does not describe the .trlo file as such, but what the gateware tries >> to achieve. >> >>> And what is in the last line? I never came accross "$@" before. >> >> That would be all the (non-shifted, i.e. not removed) options given to the >> script itself, i.e. master.bash. >> >>> - eb.bash >>> >>> ../drasi/bin/lwrocmerge \ >>> >>> ? ? --label=MCAL_EB \ >>> ? ? --merge-mode=event \ >>> ? ? --server=trans,flush=1 \ >>> ? ? --server=stream,flush=1 \ >>> ? ? --buf=size=1600Mi \ >>> ? ? --max-ev-size=20Mi \ >>> ? ? --eb-master=rio4-mcal-1 \ >>> ? ? --file-writer \ >>> ? ? --drasi=rio4-mcal-1 >>> >>> What is the purpose of this command? >> >> This runs an 'event builder' on the PC.? Not strictly needed, but this >> way, the RIO only ever needs to send data once, to this event-builder >> (EB).? File writing, and streaming of on-line data is then handled by this >> process.? It is cheaper to have better network cards and so on in a plain >> PC. >> >>> Why are values for buffer size and max >>> event size different then in the command before? >> >> The nomenclaturure is unfortunately a bit convoluted below with ucesb >> regards 'buffer size'.? The --buf in the two commands above give the size >> of the memory used to buffer data inside the process, and depends on how >> much memory each machine has.? The --max-ev-size tells how large each .lmd >> event can be.? The --max-ev-size configured in the event builder needs to >> be as large as the sum of all event sources it has.? I.e. should be able >> to be the same as in your single source above. >> >> In the readout itself, any event that is read out cannot be larger than >> this.? If it is, then the DAQ will report a fatal failure. >> >>> - fanout.bash >>> >>> #!/bin/bash >>> while : >>> do >>> ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ >>> ? ? stream://localhost \ >>> ? ? --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 >>> sleep 5 >>> done >>> >>> This looks like setting up a connection point to the outside world, right? >> >> Yes.? It accepts connections and will serve them data for online analysis. >> >> stream://localhost? tells it where to read data (here the PC itself where >> it is running).? Using the 'stream' protocol, which esentially is just raw >> LMD events.? (As is the 'transport protocol'.)? That will be served on the >> default port used for the stream server set up by the EB above. >> >> --server is then the server that accepts connections, and serves data on >> another port (8001). >> >>> And we find the third (random?) value for a buffer size. >> >> That bufsize is actually the LMD buffer size used by the stream server. >> The corresponding value in the readout and EB is set implicitly from the >> maximum event size... >> >>> - rate.bash >>> >>> ../drasi/bin/lwrocmon --rate rio4-mcal-1 >>> >>> Ok, this I understand. We can look the DAQ over the shoulder and see what >>> the thing is doing in terms of number of trigger events, transported data, >>> etc. >> >>> - log.bash >>> >>> ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost >>> >>> This is also easy to understand. >> >> :-) >> >> Then also try to do (on the PC) >> >> drasi/bin/lwrocmon --tree rio4-mcal-1 localhost >> >> which would show a 'tree-view' monitoring of the running system. >> >> >> Cheers, >> H?kan >> > -- > subexp-daq mailing list > subexp-daq at lists.chalmers.se > https://lists.chalmers.se/mailman/listinfo/subexp-daq > > From g.weber at hi-jena.gsi.de Mon Jan 22 11:10:18 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Mon, 22 Jan 2024 10:10:18 +0000 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <810ed751-3a8a-43d7-b9b1-7d7c08f8fdf4@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <222475cb-2ab6-4f4c-9bc0-d08a8b20a3cc@chalmers.se> <4e1e90ee-e985-42b2-a4e8-83f02d1c56b8@chalmers.se> <5b0a058d-b58c-4e73-a59b-24a40d59a3f1@chalmers.se> <68c6e7a91d354a35a08a6a89d181b9b6@hi-jena.gsi.de> <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de> <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <1aa0afb1bf1e4f91b5d2ab58eb0c62bb@hi-jena.gsi.de>, <810ed751-3a8a-43d7-b9b1-7d7c08f8fdf4@chalmers.se> Message-ID: <0dc854ec60194f299b776bc263eb2c72@hi-jena.gsi.de> Dear Hans, I updated the NURDLIB, but the new flag is not recognized. 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } 5: config/keyword.c:20: .Invalid keyword "dactl". 5: config/keyword.c:20: .Calling abort()... Do I also need to recompile DRASI or R3BFUSER? Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von Hans Toshihide T?rnqvist Gesendet: Freitag, 19. Januar 2024 16:31:37 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated Dear G?nter, I have implemented the dactl switch in 'mcal_daq_merge', so in main.cfg: GSI_VETAR { dactl = false direct = false } I do not know how the names of the Etherbone libraries (e.g. cherry and enigma) relate to the driver. If the dactl file is not available, we just have to skip dactl accesses and not allow the direct readout path. Have a good weekend you too! Best regards, Hans On 2024-01-19 15:22, Weber, Guenter Dr. wrote: > Dear Hans, > > > with the help of H?kan, I managed to get the VULOM running. So, we are > back to starting the DRASI. There we encountered first the fact that in > main.cfg a BARRIER is now required between the initialization of all > modules (before there was only a single BARRIER command in the whole > main.cfg. > > > Now, we are again encounter the VETAR error message. See below: > > > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: > 56583). > Thread has no error buffer yet... > CPUS: 1 > delay: 1 > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: > 56583). > Thread has no error buffer yet... > HOST: RIO4-MCAL-1 > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] > 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 > (eth1). > 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = > 0x19000000, 1 consumers. > 10: lwroc_triva_readout.c:66: Silence TRIVA (HALT) > 10: lwroc_net_io.c:167: Started server on port 56583 (data port 50126). > client union size: 244 208 188 508 640 204 204 => 640 > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: > /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 > 10: lwroc_main.c:706: Log message rate limit not in effect. > 10: lwroc_readout.c:112: call readout_init... > 10: lwroc_thread_util.c:117: This is the triva control thread! > 10: lwroc_thread_util.c:117: This is the net io thread! > 10: lwroc_thread_util.c:117: This is the slow_async thread! > 10: lwroc_thread_util.c:117: This is the data server thread! > 10: lwroc_message_internal.c:472: Message client connected! > 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) > [192.168.1.1]. > 10: lwroc_triva_control.c:370: Setup TRIVA (DISBUS, HALT, MASTER, RESET) > 10: lwroc_triva_control.c:418: Minimum event time > ctime(5000)+1*rd(688)+3*wr(634)+fctime(1000)=8590 ns (116.414 kHz) > 10: lwroc_triva_state.c:1486: (Re)send ident messages... > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 > 9: lwroc_triva_control.c:507: TEST: GO > 10: lwroc_triva_control.c:725: RUN: RESET > 10: lwroc_triva_control.c:729: RUN: MT=14 > 9: lwroc_triva_control.c:737: GO (1 good test triggers done) (max > 116.4 kHz) > 10: lwroc_triva_readout.c:376: Trigger 14 seen. > 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. > 10: config/parser.c:287: Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { > 10: config/parser.c:299: Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 > (IN_READOUT). EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: config/parser.c:287: Opened './main.cfg' { > 10: config/config.c:1299: .Global log level=verbose. > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vetar.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vetar.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:299: Closed './main.cfg' } > 10: crate/crate.c:347: crate_create { > 10: crate/crate.c:673: crate_create(MCAL) } > 10: crate/crate.c:899: crate_init(MCAL) { > 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) > 10: crate/crate.c:923: .Slow-init module[1]=GSI_VETAR. > 5: module/gsi_etherbone/gsi_etherbone.c:431: ..Gsi Etherbone > /sys/class/vetar/vetar0/dactl: Failed dactl fopen: No such file or > directory. > 5: module/gsi_etherbone/gsi_etherbone.c:431: ..Calling abort()... > > We are sure that the right NURDLIB path is used and also DRASI is > started in the correct folder. > > > What we found in the enironment variables are two lines, where 'white > rabbit' is mentioned. As I understand, this is connected to the VETAR2 > module. > > > LD_LIBRARY_PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/lib:/mbsusr/mbsdaq/mbsrun/whiterabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib > PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/bin:/bin:/bin/ces:/usr/bin:/mbsusr/mbsdaq/bin:/usr/local/bin:/usr/bin/X11:/etc:/usr/etc:.:/mbsusr/mbsdaq/tools > > Maybe, it is necessary to update something there? > > > Anyway, if you have now a switch in NURDLIB to deal with old software > for the VETAR, then we should proceed with removing NURDLIB and getting > the newer version, right? > > > > > Many thanks and have a nice weekend! > > > > > Best greetings > > G?nter > > > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > Hans Toshihide T?rnqvist > *Gesendet:* Donnerstag, 18. Januar 2024 13:28:36 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr. > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > TRLOII, DRASI, etc. were updated > Dear G?nter, > > It looks like either the Vetar driver failed, or the fw/driver is old > and nurdlib expects a file that didn't exist a while back. If it's the > latter I can add a switch to ignore this file, it's not critical for > readout and is used to enter a faster readout mode. > > Which version of nurdlib is this? The files and line numbers don't match > with what I see in the source code, and the last time gsi_etherbone.c > changed was early last year. > > The message "Could not open so-and-so" should be for the device, e.g. > /dev/pcie_wb0. This is used for the readout. > > The dactl file should fail with "Failed dactl fopen". > > To summarise, I would suggest to make sure that the correct nurdlib and > r3bfuser are executed by the DAQ scripts. Meanwhile I will prepare a > switch to ignore the dactl file which could anyhow be useful for old > configurations, and to clean up the Etherbone error messages. > > Best regards, > Hans > > On 2024-01-18 11:29, Weber, Guenter Dr. wrote: >> Dear friends, >> >> >> I now started the DAQ and it looks like there is a problem with the >> VETAR2 module. Attached please find the output once the DAQ is started >> on the RIO4. >> >> >> Here ist the error message: >> >> >> 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866) >> 11: a:1: .Gsi Etherbone init_slow { >> (module/gsi_etherbone/gsi_etherbone.c:110) >> 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No >> such file or directory. >> (module/gsi_etherbone/gsi_etherbone.c:120) >> 5: a:1: ..Calling exit(EXIT_FAILURE)... >> (module/gsi_etherbone/gsi_etherbone.c:120) >> >> How to proceed? >> >> >> >> Many thanks and best greetings >> G?nter >> >> >> >> >> ------------------------------------------------------------------------ >> *Von:* subexp-daq im Auftrag von >> H?kan T Johansson >> *Gesendet:* Dienstag, 16. Januar 2024 19:20:54 >> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >> TRLOII, DRASI, etc. were updated >> >> On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: >> >>> >>> Dear friends, >>> >>> >>> I am just trying to figure out how all the various scripts/commands work >>> together for setting up our DAQ system. Maybe, you can help to clearify some >>> things. >>> >>> >>> >>> - master.bash >> >> This would be intended to run on the readout board (RIO). The other >> scripts below is for the PC. >> >>> >>> source ../env/env.sh >>> ./trloii_setup.sh >>> # gdb --args \ >>> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ >>> --label=MCAL1 \ >>> --triva=master,fctime=10,ctime=50 \ >>> --log-no-rate-limit \ >>> --server=drasi,dest=lyserv \ >>> --buf=size=400Mi \ >>> --max-ev-size=0x1000000 \ >>> --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ >>> --eb=lyserv \ >>> "$@" >>> >>> In the first line some environment variables are set. The second line tells >>> the VULOM4 how to operate (i. e. selection from modes of operation defined >>> in vulom.trlo). Then DRASI is started with a bunch of parameters. Is there >>> somewhere an explanation of the purpose of all these settings? >> >> The drasi command line options should be described here: >> >> http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html > >> > >> >> (Note: 'lyserv' is the name of your PC, at least as seen from the RIO.) >> >> The TRLO II setup file (vulom.trlo) is worse in terms of documentation. >> The format as such is hopefully rather straightforward. A description is >> here: http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html > >> > . >> The actual meaning is more complex, the TRLO II description can be found >> here: >> >> http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html > >> > >> >> (left pane), which just is a colourised version of this: >> http://fy.chalmers.se/~f96hajo/trloii/description.txt > >> > >> >> It does not describe the .trlo file as such, but what the gateware tries >> to achieve. >> >>> And what is in the last line? I never came accross "$@" before. >> >> That would be all the (non-shifted, i.e. not removed) options given to the >> script itself, i.e. master.bash. >> >>> - eb.bash >>> >>> ../drasi/bin/lwrocmerge \ >>> >>> --label=MCAL_EB \ >>> --merge-mode=event \ >>> --server=trans,flush=1 \ >>> --server=stream,flush=1 \ >>> --buf=size=1600Mi \ >>> --max-ev-size=20Mi \ >>> --eb-master=rio4-mcal-1 \ >>> --file-writer \ >>> --drasi=rio4-mcal-1 >>> >>> What is the purpose of this command? >> >> This runs an 'event builder' on the PC. Not strictly needed, but this >> way, the RIO only ever needs to send data once, to this event-builder >> (EB). File writing, and streaming of on-line data is then handled by this >> process. It is cheaper to have better network cards and so on in a plain >> PC. >> >>> Why are values for buffer size and max >>> event size different then in the command before? >> >> The nomenclaturure is unfortunately a bit convoluted below with ucesb >> regards 'buffer size'. The --buf in the two commands above give the size >> of the memory used to buffer data inside the process, and depends on how >> much memory each machine has. The --max-ev-size tells how large each .lmd >> event can be. The --max-ev-size configured in the event builder needs to >> be as large as the sum of all event sources it has. I.e. should be able >> to be the same as in your single source above. >> >> In the readout itself, any event that is read out cannot be larger than >> this. If it is, then the DAQ will report a fatal failure. >> >>> - fanout.bash >>> >>> #!/bin/bash >>> while : >>> do >>> ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ >>> stream://localhost \ >>> --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 >>> sleep 5 >>> done >>> >>> This looks like setting up a connection point to the outside world, right? >> >> Yes. It accepts connections and will serve them data for online analysis. >> >> stream://localhost tells it where to read data (here the PC itself where >> it is running). Using the 'stream' protocol, which esentially is just raw >> LMD events. (As is the 'transport protocol'.) That will be served on the >> default port used for the stream server set up by the EB above. >> >> --server is then the server that accepts connections, and serves data on >> another port (8001). >> >>> And we find the third (random?) value for a buffer size. >> >> That bufsize is actually the LMD buffer size used by the stream server. >> The corresponding value in the readout and EB is set implicitly from the >> maximum event size... >> >>> - rate.bash >>> >>> ../drasi/bin/lwrocmon --rate rio4-mcal-1 >>> >>> Ok, this I understand. We can look the DAQ over the shoulder and see what >>> the thing is doing in terms of number of trigger events, transported data, >>> etc. >> >>> - log.bash >>> >>> ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost >>> >>> This is also easy to understand. >> >> :-) >> >> Then also try to do (on the PC) >> >> drasi/bin/lwrocmon --tree rio4-mcal-1 localhost >> >> which would show a 'tree-view' monitoring of the running system. >> >> >> Cheers, >> H?kan >> > -- > subexp-daq mailing list > subexp-daq at lists.chalmers.se > https://lists.chalmers.se/mailman/listinfo/subexp-daq > > -- 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: From f96hajo at chalmers.se Mon Jan 22 11:13:36 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Mon, 22 Jan 2024 11:13:36 +0100 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <0dc854ec60194f299b776bc263eb2c72@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <4e1e90ee-e985-42b2-a4e8-83f02d1c56b8@chalmers.se> <5b0a058d-b58c-4e73-a59b-24a40d59a3f1@chalmers.se> <68c6e7a91d354a35a08a6a89d181b9b6@hi-jena.gsi.de> <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de> <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <1aa0afb1bf1e4f91b5d2ab58eb0c62bb@hi-jena.gsi.de>, <810ed751-3a8a-43d7-b9b1-7d7c08f8fdf4@chalmers.se> <0dc854ec60194f299b776bc263eb2c72@hi-jena.gsi.de> Message-ID: <5f7958c3-297f-9303-efad-851c23f87ff0@chalmers.se> Dear G?nter, yes, r3bfuser depends on all of them (nurdlib, trloii, drasi), so needs a recompile. nurdlib also needs recompile if trloii is updated. Cheers, H?kan On Mon, 22 Jan 2024, Weber, Guenter Dr. wrote: > > Dear Hans, > > > I updated the NURDLIB, but the new flag is not recognized. > > > 10: config/parser.c:299: .Closed'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu > le_log_level.cfg' } > 5: config/keyword.c:20: .Invalid keyword "dactl". > 5: config/keyword.c:20: .Calling abort()... > > Do I also need to recompile DRASI or R3BFUSER? > > > > > Best greetings > > G?nter > > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von Hans > Toshihide T?rnqvist > Gesendet: Freitag, 19. Januar 2024 16:31:37 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, > DRASI, etc. were updated ? > Dear G?nter, > > I have implemented the dactl switch in 'mcal_daq_merge', so in main.cfg: > > GSI_VETAR { > ? dactl = false > ? direct = false > } > > I do not know how the names of the Etherbone libraries (e.g. cherry and > enigma) relate to the driver. If the dactl file is not available, we > just have to skip dactl accesses and not allow the direct readout path. > > Have a good weekend you too! > > Best regards, > Hans > > On 2024-01-19 15:22, Weber, Guenter Dr. wrote: > > Dear Hans, > > > > > > with the help of H?kan, I managed to get the VULOM running. So, we are > > back to starting the DRASI. There we encountered first the fact that in > > main.cfg a BARRIER is now required between the initialization of all > > modules (before there was only a single BARRIER command in the whole > > main.cfg. > > > > > > Now, we are again encounter the VETAR error message. See below: > > > > > > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: > > 56583). > > Thread has no error buffer yet... > > CPUS: 1 > > delay: 1 > > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: > > 56583). > > Thread has no error buffer yet... > > HOST: RIO4-MCAL-1 > > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] > > 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 > > (eth1). > > 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = > > 0x19000000, 1 consumers. > > 10: lwroc_triva_readout.c:66: Silence TRIVA? (HALT) > > 10: lwroc_net_io.c:167: Started server on port 56583 (data port 50126). > > client union size: 244 208 188 508 640 204 204? => 640 > > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: > > /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 > > 10: lwroc_main.c:706: Log message rate limit not in effect. > > 10: lwroc_readout.c:112: call readout_init... > > 10: lwroc_thread_util.c:117: This is the triva control thread! > > 10: lwroc_thread_util.c:117: This is the net io thread! > > 10: lwroc_thread_util.c:117: This is the slow_async thread! > > 10: lwroc_thread_util.c:117: This is the data server thread! > > 10: lwroc_message_internal.c:472: Message client connected! > > 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) > > [192.168.1.1]. > > 10: lwroc_triva_control.c:370: Setup TRIVA? (DISBUS, HALT, MASTER, RESET) > > 10: lwroc_triva_control.c:418: Minimum event time > > ctime(5000)+1*rd(688)+3*wr(634)+fctime(1000)=8590 ns (116.414 kHz) > > 10: lwroc_triva_state.c:1486: (Re)send ident messages... > > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 > > 9: lwroc_triva_control.c:507: TEST: GO > > 10: lwroc_triva_control.c:725: RUN: RESET > > 10: lwroc_triva_control.c:729: RUN: MT=14 > > 9: lwroc_triva_control.c:737:?? GO (1 good test triggers done) (max > > 116.4 kHz) > > 10: lwroc_triva_readout.c:376: Trigger 14 seen. > > 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. > > 10: config/parser.c:287: Opened > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/glob > al.cfg' { > > 10: config/parser.c:299: Closed > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/glob > al.cfg' } > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 > > (IN_READOUT).? EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 10: config/parser.c:287: Opened './main.cfg' { > > 10: config/config.c:1299: .Global log level=verbose. > > 10: config/parser.c:287: .Opened > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crat > e.cfg' { > > 10: config/parser.c:299: .Closed > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crat > e.cfg' } > > 10: config/parser.c:287: .Opened > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ > vulom.cfg' { > > 10: config/parser.c:299: .Closed > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ > vulom.cfg' } > > 10: config/parser.c:287: .Opened > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu > le_log_level.cfg' { > > 10: config/parser.c:299: .Closed > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu > le_log_level.cfg' } > > 10: config/parser.c:287: .Opened > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ > vetar.cfg' { > > 10: config/parser.c:299: .Closed > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ > vetar.cfg' } > > 10: config/parser.c:287: .Opened > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu > le_log_level.cfg' { > > 10: config/parser.c:299: .Closed > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu > le_log_level.cfg' } > > 10: config/parser.c:287: .Opened > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ > 3316.cfg' { > > 10: config/parser.c:299: .Closed > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ > 3316.cfg' } > > 10: config/parser.c:287: .Opened > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu > le_log_level.cfg' { > > 10: config/parser.c:299: .Closed > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu > le_log_level.cfg' } > > 10: config/parser.c:287: .Opened > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ > 3316.cfg' { > > 10: config/parser.c:299: .Closed > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ > 3316.cfg' } > > 10: config/parser.c:287: .Opened > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu > le_log_level.cfg' { > > 10: config/parser.c:299: .Closed > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu > le_log_level.cfg' } > > 10: config/parser.c:299: Closed './main.cfg' } > > 10: crate/crate.c:347: crate_create { > > 10: crate/crate.c:673: crate_create(MCAL) } > > 10: crate/crate.c:899: crate_init(MCAL) { > > 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. > > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) > > 10: crate/crate.c:923: .Slow-init module[1]=GSI_VETAR. > > 5: module/gsi_etherbone/gsi_etherbone.c:431: ..Gsi Etherbone > > /sys/class/vetar/vetar0/dactl: Failed dactl fopen: No such file or > > directory. > > 5: module/gsi_etherbone/gsi_etherbone.c:431: ..Calling abort()... > > > > We are sure that the right NURDLIB path is used and also DRASI is > > started in the correct folder. > > > > > > What we found in the enironment variables are two lines, where 'white > > rabbit' is mentioned. As I understand, this is connected to the VETAR2 > > module. > > > > > >LD_LIBRARY_PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/li > b:/mbsusr/mbsdaq/mbsrun/whiterabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib > >PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/bin:/bin:/bin > /ces:/usr/bin:/mbsusr/mbsdaq/bin:/usr/local/bin:/usr/bin/X11:/etc:/usr/etc > :.:/mbsusr/mbsdaq/tools > > > > Maybe, it is necessary to update something there? > > > > > > Anyway, if you have now a switch in NURDLIB to deal with old software > > for the VETAR, then we should proceed with removing NURDLIB and getting > > the newer version, right? > > > > > > > > > > Many thanks and have a nice weekend! > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > > > > ------------------------------------------------------------------------ > > *Von:* subexp-daq im Auftrag von > > Hans Toshihide T?rnqvist > > *Gesendet:* Donnerstag, 18. Januar 2024 13:28:36 > > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter > Dr. > > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > > TRLOII, DRASI, etc. were updated > > Dear G?nter, > > > > It looks like either the Vetar driver failed, or the fw/driver is old > > and nurdlib expects a file that didn't exist a while back. If it's the > > latter I can add a switch to ignore this file, it's not critical for > > readout and is used to enter a faster readout mode. > > > > Which version of nurdlib is this? The files and line numbers don't match > > with what I see in the source code, and the last time gsi_etherbone.c > > changed was early last year. > > > > The message "Could not open so-and-so" should be for the device, e.g. > > /dev/pcie_wb0. This is used for the readout. > > > > The dactl file should fail with "Failed dactl fopen". > > > > To summarise, I would suggest to make sure that the correct nurdlib and > > r3bfuser are executed by the DAQ scripts. Meanwhile I will prepare a > > switch to ignore the dactl file which could anyhow be useful for old > > configurations, and to clean up the Etherbone error messages. > > > > Best regards, > > Hans > > > > On 2024-01-18 11:29, Weber, Guenter Dr. wrote: > >> Dear friends, > >> > >> > >> I now started the DAQ and it looks like there is a problem with the > >> VETAR2 module. Attached please find the output once the DAQ is started > >> on the RIO4. > >> > >> > >> Here ist the error message: > >> > >> > >> 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866) > >> 11: a:1: .Gsi Etherbone init_slow { > >> (module/gsi_etherbone/gsi_etherbone.c:110) > >> 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No > >> such file or directory. > >>? ?(module/gsi_etherbone/gsi_etherbone.c:120) > >> 5: a:1: ..Calling exit(EXIT_FAILURE)... > >> (module/gsi_etherbone/gsi_etherbone.c:120) > >> > >> How to proceed? > >> > >> > >> > >> Many thanks and best greetings > >> G?nter > >> > >> > >> > >> > >> ------------------------------------------------------------------------ > >> *Von:* subexp-daq im Auftrag von > >> H?kan T Johansson > >> *Gesendet:* Dienstag, 16. Januar 2024 19:20:54 > >> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > >> *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > >> TRLOII, DRASI, etc. were updated > >> > >> On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: > >> > >>> > >>> Dear friends, > >>> > >>> > >>> I am just trying to figure out how all the various scripts/commands work > >>> together for setting up our DAQ system. Maybe, you can help to clearify > some > >>> things. > >>> > >>> > >>> > >>> - master.bash > >> > >> This would be intended to run on the readout board (RIO).? The other > >> scripts below is for the PC. > >> > >>> > >>> source ../env/env.sh > >>> ./trloii_setup.sh > >>> # gdb --args \ > >>> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ > >>> ? ? ? ? --label=MCAL1 \ > >>> ? ? ? ? --triva=master,fctime=10,ctime=50 \ > >>> ? ? ? ? --log-no-rate-limit \ > >>> ? ? ? ? --server=drasi,dest=lyserv \ > >>> ? ? ? ? --buf=size=400Mi \ > >>> ? ? ? ? --max-ev-size=0x1000000 \ > >>> ? ? ? ? --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ > >>> ? ? ? ? --eb=lyserv \ > >>> ? ? ? ? "$@" > >>> > >>> In the first line some environment variables are set. The second line > tells > >>> the VULOM4 how to operate (i. e. selection from modes of operation > defined > >>> in vulom.trlo). Then DRASI is started with a bunch of parameters. Is > there > >>> somewhere an explanation of the purpose of all these settings? > >> > >> The drasi command line options should be described here: > >> > >> http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html > > > >> > > > >> > >> (Note: 'lyserv' is the name of your PC, at least as seen from the RIO.) > >> > >> The TRLO II setup file (vulom.trlo) is worse in terms of documentation. > >> The format as such is hopefully rather straightforward.? A description is > >> here: http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html > > > >> > > . > >> The actual meaning is more complex, the TRLO II description can be found > >> here: > >> > >> http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html > > > >> > > > >> > >> (left pane), which just is a colourised version of this: > >> http://fy.chalmers.se/~f96hajo/trloii/description.txt > > > >> > > > >> > >> It does not describe the .trlo file as such, but what the gateware tries > >> to achieve. > >> > >>> And what is in the last line? I never came accross "$@" before. > >> > >> That would be all the (non-shifted, i.e. not removed) options given to > the > >> script itself, i.e. master.bash. > >> > >>> - eb.bash > >>> > >>> ../drasi/bin/lwrocmerge \ > >>> > >>> ? ? --label=MCAL_EB \ > >>> ? ? --merge-mode=event \ > >>> ? ? --server=trans,flush=1 \ > >>> ? ? --server=stream,flush=1 \ > >>> ? ? --buf=size=1600Mi \ > >>> ? ? --max-ev-size=20Mi \ > >>> ? ? --eb-master=rio4-mcal-1 \ > >>> ? ? --file-writer \ > >>> ? ? --drasi=rio4-mcal-1 > >>> > >>> What is the purpose of this command? > >> > >> This runs an 'event builder' on the PC.? Not strictly needed, but this > >> way, the RIO only ever needs to send data once, to this event-builder > >> (EB).? File writing, and streaming of on-line data is then handled by > this > >> process.? It is cheaper to have better network cards and so on in a plain > >> PC. > >> > >>> Why are values for buffer size and max > >>> event size different then in the command before? > >> > >> The nomenclaturure is unfortunately a bit convoluted below with ucesb > >> regards 'buffer size'.? The --buf in the two commands above give the size > >> of the memory used to buffer data inside the process, and depends on how > >> much memory each machine has.? The --max-ev-size tells how large each > .lmd > >> event can be.? The --max-ev-size configured in the event builder needs to > >> be as large as the sum of all event sources it has.? I.e. should be able > >> to be the same as in your single source above. > >> > >> In the readout itself, any event that is read out cannot be larger than > >> this.? If it is, then the DAQ will report a fatal failure. > >> > >>> - fanout.bash > >>> > >>> #!/bin/bash > >>> while : > >>> do > >>> ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ > >>> ? ? stream://localhost \ > >>> ? ? --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 > >>> sleep 5 > >>> done??? > >>> > >>> This looks like setting up a connection point to the outside world, > right? > >> > >> Yes.? It accepts connections and will serve them data for online > analysis. > >> > >> stream://localhost? tells it where to read data (here the PC itself where > >> it is running).? Using the 'stream' protocol, which esentially is just > raw > >> LMD events.? (As is the 'transport protocol'.)? That will be served on > the > >> default port used for the stream server set up by the EB above. > >> > >> --server is then the server that accepts connections, and serves data on > >> another port (8001). > >> > >>> And we find the third (random?) value for a buffer size. > >> > >> That bufsize is actually the LMD buffer size used by the stream server. > >> The corresponding value in the readout and EB is set implicitly from the > >> maximum event size... > >> > >>> - rate.bash > >>> > >>> ../drasi/bin/lwrocmon --rate rio4-mcal-1 > >>> > >>> Ok, this I understand. We can look the DAQ over the shoulder and see > what > >>> the thing is doing in terms of number of trigger events, transported > data, > >>> etc. > >> > >>> - log.bash > >>> > >>> ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost > >>> > >>> This is also easy to understand. > >> > >> :-) > >> > >> Then also try to do (on the PC) > >> > >> drasi/bin/lwrocmon --tree rio4-mcal-1 localhost > >> > >> which would show a 'tree-view' monitoring of the running system. > >> > >> > >> Cheers, > >> H?kan > >> > > -- > > subexp-daq mailing list > > subexp-daq at lists.chalmers.se > > https://lists.chalmers.se/mailman/listinfo/subexp-daq > > > > > -- > subexp-daq mailing list > subexp-daq at lists.chalmers.se > https://lists.chalmers.se/mailman/listinfo/subexp-daq > > From g.weber at hi-jena.gsi.de Mon Jan 22 11:40:41 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Mon, 22 Jan 2024 10:40:41 +0000 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <5f7958c3-297f-9303-efad-851c23f87ff0@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <4e1e90ee-e985-42b2-a4e8-83f02d1c56b8@chalmers.se> <5b0a058d-b58c-4e73-a59b-24a40d59a3f1@chalmers.se> <68c6e7a91d354a35a08a6a89d181b9b6@hi-jena.gsi.de> <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de> <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <1aa0afb1bf1e4f91b5d2ab58eb0c62bb@hi-jena.gsi.de>, <810ed751-3a8a-43d7-b9b1-7d7c08f8fdf4@chalmers.se> <0dc854ec60194f299b776bc263eb2c72@hi-jena.gsi.de>, <5f7958c3-297f-9303-efad-851c23f87ff0@chalmers.se> Message-ID: <897201d9f3424d318c7ed49ce4106aaa@hi-jena.gsi.de> Dear Hans, dear H?kan, I now recompiled R3BFUSER, but still I get the same error message when starting DRASI. This is how the beginning how the beginning of main.cfg looks like: log_level=verbose # info, verbose, debug, spam CRATE("MCAL") { GSI_VULOM(0x03000000) { timestamp = true # needed to get timestamps in the data output } BARRIER GSI_VETAR { dactl = false direct = false } BARRIER SIS_3316(0x30000000) { ... Do you have any idea why the dactl command is not find found? Maybe NURDLIB on GITLAB does not have the modified VETAR files yet? I have next to zero experience, so probably I am wrong. But if the last change in MODULE is from six days ago, it might not be the most recent version, right? [cid:5f466f60-98e4-492f-9be7-7b138bb94c72] Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Montag, 22. Januar 2024 11:13:36 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated Dear G?nter, yes, r3bfuser depends on all of them (nurdlib, trloii, drasi), so needs a recompile. nurdlib also needs recompile if trloii is updated. Cheers, H?kan On Mon, 22 Jan 2024, Weber, Guenter Dr. wrote: > > Dear Hans, > > > I updated the NURDLIB, but the new flag is not recognized. > > > 10: config/parser.c:299: .Closed'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu > le_log_level.cfg' } > 5: config/keyword.c:20: .Invalid keyword "dactl". > 5: config/keyword.c:20: .Calling abort()... > > Do I also need to recompile DRASI or R3BFUSER? > > > > > Best greetings > > G?nter > > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von Hans > Toshihide T?rnqvist > Gesendet: Freitag, 19. Januar 2024 16:31:37 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, > DRASI, etc. were updated > Dear G?nter, > > I have implemented the dactl switch in 'mcal_daq_merge', so in main.cfg: > > GSI_VETAR { > dactl = false > direct = false > } > > I do not know how the names of the Etherbone libraries (e.g. cherry and > enigma) relate to the driver. If the dactl file is not available, we > just have to skip dactl accesses and not allow the direct readout path. > > Have a good weekend you too! > > Best regards, > Hans > > On 2024-01-19 15:22, Weber, Guenter Dr. wrote: > > Dear Hans, > > > > > > with the help of H?kan, I managed to get the VULOM running. So, we are > > back to starting the DRASI. There we encountered first the fact that in > > main.cfg a BARRIER is now required between the initialization of all > > modules (before there was only a single BARRIER command in the whole > > main.cfg. > > > > > > Now, we are again encounter the VETAR error message. See below: > > > > > > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: > > 56583). > > Thread has no error buffer yet... > > CPUS: 1 > > delay: 1 > > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: > > 56583). > > Thread has no error buffer yet... > > HOST: RIO4-MCAL-1 > > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] > > 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 > > (eth1). > > 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = > > 0x19000000, 1 consumers. > > 10: lwroc_triva_readout.c:66: Silence TRIVA (HALT) > > 10: lwroc_net_io.c:167: Started server on port 56583 (data port 50126). > > client union size: 244 208 188 508 640 204 204 => 640 > > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: > > /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 > > 10: lwroc_main.c:706: Log message rate limit not in effect. > > 10: lwroc_readout.c:112: call readout_init... > > 10: lwroc_thread_util.c:117: This is the triva control thread! > > 10: lwroc_thread_util.c:117: This is the net io thread! > > 10: lwroc_thread_util.c:117: This is the slow_async thread! > > 10: lwroc_thread_util.c:117: This is the data server thread! > > 10: lwroc_message_internal.c:472: Message client connected! > > 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) > > [192.168.1.1]. > > 10: lwroc_triva_control.c:370: Setup TRIVA (DISBUS, HALT, MASTER, RESET) > > 10: lwroc_triva_control.c:418: Minimum event time > > ctime(5000)+1*rd(688)+3*wr(634)+fctime(1000)=8590 ns (116.414 kHz) > > 10: lwroc_triva_state.c:1486: (Re)send ident messages... > > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 > > 9: lwroc_triva_control.c:507: TEST: GO > > 10: lwroc_triva_control.c:725: RUN: RESET > > 10: lwroc_triva_control.c:729: RUN: MT=14 > > 9: lwroc_triva_control.c:737: GO (1 good test triggers done) (max > > 116.4 kHz) > > 10: lwroc_triva_readout.c:376: Trigger 14 seen. > > 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. > > 10: config/parser.c:287: Opened > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/glob > al.cfg' { > > 10: config/parser.c:299: Closed > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/glob > al.cfg' } > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 > > (IN_READOUT). EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 10: config/parser.c:287: Opened './main.cfg' { > > 10: config/config.c:1299: .Global log level=verbose. > > 10: config/parser.c:287: .Opened > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crat > e.cfg' { > > 10: config/parser.c:299: .Closed > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crat > e.cfg' } > > 10: config/parser.c:287: .Opened > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ > vulom.cfg' { > > 10: config/parser.c:299: .Closed > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ > vulom.cfg' } > > 10: config/parser.c:287: .Opened > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu > le_log_level.cfg' { > > 10: config/parser.c:299: .Closed > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu > le_log_level.cfg' } > > 10: config/parser.c:287: .Opened > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ > vetar.cfg' { > > 10: config/parser.c:299: .Closed > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ > vetar.cfg' } > > 10: config/parser.c:287: .Opened > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu > le_log_level.cfg' { > > 10: config/parser.c:299: .Closed > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu > le_log_level.cfg' } > > 10: config/parser.c:287: .Opened > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ > 3316.cfg' { > > 10: config/parser.c:299: .Closed > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ > 3316.cfg' } > > 10: config/parser.c:287: .Opened > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu > le_log_level.cfg' { > > 10: config/parser.c:299: .Closed > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu > le_log_level.cfg' } > > 10: config/parser.c:287: .Opened > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ > 3316.cfg' { > > 10: config/parser.c:299: .Closed > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ > 3316.cfg' } > > 10: config/parser.c:287: .Opened > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu > le_log_level.cfg' { > > 10: config/parser.c:299: .Closed > >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu > le_log_level.cfg' } > > 10: config/parser.c:299: Closed './main.cfg' } > > 10: crate/crate.c:347: crate_create { > > 10: crate/crate.c:673: crate_create(MCAL) } > > 10: crate/crate.c:899: crate_init(MCAL) { > > 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. > > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) > > 10: crate/crate.c:923: .Slow-init module[1]=GSI_VETAR. > > 5: module/gsi_etherbone/gsi_etherbone.c:431: ..Gsi Etherbone > > /sys/class/vetar/vetar0/dactl: Failed dactl fopen: No such file or > > directory. > > 5: module/gsi_etherbone/gsi_etherbone.c:431: ..Calling abort()... > > > > We are sure that the right NURDLIB path is used and also DRASI is > > started in the correct folder. > > > > > > What we found in the enironment variables are two lines, where 'white > > rabbit' is mentioned. As I understand, this is connected to the VETAR2 > > module. > > > > > >LD_LIBRARY_PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/li > b:/mbsusr/mbsdaq/mbsrun/whiterabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib > >PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/bin:/bin:/bin > /ces:/usr/bin:/mbsusr/mbsdaq/bin:/usr/local/bin:/usr/bin/X11:/etc:/usr/etc > :.:/mbsusr/mbsdaq/tools > > > > Maybe, it is necessary to update something there? > > > > > > Anyway, if you have now a switch in NURDLIB to deal with old software > > for the VETAR, then we should proceed with removing NURDLIB and getting > > the newer version, right? > > > > > > > > > > Many thanks and have a nice weekend! > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > > > > ------------------------------------------------------------------------ > > *Von:* subexp-daq im Auftrag von > > Hans Toshihide T?rnqvist > > *Gesendet:* Donnerstag, 18. Januar 2024 13:28:36 > > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter > Dr. > > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > > TRLOII, DRASI, etc. were updated > > Dear G?nter, > > > > It looks like either the Vetar driver failed, or the fw/driver is old > > and nurdlib expects a file that didn't exist a while back. If it's the > > latter I can add a switch to ignore this file, it's not critical for > > readout and is used to enter a faster readout mode. > > > > Which version of nurdlib is this? The files and line numbers don't match > > with what I see in the source code, and the last time gsi_etherbone.c > > changed was early last year. > > > > The message "Could not open so-and-so" should be for the device, e.g. > > /dev/pcie_wb0. This is used for the readout. > > > > The dactl file should fail with "Failed dactl fopen". > > > > To summarise, I would suggest to make sure that the correct nurdlib and > > r3bfuser are executed by the DAQ scripts. Meanwhile I will prepare a > > switch to ignore the dactl file which could anyhow be useful for old > > configurations, and to clean up the Etherbone error messages. > > > > Best regards, > > Hans > > > > On 2024-01-18 11:29, Weber, Guenter Dr. wrote: > >> Dear friends, > >> > >> > >> I now started the DAQ and it looks like there is a problem with the > >> VETAR2 module. Attached please find the output once the DAQ is started > >> on the RIO4. > >> > >> > >> Here ist the error message: > >> > >> > >> 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866) > >> 11: a:1: .Gsi Etherbone init_slow { > >> (module/gsi_etherbone/gsi_etherbone.c:110) > >> 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No > >> such file or directory. > >> (module/gsi_etherbone/gsi_etherbone.c:120) > >> 5: a:1: ..Calling exit(EXIT_FAILURE)... > >> (module/gsi_etherbone/gsi_etherbone.c:120) > >> > >> How to proceed? > >> > >> > >> > >> Many thanks and best greetings > >> G?nter > >> > >> > >> > >> > >> ------------------------------------------------------------------------ > >> *Von:* subexp-daq im Auftrag von > >> H?kan T Johansson > >> *Gesendet:* Dienstag, 16. Januar 2024 19:20:54 > >> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > >> *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > >> TRLOII, DRASI, etc. were updated > >> > >> On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: > >> > >>> > >>> Dear friends, > >>> > >>> > >>> I am just trying to figure out how all the various scripts/commands work > >>> together for setting up our DAQ system. Maybe, you can help to clearify > some > >>> things. > >>> > >>> > >>> > >>> - master.bash > >> > >> This would be intended to run on the readout board (RIO). The other > >> scripts below is for the PC. > >> > >>> > >>> source ../env/env.sh > >>> ./trloii_setup.sh > >>> # gdb --args \ > >>> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ > >>> --label=MCAL1 \ > >>> --triva=master,fctime=10,ctime=50 \ > >>> --log-no-rate-limit \ > >>> --server=drasi,dest=lyserv \ > >>> --buf=size=400Mi \ > >>> --max-ev-size=0x1000000 \ > >>> --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ > >>> --eb=lyserv \ > >>> "$@" > >>> > >>> In the first line some environment variables are set. The second line > tells > >>> the VULOM4 how to operate (i. e. selection from modes of operation > defined > >>> in vulom.trlo). Then DRASI is started with a bunch of parameters. Is > there > >>> somewhere an explanation of the purpose of all these settings? > >> > >> The drasi command line options should be described here: > >> > >> http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html > > > >> > > > >> > >> (Note: 'lyserv' is the name of your PC, at least as seen from the RIO.) > >> > >> The TRLO II setup file (vulom.trlo) is worse in terms of documentation. > >> The format as such is hopefully rather straightforward. A description is > >> here: http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html > > > >> > > . > >> The actual meaning is more complex, the TRLO II description can be found > >> here: > >> > >> http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html > > > >> > > > >> > >> (left pane), which just is a colourised version of this: > >> http://fy.chalmers.se/~f96hajo/trloii/description.txt > > > >> > > > >> > >> It does not describe the .trlo file as such, but what the gateware tries > >> to achieve. > >> > >>> And what is in the last line? I never came accross "$@" before. > >> > >> That would be all the (non-shifted, i.e. not removed) options given to > the > >> script itself, i.e. master.bash. > >> > >>> - eb.bash > >>> > >>> ../drasi/bin/lwrocmerge \ > >>> > >>> --label=MCAL_EB \ > >>> --merge-mode=event \ > >>> --server=trans,flush=1 \ > >>> --server=stream,flush=1 \ > >>> --buf=size=1600Mi \ > >>> --max-ev-size=20Mi \ > >>> --eb-master=rio4-mcal-1 \ > >>> --file-writer \ > >>> --drasi=rio4-mcal-1 > >>> > >>> What is the purpose of this command? > >> > >> This runs an 'event builder' on the PC. Not strictly needed, but this > >> way, the RIO only ever needs to send data once, to this event-builder > >> (EB). File writing, and streaming of on-line data is then handled by > this > >> process. It is cheaper to have better network cards and so on in a plain > >> PC. > >> > >>> Why are values for buffer size and max > >>> event size different then in the command before? > >> > >> The nomenclaturure is unfortunately a bit convoluted below with ucesb > >> regards 'buffer size'. The --buf in the two commands above give the size > >> of the memory used to buffer data inside the process, and depends on how > >> much memory each machine has. The --max-ev-size tells how large each > .lmd > >> event can be. The --max-ev-size configured in the event builder needs to > >> be as large as the sum of all event sources it has. I.e. should be able > >> to be the same as in your single source above. > >> > >> In the readout itself, any event that is read out cannot be larger than > >> this. If it is, then the DAQ will report a fatal failure. > >> > >>> - fanout.bash > >>> > >>> #!/bin/bash > >>> while : > >>> do > >>> ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ > >>> stream://localhost \ > >>> --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 > >>> sleep 5 > >>> done > >>> > >>> This looks like setting up a connection point to the outside world, > right? > >> > >> Yes. It accepts connections and will serve them data for online > analysis. > >> > >> stream://localhost tells it where to read data (here the PC itself where > >> it is running). Using the 'stream' protocol, which esentially is just > raw > >> LMD events. (As is the 'transport protocol'.) That will be served on > the > >> default port used for the stream server set up by the EB above. > >> > >> --server is then the server that accepts connections, and serves data on > >> another port (8001). > >> > >>> And we find the third (random?) value for a buffer size. > >> > >> That bufsize is actually the LMD buffer size used by the stream server. > >> The corresponding value in the readout and EB is set implicitly from the > >> maximum event size... > >> > >>> - rate.bash > >>> > >>> ../drasi/bin/lwrocmon --rate rio4-mcal-1 > >>> > >>> Ok, this I understand. We can look the DAQ over the shoulder and see > what > >>> the thing is doing in terms of number of trigger events, transported > data, > >>> etc. > >> > >>> - log.bash > >>> > >>> ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost > >>> > >>> This is also easy to understand. > >> > >> :-) > >> > >> Then also try to do (on the PC) > >> > >> drasi/bin/lwrocmon --tree rio4-mcal-1 localhost > >> > >> which would show a 'tree-view' monitoring of the running system. > >> > >> > >> Cheers, > >> H?kan > >> > > -- > > subexp-daq mailing list > > subexp-daq at lists.chalmers.se > > https://lists.chalmers.se/mailman/listinfo/subexp-daq > > > > > -- > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: pastedImage.png Type: image/png Size: 168174 bytes Desc: pastedImage.png URL: From hans.tornqvist at chalmers.se Mon Jan 22 11:46:56 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Mon, 22 Jan 2024 11:46:56 +0100 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <897201d9f3424d318c7ed49ce4106aaa@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <5b0a058d-b58c-4e73-a59b-24a40d59a3f1@chalmers.se> <68c6e7a91d354a35a08a6a89d181b9b6@hi-jena.gsi.de> <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de> <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <1aa0afb1bf1e4f91b5d2ab58eb0c62bb@hi-jena.gsi.de> <810ed751-3a8a-43d7-b9b1-7d7c08f8fdf4@chalmers.se> <0dc854ec60194f299b776bc263eb2c72@hi-jena.gsi.de> <5f7958c3-297f-9303-efad-851c23f87ff0@chalmers.se> <897201d9f3424d318c7ed49ce4106aaa@hi-jena.gsi.de> Message-ID: <7f6060e5-ccad-48ba-927e-cb749bea290a@chalmers.se> Dear G?nter, I'm sorry, my discipline slipped and I forgot to push that commit also to the public Gitlab... It's available there now. Best regards, Hans On 2024-01-22 11:40, Weber, Guenter Dr. wrote: > Dear Hans, dear H?kan, > > > I now recompiled R3BFUSER, but still I get the same error message when > starting DRASI. > > > This is how the beginning how the beginning of main.cfg looks like: > > > log_level=verbose # info, verbose, debug, spam > CRATE("MCAL") { > ? ? GSI_VULOM(0x03000000) { > ? ? ? ? timestamp = true # needed to get timestamps in the data output > ? ? } > ? ? BARRIER > ? ? GSI_VETAR { > ? ? ? ? dactl = false > ? ? ? ? direct = false > ? ? } > ? ? BARRIER > ? ? SIS_3316(0x30000000) { > ... > > Do you have any idea why the dactl command is not find found? Maybe > NURDLIB on GITLAB does not have the modified VETAR files yet? I have > next to zero experience, so probably I am wrong. But if the last change > in MODULE is from six days ago, it might not be the most recent version, > right? > > > > > > Best greetings > > G?nter > > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > H?kan T Johansson > *Gesendet:* Montag, 22. Januar 2024 11:13:36 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > TRLOII, DRASI, etc. were updated > > Dear G?nter, > > yes, r3bfuser depends on all of them (nurdlib, trloii, drasi), so needs a > recompile.? nurdlib also needs recompile if trloii is updated. > > Cheers, > H?kan > > > On Mon, 22 Jan 2024, Weber, Guenter Dr. wrote: > >> >> Dear Hans, >> >> >> I updated the NURDLIB, but the new flag is not recognized. >> >> >> 10: config/parser.c:299: .Closed'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >> le_log_level.cfg' } >> 5: config/keyword.c:20: .Invalid keyword "dactl". >> 5: config/keyword.c:20: .Calling abort()... >> >> Do I also need to recompile DRASI or R3BFUSER? >> >> >> >> >> Best greetings >> >> G?nter >> >> >> >> ____________________________________________________________________________ >> Von: subexp-daq im Auftrag von Hans >> Toshihide T?rnqvist >> Gesendet: Freitag, 19. Januar 2024 16:31:37 >> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, >> DRASI, etc. were updated >> Dear G?nter, >> >> I have implemented the dactl switch in 'mcal_daq_merge', so in main.cfg: >> >> GSI_VETAR { >> ? dactl = false >> ? direct = false >> } >> >> I do not know how the names of the Etherbone libraries (e.g. cherry and >> enigma) relate to the driver. If the dactl file is not available, we >> just have to skip dactl accesses and not allow the direct readout path. >> >> Have a good weekend you too! >> >> Best regards, >> Hans >> >> On 2024-01-19 15:22, Weber, Guenter Dr. wrote: >> > Dear Hans, >> > >> > >> > with the help of H?kan, I managed to get the VULOM running. So, we are >> > back to starting the DRASI. There we encountered first the fact that in >> > main.cfg a BARRIER is now required between the initialization of all >> > modules (before there was only a single BARRIER command in the whole >> > main.cfg. >> > >> > >> > Now, we are again encounter the VETAR error message. See below: >> > >> > >> > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: >> > 56583). >> > Thread has no error buffer yet... >> > CPUS: 1 >> > delay: 1 >> > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: >> > 56583). >> > Thread has no error buffer yet... >> > HOST: RIO4-MCAL-1 >> > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] >> > 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 >> > (eth1). >> > 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = >> > 0x19000000, 1 consumers. >> > 10: lwroc_triva_readout.c:66: Silence TRIVA? (HALT) >> > 10: lwroc_net_io.c:167: Started server on port 56583 (data port 50126). >> > client union size: 244 208 188 508 640 204 204? => 640 >> > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: >> > /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 >> > 10: lwroc_main.c:706: Log message rate limit not in effect. >> > 10: lwroc_readout.c:112: call readout_init... >> > 10: lwroc_thread_util.c:117: This is the triva control thread! >> > 10: lwroc_thread_util.c:117: This is the net io thread! >> > 10: lwroc_thread_util.c:117: This is the slow_async thread! >> > 10: lwroc_thread_util.c:117: This is the data server thread! >> > 10: lwroc_message_internal.c:472: Message client connected! >> > 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) >> > [192.168.1.1]. >> > 10: lwroc_triva_control.c:370: Setup TRIVA? (DISBUS, HALT, MASTER, RESET) >> > 10: lwroc_triva_control.c:418: Minimum event time >> > ctime(5000)+1*rd(688)+3*wr(634)+fctime(1000)=8590 ns (116.414 kHz) >> > 10: lwroc_triva_state.c:1486: (Re)send ident messages... >> > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 >> > 9: lwroc_triva_control.c:507: TEST: GO >> > 10: lwroc_triva_control.c:725: RUN: RESET >> > 10: lwroc_triva_control.c:729: RUN: MT=14 >> > 9: lwroc_triva_control.c:737:?? GO (1 good test triggers done) (max >> > 116.4 kHz) >> > 10: lwroc_triva_readout.c:376: Trigger 14 seen. >> > 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. >> > 10: config/parser.c:287: Opened >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/glob >> al.cfg' { >> > 10: config/parser.c:299: Closed >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/glob >> al.cfg' } >> > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 >> > (IN_READOUT).? EC: 1 >> > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> > 10: config/parser.c:287: Opened './main.cfg' { >> > 10: config/config.c:1299: .Global log level=verbose. >> > 10: config/parser.c:287: .Opened >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crat >> e.cfg' { >> > 10: config/parser.c:299: .Closed >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crat >> e.cfg' } >> > 10: config/parser.c:287: .Opened >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ >> vulom.cfg' { >> > 10: config/parser.c:299: .Closed >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ >> vulom.cfg' } >> > 10: config/parser.c:287: .Opened >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >> le_log_level.cfg' { >> > 10: config/parser.c:299: .Closed >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >> le_log_level.cfg' } >> > 10: config/parser.c:287: .Opened >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ >> vetar.cfg' { >> > 10: config/parser.c:299: .Closed >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ >> vetar.cfg' } >> > 10: config/parser.c:287: .Opened >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >> le_log_level.cfg' { >> > 10: config/parser.c:299: .Closed >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >> le_log_level.cfg' } >> > 10: config/parser.c:287: .Opened >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ >> 3316.cfg' { >> > 10: config/parser.c:299: .Closed >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ >> 3316.cfg' } >> > 10: config/parser.c:287: .Opened >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >> le_log_level.cfg' { >> > 10: config/parser.c:299: .Closed >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >> le_log_level.cfg' } >> > 10: config/parser.c:287: .Opened >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ >> 3316.cfg' { >> > 10: config/parser.c:299: .Closed >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ >> 3316.cfg' } >> > 10: config/parser.c:287: .Opened >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >> le_log_level.cfg' { >> > 10: config/parser.c:299: .Closed >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >> le_log_level.cfg' } >> > 10: config/parser.c:299: Closed './main.cfg' } >> > 10: crate/crate.c:347: crate_create { >> > 10: crate/crate.c:673: crate_create(MCAL) } >> > 10: crate/crate.c:899: crate_init(MCAL) { >> > 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. >> > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) >> > 10: crate/crate.c:923: .Slow-init module[1]=GSI_VETAR. >> > 5: module/gsi_etherbone/gsi_etherbone.c:431: ..Gsi Etherbone >> > /sys/class/vetar/vetar0/dactl: Failed dactl fopen: No such file or >> > directory. >> > 5: module/gsi_etherbone/gsi_etherbone.c:431: ..Calling abort()... >> > >> > We are sure that the right NURDLIB path is used and also DRASI is >> > started in the correct folder. >> > >> > >> > What we found in the enironment variables are two lines, where 'white >> > rabbit' is mentioned. As I understand, this is connected to the VETAR2 >> > module. >> > >> > >> >LD_LIBRARY_PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/li >> b:/mbsusr/mbsdaq/mbsrun/whiterabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib >> >PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/bin:/bin:/bin >> /ces:/usr/bin:/mbsusr/mbsdaq/bin:/usr/local/bin:/usr/bin/X11:/etc:/usr/etc >> :.:/mbsusr/mbsdaq/tools >> > >> > Maybe, it is necessary to update something there? >> > >> > >> > Anyway, if you have now a switch in NURDLIB to deal with old software >> > for the VETAR, then we should proceed with removing NURDLIB and getting >> > the newer version, right? >> > >> > >> > >> > >> > Many thanks and have a nice weekend! >> > >> > >> > >> > >> > Best greetings >> > >> > G?nter >> > >> > >> > >> > >> > ------------------------------------------------------------------------ >> > *Von:* subexp-daq im Auftrag von >> > Hans Toshihide T?rnqvist >> > *Gesendet:* Donnerstag, 18. Januar 2024 13:28:36 >> > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter >> Dr. >> > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >> > TRLOII, DRASI, etc. were updated >> > Dear G?nter, >> > >> > It looks like either the Vetar driver failed, or the fw/driver is old >> > and nurdlib expects a file that didn't exist a while back. If it's the >> > latter I can add a switch to ignore this file, it's not critical for >> > readout and is used to enter a faster readout mode. >> > >> > Which version of nurdlib is this? The files and line numbers don't match >> > with what I see in the source code, and the last time gsi_etherbone.c >> > changed was early last year. >> > >> > The message "Could not open so-and-so" should be for the device, e.g. >> > /dev/pcie_wb0. This is used for the readout. >> > >> > The dactl file should fail with "Failed dactl fopen". >> > >> > To summarise, I would suggest to make sure that the correct nurdlib and >> > r3bfuser are executed by the DAQ scripts. Meanwhile I will prepare a >> > switch to ignore the dactl file which could anyhow be useful for old >> > configurations, and to clean up the Etherbone error messages. >> > >> > Best regards, >> > Hans >> > >> > On 2024-01-18 11:29, Weber, Guenter Dr. wrote: >> >> Dear friends, >> >> >> >> >> >> I now started the DAQ and it looks like there is a problem with the >> >> VETAR2 module. Attached please find the output once the DAQ is started >> >> on the RIO4. >> >> >> >> >> >> Here ist the error message: >> >> >> >> >> >> 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866) >> >> 11: a:1: .Gsi Etherbone init_slow { >> >> (module/gsi_etherbone/gsi_etherbone.c:110) >> >> 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No >> >> such file or directory. >> >>? ?(module/gsi_etherbone/gsi_etherbone.c:120) >> >> 5: a:1: ..Calling exit(EXIT_FAILURE)... >> >> (module/gsi_etherbone/gsi_etherbone.c:120) >> >> >> >> How to proceed? >> >> >> >> >> >> >> >> Many thanks and best greetings >> >> G?nter >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> *Von:* subexp-daq im Auftrag von >> >> H?kan T Johansson >> >> *Gesendet:* Dienstag, 16. Januar 2024 19:20:54 >> >> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> >> *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >> >> TRLOII, DRASI, etc. were updated >> >> >> >> On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: >> >> >> >>> >> >>> Dear friends, >> >>> >> >>> >> >>> I am just trying to figure out how all the various scripts/commands work >> >>> together for setting up our DAQ system. Maybe, you can help to clearify >> some >> >>> things. >> >>> >> >>> >> >>> >> >>> - master.bash >> >> >> >> This would be intended to run on the readout board (RIO).? The other >> >> scripts below is for the PC. >> >> >> >>> >> >>> source ../env/env.sh >> >>> ./trloii_setup.sh >> >>> # gdb --args \ >> >>> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ >> >>> ? ? ? ? --label=MCAL1 \ >> >>> ? ? ? ? --triva=master,fctime=10,ctime=50 \ >> >>> ? ? ? ? --log-no-rate-limit \ >> >>> ? ? ? ? --server=drasi,dest=lyserv \ >> >>> ? ? ? ? --buf=size=400Mi \ >> >>> ? ? ? ? --max-ev-size=0x1000000 \ >> >>> ? ? ? ? --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ >> >>> ? ? ? ? --eb=lyserv \ >> >>> ? ? ? ? "$@" >> >>> >> >>> In the first line some environment variables are set. The second line >> tells >> >>> the VULOM4 how to operate (i. e. selection from modes of operation >> defined >> >>> in vulom.trlo). Then DRASI is started with a bunch of parameters. Is >> there >> >>> somewhere an explanation of the purpose of all these settings? >> >> >> >> The drasi command line options should be described here: >> >> >> >> http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html > >> > > >> >> > > >> >> >> >> >> (Note: 'lyserv' is the name of your PC, at least as seen from the RIO.) >> >> >> >> The TRLO II setup file (vulom.trlo) is worse in terms of documentation. >> >> The format as such is hopefully rather straightforward.? A description is >> >> here: http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html > >> > > >> >> > > >> . >> >> The actual meaning is more complex, the TRLO II description can be found >> >> here: >> >> >> >> http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html > >> > > >> >> > > >> >> >> >> >> (left pane), which just is a colourised version of this: >> >> http://fy.chalmers.se/~f96hajo/trloii/description.txt > >> > > >> >> > > >> >> >> >> >> It does not describe the .trlo file as such, but what the gateware tries >> >> to achieve. >> >> >> >>> And what is in the last line? I never came accross "$@" before. >> >> >> >> That would be all the (non-shifted, i.e. not removed) options given to >> the >> >> script itself, i.e. master.bash. >> >> >> >>> - eb.bash >> >>> >> >>> ../drasi/bin/lwrocmerge \ >> >>> >> >>> ? ? --label=MCAL_EB \ >> >>> ? ? --merge-mode=event \ >> >>> ? ? --server=trans,flush=1 \ >> >>> ? ? --server=stream,flush=1 \ >> >>> ? ? --buf=size=1600Mi \ >> >>> ? ? --max-ev-size=20Mi \ >> >>> ? ? --eb-master=rio4-mcal-1 \ >> >>> ? ? --file-writer \ >> >>> ? ? --drasi=rio4-mcal-1 >> >>> >> >>> What is the purpose of this command? >> >> >> >> This runs an 'event builder' on the PC.? Not strictly needed, but this >> >> way, the RIO only ever needs to send data once, to this event-builder >> >> (EB).? File writing, and streaming of on-line data is then handled by >> this >> >> process.? It is cheaper to have better network cards and so on in a plain >> >> PC. >> >> >> >>> Why are values for buffer size and max >> >>> event size different then in the command before? >> >> >> >> The nomenclaturure is unfortunately a bit convoluted below with ucesb >> >> regards 'buffer size'.? The --buf in the two commands above give the size >> >> of the memory used to buffer data inside the process, and depends on how >> >> much memory each machine has.? The --max-ev-size tells how large each >> .lmd >> >> event can be.? The --max-ev-size configured in the event builder needs to >> >> be as large as the sum of all event sources it has.? I.e. should be able >> >> to be the same as in your single source above. >> >> >> >> In the readout itself, any event that is read out cannot be larger than >> >> this.? If it is, then the DAQ will report a fatal failure. >> >> >> >>> - fanout.bash >> >>> >> >>> #!/bin/bash >> >>> while : >> >>> do >> >>> ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ >> >>> ? ? stream://localhost \ >> >>> ? ? --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 >> >>> sleep 5 >> >>> done >> >>> >> >>> This looks like setting up a connection point to the outside world, >> right? >> >> >> >> Yes.? It accepts connections and will serve them data for online >> analysis. >> >> >> >> stream://localhost? tells it where to read data (here the PC itself where >> >> it is running).? Using the 'stream' protocol, which esentially is just >> raw >> >> LMD events.? (As is the 'transport protocol'.)? That will be served on >> the >> >> default port used for the stream server set up by the EB above. >> >> >> >> --server is then the server that accepts connections, and serves data on >> >> another port (8001). >> >> >> >>> And we find the third (random?) value for a buffer size. >> >> >> >> That bufsize is actually the LMD buffer size used by the stream server. >> >> The corresponding value in the readout and EB is set implicitly from the >> >> maximum event size... >> >> >> >>> - rate.bash >> >>> >> >>> ../drasi/bin/lwrocmon --rate rio4-mcal-1 >> >>> >> >>> Ok, this I understand. We can look the DAQ over the shoulder and see >> what >> >>> the thing is doing in terms of number of trigger events, transported >> data, >> >>> etc. >> >> >> >>> - log.bash >> >>> >> >>> ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost >> >>> >> >>> This is also easy to understand. >> >> >> >> :-) >> >> >> >> Then also try to do (on the PC) >> >> >> >> drasi/bin/lwrocmon --tree rio4-mcal-1 localhost >> >> >> >> which would show a 'tree-view' monitoring of the running system. >> >> >> >> >> >> Cheers, >> >> H?kan >> >> >> > -- >> > subexp-daq mailing list >> > subexp-daq at lists.chalmers.se >> > https://lists.chalmers.se/mailman/listinfo/subexp-daq > >> > > >> > >> -- >> subexp-daq mailing list >> subexp-daq at lists.chalmers.se >> https://lists.chalmers.se/mailman/listinfo/subexp-daq > >> >> > From g.weber at hi-jena.gsi.de Mon Jan 22 13:16:28 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Mon, 22 Jan 2024 12:16:28 +0000 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <7f6060e5-ccad-48ba-927e-cb749bea290a@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <5b0a058d-b58c-4e73-a59b-24a40d59a3f1@chalmers.se> <68c6e7a91d354a35a08a6a89d181b9b6@hi-jena.gsi.de> <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de> <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <1aa0afb1bf1e4f91b5d2ab58eb0c62bb@hi-jena.gsi.de> <810ed751-3a8a-43d7-b9b1-7d7c08f8fdf4@chalmers.se> <0dc854ec60194f299b776bc263eb2c72@hi-jena.gsi.de> <5f7958c3-297f-9303-efad-851c23f87ff0@chalmers.se> <897201d9f3424d318c7ed49ce4106aaa@hi-jena.gsi.de>, <7f6060e5-ccad-48ba-927e-cb749bea290a@chalmers.se> Message-ID: <2d0ecc20c1ee4921b5ed807b41251fe5@hi-jena.gsi.de> Alright. Thank you. The next problem looks like this: 10: config/parser.c:299: Closed './main.cfg' } 10: crate/crate.c:347: crate_create { 5: config/config.c:376: ..Block 'GSI_VETAR' (./main.cfg:8:2) does not have requested param [0]. 5: config/config.c:376: ..Calling abort()... Maybe, the interpreter for the main.cfg is now a bit more strict than before? Is it maybe the module hardware address that is missing? But this was not needed before for some weird reason (how does the software know where to look for the VETAR then?). Best greetings and sorry for all these problems ? G?nter ________________________________ Von: subexp-daq im Auftrag von Hans Toshihide T?rnqvist Gesendet: Montag, 22. Januar 2024 11:46:56 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated Dear G?nter, I'm sorry, my discipline slipped and I forgot to push that commit also to the public Gitlab... It's available there now. Best regards, Hans On 2024-01-22 11:40, Weber, Guenter Dr. wrote: > Dear Hans, dear H?kan, > > > I now recompiled R3BFUSER, but still I get the same error message when > starting DRASI. > > > This is how the beginning how the beginning of main.cfg looks like: > > > log_level=verbose # info, verbose, debug, spam > CRATE("MCAL") { > GSI_VULOM(0x03000000) { > timestamp = true # needed to get timestamps in the data output > } > BARRIER > GSI_VETAR { > dactl = false > direct = false > } > BARRIER > SIS_3316(0x30000000) { > ... > > Do you have any idea why the dactl command is not find found? Maybe > NURDLIB on GITLAB does not have the modified VETAR files yet? I have > next to zero experience, so probably I am wrong. But if the last change > in MODULE is from six days ago, it might not be the most recent version, > right? > > > > > > Best greetings > > G?nter > > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > H?kan T Johansson > *Gesendet:* Montag, 22. Januar 2024 11:13:36 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > TRLOII, DRASI, etc. were updated > > Dear G?nter, > > yes, r3bfuser depends on all of them (nurdlib, trloii, drasi), so needs a > recompile. nurdlib also needs recompile if trloii is updated. > > Cheers, > H?kan > > > On Mon, 22 Jan 2024, Weber, Guenter Dr. wrote: > >> >> Dear Hans, >> >> >> I updated the NURDLIB, but the new flag is not recognized. >> >> >> 10: config/parser.c:299: .Closed'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >> le_log_level.cfg' } >> 5: config/keyword.c:20: .Invalid keyword "dactl". >> 5: config/keyword.c:20: .Calling abort()... >> >> Do I also need to recompile DRASI or R3BFUSER? >> >> >> >> >> Best greetings >> >> G?nter >> >> >> >> ____________________________________________________________________________ >> Von: subexp-daq im Auftrag von Hans >> Toshihide T?rnqvist >> Gesendet: Freitag, 19. Januar 2024 16:31:37 >> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, >> DRASI, etc. were updated >> Dear G?nter, >> >> I have implemented the dactl switch in 'mcal_daq_merge', so in main.cfg: >> >> GSI_VETAR { >> dactl = false >> direct = false >> } >> >> I do not know how the names of the Etherbone libraries (e.g. cherry and >> enigma) relate to the driver. If the dactl file is not available, we >> just have to skip dactl accesses and not allow the direct readout path. >> >> Have a good weekend you too! >> >> Best regards, >> Hans >> >> On 2024-01-19 15:22, Weber, Guenter Dr. wrote: >> > Dear Hans, >> > >> > >> > with the help of H?kan, I managed to get the VULOM running. So, we are >> > back to starting the DRASI. There we encountered first the fact that in >> > main.cfg a BARRIER is now required between the initialization of all >> > modules (before there was only a single BARRIER command in the whole >> > main.cfg. >> > >> > >> > Now, we are again encounter the VETAR error message. See below: >> > >> > >> > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: >> > 56583). >> > Thread has no error buffer yet... >> > CPUS: 1 >> > delay: 1 >> > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: >> > 56583). >> > Thread has no error buffer yet... >> > HOST: RIO4-MCAL-1 >> > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] >> > 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 >> > (eth1). >> > 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = >> > 0x19000000, 1 consumers. >> > 10: lwroc_triva_readout.c:66: Silence TRIVA (HALT) >> > 10: lwroc_net_io.c:167: Started server on port 56583 (data port 50126). >> > client union size: 244 208 188 508 640 204 204 => 640 >> > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: >> > /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 >> > 10: lwroc_main.c:706: Log message rate limit not in effect. >> > 10: lwroc_readout.c:112: call readout_init... >> > 10: lwroc_thread_util.c:117: This is the triva control thread! >> > 10: lwroc_thread_util.c:117: This is the net io thread! >> > 10: lwroc_thread_util.c:117: This is the slow_async thread! >> > 10: lwroc_thread_util.c:117: This is the data server thread! >> > 10: lwroc_message_internal.c:472: Message client connected! >> > 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) >> > [192.168.1.1]. >> > 10: lwroc_triva_control.c:370: Setup TRIVA (DISBUS, HALT, MASTER, RESET) >> > 10: lwroc_triva_control.c:418: Minimum event time >> > ctime(5000)+1*rd(688)+3*wr(634)+fctime(1000)=8590 ns (116.414 kHz) >> > 10: lwroc_triva_state.c:1486: (Re)send ident messages... >> > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 >> > 9: lwroc_triva_control.c:507: TEST: GO >> > 10: lwroc_triva_control.c:725: RUN: RESET >> > 10: lwroc_triva_control.c:729: RUN: MT=14 >> > 9: lwroc_triva_control.c:737: GO (1 good test triggers done) (max >> > 116.4 kHz) >> > 10: lwroc_triva_readout.c:376: Trigger 14 seen. >> > 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. >> > 10: config/parser.c:287: Opened >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/glob >> al.cfg' { >> > 10: config/parser.c:299: Closed >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/glob >> al.cfg' } >> > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 >> > (IN_READOUT). EC: 1 >> > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> > 10: config/parser.c:287: Opened './main.cfg' { >> > 10: config/config.c:1299: .Global log level=verbose. >> > 10: config/parser.c:287: .Opened >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crat >> e.cfg' { >> > 10: config/parser.c:299: .Closed >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crat >> e.cfg' } >> > 10: config/parser.c:287: .Opened >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ >> vulom.cfg' { >> > 10: config/parser.c:299: .Closed >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ >> vulom.cfg' } >> > 10: config/parser.c:287: .Opened >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >> le_log_level.cfg' { >> > 10: config/parser.c:299: .Closed >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >> le_log_level.cfg' } >> > 10: config/parser.c:287: .Opened >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ >> vetar.cfg' { >> > 10: config/parser.c:299: .Closed >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ >> vetar.cfg' } >> > 10: config/parser.c:287: .Opened >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >> le_log_level.cfg' { >> > 10: config/parser.c:299: .Closed >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >> le_log_level.cfg' } >> > 10: config/parser.c:287: .Opened >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ >> 3316.cfg' { >> > 10: config/parser.c:299: .Closed >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ >> 3316.cfg' } >> > 10: config/parser.c:287: .Opened >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >> le_log_level.cfg' { >> > 10: config/parser.c:299: .Closed >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >> le_log_level.cfg' } >> > 10: config/parser.c:287: .Opened >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ >> 3316.cfg' { >> > 10: config/parser.c:299: .Closed >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ >> 3316.cfg' } >> > 10: config/parser.c:287: .Opened >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >> le_log_level.cfg' { >> > 10: config/parser.c:299: .Closed >> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >> le_log_level.cfg' } >> > 10: config/parser.c:299: Closed './main.cfg' } >> > 10: crate/crate.c:347: crate_create { >> > 10: crate/crate.c:673: crate_create(MCAL) } >> > 10: crate/crate.c:899: crate_init(MCAL) { >> > 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. >> > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) >> > 10: crate/crate.c:923: .Slow-init module[1]=GSI_VETAR. >> > 5: module/gsi_etherbone/gsi_etherbone.c:431: ..Gsi Etherbone >> > /sys/class/vetar/vetar0/dactl: Failed dactl fopen: No such file or >> > directory. >> > 5: module/gsi_etherbone/gsi_etherbone.c:431: ..Calling abort()... >> > >> > We are sure that the right NURDLIB path is used and also DRASI is >> > started in the correct folder. >> > >> > >> > What we found in the enironment variables are two lines, where 'white >> > rabbit' is mentioned. As I understand, this is connected to the VETAR2 >> > module. >> > >> > >> >LD_LIBRARY_PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/li >> b:/mbsusr/mbsdaq/mbsrun/whiterabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib >> >PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/bin:/bin:/bin >> /ces:/usr/bin:/mbsusr/mbsdaq/bin:/usr/local/bin:/usr/bin/X11:/etc:/usr/etc >> :.:/mbsusr/mbsdaq/tools >> > >> > Maybe, it is necessary to update something there? >> > >> > >> > Anyway, if you have now a switch in NURDLIB to deal with old software >> > for the VETAR, then we should proceed with removing NURDLIB and getting >> > the newer version, right? >> > >> > >> > >> > >> > Many thanks and have a nice weekend! >> > >> > >> > >> > >> > Best greetings >> > >> > G?nter >> > >> > >> > >> > >> > ------------------------------------------------------------------------ >> > *Von:* subexp-daq im Auftrag von >> > Hans Toshihide T?rnqvist >> > *Gesendet:* Donnerstag, 18. Januar 2024 13:28:36 >> > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter >> Dr. >> > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >> > TRLOII, DRASI, etc. were updated >> > Dear G?nter, >> > >> > It looks like either the Vetar driver failed, or the fw/driver is old >> > and nurdlib expects a file that didn't exist a while back. If it's the >> > latter I can add a switch to ignore this file, it's not critical for >> > readout and is used to enter a faster readout mode. >> > >> > Which version of nurdlib is this? The files and line numbers don't match >> > with what I see in the source code, and the last time gsi_etherbone.c >> > changed was early last year. >> > >> > The message "Could not open so-and-so" should be for the device, e.g. >> > /dev/pcie_wb0. This is used for the readout. >> > >> > The dactl file should fail with "Failed dactl fopen". >> > >> > To summarise, I would suggest to make sure that the correct nurdlib and >> > r3bfuser are executed by the DAQ scripts. Meanwhile I will prepare a >> > switch to ignore the dactl file which could anyhow be useful for old >> > configurations, and to clean up the Etherbone error messages. >> > >> > Best regards, >> > Hans >> > >> > On 2024-01-18 11:29, Weber, Guenter Dr. wrote: >> >> Dear friends, >> >> >> >> >> >> I now started the DAQ and it looks like there is a problem with the >> >> VETAR2 module. Attached please find the output once the DAQ is started >> >> on the RIO4. >> >> >> >> >> >> Here ist the error message: >> >> >> >> >> >> 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866) >> >> 11: a:1: .Gsi Etherbone init_slow { >> >> (module/gsi_etherbone/gsi_etherbone.c:110) >> >> 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No >> >> such file or directory. >> >> (module/gsi_etherbone/gsi_etherbone.c:120) >> >> 5: a:1: ..Calling exit(EXIT_FAILURE)... >> >> (module/gsi_etherbone/gsi_etherbone.c:120) >> >> >> >> How to proceed? >> >> >> >> >> >> >> >> Many thanks and best greetings >> >> G?nter >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> *Von:* subexp-daq im Auftrag von >> >> H?kan T Johansson >> >> *Gesendet:* Dienstag, 16. Januar 2024 19:20:54 >> >> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> >> *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >> >> TRLOII, DRASI, etc. were updated >> >> >> >> On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: >> >> >> >>> >> >>> Dear friends, >> >>> >> >>> >> >>> I am just trying to figure out how all the various scripts/commands work >> >>> together for setting up our DAQ system. Maybe, you can help to clearify >> some >> >>> things. >> >>> >> >>> >> >>> >> >>> - master.bash >> >> >> >> This would be intended to run on the readout board (RIO). The other >> >> scripts below is for the PC. >> >> >> >>> >> >>> source ../env/env.sh >> >>> ./trloii_setup.sh >> >>> # gdb --args \ >> >>> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ >> >>> --label=MCAL1 \ >> >>> --triva=master,fctime=10,ctime=50 \ >> >>> --log-no-rate-limit \ >> >>> --server=drasi,dest=lyserv \ >> >>> --buf=size=400Mi \ >> >>> --max-ev-size=0x1000000 \ >> >>> --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ >> >>> --eb=lyserv \ >> >>> "$@" >> >>> >> >>> In the first line some environment variables are set. The second line >> tells >> >>> the VULOM4 how to operate (i. e. selection from modes of operation >> defined >> >>> in vulom.trlo). Then DRASI is started with a bunch of parameters. Is >> there >> >>> somewhere an explanation of the purpose of all these settings? >> >> >> >> The drasi command line options should be described here: >> >> >> >> http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html > >> > > >> >> > > >> >> >> >> >> (Note: 'lyserv' is the name of your PC, at least as seen from the RIO.) >> >> >> >> The TRLO II setup file (vulom.trlo) is worse in terms of documentation. >> >> The format as such is hopefully rather straightforward. A description is >> >> here: http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html > >> > > >> >> > > >> . >> >> The actual meaning is more complex, the TRLO II description can be found >> >> here: >> >> >> >> http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html > >> > > >> >> > > >> >> >> >> >> (left pane), which just is a colourised version of this: >> >> http://fy.chalmers.se/~f96hajo/trloii/description.txt > >> > > >> >> > > >> >> >> >> >> It does not describe the .trlo file as such, but what the gateware tries >> >> to achieve. >> >> >> >>> And what is in the last line? I never came accross "$@" before. >> >> >> >> That would be all the (non-shifted, i.e. not removed) options given to >> the >> >> script itself, i.e. master.bash. >> >> >> >>> - eb.bash >> >>> >> >>> ../drasi/bin/lwrocmerge \ >> >>> >> >>> --label=MCAL_EB \ >> >>> --merge-mode=event \ >> >>> --server=trans,flush=1 \ >> >>> --server=stream,flush=1 \ >> >>> --buf=size=1600Mi \ >> >>> --max-ev-size=20Mi \ >> >>> --eb-master=rio4-mcal-1 \ >> >>> --file-writer \ >> >>> --drasi=rio4-mcal-1 >> >>> >> >>> What is the purpose of this command? >> >> >> >> This runs an 'event builder' on the PC. Not strictly needed, but this >> >> way, the RIO only ever needs to send data once, to this event-builder >> >> (EB). File writing, and streaming of on-line data is then handled by >> this >> >> process. It is cheaper to have better network cards and so on in a plain >> >> PC. >> >> >> >>> Why are values for buffer size and max >> >>> event size different then in the command before? >> >> >> >> The nomenclaturure is unfortunately a bit convoluted below with ucesb >> >> regards 'buffer size'. The --buf in the two commands above give the size >> >> of the memory used to buffer data inside the process, and depends on how >> >> much memory each machine has. The --max-ev-size tells how large each >> .lmd >> >> event can be. The --max-ev-size configured in the event builder needs to >> >> be as large as the sum of all event sources it has. I.e. should be able >> >> to be the same as in your single source above. >> >> >> >> In the readout itself, any event that is read out cannot be larger than >> >> this. If it is, then the DAQ will report a fatal failure. >> >> >> >>> - fanout.bash >> >>> >> >>> #!/bin/bash >> >>> while : >> >>> do >> >>> ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ >> >>> stream://localhost \ >> >>> --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 >> >>> sleep 5 >> >>> done >> >>> >> >>> This looks like setting up a connection point to the outside world, >> right? >> >> >> >> Yes. It accepts connections and will serve them data for online >> analysis. >> >> >> >> stream://localhost tells it where to read data (here the PC itself where >> >> it is running). Using the 'stream' protocol, which esentially is just >> raw >> >> LMD events. (As is the 'transport protocol'.) That will be served on >> the >> >> default port used for the stream server set up by the EB above. >> >> >> >> --server is then the server that accepts connections, and serves data on >> >> another port (8001). >> >> >> >>> And we find the third (random?) value for a buffer size. >> >> >> >> That bufsize is actually the LMD buffer size used by the stream server. >> >> The corresponding value in the readout and EB is set implicitly from the >> >> maximum event size... >> >> >> >>> - rate.bash >> >>> >> >>> ../drasi/bin/lwrocmon --rate rio4-mcal-1 >> >>> >> >>> Ok, this I understand. We can look the DAQ over the shoulder and see >> what >> >>> the thing is doing in terms of number of trigger events, transported >> data, >> >>> etc. >> >> >> >>> - log.bash >> >>> >> >>> ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost >> >>> >> >>> This is also easy to understand. >> >> >> >> :-) >> >> >> >> Then also try to do (on the PC) >> >> >> >> drasi/bin/lwrocmon --tree rio4-mcal-1 localhost >> >> >> >> which would show a 'tree-view' monitoring of the running system. >> >> >> >> >> >> Cheers, >> >> H?kan >> >> >> > -- >> > subexp-daq mailing list >> > subexp-daq at lists.chalmers.se >> > https://lists.chalmers.se/mailman/listinfo/subexp-daq > >> > > >> > >> -- >> subexp-daq mailing list >> subexp-daq at lists.chalmers.se >> https://lists.chalmers.se/mailman/listinfo/subexp-daq > >> >> > -- 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: From hans.tornqvist at chalmers.se Mon Jan 22 14:15:01 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Mon, 22 Jan 2024 14:15:01 +0100 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <2d0ecc20c1ee4921b5ed807b41251fe5@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de> <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <1aa0afb1bf1e4f91b5d2ab58eb0c62bb@hi-jena.gsi.de> <810ed751-3a8a-43d7-b9b1-7d7c08f8fdf4@chalmers.se> <0dc854ec60194f299b776bc263eb2c72@hi-jena.gsi.de> <5f7958c3-297f-9303-efad-851c23f87ff0@chalmers.se> <897201d9f3424d318c7ed49ce4106aaa@hi-jena.gsi.de> <7f6060e5-ccad-48ba-927e-cb749bea290a@chalmers.se> <2d0ecc20c1ee4921b5ed807b41251fe5@hi-jena.gsi.de> Message-ID: <8fb50894-080f-4bf8-8ed3-f7a965de1b55@chalmers.se> On 2024-01-22 13:16, Weber, Guenter Dr. wrote: > The next problem looks like this: > > 10: config/parser.c:299: Closed './main.cfg' } > 10: crate/crate.c:347: crate_create { > 5: config/config.c:376: ..Block 'GSI_VETAR' (./main.cfg:8:2) does not > have requested param [0]. > 5: config/config.c:376: ..Calling abort()... > > Maybe, the interpreter for the main.cfg is now a bit more strict than > before? Is it maybe the module hardware address that is missing? But > this was not needed before for some weird reason (how does the software > know where to look for the VETAR then?). Aha, back then the Vetars we bought and the template implementations we received were always on address 0x50000000 (7 zeros) and that was hardcoded into nurdlib. Meanwhile I tried other addresses which worked, so the config now requires this. I would prefer to keep this explicit and update old config files, since it is rather useful information. So, please try GSI_VETAR(0x50000000) {...} > Best greetings and sorry for all these problems ? Many problems are due to me not having been proactive enough, especially with external users to keep the software more up-to-date, for which I would like to apologise. This adventure has fixed a huge number things in my backlog, I appreciate your work and patience a lot! Your trials will benefit many other DAQ users who rely on these codes :) Best regards, Hans > G?nter > > > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > Hans Toshihide T?rnqvist > *Gesendet:* Montag, 22. Januar 2024 11:46:56 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > TRLOII, DRASI, etc. were updated > Dear G?nter, > > I'm sorry, my discipline slipped and I forgot to push that commit also > to the public Gitlab... It's available there now. > > Best regards, > Hans > > On 2024-01-22 11:40, Weber, Guenter Dr. wrote: >> Dear Hans, dear H?kan, >> >> >> I now recompiled R3BFUSER, but still I get the same error message when >> starting DRASI. >> >> >> This is how the beginning how the beginning of main.cfg looks like: >> >> >> log_level=verbose # info, verbose, debug, spam >> CRATE("MCAL") { >>? ? ? GSI_VULOM(0x03000000) { >>? ? ? ? ? timestamp = true # needed to get timestamps in the data output >>? ? ? } >>? ? ? BARRIER >>? ? ? GSI_VETAR { >>? ? ? ? ? dactl = false >>? ? ? ? ? direct = false >>? ? ? } >>? ? ? BARRIER >>? ? ? SIS_3316(0x30000000) { >> ... >> >> Do you have any idea why the dactl command is not find found? Maybe >> NURDLIB on GITLAB does not have the modified VETAR files yet? I have >> next to zero experience, so probably I am wrong. But if the last change >> in MODULE is from six days ago, it might not be the most recent version, >> right? >> >> >> >> >> >> Best greetings >> >> G?nter >> >> >> >> ------------------------------------------------------------------------ >> *Von:* subexp-daq im Auftrag von >> H?kan T Johansson >> *Gesendet:* Montag, 22. Januar 2024 11:13:36 >> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >> TRLOII, DRASI, etc. were updated >> >> Dear G?nter, >> >> yes, r3bfuser depends on all of them (nurdlib, trloii, drasi), so needs a >> recompile.? nurdlib also needs recompile if trloii is updated. >> >> Cheers, >> H?kan >> >> >> On Mon, 22 Jan 2024, Weber, Guenter Dr. wrote: >> >>> >>> Dear Hans, >>> >>> >>> I updated the NURDLIB, but the new flag is not recognized. >>> >>> >>> 10: config/parser.c:299: .Closed'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>> le_log_level.cfg' } >>> 5: config/keyword.c:20: .Invalid keyword "dactl". >>> 5: config/keyword.c:20: .Calling abort()... >>> >>> Do I also need to recompile DRASI or R3BFUSER? >>> >>> >>> >>> >>> Best greetings >>> >>> G?nter >>> >>> >>> >>> ____________________________________________________________________________ >>> Von: subexp-daq im Auftrag von Hans >>> Toshihide T?rnqvist >>> Gesendet: Freitag, 19. Januar 2024 16:31:37 >>> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >>> Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, >>> DRASI, etc. were updated >>> Dear G?nter, >>> >>> I have implemented the dactl switch in 'mcal_daq_merge', so in main.cfg: >>> >>> GSI_VETAR { >>> ? dactl = false >>> ? direct = false >>> } >>> >>> I do not know how the names of the Etherbone libraries (e.g. cherry and >>> enigma) relate to the driver. If the dactl file is not available, we >>> just have to skip dactl accesses and not allow the direct readout path. >>> >>> Have a good weekend you too! >>> >>> Best regards, >>> Hans >>> >>> On 2024-01-19 15:22, Weber, Guenter Dr. wrote: >>> > Dear Hans, >>> > >>> > >>> > with the help of H?kan, I managed to get the VULOM running. So, we are >>> > back to starting the DRASI. There we encountered first the fact that in >>> > main.cfg a BARRIER is now required between the initialization of all >>> > modules (before there was only a single BARRIER command in the whole >>> > main.cfg. >>> > >>> > >>> > Now, we are again encounter the VETAR error message. See below: >>> > >>> > >>> > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: >>> > 56583). >>> > Thread has no error buffer yet... >>> > CPUS: 1 >>> > delay: 1 >>> > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: >>> > 56583). >>> > Thread has no error buffer yet... >>> > HOST: RIO4-MCAL-1 >>> > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] >>> > 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 >>> > (eth1). >>> > 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = >>> > 0x19000000, 1 consumers. >>> > 10: lwroc_triva_readout.c:66: Silence TRIVA? (HALT) >>> > 10: lwroc_net_io.c:167: Started server on port 56583 (data port 50126). >>> > client union size: 244 208 188 508 640 204 204? => 640 >>> > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: >>> > /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 >>> > 10: lwroc_main.c:706: Log message rate limit not in effect. >>> > 10: lwroc_readout.c:112: call readout_init... >>> > 10: lwroc_thread_util.c:117: This is the triva control thread! >>> > 10: lwroc_thread_util.c:117: This is the net io thread! >>> > 10: lwroc_thread_util.c:117: This is the slow_async thread! >>> > 10: lwroc_thread_util.c:117: This is the data server thread! >>> > 10: lwroc_message_internal.c:472: Message client connected! >>> > 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) >>> > [192.168.1.1]. >>> > 10: lwroc_triva_control.c:370: Setup TRIVA? (DISBUS, HALT, MASTER, RESET) >>> > 10: lwroc_triva_control.c:418: Minimum event time >>> > ctime(5000)+1*rd(688)+3*wr(634)+fctime(1000)=8590 ns (116.414 kHz) >>> > 10: lwroc_triva_state.c:1486: (Re)send ident messages... >>> > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 >>> > 9: lwroc_triva_control.c:507: TEST: GO >>> > 10: lwroc_triva_control.c:725: RUN: RESET >>> > 10: lwroc_triva_control.c:729: RUN: MT=14 >>> > 9: lwroc_triva_control.c:737:?? GO (1 good test triggers done) (max >>> > 116.4 kHz) >>> > 10: lwroc_triva_readout.c:376: Trigger 14 seen. >>> > 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. >>> > 10: config/parser.c:287: Opened >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/glob >>> al.cfg' { >>> > 10: config/parser.c:299: Closed >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/glob >>> al.cfg' } >>> > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 >>> > (IN_READOUT).? EC: 1 >>> > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >>> > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >>> > 10: config/parser.c:287: Opened './main.cfg' { >>> > 10: config/config.c:1299: .Global log level=verbose. >>> > 10: config/parser.c:287: .Opened >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crat >>> e.cfg' { >>> > 10: config/parser.c:299: .Closed >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crat >>> e.cfg' } >>> > 10: config/parser.c:287: .Opened >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ >>> vulom.cfg' { >>> > 10: config/parser.c:299: .Closed >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ >>> vulom.cfg' } >>> > 10: config/parser.c:287: .Opened >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>> le_log_level.cfg' { >>> > 10: config/parser.c:299: .Closed >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>> le_log_level.cfg' } >>> > 10: config/parser.c:287: .Opened >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ >>> vetar.cfg' { >>> > 10: config/parser.c:299: .Closed >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ >>> vetar.cfg' } >>> > 10: config/parser.c:287: .Opened >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>> le_log_level.cfg' { >>> > 10: config/parser.c:299: .Closed >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>> le_log_level.cfg' } >>> > 10: config/parser.c:287: .Opened >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ >>> 3316.cfg' { >>> > 10: config/parser.c:299: .Closed >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ >>> 3316.cfg' } >>> > 10: config/parser.c:287: .Opened >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>> le_log_level.cfg' { >>> > 10: config/parser.c:299: .Closed >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>> le_log_level.cfg' } >>> > 10: config/parser.c:287: .Opened >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ >>> 3316.cfg' { >>> > 10: config/parser.c:299: .Closed >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ >>> 3316.cfg' } >>> > 10: config/parser.c:287: .Opened >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>> le_log_level.cfg' { >>> > 10: config/parser.c:299: .Closed >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>> le_log_level.cfg' } >>> > 10: config/parser.c:299: Closed './main.cfg' } >>> > 10: crate/crate.c:347: crate_create { >>> > 10: crate/crate.c:673: crate_create(MCAL) } >>> > 10: crate/crate.c:899: crate_init(MCAL) { >>> > 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. >>> > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) >>> > 10: crate/crate.c:923: .Slow-init module[1]=GSI_VETAR. >>> > 5: module/gsi_etherbone/gsi_etherbone.c:431: ..Gsi Etherbone >>> > /sys/class/vetar/vetar0/dactl: Failed dactl fopen: No such file or >>> > directory. >>> > 5: module/gsi_etherbone/gsi_etherbone.c:431: ..Calling abort()... >>> > >>> > We are sure that the right NURDLIB path is used and also DRASI is >>> > started in the correct folder. >>> > >>> > >>> > What we found in the enironment variables are two lines, where 'white >>> > rabbit' is mentioned. As I understand, this is connected to the VETAR2 >>> > module. >>> > >>> > >>> >LD_LIBRARY_PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/li >>> b:/mbsusr/mbsdaq/mbsrun/whiterabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib >>> >PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/bin:/bin:/bin >>> /ces:/usr/bin:/mbsusr/mbsdaq/bin:/usr/local/bin:/usr/bin/X11:/etc:/usr/etc >>> :.:/mbsusr/mbsdaq/tools >>> > >>> > Maybe, it is necessary to update something there? >>> > >>> > >>> > Anyway, if you have now a switch in NURDLIB to deal with old software >>> > for the VETAR, then we should proceed with removing NURDLIB and getting >>> > the newer version, right? >>> > >>> > >>> > >>> > >>> > Many thanks and have a nice weekend! >>> > >>> > >>> > >>> > >>> > Best greetings >>> > >>> > G?nter >>> > >>> > >>> > >>> > >>> > ------------------------------------------------------------------------ >>> > *Von:* subexp-daq im Auftrag von >>> > Hans Toshihide T?rnqvist >>> > *Gesendet:* Donnerstag, 18. Januar 2024 13:28:36 >>> > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter >>> Dr. >>> > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >>> > TRLOII, DRASI, etc. were updated >>> > Dear G?nter, >>> > >>> > It looks like either the Vetar driver failed, or the fw/driver is old >>> > and nurdlib expects a file that didn't exist a while back. If it's the >>> > latter I can add a switch to ignore this file, it's not critical for >>> > readout and is used to enter a faster readout mode. >>> > >>> > Which version of nurdlib is this? The files and line numbers don't match >>> > with what I see in the source code, and the last time gsi_etherbone.c >>> > changed was early last year. >>> > >>> > The message "Could not open so-and-so" should be for the device, e.g. >>> > /dev/pcie_wb0. This is used for the readout. >>> > >>> > The dactl file should fail with "Failed dactl fopen". >>> > >>> > To summarise, I would suggest to make sure that the correct nurdlib and >>> > r3bfuser are executed by the DAQ scripts. Meanwhile I will prepare a >>> > switch to ignore the dactl file which could anyhow be useful for old >>> > configurations, and to clean up the Etherbone error messages. >>> > >>> > Best regards, >>> > Hans >>> > >>> > On 2024-01-18 11:29, Weber, Guenter Dr. wrote: >>> >> Dear friends, >>> >> >>> >> >>> >> I now started the DAQ and it looks like there is a problem with the >>> >> VETAR2 module. Attached please find the output once the DAQ is started >>> >> on the RIO4. >>> >> >>> >> >>> >> Here ist the error message: >>> >> >>> >> >>> >> 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866) >>> >> 11: a:1: .Gsi Etherbone init_slow { >>> >> (module/gsi_etherbone/gsi_etherbone.c:110) >>> >> 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No >>> >> such file or directory. >>> >>? ?(module/gsi_etherbone/gsi_etherbone.c:120) >>> >> 5: a:1: ..Calling exit(EXIT_FAILURE)... >>> >> (module/gsi_etherbone/gsi_etherbone.c:120) >>> >> >>> >> How to proceed? >>> >> >>> >> >>> >> >>> >> Many thanks and best greetings >>> >> G?nter >>> >> >>> >> >>> >> >>> >> >>> >> ------------------------------------------------------------------------ >>> >> *Von:* subexp-daq im Auftrag von >>> >> H?kan T Johansson >>> >> *Gesendet:* Dienstag, 16. Januar 2024 19:20:54 >>> >> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. >>> >> *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >>> >> TRLOII, DRASI, etc. were updated >>> >> >>> >> On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: >>> >> >>> >>> >>> >>> Dear friends, >>> >>> >>> >>> >>> >>> I am just trying to figure out how all the various scripts/commands work >>> >>> together for setting up our DAQ system. Maybe, you can help to clearify >>> some >>> >>> things. >>> >>> >>> >>> >>> >>> >>> >>> - master.bash >>> >> >>> >> This would be intended to run on the readout board (RIO).? The other >>> >> scripts below is for the PC. >>> >> >>> >>> >>> >>> source ../env/env.sh >>> >>> ./trloii_setup.sh >>> >>> # gdb --args \ >>> >>> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ >>> >>> ? ? ? ? --label=MCAL1 \ >>> >>> ? ? ? ? --triva=master,fctime=10,ctime=50 \ >>> >>> ? ? ? ? --log-no-rate-limit \ >>> >>> ? ? ? ? --server=drasi,dest=lyserv \ >>> >>> ? ? ? ? --buf=size=400Mi \ >>> >>> ? ? ? ? --max-ev-size=0x1000000 \ >>> >>> ? ? ? ? --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ >>> >>> ? ? ? ? --eb=lyserv \ >>> >>> ? ? ? ? "$@" >>> >>> >>> >>> In the first line some environment variables are set. The second line >>> tells >>> >>> the VULOM4 how to operate (i. e. selection from modes of operation >>> defined >>> >>> in vulom.trlo). Then DRASI is started with a bunch of parameters. Is >>> there >>> >>> somewhere an explanation of the purpose of all these settings? >>> >> >>> >> The drasi command line options should be described here: >>> >> >>> >> http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html > >> > >>> > > >> >>> >> >> > > >>> >>> >> >>> >> (Note: 'lyserv' is the name of your PC, at least as seen from the RIO.) >>> >> >>> >> The TRLO II setup file (vulom.trlo) is worse in terms of documentation. >>> >> The format as such is hopefully rather straightforward.? A description is >>> >> here: http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html > >> > >>> > > >> >>> >> >> > > >>> . >>> >> The actual meaning is more complex, the TRLO II description can be found >>> >> here: >>> >> >>> >> http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html > >> > >>> > > >> >>> >> >> > > >>> >>> >> >>> >> (left pane), which just is a colourised version of this: >>> >> http://fy.chalmers.se/~f96hajo/trloii/description.txt > >> > >>> > > >> >>> >> >> > > >>> >>> >> >>> >> It does not describe the .trlo file as such, but what the gateware tries >>> >> to achieve. >>> >> >>> >>> And what is in the last line? I never came accross "$@" before. >>> >> >>> >> That would be all the (non-shifted, i.e. not removed) options given to >>> the >>> >> script itself, i.e. master.bash. >>> >> >>> >>> - eb.bash >>> >>> >>> >>> ../drasi/bin/lwrocmerge \ >>> >>> >>> >>> ? ? --label=MCAL_EB \ >>> >>> ? ? --merge-mode=event \ >>> >>> ? ? --server=trans,flush=1 \ >>> >>> ? ? --server=stream,flush=1 \ >>> >>> ? ? --buf=size=1600Mi \ >>> >>> ? ? --max-ev-size=20Mi \ >>> >>> ? ? --eb-master=rio4-mcal-1 \ >>> >>> ? ? --file-writer \ >>> >>> ? ? --drasi=rio4-mcal-1 >>> >>> >>> >>> What is the purpose of this command? >>> >> >>> >> This runs an 'event builder' on the PC.? Not strictly needed, but this >>> >> way, the RIO only ever needs to send data once, to this event-builder >>> >> (EB).? File writing, and streaming of on-line data is then handled by >>> this >>> >> process.? It is cheaper to have better network cards and so on in a plain >>> >> PC. >>> >> >>> >>> Why are values for buffer size and max >>> >>> event size different then in the command before? >>> >> >>> >> The nomenclaturure is unfortunately a bit convoluted below with ucesb >>> >> regards 'buffer size'.? The --buf in the two commands above give the size >>> >> of the memory used to buffer data inside the process, and depends on how >>> >> much memory each machine has.? The --max-ev-size tells how large each >>> .lmd >>> >> event can be.? The --max-ev-size configured in the event builder needs to >>> >> be as large as the sum of all event sources it has.? I.e. should be able >>> >> to be the same as in your single source above. >>> >> >>> >> In the readout itself, any event that is read out cannot be larger than >>> >> this.? If it is, then the DAQ will report a fatal failure. >>> >> >>> >>> - fanout.bash >>> >>> >>> >>> #!/bin/bash >>> >>> while : >>> >>> do >>> >>> ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ >>> >>> ? ? stream://localhost \ >>> >>> ? ? --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 >>> >>> sleep 5 >>> >>> done >>> >>> >>> >>> This looks like setting up a connection point to the outside world, >>> right? >>> >> >>> >> Yes.? It accepts connections and will serve them data for online >>> analysis. >>> >> >>> >> stream://localhost? tells it where to read data (here the PC itself where >>> >> it is running).? Using the 'stream' protocol, which esentially is just >>> raw >>> >> LMD events.? (As is the 'transport protocol'.)? That will be served on >>> the >>> >> default port used for the stream server set up by the EB above. >>> >> >>> >> --server is then the server that accepts connections, and serves data on >>> >> another port (8001). >>> >> >>> >>> And we find the third (random?) value for a buffer size. >>> >> >>> >> That bufsize is actually the LMD buffer size used by the stream server. >>> >> The corresponding value in the readout and EB is set implicitly from the >>> >> maximum event size... >>> >> >>> >>> - rate.bash >>> >>> >>> >>> ../drasi/bin/lwrocmon --rate rio4-mcal-1 >>> >>> >>> >>> Ok, this I understand. We can look the DAQ over the shoulder and see >>> what >>> >>> the thing is doing in terms of number of trigger events, transported >>> data, >>> >>> etc. >>> >> >>> >>> - log.bash >>> >>> >>> >>> ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost >>> >>> >>> >>> This is also easy to understand. >>> >> >>> >> :-) >>> >> >>> >> Then also try to do (on the PC) >>> >> >>> >> drasi/bin/lwrocmon --tree rio4-mcal-1 localhost >>> >> >>> >> which would show a 'tree-view' monitoring of the running system. >>> >> >>> >> >>> >> Cheers, >>> >> H?kan >>> >> >>> > -- >>> > subexp-daq mailing list >>> > subexp-daq at lists.chalmers.se >>> > https://lists.chalmers.se/mailman/listinfo/subexp-daq > >> > >>> > > >> >>> > >>> -- >>> subexp-daq mailing list >>> subexp-daq at lists.chalmers.se >>> https://lists.chalmers.se/mailman/listinfo/subexp-daq > >> > >>> >>> >> > -- > subexp-daq mailing list > subexp-daq at lists.chalmers.se > https://lists.chalmers.se/mailman/listinfo/subexp-daq > > From g.weber at hi-jena.gsi.de Mon Jan 22 14:47:31 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Mon, 22 Jan 2024 13:47:31 +0000 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <8fb50894-080f-4bf8-8ed3-f7a965de1b55@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de> <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <1aa0afb1bf1e4f91b5d2ab58eb0c62bb@hi-jena.gsi.de> <810ed751-3a8a-43d7-b9b1-7d7c08f8fdf4@chalmers.se> <0dc854ec60194f299b776bc263eb2c72@hi-jena.gsi.de> <5f7958c3-297f-9303-efad-851c23f87ff0@chalmers.se> <897201d9f3424d318c7ed49ce4106aaa@hi-jena.gsi.de> <7f6060e5-ccad-48ba-927e-cb749bea290a@chalmers.se> <2d0ecc20c1ee4921b5ed807b41251fe5@hi-jena.gsi.de>, <8fb50894-080f-4bf8-8ed3-f7a965de1b55@chalmers.se> Message-ID: <266475039f5d41fc9c8247714820854a@hi-jena.gsi.de> Dear Hans, for the first time the DAQ is not crashing. However, it keeps repeating an error message. 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: 56583). Thread has no error buffer yet... CPUS: 1 delay: 1 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: 56583). Thread has no error buffer yet... HOST: RIO4-MCAL-1 Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 (eth1). 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = 0x19000000, 1 consumers. 10: lwroc_triva_readout.c:66: Silence TRIVA (HALT) 10: lwroc_net_io.c:167: Started server on port 56583 (data port 36192). client union size: 244 208 188 508 640 204 204 => 640 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 10: lwroc_main.c:706: Log message rate limit not in effect. 10: lwroc_readout.c:112: call readout_init... 10: lwroc_thread_util.c:117: This is the triva control thread! 10: lwroc_thread_util.c:117: This is the net io thread! 10: lwroc_thread_util.c:117: This is the slow_async thread! 10: lwroc_thread_util.c:117: This is the data server thread! 10: lwroc_message_internal.c:472: Message client connected! 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) [192.168.1.1]. 10: lwroc_triva_control.c:370: Setup TRIVA (DISBUS, HALT, MASTER, RESET) 10: lwroc_triva_control.c:418: Minimum event time ctime(5000)+1*rd(689)+3*wr(634)+fctime(1000)=8591 ns (116.401 kHz) 10: lwroc_triva_state.c:1486: (Re)send ident messages... 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 9: lwroc_triva_control.c:507: TEST: GO 10: lwroc_triva_control.c:725: RUN: RESET 10: lwroc_triva_control.c:729: RUN: MT=14 9: lwroc_triva_control.c:737: GO (1 good test triggers done) (max 116.4 kHz) 10: lwroc_triva_readout.c:376: Trigger 14 seen. 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. 10: config/parser.c:287: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { 10: config/parser.c:299: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } 10: config/parser.c:287: Opened './main.cfg' { 10: config/config.c:1299: .Global log level=verbose. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vetar.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vetar.cfg' } 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } 10: config/parser.c:299: Closed './main.cfg' } 10: crate/crate.c:347: crate_create { 10: crate/crate.c:673: crate_create(MCAL) } 10: crate/crate.c:899: crate_init(MCAL) { 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) 10: crate/crate.c:923: .Slow-init module[1]=GSI_VETAR. 5: module/gsi_etherbone/gsi_etherbone.c:205: ...eb_device_open: Opening device failed: system failure 10: crate/crate.c:683: .crate_deinit(MCAL) { 10: crate/crate.c:707: .crate_deinit(MCAL) } 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) 10: crate/crate.c:923: .Slow-init module[1]=GSI_VETAR. 5: module/gsi_etherbone/gsi_etherbone.c:205: ...eb_device_open: Opening device failed: system failure 10: crate/crate.c:683: .crate_deinit(MCAL) { 10: crate/crate.c:707: .crate_deinit(MCAL) } 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 ... 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. Best greetings G?nter ________________________________ Von: Hans Toshihide T?rnqvist Gesendet: Montag, 22. Januar 2024 14:15:01 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated On 2024-01-22 13:16, Weber, Guenter Dr. wrote: > The next problem looks like this: > > 10: config/parser.c:299: Closed './main.cfg' } > 10: crate/crate.c:347: crate_create { > 5: config/config.c:376: ..Block 'GSI_VETAR' (./main.cfg:8:2) does not > have requested param [0]. > 5: config/config.c:376: ..Calling abort()... > > Maybe, the interpreter for the main.cfg is now a bit more strict than > before? Is it maybe the module hardware address that is missing? But > this was not needed before for some weird reason (how does the software > know where to look for the VETAR then?). Aha, back then the Vetars we bought and the template implementations we received were always on address 0x50000000 (7 zeros) and that was hardcoded into nurdlib. Meanwhile I tried other addresses which worked, so the config now requires this. I would prefer to keep this explicit and update old config files, since it is rather useful information. So, please try GSI_VETAR(0x50000000) {...} > Best greetings and sorry for all these problems ? Many problems are due to me not having been proactive enough, especially with external users to keep the software more up-to-date, for which I would like to apologise. This adventure has fixed a huge number things in my backlog, I appreciate your work and patience a lot! Your trials will benefit many other DAQ users who rely on these codes :) Best regards, Hans > G?nter > > > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > Hans Toshihide T?rnqvist > *Gesendet:* Montag, 22. Januar 2024 11:46:56 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > TRLOII, DRASI, etc. were updated > Dear G?nter, > > I'm sorry, my discipline slipped and I forgot to push that commit also > to the public Gitlab... It's available there now. > > Best regards, > Hans > > On 2024-01-22 11:40, Weber, Guenter Dr. wrote: >> Dear Hans, dear H?kan, >> >> >> I now recompiled R3BFUSER, but still I get the same error message when >> starting DRASI. >> >> >> This is how the beginning how the beginning of main.cfg looks like: >> >> >> log_level=verbose # info, verbose, debug, spam >> CRATE("MCAL") { >> GSI_VULOM(0x03000000) { >> timestamp = true # needed to get timestamps in the data output >> } >> BARRIER >> GSI_VETAR { >> dactl = false >> direct = false >> } >> BARRIER >> SIS_3316(0x30000000) { >> ... >> >> Do you have any idea why the dactl command is not find found? Maybe >> NURDLIB on GITLAB does not have the modified VETAR files yet? I have >> next to zero experience, so probably I am wrong. But if the last change >> in MODULE is from six days ago, it might not be the most recent version, >> right? >> >> >> >> >> >> Best greetings >> >> G?nter >> >> >> >> ------------------------------------------------------------------------ >> *Von:* subexp-daq im Auftrag von >> H?kan T Johansson >> *Gesendet:* Montag, 22. Januar 2024 11:13:36 >> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >> TRLOII, DRASI, etc. were updated >> >> Dear G?nter, >> >> yes, r3bfuser depends on all of them (nurdlib, trloii, drasi), so needs a >> recompile. nurdlib also needs recompile if trloii is updated. >> >> Cheers, >> H?kan >> >> >> On Mon, 22 Jan 2024, Weber, Guenter Dr. wrote: >> >>> >>> Dear Hans, >>> >>> >>> I updated the NURDLIB, but the new flag is not recognized. >>> >>> >>> 10: config/parser.c:299: .Closed'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>> le_log_level.cfg' } >>> 5: config/keyword.c:20: .Invalid keyword "dactl". >>> 5: config/keyword.c:20: .Calling abort()... >>> >>> Do I also need to recompile DRASI or R3BFUSER? >>> >>> >>> >>> >>> Best greetings >>> >>> G?nter >>> >>> >>> >>> ____________________________________________________________________________ >>> Von: subexp-daq im Auftrag von Hans >>> Toshihide T?rnqvist >>> Gesendet: Freitag, 19. Januar 2024 16:31:37 >>> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >>> Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, >>> DRASI, etc. were updated >>> Dear G?nter, >>> >>> I have implemented the dactl switch in 'mcal_daq_merge', so in main.cfg: >>> >>> GSI_VETAR { >>> dactl = false >>> direct = false >>> } >>> >>> I do not know how the names of the Etherbone libraries (e.g. cherry and >>> enigma) relate to the driver. If the dactl file is not available, we >>> just have to skip dactl accesses and not allow the direct readout path. >>> >>> Have a good weekend you too! >>> >>> Best regards, >>> Hans >>> >>> On 2024-01-19 15:22, Weber, Guenter Dr. wrote: >>> > Dear Hans, >>> > >>> > >>> > with the help of H?kan, I managed to get the VULOM running. So, we are >>> > back to starting the DRASI. There we encountered first the fact that in >>> > main.cfg a BARRIER is now required between the initialization of all >>> > modules (before there was only a single BARRIER command in the whole >>> > main.cfg. >>> > >>> > >>> > Now, we are again encounter the VETAR error message. See below: >>> > >>> > >>> > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: >>> > 56583). >>> > Thread has no error buffer yet... >>> > CPUS: 1 >>> > delay: 1 >>> > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: >>> > 56583). >>> > Thread has no error buffer yet... >>> > HOST: RIO4-MCAL-1 >>> > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] >>> > 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 >>> > (eth1). >>> > 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = >>> > 0x19000000, 1 consumers. >>> > 10: lwroc_triva_readout.c:66: Silence TRIVA (HALT) >>> > 10: lwroc_net_io.c:167: Started server on port 56583 (data port 50126). >>> > client union size: 244 208 188 508 640 204 204 => 640 >>> > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: >>> > /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 >>> > 10: lwroc_main.c:706: Log message rate limit not in effect. >>> > 10: lwroc_readout.c:112: call readout_init... >>> > 10: lwroc_thread_util.c:117: This is the triva control thread! >>> > 10: lwroc_thread_util.c:117: This is the net io thread! >>> > 10: lwroc_thread_util.c:117: This is the slow_async thread! >>> > 10: lwroc_thread_util.c:117: This is the data server thread! >>> > 10: lwroc_message_internal.c:472: Message client connected! >>> > 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) >>> > [192.168.1.1]. >>> > 10: lwroc_triva_control.c:370: Setup TRIVA (DISBUS, HALT, MASTER, RESET) >>> > 10: lwroc_triva_control.c:418: Minimum event time >>> > ctime(5000)+1*rd(688)+3*wr(634)+fctime(1000)=8590 ns (116.414 kHz) >>> > 10: lwroc_triva_state.c:1486: (Re)send ident messages... >>> > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 >>> > 9: lwroc_triva_control.c:507: TEST: GO >>> > 10: lwroc_triva_control.c:725: RUN: RESET >>> > 10: lwroc_triva_control.c:729: RUN: MT=14 >>> > 9: lwroc_triva_control.c:737: GO (1 good test triggers done) (max >>> > 116.4 kHz) >>> > 10: lwroc_triva_readout.c:376: Trigger 14 seen. >>> > 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. >>> > 10: config/parser.c:287: Opened >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/glob >>> al.cfg' { >>> > 10: config/parser.c:299: Closed >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/glob >>> al.cfg' } >>> > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 >>> > (IN_READOUT). EC: 1 >>> > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >>> > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >>> > 10: config/parser.c:287: Opened './main.cfg' { >>> > 10: config/config.c:1299: .Global log level=verbose. >>> > 10: config/parser.c:287: .Opened >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crat >>> e.cfg' { >>> > 10: config/parser.c:299: .Closed >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crat >>> e.cfg' } >>> > 10: config/parser.c:287: .Opened >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ >>> vulom.cfg' { >>> > 10: config/parser.c:299: .Closed >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ >>> vulom.cfg' } >>> > 10: config/parser.c:287: .Opened >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>> le_log_level.cfg' { >>> > 10: config/parser.c:299: .Closed >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>> le_log_level.cfg' } >>> > 10: config/parser.c:287: .Opened >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ >>> vetar.cfg' { >>> > 10: config/parser.c:299: .Closed >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ >>> vetar.cfg' } >>> > 10: config/parser.c:287: .Opened >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>> le_log_level.cfg' { >>> > 10: config/parser.c:299: .Closed >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>> le_log_level.cfg' } >>> > 10: config/parser.c:287: .Opened >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ >>> 3316.cfg' { >>> > 10: config/parser.c:299: .Closed >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ >>> 3316.cfg' } >>> > 10: config/parser.c:287: .Opened >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>> le_log_level.cfg' { >>> > 10: config/parser.c:299: .Closed >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>> le_log_level.cfg' } >>> > 10: config/parser.c:287: .Opened >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ >>> 3316.cfg' { >>> > 10: config/parser.c:299: .Closed >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ >>> 3316.cfg' } >>> > 10: config/parser.c:287: .Opened >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>> le_log_level.cfg' { >>> > 10: config/parser.c:299: .Closed >>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>> le_log_level.cfg' } >>> > 10: config/parser.c:299: Closed './main.cfg' } >>> > 10: crate/crate.c:347: crate_create { >>> > 10: crate/crate.c:673: crate_create(MCAL) } >>> > 10: crate/crate.c:899: crate_init(MCAL) { >>> > 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. >>> > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) >>> > 10: crate/crate.c:923: .Slow-init module[1]=GSI_VETAR. >>> > 5: module/gsi_etherbone/gsi_etherbone.c:431: ..Gsi Etherbone >>> > /sys/class/vetar/vetar0/dactl: Failed dactl fopen: No such file or >>> > directory. >>> > 5: module/gsi_etherbone/gsi_etherbone.c:431: ..Calling abort()... >>> > >>> > We are sure that the right NURDLIB path is used and also DRASI is >>> > started in the correct folder. >>> > >>> > >>> > What we found in the enironment variables are two lines, where 'white >>> > rabbit' is mentioned. As I understand, this is connected to the VETAR2 >>> > module. >>> > >>> > >>> >LD_LIBRARY_PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/li >>> b:/mbsusr/mbsdaq/mbsrun/whiterabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib >>> >PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/bin:/bin:/bin >>> /ces:/usr/bin:/mbsusr/mbsdaq/bin:/usr/local/bin:/usr/bin/X11:/etc:/usr/etc >>> :.:/mbsusr/mbsdaq/tools >>> > >>> > Maybe, it is necessary to update something there? >>> > >>> > >>> > Anyway, if you have now a switch in NURDLIB to deal with old software >>> > for the VETAR, then we should proceed with removing NURDLIB and getting >>> > the newer version, right? >>> > >>> > >>> > >>> > >>> > Many thanks and have a nice weekend! >>> > >>> > >>> > >>> > >>> > Best greetings >>> > >>> > G?nter >>> > >>> > >>> > >>> > >>> > ------------------------------------------------------------------------ >>> > *Von:* subexp-daq im Auftrag von >>> > Hans Toshihide T?rnqvist >>> > *Gesendet:* Donnerstag, 18. Januar 2024 13:28:36 >>> > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter >>> Dr. >>> > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >>> > TRLOII, DRASI, etc. were updated >>> > Dear G?nter, >>> > >>> > It looks like either the Vetar driver failed, or the fw/driver is old >>> > and nurdlib expects a file that didn't exist a while back. If it's the >>> > latter I can add a switch to ignore this file, it's not critical for >>> > readout and is used to enter a faster readout mode. >>> > >>> > Which version of nurdlib is this? The files and line numbers don't match >>> > with what I see in the source code, and the last time gsi_etherbone.c >>> > changed was early last year. >>> > >>> > The message "Could not open so-and-so" should be for the device, e.g. >>> > /dev/pcie_wb0. This is used for the readout. >>> > >>> > The dactl file should fail with "Failed dactl fopen". >>> > >>> > To summarise, I would suggest to make sure that the correct nurdlib and >>> > r3bfuser are executed by the DAQ scripts. Meanwhile I will prepare a >>> > switch to ignore the dactl file which could anyhow be useful for old >>> > configurations, and to clean up the Etherbone error messages. >>> > >>> > Best regards, >>> > Hans >>> > >>> > On 2024-01-18 11:29, Weber, Guenter Dr. wrote: >>> >> Dear friends, >>> >> >>> >> >>> >> I now started the DAQ and it looks like there is a problem with the >>> >> VETAR2 module. Attached please find the output once the DAQ is started >>> >> on the RIO4. >>> >> >>> >> >>> >> Here ist the error message: >>> >> >>> >> >>> >> 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866) >>> >> 11: a:1: .Gsi Etherbone init_slow { >>> >> (module/gsi_etherbone/gsi_etherbone.c:110) >>> >> 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No >>> >> such file or directory. >>> >> (module/gsi_etherbone/gsi_etherbone.c:120) >>> >> 5: a:1: ..Calling exit(EXIT_FAILURE)... >>> >> (module/gsi_etherbone/gsi_etherbone.c:120) >>> >> >>> >> How to proceed? >>> >> >>> >> >>> >> >>> >> Many thanks and best greetings >>> >> G?nter >>> >> >>> >> >>> >> >>> >> >>> >> ------------------------------------------------------------------------ >>> >> *Von:* subexp-daq im Auftrag von >>> >> H?kan T Johansson >>> >> *Gesendet:* Dienstag, 16. Januar 2024 19:20:54 >>> >> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. >>> >> *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >>> >> TRLOII, DRASI, etc. were updated >>> >> >>> >> On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: >>> >> >>> >>> >>> >>> Dear friends, >>> >>> >>> >>> >>> >>> I am just trying to figure out how all the various scripts/commands work >>> >>> together for setting up our DAQ system. Maybe, you can help to clearify >>> some >>> >>> things. >>> >>> >>> >>> >>> >>> >>> >>> - master.bash >>> >> >>> >> This would be intended to run on the readout board (RIO). The other >>> >> scripts below is for the PC. >>> >> >>> >>> >>> >>> source ../env/env.sh >>> >>> ./trloii_setup.sh >>> >>> # gdb --args \ >>> >>> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ >>> >>> --label=MCAL1 \ >>> >>> --triva=master,fctime=10,ctime=50 \ >>> >>> --log-no-rate-limit \ >>> >>> --server=drasi,dest=lyserv \ >>> >>> --buf=size=400Mi \ >>> >>> --max-ev-size=0x1000000 \ >>> >>> --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ >>> >>> --eb=lyserv \ >>> >>> "$@" >>> >>> >>> >>> In the first line some environment variables are set. The second line >>> tells >>> >>> the VULOM4 how to operate (i. e. selection from modes of operation >>> defined >>> >>> in vulom.trlo). Then DRASI is started with a bunch of parameters. Is >>> there >>> >>> somewhere an explanation of the purpose of all these settings? >>> >> >>> >> The drasi command line options should be described here: >>> >> >>> >> http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html > >> > >>> > > >> >>> >> >> > > >>> >>> >> >>> >> (Note: 'lyserv' is the name of your PC, at least as seen from the RIO.) >>> >> >>> >> The TRLO II setup file (vulom.trlo) is worse in terms of documentation. >>> >> The format as such is hopefully rather straightforward. A description is >>> >> here: http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html > >> > >>> > > >> >>> >> >> > > >>> . >>> >> The actual meaning is more complex, the TRLO II description can be found >>> >> here: >>> >> >>> >> http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html > >> > >>> > > >> >>> >> >> > > >>> >>> >> >>> >> (left pane), which just is a colourised version of this: >>> >> http://fy.chalmers.se/~f96hajo/trloii/description.txt > >> > >>> > > >> >>> >> >> > > >>> >>> >> >>> >> It does not describe the .trlo file as such, but what the gateware tries >>> >> to achieve. >>> >> >>> >>> And what is in the last line? I never came accross "$@" before. >>> >> >>> >> That would be all the (non-shifted, i.e. not removed) options given to >>> the >>> >> script itself, i.e. master.bash. >>> >> >>> >>> - eb.bash >>> >>> >>> >>> ../drasi/bin/lwrocmerge \ >>> >>> >>> >>> --label=MCAL_EB \ >>> >>> --merge-mode=event \ >>> >>> --server=trans,flush=1 \ >>> >>> --server=stream,flush=1 \ >>> >>> --buf=size=1600Mi \ >>> >>> --max-ev-size=20Mi \ >>> >>> --eb-master=rio4-mcal-1 \ >>> >>> --file-writer \ >>> >>> --drasi=rio4-mcal-1 >>> >>> >>> >>> What is the purpose of this command? >>> >> >>> >> This runs an 'event builder' on the PC. Not strictly needed, but this >>> >> way, the RIO only ever needs to send data once, to this event-builder >>> >> (EB). File writing, and streaming of on-line data is then handled by >>> this >>> >> process. It is cheaper to have better network cards and so on in a plain >>> >> PC. >>> >> >>> >>> Why are values for buffer size and max >>> >>> event size different then in the command before? >>> >> >>> >> The nomenclaturure is unfortunately a bit convoluted below with ucesb >>> >> regards 'buffer size'. The --buf in the two commands above give the size >>> >> of the memory used to buffer data inside the process, and depends on how >>> >> much memory each machine has. The --max-ev-size tells how large each >>> .lmd >>> >> event can be. The --max-ev-size configured in the event builder needs to >>> >> be as large as the sum of all event sources it has. I.e. should be able >>> >> to be the same as in your single source above. >>> >> >>> >> In the readout itself, any event that is read out cannot be larger than >>> >> this. If it is, then the DAQ will report a fatal failure. >>> >> >>> >>> - fanout.bash >>> >>> >>> >>> #!/bin/bash >>> >>> while : >>> >>> do >>> >>> ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ >>> >>> stream://localhost \ >>> >>> --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 >>> >>> sleep 5 >>> >>> done >>> >>> >>> >>> This looks like setting up a connection point to the outside world, >>> right? >>> >> >>> >> Yes. It accepts connections and will serve them data for online >>> analysis. >>> >> >>> >> stream://localhost tells it where to read data (here the PC itself where >>> >> it is running). Using the 'stream' protocol, which esentially is just >>> raw >>> >> LMD events. (As is the 'transport protocol'.) That will be served on >>> the >>> >> default port used for the stream server set up by the EB above. >>> >> >>> >> --server is then the server that accepts connections, and serves data on >>> >> another port (8001). >>> >> >>> >>> And we find the third (random?) value for a buffer size. >>> >> >>> >> That bufsize is actually the LMD buffer size used by the stream server. >>> >> The corresponding value in the readout and EB is set implicitly from the >>> >> maximum event size... >>> >> >>> >>> - rate.bash >>> >>> >>> >>> ../drasi/bin/lwrocmon --rate rio4-mcal-1 >>> >>> >>> >>> Ok, this I understand. We can look the DAQ over the shoulder and see >>> what >>> >>> the thing is doing in terms of number of trigger events, transported >>> data, >>> >>> etc. >>> >> >>> >>> - log.bash >>> >>> >>> >>> ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost >>> >>> >>> >>> This is also easy to understand. >>> >> >>> >> :-) >>> >> >>> >> Then also try to do (on the PC) >>> >> >>> >> drasi/bin/lwrocmon --tree rio4-mcal-1 localhost >>> >> >>> >> which would show a 'tree-view' monitoring of the running system. >>> >> >>> >> >>> >> Cheers, >>> >> H?kan >>> >> >>> > -- >>> > subexp-daq mailing list >>> > subexp-daq at lists.chalmers.se >>> > https://lists.chalmers.se/mailman/listinfo/subexp-daq > >> > >>> > > >> >>> > >>> -- >>> subexp-daq mailing list >>> subexp-daq at lists.chalmers.se >>> https://lists.chalmers.se/mailman/listinfo/subexp-daq > >> > >>> >>> >> > -- > 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: From hans.tornqvist at chalmers.se Mon Jan 22 15:14:54 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Mon, 22 Jan 2024 15:14:54 +0100 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <266475039f5d41fc9c8247714820854a@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <61a2f2f5-6edc-45f9-a139-4c7da2083203@chalmers.se> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de> <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <1aa0afb1bf1e4f91b5d2ab58eb0c62bb@hi-jena.gsi.de> <810ed751-3a8a-43d7-b9b1-7d7c08f8fdf4@chalmers.se> <0dc854ec60194f299b776bc263eb2c72@hi-jena.gsi.de> <5f7958c3-297f-9303-efad-851c23f87ff0@chalmers.se> <897201d9f3424d318c7ed49ce4106aaa@hi-jena.gsi.de> <7f6060e5-ccad-48ba-927e-cb749bea290a@chalmers.se> <2d0ecc20c1ee4921b5ed807b41251fe5@hi-jena.gsi.de> <8fb50894-080f-4bf8-8ed3-f7a965de1b55@chalmers.se> <266475039f5d41fc9c8247714820854a@hi-jena.gsi.de> Message-ID: <2a94c163-aeb5-4336-bfe0-44d89172ec99@chalmers.se> Dear G?nter, It looks indeed like the Vetar driver still has a problem. The Vetar running standalone, does that mean it doesn't have an upstream White Rabbit source? This should be fine as long as you don't have to synchronise with other systems. What is the Vetar used for? It looks like you read out the timestamps from the Vulom currently. Could you please try to comment out the Vetar? Best regards, Hans On 2024-01-22 14:47, Weber, Guenter Dr. wrote: > Dear Hans, > > > for the first time the DAQ is not crashing. However, it keeps repeating > an error message. > > > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: > 56583). > Thread has no error buffer yet... > CPUS: 1 > delay: 1 > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: > 56583). > Thread has no error buffer yet... > HOST: RIO4-MCAL-1 > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] > 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 > (eth1). > 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = > 0x19000000, 1 consumers. > 10: lwroc_triva_readout.c:66: Silence TRIVA? (HALT) > 10: lwroc_net_io.c:167: Started server on port 56583 (data port 36192). > client union size: 244 208 188 508 640 204 204? => 640 > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: > /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 > 10: lwroc_main.c:706: Log message rate limit not in effect. > 10: lwroc_readout.c:112: call readout_init... > 10: lwroc_thread_util.c:117: This is the triva control thread! > 10: lwroc_thread_util.c:117: This is the net io thread! > 10: lwroc_thread_util.c:117: This is the slow_async thread! > 10: lwroc_thread_util.c:117: This is the data server thread! > 10: lwroc_message_internal.c:472: Message client connected! > 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) > [192.168.1.1]. > 10: lwroc_triva_control.c:370: Setup TRIVA? (DISBUS, HALT, MASTER, RESET) > 10: lwroc_triva_control.c:418: Minimum event time > ctime(5000)+1*rd(689)+3*wr(634)+fctime(1000)=8591 ns (116.401 kHz) > 10: lwroc_triva_state.c:1486: (Re)send ident messages... > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 > 9: lwroc_triva_control.c:507: TEST: GO > 10: lwroc_triva_control.c:725: RUN: RESET > 10: lwroc_triva_control.c:729: RUN: MT=14 > 9: lwroc_triva_control.c:737:?? GO (1 good test triggers done) (max > 116.4 kHz) > 10: lwroc_triva_readout.c:376: Trigger 14 seen. > 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. > 10: config/parser.c:287: Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { > 10: config/parser.c:299: Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } > 10: config/parser.c:287: Opened './main.cfg' { > 10: config/config.c:1299: .Global log level=verbose. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 > (IN_READOUT).? EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vetar.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vetar.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:299: Closed './main.cfg' } > 10: crate/crate.c:347: crate_create { > 10: crate/crate.c:673: crate_create(MCAL) } > 10: crate/crate.c:899: crate_init(MCAL) { > 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) > 10: crate/crate.c:923: .Slow-init module[1]=GSI_VETAR. > 5: module/gsi_etherbone/gsi_etherbone.c:205: ...eb_device_open: Opening > device failed: system failure > 10: crate/crate.c:683: .crate_deinit(MCAL) { > 10: crate/crate.c:707: .crate_deinit(MCAL) } > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, > and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 > (IN_READOUT).? EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) > 10: crate/crate.c:923: .Slow-init module[1]=GSI_VETAR. > 5: module/gsi_etherbone/gsi_etherbone.c:205: ...eb_device_open: Opening > device failed: system failure > 10: crate/crate.c:683: .crate_deinit(MCAL) { > 10: crate/crate.c:707: .crate_deinit(MCAL) } > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, > and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 > (IN_READOUT).? EC: 1 > ... > > > 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. > > > > > Best greetings > > G?nter > > > > ------------------------------------------------------------------------ > *Von:* Hans Toshihide T?rnqvist > *Gesendet:* Montag, 22. Januar 2024 14:15:01 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr. > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > TRLOII, DRASI, etc. were updated > On 2024-01-22 13:16, Weber, Guenter Dr. wrote: >> The next problem looks like this: >> >> 10: config/parser.c:299: Closed './main.cfg' } >> 10: crate/crate.c:347: crate_create { >> 5: config/config.c:376: ..Block 'GSI_VETAR' (./main.cfg:8:2) does not >> have requested param [0]. >> 5: config/config.c:376: ..Calling abort()... >> >> Maybe, the interpreter for the main.cfg is now a bit more strict than >> before? Is it maybe the module hardware address that is missing? But >> this was not needed before for some weird reason (how does the software >> know where to look for the VETAR then?). > > Aha, back then the Vetars we bought and the template implementations we > received were always on address 0x50000000 (7 zeros) and that was > hardcoded into nurdlib. Meanwhile I tried other addresses which worked, > so the config now requires this. I would prefer to keep this explicit > and update old config files, since it is rather useful information. > > So, please try GSI_VETAR(0x50000000) {...} > >> Best greetings and sorry for all these problems ? > > Many problems are due to me not having been proactive enough, especially > with external users to keep the software more up-to-date, for which I > would like to apologise. This adventure has fixed a huge number things > in my backlog, I appreciate your work and patience a lot! Your trials > will benefit many other DAQ users who rely on these codes :) > > Best regards, > Hans > >> G?nter >> >> >> >> >> ------------------------------------------------------------------------ >> *Von:* subexp-daq im Auftrag von >> Hans Toshihide T?rnqvist >> *Gesendet:* Montag, 22. Januar 2024 11:46:56 >> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >> TRLOII, DRASI, etc. were updated >> Dear G?nter, >> >> I'm sorry, my discipline slipped and I forgot to push that commit also >> to the public Gitlab... It's available there now. >> >> Best regards, >> Hans >> >> On 2024-01-22 11:40, Weber, Guenter Dr. wrote: >>> Dear Hans, dear H?kan, >>> >>> >>> I now recompiled R3BFUSER, but still I get the same error message when >>> starting DRASI. >>> >>> >>> This is how the beginning how the beginning of main.cfg looks like: >>> >>> >>> log_level=verbose # info, verbose, debug, spam >>> CRATE("MCAL") { >>>? ? ? GSI_VULOM(0x03000000) { >>>? ? ? ? ? timestamp = true # needed to get timestamps in the data output >>>? ? ? } >>>? ? ? BARRIER >>>? ? ? GSI_VETAR { >>>? ? ? ? ? dactl = false >>>? ? ? ? ? direct = false >>>? ? ? } >>>? ? ? BARRIER >>>? ? ? SIS_3316(0x30000000) { >>> ... >>> >>> Do you have any idea why the dactl command is not find found? Maybe >>> NURDLIB on GITLAB does not have the modified VETAR files yet? I have >>> next to zero experience, so probably I am wrong. But if the last change >>> in MODULE is from six days ago, it might not be the most recent version, >>> right? >>> >>> >>> >>> >>> >>> Best greetings >>> >>> G?nter >>> >>> >>> >>> ------------------------------------------------------------------------ >>> *Von:* subexp-daq im Auftrag von >>> H?kan T Johansson >>> *Gesendet:* Montag, 22. Januar 2024 11:13:36 >>> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. >>> *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >>> TRLOII, DRASI, etc. were updated >>> >>> Dear G?nter, >>> >>> yes, r3bfuser depends on all of them (nurdlib, trloii, drasi), so needs a >>> recompile.? nurdlib also needs recompile if trloii is updated. >>> >>> Cheers, >>> H?kan >>> >>> >>> On Mon, 22 Jan 2024, Weber, Guenter Dr. wrote: >>> >>>> >>>> Dear Hans, >>>> >>>> >>>> I updated the NURDLIB, but the new flag is not recognized. >>>> >>>> >>>> 10: config/parser.c:299: .Closed'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>>> le_log_level.cfg' } >>>> 5: config/keyword.c:20: .Invalid keyword "dactl". >>>> 5: config/keyword.c:20: .Calling abort()... >>>> >>>> Do I also need to recompile DRASI or R3BFUSER? >>>> >>>> >>>> >>>> >>>> Best greetings >>>> >>>> G?nter >>>> >>>> >>>> >>>> ____________________________________________________________________________ >>>> Von: subexp-daq im Auftrag von Hans >>>> Toshihide T?rnqvist >>>> Gesendet: Freitag, 19. Januar 2024 16:31:37 >>>> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >>>> Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, >>>> DRASI, etc. were updated >>>> Dear G?nter, >>>> >>>> I have implemented the dactl switch in 'mcal_daq_merge', so in main.cfg: >>>> >>>> GSI_VETAR { >>>> ? dactl = false >>>> ? direct = false >>>> } >>>> >>>> I do not know how the names of the Etherbone libraries (e.g. cherry and >>>> enigma) relate to the driver. If the dactl file is not available, we >>>> just have to skip dactl accesses and not allow the direct readout path. >>>> >>>> Have a good weekend you too! >>>> >>>> Best regards, >>>> Hans >>>> >>>> On 2024-01-19 15:22, Weber, Guenter Dr. wrote: >>>> > Dear Hans, >>>> > >>>> > >>>> > with the help of H?kan, I managed to get the VULOM running. So, we are >>>> > back to starting the DRASI. There we encountered first the fact that in >>>> > main.cfg a BARRIER is now required between the initialization of all >>>> > modules (before there was only a single BARRIER command in the whole >>>> > main.cfg. >>>> > >>>> > >>>> > Now, we are again encounter the VETAR error message. See below: >>>> > >>>> > >>>> > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: >>>> > 56583). >>>> > Thread has no error buffer yet... >>>> > CPUS: 1 >>>> > delay: 1 >>>> > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: >>>> > 56583). >>>> > Thread has no error buffer yet... >>>> > HOST: RIO4-MCAL-1 >>>> > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] >>>> > 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 >>>> > (eth1). >>>> > 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = >>>> > 0x19000000, 1 consumers. >>>> > 10: lwroc_triva_readout.c:66: Silence TRIVA? (HALT) >>>> > 10: lwroc_net_io.c:167: Started server on port 56583 (data port 50126). >>>> > client union size: 244 208 188 508 640 204 204? => 640 >>>> > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: >>>> > /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 >>>> > 10: lwroc_main.c:706: Log message rate limit not in effect. >>>> > 10: lwroc_readout.c:112: call readout_init... >>>> > 10: lwroc_thread_util.c:117: This is the triva control thread! >>>> > 10: lwroc_thread_util.c:117: This is the net io thread! >>>> > 10: lwroc_thread_util.c:117: This is the slow_async thread! >>>> > 10: lwroc_thread_util.c:117: This is the data server thread! >>>> > 10: lwroc_message_internal.c:472: Message client connected! >>>> > 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) >>>> > [192.168.1.1]. >>>> > 10: lwroc_triva_control.c:370: Setup TRIVA? (DISBUS, HALT, MASTER, RESET) >>>> > 10: lwroc_triva_control.c:418: Minimum event time >>>> > ctime(5000)+1*rd(688)+3*wr(634)+fctime(1000)=8590 ns (116.414 kHz) >>>> > 10: lwroc_triva_state.c:1486: (Re)send ident messages... >>>> > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 >>>> > 9: lwroc_triva_control.c:507: TEST: GO >>>> > 10: lwroc_triva_control.c:725: RUN: RESET >>>> > 10: lwroc_triva_control.c:729: RUN: MT=14 >>>> > 9: lwroc_triva_control.c:737:?? GO (1 good test triggers done) (max >>>> > 116.4 kHz) >>>> > 10: lwroc_triva_readout.c:376: Trigger 14 seen. >>>> > 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. >>>> > 10: config/parser.c:287: Opened >>>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/glob >>>> al.cfg' { >>>> > 10: config/parser.c:299: Closed >>>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/glob >>>> al.cfg' } >>>> > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 >>>> > (IN_READOUT).? EC: 1 >>>> > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >>>> > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >>>> > 10: config/parser.c:287: Opened './main.cfg' { >>>> > 10: config/config.c:1299: .Global log level=verbose. >>>> > 10: config/parser.c:287: .Opened >>>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crat >>>> e.cfg' { >>>> > 10: config/parser.c:299: .Closed >>>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crat >>>> e.cfg' } >>>> > 10: config/parser.c:287: .Opened >>>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ >>>> vulom.cfg' { >>>> > 10: config/parser.c:299: .Closed >>>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ >>>> vulom.cfg' } >>>> > 10: config/parser.c:287: .Opened >>>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>>> le_log_level.cfg' { >>>> > 10: config/parser.c:299: .Closed >>>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>>> le_log_level.cfg' } >>>> > 10: config/parser.c:287: .Opened >>>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ >>>> vetar.cfg' { >>>> > 10: config/parser.c:299: .Closed >>>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_ >>>> vetar.cfg' } >>>> > 10: config/parser.c:287: .Opened >>>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>>> le_log_level.cfg' { >>>> > 10: config/parser.c:299: .Closed >>>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>>> le_log_level.cfg' } >>>> > 10: config/parser.c:287: .Opened >>>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ >>>> 3316.cfg' { >>>> > 10: config/parser.c:299: .Closed >>>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ >>>> 3316.cfg' } >>>> > 10: config/parser.c:287: .Opened >>>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>>> le_log_level.cfg' { >>>> > 10: config/parser.c:299: .Closed >>>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>>> le_log_level.cfg' } >>>> > 10: config/parser.c:287: .Opened >>>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ >>>> 3316.cfg' { >>>> > 10: config/parser.c:299: .Closed >>>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_ >>>> 3316.cfg' } >>>> > 10: config/parser.c:287: .Opened >>>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>>> le_log_level.cfg' { >>>> > 10: config/parser.c:299: .Closed >>>> >'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/modu >>>> le_log_level.cfg' } >>>> > 10: config/parser.c:299: Closed './main.cfg' } >>>> > 10: crate/crate.c:347: crate_create { >>>> > 10: crate/crate.c:673: crate_create(MCAL) } >>>> > 10: crate/crate.c:899: crate_init(MCAL) { >>>> > 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. >>>> > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) >>>> > 10: crate/crate.c:923: .Slow-init module[1]=GSI_VETAR. >>>> > 5: module/gsi_etherbone/gsi_etherbone.c:431: ..Gsi Etherbone >>>> > /sys/class/vetar/vetar0/dactl: Failed dactl fopen: No such file or >>>> > directory. >>>> > 5: module/gsi_etherbone/gsi_etherbone.c:431: ..Calling abort()... >>>> > >>>> > We are sure that the right NURDLIB path is used and also DRASI is >>>> > started in the correct folder. >>>> > >>>> > >>>> > What we found in the enironment variables are two lines, where 'white >>>> > rabbit' is mentioned. As I understand, this is connected to the VETAR2 >>>> > module. >>>> > >>>> > >>>> >LD_LIBRARY_PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/li >>>> b:/mbsusr/mbsdaq/mbsrun/whiterabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib >>>> >PATH=/mbs/driv/white_rabbit/cherry/RIO4_Linux_OSV_2_6_33_SuHa/bin:/bin:/bin >>>> /ces:/usr/bin:/mbsusr/mbsdaq/bin:/usr/local/bin:/usr/bin/X11:/etc:/usr/etc >>>> :.:/mbsusr/mbsdaq/tools >>>> > >>>> > Maybe, it is necessary to update something there? >>>> > >>>> > >>>> > Anyway, if you have now a switch in NURDLIB to deal with old software >>>> > for the VETAR, then we should proceed with removing NURDLIB and getting >>>> > the newer version, right? >>>> > >>>> > >>>> > >>>> > >>>> > Many thanks and have a nice weekend! >>>> > >>>> > >>>> > >>>> > >>>> > Best greetings >>>> > >>>> > G?nter >>>> > >>>> > >>>> > >>>> > >>>> > ------------------------------------------------------------------------ >>>> > *Von:* subexp-daq im Auftrag von >>>> > Hans Toshihide T?rnqvist >>>> > *Gesendet:* Donnerstag, 18. Januar 2024 13:28:36 >>>> > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter >>>> Dr. >>>> > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >>>> > TRLOII, DRASI, etc. were updated >>>> > Dear G?nter, >>>> > >>>> > It looks like either the Vetar driver failed, or the fw/driver is old >>>> > and nurdlib expects a file that didn't exist a while back. If it's the >>>> > latter I can add a switch to ignore this file, it's not critical for >>>> > readout and is used to enter a faster readout mode. >>>> > >>>> > Which version of nurdlib is this? The files and line numbers don't match >>>> > with what I see in the source code, and the last time gsi_etherbone.c >>>> > changed was early last year. >>>> > >>>> > The message "Could not open so-and-so" should be for the device, e.g. >>>> > /dev/pcie_wb0. This is used for the readout. >>>> > >>>> > The dactl file should fail with "Failed dactl fopen". >>>> > >>>> > To summarise, I would suggest to make sure that the correct nurdlib and >>>> > r3bfuser are executed by the DAQ scripts. Meanwhile I will prepare a >>>> > switch to ignore the dactl file which could anyhow be useful for old >>>> > configurations, and to clean up the Etherbone error messages. >>>> > >>>> > Best regards, >>>> > Hans >>>> > >>>> > On 2024-01-18 11:29, Weber, Guenter Dr. wrote: >>>> >> Dear friends, >>>> >> >>>> >> >>>> >> I now started the DAQ and it looks like there is a problem with the >>>> >> VETAR2 module. Attached please find the output once the DAQ is started >>>> >> on the RIO4. >>>> >> >>>> >> >>>> >> Here ist the error message: >>>> >> >>>> >> >>>> >> 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866) >>>> >> 11: a:1: .Gsi Etherbone init_slow { >>>> >> (module/gsi_etherbone/gsi_etherbone.c:110) >>>> >> 5: a:1: ..Gsi Etherbone Could not open /sys/class/vetar/vetar0/dactl: No >>>> >> such file or directory. >>>> >>? ?(module/gsi_etherbone/gsi_etherbone.c:120) >>>> >> 5: a:1: ..Calling exit(EXIT_FAILURE)... >>>> >> (module/gsi_etherbone/gsi_etherbone.c:120) >>>> >> >>>> >> How to proceed? >>>> >> >>>> >> >>>> >> >>>> >> Many thanks and best greetings >>>> >> G?nter >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> ------------------------------------------------------------------------ >>>> >> *Von:* subexp-daq im Auftrag von >>>> >> H?kan T Johansson >>>> >> *Gesendet:* Dienstag, 16. Januar 2024 19:20:54 >>>> >> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. >>>> >> *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >>>> >> TRLOII, DRASI, etc. were updated >>>> >> >>>> >> On Tue, 16 Jan 2024, Weber, Guenter Dr. wrote: >>>> >> >>>> >>> >>>> >>> Dear friends, >>>> >>> >>>> >>> >>>> >>> I am just trying to figure out how all the various scripts/commands work >>>> >>> together for setting up our DAQ system. Maybe, you can help to clearify >>>> some >>>> >>> things. >>>> >>> >>>> >>> >>>> >>> >>>> >>> - master.bash >>>> >> >>>> >> This would be intended to run on the readout board (RIO).? The other >>>> >> scripts below is for the PC. >>>> >> >>>> >>> >>>> >>> source ../env/env.sh >>>> >>> ./trloii_setup.sh >>>> >>> # gdb --args \ >>>> >>> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug_drasi/m_read_meb.drasi \ >>>> >>> ? ? ? ? --label=MCAL1 \ >>>> >>> ? ? ? ? --triva=master,fctime=10,ctime=50 \ >>>> >>> ? ? ? ? --log-no-rate-limit \ >>>> >>> ? ? ? ? --server=drasi,dest=lyserv \ >>>> >>> ? ? ? ? --buf=size=400Mi \ >>>> >>> ? ? ? ? --max-ev-size=0x1000000 \ >>>> >>> ? ? ? ? --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ >>>> >>> ? ? ? ? --eb=lyserv \ >>>> >>> ? ? ? ? "$@" >>>> >>> >>>> >>> In the first line some environment variables are set. The second line >>>> tells >>>> >>> the VULOM4 how to operate (i. e. selection from modes of operation >>>> defined >>>> >>> in vulom.trlo). Then DRASI is started with a bunch of parameters. Is >>>> there >>>> >>> somewhere an explanation of the purpose of all these settings? >>>> >> >>>> >> The drasi command line options should be described here: >>>> >> >>>> >> http://fy.chalmers.se/~f96hajo/drasi/doc/drasi_cmdline.html > >> > >>> > >> >>>> > >> > >>> >>>> >> >>> > >> > >>>> >>>> >> >>>> >> (Note: 'lyserv' is the name of your PC, at least as seen from the RIO.) >>>> >> >>>> >> The TRLO II setup file (vulom.trlo) is worse in terms of documentation. >>>> >> The format as such is hopefully rather straightforward.? A description is >>>> >> here: http://fy.chalmers.se/~f96hajo/trloii/man5/trloconf.5.html > >> > >>> > >> >>>> > >> > >>> >>>> >> >>> > >> > >>>> . >>>> >> The actual meaning is more complex, the TRLO II description can be found >>>> >> here: >>>> >> >>>> >> http://fy.chalmers.se/~f96hajo/trloii/vulom4_trlo/descr_defs_frame.html > >> > >>> > >> >>>> > >> > >>> >>>> >> >>> > >> > >>>> >>>> >> >>>> >> (left pane), which just is a colourised version of this: >>>> >> http://fy.chalmers.se/~f96hajo/trloii/description.txt > >> > >>> > >> >>>> > >> > >>> >>>> >> >>> > >> > >>>> >>>> >> >>>> >> It does not describe the .trlo file as such, but what the gateware tries >>>> >> to achieve. >>>> >> >>>> >>> And what is in the last line? I never came accross "$@" before. >>>> >> >>>> >> That would be all the (non-shifted, i.e. not removed) options given to >>>> the >>>> >> script itself, i.e. master.bash. >>>> >> >>>> >>> - eb.bash >>>> >>> >>>> >>> ../drasi/bin/lwrocmerge \ >>>> >>> >>>> >>> ? ? --label=MCAL_EB \ >>>> >>> ? ? --merge-mode=event \ >>>> >>> ? ? --server=trans,flush=1 \ >>>> >>> ? ? --server=stream,flush=1 \ >>>> >>> ? ? --buf=size=1600Mi \ >>>> >>> ? ? --max-ev-size=20Mi \ >>>> >>> ? ? --eb-master=rio4-mcal-1 \ >>>> >>> ? ? --file-writer \ >>>> >>> ? ? --drasi=rio4-mcal-1 >>>> >>> >>>> >>> What is the purpose of this command? >>>> >> >>>> >> This runs an 'event builder' on the PC.? Not strictly needed, but this >>>> >> way, the RIO only ever needs to send data once, to this event-builder >>>> >> (EB).? File writing, and streaming of on-line data is then handled by >>>> this >>>> >> process.? It is cheaper to have better network cards and so on in a plain >>>> >> PC. >>>> >> >>>> >>> Why are values for buffer size and max >>>> >>> event size different then in the command before? >>>> >> >>>> >> The nomenclaturure is unfortunately a bit convoluted below with ucesb >>>> >> regards 'buffer size'.? The --buf in the two commands above give the size >>>> >> of the memory used to buffer data inside the process, and depends on how >>>> >> much memory each machine has.? The --max-ev-size tells how large each >>>> .lmd >>>> >> event can be.? The --max-ev-size configured in the event builder needs to >>>> >> be as large as the sum of all event sources it has.? I.e. should be able >>>> >> to be the same as in your single source above. >>>> >> >>>> >> In the readout itself, any event that is read out cannot be larger than >>>> >> this.? If it is, then the DAQ will report a fatal failure. >>>> >> >>>> >>> - fanout.bash >>>> >>> >>>> >>> #!/bin/bash >>>> >>> while : >>>> >>> do >>>> >>> ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ >>>> >>> ? ? stream://localhost \ >>>> >>> ? ? --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 >>>> >>> sleep 5 >>>> >>> done >>>> >>> >>>> >>> This looks like setting up a connection point to the outside world, >>>> right? >>>> >> >>>> >> Yes.? It accepts connections and will serve them data for online >>>> analysis. >>>> >> >>>> >> stream://localhost? tells it where to read data (here the PC itself where >>>> >> it is running).? Using the 'stream' protocol, which esentially is just >>>> raw >>>> >> LMD events.? (As is the 'transport protocol'.)? That will be served on >>>> the >>>> >> default port used for the stream server set up by the EB above. >>>> >> >>>> >> --server is then the server that accepts connections, and serves data on >>>> >> another port (8001). >>>> >> >>>> >>> And we find the third (random?) value for a buffer size. >>>> >> >>>> >> That bufsize is actually the LMD buffer size used by the stream server. >>>> >> The corresponding value in the readout and EB is set implicitly from the >>>> >> maximum event size... >>>> >> >>>> >>> - rate.bash >>>> >>> >>>> >>> ../drasi/bin/lwrocmon --rate rio4-mcal-1 >>>> >>> >>>> >>> Ok, this I understand. We can look the DAQ over the shoulder and see >>>> what >>>> >>> the thing is doing in terms of number of trigger events, transported >>>> data, >>>> >>> etc. >>>> >> >>>> >>> - log.bash >>>> >>> >>>> >>> ../drasi/bin/lwrocmon --log rio4-mcal-1 localhost >>>> >>> >>>> >>> This is also easy to understand. >>>> >> >>>> >> :-) >>>> >> >>>> >> Then also try to do (on the PC) >>>> >> >>>> >> drasi/bin/lwrocmon --tree rio4-mcal-1 localhost >>>> >> >>>> >> which would show a 'tree-view' monitoring of the running system. >>>> >> >>>> >> >>>> >> Cheers, >>>> >> H?kan >>>> >> >>>> > -- >>>> > subexp-daq mailing list >>>> > subexp-daq at lists.chalmers.se >>>> > https://lists.chalmers.se/mailman/listinfo/subexp-daq > >> > >>> > >> >>>> > >> > >>> >>>> > >>>> -- >>>> subexp-daq mailing list >>>> subexp-daq at lists.chalmers.se >>>> https://lists.chalmers.se/mailman/listinfo/subexp-daq > >> > >>> > >> >>>> >>>> >>> >> -- >> subexp-daq mailing list >> subexp-daq at lists.chalmers.se >> https://lists.chalmers.se/mailman/listinfo/subexp-daq > >> > >> From hans.tornqvist at chalmers.se Mon Jan 22 15:18:20 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Mon, 22 Jan 2024 15:18:20 +0100 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <2a94c163-aeb5-4336-bfe0-44d89172ec99@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de> <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <1aa0afb1bf1e4f91b5d2ab58eb0c62bb@hi-jena.gsi.de> <810ed751-3a8a-43d7-b9b1-7d7c08f8fdf4@chalmers.se> <0dc854ec60194f299b776bc263eb2c72@hi-jena.gsi.de> <5f7958c3-297f-9303-efad-851c23f87ff0@chalmers.se> <897201d9f3424d318c7ed49ce4106aaa@hi-jena.gsi.de> <7f6060e5-ccad-48ba-927e-cb749bea290a@chalmers.se> <2d0ecc20c1ee4921b5ed807b41251fe5@hi-jena.gsi.de> <8fb50894-080f-4bf8-8ed3-f7a965de1b55@chalmers.se> <266475039f5d41fc9c8247714820854a@hi-jena.gsi.de> <2a94c163-aeb5-4336-bfe0-44d89172ec99@chalmers.se> Message-ID: <3aad99c7-e61b-47eb-8dcd-f7f872c56d33@chalmers.se> Dear G?nter, Do you have a schematic of the setup? I.e. what modules have what connections, in the crate and to detectors. Some photos would also be nice. This would help our understanding of the setup. Best regards, Hans & H?kan From g.weber at hi-jena.gsi.de Mon Jan 22 15:29:41 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Mon, 22 Jan 2024 14:29:41 +0000 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <3aad99c7-e61b-47eb-8dcd-f7f872c56d33@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <15538bb513d54707b306c3f2fe845e22@hi-jena.gsi.de> <5b3472f4-5cf2-7a65-201a-146352ad5ce9@chalmers.se> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <1aa0afb1bf1e4f91b5d2ab58eb0c62bb@hi-jena.gsi.de> <810ed751-3a8a-43d7-b9b1-7d7c08f8fdf4@chalmers.se> <0dc854ec60194f299b776bc263eb2c72@hi-jena.gsi.de> <5f7958c3-297f-9303-efad-851c23f87ff0@chalmers.se> <897201d9f3424d318c7ed49ce4106aaa@hi-jena.gsi.de> <7f6060e5-ccad-48ba-927e-cb749bea290a@chalmers.se> <2d0ecc20c1ee4921b5ed807b41251fe5@hi-jena.gsi.de> <8fb50894-080f-4bf8-8ed3-f7a965de1b55@chalmers.se> <266475039f5d41fc9c8247714820854a@hi-jena.gsi.de> <2a94c163-aeb5-4336-bfe0-44d89172ec99@chalmers.se>, <3aad99c7-e61b-47eb-8dcd-f7f872c56d33@chalmers.se> Message-ID: Dear Hans, yes, the VETAR does not have an upstream connection. My impression was that in this case, the internal clock simply starts incrementing more or less in the same way the VULOM does. I have now commented out the VETAR. This is the result: 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: 56583). Thread has no error buffer yet... CPUS: 1 delay: 1 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: 56583). Thread has no error buffer yet... HOST: RIO4-MCAL-1 Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 (eth1). 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = 0x19000000, 1 consumers. 10: lwroc_triva_readout.c:66: Silence TRIVA (HALT) 10: lwroc_net_io.c:167: Started server on port 56583 (data port 51756). client union size: 244 208 188 508 640 204 204 => 640 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 10: lwroc_main.c:706: Log message rate limit not in effect. 10: lwroc_readout.c:112: call readout_init... 10: lwroc_thread_util.c:117: This is the triva control thread! 10: lwroc_thread_util.c:117: This is the net io thread! 10: lwroc_thread_util.c:117: This is the slow_async thread! 10: lwroc_thread_util.c:117: This is the data server thread! 10: lwroc_message_internal.c:472: Message client connected! 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) [192.168.1.1]. 10: lwroc_triva_control.c:370: Setup TRIVA (DISBUS, HALT, MASTER, RESET) 10: lwroc_triva_control.c:418: Minimum event time ctime(5000)+1*rd(691)+3*wr(633)+fctime(1000)=8590 ns (116.414 kHz) 10: lwroc_triva_state.c:1486: (Re)send ident messages... 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 9: lwroc_triva_control.c:507: TEST: GO 10: lwroc_triva_control.c:725: RUN: RESET 10: lwroc_triva_control.c:729: RUN: MT=14 9: lwroc_triva_control.c:737: GO (1 good test triggers done) (max 116.4 kHz) 10: lwroc_triva_readout.c:376: Trigger 14 seen. 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. 10: config/parser.c:287: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { 10: config/parser.c:299: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 10: config/parser.c:287: Opened './main.cfg' { 10: config/config.c:1299: .Global log level=verbose. 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } 10: config/parser.c:299: Closed './main.cfg' } 10: crate/crate.c:347: crate_create { 10: crate/crate.c:673: crate_create(MCAL) } 10: crate/crate.c:899: crate_init(MCAL) { 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) 10: crate/crate.c:923: .Slow-init module[1]=SIS_3316. 10: module/map/map.c:224: ...rd(0x30000000+0x64/32)=535ns wr(0x30000000+0x64/32)=356ns. 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x00800178. 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x3316200e. 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x0125000c. 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x0125000c. 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x0125000c. 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x0125000c. 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 10: crate/crate.c:923: .Slow-init module[2]=SIS_3316. 10: module/map/map.c:224: ...rd(0x31000000+0x64/32)=540ns wr(0x31000000+0x64/32)=360ns. 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x01250011. 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x01250011. 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 10: crate/crate.c:976: .Fast-init module[0]=GSI_VULOM. 10: crate/crate.c:976: .Fast-init module[1]=SIS_3316. 10: module/sis_3316/sis_3316.c:4177: ...threshold[0] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4177: ...threshold[1] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4177: ...threshold[2] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4177: ...threshold[3] = 15 mV -> 0x080001f3 10: module/sis_3316/sis_3316.c:4177: ...threshold[4] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4177: ...threshold[5] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4177: ...threshold[6] = 10 mV -> 0x0800014c 10: module/sis_3316/sis_3316.c:4177: ...threshold[7] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4177: ...threshold[8] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4177: ...threshold[9] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4177: ...threshold[10] = 13 mV -> 0x080001b0 10: module/sis_3316/sis_3316.c:4177: ...threshold[11] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4177: ...threshold[12] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4177: ...threshold[13] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4177: ...threshold[14] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4177: ...threshold[15] = 15 mV -> 0x080001f3 10: crate/crate.c:976: .Fast-init module[2]=SIS_3316. 10: module/sis_3316/sis_3316.c:4177: ...threshold[0] = 10 mV -> 0x0800014c 10: module/sis_3316/sis_3316.c:4177: ...threshold[1] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4177: ...threshold[2] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4177: ...threshold[3] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4177: ...threshold[4] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4177: ...threshold[5] = 10 mV -> 0x0800014c 10: module/sis_3316/sis_3316.c:4177: ...threshold[6] = 13 mV -> 0x080001b0 10: module/sis_3316/sis_3316.c:4177: ...threshold[7] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4177: ...threshold[8] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4177: ...threshold[9] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4177: ...threshold[10] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4177: ...threshold[11] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4177: ...threshold[12] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4177: ...threshold[13] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4177: ...threshold[14] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4177: ...threshold[15] = 8 mV -> 0x0800010a 10: crate/crate.c:1008: .Post-init module[1]=SIS_3316. 10: crate/crate.c:1008: .Post-init module[2]=SIS_3316. 10: crate/crate.c:1073: crate_init(MCAL) } 10: ctrl/ctrl.c:788: Control server online. Thread has no error buffer yet... 5: f_user.c:484: r3bfuser.cfg:1: Weird config! 5: f_user.c:484: Calling abort()... Looks like the DAQ is able to set the thresholds for the first two SIS3316 modules. And then crashes. But there are only these two modules, so the main.cfg is done. I just noticed that I did not put a BARRIER between the initialization of the two SIS3316 modules. Is this relevant? But if it was, the problem would probably occur after the first module and not when the main.cfg was completely processed. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von Hans Toshihide T?rnqvist Gesendet: Montag, 22. Januar 2024 15:18:20 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated Dear G?nter, Do you have a schematic of the setup? I.e. what modules have what connections, in the crate and to detectors. Some photos would also be nice. This would help our understanding of the setup. Best regards, Hans & H?kan -- 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: From hans.tornqvist at chalmers.se Mon Jan 22 15:57:24 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Mon, 22 Jan 2024 15:57:24 +0100 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <1aa0afb1bf1e4f91b5d2ab58eb0c62bb@hi-jena.gsi.de> <810ed751-3a8a-43d7-b9b1-7d7c08f8fdf4@chalmers.se> <0dc854ec60194f299b776bc263eb2c72@hi-jena.gsi.de> <5f7958c3-297f-9303-efad-851c23f87ff0@chalmers.se> <897201d9f3424d318c7ed49ce4106aaa@hi-jena.gsi.de> <7f6060e5-ccad-48ba-927e-cb749bea290a@chalmers.se> <2d0ecc20c1ee4921b5ed807b41251fe5@hi-jena.gsi.de> <8fb50894-080f-4bf8-8ed3-f7a965de1b55@chalmers.se> <266475039f5d41fc9c8247714820854a@hi-jena.gsi.de> <2a94c163-aeb5-4336-bfe0-44d89172ec99@chalmers.se> <3aad99c7-e61b-47eb-8dcd-f7f872c56d33@chalmers.se> Message-ID: <9b98f1d3-dfbb-4a99-bb6c-7d658048ad83@chalmers.se> Dear G?nter, It seems also the r3bfuser configuration parser was updated. I took the file you sent us on the 18th and updated it, with some explanations to the changes. The SIS3316 modules do not need the barrier between. Note that with the changed main.cfg, the data will be different and the unpacker may have some problems, but let's get the DAQ running first :) Best regards, Hans On 2024-01-22 15:29, Weber, Guenter Dr. wrote: > Dear Hans, > > > yes, the VETAR does not have an upstream connection. My impression was > that in this case, the internal clock simply starts incrementing more or > less in the same way the VULOM does. I have now commented out the VETAR. > This is the result: > > > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: > 56583). > Thread has no error buffer yet... > CPUS: 1 > delay: 1 > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: > 56583). > Thread has no error buffer yet... > HOST: RIO4-MCAL-1 > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] > 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 > (eth1). > 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = > 0x19000000, 1 consumers. > 10: lwroc_triva_readout.c:66: Silence TRIVA? (HALT) > 10: lwroc_net_io.c:167: Started server on port 56583 (data port 51756). > client union size: 244 208 188 508 640 204 204? => 640 > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: > /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 > 10: lwroc_main.c:706: Log message rate limit not in effect. > 10: lwroc_readout.c:112: call readout_init... > 10: lwroc_thread_util.c:117: This is the triva control thread! > 10: lwroc_thread_util.c:117: This is the net io thread! > 10: lwroc_thread_util.c:117: This is the slow_async thread! > 10: lwroc_thread_util.c:117: This is the data server thread! > 10: lwroc_message_internal.c:472: Message client connected! > 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) > [192.168.1.1]. > 10: lwroc_triva_control.c:370: Setup TRIVA? (DISBUS, HALT, MASTER, RESET) > 10: lwroc_triva_control.c:418: Minimum event time > ctime(5000)+1*rd(691)+3*wr(633)+fctime(1000)=8590 ns (116.414 kHz) > 10: lwroc_triva_state.c:1486: (Re)send ident messages... > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 > 9: lwroc_triva_control.c:507: TEST: GO > 10: lwroc_triva_control.c:725: RUN: RESET > 10: lwroc_triva_control.c:729: RUN: MT=14 > 9: lwroc_triva_control.c:737:?? GO (1 good test triggers done) (max > 116.4 kHz) > 10: lwroc_triva_readout.c:376: Trigger 14 seen. > 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. > 10: config/parser.c:287: Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { > 10: config/parser.c:299: Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 > (IN_READOUT).? EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: config/parser.c:287: Opened './main.cfg' { > 10: config/config.c:1299: .Global log level=verbose. > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:299: Closed './main.cfg' } > 10: crate/crate.c:347: crate_create { > 10: crate/crate.c:673: crate_create(MCAL) } > 10: crate/crate.c:899: crate_init(MCAL) { > 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) > 10: crate/crate.c:923: .Slow-init module[1]=SIS_3316. > 10: module/map/map.c:224: ...rd(0x30000000+0x64/32)=535ns > wr(0x30000000+0x64/32)=356ns. > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x00800178. > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x3316200e. > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x0125000c. > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, > and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 > (IN_READOUT).? EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, > and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 > (IN_READOUT).? EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: crate/crate.c:923: .Slow-init module[2]=SIS_3316. > 10: module/map/map.c:224: ...rd(0x31000000+0x64/32)=540ns > wr(0x31000000+0x64/32)=360ns. > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x01250011. > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, > and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 > (IN_READOUT).? EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: crate/crate.c:976: .Fast-init module[0]=GSI_VULOM. > 10: crate/crate.c:976: .Fast-init module[1]=SIS_3316. > 10: module/sis_3316/sis_3316.c:4177: ...threshold[0] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[1] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[2] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[3] = 15 mV -> 0x080001f3 > 10: module/sis_3316/sis_3316.c:4177: ...threshold[4] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[5] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[6] = 10 mV -> 0x0800014c > 10: module/sis_3316/sis_3316.c:4177: ...threshold[7] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[8] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[9] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[10] = 13 mV -> 0x080001b0 > 10: module/sis_3316/sis_3316.c:4177: ...threshold[11] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[12] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[13] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[14] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[15] = 15 mV -> 0x080001f3 > 10: crate/crate.c:976: .Fast-init module[2]=SIS_3316. > 10: module/sis_3316/sis_3316.c:4177: ...threshold[0] = 10 mV -> 0x0800014c > 10: module/sis_3316/sis_3316.c:4177: ...threshold[1] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[2] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[3] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[4] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[5] = 10 mV -> 0x0800014c > 10: module/sis_3316/sis_3316.c:4177: ...threshold[6] = 13 mV -> 0x080001b0 > 10: module/sis_3316/sis_3316.c:4177: ...threshold[7] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[8] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[9] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[10] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[11] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[12] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[13] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[14] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[15] = 8 mV -> 0x0800010a > 10: crate/crate.c:1008: .Post-init module[1]=SIS_3316. > 10: crate/crate.c:1008: .Post-init module[2]=SIS_3316. > 10: crate/crate.c:1073: crate_init(MCAL) } > 10: ctrl/ctrl.c:788: Control server online. > Thread has no error buffer yet... > 5: f_user.c:484: r3bfuser.cfg:1: Weird config! > 5: f_user.c:484: Calling abort()... > > > Looks like the DAQ is able to set the thresholds for the first two > SIS3316 modules. And then crashes. But there are only these two modules, > so the main.cfg is done. I just noticed that I did not put a BARRIER > between the initialization of the two SIS3316 modules. Is this relevant? > But if it was, the problem would probably occur after the first module > and not when the main.cfg was completely processed. > > > > > > Best greetings > > G?nter > > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > Hans Toshihide T?rnqvist > *Gesendet:* Montag, 22. Januar 2024 15:18:20 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > TRLOII, DRASI, etc. were updated > Dear G?nter, > > Do you have a schematic of the setup? I.e. what modules have what > connections, in the crate and to detectors. > > Some photos would also be nice. > > This would help our understanding of the setup. > > Best regards, > Hans & H?kan > -- > subexp-daq mailing list > subexp-daq at lists.chalmers.se > https://lists.chalmers.se/mailman/listinfo/subexp-daq > > -------------- next part -------------- # Please see the original r3bfuser.cfg which explains the current # configuration syntax a (little) bit better. I have added a few # comments to the changes necessary to the file that you sent us # on 2024-01-18. # This is a remnant from the nurdlib config parser, removed. # [r3bfuser] # Having both "wr_id" and "do_timestamp" is redundant, the latter removed. wr_id=0x200 # do_timestamp=1 # "do_spill_triggers=1" replaced by "spill_trigger=module,module_i,timeout". # do_spill_triggers=1 # "do_tpat=1" replaced by "tpat=module,module_i,triggers...". # do_tpat=1 # This was too generic once we had several vuloms in one crate... # Removed. # vulom_addr=3 # Is this a feature that was implemented by Bastii? I cannot find this # in the r3bfuser history. Currently nurdlib provides reading out trloii # scalers, e.g. you can set in main.cfg: # GSI_VULOM4(address) { ecl=0..15 } # # Read out the Vulom RAW scalers (1..16) on the specified trigger number # do_trlo_scalers=1 # Replaced by "lmu_scalers=module,module_i". # g_do_lmu_scalers=1 From g.weber at hi-jena.gsi.de Mon Jan 22 21:32:14 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Mon, 22 Jan 2024 20:32:14 +0000 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <9b98f1d3-dfbb-4a99-bb6c-7d658048ad83@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <1aa0afb1bf1e4f91b5d2ab58eb0c62bb@hi-jena.gsi.de> <810ed751-3a8a-43d7-b9b1-7d7c08f8fdf4@chalmers.se> <0dc854ec60194f299b776bc263eb2c72@hi-jena.gsi.de> <5f7958c3-297f-9303-efad-851c23f87ff0@chalmers.se> <897201d9f3424d318c7ed49ce4106aaa@hi-jena.gsi.de> <7f6060e5-ccad-48ba-927e-cb749bea290a@chalmers.se> <2d0ecc20c1ee4921b5ed807b41251fe5@hi-jena.gsi.de> <8fb50894-080f-4bf8-8ed3-f7a965de1b55@chalmers.se> <266475039f5d41fc9c8247714820854a@hi-jena.gsi.de> <2a94c163-aeb5-4336-bfe0-44d89172ec99@chalmers.se> <3aad99c7-e61b-47eb-8dcd-f7f872c56d33@chalmers.se> , <9b98f1d3-dfbb-4a99-bb6c-7d658048ad83@chalmers.se> Message-ID: <09e3707e3d5844e8a6ded8b78b70358d@hi-jena.gsi.de> Dear Hans, thank you for the explanations for r3bfuser.cfg. In the end only a single cryptic line remains in this file, right? With the new R3B config and modified VULOM entry in main.cfg I get the following result: ... everything looks nice and the SIS3316 threshold are set ... 10: crate/crate.c:1008: .Post-init module[1]=SIS_3316. 10: crate/crate.c:1008: .Post-init module[2]=SIS_3316. 10: crate/crate.c:1073: crate_init(MCAL) } 5: f_user.c:1257: had readout error, ret=0x4, trigger=1, prev=1 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 5: module/sis_3316/sis_3316.c:3096: [2]: timeout while polling for previous bank addr (bank 0 != 0) on ch 0 5: module/sis_3316/sis_3316.c:2512: sis3316 bank of channel not ready for readout. 5: module/sis_3316/sis_3316.c:2329: sis3316 ch[0] test_channel failed 5: crate/crate.c:1954: MCAL[2]=SIS_3316 readout error=0x00000004, dumping data: 10: crate/crate.c:1970: ---[ Dump begin ]--- 10: crate/crate.c:1970: Start=0x3005e230 Bytes=0=0x0 10: crate/crate.c:1970: ---[ Dump end ]--- 5: crate/crate.c:1449: MCAL: readout failed! 5: crate/crate.c:1493: MCAL: had problems, re-initializing. 10: crate/crate.c:683: crate_deinit(MCAL) { 10: crate/crate.c:707: crate_deinit(MCAL) } 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 10: crate/crate.c:899: crate_init(MCAL) { 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) 10: crate/crate.c:923: .Slow-init module[1]=SIS_3316. 10: module/map/map.c:224: ...rd(0x30000000+0x64/32)=535ns wr(0x30000000+0x64/32)=356ns. 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x00800178. 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x3316200e. 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x0125000c. 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x0125000c. 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x0125000c. 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x0125000c. 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 10: crate/crate.c:923: .Slow-init module[2]=SIS_3316. 10: module/map/map.c:224: ...rd(0x31000000+0x64/32)=540ns wr(0x31000000+0x64/32)=360ns. 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. 10: crate/crate.c:923: .Slow-init module[2]=SIS_3316. 10: module/map/map.c:224: ...rd(0x31000000+0x64/32)=540ns wr(0x31000000+0x64/32)=360ns. 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x01250011. 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x01250011. ^C8: lwroc_main.c:106: SIGINT received. I stopped the DAQ software manually. To me it looked like, the software tried every 10 seconds to restart the DAQ. The DAQ setup consists of 1 RIO, 1 TRIVA, 1 VULOM B, 2 SIS3316, 1 VETAR2. The VULOM provides two output signals. A fast one to synchronize the SIS3316 modules and a slow one (10 Hz) that is used for triggering the DAQ. In this test setup no external signals are fed to the digitizers. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von Hans Toshihide T?rnqvist Gesendet: Montag, 22. Januar 2024 15:57:24 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated Dear G?nter, It seems also the r3bfuser configuration parser was updated. I took the file you sent us on the 18th and updated it, with some explanations to the changes. The SIS3316 modules do not need the barrier between. Note that with the changed main.cfg, the data will be different and the unpacker may have some problems, but let's get the DAQ running first :) Best regards, Hans On 2024-01-22 15:29, Weber, Guenter Dr. wrote: > Dear Hans, > > > yes, the VETAR does not have an upstream connection. My impression was > that in this case, the internal clock simply starts incrementing more or > less in the same way the VULOM does. I have now commented out the VETAR. > This is the result: > > > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: > 56583). > Thread has no error buffer yet... > CPUS: 1 > delay: 1 > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: > 56583). > Thread has no error buffer yet... > HOST: RIO4-MCAL-1 > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] > 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 > (eth1). > 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = > 0x19000000, 1 consumers. > 10: lwroc_triva_readout.c:66: Silence TRIVA (HALT) > 10: lwroc_net_io.c:167: Started server on port 56583 (data port 51756). > client union size: 244 208 188 508 640 204 204 => 640 > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: > /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 > 10: lwroc_main.c:706: Log message rate limit not in effect. > 10: lwroc_readout.c:112: call readout_init... > 10: lwroc_thread_util.c:117: This is the triva control thread! > 10: lwroc_thread_util.c:117: This is the net io thread! > 10: lwroc_thread_util.c:117: This is the slow_async thread! > 10: lwroc_thread_util.c:117: This is the data server thread! > 10: lwroc_message_internal.c:472: Message client connected! > 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) > [192.168.1.1]. > 10: lwroc_triva_control.c:370: Setup TRIVA (DISBUS, HALT, MASTER, RESET) > 10: lwroc_triva_control.c:418: Minimum event time > ctime(5000)+1*rd(691)+3*wr(633)+fctime(1000)=8590 ns (116.414 kHz) > 10: lwroc_triva_state.c:1486: (Re)send ident messages... > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 > 9: lwroc_triva_control.c:507: TEST: GO > 10: lwroc_triva_control.c:725: RUN: RESET > 10: lwroc_triva_control.c:729: RUN: MT=14 > 9: lwroc_triva_control.c:737: GO (1 good test triggers done) (max > 116.4 kHz) > 10: lwroc_triva_readout.c:376: Trigger 14 seen. > 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. > 10: config/parser.c:287: Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { > 10: config/parser.c:299: Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 > (IN_READOUT). EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: config/parser.c:287: Opened './main.cfg' { > 10: config/config.c:1299: .Global log level=verbose. > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:299: Closed './main.cfg' } > 10: crate/crate.c:347: crate_create { > 10: crate/crate.c:673: crate_create(MCAL) } > 10: crate/crate.c:899: crate_init(MCAL) { > 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) > 10: crate/crate.c:923: .Slow-init module[1]=SIS_3316. > 10: module/map/map.c:224: ...rd(0x30000000+0x64/32)=535ns > wr(0x30000000+0x64/32)=356ns. > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x00800178. > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x3316200e. > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x0125000c. > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, > and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 > (IN_READOUT). EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, > and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 > (IN_READOUT). EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: crate/crate.c:923: .Slow-init module[2]=SIS_3316. > 10: module/map/map.c:224: ...rd(0x31000000+0x64/32)=540ns > wr(0x31000000+0x64/32)=360ns. > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x01250011. > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, > and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 > (IN_READOUT). EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: crate/crate.c:976: .Fast-init module[0]=GSI_VULOM. > 10: crate/crate.c:976: .Fast-init module[1]=SIS_3316. > 10: module/sis_3316/sis_3316.c:4177: ...threshold[0] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[1] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[2] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[3] = 15 mV -> 0x080001f3 > 10: module/sis_3316/sis_3316.c:4177: ...threshold[4] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[5] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[6] = 10 mV -> 0x0800014c > 10: module/sis_3316/sis_3316.c:4177: ...threshold[7] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[8] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[9] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[10] = 13 mV -> 0x080001b0 > 10: module/sis_3316/sis_3316.c:4177: ...threshold[11] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[12] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[13] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[14] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[15] = 15 mV -> 0x080001f3 > 10: crate/crate.c:976: .Fast-init module[2]=SIS_3316. > 10: module/sis_3316/sis_3316.c:4177: ...threshold[0] = 10 mV -> 0x0800014c > 10: module/sis_3316/sis_3316.c:4177: ...threshold[1] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[2] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[3] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[4] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[5] = 10 mV -> 0x0800014c > 10: module/sis_3316/sis_3316.c:4177: ...threshold[6] = 13 mV -> 0x080001b0 > 10: module/sis_3316/sis_3316.c:4177: ...threshold[7] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[8] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[9] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[10] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[11] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[12] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[13] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[14] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4177: ...threshold[15] = 8 mV -> 0x0800010a > 10: crate/crate.c:1008: .Post-init module[1]=SIS_3316. > 10: crate/crate.c:1008: .Post-init module[2]=SIS_3316. > 10: crate/crate.c:1073: crate_init(MCAL) } > 10: ctrl/ctrl.c:788: Control server online. > Thread has no error buffer yet... > 5: f_user.c:484: r3bfuser.cfg:1: Weird config! > 5: f_user.c:484: Calling abort()... > > > Looks like the DAQ is able to set the thresholds for the first two > SIS3316 modules. And then crashes. But there are only these two modules, > so the main.cfg is done. I just noticed that I did not put a BARRIER > between the initialization of the two SIS3316 modules. Is this relevant? > But if it was, the problem would probably occur after the first module > and not when the main.cfg was completely processed. > > > > > > Best greetings > > G?nter > > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > Hans Toshihide T?rnqvist > *Gesendet:* Montag, 22. Januar 2024 15:18:20 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > TRLOII, DRASI, etc. were updated > Dear G?nter, > > Do you have a schematic of the setup? I.e. what modules have what > connections, in the crate and to detectors. > > Some photos would also be nice. > > This would help our understanding of the setup. > > Best regards, > Hans & H?kan > -- > 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: From f96hajo at chalmers.se Mon Jan 22 23:01:43 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Mon, 22 Jan 2024 23:01:43 +0100 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <09e3707e3d5844e8a6ded8b78b70358d@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <1aa0afb1bf1e4f91b5d2ab58eb0c62bb@hi-jena.gsi.de> <810ed751-3a8a-43d7-b9b1-7d7c08f8fdf4@chalmers.se> <0dc854ec60194f299b776bc263eb2c72@hi-jena.gsi.de> <5f7958c3-297f-9303-efad-851c23f87ff0@chalmers.se> <897201d9f3424d318c7ed49ce4106aaa@hi-jena.gsi.de> <7f6060e5-ccad-48ba-927e-cb749bea290a@chalmers.se> <2d0ecc20c1ee4921b5ed807b41251fe5@hi-jena.gsi.de> <8fb50894-080f-4bf8-8ed3-f7a965de1b55@chalmers.se> <266475039f5d41fc9c8247714820854a@hi-jena.gsi.de> <2a94c163-aeb5-4336-bfe0-44d89172ec99@chalmers.se> <3aad99c7-e61b-47eb-8dcd-f7f872c56d33@chalmers.se> , <9b98f1d3-dfbb-4a99-bb6c-7d658048ad83@chalmers.se> <09e3707e3d5844e8a6ded8b78b70358d@hi-jena.gsi.de> Message-ID: <36e8dae7-13cb-9258-99f3-4c5f2004c2a7@chalmers.se> Dear G?nter, The error would be the line > 5: module/sis_3316/sis_3316.c:3096: [2]: timeout while polling for previous bank addr (bank 0 != 0) on ch 0 (the printout from lwroc_triva_state.c is basically debug help, just trying to help identifying which system is stuck, in case one has multiple crates (not the case here).) Question: when the modules are re-inited (which always happens after readout failure), it looks like the two SIS3316 modules have different firmwares? Is that intentional? How do those values compare to the other DAQ system? Best regards, H?kan On Mon, 22 Jan 2024, Weber, Guenter Dr. wrote: > > Dear Hans, > > > thank you for the explanations for r3bfuser.cfg. In the end only a single cryptic line remains in this file, right? > > > With the new R3B config and modified VULOM entry in main.cfg I get the following result: > > > ... everything looks nice and the SIS3316 threshold are set ... > > 10: crate/crate.c:1008: .Post-init module[1]=SIS_3316. > 10: crate/crate.c:1008: .Post-init module[2]=SIS_3316. > 10: crate/crate.c:1073: crate_init(MCAL) } > 5: f_user.c:1257: had readout error, ret=0x4, trigger=1, prev=1 > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 5: module/sis_3316/sis_3316.c:3096: [2]: timeout while polling for previous bank addr (bank 0 != 0) on ch 0 > 5: module/sis_3316/sis_3316.c:2512: sis3316 bank of channel not ready for readout. > 5: module/sis_3316/sis_3316.c:2329: sis3316 ch[0] test_channel failed > 5: crate/crate.c:1954: MCAL[2]=SIS_3316 readout error=0x00000004, dumping data: > 10: crate/crate.c:1970: ---[ Dump begin ]--- > 10: crate/crate.c:1970: Start=0x3005e230? Bytes=0=0x0 > 10: crate/crate.c:1970: ---[? Dump end? ]--- > 5: crate/crate.c:1449: MCAL: readout failed! > 5: crate/crate.c:1493: MCAL: had problems, re-initializing. > 10: crate/crate.c:683: crate_deinit(MCAL) { > 10: crate/crate.c:707: crate_deinit(MCAL) } > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: crate/crate.c:899: crate_init(MCAL) { > 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) > 10: crate/crate.c:923: .Slow-init module[1]=SIS_3316. > 10: module/map/map.c:224: ...rd(0x30000000+0x64/32)=535ns wr(0x30000000+0x64/32)=356ns. > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x00800178. > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x3316200e. > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x0125000c. > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: crate/crate.c:923: .Slow-init module[2]=SIS_3316. > 10: module/map/map.c:224: ...rd(0x31000000+0x64/32)=540ns wr(0x31000000+0x64/32)=360ns. > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. > 10: crate/crate.c:923: .Slow-init module[2]=SIS_3316. > 10: module/map/map.c:224: ...rd(0x31000000+0x64/32)=540ns wr(0x31000000+0x64/32)=360ns. > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x01250011. > ^C8: lwroc_main.c:106: SIGINT received. > > I stopped the DAQ software manually. To me it looked like, the software tried every 10 seconds to restart the DAQ. > > > The DAQ setup consists of 1 RIO, 1 TRIVA, 1 VULOM B, 2 SIS3316, 1 VETAR2. > > The VULOM provides two output signals. A fast one to synchronize the SIS3316 modules and a slow one (10 Hz) that is used for triggering the DAQ. In this test setup no external signals are fed to the digitizers. > > > > > > Best greetings > > G?nter > > > > _______________________________________________________________________________________________________________________________________________________________________________________________________________________________ > Von: subexp-daq im Auftrag von Hans Toshihide T?rnqvist > Gesendet: Montag, 22. Januar 2024 15:57:24 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated ? > Dear G?nter, > > It seems also the r3bfuser configuration parser was updated. I took the > file you sent us on the 18th and updated it, with some explanations to > the changes. > > The SIS3316 modules do not need the barrier between. Note that with the > changed main.cfg, the data will be different and the unpacker may have > some problems, but let's get the DAQ running first :) > > Best regards, > Hans > > On 2024-01-22 15:29, Weber, Guenter Dr. wrote: > > Dear Hans, > > > > > > yes, the VETAR does not have an upstream connection. My impression was > > that in this case, the internal clock simply starts incrementing more or > > less in the same way the VULOM does. I have now commented out the VETAR. > > This is the result: > > > > > > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: > > 56583). > > Thread has no error buffer yet... > > CPUS: 1 > > delay: 1 > > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: > > 56583). > > Thread has no error buffer yet... > > HOST: RIO4-MCAL-1 > > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] > > 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 > > (eth1). > > 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = > > 0x19000000, 1 consumers. > > 10: lwroc_triva_readout.c:66: Silence TRIVA? (HALT) > > 10: lwroc_net_io.c:167: Started server on port 56583 (data port 51756). > > client union size: 244 208 188 508 640 204 204? => 640 > > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: > > /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 > > 10: lwroc_main.c:706: Log message rate limit not in effect. > > 10: lwroc_readout.c:112: call readout_init... > > 10: lwroc_thread_util.c:117: This is the triva control thread! > > 10: lwroc_thread_util.c:117: This is the net io thread! > > 10: lwroc_thread_util.c:117: This is the slow_async thread! > > 10: lwroc_thread_util.c:117: This is the data server thread! > > 10: lwroc_message_internal.c:472: Message client connected! > > 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) > > [192.168.1.1]. > > 10: lwroc_triva_control.c:370: Setup TRIVA? (DISBUS, HALT, MASTER, RESET) > > 10: lwroc_triva_control.c:418: Minimum event time > > ctime(5000)+1*rd(691)+3*wr(633)+fctime(1000)=8590 ns (116.414 kHz) > > 10: lwroc_triva_state.c:1486: (Re)send ident messages... > > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 > > 9: lwroc_triva_control.c:507: TEST: GO > > 10: lwroc_triva_control.c:725: RUN: RESET > > 10: lwroc_triva_control.c:729: RUN: MT=14 > > 9: lwroc_triva_control.c:737:?? GO (1 good test triggers done) (max > > 116.4 kHz) > > 10: lwroc_triva_readout.c:376: Trigger 14 seen. > > 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. > > 10: config/parser.c:287: Opened > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { > > 10: config/parser.c:299: Closed > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 > > (IN_READOUT).? EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 10: config/parser.c:287: Opened './main.cfg' { > > 10: config/config.c:1299: .Global log level=verbose. > > 10: config/parser.c:287: .Opened > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { > > 10: config/parser.c:299: .Closed > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } > > 10: config/parser.c:287: .Opened > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { > > 10: config/parser.c:299: .Closed > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } > > 10: config/parser.c:287: .Opened > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > > 10: config/parser.c:299: .Closed > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > > 10: config/parser.c:287: .Opened > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > > 10: config/parser.c:299: .Closed > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > > 10: config/parser.c:287: .Opened > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > > 10: config/parser.c:299: .Closed > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > > 10: config/parser.c:287: .Opened > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > > 10: config/parser.c:299: .Closed > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > > 10: config/parser.c:287: .Opened > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > > 10: config/parser.c:299: .Closed > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > > 10: config/parser.c:299: Closed './main.cfg' } > > 10: crate/crate.c:347: crate_create { > > 10: crate/crate.c:673: crate_create(MCAL) } > > 10: crate/crate.c:899: crate_init(MCAL) { > > 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. > > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) > > 10: crate/crate.c:923: .Slow-init module[1]=SIS_3316. > > 10: module/map/map.c:224: ...rd(0x30000000+0x64/32)=535ns > > wr(0x30000000+0x64/32)=356ns. > > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x00800178. > > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x3316200e. > > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x0125000c. > > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x0125000c. > > 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x0125000c. > > 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x0125000c. > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, > > and in deadtime. > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 > > (IN_READOUT).? EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, > > and in deadtime. > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 > > (IN_READOUT).? EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 10: crate/crate.c:923: .Slow-init module[2]=SIS_3316. > > 10: module/map/map.c:224: ...rd(0x31000000+0x64/32)=540ns > > wr(0x31000000+0x64/32)=360ns. > > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. > > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. > > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. > > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. > > 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x01250011. > > 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x01250011. > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, > > and in deadtime. > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 > > (IN_READOUT).? EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 10: crate/crate.c:976: .Fast-init module[0]=GSI_VULOM. > > 10: crate/crate.c:976: .Fast-init module[1]=SIS_3316. > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[0] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[1] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[2] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[3] = 15 mV -> 0x080001f3 > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[4] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[5] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[6] = 10 mV -> 0x0800014c > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[7] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[8] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[9] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[10] = 13 mV -> 0x080001b0 > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[11] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[12] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[13] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[14] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[15] = 15 mV -> 0x080001f3 > > 10: crate/crate.c:976: .Fast-init module[2]=SIS_3316. > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[0] = 10 mV -> 0x0800014c > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[1] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[2] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[3] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[4] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[5] = 10 mV -> 0x0800014c > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[6] = 13 mV -> 0x080001b0 > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[7] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[8] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[9] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[10] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[11] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[12] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[13] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[14] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[15] = 8 mV -> 0x0800010a > > 10: crate/crate.c:1008: .Post-init module[1]=SIS_3316. > > 10: crate/crate.c:1008: .Post-init module[2]=SIS_3316. > > 10: crate/crate.c:1073: crate_init(MCAL) } > > 10: ctrl/ctrl.c:788: Control server online. > > Thread has no error buffer yet... > > 5: f_user.c:484: r3bfuser.cfg:1: Weird config! > > 5: f_user.c:484: Calling abort()... > > > > > > Looks like the DAQ is able to set the thresholds for the first two > > SIS3316 modules. And then crashes. But there are only these two modules, > > so the main.cfg is done. I just noticed that I did not put a BARRIER > > between the initialization of the two SIS3316 modules. Is this relevant? > > But if it was, the problem would probably occur after the first module > > and not when the main.cfg was completely processed. > > > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > > ------------------------------------------------------------------------ > > *Von:* subexp-daq im Auftrag von > > Hans Toshihide T?rnqvist > > *Gesendet:* Montag, 22. Januar 2024 15:18:20 > > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > > TRLOII, DRASI, etc. were updated > > Dear G?nter, > > > > Do you have a schematic of the setup? I.e. what modules have what > > connections, in the crate and to detectors. > > > > Some photos would also be nice. > > > > This would help our understanding of the setup. > > > > Best regards, > > Hans & H?kan > > -- > > subexp-daq mailing list > > subexp-daq at lists.chalmers.se > > https://lists.chalmers.se/mailman/listinfo/subexp-daq > > > > > > From g.weber at hi-jena.gsi.de Tue Jan 23 11:05:12 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 23 Jan 2024 10:05:12 +0000 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <36e8dae7-13cb-9258-99f3-4c5f2004c2a7@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <9b8c9919505c48c1b3981670af51a1de@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <1aa0afb1bf1e4f91b5d2ab58eb0c62bb@hi-jena.gsi.de> <810ed751-3a8a-43d7-b9b1-7d7c08f8fdf4@chalmers.se> <0dc854ec60194f299b776bc263eb2c72@hi-jena.gsi.de> <5f7958c3-297f-9303-efad-851c23f87ff0@chalmers.se> <897201d9f3424d318c7ed49ce4106aaa@hi-jena.gsi.de> <7f6060e5-ccad-48ba-927e-cb749bea290a@chalmers.se> <2d0ecc20c1ee4921b5ed807b41251fe5@hi-jena.gsi.de> <8fb50894-080f-4bf8-8ed3-f7a965de1b55@chalmers.se> <266475039f5d41fc9c8247714820854a@hi-jena.gsi.de> <2a94c163-aeb5-4336-bfe0-44d89172ec99@chalmers.se> <3aad99c7-e61b-47eb-8dcd-f7f872c56d33@chalmers.se> , <9b98f1d3-dfbb-4a99-bb6c-7d658048ad83@chalmers.se> <09e3707e3d5844e8a6ded8b78b70358d@hi-jena.gsi.de>, <36e8dae7-13cb-9258-99f3-4c5f2004c2a7@chalmers.se> Message-ID: <929564d321f54545b6abb2a24c9c6162@hi-jena.gsi.de> Dear H?kan, as far as I know we never touched the SIS3316 firmware. But, as you know by now, I know every little about the details of our DAQ, unfortunately. Just for checking, I now removed the SIS3316 entries from main.cfg. Thus, after also eliminating the VETAR, we just have the VULOM. And now I don't get any errors: 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: 56583). Thread has no error buffer yet... CPUS: 1 delay: 1 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: 56583). Thread has no error buffer yet... HOST: RIO4-MCAL-1 Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 (eth1). 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = 0x19000000, 1 consumers. 10: lwroc_triva_readout.c:66: Silence TRIVA (HALT) 10: lwroc_net_io.c:167: Started server on port 56583 (data port 39340). client union size: 244 208 188 508 640 204 204 => 640 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 10: lwroc_main.c:706: Log message rate limit not in effect. 10: lwroc_readout.c:112: call readout_init... 10: lwroc_thread_util.c:117: This is the triva control thread! 10: lwroc_thread_util.c:117: This is the net io thread! 10: lwroc_thread_util.c:117: This is the slow_async thread! 10: lwroc_thread_util.c:117: This is the data server thread! 10: lwroc_message_internal.c:472: Message client connected! 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) [192.168.1.1]. 10: lwroc_triva_control.c:370: Setup TRIVA (DISBUS, HALT, MASTER, RESET) 10: lwroc_triva_control.c:418: Minimum event time ctime(5000)+1*rd(689)+3*wr(634)+fctime(1000)=8591 ns (116.401 kHz) 10: lwroc_triva_state.c:1486: (Re)send ident messages... 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 9: lwroc_triva_control.c:507: TEST: GO 10: lwroc_triva_control.c:725: RUN: RESET 10: lwroc_triva_control.c:729: RUN: MT=14 9: lwroc_triva_control.c:737: GO (1 good test triggers done) (max 116.4 kHz) 10: lwroc_triva_readout.c:376: Trigger 14 seen. 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. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 10: config/parser.c:287: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { 10: config/parser.c:299: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } 10: config/parser.c:287: Opened './main.cfg' { 10: config/config.c:1299: .Global log level=verbose. 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } 10: config/parser.c:287: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { 10: config/parser.c:299: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } 10: config/parser.c:299: Closed './main.cfg' } 10: crate/crate.c:347: crate_create { 10: crate/crate.c:673: crate_create(MCAL) } 10: crate/crate.c:899: crate_init(MCAL) { 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) 10: crate/crate.c:976: .Fast-init module[0]=GSI_VULOM. 10: crate/crate.c:1073: crate_init(MCAL) } 10: ctrl/ctrl.c:788: Control server online. Thread has no error buffer yet... 10: f_user.c:559: WR ID=0x200. 10: f_user.c:565: TS offset unset. Will not modify stamp. 10: f_user.c:572: TPAT: No. 10: f_user.c:573: Sync-check: No. 10: f_user.c:575: Spill triggers: No. 10: f_user.c:576: LMU: No. 10: f_user.c:577: Timer latches: No. 10: f_user.c:578: Spill shape: No. 10: f_user.c:579: Micro-structure: No. 10: f_user.c:581: Multi-event flag: No. 10: f_user.c:586: UDP destination: None. The DAQ is running with 10 Hz, as expected. Is there an easy way to look at the output of the DAQ? This should now contain only of the time stamp and the 16 scaler channels from the VULOM. If we can verify that this minimum example is now running as expected, we can go back to debugging the SIS3316 part, ok? Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Montag, 22. Januar 2024 23:01:43 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated Dear G?nter, The error would be the line > 5: module/sis_3316/sis_3316.c:3096: [2]: timeout while polling for previous bank addr (bank 0 != 0) on ch 0 (the printout from lwroc_triva_state.c is basically debug help, just trying to help identifying which system is stuck, in case one has multiple crates (not the case here).) Question: when the modules are re-inited (which always happens after readout failure), it looks like the two SIS3316 modules have different firmwares? Is that intentional? How do those values compare to the other DAQ system? Best regards, H?kan On Mon, 22 Jan 2024, Weber, Guenter Dr. wrote: > > Dear Hans, > > > thank you for the explanations for r3bfuser.cfg. In the end only a single cryptic line remains in this file, right? > > > With the new R3B config and modified VULOM entry in main.cfg I get the following result: > > > ... everything looks nice and the SIS3316 threshold are set ... > > 10: crate/crate.c:1008: .Post-init module[1]=SIS_3316. > 10: crate/crate.c:1008: .Post-init module[2]=SIS_3316. > 10: crate/crate.c:1073: crate_init(MCAL) } > 5: f_user.c:1257: had readout error, ret=0x4, trigger=1, prev=1 > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 5: module/sis_3316/sis_3316.c:3096: [2]: timeout while polling for previous bank addr (bank 0 != 0) on ch 0 > 5: module/sis_3316/sis_3316.c:2512: sis3316 bank of channel not ready for readout. > 5: module/sis_3316/sis_3316.c:2329: sis3316 ch[0] test_channel failed > 5: crate/crate.c:1954: MCAL[2]=SIS_3316 readout error=0x00000004, dumping data: > 10: crate/crate.c:1970: ---[ Dump begin ]--- > 10: crate/crate.c:1970: Start=0x3005e230 Bytes=0=0x0 > 10: crate/crate.c:1970: ---[ Dump end ]--- > 5: crate/crate.c:1449: MCAL: readout failed! > 5: crate/crate.c:1493: MCAL: had problems, re-initializing. > 10: crate/crate.c:683: crate_deinit(MCAL) { > 10: crate/crate.c:707: crate_deinit(MCAL) } > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: crate/crate.c:899: crate_init(MCAL) { > 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) > 10: crate/crate.c:923: .Slow-init module[1]=SIS_3316. > 10: module/map/map.c:224: ...rd(0x30000000+0x64/32)=535ns wr(0x30000000+0x64/32)=356ns. > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x00800178. > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x3316200e. > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x0125000c. > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: crate/crate.c:923: .Slow-init module[2]=SIS_3316. > 10: module/map/map.c:224: ...rd(0x31000000+0x64/32)=540ns wr(0x31000000+0x64/32)=360ns. > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. > 10: crate/crate.c:923: .Slow-init module[2]=SIS_3316. > 10: module/map/map.c:224: ...rd(0x31000000+0x64/32)=540ns wr(0x31000000+0x64/32)=360ns. > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x01250011. > ^C8: lwroc_main.c:106: SIGINT received. > > I stopped the DAQ software manually. To me it looked like, the software tried every 10 seconds to restart the DAQ. > > > The DAQ setup consists of 1 RIO, 1 TRIVA, 1 VULOM B, 2 SIS3316, 1 VETAR2. > > The VULOM provides two output signals. A fast one to synchronize the SIS3316 modules and a slow one (10 Hz) that is used for triggering the DAQ. In this test setup no external signals are fed to the digitizers. > > > > > > Best greetings > > G?nter > > > > _______________________________________________________________________________________________________________________________________________________________________________________________________________________________ > Von: subexp-daq im Auftrag von Hans Toshihide T?rnqvist > Gesendet: Montag, 22. Januar 2024 15:57:24 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated > Dear G?nter, > > It seems also the r3bfuser configuration parser was updated. I took the > file you sent us on the 18th and updated it, with some explanations to > the changes. > > The SIS3316 modules do not need the barrier between. Note that with the > changed main.cfg, the data will be different and the unpacker may have > some problems, but let's get the DAQ running first :) > > Best regards, > Hans > > On 2024-01-22 15:29, Weber, Guenter Dr. wrote: > > Dear Hans, > > > > > > yes, the VETAR does not have an upstream connection. My impression was > > that in this case, the internal clock simply starts incrementing more or > > less in the same way the VULOM does. I have now commented out the VETAR. > > This is the result: > > > > > > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: > > 56583). > > Thread has no error buffer yet... > > CPUS: 1 > > delay: 1 > > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: > > 56583). > > Thread has no error buffer yet... > > HOST: RIO4-MCAL-1 > > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] > > 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 > > (eth1). > > 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = > > 0x19000000, 1 consumers. > > 10: lwroc_triva_readout.c:66: Silence TRIVA (HALT) > > 10: lwroc_net_io.c:167: Started server on port 56583 (data port 51756). > > client union size: 244 208 188 508 640 204 204 => 640 > > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: > > /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 > > 10: lwroc_main.c:706: Log message rate limit not in effect. > > 10: lwroc_readout.c:112: call readout_init... > > 10: lwroc_thread_util.c:117: This is the triva control thread! > > 10: lwroc_thread_util.c:117: This is the net io thread! > > 10: lwroc_thread_util.c:117: This is the slow_async thread! > > 10: lwroc_thread_util.c:117: This is the data server thread! > > 10: lwroc_message_internal.c:472: Message client connected! > > 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) > > [192.168.1.1]. > > 10: lwroc_triva_control.c:370: Setup TRIVA (DISBUS, HALT, MASTER, RESET) > > 10: lwroc_triva_control.c:418: Minimum event time > > ctime(5000)+1*rd(691)+3*wr(633)+fctime(1000)=8590 ns (116.414 kHz) > > 10: lwroc_triva_state.c:1486: (Re)send ident messages... > > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 > > 9: lwroc_triva_control.c:507: TEST: GO > > 10: lwroc_triva_control.c:725: RUN: RESET > > 10: lwroc_triva_control.c:729: RUN: MT=14 > > 9: lwroc_triva_control.c:737: GO (1 good test triggers done) (max > > 116.4 kHz) > > 10: lwroc_triva_readout.c:376: Trigger 14 seen. > > 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. > > 10: config/parser.c:287: Opened > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { > > 10: config/parser.c:299: Closed > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 > > (IN_READOUT). EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 10: config/parser.c:287: Opened './main.cfg' { > > 10: config/config.c:1299: .Global log level=verbose. > > 10: config/parser.c:287: .Opened > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { > > 10: config/parser.c:299: .Closed > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } > > 10: config/parser.c:287: .Opened > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { > > 10: config/parser.c:299: .Closed > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } > > 10: config/parser.c:287: .Opened > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > > 10: config/parser.c:299: .Closed > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > > 10: config/parser.c:287: .Opened > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > > 10: config/parser.c:299: .Closed > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > > 10: config/parser.c:287: .Opened > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > > 10: config/parser.c:299: .Closed > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > > 10: config/parser.c:287: .Opened > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > > 10: config/parser.c:299: .Closed > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > > 10: config/parser.c:287: .Opened > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > > 10: config/parser.c:299: .Closed > > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > > 10: config/parser.c:299: Closed './main.cfg' } > > 10: crate/crate.c:347: crate_create { > > 10: crate/crate.c:673: crate_create(MCAL) } > > 10: crate/crate.c:899: crate_init(MCAL) { > > 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. > > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) > > 10: crate/crate.c:923: .Slow-init module[1]=SIS_3316. > > 10: module/map/map.c:224: ...rd(0x30000000+0x64/32)=535ns > > wr(0x30000000+0x64/32)=356ns. > > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x00800178. > > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x3316200e. > > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x0125000c. > > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x0125000c. > > 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x0125000c. > > 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x0125000c. > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, > > and in deadtime. > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 > > (IN_READOUT). EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, > > and in deadtime. > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 > > (IN_READOUT). EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 10: crate/crate.c:923: .Slow-init module[2]=SIS_3316. > > 10: module/map/map.c:224: ...rd(0x31000000+0x64/32)=540ns > > wr(0x31000000+0x64/32)=360ns. > > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. > > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. > > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. > > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. > > 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x01250011. > > 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x01250011. > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, > > and in deadtime. > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 > > (IN_READOUT). EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 10: crate/crate.c:976: .Fast-init module[0]=GSI_VULOM. > > 10: crate/crate.c:976: .Fast-init module[1]=SIS_3316. > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[0] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[1] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[2] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[3] = 15 mV -> 0x080001f3 > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[4] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[5] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[6] = 10 mV -> 0x0800014c > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[7] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[8] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[9] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[10] = 13 mV -> 0x080001b0 > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[11] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[12] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[13] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[14] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[15] = 15 mV -> 0x080001f3 > > 10: crate/crate.c:976: .Fast-init module[2]=SIS_3316. > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[0] = 10 mV -> 0x0800014c > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[1] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[2] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[3] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[4] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[5] = 10 mV -> 0x0800014c > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[6] = 13 mV -> 0x080001b0 > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[7] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[8] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[9] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[10] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[11] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[12] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[13] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[14] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4177: ...threshold[15] = 8 mV -> 0x0800010a > > 10: crate/crate.c:1008: .Post-init module[1]=SIS_3316. > > 10: crate/crate.c:1008: .Post-init module[2]=SIS_3316. > > 10: crate/crate.c:1073: crate_init(MCAL) } > > 10: ctrl/ctrl.c:788: Control server online. > > Thread has no error buffer yet... > > 5: f_user.c:484: r3bfuser.cfg:1: Weird config! > > 5: f_user.c:484: Calling abort()... > > > > > > Looks like the DAQ is able to set the thresholds for the first two > > SIS3316 modules. And then crashes. But there are only these two modules, > > so the main.cfg is done. I just noticed that I did not put a BARRIER > > between the initialization of the two SIS3316 modules. Is this relevant? > > But if it was, the problem would probably occur after the first module > > and not when the main.cfg was completely processed. > > > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > > ------------------------------------------------------------------------ > > *Von:* subexp-daq im Auftrag von > > Hans Toshihide T?rnqvist > > *Gesendet:* Montag, 22. Januar 2024 15:18:20 > > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > > TRLOII, DRASI, etc. were updated > > Dear G?nter, > > > > Do you have a schematic of the setup? I.e. what modules have what > > connections, in the crate and to detectors. > > > > Some photos would also be nice. > > > > This would help our understanding of the setup. > > > > Best regards, > > Hans & H?kan > > -- > > 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: From hans.tornqvist at chalmers.se Tue Jan 23 11:25:45 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Tue, 23 Jan 2024 11:25:45 +0100 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <929564d321f54545b6abb2a24c9c6162@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <1aa0afb1bf1e4f91b5d2ab58eb0c62bb@hi-jena.gsi.de> <810ed751-3a8a-43d7-b9b1-7d7c08f8fdf4@chalmers.se> <0dc854ec60194f299b776bc263eb2c72@hi-jena.gsi.de> <5f7958c3-297f-9303-efad-851c23f87ff0@chalmers.se> <897201d9f3424d318c7ed49ce4106aaa@hi-jena.gsi.de> <7f6060e5-ccad-48ba-927e-cb749bea290a@chalmers.se> <2d0ecc20c1ee4921b5ed807b41251fe5@hi-jena.gsi.de> <8fb50894-080f-4bf8-8ed3-f7a965de1b55@chalmers.se> <266475039f5d41fc9c8247714820854a@hi-jena.gsi.de> <2a94c163-aeb5-4336-bfe0-44d89172ec99@chalmers.se> <3aad99c7-e61b-47eb-8dcd-f7f872c56d33@chalmers.se> <9b98f1d3-dfbb-4a99-bb6c-7d658048ad83@chalmers.se> <09e3707e3d5844e8a6ded8b78b70358d@hi-jena.gsi.de> <36e8dae7-13cb-9258-99f3-4c5f2004c2a7@chalmers.se> <929564d321f54545b6abb2a24c9c6162@hi-jena.gsi.de> Message-ID: Dear G?nter, I will have to look into the merge I did of the 'mcal_daq' and 'master' changes for the sis3316. It is a very complex module with by far the most complex code that I do not know very well, so it is very likely that I made a mistake. You should have a ucesb/ directory, and inside there is hopefully an already built binary ucesb/empty/empty. If not: cd ucesb make empty -j8 You can then use it like this: cd ucesb/empty ./empty --stream=my-daq-node --print --data --max-events=10 You can also save a raw data file: ./empty --stream=my-daq-node --output=my-test-file.lmd --max-events=10 and look at that: ./empty my-test-file.lmd --print --data Best regards, Hans On 2024-01-23 11:05, Weber, Guenter Dr. wrote: > Dear H?kan, > > > as far as I know we never touched the SIS3316 firmware. But, as you know > by now, I know every little about the details of our DAQ, unfortunately. > > > Just for checking, I now removed the SIS3316 entries from main.cfg. > Thus, after also eliminating the VETAR, we just have the VULOM. And now > I don't get any errors: > > > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: > 56583). > Thread has no error buffer yet... > CPUS: 1 > delay: 1 > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: > 56583). > Thread has no error buffer yet... > HOST: RIO4-MCAL-1 > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] > 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 > (eth1). > 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = > 0x19000000, 1 consumers. > 10: lwroc_triva_readout.c:66: Silence TRIVA? (HALT) > 10: lwroc_net_io.c:167: Started server on port 56583 (data port 39340). > client union size: 244 208 188 508 640 204 204? => 640 > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: > /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 > 10: lwroc_main.c:706: Log message rate limit not in effect. > 10: lwroc_readout.c:112: call readout_init... > 10: lwroc_thread_util.c:117: This is the triva control thread! > 10: lwroc_thread_util.c:117: This is the net io thread! > 10: lwroc_thread_util.c:117: This is the slow_async thread! > 10: lwroc_thread_util.c:117: This is the data server thread! > 10: lwroc_message_internal.c:472: Message client connected! > 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) > [192.168.1.1]. > 10: lwroc_triva_control.c:370: Setup TRIVA? (DISBUS, HALT, MASTER, RESET) > 10: lwroc_triva_control.c:418: Minimum event time > ctime(5000)+1*rd(689)+3*wr(634)+fctime(1000)=8591 ns (116.401 kHz) > 10: lwroc_triva_state.c:1486: (Re)send ident messages... > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 > 9: lwroc_triva_control.c:507: TEST: GO > 10: lwroc_triva_control.c:725: RUN: RESET > 10: lwroc_triva_control.c:729: RUN: MT=14 > 9: lwroc_triva_control.c:737:?? GO (1 good test triggers done) (max > 116.4 kHz) > 10: lwroc_triva_readout.c:376: Trigger 14 seen. > 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. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 > (IN_READOUT).? EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: config/parser.c:287: Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { > 10: config/parser.c:299: Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } > 10: config/parser.c:287: Opened './main.cfg' { > 10: config/config.c:1299: .Global log level=verbose. > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:299: Closed './main.cfg' } > 10: crate/crate.c:347: crate_create { > 10: crate/crate.c:673: crate_create(MCAL) } > 10: crate/crate.c:899: crate_init(MCAL) { > 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) > 10: crate/crate.c:976: .Fast-init module[0]=GSI_VULOM. > 10: crate/crate.c:1073: crate_init(MCAL) } > 10: ctrl/ctrl.c:788: Control server online. > Thread has no error buffer yet... > 10: f_user.c:559: WR ID=0x200. > 10: f_user.c:565: TS offset unset. Will not modify stamp. > 10: f_user.c:572: TPAT: No. > 10: f_user.c:573: Sync-check: No. > 10: f_user.c:575: Spill triggers: No. > 10: f_user.c:576: LMU: No. > 10: f_user.c:577: Timer latches: No. > 10: f_user.c:578: Spill shape: No. > 10: f_user.c:579: Micro-structure: No. > 10: f_user.c:581: Multi-event flag: No. > 10: f_user.c:586: UDP destination: None. > > The DAQ is running with 10 Hz, as expected. Is there an easy way to look > at the output of the DAQ? This should now contain only of the time stamp > and the 16 scaler channels from the VULOM. If we can verify that this > minimum example is now running as expected, we can go back to debugging > the SIS3316 part, ok? > > > > > Best greetings > > G?nter > > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > H?kan T Johansson > *Gesendet:* Montag, 22. Januar 2024 23:01:43 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > TRLOII, DRASI, etc. were updated > > Dear G?nter, > > The error would be the line > >> 5: module/sis_3316/sis_3316.c:3096: [2]: timeout while polling for previous bank addr (bank 0 != 0) on ch 0 > > (the printout from lwroc_triva_state.c is basically debug help, just > trying to help identifying which system is stuck, in case one has multiple > crates (not the case here).) > > Question: when the modules are re-inited (which always happens after > readout failure), it looks like the two SIS3316 modules have different > firmwares? > > Is that intentional? > > How do those values compare to the other DAQ system? > > Best regards, > H?kan > > > > On Mon, 22 Jan 2024, Weber, Guenter Dr. wrote: > >> >> Dear Hans, >> >> >> thank you for the explanations for r3bfuser.cfg. In the end only a single cryptic line remains in this file, right? >> >> >> With the new R3B config and modified VULOM entry in main.cfg I get the following result: >> >> >> ... everything looks nice and the SIS3316 threshold are set ... >> >> 10: crate/crate.c:1008: .Post-init module[1]=SIS_3316. >> 10: crate/crate.c:1008: .Post-init module[2]=SIS_3316. >> 10: crate/crate.c:1073: crate_init(MCAL) } >> 5: f_user.c:1257: had readout error, ret=0x4, trigger=1, prev=1 >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 5: module/sis_3316/sis_3316.c:3096: [2]: timeout while polling for previous bank addr (bank 0 != 0) on ch 0 >> 5: module/sis_3316/sis_3316.c:2512: sis3316 bank of channel not ready for readout. >> 5: module/sis_3316/sis_3316.c:2329: sis3316 ch[0] test_channel failed >> 5: crate/crate.c:1954: MCAL[2]=SIS_3316 readout error=0x00000004, dumping data: >> 10: crate/crate.c:1970: ---[ Dump begin ]--- >> 10: crate/crate.c:1970: Start=0x3005e230? Bytes=0=0x0 >> 10: crate/crate.c:1970: ---[? Dump end? ]--- >> 5: crate/crate.c:1449: MCAL: readout failed! >> 5: crate/crate.c:1493: MCAL: had problems, re-initializing. >> 10: crate/crate.c:683: crate_deinit(MCAL) { >> 10: crate/crate.c:707: crate_deinit(MCAL) } >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 10: crate/crate.c:899: crate_init(MCAL) { >> 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. >> LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) >> 10: crate/crate.c:923: .Slow-init module[1]=SIS_3316. >> 10: module/map/map.c:224: ...rd(0x30000000+0x64/32)=535ns wr(0x30000000+0x64/32)=356ns. >> 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x00800178. >> 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x3316200e. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x0125000c. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x0125000c. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x0125000c. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x0125000c. >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 10: crate/crate.c:923: .Slow-init module[2]=SIS_3316. >> 10: module/map/map.c:224: ...rd(0x31000000+0x64/32)=540ns wr(0x31000000+0x64/32)=360ns. >> 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. >> 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. >> 10: crate/crate.c:923: .Slow-init module[2]=SIS_3316. >> 10: module/map/map.c:224: ...rd(0x31000000+0x64/32)=540ns wr(0x31000000+0x64/32)=360ns. >> 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. >> 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x01250011. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x01250011. >> ^C8: lwroc_main.c:106: SIGINT received. >> >> I stopped the DAQ software manually. To me it looked like, the software tried every 10 seconds to restart the DAQ. >> >> >> The DAQ setup consists of 1 RIO, 1 TRIVA, 1 VULOM B, 2 SIS3316, 1 VETAR2. >> >> The VULOM provides two output signals. A fast one to synchronize the SIS3316 modules and a slow one (10 Hz) that is used for triggering the DAQ. In this test setup no external signals are fed to the digitizers. >> >> >> >> >> >> Best greetings >> >> G?nter >> >> >> >> _______________________________________________________________________________________________________________________________________________________________________________________________________________________________ >> Von: subexp-daq im Auftrag von Hans Toshihide T?rnqvist >> Gesendet: Montag, 22. Januar 2024 15:57:24 >> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated >> Dear G?nter, >> >> It seems also the r3bfuser configuration parser was updated. I took the >> file you sent us on the 18th and updated it, with some explanations to >> the changes. >> >> The SIS3316 modules do not need the barrier between. Note that with the >> changed main.cfg, the data will be different and the unpacker may have >> some problems, but let's get the DAQ running first :) >> >> Best regards, >> Hans >> >> On 2024-01-22 15:29, Weber, Guenter Dr. wrote: >> > Dear Hans, >> > >> > >> > yes, the VETAR does not have an upstream connection. My impression was >> > that in this case, the internal clock simply starts incrementing more or >> > less in the same way the VULOM does. I have now commented out the VETAR. >> > This is the result: >> > >> > >> > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: >> > 56583). >> > Thread has no error buffer yet... >> > CPUS: 1 >> > delay: 1 >> > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: >> > 56583). >> > Thread has no error buffer yet... >> > HOST: RIO4-MCAL-1 >> > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] >> > 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 >> > (eth1). >> > 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = >> > 0x19000000, 1 consumers. >> > 10: lwroc_triva_readout.c:66: Silence TRIVA? (HALT) >> > 10: lwroc_net_io.c:167: Started server on port 56583 (data port 51756). >> > client union size: 244 208 188 508 640 204 204? => 640 >> > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: >> > /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 >> > 10: lwroc_main.c:706: Log message rate limit not in effect. >> > 10: lwroc_readout.c:112: call readout_init... >> > 10: lwroc_thread_util.c:117: This is the triva control thread! >> > 10: lwroc_thread_util.c:117: This is the net io thread! >> > 10: lwroc_thread_util.c:117: This is the slow_async thread! >> > 10: lwroc_thread_util.c:117: This is the data server thread! >> > 10: lwroc_message_internal.c:472: Message client connected! >> > 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) >> > [192.168.1.1]. >> > 10: lwroc_triva_control.c:370: Setup TRIVA? (DISBUS, HALT, MASTER, RESET) >> > 10: lwroc_triva_control.c:418: Minimum event time >> > ctime(5000)+1*rd(691)+3*wr(633)+fctime(1000)=8590 ns (116.414 kHz) >> > 10: lwroc_triva_state.c:1486: (Re)send ident messages... >> > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 >> > 9: lwroc_triva_control.c:507: TEST: GO >> > 10: lwroc_triva_control.c:725: RUN: RESET >> > 10: lwroc_triva_control.c:729: RUN: MT=14 >> > 9: lwroc_triva_control.c:737:?? GO (1 good test triggers done) (max >> > 116.4 kHz) >> > 10: lwroc_triva_readout.c:376: Trigger 14 seen. >> > 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. >> > 10: config/parser.c:287: Opened >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { >> > 10: config/parser.c:299: Closed >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } >> > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 >> > (IN_READOUT).? EC: 1 >> > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> > 10: config/parser.c:287: Opened './main.cfg' { >> > 10: config/config.c:1299: .Global log level=verbose. >> > 10: config/parser.c:287: .Opened >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { >> > 10: config/parser.c:299: .Closed >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } >> > 10: config/parser.c:287: .Opened >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { >> > 10: config/parser.c:299: .Closed >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } >> > 10: config/parser.c:287: .Opened >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { >> > 10: config/parser.c:299: .Closed >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } >> > 10: config/parser.c:287: .Opened >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { >> > 10: config/parser.c:299: .Closed >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } >> > 10: config/parser.c:287: .Opened >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { >> > 10: config/parser.c:299: .Closed >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } >> > 10: config/parser.c:287: .Opened >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { >> > 10: config/parser.c:299: .Closed >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } >> > 10: config/parser.c:287: .Opened >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { >> > 10: config/parser.c:299: .Closed >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } >> > 10: config/parser.c:299: Closed './main.cfg' } >> > 10: crate/crate.c:347: crate_create { >> > 10: crate/crate.c:673: crate_create(MCAL) } >> > 10: crate/crate.c:899: crate_init(MCAL) { >> > 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. >> > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) >> > 10: crate/crate.c:923: .Slow-init module[1]=SIS_3316. >> > 10: module/map/map.c:224: ...rd(0x30000000+0x64/32)=535ns >> > wr(0x30000000+0x64/32)=356ns. >> > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x00800178. >> > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x3316200e. >> > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x0125000c. >> > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x0125000c. >> > 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x0125000c. >> > 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x0125000c. >> > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, >> > and in deadtime. >> > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 >> > (IN_READOUT).? EC: 1 >> > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, >> > and in deadtime. >> > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 >> > (IN_READOUT).? EC: 1 >> > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> > 10: crate/crate.c:923: .Slow-init module[2]=SIS_3316. >> > 10: module/map/map.c:224: ...rd(0x31000000+0x64/32)=540ns >> > wr(0x31000000+0x64/32)=360ns. >> > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. >> > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. >> > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. >> > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. >> > 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x01250011. >> > 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x01250011. >> > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, >> > and in deadtime. >> > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 >> > (IN_READOUT).? EC: 1 >> > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> > 10: crate/crate.c:976: .Fast-init module[0]=GSI_VULOM. >> > 10: crate/crate.c:976: .Fast-init module[1]=SIS_3316. >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[0] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[1] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[2] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[3] = 15 mV -> 0x080001f3 >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[4] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[5] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[6] = 10 mV -> 0x0800014c >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[7] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[8] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[9] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[10] = 13 mV -> 0x080001b0 >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[11] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[12] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[13] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[14] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[15] = 15 mV -> 0x080001f3 >> > 10: crate/crate.c:976: .Fast-init module[2]=SIS_3316. >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[0] = 10 mV -> 0x0800014c >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[1] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[2] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[3] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[4] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[5] = 10 mV -> 0x0800014c >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[6] = 13 mV -> 0x080001b0 >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[7] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[8] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[9] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[10] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[11] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[12] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[13] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[14] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[15] = 8 mV -> 0x0800010a >> > 10: crate/crate.c:1008: .Post-init module[1]=SIS_3316. >> > 10: crate/crate.c:1008: .Post-init module[2]=SIS_3316. >> > 10: crate/crate.c:1073: crate_init(MCAL) } >> > 10: ctrl/ctrl.c:788: Control server online. >> > Thread has no error buffer yet... >> > 5: f_user.c:484: r3bfuser.cfg:1: Weird config! >> > 5: f_user.c:484: Calling abort()... >> > >> > >> > Looks like the DAQ is able to set the thresholds for the first two >> > SIS3316 modules. And then crashes. But there are only these two modules, >> > so the main.cfg is done. I just noticed that I did not put a BARRIER >> > between the initialization of the two SIS3316 modules. Is this relevant? >> > But if it was, the problem would probably occur after the first module >> > and not when the main.cfg was completely processed. >> > >> > >> > >> > >> > >> > Best greetings >> > >> > G?nter >> > >> > >> > >> > ------------------------------------------------------------------------ >> > *Von:* subexp-daq im Auftrag von >> > Hans Toshihide T?rnqvist >> > *Gesendet:* Montag, 22. Januar 2024 15:18:20 >> > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >> > TRLOII, DRASI, etc. were updated >> > Dear G?nter, >> > >> > Do you have a schematic of the setup? I.e. what modules have what >> > connections, in the crate and to detectors. >> > >> > Some photos would also be nice. >> > >> > This would help our understanding of the setup. >> > >> > Best regards, >> > Hans & H?kan >> > -- >> > subexp-daq mailing list >> > subexp-daq at lists.chalmers.se >> > https://lists.chalmers.se/mailman/listinfo/subexp-daq > >> > > >> > >> >> > From g.weber at hi-jena.gsi.de Tue Jan 23 11:53:13 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 23 Jan 2024 10:53:13 +0000 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <1aa0afb1bf1e4f91b5d2ab58eb0c62bb@hi-jena.gsi.de> <810ed751-3a8a-43d7-b9b1-7d7c08f8fdf4@chalmers.se> <0dc854ec60194f299b776bc263eb2c72@hi-jena.gsi.de> <5f7958c3-297f-9303-efad-851c23f87ff0@chalmers.se> <897201d9f3424d318c7ed49ce4106aaa@hi-jena.gsi.de> <7f6060e5-ccad-48ba-927e-cb749bea290a@chalmers.se> <2d0ecc20c1ee4921b5ed807b41251fe5@hi-jena.gsi.de> <8fb50894-080f-4bf8-8ed3-f7a965de1b55@chalmers.se> <266475039f5d41fc9c8247714820854a@hi-jena.gsi.de> <2a94c163-aeb5-4336-bfe0-44d89172ec99@chalmers.se> <3aad99c7-e61b-47eb-8dcd-f7f872c56d33@chalmers.se> <9b98f1d3-dfbb-4a99-bb6c-7d658048ad83@chalmers.se> <09e3707e3d5844e8a6ded8b78b70358d@hi-jena.gsi.de> <36e8dae7-13cb-9258-99f3-4c5f2004c2a7@chalmers.se> <929564d321f54545b6abb2a24c9c6162@hi-jena.gsi.de>, Message-ID: <111a7ad2c61a4e05bc826ee5cabd98d7@hi-jena.gsi.de> Dear Hans, I do not know how to interpret "my-daq-node". But I found a similar command that Bastian once showed me. Is my-daq-note = localhost:8001? mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/ucesb/empty$ ./empty stream://localhost:8001 --print --data --max-events=10 Reading mapping/calibration file './gen_empty/data_mapping.hh'... Optional map/calib file './calibration.hh' does not exist, is ok. Server 'localhost' known... (IP : 127.0.0.1) (port: 8001). Connecting TCP port: 8001 Redirected -> port 7001 Connecting TCP port: 7001 Server data: 81920 kiB chunks; prefetch buffer: 256 MiB. Event 23349 Type/Subtype 10 1 Size 140 Trigger 1 SubEv ProcID 1 Type/Subtype 10 1 Size 24 Ctrl 9 Subcrate 1 00000200 03e12cf3 04e1ddf1 05e12f3d 06e10001 f1a2000a SubEv ProcID 1 Type/Subtype 20 2 Size 84 Ctrl 9 Subcrate 1 80000000 65d8a6da 00012f3d ddf12cf3 00000010 0032e01c 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 Event 23350 Type/Subtype 10 1 Size 140 Trigger 1 SubEv ProcID 1 Type/Subtype 10 1 Size 24 Ctrl 9 Subcrate 1 00000200 03e10df3 04e1e3e7 05e12f3d 06e10001 f1a2000a SubEv ProcID 1 Type/Subtype 20 2 Size 84 Ctrl 9 Subcrate 1 80000000 65d8a6da 00012f3d e3e70df3 00000010 0032e01d 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 Event 23351 Type/Subtype 10 1 Size 140 Trigger 1 SubEv ProcID 1 Type/Subtype 10 1 Size 24 Ctrl 9 Subcrate 1 00000200 03e1eef8 04e1e9dc 05e12f3d 06e10001 f1a2000a SubEv ProcID 1 Type/Subtype 20 2 Size 84 Ctrl 9 Subcrate 1 80000000 65d8a6db 00012f3d e9dceef8 00000010 0032e01e 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 Event 23352 Type/Subtype 10 1 Size 140 Trigger 1 SubEv ProcID 1 Type/Subtype 10 1 Size 24 Ctrl 9 Subcrate 1 00000200 03e1cff9 04e1efd2 05e12f3d 06e10001 f1a2000a SubEv ProcID 1 Type/Subtype 20 2 Size 84 Ctrl 9 Subcrate 1 80000000 65d8a6db 00012f3d efd2cff9 00000010 0032e01f 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 Event 23353 Type/Subtype 10 1 Size 140 Trigger 1 SubEv ProcID 1 Type/Subtype 10 1 Size 24 Ctrl 9 Subcrate 1 00000200 03e1b0f4 04e1f5c8 05e12f3d 06e10001 f1a2000a SubEv ProcID 1 Type/Subtype 20 2 Size 84 Ctrl 9 Subcrate 1 80000000 65d8a6db 00012f3d f5c8b0f4 00000010 0032e020 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 Event 23354 Type/Subtype 10 1 Size 140 Trigger 1 SubEv ProcID 1 Type/Subtype 10 1 Size 24 Ctrl 9 Subcrate 1 00000200 03e191f4 04e1fbbe 05e12f3d 06e10001 f1a2000a SubEv ProcID 1 Type/Subtype 20 2 Size 84 Ctrl 9 Subcrate 1 80000000 65d8a6db 00012f3d fbbe91f4 00000010 0032e021 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 Event 23355 Type/Subtype 10 1 Size 140 Trigger 1 SubEv ProcID 1 Type/Subtype 10 1 Size 24 Ctrl 9 Subcrate 1 00000200 03e172f9 04e101b4 05e12f3e 06e10001 f1a2000a SubEv ProcID 1 Type/Subtype 20 2 Size 84 Ctrl 9 Subcrate 1 80000000 65d8a6db 00012f3e 01b472f9 00000010 0032e022 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 Event 23356 Type/Subtype 10 1 Size 140 Trigger 1 SubEv ProcID 1 Type/Subtype 10 1 Size 24 Ctrl 9 Subcrate 1 00000200 03e153f0 04e107aa 05e12f3e 06e10001 f1a2000a SubEv ProcID 1 Type/Subtype 20 2 Size 84 Ctrl 9 Subcrate 1 80000000 65d8a6db 00012f3e 07aa53f0 00000010 0032e023 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 Event 23357 Type/Subtype 10 1 Size 140 Trigger 1 SubEv ProcID 1 Type/Subtype 10 1 Size 24 Ctrl 9 Subcrate 1 00000200 03e134f9 04e10da0 05e12f3e 06e10001 f1a2000a SubEv ProcID 1 Type/Subtype 20 2 Size 84 Ctrl 9 Subcrate 1 80000000 65d8a6db 00012f3e 0da034f9 00000010 0032e024 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 Event 23358 Type/Subtype 10 1 Size 140 Trigger 1 SubEv ProcID 1 Type/Subtype 10 1 Size 24 Ctrl 9 Subcrate 1 00000200 03e115f4 04e11396 05e12f3e 06e10001 f1a2000a SubEv ProcID 1 Type/Subtype 20 2 Size 84 Ctrl 9 Subcrate 1 80000000 65d8a6db 00012f3e 139615f4 00000010 0032e025 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 The last 16 entries of the LMD events are most probably the VULOM scalers, with the first channel incrementing by one for each trigger. Unclear to me is why the last 8 channels show a 1 instead of 0. The 3rd and 4th entries belong to the 64-bit VULOM timestamp, probably. Could you explain what the first two entries are? And the 5th? Many thanks and best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von Hans Toshihide T?rnqvist Gesendet: Dienstag, 23. Januar 2024 11:25:45 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated Dear G?nter, I will have to look into the merge I did of the 'mcal_daq' and 'master' changes for the sis3316. It is a very complex module with by far the most complex code that I do not know very well, so it is very likely that I made a mistake. You should have a ucesb/ directory, and inside there is hopefully an already built binary ucesb/empty/empty. If not: cd ucesb make empty -j8 You can then use it like this: cd ucesb/empty ./empty --stream=my-daq-node --print --data --max-events=10 You can also save a raw data file: ./empty --stream=my-daq-node --output=my-test-file.lmd --max-events=10 and look at that: ./empty my-test-file.lmd --print --data Best regards, Hans On 2024-01-23 11:05, Weber, Guenter Dr. wrote: > Dear H?kan, > > > as far as I know we never touched the SIS3316 firmware. But, as you know > by now, I know every little about the details of our DAQ, unfortunately. > > > Just for checking, I now removed the SIS3316 entries from main.cfg. > Thus, after also eliminating the VETAR, we just have the VULOM. And now > I don't get any errors: > > > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: > 56583). > Thread has no error buffer yet... > CPUS: 1 > delay: 1 > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: > 56583). > Thread has no error buffer yet... > HOST: RIO4-MCAL-1 > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] > 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 > (eth1). > 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = > 0x19000000, 1 consumers. > 10: lwroc_triva_readout.c:66: Silence TRIVA (HALT) > 10: lwroc_net_io.c:167: Started server on port 56583 (data port 39340). > client union size: 244 208 188 508 640 204 204 => 640 > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: > /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 > 10: lwroc_main.c:706: Log message rate limit not in effect. > 10: lwroc_readout.c:112: call readout_init... > 10: lwroc_thread_util.c:117: This is the triva control thread! > 10: lwroc_thread_util.c:117: This is the net io thread! > 10: lwroc_thread_util.c:117: This is the slow_async thread! > 10: lwroc_thread_util.c:117: This is the data server thread! > 10: lwroc_message_internal.c:472: Message client connected! > 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) > [192.168.1.1]. > 10: lwroc_triva_control.c:370: Setup TRIVA (DISBUS, HALT, MASTER, RESET) > 10: lwroc_triva_control.c:418: Minimum event time > ctime(5000)+1*rd(689)+3*wr(634)+fctime(1000)=8591 ns (116.401 kHz) > 10: lwroc_triva_state.c:1486: (Re)send ident messages... > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 > 9: lwroc_triva_control.c:507: TEST: GO > 10: lwroc_triva_control.c:725: RUN: RESET > 10: lwroc_triva_control.c:729: RUN: MT=14 > 9: lwroc_triva_control.c:737: GO (1 good test triggers done) (max > 116.4 kHz) > 10: lwroc_triva_readout.c:376: Trigger 14 seen. > 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. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 > (IN_READOUT). EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: config/parser.c:287: Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { > 10: config/parser.c:299: Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } > 10: config/parser.c:287: Opened './main.cfg' { > 10: config/config.c:1299: .Global log level=verbose. > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } > 10: config/parser.c:287: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:299: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:299: Closed './main.cfg' } > 10: crate/crate.c:347: crate_create { > 10: crate/crate.c:673: crate_create(MCAL) } > 10: crate/crate.c:899: crate_init(MCAL) { > 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) > 10: crate/crate.c:976: .Fast-init module[0]=GSI_VULOM. > 10: crate/crate.c:1073: crate_init(MCAL) } > 10: ctrl/ctrl.c:788: Control server online. > Thread has no error buffer yet... > 10: f_user.c:559: WR ID=0x200. > 10: f_user.c:565: TS offset unset. Will not modify stamp. > 10: f_user.c:572: TPAT: No. > 10: f_user.c:573: Sync-check: No. > 10: f_user.c:575: Spill triggers: No. > 10: f_user.c:576: LMU: No. > 10: f_user.c:577: Timer latches: No. > 10: f_user.c:578: Spill shape: No. > 10: f_user.c:579: Micro-structure: No. > 10: f_user.c:581: Multi-event flag: No. > 10: f_user.c:586: UDP destination: None. > > The DAQ is running with 10 Hz, as expected. Is there an easy way to look > at the output of the DAQ? This should now contain only of the time stamp > and the 16 scaler channels from the VULOM. If we can verify that this > minimum example is now running as expected, we can go back to debugging > the SIS3316 part, ok? > > > > > Best greetings > > G?nter > > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > H?kan T Johansson > *Gesendet:* Montag, 22. Januar 2024 23:01:43 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > TRLOII, DRASI, etc. were updated > > Dear G?nter, > > The error would be the line > >> 5: module/sis_3316/sis_3316.c:3096: [2]: timeout while polling for previous bank addr (bank 0 != 0) on ch 0 > > (the printout from lwroc_triva_state.c is basically debug help, just > trying to help identifying which system is stuck, in case one has multiple > crates (not the case here).) > > Question: when the modules are re-inited (which always happens after > readout failure), it looks like the two SIS3316 modules have different > firmwares? > > Is that intentional? > > How do those values compare to the other DAQ system? > > Best regards, > H?kan > > > > On Mon, 22 Jan 2024, Weber, Guenter Dr. wrote: > >> >> Dear Hans, >> >> >> thank you for the explanations for r3bfuser.cfg. In the end only a single cryptic line remains in this file, right? >> >> >> With the new R3B config and modified VULOM entry in main.cfg I get the following result: >> >> >> ... everything looks nice and the SIS3316 threshold are set ... >> >> 10: crate/crate.c:1008: .Post-init module[1]=SIS_3316. >> 10: crate/crate.c:1008: .Post-init module[2]=SIS_3316. >> 10: crate/crate.c:1073: crate_init(MCAL) } >> 5: f_user.c:1257: had readout error, ret=0x4, trigger=1, prev=1 >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 5: module/sis_3316/sis_3316.c:3096: [2]: timeout while polling for previous bank addr (bank 0 != 0) on ch 0 >> 5: module/sis_3316/sis_3316.c:2512: sis3316 bank of channel not ready for readout. >> 5: module/sis_3316/sis_3316.c:2329: sis3316 ch[0] test_channel failed >> 5: crate/crate.c:1954: MCAL[2]=SIS_3316 readout error=0x00000004, dumping data: >> 10: crate/crate.c:1970: ---[ Dump begin ]--- >> 10: crate/crate.c:1970: Start=0x3005e230 Bytes=0=0x0 >> 10: crate/crate.c:1970: ---[ Dump end ]--- >> 5: crate/crate.c:1449: MCAL: readout failed! >> 5: crate/crate.c:1493: MCAL: had problems, re-initializing. >> 10: crate/crate.c:683: crate_deinit(MCAL) { >> 10: crate/crate.c:707: crate_deinit(MCAL) } >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 10: crate/crate.c:899: crate_init(MCAL) { >> 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. >> LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) >> 10: crate/crate.c:923: .Slow-init module[1]=SIS_3316. >> 10: module/map/map.c:224: ...rd(0x30000000+0x64/32)=535ns wr(0x30000000+0x64/32)=356ns. >> 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x00800178. >> 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x3316200e. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x0125000c. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x0125000c. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x0125000c. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x0125000c. >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 10: crate/crate.c:923: .Slow-init module[2]=SIS_3316. >> 10: module/map/map.c:224: ...rd(0x31000000+0x64/32)=540ns wr(0x31000000+0x64/32)=360ns. >> 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. >> 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. >> 10: crate/crate.c:923: .Slow-init module[2]=SIS_3316. >> 10: module/map/map.c:224: ...rd(0x31000000+0x64/32)=540ns wr(0x31000000+0x64/32)=360ns. >> 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. >> 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x01250011. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x01250011. >> ^C8: lwroc_main.c:106: SIGINT received. >> >> I stopped the DAQ software manually. To me it looked like, the software tried every 10 seconds to restart the DAQ. >> >> >> The DAQ setup consists of 1 RIO, 1 TRIVA, 1 VULOM B, 2 SIS3316, 1 VETAR2. >> >> The VULOM provides two output signals. A fast one to synchronize the SIS3316 modules and a slow one (10 Hz) that is used for triggering the DAQ. In this test setup no external signals are fed to the digitizers. >> >> >> >> >> >> Best greetings >> >> G?nter >> >> >> >> _______________________________________________________________________________________________________________________________________________________________________________________________________________________________ >> Von: subexp-daq im Auftrag von Hans Toshihide T?rnqvist >> Gesendet: Montag, 22. Januar 2024 15:57:24 >> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated >> Dear G?nter, >> >> It seems also the r3bfuser configuration parser was updated. I took the >> file you sent us on the 18th and updated it, with some explanations to >> the changes. >> >> The SIS3316 modules do not need the barrier between. Note that with the >> changed main.cfg, the data will be different and the unpacker may have >> some problems, but let's get the DAQ running first :) >> >> Best regards, >> Hans >> >> On 2024-01-22 15:29, Weber, Guenter Dr. wrote: >> > Dear Hans, >> > >> > >> > yes, the VETAR does not have an upstream connection. My impression was >> > that in this case, the internal clock simply starts incrementing more or >> > less in the same way the VULOM does. I have now commented out the VETAR. >> > This is the result: >> > >> > >> > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: >> > 56583). >> > Thread has no error buffer yet... >> > CPUS: 1 >> > delay: 1 >> > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: >> > 56583). >> > Thread has no error buffer yet... >> > HOST: RIO4-MCAL-1 >> > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] >> > 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 >> > (eth1). >> > 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = >> > 0x19000000, 1 consumers. >> > 10: lwroc_triva_readout.c:66: Silence TRIVA (HALT) >> > 10: lwroc_net_io.c:167: Started server on port 56583 (data port 51756). >> > client union size: 244 208 188 508 640 204 204 => 640 >> > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: >> > /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 >> > 10: lwroc_main.c:706: Log message rate limit not in effect. >> > 10: lwroc_readout.c:112: call readout_init... >> > 10: lwroc_thread_util.c:117: This is the triva control thread! >> > 10: lwroc_thread_util.c:117: This is the net io thread! >> > 10: lwroc_thread_util.c:117: This is the slow_async thread! >> > 10: lwroc_thread_util.c:117: This is the data server thread! >> > 10: lwroc_message_internal.c:472: Message client connected! >> > 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) >> > [192.168.1.1]. >> > 10: lwroc_triva_control.c:370: Setup TRIVA (DISBUS, HALT, MASTER, RESET) >> > 10: lwroc_triva_control.c:418: Minimum event time >> > ctime(5000)+1*rd(691)+3*wr(633)+fctime(1000)=8590 ns (116.414 kHz) >> > 10: lwroc_triva_state.c:1486: (Re)send ident messages... >> > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 >> > 9: lwroc_triva_control.c:507: TEST: GO >> > 10: lwroc_triva_control.c:725: RUN: RESET >> > 10: lwroc_triva_control.c:729: RUN: MT=14 >> > 9: lwroc_triva_control.c:737: GO (1 good test triggers done) (max >> > 116.4 kHz) >> > 10: lwroc_triva_readout.c:376: Trigger 14 seen. >> > 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. >> > 10: config/parser.c:287: Opened >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { >> > 10: config/parser.c:299: Closed >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } >> > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 >> > (IN_READOUT). EC: 1 >> > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> > 10: config/parser.c:287: Opened './main.cfg' { >> > 10: config/config.c:1299: .Global log level=verbose. >> > 10: config/parser.c:287: .Opened >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { >> > 10: config/parser.c:299: .Closed >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } >> > 10: config/parser.c:287: .Opened >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { >> > 10: config/parser.c:299: .Closed >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } >> > 10: config/parser.c:287: .Opened >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { >> > 10: config/parser.c:299: .Closed >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } >> > 10: config/parser.c:287: .Opened >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { >> > 10: config/parser.c:299: .Closed >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } >> > 10: config/parser.c:287: .Opened >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { >> > 10: config/parser.c:299: .Closed >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } >> > 10: config/parser.c:287: .Opened >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { >> > 10: config/parser.c:299: .Closed >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } >> > 10: config/parser.c:287: .Opened >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { >> > 10: config/parser.c:299: .Closed >> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } >> > 10: config/parser.c:299: Closed './main.cfg' } >> > 10: crate/crate.c:347: crate_create { >> > 10: crate/crate.c:673: crate_create(MCAL) } >> > 10: crate/crate.c:899: crate_init(MCAL) { >> > 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. >> > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) >> > 10: crate/crate.c:923: .Slow-init module[1]=SIS_3316. >> > 10: module/map/map.c:224: ...rd(0x30000000+0x64/32)=535ns >> > wr(0x30000000+0x64/32)=356ns. >> > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x00800178. >> > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x3316200e. >> > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x0125000c. >> > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x0125000c. >> > 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x0125000c. >> > 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x0125000c. >> > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, >> > and in deadtime. >> > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 >> > (IN_READOUT). EC: 1 >> > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, >> > and in deadtime. >> > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 >> > (IN_READOUT). EC: 1 >> > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> > 10: crate/crate.c:923: .Slow-init module[2]=SIS_3316. >> > 10: module/map/map.c:224: ...rd(0x31000000+0x64/32)=540ns >> > wr(0x31000000+0x64/32)=360ns. >> > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. >> > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. >> > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. >> > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. >> > 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x01250011. >> > 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x01250011. >> > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, >> > and in deadtime. >> > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 >> > (IN_READOUT). EC: 1 >> > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> > 10: crate/crate.c:976: .Fast-init module[0]=GSI_VULOM. >> > 10: crate/crate.c:976: .Fast-init module[1]=SIS_3316. >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[0] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[1] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[2] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[3] = 15 mV -> 0x080001f3 >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[4] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[5] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[6] = 10 mV -> 0x0800014c >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[7] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[8] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[9] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[10] = 13 mV -> 0x080001b0 >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[11] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[12] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[13] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[14] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[15] = 15 mV -> 0x080001f3 >> > 10: crate/crate.c:976: .Fast-init module[2]=SIS_3316. >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[0] = 10 mV -> 0x0800014c >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[1] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[2] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[3] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[4] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[5] = 10 mV -> 0x0800014c >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[6] = 13 mV -> 0x080001b0 >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[7] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[8] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[9] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[10] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[11] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[12] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[13] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[14] = 8 mV -> 0x0800010a >> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[15] = 8 mV -> 0x0800010a >> > 10: crate/crate.c:1008: .Post-init module[1]=SIS_3316. >> > 10: crate/crate.c:1008: .Post-init module[2]=SIS_3316. >> > 10: crate/crate.c:1073: crate_init(MCAL) } >> > 10: ctrl/ctrl.c:788: Control server online. >> > Thread has no error buffer yet... >> > 5: f_user.c:484: r3bfuser.cfg:1: Weird config! >> > 5: f_user.c:484: Calling abort()... >> > >> > >> > Looks like the DAQ is able to set the thresholds for the first two >> > SIS3316 modules. And then crashes. But there are only these two modules, >> > so the main.cfg is done. I just noticed that I did not put a BARRIER >> > between the initialization of the two SIS3316 modules. Is this relevant? >> > But if it was, the problem would probably occur after the first module >> > and not when the main.cfg was completely processed. >> > >> > >> > >> > >> > >> > Best greetings >> > >> > G?nter >> > >> > >> > >> > ------------------------------------------------------------------------ >> > *Von:* subexp-daq im Auftrag von >> > Hans Toshihide T?rnqvist >> > *Gesendet:* Montag, 22. Januar 2024 15:18:20 >> > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >> > TRLOII, DRASI, etc. were updated >> > Dear G?nter, >> > >> > Do you have a schematic of the setup? I.e. what modules have what >> > connections, in the crate and to detectors. >> > >> > Some photos would also be nice. >> > >> > This would help our understanding of the setup. >> > >> > Best regards, >> > Hans & H?kan >> > -- >> > subexp-daq mailing list >> > subexp-daq at lists.chalmers.se >> > https://lists.chalmers.se/mailman/listinfo/subexp-daq > >> > > >> > >> >> > -- 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: From hans.tornqvist at chalmers.se Tue Jan 23 12:17:18 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Tue, 23 Jan 2024 12:17:18 +0100 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <111a7ad2c61a4e05bc826ee5cabd98d7@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <1aa0afb1bf1e4f91b5d2ab58eb0c62bb@hi-jena.gsi.de> <810ed751-3a8a-43d7-b9b1-7d7c08f8fdf4@chalmers.se> <0dc854ec60194f299b776bc263eb2c72@hi-jena.gsi.de> <5f7958c3-297f-9303-efad-851c23f87ff0@chalmers.se> <897201d9f3424d318c7ed49ce4106aaa@hi-jena.gsi.de> <7f6060e5-ccad-48ba-927e-cb749bea290a@chalmers.se> <2d0ecc20c1ee4921b5ed807b41251fe5@hi-jena.gsi.de> <8fb50894-080f-4bf8-8ed3-f7a965de1b55@chalmers.se> <266475039f5d41fc9c8247714820854a@hi-jena.gsi.de> <2a94c163-aeb5-4336-bfe0-44d89172ec99@chalmers.se> <3aad99c7-e61b-47eb-8dcd-f7f872c56d33@chalmers.se> <9b98f1d3-dfbb-4a99-bb6c-7d658048ad83@chalmers.se> <09e3707e3d5844e8a6ded8b78b70358d@hi-jena.gsi.de> <36e8dae7-13cb-9258-99f3-4c5f2004c2a7@chalmers.se> <929564d321f54545b6abb2a24c9c6162@hi-jena.gsi.de> <111a7ad2c61a4e05bc826ee5cabd98d7@hi-jena.gsi.de> Message-ID: <6c3dc49a-5566-4a8f-b9b4-4a16f16586e9@chalmers.se> Dear G?nter, On 2024-01-23 11:53, Weber, Guenter Dr. wrote: > Dear Hans, > > I do not know how to interpret "my-daq-node". But I found a similar > command that Bastian once showed me. Is my-daq-note = localhost:8001? Sorry I did not explain this part properly, but you found the correct value. > mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/ucesb/empty$ ./empty > stream://localhost:8001 --print --data --max-events=10 > Event???????? 23358 Type/Subtype?? 10??? 1 Size????? 140 Trigger? 1 > ?SubEv ProcID???? 1 Type/Subtype?? 10??? 1 Size?????? 24 Ctrl?? 9 > Subcrate?? 1 > ?00000200 03e115f4 04e11396 05e12f3e 06e10001 f1a2000a > ?SubEv ProcID???? 1 Type/Subtype?? 20??? 2 Size?????? 84 Ctrl?? 9 > Subcrate?? 1 > ?80000000 65d8a6db 00012f3e 139615f4 00000010 0032e025 00000000 00000000 > ?00000000 00000000 00000000 00000000 00000000 00000001 00000001 00000001 > ?00000001 00000001 00000001 00000001 00000001 > > The last 16 entries of the LMD events are most probably the VULOM > scalers, with the first channel incrementing by one for each trigger. > Unclear to me is why the last 8 channels show a 1 instead of 0. Do you know what is connected to the last 8 channels? What if you reset the scalers before you start the DAQ, e.g.: $VULOM4_CTRL --addr=... --mux-src-scalers=reset > The 3rd and 4th entries belong to the 64-bit VULOM timestamp, probably. Yes. > Could you explain what the first two entries are? And the 5th? Word 1: Readout status The f-user builds this word based on the nurdlib readout result and the r3bfuser config. Each bit has a special meaning which you can find in ucesb/spec/land_std_vme.spec. Certain bits will expect certain data to follow this first word, see next. Word 2: Timestamp Since the readout status has the most significant bit set (bit 31), the next word is interpreted as a 32-bit timestamp. The r3bfuser puts its computer time here. Word 5: # of trloii scalers The # of trloii scaler values that follow, 0x10 = 16. Preferably the trloii readout should have provided a header with feature bits to explain whether there are timestamps and scalers, but it is what it is now... There is also the issue of the Vetar not being read out. It would be nice if the unpacker remained unchanged so you can read old and new files with the same program. If the Vetar is not needed since you read out the trloii timestamps, the easiest fix for now would be to introduce two barrier words after the Vulom. Nurdlib will not complain if there are too many, and Vetar timestamps can take on any value so the barrier words should be accepted by the unpacker. I will try to go through the sis3316 merge soon. Best regards, Hans > Many thanks and best greetings > > G?nter > > > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > Hans Toshihide T?rnqvist > *Gesendet:* Dienstag, 23. Januar 2024 11:25:45 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > TRLOII, DRASI, etc. were updated > Dear G?nter, > > I will have to look into the merge I did of the 'mcal_daq' and 'master' > changes for the sis3316. It is a very complex module with by far the > most complex code that I do not know very well, so it is very likely > that I made a mistake. > > You should have a ucesb/ directory, and inside there is hopefully an > already built binary ucesb/empty/empty. If not: > > cd ucesb > make empty -j8 > > You can then use it like this: > > cd ucesb/empty > ./empty --stream=my-daq-node --print --data --max-events=10 > > You can also save a raw data file: > > ./empty --stream=my-daq-node --output=my-test-file.lmd --max-events=10 > > and look at that: > > ./empty my-test-file.lmd --print --data > > Best regards, > Hans > > On 2024-01-23 11:05, Weber, Guenter Dr. wrote: >> Dear H?kan, >> >> >> as far as I know we never touched the SIS3316 firmware. But, as you know >> by now, I know every little about the details of our DAQ, unfortunately. >> >> >> Just for checking, I now removed the SIS3316 entries from main.cfg. >> Thus, after also eliminating the VETAR, we just have the VULOM. And now >> I don't get any errors: >> >> >> 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: >> 56583). >> Thread has no error buffer yet... >> CPUS: 1 >> delay: 1 >> 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: >> 56583). >> Thread has no error buffer yet... >> HOST: RIO4-MCAL-1 >> Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] >> 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 >> (eth1). >> 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = >> 0x19000000, 1 consumers. >> 10: lwroc_triva_readout.c:66: Silence TRIVA? (HALT) >> 10: lwroc_net_io.c:167: Started server on port 56583 (data port 39340). >> client union size: 244 208 188 508 640 204 204? => 640 >> 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: >> /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 >> 10: lwroc_main.c:706: Log message rate limit not in effect. >> 10: lwroc_readout.c:112: call readout_init... >> 10: lwroc_thread_util.c:117: This is the triva control thread! >> 10: lwroc_thread_util.c:117: This is the net io thread! >> 10: lwroc_thread_util.c:117: This is the slow_async thread! >> 10: lwroc_thread_util.c:117: This is the data server thread! >> 10: lwroc_message_internal.c:472: Message client connected! >> 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) >> [192.168.1.1]. >> 10: lwroc_triva_control.c:370: Setup TRIVA? (DISBUS, HALT, MASTER, RESET) >> 10: lwroc_triva_control.c:418: Minimum event time >> ctime(5000)+1*rd(689)+3*wr(634)+fctime(1000)=8591 ns (116.401 kHz) >> 10: lwroc_triva_state.c:1486: (Re)send ident messages... >> 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 >> 9: lwroc_triva_control.c:507: TEST: GO >> 10: lwroc_triva_control.c:725: RUN: RESET >> 10: lwroc_triva_control.c:729: RUN: MT=14 >> 9: lwroc_triva_control.c:737:?? GO (1 good test triggers done) (max >> 116.4 kHz) >> 10: lwroc_triva_readout.c:376: Trigger 14 seen. >> 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. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 >> (IN_READOUT).? EC: 1 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 10: config/parser.c:287: Opened >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { >> 10: config/parser.c:299: Closed >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } >> 10: config/parser.c:287: Opened './main.cfg' { >> 10: config/config.c:1299: .Global log level=verbose. >> 10: config/parser.c:287: .Opened >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { >> 10: config/parser.c:299: .Closed >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } >> 10: config/parser.c:287: .Opened >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { >> 10: config/parser.c:299: .Closed >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } >> 10: config/parser.c:287: .Opened >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { >> 10: config/parser.c:299: .Closed >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } >> 10: config/parser.c:299: Closed './main.cfg' } >> 10: crate/crate.c:347: crate_create { >> 10: crate/crate.c:673: crate_create(MCAL) } >> 10: crate/crate.c:899: crate_init(MCAL) { >> 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. >> LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) >> 10: crate/crate.c:976: .Fast-init module[0]=GSI_VULOM. >> 10: crate/crate.c:1073: crate_init(MCAL) } >> 10: ctrl/ctrl.c:788: Control server online. >> Thread has no error buffer yet... >> 10: f_user.c:559: WR ID=0x200. >> 10: f_user.c:565: TS offset unset. Will not modify stamp. >> 10: f_user.c:572: TPAT: No. >> 10: f_user.c:573: Sync-check: No. >> 10: f_user.c:575: Spill triggers: No. >> 10: f_user.c:576: LMU: No. >> 10: f_user.c:577: Timer latches: No. >> 10: f_user.c:578: Spill shape: No. >> 10: f_user.c:579: Micro-structure: No. >> 10: f_user.c:581: Multi-event flag: No. >> 10: f_user.c:586: UDP destination: None. >> >> The DAQ is running with 10 Hz, as expected. Is there an easy way to look >> at the output of the DAQ? This should now contain only of the time stamp >> and the 16 scaler channels from the VULOM. If we can verify that this >> minimum example is now running as expected, we can go back to debugging >> the SIS3316 part, ok? >> >> >> >> >> Best greetings >> >> G?nter >> >> >> >> ------------------------------------------------------------------------ >> *Von:* subexp-daq im Auftrag von >> H?kan T Johansson >> *Gesendet:* Montag, 22. Januar 2024 23:01:43 >> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >> TRLOII, DRASI, etc. were updated >> >> Dear G?nter, >> >> The error would be the line >> >>> 5: module/sis_3316/sis_3316.c:3096: [2]: timeout while polling for previous bank addr (bank 0 != 0) on ch 0 >> >> (the printout from lwroc_triva_state.c is basically debug help, just >> trying to help identifying which system is stuck, in case one has multiple >> crates (not the case here).) >> >> Question: when the modules are re-inited (which always happens after >> readout failure), it looks like the two SIS3316 modules have different >> firmwares? >> >> Is that intentional? >> >> How do those values compare to the other DAQ system? >> >> Best regards, >> H?kan >> >> >> >> On Mon, 22 Jan 2024, Weber, Guenter Dr. wrote: >> >>> >>> Dear Hans, >>> >>> >>> thank you for the explanations for r3bfuser.cfg. In the end only a single cryptic line remains in this file, right? >>> >>> >>> With the new R3B config and modified VULOM entry in main.cfg I get the following result: >>> >>> >>> ... everything looks nice and the SIS3316 threshold are set ... >>> >>> 10: crate/crate.c:1008: .Post-init module[1]=SIS_3316. >>> 10: crate/crate.c:1008: .Post-init module[2]=SIS_3316. >>> 10: crate/crate.c:1073: crate_init(MCAL) } >>> 5: f_user.c:1257: had readout error, ret=0x4, trigger=1, prev=1 >>> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >>> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 >>> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >>> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >>> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >>> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 >>> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >>> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >>> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >>> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 >>> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >>> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >>> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >>> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 >>> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >>> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >>> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >>> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 >>> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >>> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >>> 5: module/sis_3316/sis_3316.c:3096: [2]: timeout while polling for previous bank addr (bank 0 != 0) on ch 0 >>> 5: module/sis_3316/sis_3316.c:2512: sis3316 bank of channel not ready for readout. >>> 5: module/sis_3316/sis_3316.c:2329: sis3316 ch[0] test_channel failed >>> 5: crate/crate.c:1954: MCAL[2]=SIS_3316 readout error=0x00000004, dumping data: >>> 10: crate/crate.c:1970: ---[ Dump begin ]--- >>> 10: crate/crate.c:1970: Start=0x3005e230? Bytes=0=0x0 >>> 10: crate/crate.c:1970: ---[? Dump end? ]--- >>> 5: crate/crate.c:1449: MCAL: readout failed! >>> 5: crate/crate.c:1493: MCAL: had problems, re-initializing. >>> 10: crate/crate.c:683: crate_deinit(MCAL) { >>> 10: crate/crate.c:707: crate_deinit(MCAL) } >>> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >>> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 >>> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >>> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >>> 10: crate/crate.c:899: crate_init(MCAL) { >>> 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. >>> LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) >>> 10: crate/crate.c:923: .Slow-init module[1]=SIS_3316. >>> 10: module/map/map.c:224: ...rd(0x30000000+0x64/32)=535ns wr(0x30000000+0x64/32)=356ns. >>> 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x00800178. >>> 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x3316200e. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x0125000c. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x0125000c. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x0125000c. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x0125000c. >>> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >>> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 >>> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >>> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >>> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >>> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 >>> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >>> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >>> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. >>> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 5 >>> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >>> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >>> 10: crate/crate.c:923: .Slow-init module[2]=SIS_3316. >>> 10: module/map/map.c:224: ...rd(0x31000000+0x64/32)=540ns wr(0x31000000+0x64/32)=360ns. >>> 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. >>> 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. >>> 10: crate/crate.c:923: .Slow-init module[2]=SIS_3316. >>> 10: module/map/map.c:224: ...rd(0x31000000+0x64/32)=540ns wr(0x31000000+0x64/32)=360ns. >>> 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. >>> 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x01250011. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x01250011. >>> ^C8: lwroc_main.c:106: SIGINT received. >>> >>> I stopped the DAQ software manually. To me it looked like, the software tried every 10 seconds to restart the DAQ. >>> >>> >>> The DAQ setup consists of 1 RIO, 1 TRIVA, 1 VULOM B, 2 SIS3316, 1 VETAR2. >>> >>> The VULOM provides two output signals. A fast one to synchronize the SIS3316 modules and a slow one (10 Hz) that is used for triggering the DAQ. In this test setup no external signals are fed to the digitizers. >>> >>> >>> >>> >>> >>> Best greetings >>> >>> G?nter >>> >>> >>> >>> _______________________________________________________________________________________________________________________________________________________________________________________________________________________________ >>> Von: subexp-daq im Auftrag von Hans Toshihide T?rnqvist >>> Gesendet: Montag, 22. Januar 2024 15:57:24 >>> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >>> Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated >>> Dear G?nter, >>> >>> It seems also the r3bfuser configuration parser was updated. I took the >>> file you sent us on the 18th and updated it, with some explanations to >>> the changes. >>> >>> The SIS3316 modules do not need the barrier between. Note that with the >>> changed main.cfg, the data will be different and the unpacker may have >>> some problems, but let's get the DAQ running first :) >>> >>> Best regards, >>> Hans >>> >>> On 2024-01-22 15:29, Weber, Guenter Dr. wrote: >>> > Dear Hans, >>> > >>> > >>> > yes, the VETAR does not have an upstream connection. My impression was >>> > that in this case, the internal clock simply starts incrementing more or >>> > less in the same way the VULOM does. I have now commented out the VETAR. >>> > This is the result: >>> > >>> > >>> > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: >>> > 56583). >>> > Thread has no error buffer yet... >>> > CPUS: 1 >>> > delay: 1 >>> > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port: >>> > 56583). >>> > Thread has no error buffer yet... >>> > HOST: RIO4-MCAL-1 >>> > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] >>> > 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0 >>> > (eth1). >>> > 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 = >>> > 0x19000000, 1 consumers. >>> > 10: lwroc_triva_readout.c:66: Silence TRIVA? (HALT) >>> > 10: lwroc_net_io.c:167: Started server on port 56583 (data port 51756). >>> > client union size: 244 208 188 508 640 204 204? => 640 >>> > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: >>> > /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 >>> > 10: lwroc_main.c:706: Log message rate limit not in effect. >>> > 10: lwroc_readout.c:112: call readout_init... >>> > 10: lwroc_thread_util.c:117: This is the triva control thread! >>> > 10: lwroc_thread_util.c:117: This is the net io thread! >>> > 10: lwroc_thread_util.c:117: This is the slow_async thread! >>> > 10: lwroc_thread_util.c:117: This is the data server thread! >>> > 10: lwroc_message_internal.c:472: Message client connected! >>> > 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data) >>> > [192.168.1.1]. >>> > 10: lwroc_triva_control.c:370: Setup TRIVA? (DISBUS, HALT, MASTER, RESET) >>> > 10: lwroc_triva_control.c:418: Minimum event time >>> > ctime(5000)+1*rd(691)+3*wr(633)+fctime(1000)=8590 ns (116.414 kHz) >>> > 10: lwroc_triva_state.c:1486: (Re)send ident messages... >>> > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 >>> > 9: lwroc_triva_control.c:507: TEST: GO >>> > 10: lwroc_triva_control.c:725: RUN: RESET >>> > 10: lwroc_triva_control.c:729: RUN: MT=14 >>> > 9: lwroc_triva_control.c:737:?? GO (1 good test triggers done) (max >>> > 116.4 kHz) >>> > 10: lwroc_triva_readout.c:376: Trigger 14 seen. >>> > 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. >>> > 10: config/parser.c:287: Opened >>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { >>> > 10: config/parser.c:299: Closed >>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } >>> > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 >>> > (IN_READOUT).? EC: 1 >>> > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >>> > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >>> > 10: config/parser.c:287: Opened './main.cfg' { >>> > 10: config/config.c:1299: .Global log level=verbose. >>> > 10: config/parser.c:287: .Opened >>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { >>> > 10: config/parser.c:299: .Closed >>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } >>> > 10: config/parser.c:287: .Opened >>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { >>> > 10: config/parser.c:299: .Closed >>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } >>> > 10: config/parser.c:287: .Opened >>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { >>> > 10: config/parser.c:299: .Closed >>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } >>> > 10: config/parser.c:287: .Opened >>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { >>> > 10: config/parser.c:299: .Closed >>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } >>> > 10: config/parser.c:287: .Opened >>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { >>> > 10: config/parser.c:299: .Closed >>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } >>> > 10: config/parser.c:287: .Opened >>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { >>> > 10: config/parser.c:299: .Closed >>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } >>> > 10: config/parser.c:287: .Opened >>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { >>> > 10: config/parser.c:299: .Closed >>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } >>> > 10: config/parser.c:299: Closed './main.cfg' } >>> > 10: crate/crate.c:347: crate_create { >>> > 10: crate/crate.c:673: crate_create(MCAL) } >>> > 10: crate/crate.c:899: crate_init(MCAL) { >>> > 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM. >>> > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) >>> > 10: crate/crate.c:923: .Slow-init module[1]=SIS_3316. >>> > 10: module/map/map.c:224: ...rd(0x30000000+0x64/32)=535ns >>> > wr(0x30000000+0x64/32)=356ns. >>> > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x00800178. >>> > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x3316200e. >>> > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x0125000c. >>> > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x0125000c. >>> > 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x0125000c. >>> > 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x0125000c. >>> > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, >>> > and in deadtime. >>> > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 >>> > (IN_READOUT).? EC: 1 >>> > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >>> > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >>> > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, >>> > and in deadtime. >>> > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 >>> > (IN_READOUT).? EC: 1 >>> > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >>> > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >>> > 10: crate/crate.c:923: .Slow-init module[2]=SIS_3316. >>> > 10: module/map/map.c:224: ...rd(0x31000000+0x64/32)=540ns >>> > wr(0x31000000+0x64/32)=360ns. >>> > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. >>> > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. >>> > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. >>> > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. >>> > 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x01250011. >>> > 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x01250011. >>> > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, >>> > and in deadtime. >>> > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 >>> > (IN_READOUT).? EC: 1 >>> > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >>> > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >>> > 10: crate/crate.c:976: .Fast-init module[0]=GSI_VULOM. >>> > 10: crate/crate.c:976: .Fast-init module[1]=SIS_3316. >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[0] = 8 mV -> 0x0800010a >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[1] = 8 mV -> 0x0800010a >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[2] = 8 mV -> 0x0800010a >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[3] = 15 mV -> 0x080001f3 >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[4] = 8 mV -> 0x0800010a >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[5] = 8 mV -> 0x0800010a >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[6] = 10 mV -> 0x0800014c >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[7] = 8 mV -> 0x0800010a >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[8] = 8 mV -> 0x0800010a >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[9] = 8 mV -> 0x0800010a >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[10] = 13 mV -> 0x080001b0 >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[11] = 8 mV -> 0x0800010a >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[12] = 8 mV -> 0x0800010a >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[13] = 8 mV -> 0x0800010a >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[14] = 8 mV -> 0x0800010a >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[15] = 15 mV -> 0x080001f3 >>> > 10: crate/crate.c:976: .Fast-init module[2]=SIS_3316. >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[0] = 10 mV -> 0x0800014c >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[1] = 8 mV -> 0x0800010a >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[2] = 8 mV -> 0x0800010a >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[3] = 8 mV -> 0x0800010a >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[4] = 8 mV -> 0x0800010a >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[5] = 10 mV -> 0x0800014c >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[6] = 13 mV -> 0x080001b0 >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[7] = 8 mV -> 0x0800010a >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[8] = 8 mV -> 0x0800010a >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[9] = 8 mV -> 0x0800010a >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[10] = 8 mV -> 0x0800010a >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[11] = 8 mV -> 0x0800010a >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[12] = 8 mV -> 0x0800010a >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[13] = 8 mV -> 0x0800010a >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[14] = 8 mV -> 0x0800010a >>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[15] = 8 mV -> 0x0800010a >>> > 10: crate/crate.c:1008: .Post-init module[1]=SIS_3316. >>> > 10: crate/crate.c:1008: .Post-init module[2]=SIS_3316. >>> > 10: crate/crate.c:1073: crate_init(MCAL) } >>> > 10: ctrl/ctrl.c:788: Control server online. >>> > Thread has no error buffer yet... >>> > 5: f_user.c:484: r3bfuser.cfg:1: Weird config! >>> > 5: f_user.c:484: Calling abort()... >>> > >>> > >>> > Looks like the DAQ is able to set the thresholds for the first two >>> > SIS3316 modules. And then crashes. But there are only these two modules, >>> > so the main.cfg is done. I just noticed that I did not put a BARRIER >>> > between the initialization of the two SIS3316 modules. Is this relevant? >>> > But if it was, the problem would probably occur after the first module >>> > and not when the main.cfg was completely processed. >>> > >>> > >>> > >>> > >>> > >>> > Best greetings >>> > >>> > G?nter >>> > >>> > >>> > >>> > ------------------------------------------------------------------------ >>> > *Von:* subexp-daq im Auftrag von >>> > Hans Toshihide T?rnqvist >>> > *Gesendet:* Montag, 22. Januar 2024 15:18:20 >>> > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. >>> > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >>> > TRLOII, DRASI, etc. were updated >>> > Dear G?nter, >>> > >>> > Do you have a schematic of the setup? I.e. what modules have what >>> > connections, in the crate and to detectors. >>> > >>> > Some photos would also be nice. >>> > >>> > This would help our understanding of the setup. >>> > >>> > Best regards, >>> > Hans & H?kan >>> > -- >>> > subexp-daq mailing list >>> > subexp-daq at lists.chalmers.se >>> > https://lists.chalmers.se/mailman/listinfo/subexp-daq > >> > >>> > > >> >>> > >>> >>> >> > -- > subexp-daq mailing list > subexp-daq at lists.chalmers.se > https://lists.chalmers.se/mailman/listinfo/subexp-daq > > From f96hajo at chalmers.se Tue Jan 23 12:32:50 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Tue, 23 Jan 2024 12:32:50 +0100 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <929564d321f54545b6abb2a24c9c6162@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <1aa0afb1bf1e4f91b5d2ab58eb0c62bb@hi-jena.gsi.de> <810ed751-3a8a-43d7-b9b1-7d7c08f8fdf4@chalmers.se> <0dc854ec60194f299b776bc263eb2c72@hi-jena.gsi.de> <5f7958c3-297f-9303-efad-851c23f87ff0@chalmers.se> <897201d9f3424d318c7ed49ce4106aaa@hi-jena.gsi.de> <7f6060e5-ccad-48ba-927e-cb749bea290a@chalmers.se> <2d0ecc20c1ee4921b5ed807b41251fe5@hi-jena.gsi.de> <8fb50894-080f-4bf8-8ed3-f7a965de1b55@chalmers.se> <266475039f5d41fc9c8247714820854a@hi-jena.gsi.de> <2a94c163-aeb5-4336-bfe0-44d89172ec99@chalmers.se> <3aad99c7-e61b-47eb-8dcd-f7f872c56d33@chalmers.se> , <9b98f1d3-dfbb-4a99-bb6c-7d658048ad83@chalmers.se> <09e3707e3d5844e8a6ded8b78b70358d@hi-jena.gsi.de>, <36e8dae7-13cb-9258-99f3-4c5f2004c2a7@chalmers.se> <929564d321f54545b6abb2a24c9c6162@hi-jena.gsi.de> Message-ID: <16a7c247-a7ab-3217-d905-27e3264432da@chalmers.se> Dear G?nter, On Tue, 23 Jan 2024, Weber, Guenter Dr. wrote: > as far as I know we never touched the SIS3316 firmware. But, as you know by > now, I know every little about the details of our DAQ, unfortunately. Could you for the other DAQ system (with working SIS3316), check the output at startup or module re-init corresponding to these lines: 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x00800178. 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x3316200e. 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x0125000c. 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x0125000c. 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x0125000c. 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x0125000c. 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x01250011. 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x01250011. and see what versions those modules have loaded? Cheers, H?kan From g.weber at hi-jena.gsi.de Tue Jan 23 13:29:59 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 23 Jan 2024 12:29:59 +0000 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <16a7c247-a7ab-3217-d905-27e3264432da@chalmers.se> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <7cc6feff289e49a793efe26cf94724ad@hi-jena.gsi.de> <11285dde-8918-4b0a-9074-621f3865c347@chalmers.se> <1aa0afb1bf1e4f91b5d2ab58eb0c62bb@hi-jena.gsi.de> <810ed751-3a8a-43d7-b9b1-7d7c08f8fdf4@chalmers.se> <0dc854ec60194f299b776bc263eb2c72@hi-jena.gsi.de> <5f7958c3-297f-9303-efad-851c23f87ff0@chalmers.se> <897201d9f3424d318c7ed49ce4106aaa@hi-jena.gsi.de> <7f6060e5-ccad-48ba-927e-cb749bea290a@chalmers.se> <2d0ecc20c1ee4921b5ed807b41251fe5@hi-jena.gsi.de> <8fb50894-080f-4bf8-8ed3-f7a965de1b55@chalmers.se> <266475039f5d41fc9c8247714820854a@hi-jena.gsi.de> <2a94c163-aeb5-4336-bfe0-44d89172ec99@chalmers.se> <3aad99c7-e61b-47eb-8dcd-f7f872c56d33@chalmers.se> , <9b98f1d3-dfbb-4a99-bb6c-7d658048ad83@chalmers.se> <09e3707e3d5844e8a6ded8b78b70358d@hi-jena.gsi.de>, <36e8dae7-13cb-9258-99f3-4c5f2004c2a7@chalmers.se> <929564d321f54545b6abb2a24c9c6162@hi-jena.gsi.de>, <16a7c247-a7ab-3217-d905-27e3264432da@chalmers.se> Message-ID: Dear friends, attached please find the output of the old system. To me it looks as if every single setting of the SIS3316 modules is printed to screen. In total almost 2000 lines for just two modules. I find the following serial number entries: Line 701: 10: a:1: ..Serial number=0x00800172. (module/sis_3316/sis_3316.c:1305) 10: a:1: ..id/firmware=0x33162010. (module/sis_3316/sis_3316.c:1312) Line 796: 10: a:1: ..Serial number=0x00800170. (module/sis_3316/sis_3316.c:1305) 10: a:1: ..id/firmware=0x3316a012. (module/sis_3316/sis_3316.c:1312) Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Dienstag, 23. Januar 2024 12:32:50 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated Dear G?nter, On Tue, 23 Jan 2024, Weber, Guenter Dr. wrote: > as far as I know we never touched the SIS3316 firmware. But, as you know by > now, I know every little about the details of our DAQ, unfortunately. Could you for the other DAQ system (with working SIS3316), check the output at startup or module re-init corresponding to these lines: 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x00800178. 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x3316200e. 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x0125000c. 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x0125000c. 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x0125000c. 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x0125000c. 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x01250011. 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x01250011. and see what versions those modules have loaded? Cheers, H?kan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- RIO4-MCAL-2 mbsdaq > ./master.bash hwmap_mapvme.c:240: LOG: Virtual address for TRLO II @ VME 0x03000000 is 0x3005e000. LOG: TRLO: MD5SUM: 0x426cb99c (CT: 5bba6507 = 2018-10-07 19:56:55 UTC) Clear module setup. Loading config file 'vulom.trlo'. Executing 'standalone'. Executing 'module_trigger'. 10: lwroc_hostname_util.c:105: Host 'lyserv' known as 192.168.1.1 (port: 56583). Thread has no error buffer yet... CPUS: 1 delay: 1 10: lwroc_hostname_util.c:105: Host 'lyserv' known as 192.168.1.1 (port: 56583). Thread has no error buffer yet... HOST: RIO4-MCAL-2 Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] 10: lwroc_data_pipe.c:122: Data buffer READOUT_PIPE, size 419430400 = 0x19000000, 1 consumers. 11: lwroc_triva_readout.c:53: TRIVA: master,fctime=10,ctime=50 11: lwroc_triva_readout.c:210: TRIVA mode: master=1 11: lwroc_triva_readout.c:222: TRIVA VME map (addr=0x02000000) 11: hwmap_mapvme.c:240: Virtual address for TRIVA @ VME 0x02000000 is 0x30025000. 11: lwroc_triva_readout.c:264: TRIVA off 0x00 = 00009422 10: lwroc_triva_readout.c:66: Silence TRIVA (HALT) 10: lwroc_net_io.c:164: Started server on port 56583 (data port 46763). client union size: 244 192 184 508 640 3048 204 => 3048 10: lwroc_readout.c:100: call readout_init... 10: lwroc_thread_util.c:105: This is the triva control thread! 10: lwroc_thread_util.c:105: This is the net io thread! 10: lwroc_thread_util.c:105: This is the data server thread! 10: lwroc_net_trans.c:1073: [drasi] Transport client connected (data) [192.168.1.1]. network client -> data network thread using blocking writes 10: lwroc_message_internal.c:418: Message client connected! 11: lwroc_triva_readout.c:606: Readout thread waiting for inject request... 11: lwroc_triva_control.c:350: TRIVA control: startup (wait for init request). move to data server thread... 11: lwroc_net_message.c:192: [msgclnt: 192.168.1.1] Connected. 10: lwroc_triva_control.c:370: Setup TRIVA (DISBUS, HALT, MASTER, RESET) 11: lwroc_triva_control.c:397: Set FCAtime to 10 and Ctime to 50... 10: lwroc_triva_control.c:418: Minimum event time ctime(5000)+1*rd(691)+3*wr(633)+fctime(1000)=8590 ns (116.414 kHz) 11: lwroc_triva_control.c:420: Clearing TRIVA... (HALT, DIS_IRQ, CLEAR=RESET) 10: lwroc_triva_state.c:1412: (Re)send ident messages... 11: lwroc_triva_readout.c:628: Readout thread injecting ID message! 11: lwroc_triva_control.c:478: TRIVA control: initialised (wait for test request). 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 9: lwroc_triva_control.c:507: TEST: GO 11: lwroc_triva_control.c:522: status = 0x00008021 11: lwroc_triva_control.c:670: TRIVA control: initialised (going for run). 11: lwroc_triva_control.c:679: status = 0x00000021 10: lwroc_triva_control.c:700: RUN: RESET 10: lwroc_triva_control.c:704: RUN: MT=14 9: lwroc_triva_control.c:712: GO (1 good test triggers done) (max 116.4 kHz) 11: lwroc_triva_readout.c:683: Readout thread loop active! 10: lwroc_triva_readout.c:369: Trigger 14 seen. 11: lwroc_triva_control.c:745: TRIVA control: running... 10: a:1: Global log level=verbose. (config/config.c:1292) 11: a:1: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/crate.cfg'. (config/parser.c:286) 8: lwroc_triva_state.c:2322: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 10: lwroc_triva_state.c:2351: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2411: Node(s) busy in readout, waiting... 11: a:1: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/crate.cfg'. (config/parser.c:298) 11: a:1: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg'. (config/parser.c:286) 11: a:1: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg'. (config/parser.c:298) 11: a:1: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/module_log_level.cfg'. (config/parser.c:286) 11: a:1: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/module_log_level.cfg'. (config/parser.c:298) 11: a:1: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/gsi_vetar.cfg'. (config/parser.c:286) 11: a:1: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/gsi_vetar.cfg'. (config/parser.c:298) 11: a:1: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/module_log_level.cfg'. (config/parser.c:286) 11: a:1: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/module_log_level.cfg'. (config/parser.c:298) 11: a:1: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/sis_3316.cfg'. (config/parser.c:286) 11: a:1: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/sis_3316.cfg'. (config/parser.c:298) 11: a:1: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/module_log_level.cfg'. (config/parser.c:286) 11: a:1: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/module_log_level.cfg'. (config/parser.c:298) 11: a:1: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/sis_3316.cfg'. (config/parser.c:286) 11: a:1: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/sis_3316.cfg'. (config/parser.c:298) 11: a:1: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/module_log_level.cfg'. (config/parser.c:286) 11: a:1: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2023_mcalstruck/nurdlib/cfg/default/module_log_level.cfg'. (config/parser.c:298) 11: a:1: Closed './main.cfg'. (config/parser.c:298) 10: a:1: crate_create { (crate/crate.c:301) 11: a:1: .Crate="MCAL". (crate/crate.c:316) 11: a:1: .Adaptive CVT=no. (crate/crate.c:321) 11: a:1: .Shadow readout disabled. (crate/crate.c:332) 11: a:1: .Early deadtime release=no. (crate/crate.c:337) 11: a:1: .event_max override=0. (crate/crate.c:342) 11: a:1: .Re-init sleep=1s. (crate/crate.c:347) 11: a:1: .Gsi Siderem crate_create { (module/gsi_siderem/gsi_siderem.c:51) 11: a:1: .Gsi Siderem crate_create } (module/gsi_siderem/gsi_siderem.c:55) 11: a:1: .Gsi Tacquila crate_create { (module/gsi_tacquila/gsi_tacquila.c:103) 11: a:1: .Gsi Tacquila crate_create } (module/gsi_tacquila/gsi_tacquila.c:106) 11: a:1: .Pnpi Cros3 crate_create { (module/pnpi_cros3/pnpi_cros3.c:216) 11: a:1: .Pnpi Cros3 crate_create } (module/pnpi_cros3/pnpi_cros3.c:219) 11: a:1: .Gsi Vulom create { (module/gsi_vulom/gsi_vulom.c:5) 11: a:1: ..TRLO II create { (module/trloii/trloii.c:300) 11: a:1: ...Address=03000000. (module/trloii/trloii.c:303) 11: a:1: ...Has timestamps. (module/trloii/trloii.c:307) 11: a:1: ..TRLO II create } (module/trloii/trloii.c:329) 11: a:1: .Gsi Vulom create } (module/gsi_vulom/gsi_vulom.c:5) 11: a:1: .module[0]=GSI_VULOM. (crate/crate.c:468) 11: a:1: .Gsi Etherbone create { (module/gsi_etherbone/gsi_etherbone.c:72) 11: a:1: ..Mode=etherbone. (module/gsi_etherbone/gsi_etherbone.c:82) 11: a:1: ..Address=0x50000000. (module/gsi_etherbone/gsi_etherbone.c:87) 11: a:1: .Gsi Etherbone create } (module/gsi_etherbone/gsi_etherbone.c:90) 11: a:1: .module[1]=GSI_VETAR. (crate/crate.c:468) 11: a:1: .Gsi Vulom are_distinguishable. (module/gsi_vulom/gsi_vulom.c:5) 11: a:1: .sis3316 create { (module/sis_3316/sis_3316.c:227) 11: a:1: ..Address = 30000000 (module/sis_3316/sis_3316.c:238) 11: a:1: ..sis3316 get_config { (module/sis_3316/sis_3316.c:3138) 11: a:1: ...channels_to_read = mask 0x00000000 (module/sis_3316/sis_3316.c:3148) 11: a:1: ...use_tau_correction = mask 0x00000000 (module/sis_3316/sis_3316.c:3160) 11: a:1: ...use_external_trigger = mask 0x0000ffff (module/sis_3316/sis_3316.c:3166) 11: a:1: ...use_internal_trigger = mask 0x00000000 (module/sis_3316/sis_3316.c:3172) 11: a:1: ...trigger_output = mask 0x00000000 (module/sis_3316/sis_3316.c:3178) 11: a:1: ...use_dual_threshold = mask 0x0000ffff (module/sis_3316/sis_3316.c:3184) 11: a:1: ...use_external_gate = mask 0x00000000. (module/sis_3316/sis_3316.c:3192) 11: a:1: ...use_external_veto = mask 0x00000000. (module/sis_3316/sis_3316.c:3198) 11: a:1: ...discard_data = mask 0x00000000 (module/sis_3316/sis_3316.c:3204) 11: a:1: ...discard_threshold = 0. (module/sis_3316/sis_3316.c:3210) 11: a:1: ...dac_offset[0] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[1] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[2] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[3] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[4] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[5] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[6] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[7] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[8] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[9] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[10] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[11] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[12] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[13] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[14] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[15] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...energy_pickup[0] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[1] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[2] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[3] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[4] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[5] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[6] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[7] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[8] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[9] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[10] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[11] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[12] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[13] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[14] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[15] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...internal_trigger_delay[0] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[1] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[2] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[3] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[4] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[5] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[6] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[7] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[8] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[9] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[10] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[11] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[12] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[13] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[14] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[15] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...use user counter = no. (module/sis_3316/sis_3316.c:3240) 11: a:1: ...use ADC dithering = no. (module/sis_3316/sis_3316.c:3246) 11: a:1: ...use auto bank switch = yes. (module/sis_3316/sis_3316.c:3252) 11: a:1: ...Run mode = SYNC (simple) (module/sis_3316/sis_3316.c:3269) 11: a:1: ...use termination = no. (module/sis_3316/sis_3316.c:3279) 11: a:1: ...average mode[0] = 16 samples (0x 3) (module/sis_3316/sis_3316.c:3315) 11: a:1: ...average pretrigger[0] = 3900 samples (module/sis_3316/sis_3316.c:3318) 11: a:1: ...average length[0] = 16384 samples (module/sis_3316/sis_3316.c:3320) 11: a:1: ...average mode[1] = 16 samples (0x 3) (module/sis_3316/sis_3316.c:3315) 11: a:1: ...average pretrigger[1] = 3900 samples (module/sis_3316/sis_3316.c:3318) 11: a:1: ...average length[1] = 16384 samples (module/sis_3316/sis_3316.c:3320) 11: a:1: ...average mode[2] = 16 samples (0x 3) (module/sis_3316/sis_3316.c:3315) 11: a:1: ...average pretrigger[2] = 3900 samples (module/sis_3316/sis_3316.c:3318) 11: a:1: ...average length[2] = 16384 samples (module/sis_3316/sis_3316.c:3320) 11: a:1: ...average mode[3] = 16 samples (0x 3) (module/sis_3316/sis_3316.c:3315) 11: a:1: ...average pretrigger[3] = 3900 samples (module/sis_3316/sis_3316.c:3318) 11: a:1: ...average length[3] = 16384 samples (module/sis_3316/sis_3316.c:3320) 11: a:1: ...use check_level = paranoid. (module/sis_3316/sis_3316.c:3336) 11: a:1: ...Using BLT mode = 80. (module/sis_3316/sis_3316.c:3343) 11: a:1: ...Sampling clock frequency = 125 MHz. (module/sis_3316/sis_3316.c:3348) 11: a:1: ...External clock frequency = 12 MHz. (module/sis_3316/sis_3316.c:3364) 11: a:1: ...use accumulator 2 = yes. (module/sis_3316/sis_3316.c:3386) 11: a:1: ...use accumulator 6 = yes. (module/sis_3316/sis_3316.c:3392) 11: a:1: ...Use MAW data = no. (module/sis_3316/sis_3316.c:3398) 11: a:1: ...Use max energy = yes. (module/sis_3316/sis_3316.c:3404) 11: a:1: ...use_peak_charge = no. (module/sis_3316/sis_3316.c:3410) 11: a:1: ...write traces raw = no. (module/sis_3316/sis_3316.c:3416) 11: a:1: ...write traces maw = no. (module/sis_3316/sis_3316.c:3422) 11: a:1: ...write traces maw energy = no. (module/sis_3316/sis_3316.c:3428) 11: a:1: ...write histograms = no. (module/sis_3316/sis_3316.c:3434) 11: a:1: ...is FP bus master = yes. (module/sis_3316/sis_3316.c:3440) 11: a:1: ...Baseline average = 64 ns. (module/sis_3316/sis_3316.c:3456) 11: a:1: ...Baseline delay = 32 ns. (module/sis_3316/sis_3316.c:3462) 11: a:1: ...Decaytime[0] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[1] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[2] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[3] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[4] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[5] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[6] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[7] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[8] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[9] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[10] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[11] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[12] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[13] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[14] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[15] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Invert signal = no. (module/sis_3316/sis_3316.c:3484) 11: a:1: ...use_cfd_trigger = yes. (module/sis_3316/sis_3316.c:3490) 11: a:1: ...threshold_mV[0] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[1] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[2] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[3] = 15. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[4] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[5] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[6] = 10. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[7] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[8] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[9] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[10] = 13. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[11] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[12] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[13] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[14] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[15] = 15. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_high_e_mV[0] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[1] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[2] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[3] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[4] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[5] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[6] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[7] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[8] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[9] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[10] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[11] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[12] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[13] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[14] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[15] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...peak[0] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[1] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[2] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[3] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[4] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[5] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[6] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[7] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[8] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[9] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[10] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[11] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[12] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[13] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[14] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[15] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...gap[0] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[1] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[2] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[3] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[4] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[5] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[6] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[7] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[8] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[9] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[10] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[11] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[12] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[13] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[14] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[15] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...peak_e[0] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[1] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[2] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[3] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[4] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[5] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[6] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[7] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[8] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[9] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[10] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[11] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[12] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[13] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[14] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[15] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...gap_e[0] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[1] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[2] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[3] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[4] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[5] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[6] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[7] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[8] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[9] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[10] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[11] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[12] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[13] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[14] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[15] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...sample_length[0] = 8000 ns. (module/sis_3316/sis_3316.c:3557) 11: a:1: ... = 0 ms. (module/sis_3316/sis_3316.c:3559) 11: a:1: ...sample_length[0] = 1000 samples. (module/sis_3316/sis_3316.c:3564) 11: a:1: ...sample_length[1] = 8000 ns. (module/sis_3316/sis_3316.c:3557) 11: a:1: ... = 0 ms. (module/sis_3316/sis_3316.c:3559) 11: a:1: ...sample_length[1] = 1000 samples. (module/sis_3316/sis_3316.c:3564) 11: a:1: ...sample_length[2] = 8000 ns. (module/sis_3316/sis_3316.c:3557) 11: a:1: ... = 0 ms. (module/sis_3316/sis_3316.c:3559) 11: a:1: ...sample_length[2] = 1000 samples. (module/sis_3316/sis_3316.c:3564) 11: a:1: ...sample_length[3] = 8000 ns. (module/sis_3316/sis_3316.c:3557) 11: a:1: ... = 0 ms. (module/sis_3316/sis_3316.c:3559) 11: a:1: ...sample_length[3] = 1000 samples. (module/sis_3316/sis_3316.c:3564) 11: a:1: ...pretrigger_delay[0] = 32500 ns. (module/sis_3316/sis_3316.c:3581) 11: a:1: ...pretrigger_delay[0] = 4062 samples. (module/sis_3316/sis_3316.c:3586) 11: a:1: ...pretrigger_delay[1] = 32500 ns. (module/sis_3316/sis_3316.c:3581) 11: a:1: ...pretrigger_delay[1] = 4062 samples. (module/sis_3316/sis_3316.c:3586) 11: a:1: ...pretrigger_delay[2] = 32500 ns. (module/sis_3316/sis_3316.c:3581) 11: a:1: ...pretrigger_delay[2] = 4062 samples. (module/sis_3316/sis_3316.c:3586) 11: a:1: ...pretrigger_delay[3] = 32500 ns. (module/sis_3316/sis_3316.c:3581) 11: a:1: ...pretrigger_delay[3] = 4062 samples. (module/sis_3316/sis_3316.c:3586) 11: a:1: ...sample_length_maw[0] = 2048. (module/sis_3316/sis_3316.c:3601) 11: a:1: ...sample_length_maw[1] = 2048. (module/sis_3316/sis_3316.c:3601) 11: a:1: ...sample_length_maw[2] = 2048. (module/sis_3316/sis_3316.c:3601) 11: a:1: ...sample_length_maw[3] = 2048. (module/sis_3316/sis_3316.c:3601) 11: a:1: ...pretrigger_delay_maw[0] = 100. (module/sis_3316/sis_3316.c:3610) 11: a:1: ...pretrigger_delay_maw[1] = 100. (module/sis_3316/sis_3316.c:3610) 11: a:1: ...pretrigger_delay_maw[2] = 100. (module/sis_3316/sis_3316.c:3610) 11: a:1: ...pretrigger_delay_maw[3] = 100. (module/sis_3316/sis_3316.c:3610) 11: a:1: ...sample_length_maw_e[0] = 2048. (module/sis_3316/sis_3316.c:3626) 11: a:1: ...sample_length_maw_e[1] = 2048. (module/sis_3316/sis_3316.c:3626) 11: a:1: ...sample_length_maw_e[2] = 2048. (module/sis_3316/sis_3316.c:3626) 11: a:1: ...sample_length_maw_e[3] = 2048. (module/sis_3316/sis_3316.c:3626) 11: a:1: ...pretrigger_delay_maw_e[0] = 100. (module/sis_3316/sis_3316.c:3635) 11: a:1: ...pretrigger_delay_maw_e[1] = 100. (module/sis_3316/sis_3316.c:3635) 11: a:1: ...pretrigger_delay_maw_e[2] = 100. (module/sis_3316/sis_3316.c:3635) 11: a:1: ...pretrigger_delay_maw_e[3] = 100. (module/sis_3316/sis_3316.c:3635) 11: a:1: ...gate[0].delay = 1024 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[0].width = 2048 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[1].delay = 65000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[1].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[2].delay = 130000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[2].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[3].delay = 195000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[3].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[4].delay = 260000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[4].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[5].delay = 325000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[5].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[6].delay = 390000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[6].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[7].delay = 455000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[7].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ..sis3316 get_config } (module/sis_3316/sis_3316.c:3668) 11: a:1: .sis3316 create } (module/sis_3316/sis_3316.c:249) 11: a:1: .module[2]=SIS_3316. (crate/crate.c:468) 11: a:1: .sis3316 create { (module/sis_3316/sis_3316.c:227) 11: a:1: ..Address = 31000000 (module/sis_3316/sis_3316.c:238) 11: a:1: ..sis3316 get_config { (module/sis_3316/sis_3316.c:3138) 11: a:1: ...channels_to_read = mask 0x0000ffff (module/sis_3316/sis_3316.c:3148) 11: a:1: ...use_tau_correction = mask 0x00000000 (module/sis_3316/sis_3316.c:3160) 11: a:1: ...use_external_trigger = mask 0x0000ffff (module/sis_3316/sis_3316.c:3166) 11: a:1: ...use_internal_trigger = mask 0x00000000 (module/sis_3316/sis_3316.c:3172) 11: a:1: ...trigger_output = mask 0x00000000 (module/sis_3316/sis_3316.c:3178) 11: a:1: ...use_dual_threshold = mask 0x0000ffff (module/sis_3316/sis_3316.c:3184) 11: a:1: ...use_external_gate = mask 0x00000000. (module/sis_3316/sis_3316.c:3192) 11: a:1: ...use_external_veto = mask 0x00000000. (module/sis_3316/sis_3316.c:3198) 11: a:1: ...discard_data = mask 0x00000000 (module/sis_3316/sis_3316.c:3204) 11: a:1: ...discard_threshold = 0. (module/sis_3316/sis_3316.c:3210) 11: a:1: ...dac_offset[0] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[1] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[2] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[3] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[4] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[5] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[6] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[7] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[8] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[9] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[10] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[11] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[12] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[13] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[14] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[15] = 0. (module/sis_3316/sis_3316.c:3217) a:1: ...energy_pickup[0] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[1] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[2] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[3] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[4] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[5] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[6] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[7] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[8] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[9] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[10] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[11] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[12] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[13] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[14] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[15] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...internal_trigger_delay[0] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[1] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[2] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[3] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[4] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[5] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[6] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[7] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[8] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[9] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[10] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[11] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[12] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[13] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[14] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[15] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...use user counter = no. (module/sis_3316/sis_3316.c:3240) 11: a:1: ...use ADC dithering = no. (module/sis_3316/sis_3316.c:3246) 11: a:1: ...use auto bank switch = yes. (module/sis_3316/sis_3316.c:3252) 11: a:1: ...Run mode = SYNC (simple) (module/sis_3316/sis_3316.c:3269) 11: a:1: ...use termination = no. (module/sis_3316/sis_3316.c:3279) 11: a:1: ...average mode[0] = 16 samples (0x 3) (module/sis_3316/sis_3316.c:3315) 11: a:1: ...average pretrigger[0] = 3900 samples (module/sis_3316/sis_3316.c:3318) 11: a:1: ...average length[0] = 16384 samples (module/sis_3316/sis_3316.c:3320) 11: a:1: ...average mode[1] = 16 samples (0x 3) (module/sis_3316/sis_3316.c:3315) 11: a:1: ...average pretrigger[1] = 3900 samples (module/sis_3316/sis_3316.c:3318) 11: a:1: ...average length[1] = 16384 samples (module/sis_3316/sis_3316.c:3320) 11: a:1: ...average mode[2] = 16 samples (0x 3) (module/sis_3316/sis_3316.c:3315) 11: a:1: ...average pretrigger[2] = 3900 samples (module/sis_3316/sis_3316.c:3318) 11: a:1: ...average length[2] = 16384 samples (module/sis_3316/sis_3316.c:3320) 11: a:1: ...average mode[3] = 16 samples (0x 3) (module/sis_3316/sis_3316.c:3315) 11: a:1: ...average pretrigger[3] = 3900 samples (module/sis_3316/sis_3316.c:3318) 11: a:1: ...average length[3] = 16384 samples (module/sis_3316/sis_3316.c:3320) 11: a:1: ...use check_level = paranoid. (module/sis_3316/sis_3316.c:3336) 11: a:1: ...Using BLT mode = 80. (module/sis_3316/sis_3316.c:3343) 11: a:1: ...Sampling clock frequency = 125 MHz. (module/sis_3316/sis_3316.c:3348) 11: a:1: ...External clock frequency = 0 MHz. (module/sis_3316/sis_3316.c:3364) 11: a:1: ...use accumulator 2 = yes. (module/sis_3316/sis_3316.c:3386) 11: a:1: ...use accumulator 6 = yes. (module/sis_3316/sis_3316.c:3392) 11: a:1: ...Use MAW data = no. (module/sis_3316/sis_3316.c:3398) 11: a:1: ...Use max energy = yes. (module/sis_3316/sis_3316.c:3404) 11: a:1: ...use_peak_charge = no. (module/sis_3316/sis_3316.c:3410) 11: a:1: ...write traces raw = no. (module/sis_3316/sis_3316.c:3416) 11: a:1: ...write traces maw = no. (module/sis_3316/sis_3316.c:3422) 11: a:1: ...write traces maw energy = no. (module/sis_3316/sis_3316.c:3428) 11: a:1: ...write histograms = no. (module/sis_3316/sis_3316.c:3434) 11: a:1: ...is FP bus master = no. (module/sis_3316/sis_3316.c:3440) 11: a:1: ...Baseline average = 64 ns. (module/sis_3316/sis_3316.c:3456) 11: a:1: ...Baseline delay = 32 ns. (module/sis_3316/sis_3316.c:3462) 11: a:1: ...Decaytime[0] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[1] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[2] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[3] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[4] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[5] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[6] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[7] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[8] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[9] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[10] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[11] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[12] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[13] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[14] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[15] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Invert signal = no. (module/sis_3316/sis_3316.c:3484) 11: a:1: ...use_cfd_trigger = yes. (module/sis_3316/sis_3316.c:3490) 11: a:1: ...threshold_mV[0] = 10. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[1] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[2] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[3] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[4] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[5] = 10. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[6] = 13. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[7] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[8] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[9] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[10] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[11] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[12] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[13] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[14] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[15] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_high_e_mV[0] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[1] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[2] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[3] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[4] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[5] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[6] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[7] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[8] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[9] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[10] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[11] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[12] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[13] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[14] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[15] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...peak[0] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[1] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[2] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[3] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[4] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[5] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[6] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[7] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[8] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[9] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[10] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[11] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[12] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[13] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[14] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[15] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...gap[0] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[1] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[2] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[3] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[4] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[5] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[6] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[7] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[8] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[9] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[10] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[11] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[12] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[13] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[14] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[15] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...peak_e[0] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[1] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[2] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[3] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[4] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[5] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[6] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[7] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[8] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[9] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[10] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[11] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[12] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[13] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[14] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[15] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...gap_e[0] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[1] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[2] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[3] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[4] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[5] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[6] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[7] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[8] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[9] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[10] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[11] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[12] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[13] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[14] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[15] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...sample_length[0] = 8000 ns. (module/sis_3316/sis_3316.c:3557) 11: a:1: ... = 0 ms. (module/sis_3316/sis_3316.c:3559) 11: a:1: ...sample_length[0] = 1000 samples. (module/sis_3316/sis_3316.c:3564) 11: a:1: ...sample_length[1] = 8000 ns. (module/sis_3316/sis_3316.c:3557) 11: a:1: ... = 0 ms. (module/sis_3316/sis_3316.c:3559) 11: a:1: ...sample_length[1] = 1000 samples. (module/sis_3316/sis_3316.c:3564) 11: a:1: ...sample_length[2] = 8000 ns. (module/sis_3316/sis_3316.c:3557) 11: a:1: ... = 0 ms. (module/sis_3316/sis_3316.c:3559) 11: a:1: ...sample_length[2] = 1000 samples. (module/sis_3316/sis_3316.c:3564) 11: a:1: ...sample_length[3] = 8000 ns. (module/sis_3316/sis_3316.c:3557) 11: a:1: ... = 0 ms. (module/sis_3316/sis_3316.c:3559) 11: a:1: ...sample_length[3] = 1000 samples. (module/sis_3316/sis_3316.c:3564) 11: a:1: ...pretrigger_delay[0] = 32500 ns. (module/sis_3316/sis_3316.c:3581) 11: a:1: ...pretrigger_delay[0] = 4062 samples. (module/sis_3316/sis_3316.c:3586) 11: a:1: ...pretrigger_delay[1] = 32500 ns. (module/sis_3316/sis_3316.c:3581) 11: a:1: ...pretrigger_delay[1] = 4062 samples. (module/sis_3316/sis_3316.c:3586) 11: a:1: ...pretrigger_delay[2] = 32500 ns. (module/sis_3316/sis_3316.c:3581) 11: a:1: ...pretrigger_delay[2] = 4062 samples. (module/sis_3316/sis_3316.c:3586) 11: a:1: ...pretrigger_delay[3] = 32500 ns. (module/sis_3316/sis_3316.c:3581) 11: a:1: ...pretrigger_delay[3] = 4062 samples. (module/sis_3316/sis_3316.c:3586) 11: a:1: ...sample_length_maw[0] = 2048. (module/sis_3316/sis_3316.c:3601) 11: a:1: ...sample_length_maw[1] = 2048. (module/sis_3316/sis_3316.c:3601) 11: a:1: ...sample_length_maw[2] = 2048. (module/sis_3316/sis_3316.c:3601) 11: a:1: ...sample_length_maw[3] = 2048. (module/sis_3316/sis_3316.c:3601) 11: a:1: ...pretrigger_delay_maw[0] = 100. (module/sis_3316/sis_3316.c:3610) 11: a:1: ...pretrigger_delay_maw[1] = 100. (module/sis_3316/sis_3316.c:3610) 11: a:1: ...pretrigger_delay_maw[2] = 100. (module/sis_3316/sis_3316.c:3610) 11: a:1: ...pretrigger_delay_maw[3] = 100. (module/sis_3316/sis_3316.c:3610) 11: a:1: ...sample_length_maw_e[0] = 2048. (module/sis_3316/sis_3316.c:3626) 11: a:1: ...sample_length_maw_e[1] = 2048. (module/sis_3316/sis_3316.c:3626) 11: a:1: ...sample_length_maw_e[2] = 2048. (module/sis_3316/sis_3316.c:3626) 11: a:1: ...sample_length_maw_e[3] = 2048. (module/sis_3316/sis_3316.c:3626) 11: a:1: ...pretrigger_delay_maw_e[0] = 100. (module/sis_3316/sis_3316.c:3635) 11: a:1: ...pretrigger_delay_maw_e[1] = 100. (module/sis_3316/sis_3316.c:3635) 11: a:1: ...pretrigger_delay_maw_e[2] = 100. (module/sis_3316/sis_3316.c:3635) 11: a:1: ...pretrigger_delay_maw_e[3] = 100. (module/sis_3316/sis_3316.c:3635) 11: a:1: ...gate[0].delay = 1024 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[0].width = 2048 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[1].delay = 65000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[1].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[2].delay = 130000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[2].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[3].delay = 195000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[3].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[4].delay = 260000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[4].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[5].delay = 325000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[5].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[6].delay = 390000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[6].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[7].delay = 455000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[7].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ..sis3316 get_config } (module/sis_3316/sis_3316.c:3668) 11: a:1: .sis3316 create } (module/sis_3316/sis_3316.c:249) 11: a:1: .module[3]=SIS_3316. (crate/crate.c:468) 11: a:1: .Counter=auto:Default. (crate/crate.c:572) 10: a:1: crate_create(MCAL) } (crate/crate.c:622) 10: a:1: crate_init(MCAL) { (crate/crate.c:841) 11: a:1: .map_setup { (module/map/map.c:183) 11: a:1: ..sicy_setup { (module/map/map_xpc_3310.c:82) 11: a:1: ...bridge_setup { (module/map/map_xpc_3310.c:52) 11: a:1: ...bridge_setup } (module/map/map_xpc_3310.c:60) 11: a:1: ..sicy_setup } (module/map/map_xpc_3310.c:84) 11: a:1: ..blt_setup { (module/map/map_xpc_3310.c:126) 11: a:1: ...bridge_setup { (module/map/map_xpc_3310.c:52) 11: a:1: ...bridge_setup } (module/map/map_xpc_3310.c:60) 11: a:1: ..blt_setup } (module/map/map_xpc_3310.c:136) 11: a:1: ..Broken BLT return val = yes. (module/map/map.c:186) 11: a:1: .map_setup } (module/map/map.c:193) 11: a:1: .Slow module[0]=GSI_VULOM. (crate/crate.c:866) 11: a:1: .Gsi Vulom init_slow { (module/gsi_vulom/gsi_vulom.c:5) 11: a:1: ..TRLO II init_slow { (module/trloii/trloii.c:404) 11: a:1: ...map_map(addr=0x03000000,size=0x00016000,mode=noblt,poke=0x0000000c/32) { (module/map/map.c:127) 11: a:1: ....map_poke { (module/map/map.c:171) 11: a:1: .....sicy_map(addr=0x0300000c,size=0x4) { (module/map/map.c:255) 11: a:1: .....sicy_map(mapped=0x3001f00c) } (module/map/map.c:267) 11: a:1: .....Poke reading 0x3001f00c... (module/map/map_sicy_common.c:38) 11: a:1: .....sicy_unmap { (module/map/map.c:275) 11: a:1: .....sicy_unmap } (module/map/map.c:277) 11: a:1: ....map_poke } (module/map/map.c:177) 11: a:1: ....sicy_map(addr=0x03000000,size=0x16000) { (module/map/map.c:255) 11: a:1: ....sicy_map(mapped=0x30036000) } (module/map/map.c:267) 11: a:1: ...map_map(mapped=0x30036000) } (module/map/map.c:156) 11: a:1: ..TRLO II init_slow } (module/trloii/trloii.c:442) 11: a:1: .Gsi Vulom init_slow } (module/gsi_vulom/gsi_vulom.c:5) 11: a:1: .Slow module[1]=GSI_VETAR. (crate/crate.c:866) 11: a:1: .Gsi Etherbone init_slow { (module/gsi_etherbone/gsi_etherbone.c:110) 11: a:1: ..Gsi Etherbone init_etherbone { (module/gsi_etherbone/gsi_etherbone.c:293) 11: a:1: ...Address = 0x02000100 (module/gsi_etherbone/gsi_etherbone.c:321) 11: a:1: ...Etherbone FIFO channel = 3 (module/gsi_etherbone/gsi_etherbone.c:330) 11: a:1: ...Etherbone FIFO size = 256 (module/gsi_etherbone/gsi_etherbone.c:335) 11: a:1: ..Gsi Etherbone init_etherbone } (module/gsi_etherbone/gsi_etherbone.c:344) 11: a:1: .Gsi Etherbone init_slow } (module/gsi_etherbone/gsi_etherbone.c:131) 11: a:1: .Slow module[2]=SIS_3316. (crate/crate.c:866) 11: a:1: .sis3316 init_slow { (module/sis_3316/sis_3316.c:1282) 11: a:1: ..map_map(addr=0x30000000,size=0x00400004,mode=noblt,poke=0x0000005c/32) { (module/map/map.c:127) 11: a:1: ...map_poke { (module/map/map.c:171) 11: a:1: ....sicy_map(addr=0x3000005c,size=0x4) { (module/map/map.c:255) 11: a:1: ....sicy_map(mapped=0x3001f05c) } (module/map/map.c:267) 11: a:1: ....Poke reading 0x3001f05c... (module/map/map_sicy_common.c:38) 11: a:1: ....sicy_unmap { (module/map/map.c:275) 11: a:1: ....sicy_unmap } (module/map/map.c:277) 11: a:1: ...map_poke } (module/map/map.c:177) 11: a:1: ...sicy_map(addr=0x30000000,size=0x400004) { (module/map/map.c:255) 11: a:1: ...sicy_map(mapped=0x4a85f000) } (module/map/map.c:267) 11: a:1: ..map_map(mapped=0x4a85f000) } (module/map/map.c:156) 11: a:1: ..map_map(addr=0x30000000,size=0x00500000,mode=blt_2esst,poke=0x0000005c/32) { (module/map/map.c:127) 11: a:1: ...map_poke { (module/map/map.c:171) 11: a:1: ....sicy_map(addr=0x3000005c,size=0x4) { (module/map/map.c:255) 11: a:1: ....sicy_map(mapped=0x3001f05c) } (module/map/map.c:267) 11: a:1: ....Poke reading 0x3001f05c... (module/map/map_sicy_common.c:38) 11: a:1: ....sicy_unmap { (module/map/map.c:275) 11: a:1: ....sicy_unmap } (module/map/map.c:277) 11: a:1: ...map_poke } (module/map/map.c:177) 11: a:1: ...blt_map { (module/map/map.c:32) 11: a:1: ....blt_mode = blt_2esst. (module/map/map.c:37) 11: a:1: ....mapped_ptr = (nil). (module/map/map.c:39) 11: a:1: ....size = 0x00500000. (module/map/map.c:40) 11: a:1: ...blt_map } (module/map/map.c:41) 11: a:1: ..map_map(mapped=(nil)) } (module/map/map.c:156) 11: a:1: ..Data link status: 0x00000000 (module/sis_3316/sis_3316.c:306) 11: a:1: ..ADC 0 status: 0x00130118 (module/sis_3316/sis_3316.c:314) 11: a:1: ..ADC 1 status: 0x00130118 (module/sis_3316/sis_3316.c:314) 11: a:1: ..ADC 2 status: 0x00130118 (module/sis_3316/sis_3316.c:314) 11: a:1: ..ADC 3 status: 0x00130118 (module/sis_3316/sis_3316.c:314) 10: a:1: ..Serial number=0x00800172. (module/sis_3316/sis_3316.c:1305) 10: a:1: ..id/firmware=0x33162010. (module/sis_3316/sis_3316.c:1312) 10: a:1: ..adc[0] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) 11: a:1: ..adc[0] has 16 bits. (module/sis_3316/sis_3316.c:1322) 10: a:1: ..adc[1] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) 11: a:1: ..adc[1] has 16 bits. (module/sis_3316/sis_3316.c:1322) 10: a:1: ..adc[2] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) 11: a:1: ..adc[2] has 16 bits. (module/sis_3316/sis_3316.c:1322) 10: a:1: ..adc[3] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) 11: a:1: ..adc[3] has 16 bits. (module/sis_3316/sis_3316.c:1322) 11: a:1: ..sis3316[2]: Enable external clock (module/sis_3316/sis_3316.c:1344) 11: a:1: ..sis3316[2]: is FPbus master (default). (module/sis_3316/sis_3316.c:1356) 11: a:1: ..sis3316: wait for clock to stabilise (module/sis_3316/sis_3316.c:1373) 8: lwroc_triva_state.c:1951: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2322: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 10: lwroc_triva_state.c:2351: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2411: Node(s) busy in readout, waiting... 11: a:1: ..ADC 0 status: 0x00130118 (module/sis_3316/sis_3316.c:1388) 11: a:1: ..ADC 1 status: 0x00130118 (module/sis_3316/sis_3316.c:1388) 11: a:1: ..ADC 2 status: 0x00130118 (module/sis_3316/sis_3316.c:1388) 11: a:1: ..ADC 3 status: 0x00130118 (module/sis_3316/sis_3316.c:1388) 11: a:1: ..Calibrating IOB logic. (module/sis_3316/sis_3316.c:1393) 8: lwroc_triva_state.c:1951: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2322: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 10: lwroc_triva_state.c:2351: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2411: Node(s) busy in readout, waiting... 11: a:1: ..Base address #0: 0x30000000 (module/sis_3316/sis_3316.c:1413) 11: a:1: ..Header ID #0: 0x30000000 (module/sis_3316/sis_3316.c:1415) 11: a:1: ..Base address #1: 0x30000000 (module/sis_3316/sis_3316.c:1413) 11: a:1: ..Header ID #1: 0x30400000 (module/sis_3316/sis_3316.c:1415) 11: a:1: ..Base address #2: 0x30000000 (module/sis_3316/sis_3316.c:1413) 11: a:1: ..Header ID #2: 0x30800000 (module/sis_3316/sis_3316.c:1415) 11: a:1: ..Base address #3: 0x30000000 (module/sis_3316/sis_3316.c:1413) 11: a:1: ..Header ID #3: 0x30c00000 (module/sis_3316/sis_3316.c:1415) 11: a:1: ..sis3316 memtest { (module/sis_3316/sis_3316.c:1453) 11: a:1: ...n_memtest_bursts = 64 (module/sis_3316/sis_3316.c:1475) 11: a:1: ...adc[0] { (module/sis_3316/sis_3316.c:1502) 11: a:1: ....wrote 4096 bytes in 1665.777992 us. (module/sis_3316/sis_3316.c:1530) 11: a:1: ....read 4096 bytes in 301.246066 us. (module/sis_3316/sis_3316.c:1567) 11: a:1: ...adc[0] } (module/sis_3316/sis_3316.c:1590) 11: a:1: ...adc[1] { (module/sis_3316/sis_3316.c:1502) 11: a:1: ....wrote 4096 bytes in 1654.642634 us. (module/sis_3316/sis_3316.c:1530) 11: a:1: ....read 4096 bytes in 244.532712 us. (module/sis_3316/sis_3316.c:1567) 11: a:1: ...adc[1] } (module/sis_3316/sis_3316.c:1590) 11: a:1: ...adc[2] { (module/sis_3316/sis_3316.c:1502) 11: a:1: ....wrote 4096 bytes in 1660.641748 us. (module/sis_3316/sis_3316.c:1530) 11: a:1: ....read 4096 bytes in 244.725961 us. (module/sis_3316/sis_3316.c:1567) 11: a:1: ...adc[2] } (module/sis_3316/sis_3316.c:1590) 11: a:1: ...adc[3] { (module/sis_3316/sis_3316.c:1502) 11: a:1: ....wrote 4096 bytes in 1651.258674 us. (module/sis_3316/sis_3316.c:1530) 11: a:1: ....read 4096 bytes in 245.541800 us. (module/sis_3316/sis_3316.c:1567) 11: a:1: ...adc[3] } (module/sis_3316/sis_3316.c:1590) 11: a:1: ...passed OK (module/sis_3316/sis_3316.c:1592) 11: a:1: ..sis3316 memtest } (module/sis_3316/sis_3316.c:1593) 11: a:1: .sis3316 init_slow } (module/sis_3316/sis_3316.c:1427) 11: a:1: .Slow module[3]=SIS_3316. (crate/crate.c:866) 11: a:1: .sis3316 init_slow { (module/sis_3316/sis_3316.c:1282) 11: a:1: ..map_map(addr=0x31000000,size=0x00400004,mode=noblt,poke=0x0000005c/32) { (module/map/map.c:127) 11: a:1: ...map_poke { (module/map/map.c:171) 11: a:1: ....sicy_map(addr=0x3100005c,size=0x4) { (module/map/map.c:255) 11: a:1: ....sicy_map(mapped=0x3001f05c) } (module/map/map.c:267) 11: a:1: ....Poke reading 0x3001f05c... (module/map/map_sicy_common.c:38) 11: a:1: ....sicy_unmap { (module/map/map.c:275) 11: a:1: ....sicy_unmap } (module/map/map.c:277) 11: a:1: ...map_poke } (module/map/map.c:177) 11: a:1: ...sicy_map(addr=0x31000000,size=0x400004) { (module/map/map.c:255) 11: a:1: ...sicy_map(mapped=0x4ac61000) } (module/map/map.c:267) 11: a:1: ..map_map(mapped=0x4ac61000) } (module/map/map.c:156) 11: a:1: ..map_map(addr=0x31000000,size=0x00500000,mode=blt_2esst,poke=0x0000005c/32) { (module/map/map.c:127) 11: a:1: ...map_poke { (module/map/map.c:171) 11: a:1: ....sicy_map(addr=0x3100005c,size=0x4) { (module/map/map.c:255) 11: a:1: ....sicy_map(mapped=0x3001f05c) } (module/map/map.c:267) 11: a:1: ....Poke reading 0x3001f05c... (module/map/map_sicy_common.c:38) 11: a:1: ....sicy_unmap { (module/map/map.c:275) 11: a:1: ....sicy_unmap } (module/map/map.c:277) 11: a:1: ...map_poke } (module/map/map.c:177) 11: a:1: ...blt_map { (module/map/map.c:32) 11: a:1: ....blt_mode = blt_2esst. (module/map/map.c:37) 11: a:1: ....mapped_ptr = (nil). (module/map/map.c:39) 11: a:1: ....size = 0x00500000. (module/map/map.c:40) 11: a:1: ...blt_map } (module/map/map.c:41) 11: a:1: ..map_map(mapped=(nil)) } (module/map/map.c:156) 11: a:1: ..Data link status: 0x00000000 (module/sis_3316/sis_3316.c:306) 11: a:1: ..ADC 0 status: 0x00230118 (module/sis_3316/sis_3316.c:314) 11: a:1: ..ADC 1 status: 0x00230118 (module/sis_3316/sis_3316.c:314) 11: a:1: ..ADC 2 status: 0x00230118 (module/sis_3316/sis_3316.c:314) 11: a:1: ..ADC 3 status: 0x00230118 (module/sis_3316/sis_3316.c:314) 10: a:1: ..Serial number=0x00800170. (module/sis_3316/sis_3316.c:1305) 10: a:1: ..id/firmware=0x3316a012. (module/sis_3316/sis_3316.c:1312) 10: a:1: ..adc[0] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) 11: a:1: ..adc[0] has 16 bits. (module/sis_3316/sis_3316.c:1322) 10: a:1: ..adc[1] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) 11: a:1: ..adc[1] has 16 bits. (module/sis_3316/sis_3316.c:1322) 10: a:1: ..adc[2] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) 11: a:1: ..adc[2] has 16 bits. (module/sis_3316/sis_3316.c:1322) 10: a:1: ..adc[3] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) 11: a:1: ..adc[3] has 16 bits. (module/sis_3316/sis_3316.c:1322) 11: a:1: ..sis3316[3]: Enable fp_bus clock (module/sis_3316/sis_3316.c:1344) 11: a:1: ..Setting frequency to 125 MHz (module/sis_3316/sis_3316.c:427) 11: a:1: ..Divider setting = 0x21:c2:bb:8d:6d:4f (module/sis_3316/sis_3316_i2c.c:500) 11: a:1: ..New setting = 0x21:c2:bb:8d:6d:4f (module/sis_3316/sis_3316_i2c.c:511) 11: a:1: ..ADC 0 status: 0x00130118 (module/sis_3316/sis_3316.c:1388) 11: a:1: ..ADC 1 status: 0x00130118 (module/sis_3316/sis_3316.c:1388) 11: a:1: ..ADC 2 status: 0x00130118 (module/sis_3316/sis_3316.c:1388) 11: a:1: ..ADC 3 status: 0x00130118 (module/sis_3316/sis_3316.c:1388) 11: a:1: ..Calibrating IOB logic. (module/sis_3316/sis_3316.c:1393) 8: lwroc_triva_state.c:1951: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2322: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 10: lwroc_triva_state.c:2351: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2411: Node(s) busy in readout, waiting... 11: a:1: ..Base address #0: 0x31000000 (module/sis_3316/sis_3316.c:1413) 11: a:1: ..Header ID #0: 0x31000000 (module/sis_3316/sis_3316.c:1415) 11: a:1: ..Base address #1: 0x31000000 (module/sis_3316/sis_3316.c:1413) 11: a:1: ..Header ID #1: 0x31400000 (module/sis_3316/sis_3316.c:1415) 11: a:1: ..Base address #2: 0x31000000 (module/sis_3316/sis_3316.c:1413) 11: a:1: ..Header ID #2: 0x31800000 (module/sis_3316/sis_3316.c:1415) 11: a:1: ..Base address #3: 0x31000000 (module/sis_3316/sis_3316.c:1413) 11: a:1: ..Header ID #3: 0x31c00000 (module/sis_3316/sis_3316.c:1415) 11: a:1: ..sis3316 memtest { (module/sis_3316/sis_3316.c:1453) 11: a:1: ...n_memtest_bursts = 64 (module/sis_3316/sis_3316.c:1475) 11: a:1: ...adc[0] { (module/sis_3316/sis_3316.c:1502) 11: a:1: ....wrote 4096 bytes in 1646.914985 us. (module/sis_3316/sis_3316.c:1530) 11: a:1: ....read 4096 bytes in 252.311118 us. (module/sis_3316/sis_3316.c:1567) 11: a:1: ...adc[0] } (module/sis_3316/sis_3316.c:1590) 11: a:1: ...adc[1] { (module/sis_3316/sis_3316.c:1502) 11: a:1: ....wrote 4096 bytes in 1647.179015 us. (module/sis_3316/sis_3316.c:1530) 11: a:1: ....read 4096 bytes in 248.158351 us. (module/sis_3316/sis_3316.c:1567) 11: a:1: ...adc[1] } (module/sis_3316/sis_3316.c:1590) 11: a:1: ...adc[2] { (module/sis_3316/sis_3316.c:1502) 11: a:1: ....wrote 4096 bytes in 1650.394872 us. (module/sis_3316/sis_3316.c:1530) 11: a:1: ....read 4096 bytes in 247.198623 us. (module/sis_3316/sis_3316.c:1567) 11: a:1: ...adc[2] } (module/sis_3316/sis_3316.c:1590) 11: a:1: ...adc[3] { (module/sis_3316/sis_3316.c:1502) 11: a:1: ....wrote 4096 bytes in 1640.675124 us. (module/sis_3316/sis_3316.c:1530) 11: a:1: ....read 4096 bytes in 249.454286 us. (module/sis_3316/sis_3316.c:1567) 11: a:1: ...adc[3] } (module/sis_3316/sis_3316.c:1590) 11: a:1: ...passed OK (module/sis_3316/sis_3316.c:1592) 11: a:1: ..sis3316 memtest } (module/sis_3316/sis_3316.c:1593) 11: a:1: .sis3316 init_slow } (module/sis_3316/sis_3316.c:1427) 11: a:1: .Default: max events/trig=1. (crate/crate.c:903) 11: a:1: .Fast module[0]=GSI_VULOM. (crate/crate.c:916) 11: a:1: .Fast module[1]=GSI_VETAR. (crate/crate.c:916) 11: a:1: .Fast module[2]=SIS_3316. (crate/crate.c:916) 11: a:1: .sis3316 init_fast { (module/sis_3316/sis_3316.c:685) 11: a:1: ..sis3316 get_config { (module/sis_3316/sis_3316.c:3138) 11: a:1: ...channels_to_read = mask 0x00000000 (module/sis_3316/sis_3316.c:3148) 11: a:1: ...use_tau_correction = mask 0x00000000 (module/sis_3316/sis_3316.c:3160) 11: a:1: ...use_external_trigger = mask 0x0000ffff (module/sis_3316/sis_3316.c:3166) 11: a:1: ...use_internal_trigger = mask 0x00000000 (module/sis_3316/sis_3316.c:3172) 11: a:1: ...trigger_output = mask 0x00000000 (module/sis_3316/sis_3316.c:3178) 11: a:1: ...use_dual_threshold = mask 0x0000ffff (module/sis_3316/sis_3316.c:3184) 11: a:1: ...use_external_gate = mask 0x00000000. (module/sis_3316/sis_3316.c:3192) 11: a:1: ...use_external_veto = mask 0x00000000. (module/sis_3316/sis_3316.c:3198) 11: a:1: ...discard_data = mask 0x00000000 (module/sis_3316/sis_3316.c:3204) 11: a:1: ...discard_threshold = 0. (module/sis_3316/sis_3316.c:3210) 11: a:1: ...dac_offset[0] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[1] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[2] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[3] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[4] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[5] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[6] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[7] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[8] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[9] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[10] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[11] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[12] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[13] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[14] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[15] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...energy_pickup[0] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[1] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[2] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[3] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[4] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[5] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[6] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[7] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[8] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[9] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[10] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[11] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[12] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[13] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[14] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[15] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...internal_trigger_delay[0] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[1] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[2] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[3] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[4] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[5] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[6] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[7] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[8] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[9] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[10] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[11] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[12] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[13] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[14] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[15] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...use user counter = no. (module/sis_3316/sis_3316.c:3240) 11: a:1: ...use ADC dithering = no. (module/sis_3316/sis_3316.c:3246) 11: a:1: ...use auto bank switch = yes. (module/sis_3316/sis_3316.c:3252) 11: a:1: ...Run mode = SYNC (simple) (module/sis_3316/sis_3316.c:3269) 11: a:1: ...use termination = no. (module/sis_3316/sis_3316.c:3279) 11: a:1: ...average mode[0] = 16 samples (0x 3) (module/sis_3316/sis_3316.c:3315) 11: a:1: ...average pretrigger[0] = 3900 samples (module/sis_3316/sis_3316.c:3318) 11: a:1: ...average length[0] = 16384 samples (module/sis_3316/sis_3316.c:3320) 11: a:1: ...average mode[1] = 16 samples (0x 3) (module/sis_3316/sis_3316.c:3315) 11: a:1: ...average pretrigger[1] = 3900 samples (module/sis_3316/sis_3316.c:3318) 11: a:1: ...average length[1] = 16384 samples (module/sis_3316/sis_3316.c:3320) 11: a:1: ...average mode[2] = 16 samples (0x 3) (module/sis_3316/sis_3316.c:3315) 11: a:1: ...average pretrigger[2] = 3900 samples (module/sis_3316/sis_3316.c:3318) 11: a:1: ...average length[2] = 16384 samples (module/sis_3316/sis_3316.c:3320) 11: a:1: ...average mode[3] = 16 samples (0x 3) (module/sis_3316/sis_3316.c:3315) 11: a:1: ...average pretrigger[3] = 3900 samples (module/sis_3316/sis_3316.c:3318) 11: a:1: ...average length[3] = 16384 samples (module/sis_3316/sis_3316.c:3320) 11: a:1: ...use check_level = paranoid. (module/sis_3316/sis_3316.c:3336) 11: a:1: ...Using BLT mode = 80. (module/sis_3316/sis_3316.c:3343) 11: a:1: ...Sampling clock frequency = 125 MHz. (module/sis_3316/sis_3316.c:3348) 11: a:1: ...External clock frequency = 12 MHz. (module/sis_3316/sis_3316.c:3364) 11: a:1: ...use accumulator 2 = yes. (module/sis_3316/sis_3316.c:3386) 11: a:1: ...use accumulator 6 = yes. (module/sis_3316/sis_3316.c:3392) 11: a:1: ...Use MAW data = no. (module/sis_3316/sis_3316.c:3398) 11: a:1: ...Use max energy = yes. (module/sis_3316/sis_3316.c:3404) 11: a:1: ...use_peak_charge = no. (module/sis_3316/sis_3316.c:3410) 11: a:1: ...write traces raw = no. (module/sis_3316/sis_3316.c:3416) 11: a:1: ...write traces maw = no. (module/sis_3316/sis_3316.c:3422) 11: a:1: ...write traces maw energy = no. (module/sis_3316/sis_3316.c:3428) 11: a:1: ...write histograms = no. (module/sis_3316/sis_3316.c:3434) 11: a:1: ...is FP bus master = yes. (module/sis_3316/sis_3316.c:3440) 11: a:1: ...Baseline average = 64 ns. (module/sis_3316/sis_3316.c:3456) 11: a:1: ...Baseline delay = 32 ns. (module/sis_3316/sis_3316.c:3462) 11: a:1: ...Decaytime[0] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[1] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[2] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[3] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[4] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[5] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[6] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[7] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[8] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[9] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[10] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[11] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[12] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[13] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[14] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[15] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Invert signal = no. (module/sis_3316/sis_3316.c:3484) 11: a:1: ...use_cfd_trigger = yes. (module/sis_3316/sis_3316.c:3490) 11: a:1: ...threshold_mV[0] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[1] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[2] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[3] = 15. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[4] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[5] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[6] = 10. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[7] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[8] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[9] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[10] = 13. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[11] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[12] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[13] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[14] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[15] = 15. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_high_e_mV[0] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[1] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[2] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[3] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[4] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[5] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[6] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[7] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[8] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[9] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[10] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[11] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[12] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[13] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[14] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[15] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...peak[0] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[1] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[2] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[3] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[4] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[5] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[6] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[7] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[8] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[9] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[10] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[11] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[12] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[13] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[14] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[15] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...gap[0] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[1] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[2] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[3] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[4] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[5] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[6] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[7] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[8] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[9] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[10] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[11] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[12] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[13] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[14] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[15] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...peak_e[0] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[1] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[2] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[3] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[4] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[5] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[6] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[7] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[8] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[9] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[10] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[11] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[12] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[13] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[14] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[15] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...gap_e[0] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[1] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[2] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[3] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[4] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[5] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[6] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[7] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[8] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[9] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[10] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[11] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[12] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[13] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[14] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[15] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...sample_length[0] = 8000 ns. (module/sis_3316/sis_3316.c:3557) 11: a:1: ... = 0 ms. (module/sis_3316/sis_3316.c:3559) 11: a:1: ...sample_length[0] = 1000 samples. (module/sis_3316/sis_3316.c:3564) 11: a:1: ...sample_length[1] = 8000 ns. (module/sis_3316/sis_3316.c:3557) 11: a:1: ... = 0 ms. (module/sis_3316/sis_3316.c:3559) 11: a:1: ...sample_length[1] = 1000 samples. (module/sis_3316/sis_3316.c:3564) 11: a:1: ...sample_length[2] = 8000 ns. (module/sis_3316/sis_3316.c:3557) 11: a:1: ... = 0 ms. (module/sis_3316/sis_3316.c:3559) 11: a:1: ...sample_length[2] = 1000 samples. (module/sis_3316/sis_3316.c:3564) 11: a:1: ...sample_length[3] = 8000 ns. (module/sis_3316/sis_3316.c:3557) 11: a:1: ... = 0 ms. (module/sis_3316/sis_3316.c:3559) 11: a:1: ...sample_length[3] = 1000 samples. (module/sis_3316/sis_3316.c:3564) 11: a:1: ...pretrigger_delay[0] = 32500 ns. (module/sis_3316/sis_3316.c:3581) 11: a:1: ...pretrigger_delay[0] = 4062 samples. (module/sis_3316/sis_3316.c:3586) 11: a:1: ...pretrigger_delay[1] = 32500 ns. (module/sis_3316/sis_3316.c:3581) 11: a:1: ...pretrigger_delay[1] = 4062 samples. (module/sis_3316/sis_3316.c:3586) 11: a:1: ...pretrigger_delay[2] = 32500 ns. (module/sis_3316/sis_3316.c:3581) 11: a:1: ...pretrigger_delay[2] = 4062 samples. (module/sis_3316/sis_3316.c:3586) 11: a:1: ...pretrigger_delay[3] = 32500 ns. (module/sis_3316/sis_3316.c:3581) 11: a:1: ...pretrigger_delay[3] = 4062 samples. (module/sis_3316/sis_3316.c:3586) 11: a:1: ...sample_length_maw[0] = 2048. (module/sis_3316/sis_3316.c:3601) 11: a:1: ...sample_length_maw[1] = 2048. (module/sis_3316/sis_3316.c:3601) 11: a:1: ...sample_length_maw[2] = 2048. (module/sis_3316/sis_3316.c:3601) 11: a:1: ...sample_length_maw[3] = 2048. (module/sis_3316/sis_3316.c:3601) 11: a:1: ...pretrigger_delay_maw[0] = 100. (module/sis_3316/sis_3316.c:3610) 11: a:1: ...pretrigger_delay_maw[1] = 100. (module/sis_3316/sis_3316.c:3610) 11: a:1: ...pretrigger_delay_maw[2] = 100. (module/sis_3316/sis_3316.c:3610) 11: a:1: ...pretrigger_delay_maw[3] = 100. (module/sis_3316/sis_3316.c:3610) 11: a:1: ...sample_length_maw_e[0] = 2048. (module/sis_3316/sis_3316.c:3626) 11: a:1: ...sample_length_maw_e[1] = 2048. (module/sis_3316/sis_3316.c:3626) 11: a:1: ...sample_length_maw_e[2] = 2048. (module/sis_3316/sis_3316.c:3626) 11: a:1: ...sample_length_maw_e[3] = 2048. (module/sis_3316/sis_3316.c:3626) 11: a:1: ...pretrigger_delay_maw_e[0] = 100. (module/sis_3316/sis_3316.c:3635) 11: a:1: ...pretrigger_delay_maw_e[1] = 100. (module/sis_3316/sis_3316.c:3635) 11: a:1: ...pretrigger_delay_maw_e[2] = 100. (module/sis_3316/sis_3316.c:3635) 11: a:1: ...pretrigger_delay_maw_e[3] = 100. (module/sis_3316/sis_3316.c:3635) 11: a:1: ...gate[0].delay = 1024 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[0].width = 2048 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[1].delay = 65000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[1].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[2].delay = 130000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[2].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[3].delay = 195000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[3].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[4].delay = 260000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[4].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[5].delay = 325000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[5].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[6].delay = 390000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[6].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[7].delay = 455000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[7].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ..sis3316 get_config } (module/sis_3316/sis_3316.c:3668) 11: a:1: ..sis3316 calculate_settings { (module/sis_3316/sis_3316.c:3726) 11: a:1: ...samples_per_ns = 8 (module/sis_3316/sis_3316.c:3730) 11: a:1: ...decaytime_s[0] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[0] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[1] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[1] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[2] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[2] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[3] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[3] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[4] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[4] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[5] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[5] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[6] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[6] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[7] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[7] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[8] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[8] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[9] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[9] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[10] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[10] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[11] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[11] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[12] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[12] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[13] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[13] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[14] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[14] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[15] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[15] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...adc 0, pileup_len = 1250, repileup_len = 1250 (module/sis_3316/sis_3316.c:3761) 11: a:1: ...adc 1, pileup_len = 1250, repileup_len = 1250 (module/sis_3316/sis_3316.c:3761) 11: a:1: ...adc 2, pileup_len = 1250, repileup_len = 1250 (module/sis_3316/sis_3316.c:3761) 11: a:1: ...adc 3, pileup_len = 1250, repileup_len = 1250 (module/sis_3316/sis_3316.c:3761) 11: a:1: ...trigger_gate_window_length[0]=62498 (calc) (module/sis_3316/sis_3316.c:3835) 11: a:1: ...trigger_gate_window_length[1]=62498 (calc) (module/sis_3316/sis_3316.c:3835) 11: a:1: ...trigger_gate_window_length[2]=62498 (calc) (module/sis_3316/sis_3316.c:3835) 11: a:1: ...trigger_gate_window_length[3]=62498 (calc) (module/sis_3316/sis_3316.c:3835) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...histogram_divider[0] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[1] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[2] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[3] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[4] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[5] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[6] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[7] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[8] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[9] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[10] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[11] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[12] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[13] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[14] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[15] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...threshold[0] = 8 mV -> 0x0800d012 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[1] = 8 mV -> 0x0800d012 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[2] = 8 mV -> 0x0800d012 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[3] = 15 mV -> 0x08018623 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[4] = 8 mV -> 0x0800d012 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[5] = 8 mV -> 0x0800d012 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[6] = 10 mV -> 0x08010417 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[7] = 8 mV -> 0x0800d012 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[8] = 8 mV -> 0x0800d012 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[9] = 8 mV -> 0x0800d012 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[10] = 13 mV -> 0x0801521e (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[11] = 8 mV -> 0x0800d012 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[12] = 8 mV -> 0x0800d012 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[13] = 8 mV -> 0x0800d012 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[14] = 8 mV -> 0x0800d012 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[15] = 15 mV -> 0x08018623 (module/sis_3316/sis_3316.c:3944) 11: a:1: ..sis3316 calculate_settings } (module/sis_3316/sis_3316.c:3949) 11: a:1: ..DAC offset 0 = 82080000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 1 = 82180000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 2 = 82280000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 3 = 82380000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 4 = 82080000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 5 = 82180000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 6 = 82280000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 7 = 82380000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 8 = 82080000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 9 = 82180000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 10 = 82280000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 11 = 82380000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 12 = 82080000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 13 = 82180000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 14 = 82280000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 15 = 82380000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..Tap delay ADC 0: 0x00001320 (module/sis_3316/sis_3316.c:362) 11: a:1: ..Tap delay ADC 1: 0x00001320 (module/sis_3316/sis_3316.c:362) 11: a:1: ..Tap delay ADC 2: 0x00001320 (module/sis_3316/sis_3316.c:362) 11: a:1: ..Tap delay ADC 3: 0x00001320 (module/sis_3316/sis_3316.c:362) 11: a:1: ..Setting gain/termination. (module/sis_3316/sis_3316.c:720) 11: a:1: ..Gain & termination = 04040404 (module/sis_3316/sis_3316.c:742) 11: a:1: ..Gain & termination = 04040404 (module/sis_3316/sis_3316.c:742) 11: a:1: ..Gain & termination = 04040404 (module/sis_3316/sis_3316.c:742) 11: a:1: ..Gain & termination = 04040404 (module/sis_3316/sis_3316.c:742) 11: a:1: ..T gap 0= 0xfe 4= 0xfe 8= 0xfe 12= 0xfe (module/sis_3316/sis_3316.c:783) 11: a:1: ..T peak 0= 0xfe 4= 0xfe 8= 0xfe 12= 0xfe (module/sis_3316/sis_3316.c:789) 11: a:1: ..T gap 1= 0xfe 5= 0xfe 9= 0xfe 13= 0xfe (module/sis_3316/sis_3316.c:783) 11: a:1: ..T peak 1= 0xfe 5= 0xfe 9= 0xfe 13= 0xfe (module/sis_3316/sis_3316.c:789) 11: a:1: ..T gap 2= 0xfe 6= 0xfe 10= 0xfe 14= 0xfe (module/sis_3316/sis_3316.c:783) 11: a:1: ..T peak 2= 0xfe 6= 0xfe 10= 0xfe 14= 0xfe (module/sis_3316/sis_3316.c:789) 11: a:1: ..T gap 3= 0xfe 7= 0xfe 11= 0xfe 15= 0xfe (module/sis_3316/sis_3316.c:783) 11: a:1: ..T peak 3= 0xfe 7= 0xfe 11= 0xfe 15= 0xfe (module/sis_3316/sis_3316.c:789) 11: a:1: ..Threshold 0 = 0xb800d012 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 1 = 0xb800d012 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 2 = 0xb800d012 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 3 = 0xb8018623 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 4 = 0xb800d012 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 5 = 0xb800d012 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 6 = 0xb8010417 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 7 = 0xb800d012 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 8 = 0xb800d012 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 9 = 0xb800d012 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 10 = 0xb801521e (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 11 = 0xb800d012 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 12 = 0xb800d012 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 13 = 0xb800d012 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 14 = 0xb800d012 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 15 = 0xb8018623 (module/sis_3316/sis_3316.c:815) 11: a:1: ..energy_pickup[00] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[01] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[02] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[03] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[04] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[05] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[06] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[07] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[08] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[09] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[10] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[11] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[12] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[13] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[14] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[15] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..fir_energy_setup[00] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..fir_energy_setup[01] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..fir_energy_setup[02] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..fir_energy_setup[03] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..Gap time E 0= 0x1f4 1= 0x1f4 2= 0x1f4 3= 0x1f4 (module/sis_3316/sis_3316.c:840) 11: a:1: ..Peak time E 0= 0x1f4 1= 0x1f4 2= 0x1f4 3= 0x1f4 (module/sis_3316/sis_3316.c:847) 11: a:1: ..Tau config 0= 0,0 1= 0,0 2= 0,0 3= 0,0 (module/sis_3316/sis_3316.c:854) 11: a:1: ..fir_energy_setup[04] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..fir_energy_setup[05] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..fir_energy_setup[06] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..fir_energy_setup[07] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..Gap time E 4= 0x1f4 5= 0x1f4 6= 0x1f4 7= 0x1f4 (module/sis_3316/sis_3316.c:840) 11: a:1: ..Peak time E 4= 0x1f4 5= 0x1f4 6= 0x1f4 7= 0x1f4 (module/sis_3316/sis_3316.c:847) 11: a:1: ..Tau config 4= 0,0 5= 0,0 6= 0,0 7= 0,0 (module/sis_3316/sis_3316.c:854) 11: a:1: ..fir_energy_setup[08] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..fir_energy_setup[09] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..fir_energy_setup[10] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..fir_energy_setup[11] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..Gap time E 8= 0x1f4 9= 0x1f4 10= 0x1f4 11= 0x1f4 (module/sis_3316/sis_3316.c:840) 11: a:1: ..Peak time E 8= 0x1f4 9= 0x1f4 10= 0x1f4 11= 0x1f4 (module/sis_3316/sis_3316.c:847) 11: a:1: ..Tau config 8= 0,0 9= 0,0 10= 0,0 11= 0,0 (module/sis_3316/sis_3316.c:854) 11: a:1: ..fir_energy_setup[12] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..fir_energy_setup[13] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..fir_energy_setup[14] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..fir_energy_setup[15] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..Gap time E 12= 0x1f4 13= 0x1f4 14= 0x1f4 15= 0x1f4 (module/sis_3316/sis_3316.c:840) 11: a:1: ..Peak time E 12= 0x1f4 13= 0x1f4 14= 0x1f4 15= 0x1f4 (module/sis_3316/sis_3316.c:847) 11: a:1: ..Tau config 12= 0,0 13= 0,0 14= 0,0 15= 0,0 (module/sis_3316/sis_3316.c:854) 11: a:1: ..Sample Length [0] = 0 samples (module/sis_3316/sis_3316.c:924) 11: a:1: ..trigger_gate_window_length[0] = 62498 (module/sis_3316/sis_3316.c:926) 11: a:1: ..Sample Length [1] = 0 samples (module/sis_3316/sis_3316.c:924) 11: a:1: ..trigger_gate_window_length[1] = 62498 (module/sis_3316/sis_3316.c:926) 11: a:1: ..Sample Length [2] = 0 samples (module/sis_3316/sis_3316.c:924) 11: a:1: ..trigger_gate_window_length[2] = 62498 (module/sis_3316/sis_3316.c:926) 11: a:1: ..Sample Length [3] = 0 samples (module/sis_3316/sis_3316.c:924) 11: a:1: ..trigger_gate_window_length[3] = 62498 (module/sis_3316/sis_3316.c:926) 11: a:1: ..ADC[0] Gate0 = (width = 255, delay = 128) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[0] Gate1 = (width = 511, delay = 8125) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[0] Gate2 = (width = 511, delay = 16250) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[0] Gate3 = (width = 511, delay = 24375) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[0] Gate4 = (width = 511, delay = 32500) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[0] Gate5 = (width = 511, delay = 40625) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[1] Gate0 = (width = 255, delay = 128) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[1] Gate1 = (width = 511, delay = 8125) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[1] Gate2 = (width = 511, delay = 16250) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[1] Gate3 = (width = 511, delay = 24375) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[1] Gate4 = (width = 511, delay = 32500) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[1] Gate5 = (width = 511, delay = 40625) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[2] Gate0 = (width = 255, delay = 128) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[2] Gate1 = (width = 511, delay = 8125) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[2] Gate2 = (width = 511, delay = 16250) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[2] Gate3 = (width = 511, delay = 24375) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[2] Gate4 = (width = 511, delay = 32500) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[2] Gate5 = (width = 511, delay = 40625) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[3] Gate0 = (width = 255, delay = 128) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[3] Gate1 = (width = 511, delay = 8125) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[3] Gate2 = (width = 511, delay = 16250) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[3] Gate3 = (width = 511, delay = 24375) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[3] Gate4 = (width = 511, delay = 32500) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[3] Gate5 = (width = 511, delay = 40625) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[0] Gate6 = (width = 511, delay = 48750) (module/sis_3316/sis_3316.c:973) 11: a:1: ..ADC[0] Gate7 = (width = 511, delay = 56875) (module/sis_3316/sis_3316.c:973) 11: a:1: ..ADC[1] Gate6 = (width = 511, delay = 48750) (module/sis_3316/sis_3316.c:973) 11: a:1: ..ADC[1] Gate7 = (width = 511, delay = 56875) (module/sis_3316/sis_3316.c:973) 11: a:1: ..ADC[2] Gate6 = (width = 511, delay = 48750) (module/sis_3316/sis_3316.c:973) 11: a:1: ..ADC[2] Gate7 = (width = 511, delay = 56875) (module/sis_3316/sis_3316.c:973) 11: a:1: ..ADC[3] Gate6 = (width = 511, delay = 48750) (module/sis_3316/sis_3316.c:973) 11: a:1: ..ADC[3] Gate7 = (width = 511, delay = 56875) (module/sis_3316/sis_3316.c:973) 11: a:1: ..ADC[0] internal_delay = 0x00000000 (module/sis_3316/sis_3316.c:993) 11: a:1: ..ADC[1] internal_delay = 0x00000000 (module/sis_3316/sis_3316.c:993) 11: a:1: ..ADC[2] internal_delay = 0x00000000 (module/sis_3316/sis_3316.c:993) 11: a:1: ..ADC[3] internal_delay = 0x00000000 (module/sis_3316/sis_3316.c:993) 11: a:1: ..Pretrigger delay 0= 4062 1= 4062 2= 4062 3= 4062 (module/sis_3316/sis_3316.c:1014) 11: a:1: ..Setting TI as trigger/gate input. (module/sis_3316/sis_3316.c:1049) 11: a:1: ..UO as sampling active flag. (module/sis_3316/sis_3316.c:1115) 11: a:1: ..Event = 0x08080808 0x08080808 0x08080808 0x08080808 (module/sis_3316/sis_3316.c:567) 11: a:1: ..Data format = 0x0b0b0b0b (module/sis_3316/sis_3316.c:639) 11: a:1: ..Event length 0 = 8206 (raw=0,avg=8192,maw=0) (module/sis_3316/sis_3316.c:648) 11: a:1: ..Maw buffer setup[0] = 0x00640000 (module/sis_3316/sis_3316.c:664) 11: a:1: ..Event length 1 = 8206 (raw=0,avg=8192,maw=0) (module/sis_3316/sis_3316.c:648) 11: a:1: ..Maw buffer setup[1] = 0x00640000 (module/sis_3316/sis_3316.c:664) 11: a:1: ..Event length 2 = 8206 (raw=0,avg=8192,maw=0) (module/sis_3316/sis_3316.c:648) 11: a:1: ..Maw buffer setup[2] = 0x00640000 (module/sis_3316/sis_3316.c:664) 11: a:1: ..Event length 3 = 8206 (raw=0,avg=8192,maw=0) (module/sis_3316/sis_3316.c:648) 11: a:1: ..Maw buffer setup[3] = 0x00640000 (module/sis_3316/sis_3316.c:664) 11: a:1: ..Average mode setup[0] = 0x3f3c4000 (module/sis_3316/sis_3316.c:587) 11: a:1: ..Average mode setup[1] = 0x3f3c4000 (module/sis_3316/sis_3316.c:587) 11: a:1: ..Average mode setup[2] = 0x3f3c4000 (module/sis_3316/sis_3316.c:587) 11: a:1: ..Average mode setup[3] = 0x3f3c4000 (module/sis_3316/sis_3316.c:587) 11: a:1: ..Configured num_hits per channel 1 (module/sis_3316/sis_3316.c:1151) 11: a:1: ..Restricting number of hits to 0 (module/sis_3316/sis_3316.c:1181) 11: a:1: ..Maximum possible number of hits 0 (module/sis_3316/sis_3316.c:1194) 11: a:1: ..Using at most 0 bytes per readout (module/sis_3316/sis_3316.c:1196) 11: a:1: ..Channels enabled: 0 (module/sis_3316/sis_3316.c:1197) 11: a:1: ..[2] Adjusting num hits to: 1 (module/sis_3316/sis_3316.c:2353) 11: a:1: ..May discard data for channels: 00000000 (module/sis_3316/sis_3316.c:1252) 11: a:1: .sis3316 init_fast } (module/sis_3316/sis_3316.c:1257) 11: a:1: .Fast module[3]=SIS_3316. (crate/crate.c:916) 11: a:1: .sis3316 init_fast { (module/sis_3316/sis_3316.c:685) 11: a:1: ..sis3316 get_config { (module/sis_3316/sis_3316.c:3138) 11: a:1: ...channels_to_read = mask 0x0000ffff (module/sis_3316/sis_3316.c:3148) 11: a:1: ...use_tau_correction = mask 0x00000000 (module/sis_3316/sis_3316.c:3160) 11: a:1: ...use_external_trigger = mask 0x0000ffff (module/sis_3316/sis_3316.c:3166) 11: a:1: ...use_internal_trigger = mask 0x00000000 (module/sis_3316/sis_3316.c:3172) 11: a:1: ...trigger_output = mask 0x00000000 (module/sis_3316/sis_3316.c:3178) 11: a:1: ...use_dual_threshold = mask 0x0000ffff (module/sis_3316/sis_3316.c:3184) 11: a:1: ...use_external_gate = mask 0x00000000. (module/sis_3316/sis_3316.c:3192) 11: a:1: ...use_external_veto = mask 0x00000000. (module/sis_3316/sis_3316.c:3198) 11: a:1: ...discard_data = mask 0x00000000 (module/sis_3316/sis_3316.c:3204) 11: a:1: ...discard_threshold = 0. (module/sis_3316/sis_3316.c:3210) 11: a:1: ...dac_offset[0] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[1] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[2] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[3] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[4] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[5] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[6] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[7] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[8] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[9] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[10] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[11] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[12] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[13] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[14] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...dac_offset[15] = 0. (module/sis_3316/sis_3316.c:3217) 11: a:1: ...energy_pickup[0] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[1] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[2] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[3] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[4] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[5] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[6] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[7] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[8] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[9] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[10] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[11] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[12] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[13] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[14] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...energy_pickup[15] = 0. (module/sis_3316/sis_3316.c:3225) 11: a:1: ...internal_trigger_delay[0] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[1] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[2] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[3] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[4] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[5] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[6] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[7] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[8] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[9] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[10] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[11] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[12] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[13] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[14] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...internal_trigger_delay[15] = 0 ns. (module/sis_3316/sis_3316.c:3233) 11: a:1: ...use user counter = no. (module/sis_3316/sis_3316.c:3240) 11: a:1: ...use ADC dithering = no. (module/sis_3316/sis_3316.c:3246) 11: a:1: ...use auto bank switch = yes. (module/sis_3316/sis_3316.c:3252) 11: a:1: ...Run mode = SYNC (simple) (module/sis_3316/sis_3316.c:3269) 11: a:1: ...use termination = no. (module/sis_3316/sis_3316.c:3279) 11: a:1: ...average mode[0] = 16 samples (0x 3) (module/sis_3316/sis_3316.c:3315) 11: a:1: ...average pretrigger[0] = 3900 samples (module/sis_3316/sis_3316.c:3318) 11: a:1: ...average length[0] = 16384 samples (module/sis_3316/sis_3316.c:3320) 11: a:1: ...average mode[1] = 16 samples (0x 3) (module/sis_3316/sis_3316.c:3315) 11: a:1: ...average pretrigger[1] = 3900 samples (module/sis_3316/sis_3316.c:3318) 11: a:1: ...average length[1] = 16384 samples (module/sis_3316/sis_3316.c:3320) 11: a:1: ...average mode[2] = 16 samples (0x 3) (module/sis_3316/sis_3316.c:3315) 11: a:1: ...average pretrigger[2] = 3900 samples (module/sis_3316/sis_3316.c:3318) 11: a:1: ...average length[2] = 16384 samples (module/sis_3316/sis_3316.c:3320) 11: a:1: ...average mode[3] = 16 samples (0x 3) (module/sis_3316/sis_3316.c:3315) 11: a:1: ...average pretrigger[3] = 3900 samples (module/sis_3316/sis_3316.c:3318) 11: a:1: ...average length[3] = 16384 samples (module/sis_3316/sis_3316.c:3320) 11: a:1: ...use check_level = paranoid. (module/sis_3316/sis_3316.c:3336) 11: a:1: ...Using BLT mode = 80. (module/sis_3316/sis_3316.c:3343) 11: a:1: ...Sampling clock frequency = 125 MHz. (module/sis_3316/sis_3316.c:3348) 11: a:1: ...External clock frequency = 0 MHz. (module/sis_3316/sis_3316.c:3364) 11: a:1: ...use accumulator 2 = yes. (module/sis_3316/sis_3316.c:3386) 11: a:1: ...use accumulator 6 = yes. (module/sis_3316/sis_3316.c:3392) 11: a:1: ...Use MAW data = no. (module/sis_3316/sis_3316.c:3398) 11: a:1: ...Use max energy = yes. (module/sis_3316/sis_3316.c:3404) 11: a:1: ...use_peak_charge = no. (module/sis_3316/sis_3316.c:3410) 11: a:1: ...write traces raw = no. (module/sis_3316/sis_3316.c:3416) 11: a:1: ...write traces maw = no. (module/sis_3316/sis_3316.c:3422) 11: a:1: ...write traces maw energy = no. (module/sis_3316/sis_3316.c:3428) 11: a:1: ...write histograms = no. (module/sis_3316/sis_3316.c:3434) 11: a:1: ...is FP bus master = no. (module/sis_3316/sis_3316.c:3440) 11: a:1: ...Baseline average = 64 ns. (module/sis_3316/sis_3316.c:3456) 11: a:1: ...Baseline delay = 32 ns. (module/sis_3316/sis_3316.c:3462) 11: a:1: ...Decaytime[0] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[1] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[2] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[3] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[4] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[5] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[6] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[7] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[8] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[9] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[10] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[11] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[12] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[13] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[14] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Decaytime[15] = 2000. (module/sis_3316/sis_3316.c:3473) 11: a:1: ...Invert signal = no. (module/sis_3316/sis_3316.c:3484) 11: a:1: ...use_cfd_trigger = yes. (module/sis_3316/sis_3316.c:3490) 11: a:1: ...threshold_mV[0] = 10. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[1] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[2] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[3] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[4] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[5] = 10. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[6] = 13. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[7] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[8] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[9] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[10] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[11] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[12] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[13] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[14] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_mV[15] = 8. (module/sis_3316/sis_3316.c:3497) 11: a:1: ...threshold_high_e_mV[0] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[1] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[2] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[3] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[4] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[5] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[6] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[7] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[8] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[9] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[10] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[11] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[12] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[13] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[14] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...threshold_high_e_mV[15] = 2000. (module/sis_3316/sis_3316.c:3505) 11: a:1: ...peak[0] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[1] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[2] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[3] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[4] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[5] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[6] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[7] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[8] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[9] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[10] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[11] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[12] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[13] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[14] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...peak[15] = 254. (module/sis_3316/sis_3316.c:3513) 11: a:1: ...gap[0] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[1] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[2] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[3] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[4] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[5] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[6] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[7] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[8] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[9] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[10] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[11] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[12] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[13] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[14] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...gap[15] = 254. (module/sis_3316/sis_3316.c:3521) 11: a:1: ...peak_e[0] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[1] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[2] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[3] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[4] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[5] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[6] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[7] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[8] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[9] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[10] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[11] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[12] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[13] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[14] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...peak_e[15] = 500. (module/sis_3316/sis_3316.c:3529) 11: a:1: ...gap_e[0] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[1] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[2] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[3] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[4] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[5] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[6] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[7] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[8] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[9] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[10] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[11] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[12] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[13] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[14] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...gap_e[15] = 500. (module/sis_3316/sis_3316.c:3537) 11: a:1: ...sample_length[0] = 8000 ns. (module/sis_3316/sis_3316.c:3557) 11: a:1: ... = 0 ms. (module/sis_3316/sis_3316.c:3559) 11: a:1: ...sample_length[0] = 1000 samples. (module/sis_3316/sis_3316.c:3564) 11: a:1: ...sample_length[1] = 8000 ns. (module/sis_3316/sis_3316.c:3557) 11: a:1: ... = 0 ms. (module/sis_3316/sis_3316.c:3559) 11: a:1: ...sample_length[1] = 1000 samples. (module/sis_3316/sis_3316.c:3564) 11: a:1: ...sample_length[2] = 8000 ns. (module/sis_3316/sis_3316.c:3557) 11: a:1: ... = 0 ms. (module/sis_3316/sis_3316.c:3559) 11: a:1: ...sample_length[2] = 1000 samples. (module/sis_3316/sis_3316.c:3564) 11: a:1: ...sample_length[3] = 8000 ns. (module/sis_3316/sis_3316.c:3557) 11: a:1: ... = 0 ms. (module/sis_3316/sis_3316.c:3559) 11: a:1: ...sample_length[3] = 1000 samples. (module/sis_3316/sis_3316.c:3564) 11: a:1: ...pretrigger_delay[0] = 32500 ns. (module/sis_3316/sis_3316.c:3581) 11: a:1: ...pretrigger_delay[0] = 4062 samples. (module/sis_3316/sis_3316.c:3586) 11: a:1: ...pretrigger_delay[1] = 32500 ns. (module/sis_3316/sis_3316.c:3581) 11: a:1: ...pretrigger_delay[1] = 4062 samples. (module/sis_3316/sis_3316.c:3586) 11: a:1: ...pretrigger_delay[2] = 32500 ns. (module/sis_3316/sis_3316.c:3581) 11: a:1: ...pretrigger_delay[2] = 4062 samples. (module/sis_3316/sis_3316.c:3586) 11: a:1: ...pretrigger_delay[3] = 32500 ns. (module/sis_3316/sis_3316.c:3581) 11: a:1: ...pretrigger_delay[3] = 4062 samples. (module/sis_3316/sis_3316.c:3586) 11: a:1: ...sample_length_maw[0] = 2048. (module/sis_3316/sis_3316.c:3601) 11: a:1: ...sample_length_maw[1] = 2048. (module/sis_3316/sis_3316.c:3601) 11: a:1: ...sample_length_maw[2] = 2048. (module/sis_3316/sis_3316.c:3601) 11: a:1: ...sample_length_maw[3] = 2048. (module/sis_3316/sis_3316.c:3601) 11: a:1: ...pretrigger_delay_maw[0] = 100. (module/sis_3316/sis_3316.c:3610) 11: a:1: ...pretrigger_delay_maw[1] = 100. (module/sis_3316/sis_3316.c:3610) 11: a:1: ...pretrigger_delay_maw[2] = 100. (module/sis_3316/sis_3316.c:3610) 11: a:1: ...pretrigger_delay_maw[3] = 100. (module/sis_3316/sis_3316.c:3610) 11: a:1: ...sample_length_maw_e[0] = 2048. (module/sis_3316/sis_3316.c:3626) 11: a:1: ...sample_length_maw_e[1] = 2048. (module/sis_3316/sis_3316.c:3626) 11: a:1: ...sample_length_maw_e[2] = 2048. (module/sis_3316/sis_3316.c:3626) 11: a:1: ...sample_length_maw_e[3] = 2048. (module/sis_3316/sis_3316.c:3626) 11: a:1: ...pretrigger_delay_maw_e[0] = 100. (module/sis_3316/sis_3316.c:3635) 11: a:1: ...pretrigger_delay_maw_e[1] = 100. (module/sis_3316/sis_3316.c:3635) 11: a:1: ...pretrigger_delay_maw_e[2] = 100. (module/sis_3316/sis_3316.c:3635) 11: a:1: ...pretrigger_delay_maw_e[3] = 100. (module/sis_3316/sis_3316.c:3635) 11: a:1: ...gate[0].delay = 1024 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[0].width = 2048 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[1].delay = 65000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[1].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[2].delay = 130000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[2].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[3].delay = 195000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[3].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[4].delay = 260000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[4].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[5].delay = 325000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[5].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[6].delay = 390000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[6].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ...gate[7].delay = 455000 ns. (module/sis_3316/sis_3316.c:3653) 11: a:1: ...gate[7].width = 4096 ns. (module/sis_3316/sis_3316.c:3661) 11: a:1: ..sis3316 get_config } (module/sis_3316/sis_3316.c:3668) 11: a:1: ..sis3316 calculate_settings { (module/sis_3316/sis_3316.c:3726) 11: a:1: ...samples_per_ns = 8 (module/sis_3316/sis_3316.c:3730) 11: a:1: ...decaytime_s[0] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[0] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[1] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[1] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[2] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[2] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[3] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[3] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[4] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[4] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[5] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[5] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[6] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[6] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[7] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[7] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[8] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[8] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[9] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[9] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[10] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[10] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[11] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[11] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[12] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[12] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[13] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[13] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[14] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[14] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...decaytime_s[15] = 250 (module/sis_3316/sis_3316.c:3744) 11: a:1: ...signal_length_s[15] = 1250 (module/sis_3316/sis_3316.c:3746) 11: a:1: ...adc 0, pileup_len = 1250, repileup_len = 1250 (module/sis_3316/sis_3316.c:3761) 11: a:1: ...adc 1, pileup_len = 1250, repileup_len = 1250 (module/sis_3316/sis_3316.c:3761) 11: a:1: ...adc 2, pileup_len = 1250, repileup_len = 1250 (module/sis_3316/sis_3316.c:3761) 11: a:1: ...adc 3, pileup_len = 1250, repileup_len = 1250 (module/sis_3316/sis_3316.c:3761) 11: a:1: ...trigger_gate_window_length[0]=62498 (calc) (module/sis_3316/sis_3316.c:3835) 11: a:1: ...trigger_gate_window_length[1]=62498 (calc) (module/sis_3316/sis_3316.c:3835) 11: a:1: ...trigger_gate_window_length[2]=62498 (calc) (module/sis_3316/sis_3316.c:3835) 11: a:1: ...trigger_gate_window_length[3]=62498 (calc) (module/sis_3316/sis_3316.c:3835) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...Setting tau table to 0. (module/sis_3316/sis_3316.c:3851) 11: a:1: ...histogram_divider[0] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[1] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[2] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[3] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[4] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[5] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[6] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[7] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[8] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[9] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[10] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[11] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[12] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[13] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[14] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...histogram_divider[15] = 390 (module/sis_3316/sis_3316.c:3921) 11: a:1: ...threshold[0] = 10 mV -> 0x08010417 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[1] = 8 mV -> 0x0800d012 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[2] = 8 mV -> 0x0800d012 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[3] = 8 mV -> 0x0800d012 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[4] = 8 mV -> 0x0800d012 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[5] = 10 mV -> 0x08010417 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[6] = 13 mV -> 0x0801521e (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[7] = 8 mV -> 0x0800d012 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[8] = 8 mV -> 0x0800d012 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[9] = 8 mV -> 0x0800d012 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[10] = 8 mV -> 0x0800d012 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[11] = 8 mV -> 0x0800d012 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[12] = 8 mV -> 0x0800d012 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[13] = 8 mV -> 0x0800d012 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[14] = 8 mV -> 0x0800d012 (module/sis_3316/sis_3316.c:3944) 11: a:1: ...threshold[15] = 8 mV -> 0x0800d012 (module/sis_3316/sis_3316.c:3944) 11: a:1: ..sis3316 calculate_settings } (module/sis_3316/sis_3316.c:3949) 11: a:1: ..DAC offset 0 = 82080000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 1 = 82180000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 2 = 82280000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 3 = 82380000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 4 = 82080000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 5 = 82180000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 6 = 82280000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 7 = 82380000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 8 = 82080000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 9 = 82180000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 10 = 82280000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 11 = 82380000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 12 = 82080000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 13 = 82180000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 14 = 82280000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..DAC offset 15 = 82380000 (module/sis_3316/sis_3316.c:458) 11: a:1: ..Tap delay ADC 0: 0x00001320 (module/sis_3316/sis_3316.c:362) 11: a:1: ..Tap delay ADC 1: 0x00001320 (module/sis_3316/sis_3316.c:362) 11: a:1: ..Tap delay ADC 2: 0x00001320 (module/sis_3316/sis_3316.c:362) 11: a:1: ..Tap delay ADC 3: 0x00001320 (module/sis_3316/sis_3316.c:362) 11: a:1: ..Setting gain/termination. (module/sis_3316/sis_3316.c:720) 11: a:1: ..Gain & termination = 04040404 (module/sis_3316/sis_3316.c:742) 11: a:1: ..Gain & termination = 04040404 (module/sis_3316/sis_3316.c:742) 11: a:1: ..Gain & termination = 04040404 (module/sis_3316/sis_3316.c:742) 11: a:1: ..Gain & termination = 04040404 (module/sis_3316/sis_3316.c:742) 11: a:1: ..T gap 0= 0xfe 4= 0xfe 8= 0xfe 12= 0xfe (module/sis_3316/sis_3316.c:783) 11: a:1: ..T peak 0= 0xfe 4= 0xfe 8= 0xfe 12= 0xfe (module/sis_3316/sis_3316.c:789) 11: a:1: ..T gap 1= 0xfe 5= 0xfe 9= 0xfe 13= 0xfe (module/sis_3316/sis_3316.c:783) 11: a:1: ..T peak 1= 0xfe 5= 0xfe 9= 0xfe 13= 0xfe (module/sis_3316/sis_3316.c:789) 11: a:1: ..T gap 2= 0xfe 6= 0xfe 10= 0xfe 14= 0xfe (module/sis_3316/sis_3316.c:783) 11: a:1: ..T peak 2= 0xfe 6= 0xfe 10= 0xfe 14= 0xfe (module/sis_3316/sis_3316.c:789) 11: a:1: ..T gap 3= 0xfe 7= 0xfe 11= 0xfe 15= 0xfe (module/sis_3316/sis_3316.c:783) 11: a:1: ..T peak 3= 0xfe 7= 0xfe 11= 0xfe 15= 0xfe (module/sis_3316/sis_3316.c:789) 11: a:1: ..Threshold 0 = 0xb8010417 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 1 = 0xb800d012 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 2 = 0xb800d012 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 3 = 0xb800d012 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 4 = 0xb800d012 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 5 = 0xb8010417 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 6 = 0xb801521e (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 7 = 0xb800d012 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 8 = 0xb800d012 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 9 = 0xb800d012 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 10 = 0xb800d012 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 11 = 0xb800d012 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 12 = 0xb800d012 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 13 = 0xb800d012 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 14 = 0xb800d012 (module/sis_3316/sis_3316.c:815) 11: a:1: ..Threshold 15 = 0xb800d012 (module/sis_3316/sis_3316.c:815) 11: a:1: ..energy_pickup[00] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[01] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[02] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[03] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[04] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[05] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[06] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[07] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[08] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[09] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[10] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[11] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[12] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[13] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[14] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..energy_pickup[15] = 00000000 (module/sis_3316/sis_3316.c:825) 11: a:1: ..fir_energy_setup[00] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..fir_energy_setup[01] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..fir_energy_setup[02] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..fir_energy_setup[03] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..Gap time E 0= 0x1f4 1= 0x1f4 2= 0x1f4 3= 0x1f4 (module/sis_3316/sis_3316.c:840) 11: a:1: ..Peak time E 0= 0x1f4 1= 0x1f4 2= 0x1f4 3= 0x1f4 (module/sis_3316/sis_3316.c:847) 11: a:1: ..Tau config 0= 0,0 1= 0,0 2= 0,0 3= 0,0 (module/sis_3316/sis_3316.c:854) 11: a:1: ..fir_energy_setup[04] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..fir_energy_setup[05] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..fir_energy_setup[06] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..fir_energy_setup[07] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..Gap time E 4= 0x1f4 5= 0x1f4 6= 0x1f4 7= 0x1f4 (module/sis_3316/sis_3316.c:840) 11: a:1: ..Peak time E 4= 0x1f4 5= 0x1f4 6= 0x1f4 7= 0x1f4 (module/sis_3316/sis_3316.c:847) 11: a:1: ..Tau config 4= 0,0 5= 0,0 6= 0,0 7= 0,0 (module/sis_3316/sis_3316.c:854) 11: a:1: ..fir_energy_setup[08] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..fir_energy_setup[09] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..fir_energy_setup[10] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..fir_energy_setup[11] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..Gap time E 8= 0x1f4 9= 0x1f4 10= 0x1f4 11= 0x1f4 (module/sis_3316/sis_3316.c:840) 11: a:1: ..Peak time E 8= 0x1f4 9= 0x1f4 10= 0x1f4 11= 0x1f4 (module/sis_3316/sis_3316.c:847) 11: a:1: ..Tau config 8= 0,0 9= 0,0 10= 0,0 11= 0,0 (module/sis_3316/sis_3316.c:854) 11: a:1: ..fir_energy_setup[12] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..fir_energy_setup[13] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..fir_energy_setup[14] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..fir_energy_setup[15] = 00df41f4 (module/sis_3316/sis_3316.c:838) 11: a:1: ..Gap time E 12= 0x1f4 13= 0x1f4 14= 0x1f4 15= 0x1f4 (module/sis_3316/sis_3316.c:840) 11: a:1: ..Peak time E 12= 0x1f4 13= 0x1f4 14= 0x1f4 15= 0x1f4 (module/sis_3316/sis_3316.c:847) 11: a:1: ..Tau config 12= 0,0 13= 0,0 14= 0,0 15= 0,0 (module/sis_3316/sis_3316.c:854) 11: a:1: ..Sample Length [0] = 0 samples (module/sis_3316/sis_3316.c:924) 11: a:1: ..trigger_gate_window_length[0] = 62498 (module/sis_3316/sis_3316.c:926) 11: a:1: ..Sample Length [1] = 0 samples (module/sis_3316/sis_3316.c:924) 11: a:1: ..trigger_gate_window_length[1] = 62498 (module/sis_3316/sis_3316.c:926) 11: a:1: ..Sample Length [2] = 0 samples (module/sis_3316/sis_3316.c:924) 11: a:1: ..trigger_gate_window_length[2] = 62498 (module/sis_3316/sis_3316.c:926) 11: a:1: ..Sample Length [3] = 0 samples (module/sis_3316/sis_3316.c:924) 11: a:1: ..trigger_gate_window_length[3] = 62498 (module/sis_3316/sis_3316.c:926) 11: a:1: ..ADC[0] Gate0 = (width = 255, delay = 128) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[0] Gate1 = (width = 511, delay = 8125) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[0] Gate2 = (width = 511, delay = 16250) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[0] Gate3 = (width = 511, delay = 24375) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[0] Gate4 = (width = 511, delay = 32500) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[0] Gate5 = (width = 511, delay = 40625) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[1] Gate0 = (width = 255, delay = 128) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[1] Gate1 = (width = 511, delay = 8125) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[1] Gate2 = (width = 511, delay = 16250) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[1] Gate3 = (width = 511, delay = 24375) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[1] Gate4 = (width = 511, delay = 32500) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[1] Gate5 = (width = 511, delay = 40625) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[2] Gate0 = (width = 255, delay = 128) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[2] Gate1 = (width = 511, delay = 8125) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[2] Gate2 = (width = 511, delay = 16250) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[2] Gate3 = (width = 511, delay = 24375) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[2] Gate4 = (width = 511, delay = 32500) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[2] Gate5 = (width = 511, delay = 40625) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[3] Gate0 = (width = 255, delay = 128) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[3] Gate1 = (width = 511, delay = 8125) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[3] Gate2 = (width = 511, delay = 16250) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[3] Gate3 = (width = 511, delay = 24375) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[3] Gate4 = (width = 511, delay = 32500) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[3] Gate5 = (width = 511, delay = 40625) (module/sis_3316/sis_3316.c:955) 11: a:1: ..ADC[0] Gate6 = (width = 511, delay = 48750) (module/sis_3316/sis_3316.c:973) 11: a:1: ..ADC[0] Gate7 = (width = 511, delay = 56875) (module/sis_3316/sis_3316.c:973) 11: a:1: ..ADC[1] Gate6 = (width = 511, delay = 48750) (module/sis_3316/sis_3316.c:973) 11: a:1: ..ADC[1] Gate7 = (width = 511, delay = 56875) (module/sis_3316/sis_3316.c:973) 11: a:1: ..ADC[2] Gate6 = (width = 511, delay = 48750) (module/sis_3316/sis_3316.c:973) 11: a:1: ..ADC[2] Gate7 = (width = 511, delay = 56875) (module/sis_3316/sis_3316.c:973) 11: a:1: ..ADC[3] Gate6 = (width = 511, delay = 48750) (module/sis_3316/sis_3316.c:973) 11: a:1: ..ADC[3] Gate7 = (width = 511, delay = 56875) (module/sis_3316/sis_3316.c:973) 11: a:1: ..ADC[0] internal_delay = 0x00000000 (module/sis_3316/sis_3316.c:993) 11: a:1: ..ADC[1] internal_delay = 0x00000000 (module/sis_3316/sis_3316.c:993) 11: a:1: ..ADC[2] internal_delay = 0x00000000 (module/sis_3316/sis_3316.c:993) 11: a:1: ..ADC[3] internal_delay = 0x00000000 (module/sis_3316/sis_3316.c:993) 11: a:1: ..Pretrigger delay 0= 4062 1= 4062 2= 4062 3= 4062 (module/sis_3316/sis_3316.c:1014) 11: a:1: ..Setting TI as trigger/gate input. (module/sis_3316/sis_3316.c:1049) 11: a:1: ..UO as sampling active flag. (module/sis_3316/sis_3316.c:1115) 11: a:1: ..Event = 0x08080808 0x08080808 0x08080808 0x08080808 (module/sis_3316/sis_3316.c:567) 11: a:1: ..Data format = 0x0b0b0b0b (module/sis_3316/sis_3316.c:639) 11: a:1: ..Event length 0 = 8206 (raw=0,avg=8192,maw=0) (module/sis_3316/sis_3316.c:648) 11: a:1: ..Maw buffer setup[0] = 0x00640000 (module/sis_3316/sis_3316.c:664) 11: a:1: ..Event length 1 = 8206 (raw=0,avg=8192,maw=0) (module/sis_3316/sis_3316.c:648) 11: a:1: ..Maw buffer setup[1] = 0x00640000 (module/sis_3316/sis_3316.c:664) 11: a:1: ..Event length 2 = 8206 (raw=0,avg=8192,maw=0) (module/sis_3316/sis_3316.c:648) 11: a:1: ..Maw buffer setup[2] = 0x00640000 (module/sis_3316/sis_3316.c:664) 11: a:1: ..Event length 3 = 8206 (raw=0,avg=8192,maw=0) (module/sis_3316/sis_3316.c:648) 11: a:1: ..Maw buffer setup[3] = 0x00640000 (module/sis_3316/sis_3316.c:664) 11: a:1: ..Average mode setup[0] = 0x3f3c4000 (module/sis_3316/sis_3316.c:587) 11: a:1: ..Average mode setup[1] = 0x3f3c4000 (module/sis_3316/sis_3316.c:587) 11: a:1: ..Average mode setup[2] = 0x3f3c4000 (module/sis_3316/sis_3316.c:587) 11: a:1: ..Average mode setup[3] = 0x3f3c4000 (module/sis_3316/sis_3316.c:587) 11: a:1: ..Configured num_hits per channel 1 (module/sis_3316/sis_3316.c:1151) 11: a:1: ..Maximum possible number of hits 1 (module/sis_3316/sis_3316.c:1194) 11: a:1: ..Using at most 525248 bytes per readout (module/sis_3316/sis_3316.c:1196) 11: a:1: ..Channels enabled: 16 (module/sis_3316/sis_3316.c:1197) 11: a:1: ..[3] Adjusting num hits to: 1 (module/sis_3316/sis_3316.c:2353) 11: a:1: ..May discard data for channels: 00000000 (module/sis_3316/sis_3316.c:1252) 11: a:1: .sis3316 init_fast } (module/sis_3316/sis_3316.c:1257) 11: a:1: .Post module[2]=SIS_3316. (crate/crate.c:942) 11: a:1: .sis3316 post_init { (module/sis_3316/sis_3316.c:195) 11: a:1: ..clear timestamp (module/sis_3316/sis_3316.c:204) 11: a:1: .sis3316 post_init(ctr=0x00000000) } (module/sis_3316/sis_3316.c:209) 11: a:1: .2 bank 1 armed. (module/sis_3316/sis_3316.c:214) 11: a:1: .2 configuration complete. (module/sis_3316/sis_3316.c:215) 11: a:1: .Post module[3]=SIS_3316. (crate/crate.c:942) 11: a:1: .sis3316 post_init { (module/sis_3316/sis_3316.c:195) 11: a:1: .sis3316 post_init(ctr=0x00000000) } (module/sis_3316/sis_3316.c:209) 11: a:1: .3 bank 1 armed. (module/sis_3316/sis_3316.c:214) 11: a:1: .3 configuration complete. (module/sis_3316/sis_3316.c:215) 11: a:1: .[0]=GSI_VULOM this(0x00000000)-crate(0x00000000)=0x00000000. (crate/crate.c:1692) 11: a:1: .[1]=GSI_VETAR this(0x00000000)-crate(0x00000000)=0x00000000. (crate/crate.c:1692) 11: a:1: .[2]=SIS_3316 this(0x00000000)-crate(0x00000000)=0x00000000. (crate/crate.c:1692) 11: a:1: .[3]=SIS_3316 this(0x00000000)-crate(0x00000000)=0x00000000. (crate/crate.c:1692) 10: a:1: crate_init(MCAL) } (crate/crate.c:1002) 10: a:1: Control server online. (ctrl/ctrl.c:796) Thread has no error buffer yet... 10: a:1: WR ID=0x200. (f_user.c:275) 10: a:1: Will read out beam sampler: No. (f_user.c:278) 10: a:1: Will read trig LMU scalers: No. (f_user.c:279) 10: a:1: Will read LOS scalers: No. (f_user.c:280) 10: a:1: Will read out ROLU+SofStart scalers: No. (f_user.c:281) 10: a:1: Will collect spill structure: No. (f_user.c:282) 10: a:1: Will use triggers 10..13 for spills: No. (f_user.c:283) 10: a:1: Will read event TPAT: No. (f_user.c:284) 10: a:1: Will read TrLoII scalers on trigger: 1 (f_user.c:286) 10: a:1: Using 0x3 as vulom address. (f_user.c:291) 10: a:1: Will send info via UDP: No. (f_user.c:293) 11: hwmap_mapvme.c:240: Virtual address for TRLO II @ VME 0x03000000 is 0x4b863000. LOG: TRLO: MD5SUM: 0x426cb99c (CT: 5bba6507 = 2018-10-07 19:56:55 UTC) From f96hajo at chalmers.se Tue Jan 23 14:15:41 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Tue, 23 Jan 2024 14:15:41 +0100 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <1aa0afb1bf1e4f91b5d2ab58eb0c62bb@hi-jena.gsi.de> <810ed751-3a8a-43d7-b9b1-7d7c08f8fdf4@chalmers.se> <0dc854ec60194f299b776bc263eb2c72@hi-jena.gsi.de> <5f7958c3-297f-9303-efad-851c23f87ff0@chalmers.se> <897201d9f3424d318c7ed49ce4106aaa@hi-jena.gsi.de> <7f6060e5-ccad-48ba-927e-cb749bea290a@chalmers.se> <2d0ecc20c1ee4921b5ed807b41251fe5@hi-jena.gsi.de> <8fb50894-080f-4bf8-8ed3-f7a965de1b55@chalmers.se> <266475039f5d41fc9c8247714820854a@hi-jena.gsi.de> <2a94c163-aeb5-4336-bfe0-44d89172ec99@chalmers.se> <3aad99c7-e61b-47eb-8dcd-f7f872c56d33@chalmers.se> , <9b98f1d3-dfbb-4a99-bb6c-7d658048ad83@chalmers.se> <09e3707e3d5844e8a6ded8b78b70358d@hi-jena.gsi.de>, <36e8dae7-13cb-9258-99f3-4c5f2004c2a7@chalmers.se> <929564d321f54545b6abb2a24c9c6162@hi-jena.gsi.de>, <16a7c247-a7ab-3217-d905-27e3264432da@chalmers.se> Message-ID: Dear G?nter, how about the lines '..adc[0] firmware=' ? The ADC FPGAs have a different image than the VME FPGA. Perhaps they were not present with the older software..? I do not know much about the SSI3316 firmware versions, but from the looks of it, we have at least three different ones at hand so far for the VME FPGA: 0x3316200e, 0x33162010, 0x3316a012 Best regards, H?kan On Tue, 23 Jan 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > attached please find the output of the old system. To me it looks as if > every single setting of the SIS3316 modules is printed to screen. In total > almost 2000 lines for just two modules. > > > I find the following serial number entries: > > > Line 701: > > 10: a:1: ..Serial number=0x00800172. (module/sis_3316/sis_3316.c:1305) > 10: a:1: ..id/firmware=0x33162010. (module/sis_3316/sis_3316.c:1312) > > > Line 796: > > 10: a:1: ..Serial number=0x00800170. (module/sis_3316/sis_3316.c:1305) > 10: a:1: ..id/firmware=0x3316a012. (module/sis_3316/sis_3316.c:1312) > > > > Best greetings > > G?nter > > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan > T Johansson > Gesendet: Dienstag, 23. Januar 2024 12:32:50 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, > DRASI, etc. were updated ? > > Dear G?nter, > > On Tue, 23 Jan 2024, Weber, Guenter Dr. wrote: > > > as far as I know we never touched the SIS3316 firmware. But, as you know > by > > now, I know every little about the details of our DAQ, unfortunately. > > Could you for the other DAQ system (with working SIS3316), check the > output at startup or module re-init corresponding to these lines: > > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x00800178. > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x3316200e. > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x0125000c. > > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x01250011. > > and see what versions those modules have loaded? > > Cheers, > H?kan > > From g.weber at hi-jena.gsi.de Tue Jan 23 16:12:21 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 23 Jan 2024 15:12:21 +0000 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <1aa0afb1bf1e4f91b5d2ab58eb0c62bb@hi-jena.gsi.de> <810ed751-3a8a-43d7-b9b1-7d7c08f8fdf4@chalmers.se> <0dc854ec60194f299b776bc263eb2c72@hi-jena.gsi.de> <5f7958c3-297f-9303-efad-851c23f87ff0@chalmers.se> <897201d9f3424d318c7ed49ce4106aaa@hi-jena.gsi.de> <7f6060e5-ccad-48ba-927e-cb749bea290a@chalmers.se> <2d0ecc20c1ee4921b5ed807b41251fe5@hi-jena.gsi.de> <8fb50894-080f-4bf8-8ed3-f7a965de1b55@chalmers.se> <266475039f5d41fc9c8247714820854a@hi-jena.gsi.de> <2a94c163-aeb5-4336-bfe0-44d89172ec99@chalmers.se> <3aad99c7-e61b-47eb-8dcd-f7f872c56d33@chalmers.se> , <9b98f1d3-dfbb-4a99-bb6c-7d658048ad83@chalmers.se> <09e3707e3d5844e8a6ded8b78b70358d@hi-jena.gsi.de>, <36e8dae7-13cb-9258-99f3-4c5f2004c2a7@chalmers.se> <929564d321f54545b6abb2a24c9c6162@hi-jena.gsi.de>, <16a7c247-a7ab-3217-d905-27e3264432da@chalmers.se> , Message-ID: <1dac3e9e97924dfb98369b0c740f6a56@hi-jena.gsi.de> Dear H?kan, the ADC firmware is printed right after the firmware of the VME module: 0: a:1: ..Serial number=0x00800172. (module/sis_3316/sis_3316.c:1305) 10: a:1: ..id/firmware=0x33162010. (module/sis_3316/sis_3316.c:1312) 10: a:1: ..adc[0] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) 11: a:1: ..adc[0] has 16 bits. (module/sis_3316/sis_3316.c:1322) 10: a:1: ..adc[1] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) 11: a:1: ..adc[1] has 16 bits. (module/sis_3316/sis_3316.c:1322) 10: a:1: ..adc[2] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) 11: a:1: ..adc[2] has 16 bits. (module/sis_3316/sis_3316.c:1322) 10: a:1: ..adc[3] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) 11: a:1: ..adc[3] has 16 bits. (module/sis_3316/sis_3316.c:1322) and 10: a:1: ..Serial number=0x00800170. (module/sis_3316/sis_3316.c:1305) 10: a:1: ..id/firmware=0x3316a012. (module/sis_3316/sis_3316.c:1312) 10: a:1: ..adc[0] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) 11: a:1: ..adc[0] has 16 bits. (module/sis_3316/sis_3316.c:1322) 10: a:1: ..adc[1] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) 11: a:1: ..adc[1] has 16 bits. (module/sis_3316/sis_3316.c:1322) 10: a:1: ..adc[2] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) 11: a:1: ..adc[2] has 16 bits. (module/sis_3316/sis_3316.c:1322) 10: a:1: ..adc[3] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) 11: a:1: ..adc[3] has 16 bits. (module/sis_3316/sis_3316.c:1322) We never had look at the firmware and also exchanged or six SIS3316 modules for each other. Thus, my assumption is that differences in the firmware number should not matter. But of course, I am not sure about this. What puzzles me right now is the fact, that on the old system we get so much more output on the command line. On the new system it is just the SIS3316 firmware information and, for some reason, the threshold settings (out of a ton of various setting options for this type of module). Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Dienstag, 23. Januar 2024 14:15:41 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated Dear G?nter, how about the lines '..adc[0] firmware=' ? The ADC FPGAs have a different image than the VME FPGA. Perhaps they were not present with the older software..? I do not know much about the SSI3316 firmware versions, but from the looks of it, we have at least three different ones at hand so far for the VME FPGA: 0x3316200e, 0x33162010, 0x3316a012 Best regards, H?kan On Tue, 23 Jan 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > attached please find the output of the old system. To me it looks as if > every single setting of the SIS3316 modules is printed to screen. In total > almost 2000 lines for just two modules. > > > I find the following serial number entries: > > > Line 701: > > 10: a:1: ..Serial number=0x00800172. (module/sis_3316/sis_3316.c:1305) > 10: a:1: ..id/firmware=0x33162010. (module/sis_3316/sis_3316.c:1312) > > > Line 796: > > 10: a:1: ..Serial number=0x00800170. (module/sis_3316/sis_3316.c:1305) > 10: a:1: ..id/firmware=0x3316a012. (module/sis_3316/sis_3316.c:1312) > > > > Best greetings > > G?nter > > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan > T Johansson > Gesendet: Dienstag, 23. Januar 2024 12:32:50 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, > DRASI, etc. were updated > > Dear G?nter, > > On Tue, 23 Jan 2024, Weber, Guenter Dr. wrote: > > > as far as I know we never touched the SIS3316 firmware. But, as you know > by > > now, I know every little about the details of our DAQ, unfortunately. > > Could you for the other DAQ system (with working SIS3316), check the > output at startup or module re-init corresponding to these lines: > > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x00800178. > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x3316200e. > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x0125000c. > > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x01250011. > > and see what versions those modules have loaded? > > Cheers, > H?kan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.tornqvist at chalmers.se Tue Jan 23 16:19:34 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Tue, 23 Jan 2024 16:19:34 +0100 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <1dac3e9e97924dfb98369b0c740f6a56@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <0dc854ec60194f299b776bc263eb2c72@hi-jena.gsi.de> <5f7958c3-297f-9303-efad-851c23f87ff0@chalmers.se> <897201d9f3424d318c7ed49ce4106aaa@hi-jena.gsi.de> <7f6060e5-ccad-48ba-927e-cb749bea290a@chalmers.se> <2d0ecc20c1ee4921b5ed807b41251fe5@hi-jena.gsi.de> <8fb50894-080f-4bf8-8ed3-f7a965de1b55@chalmers.se> <266475039f5d41fc9c8247714820854a@hi-jena.gsi.de> <2a94c163-aeb5-4336-bfe0-44d89172ec99@chalmers.se> <3aad99c7-e61b-47eb-8dcd-f7f872c56d33@chalmers.se> <9b98f1d3-dfbb-4a99-bb6c-7d658048ad83@chalmers.se> <09e3707e3d5844e8a6ded8b78b70358d@hi-jena.gsi.de> <36e8dae7-13cb-9258-99f3-4c5f2004c2a7@chalmers.se> <929564d321f54545b6abb2a24c9c6162@hi-jena.gsi.de> <16a7c247-a7ab-3217-d905-27e3264432da@chalmers.se> <1dac3e9e97924dfb98369b0c740f6a56@hi-jena.gsi.de> Message-ID: Dear G?nter, Are you using different main.cfg files for the new and old DAQ? Could you add "log_level = verbose" or "log_level = debug" in the new main.cfg if it's not there? That should print a lot more information. Note that all that text ends up in the log, have a look at it so it does not explode in size, especially if you set " = debug"! Please try to recreate the crate setup with the same firmware versions and addresses etc like before, that will reduce the number of free variables in the testing. Best regards, Hans On 2024-01-23 16:12, Weber, Guenter Dr. wrote: > Dear H?kan, > > > the ADC firmware is printed right after the firmware of the VME module: > > > 0: a:1: ..Serial number=0x00800172. (module/sis_3316/sis_3316.c:1305) > 10: a:1: ..id/firmware=0x33162010. (module/sis_3316/sis_3316.c:1312) > 10: a:1: ..adc[0] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) > 11: a:1: ..adc[0] has 16 bits. (module/sis_3316/sis_3316.c:1322) > 10: a:1: ..adc[1] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) > 11: a:1: ..adc[1] has 16 bits. (module/sis_3316/sis_3316.c:1322) > 10: a:1: ..adc[2] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) > 11: a:1: ..adc[2] has 16 bits. (module/sis_3316/sis_3316.c:1322) > 10: a:1: ..adc[3] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) > 11: a:1: ..adc[3] has 16 bits. (module/sis_3316/sis_3316.c:1322) > > > and > > > 10: a:1: ..Serial number=0x00800170. (module/sis_3316/sis_3316.c:1305) > 10: a:1: ..id/firmware=0x3316a012. (module/sis_3316/sis_3316.c:1312) > 10: a:1: ..adc[0] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) > 11: a:1: ..adc[0] has 16 bits. (module/sis_3316/sis_3316.c:1322) > 10: a:1: ..adc[1] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) > 11: a:1: ..adc[1] has 16 bits. (module/sis_3316/sis_3316.c:1322) > 10: a:1: ..adc[2] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) > 11: a:1: ..adc[2] has 16 bits. (module/sis_3316/sis_3316.c:1322) > 10: a:1: ..adc[3] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) > 11: a:1: ..adc[3] has 16 bits. (module/sis_3316/sis_3316.c:1322) > > > We never had look at the firmware and also exchanged or six SIS3316 > modules for each other. Thus, my assumption is that differences in the > firmware number should not matter. But of course, I am not sure about this. > > > What puzzles me right now is the fact, that on the old system we get so > much more output on the command line. On the new system it is just the > SIS3316 firmware information and, for some reason, the threshold > settings (out of a ton of various setting options for this type of module). > > > > > > Best greetings > > G?nter > > > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > H?kan T Johansson > *Gesendet:* Dienstag, 23. Januar 2024 14:15:41 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > TRLOII, DRASI, etc. were updated > > Dear G?nter, > > how about the lines '..adc[0] firmware=' ?? The ADC FPGAs have a different > image than the VME FPGA. > > Perhaps they were not present with the older software..? > > I do not know much about the SSI3316 firmware versions, but from the looks > of it, we have at least three different ones at hand so far for the VME > FPGA: > > 0x3316200e, 0x33162010, 0x3316a012 > > Best regards, > H?kan > > > On Tue, 23 Jan 2024, Weber, Guenter Dr. wrote: > >> >> Dear friends, >> >> >> attached please find the output of the old system. To me it looks as if >> every single setting of the SIS3316 modules is printed to screen. In total >> almost 2000 lines for just two modules. >> >> >> I find the following serial number entries: >> >> >> Line 701: >> >> 10: a:1: ..Serial number=0x00800172. (module/sis_3316/sis_3316.c:1305) >> 10: a:1: ..id/firmware=0x33162010. (module/sis_3316/sis_3316.c:1312) >> >> >> Line 796: >> >> 10: a:1: ..Serial number=0x00800170. (module/sis_3316/sis_3316.c:1305) >> 10: a:1: ..id/firmware=0x3316a012. (module/sis_3316/sis_3316.c:1312) > > > > >> >> >> >> Best greetings >> >> G?nter >> >> >> >> ____________________________________________________________________________ >> Von: subexp-daq im Auftrag von H?kan >> T Johansson >> Gesendet: Dienstag, 23. Januar 2024 12:32:50 >> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, >> DRASI, etc. were updated >> >> Dear G?nter, >> >> On Tue, 23 Jan 2024, Weber, Guenter Dr. wrote: >> >> > as far as I know we never touched the SIS3316 firmware. But, as you know >> by >> > now, I know every little about the details of our DAQ, unfortunately. >> >> Could you for the other DAQ system (with working SIS3316), check the >> output at startup or module re-init corresponding to these lines: >> >> 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x00800178. >> 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x3316200e. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x0125000c. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x0125000c. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x0125000c. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x0125000c. >> >> 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. >> 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x01250011. >> 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x01250011. >> >> and see what versions those modules have loaded? >> >> Cheers, >> H?kan >> >> > From f96hajo at chalmers.se Wed Jan 24 06:42:24 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Wed, 24 Jan 2024 06:42:24 +0100 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <5f7958c3-297f-9303-efad-851c23f87ff0@chalmers.se> <897201d9f3424d318c7ed49ce4106aaa@hi-jena.gsi.de> <7f6060e5-ccad-48ba-927e-cb749bea290a@chalmers.se> <2d0ecc20c1ee4921b5ed807b41251fe5@hi-jena.gsi.de> <8fb50894-080f-4bf8-8ed3-f7a965de1b55@chalmers.se> <266475039f5d41fc9c8247714820854a@hi-jena.gsi.de> <2a94c163-aeb5-4336-bfe0-44d89172ec99@chalmers.se> <3aad99c7-e61b-47eb-8dcd-f7f872c56d33@chalmers.se> <9b98f1d3-dfbb-4a99-bb6c-7d658048ad83@chalmers.se> <09e3707e3d5844e8a6ded8b78b70358d@hi-jena.gsi.de> <36e8dae7-13cb-9258-99f3-4c5f2004c2a7@chalmers.se> <929564d321f54545b6abb2a24c9c6162@hi-jena.gsi.de> <16a7c247-a7ab-3217-d905-27e3264432da@chalmers.se> <1dac3e9e97924dfb98369b0c740f6a56@hi-jena.gsi.de> Message-ID: Dear G?nter, before you do a lot of module surgery: given that the merge of the changes you had in nurdlib in the 'old' but working daq into current nurdlib was a veritable monster, we have figured that those need to be more carefully considered, piece-by-piece. With some luck, some inadvertent mistake in the merge operation is perhaps found. This might take a few days... If that does not work, one can dump the full register set in the modules in both the 'old' and 'new' daqs after setup and compare those, which would then hopefully hint at what is not the same. But the code inspection is a safer long-term approach, so we prefer to do that first. Best regards, H?kan On Tue, 23 Jan 2024, Hans Toshihide T?rnqvist wrote: > Dear G?nter, > > Are you using different main.cfg files for the new and old DAQ? > > Could you add "log_level = verbose" or "log_level = debug" in the new > main.cfg if it's not there? That should print a lot more information. > > Note that all that text ends up in the log, have a look at it so it does > not explode in size, especially if you set " = debug"! > > Please try to recreate the crate setup with the same firmware versions > and addresses etc like before, that will reduce the number of free > variables in the testing. > > Best regards, > Hans > > > On 2024-01-23 16:12, Weber, Guenter Dr. wrote: >> Dear H?kan, >> >> >> the ADC firmware is printed right after the firmware of the VME module: >> >> >> 0: a:1: ..Serial number=0x00800172. (module/sis_3316/sis_3316.c:1305) >> 10: a:1: ..id/firmware=0x33162010. (module/sis_3316/sis_3316.c:1312) >> 10: a:1: ..adc[0] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) >> 11: a:1: ..adc[0] has 16 bits. (module/sis_3316/sis_3316.c:1322) >> 10: a:1: ..adc[1] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) >> 11: a:1: ..adc[1] has 16 bits. (module/sis_3316/sis_3316.c:1322) >> 10: a:1: ..adc[2] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) >> 11: a:1: ..adc[2] has 16 bits. (module/sis_3316/sis_3316.c:1322) >> 10: a:1: ..adc[3] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) >> 11: a:1: ..adc[3] has 16 bits. (module/sis_3316/sis_3316.c:1322) >> >> >> and >> >> >> 10: a:1: ..Serial number=0x00800170. (module/sis_3316/sis_3316.c:1305) >> 10: a:1: ..id/firmware=0x3316a012. (module/sis_3316/sis_3316.c:1312) >> 10: a:1: ..adc[0] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) >> 11: a:1: ..adc[0] has 16 bits. (module/sis_3316/sis_3316.c:1322) >> 10: a:1: ..adc[1] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) >> 11: a:1: ..adc[1] has 16 bits. (module/sis_3316/sis_3316.c:1322) >> 10: a:1: ..adc[2] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) >> 11: a:1: ..adc[2] has 16 bits. (module/sis_3316/sis_3316.c:1322) >> 10: a:1: ..adc[3] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) >> 11: a:1: ..adc[3] has 16 bits. (module/sis_3316/sis_3316.c:1322) >> >> >> We never had look at the firmware and also exchanged or six SIS3316 >> modules for each other. Thus, my assumption is that differences in the >> firmware number should not matter. But of course, I am not sure about this. >> >> >> What puzzles me right now is the fact, that on the old system we get so >> much more output on the command line. On the new system it is just the >> SIS3316 firmware information and, for some reason, the threshold >> settings (out of a ton of various setting options for this type of module). >> >> >> >> >> >> Best greetings >> >> G?nter >> >> >> >> >> ------------------------------------------------------------------------ >> *Von:* subexp-daq im Auftrag von >> H?kan T Johansson >> *Gesendet:* Dienstag, 23. Januar 2024 14:15:41 >> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >> TRLOII, DRASI, etc. were updated >> >> Dear G?nter, >> >> how about the lines '..adc[0] firmware=' ?? The ADC FPGAs have a different >> image than the VME FPGA. >> >> Perhaps they were not present with the older software..? >> >> I do not know much about the SSI3316 firmware versions, but from the looks >> of it, we have at least three different ones at hand so far for the VME >> FPGA: >> >> 0x3316200e, 0x33162010, 0x3316a012 >> >> Best regards, >> H?kan >> >> >> On Tue, 23 Jan 2024, Weber, Guenter Dr. wrote: >> >>> >>> Dear friends, >>> >>> >>> attached please find the output of the old system. To me it looks as if >>> every single setting of the SIS3316 modules is printed to screen. In total >>> almost 2000 lines for just two modules. >>> >>> >>> I find the following serial number entries: >>> >>> >>> Line 701: >>> >>> 10: a:1: ..Serial number=0x00800172. (module/sis_3316/sis_3316.c:1305) >>> 10: a:1: ..id/firmware=0x33162010. (module/sis_3316/sis_3316.c:1312) >>> >>> >>> Line 796: >>> >>> 10: a:1: ..Serial number=0x00800170. (module/sis_3316/sis_3316.c:1305) >>> 10: a:1: ..id/firmware=0x3316a012. (module/sis_3316/sis_3316.c:1312) >> >> >> >> >>> >>> >>> >>> Best greetings >>> >>> G?nter >>> >>> >>> >>> > ____________________________________________________________________________ >>> Von: subexp-daq im Auftrag von > H?kan >>> T Johansson >>> Gesendet: Dienstag, 23. Januar 2024 12:32:50 >>> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >>> Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, >>> DRASI, etc. were updated >>> >>> Dear G?nter, >>> >>> On Tue, 23 Jan 2024, Weber, Guenter Dr. wrote: >>> >>> > as far as I know we never touched the SIS3316 firmware. But, as you know >>> by >>> > now, I know every little about the details of our DAQ, unfortunately. >>> >>> Could you for the other DAQ system (with working SIS3316), check the >>> output at startup or module re-init corresponding to these lines: >>> >>> 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x00800178. >>> 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x3316200e. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x0125000c. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x0125000c. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x0125000c. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x0125000c. >>> >>> 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. >>> 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x01250011. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x01250011. >>> >>> and see what versions those modules have loaded? >>> >>> Cheers, >>> H?kan >>> >>> >> > -- > subexp-daq mailing list > subexp-daq at lists.chalmers.se > https://lists.chalmers.se/mailman/listinfo/subexp-daq > From g.weber at hi-jena.gsi.de Wed Jan 24 11:23:19 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Wed, 24 Jan 2024 10:23:19 +0000 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <5f7958c3-297f-9303-efad-851c23f87ff0@chalmers.se> <897201d9f3424d318c7ed49ce4106aaa@hi-jena.gsi.de> <7f6060e5-ccad-48ba-927e-cb749bea290a@chalmers.se> <2d0ecc20c1ee4921b5ed807b41251fe5@hi-jena.gsi.de> <8fb50894-080f-4bf8-8ed3-f7a965de1b55@chalmers.se> <266475039f5d41fc9c8247714820854a@hi-jena.gsi.de> <2a94c163-aeb5-4336-bfe0-44d89172ec99@chalmers.se> <3aad99c7-e61b-47eb-8dcd-f7f872c56d33@chalmers.se> <9b98f1d3-dfbb-4a99-bb6c-7d658048ad83@chalmers.se> <09e3707e3d5844e8a6ded8b78b70358d@hi-jena.gsi.de> <36e8dae7-13cb-9258-99f3-4c5f2004c2a7@chalmers.se> <929564d321f54545b6abb2a24c9c6162@hi-jena.gsi.de> <16a7c247-a7ab-3217-d905-27e3264432da@chalmers.se> <1dac3e9e97924dfb98369b0c740f6a56@hi-jena.gsi.de> , Message-ID: Dear friends, I now wanted to turn thing around and only have a single SIS3316 module in the DAQ. So I commented out the VULOM in main.cfg. However, now the r3bfuser.cfg needs to change, I guess. 5: f_user.c:745: User set WR ID=0x200, but no WR-capable module configured for nurdlib! What would be the correct R3B setting now with just a SIS3316 module in main.cfg? Or is the way to go, not to comment out the complete VULOM entry but just the timestamp and ecl options, i. e. having only GSI_VETAR(0x50000000) { # dactl = false # direct = false } ? Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Mittwoch, 24. Januar 2024 06:42:24 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated Dear G?nter, before you do a lot of module surgery: given that the merge of the changes you had in nurdlib in the 'old' but working daq into current nurdlib was a veritable monster, we have figured that those need to be more carefully considered, piece-by-piece. With some luck, some inadvertent mistake in the merge operation is perhaps found. This might take a few days... If that does not work, one can dump the full register set in the modules in both the 'old' and 'new' daqs after setup and compare those, which would then hopefully hint at what is not the same. But the code inspection is a safer long-term approach, so we prefer to do that first. Best regards, H?kan On Tue, 23 Jan 2024, Hans Toshihide T?rnqvist wrote: > Dear G?nter, > > Are you using different main.cfg files for the new and old DAQ? > > Could you add "log_level = verbose" or "log_level = debug" in the new > main.cfg if it's not there? That should print a lot more information. > > Note that all that text ends up in the log, have a look at it so it does > not explode in size, especially if you set " = debug"! > > Please try to recreate the crate setup with the same firmware versions > and addresses etc like before, that will reduce the number of free > variables in the testing. > > Best regards, > Hans > > > On 2024-01-23 16:12, Weber, Guenter Dr. wrote: >> Dear H?kan, >> >> >> the ADC firmware is printed right after the firmware of the VME module: >> >> >> 0: a:1: ..Serial number=0x00800172. (module/sis_3316/sis_3316.c:1305) >> 10: a:1: ..id/firmware=0x33162010. (module/sis_3316/sis_3316.c:1312) >> 10: a:1: ..adc[0] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) >> 11: a:1: ..adc[0] has 16 bits. (module/sis_3316/sis_3316.c:1322) >> 10: a:1: ..adc[1] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) >> 11: a:1: ..adc[1] has 16 bits. (module/sis_3316/sis_3316.c:1322) >> 10: a:1: ..adc[2] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) >> 11: a:1: ..adc[2] has 16 bits. (module/sis_3316/sis_3316.c:1322) >> 10: a:1: ..adc[3] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) >> 11: a:1: ..adc[3] has 16 bits. (module/sis_3316/sis_3316.c:1322) >> >> >> and >> >> >> 10: a:1: ..Serial number=0x00800170. (module/sis_3316/sis_3316.c:1305) >> 10: a:1: ..id/firmware=0x3316a012. (module/sis_3316/sis_3316.c:1312) >> 10: a:1: ..adc[0] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) >> 11: a:1: ..adc[0] has 16 bits. (module/sis_3316/sis_3316.c:1322) >> 10: a:1: ..adc[1] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) >> 11: a:1: ..adc[1] has 16 bits. (module/sis_3316/sis_3316.c:1322) >> 10: a:1: ..adc[2] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) >> 11: a:1: ..adc[2] has 16 bits. (module/sis_3316/sis_3316.c:1322) >> 10: a:1: ..adc[3] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) >> 11: a:1: ..adc[3] has 16 bits. (module/sis_3316/sis_3316.c:1322) >> >> >> We never had look at the firmware and also exchanged or six SIS3316 >> modules for each other. Thus, my assumption is that differences in the >> firmware number should not matter. But of course, I am not sure about this. >> >> >> What puzzles me right now is the fact, that on the old system we get so >> much more output on the command line. On the new system it is just the >> SIS3316 firmware information and, for some reason, the threshold >> settings (out of a ton of various setting options for this type of module). >> >> >> >> >> >> Best greetings >> >> G?nter >> >> >> >> >> ------------------------------------------------------------------------ >> *Von:* subexp-daq im Auftrag von >> H?kan T Johansson >> *Gesendet:* Dienstag, 23. Januar 2024 14:15:41 >> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >> TRLOII, DRASI, etc. were updated >> >> Dear G?nter, >> >> how about the lines '..adc[0] firmware=' ? The ADC FPGAs have a different >> image than the VME FPGA. >> >> Perhaps they were not present with the older software..? >> >> I do not know much about the SSI3316 firmware versions, but from the looks >> of it, we have at least three different ones at hand so far for the VME >> FPGA: >> >> 0x3316200e, 0x33162010, 0x3316a012 >> >> Best regards, >> H?kan >> >> >> On Tue, 23 Jan 2024, Weber, Guenter Dr. wrote: >> >>> >>> Dear friends, >>> >>> >>> attached please find the output of the old system. To me it looks as if >>> every single setting of the SIS3316 modules is printed to screen. In total >>> almost 2000 lines for just two modules. >>> >>> >>> I find the following serial number entries: >>> >>> >>> Line 701: >>> >>> 10: a:1: ..Serial number=0x00800172. (module/sis_3316/sis_3316.c:1305) >>> 10: a:1: ..id/firmware=0x33162010. (module/sis_3316/sis_3316.c:1312) >>> >>> >>> Line 796: >>> >>> 10: a:1: ..Serial number=0x00800170. (module/sis_3316/sis_3316.c:1305) >>> 10: a:1: ..id/firmware=0x3316a012. (module/sis_3316/sis_3316.c:1312) >> >> >> >> >>> >>> >>> >>> Best greetings >>> >>> G?nter >>> >>> >>> >>> > ____________________________________________________________________________ >>> Von: subexp-daq im Auftrag von > H?kan >>> T Johansson >>> Gesendet: Dienstag, 23. Januar 2024 12:32:50 >>> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >>> Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, >>> DRASI, etc. were updated >>> >>> Dear G?nter, >>> >>> On Tue, 23 Jan 2024, Weber, Guenter Dr. wrote: >>> >>> > as far as I know we never touched the SIS3316 firmware. But, as you know >>> by >>> > now, I know every little about the details of our DAQ, unfortunately. >>> >>> Could you for the other DAQ system (with working SIS3316), check the >>> output at startup or module re-init corresponding to these lines: >>> >>> 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x00800178. >>> 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x3316200e. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x0125000c. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x0125000c. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x0125000c. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x0125000c. >>> >>> 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. >>> 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x01250011. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x01250011. >>> >>> and see what versions those modules have loaded? >>> >>> Cheers, >>> H?kan >>> >>> >> > -- > 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: From g.weber at hi-jena.gsi.de Wed Jan 24 11:48:15 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Wed, 24 Jan 2024 10:48:15 +0000 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <5f7958c3-297f-9303-efad-851c23f87ff0@chalmers.se> <897201d9f3424d318c7ed49ce4106aaa@hi-jena.gsi.de> <7f6060e5-ccad-48ba-927e-cb749bea290a@chalmers.se> <2d0ecc20c1ee4921b5ed807b41251fe5@hi-jena.gsi.de> <8fb50894-080f-4bf8-8ed3-f7a965de1b55@chalmers.se> <266475039f5d41fc9c8247714820854a@hi-jena.gsi.de> <2a94c163-aeb5-4336-bfe0-44d89172ec99@chalmers.se> <3aad99c7-e61b-47eb-8dcd-f7f872c56d33@chalmers.se> <9b98f1d3-dfbb-4a99-bb6c-7d658048ad83@chalmers.se> <09e3707e3d5844e8a6ded8b78b70358d@hi-jena.gsi.de> <36e8dae7-13cb-9258-99f3-4c5f2004c2a7@chalmers.se> <929564d321f54545b6abb2a24c9c6162@hi-jena.gsi.de> <16a7c247-a7ab-3217-d905-27e3264432da@chalmers.se> <1dac3e9e97924dfb98369b0c740f6a56@hi-jena.gsi.de> , , Message-ID: <35b1c34ea9e14282807f085fc893c0a5@hi-jena.gsi.de> Small update: If no channel of the SIS3316 module is not read out, then the DAQ is running smoothly. As soon as I want to read out one channel, the error message is triggered. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von Weber, Guenter Dr. Gesendet: Mittwoch, 24. Januar 2024 11:23:19 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated Dear friends, I now wanted to turn thing around and only have a single SIS3316 module in the DAQ. So I commented out the VULOM in main.cfg. However, now the r3bfuser.cfg needs to change, I guess. 5: f_user.c:745: User set WR ID=0x200, but no WR-capable module configured for nurdlib! What would be the correct R3B setting now with just a SIS3316 module in main.cfg? Or is the way to go, not to comment out the complete VULOM entry but just the timestamp and ecl options, i. e. having only GSI_VETAR(0x50000000) { # dactl = false # direct = false } ? Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Mittwoch, 24. Januar 2024 06:42:24 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated Dear G?nter, before you do a lot of module surgery: given that the merge of the changes you had in nurdlib in the 'old' but working daq into current nurdlib was a veritable monster, we have figured that those need to be more carefully considered, piece-by-piece. With some luck, some inadvertent mistake in the merge operation is perhaps found. This might take a few days... If that does not work, one can dump the full register set in the modules in both the 'old' and 'new' daqs after setup and compare those, which would then hopefully hint at what is not the same. But the code inspection is a safer long-term approach, so we prefer to do that first. Best regards, H?kan On Tue, 23 Jan 2024, Hans Toshihide T?rnqvist wrote: > Dear G?nter, > > Are you using different main.cfg files for the new and old DAQ? > > Could you add "log_level = verbose" or "log_level = debug" in the new > main.cfg if it's not there? That should print a lot more information. > > Note that all that text ends up in the log, have a look at it so it does > not explode in size, especially if you set " = debug"! > > Please try to recreate the crate setup with the same firmware versions > and addresses etc like before, that will reduce the number of free > variables in the testing. > > Best regards, > Hans > > > On 2024-01-23 16:12, Weber, Guenter Dr. wrote: >> Dear H?kan, >> >> >> the ADC firmware is printed right after the firmware of the VME module: >> >> >> 0: a:1: ..Serial number=0x00800172. (module/sis_3316/sis_3316.c:1305) >> 10: a:1: ..id/firmware=0x33162010. (module/sis_3316/sis_3316.c:1312) >> 10: a:1: ..adc[0] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) >> 11: a:1: ..adc[0] has 16 bits. (module/sis_3316/sis_3316.c:1322) >> 10: a:1: ..adc[1] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) >> 11: a:1: ..adc[1] has 16 bits. (module/sis_3316/sis_3316.c:1322) >> 10: a:1: ..adc[2] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) >> 11: a:1: ..adc[2] has 16 bits. (module/sis_3316/sis_3316.c:1322) >> 10: a:1: ..adc[3] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) >> 11: a:1: ..adc[3] has 16 bits. (module/sis_3316/sis_3316.c:1322) >> >> >> and >> >> >> 10: a:1: ..Serial number=0x00800170. (module/sis_3316/sis_3316.c:1305) >> 10: a:1: ..id/firmware=0x3316a012. (module/sis_3316/sis_3316.c:1312) >> 10: a:1: ..adc[0] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) >> 11: a:1: ..adc[0] has 16 bits. (module/sis_3316/sis_3316.c:1322) >> 10: a:1: ..adc[1] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) >> 11: a:1: ..adc[1] has 16 bits. (module/sis_3316/sis_3316.c:1322) >> 10: a:1: ..adc[2] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) >> 11: a:1: ..adc[2] has 16 bits. (module/sis_3316/sis_3316.c:1322) >> 10: a:1: ..adc[3] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) >> 11: a:1: ..adc[3] has 16 bits. (module/sis_3316/sis_3316.c:1322) >> >> >> We never had look at the firmware and also exchanged or six SIS3316 >> modules for each other. Thus, my assumption is that differences in the >> firmware number should not matter. But of course, I am not sure about this. >> >> >> What puzzles me right now is the fact, that on the old system we get so >> much more output on the command line. On the new system it is just the >> SIS3316 firmware information and, for some reason, the threshold >> settings (out of a ton of various setting options for this type of module). >> >> >> >> >> >> Best greetings >> >> G?nter >> >> >> >> >> ------------------------------------------------------------------------ >> *Von:* subexp-daq im Auftrag von >> H?kan T Johansson >> *Gesendet:* Dienstag, 23. Januar 2024 14:15:41 >> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >> TRLOII, DRASI, etc. were updated >> >> Dear G?nter, >> >> how about the lines '..adc[0] firmware=' ? The ADC FPGAs have a different >> image than the VME FPGA. >> >> Perhaps they were not present with the older software..? >> >> I do not know much about the SSI3316 firmware versions, but from the looks >> of it, we have at least three different ones at hand so far for the VME >> FPGA: >> >> 0x3316200e, 0x33162010, 0x3316a012 >> >> Best regards, >> H?kan >> >> >> On Tue, 23 Jan 2024, Weber, Guenter Dr. wrote: >> >>> >>> Dear friends, >>> >>> >>> attached please find the output of the old system. To me it looks as if >>> every single setting of the SIS3316 modules is printed to screen. In total >>> almost 2000 lines for just two modules. >>> >>> >>> I find the following serial number entries: >>> >>> >>> Line 701: >>> >>> 10: a:1: ..Serial number=0x00800172. (module/sis_3316/sis_3316.c:1305) >>> 10: a:1: ..id/firmware=0x33162010. (module/sis_3316/sis_3316.c:1312) >>> >>> >>> Line 796: >>> >>> 10: a:1: ..Serial number=0x00800170. (module/sis_3316/sis_3316.c:1305) >>> 10: a:1: ..id/firmware=0x3316a012. (module/sis_3316/sis_3316.c:1312) >> >> >> >> >>> >>> >>> >>> Best greetings >>> >>> G?nter >>> >>> >>> >>> > ____________________________________________________________________________ >>> Von: subexp-daq im Auftrag von > H?kan >>> T Johansson >>> Gesendet: Dienstag, 23. Januar 2024 12:32:50 >>> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >>> Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, >>> DRASI, etc. were updated >>> >>> Dear G?nter, >>> >>> On Tue, 23 Jan 2024, Weber, Guenter Dr. wrote: >>> >>> > as far as I know we never touched the SIS3316 firmware. But, as you know >>> by >>> > now, I know every little about the details of our DAQ, unfortunately. >>> >>> Could you for the other DAQ system (with working SIS3316), check the >>> output at startup or module re-init corresponding to these lines: >>> >>> 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x00800178. >>> 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x3316200e. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x0125000c. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x0125000c. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x0125000c. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x0125000c. >>> >>> 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. >>> 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x01250011. >>> 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x01250011. >>> >>> and see what versions those modules have loaded? >>> >>> Cheers, >>> H?kan >>> >>> >> > -- > 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: From hans.tornqvist at chalmers.se Wed Jan 24 12:37:25 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Wed, 24 Jan 2024 12:37:25 +0100 Subject: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated In-Reply-To: <35b1c34ea9e14282807f085fc893c0a5@hi-jena.gsi.de> References: <7c373d090c5f4520a3e01a51721e68a8@hi-jena.gsi.de> <2d0ecc20c1ee4921b5ed807b41251fe5@hi-jena.gsi.de> <8fb50894-080f-4bf8-8ed3-f7a965de1b55@chalmers.se> <266475039f5d41fc9c8247714820854a@hi-jena.gsi.de> <2a94c163-aeb5-4336-bfe0-44d89172ec99@chalmers.se> <3aad99c7-e61b-47eb-8dcd-f7f872c56d33@chalmers.se> <9b98f1d3-dfbb-4a99-bb6c-7d658048ad83@chalmers.se> <09e3707e3d5844e8a6ded8b78b70358d@hi-jena.gsi.de> <36e8dae7-13cb-9258-99f3-4c5f2004c2a7@chalmers.se> <929564d321f54545b6abb2a24c9c6162@hi-jena.gsi.de> <16a7c247-a7ab-3217-d905-27e3264432da@chalmers.se> <1dac3e9e97924dfb98369b0c740f6a56@hi-jena.gsi.de> <35b1c34ea9e14282807f085fc893c0a5@hi-jena.gsi.de> Message-ID: <1bee9cda-9fe6-4d13-adea-702f32c506f4@chalmers.se> Dear G?nter, This is puzzling... To explain: If r3bfuser.cfg has wr_id set, the init phase will query nurdlib for modules that can deliver timestamps. This error message will show up if no timestamping module was found and the process will abort. Init must finish before the readout loop can start. So, if wr_id is set and both vulom and vetar are commented, the DAQ should abort. Should not matter how the sis3316 is configured. If you let any of vulom or vetar uncommented, init will query first the vetar and then the vulom. This happens in r3bfuser.c starting on line 722. I would suggest that you either comment out wr_id in r3bfuser.cfg, or you put back the vulom in main.cfg. Since the vetar has other problems let's ignore it for now. Best regards, Hans On 2024-01-24 11:48, Weber, Guenter Dr. wrote: > Small update: > > > If no channel of the SIS3316 module is not read out, then the DAQ is > running smoothly. As soon as I want to read out one channel, the error > message is triggered. > > > > > Best greetings > > G?nter > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > Weber, Guenter Dr. > *Gesendet:* Mittwoch, 24. Januar 2024 11:23:19 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > TRLOII, DRASI, etc. were updated > > Dear friends, > > > I now wanted to turn thing around and only have a single SIS3316 module > in the DAQ. So I commented out the VULOM in main.cfg. However, now the > r3bfuser.cfg needs to change, I guess. > > > 5: f_user.c:745: User set WR ID=0x200, but no WR-capable module > configured for nurdlib! > > > What would be the correct R3B setting now with just a SIS3316 module in > main.cfg? Or is the way to go, not to comment out the complete VULOM > entry but just the timestamp and ecl options, i. e. having only > > > ? ? GSI_VETAR(0x50000000) { > ? ? # ? dactl = false > ? ? # ? direct = false > ? ? } > > > ? > > > > > Best greetings > > G?nter > > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > H?kan T Johansson > *Gesendet:* Mittwoch, 24. Januar 2024 06:42:24 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, > TRLOII, DRASI, etc. were updated > > Dear G?nter, > > before you do a lot of module surgery: > > given that the merge of the changes you had in nurdlib in the 'old' but > working daq into current nurdlib was a veritable monster, we have figured > that those need to be more carefully considered, piece-by-piece.? With > some luck, some inadvertent mistake in the merge operation is perhaps > found. > > This might take a few days... > > If that does not work, one can dump the full register set in the modules > in both the 'old' and 'new' daqs after setup and compare those, which > would then hopefully hint at what is not the same. > > But the code inspection is a safer long-term approach, so we prefer to do > that first. > > Best regards, > H?kan > > > > On Tue, 23 Jan 2024, Hans Toshihide T?rnqvist wrote: > >> Dear G?nter, >> >> Are you using different main.cfg files for the new and old DAQ? >> >> Could you add "log_level = verbose" or "log_level = debug" in the new >> main.cfg if it's not there? That should print a lot more information. >> >> Note that all that text ends up in the log, have a look at it so it does >> not explode in size, especially if you set " = debug"! >> >> Please try to recreate the crate setup with the same firmware versions >> and addresses etc like before, that will reduce the number of free >> variables in the testing. >> >> Best regards, >> Hans >> >> >> On 2024-01-23 16:12, Weber, Guenter Dr. wrote: >>> Dear H?kan, >>> >>> >>> the ADC firmware is printed right after the firmware of the VME module: >>> >>> >>> 0: a:1: ..Serial number=0x00800172. (module/sis_3316/sis_3316.c:1305) >>> 10: a:1: ..id/firmware=0x33162010. (module/sis_3316/sis_3316.c:1312) >>> 10: a:1: ..adc[0] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) >>> 11: a:1: ..adc[0] has 16 bits. (module/sis_3316/sis_3316.c:1322) >>> 10: a:1: ..adc[1] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) >>> 11: a:1: ..adc[1] has 16 bits. (module/sis_3316/sis_3316.c:1322) >>> 10: a:1: ..adc[2] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) >>> 11: a:1: ..adc[2] has 16 bits. (module/sis_3316/sis_3316.c:1322) >>> 10: a:1: ..adc[3] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315) >>> 11: a:1: ..adc[3] has 16 bits. (module/sis_3316/sis_3316.c:1322) >>> >>> >>> and >>> >>> >>> 10: a:1: ..Serial number=0x00800170. (module/sis_3316/sis_3316.c:1305) >>> 10: a:1: ..id/firmware=0x3316a012. (module/sis_3316/sis_3316.c:1312) >>> 10: a:1: ..adc[0] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) >>> 11: a:1: ..adc[0] has 16 bits. (module/sis_3316/sis_3316.c:1322) >>> 10: a:1: ..adc[1] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) >>> 11: a:1: ..adc[1] has 16 bits. (module/sis_3316/sis_3316.c:1322) >>> 10: a:1: ..adc[2] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) >>> 11: a:1: ..adc[2] has 16 bits. (module/sis_3316/sis_3316.c:1322) >>> 10: a:1: ..adc[3] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315) >>> 11: a:1: ..adc[3] has 16 bits. (module/sis_3316/sis_3316.c:1322) >>> >>> >>> We never had look at the firmware and also exchanged or six SIS3316 >>> modules for each other. Thus, my assumption is that differences in the >>> firmware number should not matter. But of course, I am not sure about this. >>> >>> >>> What puzzles me right now is the fact, that on the old system we get so >>> much more output on the command line. On the new system it is just the >>> SIS3316 firmware information and, for some reason, the threshold >>> settings (out of a ton of various setting options for this type of module). >>> >>> >>> >>> >>> >>> Best greetings >>> >>> G?nter >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> *Von:* subexp-daq im Auftrag von >>> H?kan T Johansson >>> *Gesendet:* Dienstag, 23. Januar 2024 14:15:41 >>> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. >>> *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB, >>> TRLOII, DRASI, etc. were updated >>> >>> Dear G?nter, >>> >>> how about the lines '..adc[0] firmware=' ?? The ADC FPGAs have a different >>> image than the VME FPGA. >>> >>> Perhaps they were not present with the older software..? >>> >>> I do not know much about the SSI3316 firmware versions, but from the looks >>> of it, we have at least three different ones at hand so far for the VME >>> FPGA: >>> >>> 0x3316200e, 0x33162010, 0x3316a012 >>> >>> Best regards, >>> H?kan >>> >>> >>> On Tue, 23 Jan 2024, Weber, Guenter Dr. wrote: >>> >>>> >>>> Dear friends, >>>> >>>> >>>> attached please find the output of the old system. To me it looks as if >>>> every single setting of the SIS3316 modules is printed to screen. In total >>>> almost 2000 lines for just two modules. >>>> >>>> >>>> I find the following serial number entries: >>>> >>>> >>>> Line 701: >>>> >>>> 10: a:1: ..Serial number=0x00800172. (module/sis_3316/sis_3316.c:1305) >>>> 10: a:1: ..id/firmware=0x33162010. (module/sis_3316/sis_3316.c:1312) >>>> >>>> >>>> Line 796: >>>> >>>> 10: a:1: ..Serial number=0x00800170. (module/sis_3316/sis_3316.c:1305) >>>> 10: a:1: ..id/firmware=0x3316a012. (module/sis_3316/sis_3316.c:1312) >>> >>> >>> >>> >>>> >>>> >>>> >>>> Best greetings >>>> >>>> G?nter >>>> >>>> >>>> >>>> >> ____________________________________________________________________________ >>>> Von: subexp-daq im Auftrag von >> H?kan >>>> T Johansson >>>> Gesendet: Dienstag, 23. Januar 2024 12:32:50 >>>> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >>>> Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, >>>> DRASI, etc. were updated >>>> >>>> Dear G?nter, >>>> >>>> On Tue, 23 Jan 2024, Weber, Guenter Dr. wrote: >>>> >>>> > as far as I know we never touched the SIS3316 firmware. But, as you know >>>> by >>>> > now, I know every little about the details of our DAQ, unfortunately. >>>> >>>> Could you for the other DAQ system (with working SIS3316), check the >>>> output at startup or module re-init corresponding to these lines: >>>> >>>> 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x00800178. >>>> 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x3316200e. >>>> 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x0125000c. >>>> 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x0125000c. >>>> 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x0125000c. >>>> 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x0125000c. >>>> >>>> 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7. >>>> 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010. >>>> 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011. >>>> 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011. >>>> 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x01250011. >>>> 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x01250011. >>>> >>>> and see what versions those modules have loaded? >>>> >>>> Cheers, >>>> H?kan >>>> >>>> >>> >> -- >> subexp-daq mailing list >> subexp-daq at lists.chalmers.se >> https://lists.chalmers.se/mailman/listinfo/subexp-daq > >> > From g.weber at hi-jena.gsi.de Wed Jan 31 17:33:46 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Wed, 31 Jan 2024 16:33:46 +0000 Subject: [subexp-daq] Adding a new module type to NURDLIB Message-ID: <6698a39c37734766906e7e9632d27392@hi-jena.gsi.de> Dear Hans, dear H?kan, I would like to integrate a new module into NURDLIB. It is the V767A TDC from CEAN. In NURDLIB there is a folder "dummy". Should one use this as a template? How to decide if a module is 'distinguishable'? And is there anything else one should keep in mind before starting to play around? Thank you very much! Best greetings G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.tornqvist at chalmers.se Wed Jan 31 18:43:37 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Wed, 31 Jan 2024 18:43:37 +0100 Subject: [subexp-daq] Adding a new module type to NURDLIB In-Reply-To: <6698a39c37734766906e7e9632d27392@hi-jena.gsi.de> References: <6698a39c37734766906e7e9632d27392@hi-jena.gsi.de> Message-ID: Dear G?nter, I would suggest that you take a look at the v560 implementation, it looks like a somewhat similar Caen module. Distinguishable means if one can distinguish it from another module mainly by looking at the first word in the data. This is used to determine whether barriers will be needed between certain groupings of modules. For example: module-1 header description: Bits 24..31 = module ID Bits 16..23 = 0 module-2 header description: Bits 24..31 = module ID Bits 16..23 = 0 module-3 header description: Bits 24..31 = Serial-number Bits 16..23 = 1 module-4 header description: Bits 24..31 = Serial-number Bits 16..23 = module ID First, if nurdlib knows about the module ID of some electronics (e.g. the GEO of Caen modules), it will throw an error and quit if two modules somehow got the same ID. Typically it can be set by software and nurdlib keeps a counter to assign unique ID's. module-1 and module-2 can be easily distinguished by the module ID, but also by bits 16..23, so they are def. distinguishable. module-1 and module-3 can be via bits 16..23. The module ID is useless here since the serial-number could probably take any value. module-3 against itself would not be very safe however in case the same serial-number was used for reasons out of our control! module-1 and module-4 are not distinguishable since there's no way to guarantee that the bits explained here do not collide. If you are not certain, you could say that the v767 is not distinguishable with any other module type, not even against itself. Have a quick look at the other Caen implementations to get an idea. This could be maintained better with masking module ID's and fixed bits, which is on my todo... I'll put this explanation in the wip manual. Other than that, the different functions are explained quite well in module/module.h. So far the module implementations by other people have worked quite well, so there's probably not too much to worry about. I haven't been able to find a solid moment to go through the sis3316 code yet. Cheers, Hans On 2024-01-31 17:33, Weber, Guenter Dr. wrote: > Dear Hans, dear H?kan, > > > I would like to integrate a new module into NURDLIB. It is the V767A TDC > from CEAN. > > > In NURDLIB there is a folder "dummy". Should one use this as a template? > How to decide if a module is 'distinguishable'? And is there anything > else one should keep in mind before starting to play around? > > > > Thank you very much! > > > > > Best greetings > > G?nter > > > > >