From g.weber at hi-jena.gsi.de Wed Apr 3 19:21:35 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Wed, 3 Apr 2024 17:21:35 +0000 Subject: [subexp-daq] Question on UCESB Message-ID: <9915e48ab12d433da8d117409071b138@hi-jena.gsi.de> Dear friends, we now had a brief look into UCESB and UPEXPS. Is our intepretation correct, that *.spec-Files are used for mapping between the raw data within an LMD event and "interpreted" data that is then used for further analysis? If true, why is the folder SPEC containing only spec files for a few of the modules available in NURDLIB? Is it just the case that nobody found time yet or is there a design decision behind this? We are now ondering what is the best wyo add a spec file for the new module that we added to NURDLIB. Also, if this made sense, we could add a spec file for the STRUCK digitizers whcih currently does only exist within UPEXPS. To us there it is not really clear where UCESB ends and UPEXPS begins. Could you explain what exactly is the purpose of both packages? What is UPEXPS doing that could/should not be a part of UCESB? Thank you very much! Best greetings G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Thu Apr 4 06:39:32 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Thu, 4 Apr 2024 06:39:32 +0200 Subject: [subexp-daq] Question on UCESB In-Reply-To: <9915e48ab12d433da8d117409071b138@hi-jena.gsi.de> References: <9915e48ab12d433da8d117409071b138@hi-jena.gsi.de> Message-ID: On Wed, 3 Apr 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > we now had a brief look into UCESB and UPEXPS. > > > Is our intepretation correct, that *.spec-Files are used for mapping between > the raw data within an LMD event and "interpreted" data that is then used > for further analysis? Yes. The .spec files contain the data format descriptions, and also the mappings of channel names (in the SIGNAL statements). > If true, why is the folder SPEC containing only spec > files for a few of the modules available in NURDLIB? The ucesb/spec/ directory comntain files where I or users have sent me patches/commits with those data format specifications. > Is it just the case > that nobody found time yet or is there a design decision behind this? If users place / keep them elsewhere (like e.g. upexps) longterm, there is not much I can do... :-) Not a design decision. Except that the stuff in (the generic spec/ directory) should not be experiment specific. > We are > now ondering what is the best wyo add a spec file for the new module that we > added to NURDLIB. Sure! Yes, please! > Also, if this made sense, we could add a spec file for the > STRUCK digitizers whcih currently does only exist within UPEXPS. Yes. But we also need to know where it came from, since ucesb is publically available, and just for good form want to keep the license in order. I do want to make a mess like this, but to avoid issues down the road. > To us there it is not really clear where UCESB ends and UPEXPS begins. Could > you explain what exactly is the purpose of both packages? What is UPEXPS > doing that could/should not be a part of UCESB? Generally, ucesb/ is (expect for the fast that it has some (old) example and test directories, not experiment-specific. upexps (or any other user repo) would contain the signal mappings for sure. Some .spec files would likely be better to have somewhere under ucesb/spec/ Cheers, H?kan From f96hajo at chalmers.se Thu Apr 4 07:02:18 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Thu, 4 Apr 2024 07:02:18 +0200 Subject: [subexp-daq] Nupeline In-Reply-To: <5816b34eeacbe0edbdc93f889c9c34d1c145f613.camel@ikp.tu-darmstadt.de> References: , <241125ce-60af-a7b7-f94a-096376b519b1@chalmers.se> <6838bc02e7e44974939bcc385b4f1d02@hi-jena.gsi.de> <5816b34eeacbe0edbdc93f889c9c34d1c145f613.camel@ikp.tu-darmstadt.de> Message-ID: <1330b176-6a1a-400d-c094-e6fc649c14d4@chalmers.se> Dear Oliver and G?nter, just a suggestion, since you are at least two users of nupeline and may benefit from each other: Perhaps it would be an idea to have the code available at e.g. an gitlab.com group nupeline (or something such). At least the 'nupeline' repository has a license (MIT) that makes it possible to have it public. For 'nupeline.configs' and 'nupeline.examples' this is however not clear. Perhaps Bastii can clarify that situation? One could also think to only use parts of those repositories if there are parts that are unclear license-wise. The reason for wanting also the examples is that they then can form the basis of CI testing, which would prevent unintentional breaking of them in the generic (nupeline) code. Then you could also add the codes that you use locally as either more repositories, or as new parts of e.g. 'nupeline.examples' to again avoid generic changes to break them, by including them in CI builds. I do not want to offer that I do anything here, but I could help with getting the CI working. And possibly vet merge requests into a 'master' branch. But that would not be maintenance, just based on look-and-feel and CI success. It would be much better if someone that uses the code would do that job. For starters, it sounds like were are not talking about much commits anyhow. Who knows - nupeline might get a life of its own? ;) Cheers, H?kan On Fri, 22 Mar 2024, Oliver Papst wrote: > Dear G?nter, > > I am another user of nupeline. We use it both in Darmstadt for the DHIPS setup > and at HI?S, Duke University, for our experiments using the Clover array setup. > > I have created several boxes myself, but I don?t have the capacity to put any > work into nupeline myself. I just use it as-it-is. For lack of a better > alternative that is known to us, we will continue to use it for now. I would > also prefer using something that is actively maintained, though. > > Cheers, > > Oliver > > On Fri, 2024-03-22 at 16:49 +0000, Weber, Guenter Dr. wrote: >> Dear H?kan, >> >> >> thank you very much for the explanations. >> >> >> To be independent from Bastian's legacy code we have now our tailor made unpacker for some of the LMD data. If we found a way to feed it not only with files from hard disk but also the data stream provided by UCESB, we could also use it for online analysis. We could then adapt this unpacker to the specific structure of our experimental data. >> >> >> However, as UCESB itself is (as I understand) an unpacker for LMD data, probably the better way would be to use UCESB for basic unpacking into LMD events/subevents and then as a second stage a dedicated mapper (which in an ideal world would result from the settings of the modules in main.cfg) to interpret the data words. This is (again: as I understand it) the approach taken by Bastian. This second stage could then curate/organize the data and give it to subsequent programs in a more user-friendly data format than plain LMD structures. >> >> >> However, I see little use to invest time into the existing NUPELINE package if Bastian was basicly the only person maintaining it. Is there maybe something else 'on the market'? Or am I mistaken and there is somebody out there, who is also continuing to use NUPELINE? >> >> >> (Sorry, if this e-mail is a bit repetitive. I just want to make sure that my understanding of the situation is correct.) >> >> >> >> >> Best greetings >> >> G?nter >> >> >> >> >> ________________________________ >> Von: subexp-daq im Auftrag von H?kan T Johansson >> Gesendet: Freitag, 22. M?rz 2024 13:06 >> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> Betreff: Re: [subexp-daq] Question on UCESB / UPEXPS >> >> >> Dear G?nter, >> >> feel free to respond to issues separately, it was quite a bunch of >> questions :-) (I like!) >> >> On Fri, 22 Mar 2024, Weber, Guenter Dr. wrote: >> >> > >> > Dear friends, >> > >> > >> > we have now checked the code for the SIS3316 module and will push a version >> > with some bug fixes soon. >> >> That is excellent news! >> >> > The next thing on our list is to understand how we can access and store the >> > data that we produce. Bastian told us the following command to write LMD >> > files to hard disk: >> > >> > >> > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/drasi/bin/lwrocctrl >> > localhost --file-open=auto=1Gi,${file} >> > >> > How does this LWROCCTRL work together with the Event Builder and UCESB which >> > are started by the following commands? >> > >> > ../drasi/bin/lwrocmerge \ >> > --label=MCAL_EB \ >> > --merge-mode=event \ >> > --server=trans,flush=1 \ >> > --server=stream,flush=1 \ >> > --buf=size=800Mi \ >> > --max-ev-size=10Mi \ >> > --eb-master=rio4-mcal-2 \ >> > --file-writer \ >> > --drasi=rio4-mcal-2 >> > >> > ------------------------------------ >> >> lwrocctrl works by communicating with drasi instances. >> for the lwrocctrl --file... options, it should be an instance which has a >> --file-writer specified. >> >> You can run the lwrocctrl also from another machine (e.g. your PC), but >> then instead of 'localhost' give the name (or IP) of the machine where the >> instance is running. >> >> For the communication to work, both have to find a directory >> ~/.drasi_tokens/ with one or more common files which it will do a cheap >> hash of. That is just some very minor protection against mistakes (users >> talking with the wrong machine. It is not a security measure as such. >> >> To see if an instance is willing to talk, you can try >> >> PATH-TO-DRASI/bin/bin/lwrocctrl --file-status [node] >> >> > >> > while : >> > do >> > ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ >> > stream://localhost \ >> > --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 >> > sleep 5 >> > done >> >> That connects to the server above (lwrocmerge) started with >> --server=stream. >> >> And its --server option means it will act as a kind of proxy server. I.e. >> other users that want data can connect to that instead of directly to the >> DAQ process. >> >> > Moreover, to read in the online data stream as well as the LMD files from >> > disk, to us it looks like Bastian used a programm called UCESB_IN which is >> > using a mapping that is defined within UPEXPS to interpret the content of >> > the LMD files. To us it looks like UCESB_IN is like a wrapper for UCESB to >> > do a mapping of the content of the LMD events and to send out a data stream >> > of some of this content. Attached please find the configuration file for >> > UCESB_IN. >> >> The attached .cfg file looks like a setup for Bastii's nupeline, which I >> have very little clue about. >> >> Indeed it sure looks like it in turn uses an UCESB unpacker. With the >> source in upexps. That (upexps) has maintenance issues. >> >> Perhaps someone else reading this mailing list is also using unpackers >> from the upexps? If so, now would be a good time to speak up, because I >> think we need to figure out how to have something backwards compatible and >> maintainable for you, without being 'encouraged' to do the maintenance >> work that other users at GSI (R3B) refuse to do... >> >> > Here, we are not sure up to which point there is a common approach to read >> > experimental data and beyond that everybody is on his own. >> >> ... while still sharing as much as possible with other users. >> >> > Many thanks and best greetings from Jena >> > G?nter >> >> Cheers, >> H?kan > > -- > subexp-daq mailing list > subexp-daq at lists.chalmers.se > https://lists.chalmers.se/mailman/listinfo/subexp-daq From B.Loeher at gsi.de Thu Apr 4 10:55:15 2024 From: B.Loeher at gsi.de (Loeher, Bastian Dr.) Date: Thu, 4 Apr 2024 08:55:15 +0000 Subject: [subexp-daq] Nupeline In-Reply-To: <1330b176-6a1a-400d-c094-e6fc649c14d4@chalmers.se> References: , <241125ce-60af-a7b7-f94a-096376b519b1@chalmers.se> <6838bc02e7e44974939bcc385b4f1d02@hi-jena.gsi.de> <5816b34eeacbe0edbdc93f889c9c34d1c145f613.camel@ikp.tu-darmstadt.de>, <1330b176-6a1a-400d-c094-e6fc649c14d4@chalmers.se> Message-ID: <22258ca7-834d-43d7-95ca-265f2644ca32@email.android.com> Hi everyone, I could make all related repositories freely available and put respective licenses on the repositories where they are missing. None of the code has unclear origins. Where would be a good place? I could even put it up on github.com. Cheers Bastii Am 04.04.2024 07:02 schrieb H?kan T Johansson : Dear Oliver and G?nter, just a suggestion, since you are at least two users of nupeline and may benefit from each other: Perhaps it would be an idea to have the code available at e.g. an gitlab.com group nupeline (or something such). At least the 'nupeline' repository has a license (MIT) that makes it possible to have it public. For 'nupeline.configs' and 'nupeline.examples' this is however not clear. Perhaps Bastii can clarify that situation? One could also think to only use parts of those repositories if there are parts that are unclear license-wise. The reason for wanting also the examples is that they then can form the basis of CI testing, which would prevent unintentional breaking of them in the generic (nupeline) code. Then you could also add the codes that you use locally as either more repositories, or as new parts of e.g. 'nupeline.examples' to again avoid generic changes to break them, by including them in CI builds. I do not want to offer that I do anything here, but I could help with getting the CI working. And possibly vet merge requests into a 'master' branch. But that would not be maintenance, just based on look-and-feel and CI success. It would be much better if someone that uses the code would do that job. For starters, it sounds like were are not talking about much commits anyhow. Who knows - nupeline might get a life of its own? ;) Cheers, H?kan On Fri, 22 Mar 2024, Oliver Papst wrote: > Dear G?nter, > > I am another user of nupeline. We use it both in Darmstadt for the DHIPS setup > and at HI?S, Duke University, for our experiments using the Clover array setup. > > I have created several boxes myself, but I don?t have the capacity to put any > work into nupeline myself. I just use it as-it-is. For lack of a better > alternative that is known to us, we will continue to use it for now. I would > also prefer using something that is actively maintained, though. > > Cheers, > > Oliver > > On Fri, 2024-03-22 at 16:49 +0000, Weber, Guenter Dr. wrote: >> Dear H?kan, >> >> >> thank you very much for the explanations. >> >> >> To be independent from Bastian's legacy code we have now our tailor made unpacker for some of the LMD data. If we found a way to feed it not only with files from hard disk but also the data stream provided by UCESB, we could also use it for online analysis. We could then adapt this unpacker to the specific structure of our experimental data. >> >> >> However, as UCESB itself is (as I understand) an unpacker for LMD data, probably the better way would be to use UCESB for basic unpacking into LMD events/subevents and then as a second stage a dedicated mapper (which in an ideal world would result from the settings of the modules in main.cfg) to interpret the data words. This is (again: as I understand it) the approach taken by Bastian. This second stage could then curate/organize the data and give it to subsequent programs in a more user-friendly data format than plain LMD structures. >> >> >> However, I see little use to invest time into the existing NUPELINE package if Bastian was basicly the only person maintaining it. Is there maybe something else 'on the market'? Or am I mistaken and there is somebody out there, who is also continuing to use NUPELINE? >> >> >> (Sorry, if this e-mail is a bit repetitive. I just want to make sure that my understanding of the situation is correct.) >> >> >> >> >> Best greetings >> >> G?nter >> >> >> >> >> ________________________________ >> Von: subexp-daq im Auftrag von H?kan T Johansson >> Gesendet: Freitag, 22. M?rz 2024 13:06 >> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> Betreff: Re: [subexp-daq] Question on UCESB / UPEXPS >> >> >> Dear G?nter, >> >> feel free to respond to issues separately, it was quite a bunch of >> questions :-) (I like!) >> >> On Fri, 22 Mar 2024, Weber, Guenter Dr. wrote: >> >> > >> > Dear friends, >> > >> > >> > we have now checked the code for the SIS3316 module and will push a version >> > with some bug fixes soon. >> >> That is excellent news! >> >> > The next thing on our list is to understand how we can access and store the >> > data that we produce. Bastian told us the following command to write LMD >> > files to hard disk: >> > >> > >> > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/drasi/bin/lwrocctrl >> > localhost --file-open=auto=1Gi,${file} >> > >> > How does this LWROCCTRL work together with the Event Builder and UCESB which >> > are started by the following commands? >> > >> > ../drasi/bin/lwrocmerge \ >> > --label=MCAL_EB \ >> > --merge-mode=event \ >> > --server=trans,flush=1 \ >> > --server=stream,flush=1 \ >> > --buf=size=800Mi \ >> > --max-ev-size=10Mi \ >> > --eb-master=rio4-mcal-2 \ >> > --file-writer \ >> > --drasi=rio4-mcal-2 >> > >> > ------------------------------------ >> >> lwrocctrl works by communicating with drasi instances. >> for the lwrocctrl --file... options, it should be an instance which has a >> --file-writer specified. >> >> You can run the lwrocctrl also from another machine (e.g. your PC), but >> then instead of 'localhost' give the name (or IP) of the machine where the >> instance is running. >> >> For the communication to work, both have to find a directory >> ~/.drasi_tokens/ with one or more common files which it will do a cheap >> hash of. That is just some very minor protection against mistakes (users >> talking with the wrong machine. It is not a security measure as such. >> >> To see if an instance is willing to talk, you can try >> >> PATH-TO-DRASI/bin/bin/lwrocctrl --file-status [node] >> >> > >> > while : >> > do >> > ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ >> > stream://localhost \ >> > --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 >> > sleep 5 >> > done >> >> That connects to the server above (lwrocmerge) started with >> --server=stream. >> >> And its --server option means it will act as a kind of proxy server. I.e. >> other users that want data can connect to that instead of directly to the >> DAQ process. >> >> > Moreover, to read in the online data stream as well as the LMD files from >> > disk, to us it looks like Bastian used a programm called UCESB_IN which is >> > using a mapping that is defined within UPEXPS to interpret the content of >> > the LMD files. To us it looks like UCESB_IN is like a wrapper for UCESB to >> > do a mapping of the content of the LMD events and to send out a data stream >> > of some of this content. Attached please find the configuration file for >> > UCESB_IN. >> >> The attached .cfg file looks like a setup for Bastii's nupeline, which I >> have very little clue about. >> >> Indeed it sure looks like it in turn uses an UCESB unpacker. With the >> source in upexps. That (upexps) has maintenance issues. >> >> Perhaps someone else reading this mailing list is also using unpackers >> from the upexps? If so, now would be a good time to speak up, because I >> think we need to figure out how to have something backwards compatible and >> maintainable for you, without being 'encouraged' to do the maintenance >> work that other users at GSI (R3B) refuse to do... >> >> > Here, we are not sure up to which point there is a common approach to read >> > experimental data and beyond that everybody is on his own. >> >> ... while still sharing as much as possible with other users. >> >> > Many thanks and best greetings from Jena >> > G?nter >> >> 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 Thu Apr 4 20:47:19 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Thu, 4 Apr 2024 18:47:19 +0000 Subject: [subexp-daq] Question on UCESB In-Reply-To: References: <9915e48ab12d433da8d117409071b138@hi-jena.gsi.de>, Message-ID: <175903985aa0446e8502a40b06ecec43@hi-jena.gsi.de> Dear friends, we now (think that we have) understoof how *.spec-Files work. For a minimum setup with just the VULOM (Timestamp and 16 scaler channels) we compiled out own UCESB example. The output of an event looks like this: Event 203 Type/Subtype 10 1 Size 140 Trigger 1 SubEv ProcID 1 Type/Subtype 10 1 Size 24 Ctrl 9 Subcrate 1 00000200 03e1a48c 04e1e9dd 05e109e1 06e10000 f1a2000a SubEv ProcID 1 Type/Subtype 20 2 Size 84 Ctrl 9 Subcrate 1 80000000 660ebf44 000009e1 e9dda48c 00000010 0001a871 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 Event 203 Trigger 1 .RAW.TIMESTAMP.VULOM.HI: 0x000009e1=2529 .RAW.TIMESTAMP.VULOM.LO: 0xe9dda48c=-371350388 .RAW.VULOM.SCALER[0]: 0x0001a871=108657 .RAW.VULOM.SCALER[1]: 0x00000000=0 .RAW.VULOM.SCALER[2]: 0x00000000=0 .RAW.VULOM.SCALER[3]: 0x00000000=0 .RAW.VULOM.SCALER[4]: 0x00000000=0 .RAW.VULOM.SCALER[5]: 0x00000000=0 .RAW.VULOM.SCALER[6]: 0x00000000=0 .RAW.VULOM.SCALER[7]: 0x00000000=0 .RAW.VULOM.SCALER[8]: 0x00000001=1 .RAW.VULOM.SCALER[9]: 0x00000001=1 .RAW.VULOM.SCALER[10]: 0x00000001=1 .RAW.VULOM.SCALER[11]: 0x00000001=1 .RAW.VULOM.SCALER[12]: 0x00000001=1 .RAW.VULOM.SCALER[13]: 0x00000001=1 .RAW.VULOM.SCALER[14]: 0x00000001=1 .RAW.VULOM.SCALER[15]: 0x00000001=1 (produced with "--data --dump=RAW --print") We now would like to take the easisest possible route to transport the RAW data to Pyhton, where our main analysis is living. Unfortunately, ext_data_client.h and the code behind it does not really feel inviting to be converted into Python. Is there any other way to generate a data stream from UCESB? So far, we had only success with writing the data into a ROOT file and then using uproot in Pyhton to read the file. But this is no solution for online analysis where we would need a data stream. We also had a look how Bastian did this with UCESB_IN (part of NUPELINE), but we felt a bit overwhelmed. Idealy, we could access the data stream from UCESB with such a simple Python code: import socket import sys import numpy as np sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server_address = ("10.141.184.131", 8001) print(sys.stderr, 'connecting to %s port %s' % server_address) sock.connect(server_address) print("Connected") data = sock.recv(80) print( data ) t = np.dtype('u4, u4, u8, (16)u4') /* for our test data: trigger type, event number, timestamp, 16 scaler channels */ a = np.frombuffer(data, dtype=t) sock.close() However, of course just get 'a magic word' from UCESB as we have not implemented the correct protocoll to acccess the data. In an idea case, we would be able to avoid implementing this protocoll (or find an easy way to do it). Thank you very much and best greetings from Jena. G?nter ---------------- G?nter Weber Helmholtz-Institut Jena Fr?belstieg 3 07743 Jena Germany Phone: +49-3641-947605 www.hi-jena.de GSI Helmholtzzentrum f?r Schwerionenforschung Planckstrasse 1 64291 Darmstadt Germany www.gsi.de ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Donnerstag, 4. April 2024 06:39:32 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] Question on UCESB On Wed, 3 Apr 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > we now had a brief look into UCESB and UPEXPS. > > > Is our intepretation correct, that *.spec-Files are used for mapping between > the raw data within an LMD event and "interpreted" data that is then used > for further analysis? Yes. The .spec files contain the data format descriptions, and also the mappings of channel names (in the SIGNAL statements). > If true, why is the folder SPEC containing only spec > files for a few of the modules available in NURDLIB? The ucesb/spec/ directory comntain files where I or users have sent me patches/commits with those data format specifications. > Is it just the case > that nobody found time yet or is there a design decision behind this? If users place / keep them elsewhere (like e.g. upexps) longterm, there is not much I can do... :-) Not a design decision. Except that the stuff in (the generic spec/ directory) should not be experiment specific. > We are > now ondering what is the best wyo add a spec file for the new module that we > added to NURDLIB. Sure! Yes, please! > Also, if this made sense, we could add a spec file for the > STRUCK digitizers whcih currently does only exist within UPEXPS. Yes. But we also need to know where it came from, since ucesb is publically available, and just for good form want to keep the license in order. I do want to make a mess like this, but to avoid issues down the road. > To us there it is not really clear where UCESB ends and UPEXPS begins. Could > you explain what exactly is the purpose of both packages? What is UPEXPS > doing that could/should not be a part of UCESB? Generally, ucesb/ is (expect for the fast that it has some (old) example and test directories, not experiment-specific. upexps (or any other user repo) would contain the signal mappings for sure. Some .spec files would likely be better to have somewhere under ucesb/spec/ Cheers, H?kan -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.weber at hi-jena.gsi.de Thu Apr 4 21:06:31 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Thu, 4 Apr 2024 19:06:31 +0000 Subject: [subexp-daq] Question on UCESB In-Reply-To: <175903985aa0446e8502a40b06ecec43@hi-jena.gsi.de> References: <9915e48ab12d433da8d117409071b138@hi-jena.gsi.de>, , <175903985aa0446e8502a40b06ecec43@hi-jena.gsi.de> Message-ID: P.S. A follow-up question: In UCESB manual there is some example code on page 65 (listing 6.2), where we find: #define EXT_EVENT_STRUCT EXT_STR_h101 #define EXT_EVENT_STRUCT_LAYOUT EXT_STR_h101_layout #define EXT_EVENT_STRUCT_LAYOUT_INIT EXT_STR_h101_LAYOUT_INIT However, the jena_test.hh created by our UCESB does only have typedef struct EXT_STR_h101_t and typedef struct EXT_STR_h101_onion_t. >From where could we get _layout and LAYOUT_INIT for our test case? Thank you very much! Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von Weber, Guenter Dr. Gesendet: Donnerstag, 4. April 2024 20:47:19 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] Question on UCESB Dear friends, we now (think that we have) understoof how *.spec-Files work. For a minimum setup with just the VULOM (Timestamp and 16 scaler channels) we compiled out own UCESB example. The output of an event looks like this: Event 203 Type/Subtype 10 1 Size 140 Trigger 1 SubEv ProcID 1 Type/Subtype 10 1 Size 24 Ctrl 9 Subcrate 1 00000200 03e1a48c 04e1e9dd 05e109e1 06e10000 f1a2000a SubEv ProcID 1 Type/Subtype 20 2 Size 84 Ctrl 9 Subcrate 1 80000000 660ebf44 000009e1 e9dda48c 00000010 0001a871 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 Event 203 Trigger 1 .RAW.TIMESTAMP.VULOM.HI: 0x000009e1=2529 .RAW.TIMESTAMP.VULOM.LO: 0xe9dda48c=-371350388 .RAW.VULOM.SCALER[0]: 0x0001a871=108657 .RAW.VULOM.SCALER[1]: 0x00000000=0 .RAW.VULOM.SCALER[2]: 0x00000000=0 .RAW.VULOM.SCALER[3]: 0x00000000=0 .RAW.VULOM.SCALER[4]: 0x00000000=0 .RAW.VULOM.SCALER[5]: 0x00000000=0 .RAW.VULOM.SCALER[6]: 0x00000000=0 .RAW.VULOM.SCALER[7]: 0x00000000=0 .RAW.VULOM.SCALER[8]: 0x00000001=1 .RAW.VULOM.SCALER[9]: 0x00000001=1 .RAW.VULOM.SCALER[10]: 0x00000001=1 .RAW.VULOM.SCALER[11]: 0x00000001=1 .RAW.VULOM.SCALER[12]: 0x00000001=1 .RAW.VULOM.SCALER[13]: 0x00000001=1 .RAW.VULOM.SCALER[14]: 0x00000001=1 .RAW.VULOM.SCALER[15]: 0x00000001=1 (produced with "--data --dump=RAW --print") We now would like to take the easisest possible route to transport the RAW data to Pyhton, where our main analysis is living. Unfortunately, ext_data_client.h and the code behind it does not really feel inviting to be converted into Python. Is there any other way to generate a data stream from UCESB? So far, we had only success with writing the data into a ROOT file and then using uproot in Pyhton to read the file. But this is no solution for online analysis where we would need a data stream. We also had a look how Bastian did this with UCESB_IN (part of NUPELINE), but we felt a bit overwhelmed. Idealy, we could access the data stream from UCESB with such a simple Python code: import socket import sys import numpy as np sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server_address = ("10.141.184.131", 8001) print(sys.stderr, 'connecting to %s port %s' % server_address) sock.connect(server_address) print("Connected") data = sock.recv(80) print( data ) t = np.dtype('u4, u4, u8, (16)u4') /* for our test data: trigger type, event number, timestamp, 16 scaler channels */ a = np.frombuffer(data, dtype=t) sock.close() However, of course just get 'a magic word' from UCESB as we have not implemented the correct protocoll to acccess the data. In an idea case, we would be able to avoid implementing this protocoll (or find an easy way to do it). Thank you very much and best greetings from Jena. G?nter ---------------- G?nter Weber Helmholtz-Institut Jena Fr?belstieg 3 07743 Jena Germany Phone: +49-3641-947605 www.hi-jena.de GSI Helmholtzzentrum f?r Schwerionenforschung Planckstrasse 1 64291 Darmstadt Germany www.gsi.de ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Donnerstag, 4. April 2024 06:39:32 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] Question on UCESB On Wed, 3 Apr 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > we now had a brief look into UCESB and UPEXPS. > > > Is our intepretation correct, that *.spec-Files are used for mapping between > the raw data within an LMD event and "interpreted" data that is then used > for further analysis? Yes. The .spec files contain the data format descriptions, and also the mappings of channel names (in the SIGNAL statements). > If true, why is the folder SPEC containing only spec > files for a few of the modules available in NURDLIB? The ucesb/spec/ directory comntain files where I or users have sent me patches/commits with those data format specifications. > Is it just the case > that nobody found time yet or is there a design decision behind this? If users place / keep them elsewhere (like e.g. upexps) longterm, there is not much I can do... :-) Not a design decision. Except that the stuff in (the generic spec/ directory) should not be experiment specific. > We are > now ondering what is the best wyo add a spec file for the new module that we > added to NURDLIB. Sure! Yes, please! > Also, if this made sense, we could add a spec file for the > STRUCK digitizers whcih currently does only exist within UPEXPS. Yes. But we also need to know where it came from, since ucesb is publically available, and just for good form want to keep the license in order. I do want to make a mess like this, but to avoid issues down the road. > To us there it is not really clear where UCESB ends and UPEXPS begins. Could > you explain what exactly is the purpose of both packages? What is UPEXPS > doing that could/should not be a part of UCESB? Generally, ucesb/ is (expect for the fast that it has some (old) example and test directories, not experiment-specific. upexps (or any other user repo) would contain the signal mappings for sure. Some .spec files would likely be better to have somewhere under ucesb/spec/ Cheers, H?kan -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Thu Apr 4 21:26:26 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Thu, 4 Apr 2024 21:26:26 +0200 Subject: [subexp-daq] Nupeline In-Reply-To: <22258ca7-834d-43d7-95ca-265f2644ca32@email.android.com> References: , <241125ce-60af-a7b7-f94a-096376b519b1@chalmers.se> <6838bc02e7e44974939bcc385b4f1d02@hi-jena.gsi.de> <5816b34eeacbe0edbdc93f889c9c34d1c145f613.camel@ikp.tu-darmstadt.de>, <1330b176-6a1a-400d-c094-e6fc649c14d4@chalmers.se> <22258ca7-834d-43d7-95ca-265f2644ca32@email.android.com> Message-ID: <00205e3e-1def-1edf-968e-87fee4fa1483@chalmers.se> Hi Bastii, How about gitlab.com in a group nupeline ? Then it can re-use the CI scripts that exist already and at least I have more experience with gitlab CI. Besides, github actions (their CI) gave me the creeps when I tried something with r3broot once. By default they were allowed to modify my repositories! Cheers, H?kan On Thu, 4 Apr 2024, Loeher, Bastian Dr. wrote: > Hi everyone, > I could make all related repositories freely available and put respective > licenses on the repositories where they are missing. None of the code has > unclear origins. > > Where would be a good place? I could even put it up on github.com. > > Cheers > Bastii > > Am 04.04.2024 07:02 schrieb H?kan T Johansson : > > Dear Oliver and G?nter, > > just a suggestion, since you are at least two users of nupeline and may > benefit from each other: > > Perhaps it would be an idea to have the code available at e.g. an > gitlab.com group nupeline (or something such). > > At least the 'nupeline' repository has a license (MIT) that makes it > possible to have it public. > > For 'nupeline.configs' and 'nupeline.examples' this is however not clear. > Perhaps Bastii can clarify that situation? > > One could also think to only use parts of those repositories if there are > parts that are unclear license-wise. > > The reason for wanting also the examples is that they then can form the > basis of CI testing, which would prevent unintentional breaking of them in > the generic (nupeline) code. > > Then you could also add the codes that you use locally as either more > repositories, or as new parts of e.g. 'nupeline.examples' to again avoid > generic changes to break them, by including them in CI builds. > > I do not want to offer that I do anything here, but I could help with > getting the CI working.? And possibly vet merge requests into a 'master' > branch.? But that would not be maintenance, just based on look-and-feel > and CI success.? It would be much better if someone that uses the code > would do that job.? For starters, it sounds like were are not talking > about much commits anyhow. > > Who knows - nupeline might get a life of its own?? ;) > > Cheers, > H?kan > > > > On Fri, 22 Mar 2024, Oliver Papst wrote: > > > Dear G?nter, > > > > I am another user of nupeline. We use it both in Darmstadt for the DHIPS > setup > > and at HI?S, Duke University, for our experiments using the Clover array > setup. > > > > I have created several boxes myself, but I don?t have the capacity to put > any > > work into nupeline myself. I just use it as-it-is. For lack of a better > > alternative that is known to us, we will continue to use it for now. I > would > > also prefer using something that is actively maintained, though. > > > > Cheers, > > > > Oliver > > > > On Fri, 2024-03-22 at 16:49 +0000, Weber, Guenter Dr. wrote: > >> Dear H?kan, > >> > >> > >> thank you very much for the explanations. > >> > >> > >> To be independent from Bastian's legacy code we have now our tailor made > unpacker for some of the LMD data. If we found a way to feed it not only > with files from hard disk but also the data stream provided by UCESB, we > could also use it for online analysis. We could then adapt this unpacker to > the specific structure of our experimental data. > >> > >> > >> However, as UCESB itself is (as I understand) an unpacker for LMD data, > probably the better way would be to use UCESB for basic unpacking into LMD > events/subevents and then as a second stage a dedicated mapper (which in an > ideal world would result from the settings of the modules in main.cfg) to > interpret the data words. This is (again: as I understand it) the approach > taken by Bastian. This second stage could then curate/organize the data and > give it to subsequent programs in a more user-friendly data format than > plain LMD structures. > >> > >> > >> However, I see little use to invest time into the existing NUPELINE > package if Bastian was basicly the only person maintaining it. Is there > maybe something else 'on the market'? Or am I mistaken and there is somebody > out there, who is also continuing to use NUPELINE? > >> > >> > >> (Sorry, if this e-mail is a bit repetitive. I just want to make sure that > my understanding of the situation is correct.) > >> > >> > >> > >> > >> Best greetings > >> > >> G?nter > >> > >> > >> > >> > >> ________________________________ > >> Von: subexp-daq im Auftrag von > H?kan T Johansson > >> Gesendet: Freitag, 22. M?rz 2024 13:06 > >> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > >> Betreff: Re: [subexp-daq] Question on UCESB / UPEXPS > >> > >> > >> Dear G?nter, > >> > >> feel free to respond to issues separately, it was quite a bunch of > >> questions :-)? (I like!) > >> > >> On Fri, 22 Mar 2024, Weber, Guenter Dr. wrote: > >> > >> > > >> > Dear friends, > >> > > >> > > >> > we have now checked the code for the SIS3316 module and will push a > version > >> > with some bug fixes soon. > >> > >> That is excellent news! > >> > >> > The next thing on our list is to understand how we can access and store > the > >> > data that we produce. Bastian told us the following command to write > LMD > >> > files to hard disk: > >> > > >> > > >> > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/drasi/bin/lwrocctrl > >> > localhost --file-open=auto=1Gi,${file} > >> > > >> > How does this LWROCCTRL work together with the Event Builder and UCESB > which > >> > are started by the following commands? > >> > > >> > ../drasi/bin/lwrocmerge \ > >> >???? --label=MCAL_EB \ > >> >???? --merge-mode=event \ > >> >???? --server=trans,flush=1 \ > >> >???? --server=stream,flush=1 \ > >> >???? --buf=size=800Mi \ > >> >???? --max-ev-size=10Mi \ > >> >???? --eb-master=rio4-mcal-2 \ > >> >???? --file-writer \ > >> >???? --drasi=rio4-mcal-2 > >> > > >> > ------------------------------------ > >> > >> lwrocctrl works by communicating with drasi instances. > >> for the lwrocctrl --file... options, it should be an instance which has a > >> --file-writer specified. > >> > >> You can run the lwrocctrl also from another machine (e.g. your PC), but > >> then instead of 'localhost' give the name (or IP) of the machine where > the > >> instance is running. > >> > >> For the communication to work, both have to find a directory > >> ~/.drasi_tokens/ with one or more common files which it will do a cheap > >> hash of.? That is just some very minor protection against mistakes (users > >> talking with the wrong machine.? It is not a security measure as such. > >> > >> To see if an instance is willing to talk, you can try > >> > >> PATH-TO-DRASI/bin/bin/lwrocctrl --file-status [node] > >> > >> > > >> > while : > >> > do > >> > ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ > >> >???? stream://localhost \ > >> >???? --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 > >> > sleep 5 > >> > done > >> > >> That connects to the server above (lwrocmerge) started with > >> --server=stream. > >> > >> And its --server option means it will act as a kind of proxy server.? > I.e. > >> other users that want data can connect to that instead of directly to the > >> DAQ process. > >> > >> > Moreover, to read in the online data stream as well as the LMD files > from > >> > disk, to us it looks like Bastian used a programm called UCESB_IN which > is > >> > using a mapping that is defined within UPEXPS to interpret the content > of > >> > the LMD files. To us it looks like UCESB_IN is like a wrapper for UCESB > to > >> > do a mapping of the content of the LMD events and to send out a data > stream > >> > of some of this content. Attached please find the configuration file > for > >> > UCESB_IN. > >> > >> The attached .cfg file looks like a setup for Bastii's nupeline, which I > >> have very little clue about. > >> > >> Indeed it sure looks like it in turn uses an UCESB unpacker.? With the > >> source in upexps.? That (upexps) has maintenance issues. > >> > >> Perhaps someone else reading this mailing list is also using unpackers > >> from the upexps?? If so, now would be a good time to speak up, because I > >> think we need to figure out how to have something backwards compatible > and > >> maintainable for you, without being 'encouraged' to do the maintenance > >> work that other users at GSI (R3B) refuse to do... > >> > >> > Here, we are not sure up to which point there is a common approach to > read > >> > experimental data and beyond that everybody is on his own. > >> > >> ... while still sharing as much as possible with other users. > >> > >> > Many thanks and best greetings from Jena > >> > G?nter > >> > >> Cheers, > >> H?kan > > > > -- > > subexp-daq mailing list > > subexp-daq at lists.chalmers.se > > https://lists.chalmers.se/mailman/listinfo/subexp-daq > > From B.Loeher at gsi.de Thu Apr 4 22:45:26 2024 From: B.Loeher at gsi.de (Loeher, Bastian Dr.) Date: Thu, 4 Apr 2024 22:45:26 +0200 Subject: [subexp-daq] Nupeline In-Reply-To: <00205e3e-1def-1edf-968e-87fee4fa1483@chalmers.se> References: <241125ce-60af-a7b7-f94a-096376b519b1@chalmers.se> <6838bc02e7e44974939bcc385b4f1d02@hi-jena.gsi.de> <5816b34eeacbe0edbdc93f889c9c34d1c145f613.camel@ikp.tu-darmstadt.de> <1330b176-6a1a-400d-c094-e6fc649c14d4@chalmers.se> <22258ca7-834d-43d7-95ca-265f2644ca32@email.android.com> <00205e3e-1def-1edf-968e-87fee4fa1483@chalmers.se> Message-ID: Hi H?kan, sounds reasonable! Aha, you did already create the group =) I tried and it suggested to use 'nupeline1' as a group name. Well then, carry on! Cheers -bastii On 240404-2126, H?kan T Johansson wrote: > > Hi Bastii, > > How about gitlab.com in a group nupeline ? > > Then it can re-use the CI scripts that exist already and at least I have > more experience with gitlab CI. > > Besides, github actions (their CI) gave me the creeps when I tried something > with r3broot once. By default they were allowed to modify my repositories! > > Cheers, > H?kan > > > > On Thu, 4 Apr 2024, Loeher, Bastian Dr. wrote: > > > Hi everyone, > > I could make all related repositories freely available and put respective > > licenses on the repositories where they are missing. None of the code has > > unclear origins. > > > > Where would be a good place? I could even put it up on github.com. > > > > Cheers > > Bastii > > > > Am 04.04.2024 07:02 schrieb H?kan T Johansson : > > > > Dear Oliver and G?nter, > > > > just a suggestion, since you are at least two users of nupeline and may > > benefit from each other: > > > > Perhaps it would be an idea to have the code available at e.g. an > > gitlab.com group nupeline (or something such). > > > > At least the 'nupeline' repository has a license (MIT) that makes it > > possible to have it public. > > > > For 'nupeline.configs' and 'nupeline.examples' this is however not clear. > > Perhaps Bastii can clarify that situation? > > > > One could also think to only use parts of those repositories if there are > > parts that are unclear license-wise. > > > > The reason for wanting also the examples is that they then can form the > > basis of CI testing, which would prevent unintentional breaking of them in > > the generic (nupeline) code. > > > > Then you could also add the codes that you use locally as either more > > repositories, or as new parts of e.g. 'nupeline.examples' to again avoid > > generic changes to break them, by including them in CI builds. > > > > I do not want to offer that I do anything here, but I could help with > > getting the CI working.? And possibly vet merge requests into a 'master' > > branch.? But that would not be maintenance, just based on look-and-feel > > and CI success.? It would be much better if someone that uses the code > > would do that job.? For starters, it sounds like were are not talking > > about much commits anyhow. > > > > Who knows - nupeline might get a life of its own?? ;) > > > > Cheers, > > H?kan > > > > > > > > On Fri, 22 Mar 2024, Oliver Papst wrote: > > > > > Dear G?nter, > > > > > > I am another user of nupeline. We use it both in Darmstadt for the DHIPS > > setup > > > and at HI?S, Duke University, for our experiments using the Clover array > > setup. > > > > > > I have created several boxes myself, but I don?t have the capacity to put > > any > > > work into nupeline myself. I just use it as-it-is. For lack of a better > > > alternative that is known to us, we will continue to use it for now. I > > would > > > also prefer using something that is actively maintained, though. > > > > > > Cheers, > > > > > > Oliver > > > > > > On Fri, 2024-03-22 at 16:49 +0000, Weber, Guenter Dr. wrote: > > >> Dear H?kan, > > >> > > >> > > >> thank you very much for the explanations. > > >> > > >> > > >> To be independent from Bastian's legacy code we have now our tailor made > > unpacker for some of the LMD data. If we found a way to feed it not only > > with files from hard disk but also the data stream provided by UCESB, we > > could also use it for online analysis. We could then adapt this unpacker to > > the specific structure of our experimental data. > > >> > > >> > > >> However, as UCESB itself is (as I understand) an unpacker for LMD data, > > probably the better way would be to use UCESB for basic unpacking into LMD > > events/subevents and then as a second stage a dedicated mapper (which in an > > ideal world would result from the settings of the modules in main.cfg) to > > interpret the data words. This is (again: as I understand it) the approach > > taken by Bastian. This second stage could then curate/organize the data and > > give it to subsequent programs in a more user-friendly data format than > > plain LMD structures. > > >> > > >> > > >> However, I see little use to invest time into the existing NUPELINE > > package if Bastian was basicly the only person maintaining it. Is there > > maybe something else 'on the market'? Or am I mistaken and there is somebody > > out there, who is also continuing to use NUPELINE? > > >> > > >> > > >> (Sorry, if this e-mail is a bit repetitive. I just want to make sure that > > my understanding of the situation is correct.) > > >> > > >> > > >> > > >> > > >> Best greetings > > >> > > >> G?nter > > >> > > >> > > >> > > >> > > >> ________________________________ > > >> Von: subexp-daq im Auftrag von > > H?kan T Johansson > > >> Gesendet: Freitag, 22. M?rz 2024 13:06 > > >> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > >> Betreff: Re: [subexp-daq] Question on UCESB / UPEXPS > > >> > > >> > > >> Dear G?nter, > > >> > > >> feel free to respond to issues separately, it was quite a bunch of > > >> questions :-)? (I like!) > > >> > > >> On Fri, 22 Mar 2024, Weber, Guenter Dr. wrote: > > >> > > >> > > > >> > Dear friends, > > >> > > > >> > > > >> > we have now checked the code for the SIS3316 module and will push a > > version > > >> > with some bug fixes soon. > > >> > > >> That is excellent news! > > >> > > >> > The next thing on our list is to understand how we can access and store > > the > > >> > data that we produce. Bastian told us the following command to write > > LMD > > >> > files to hard disk: > > >> > > > >> > > > >> > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/drasi/bin/lwrocctrl > > >> > localhost --file-open=auto=1Gi,${file} > > >> > > > >> > How does this LWROCCTRL work together with the Event Builder and UCESB > > which > > >> > are started by the following commands? > > >> > > > >> > ../drasi/bin/lwrocmerge \ > > >> >???? --label=MCAL_EB \ > > >> >???? --merge-mode=event \ > > >> >???? --server=trans,flush=1 \ > > >> >???? --server=stream,flush=1 \ > > >> >???? --buf=size=800Mi \ > > >> >???? --max-ev-size=10Mi \ > > >> >???? --eb-master=rio4-mcal-2 \ > > >> >???? --file-writer \ > > >> >???? --drasi=rio4-mcal-2 > > >> > > > >> > ------------------------------------ > > >> > > >> lwrocctrl works by communicating with drasi instances. > > >> for the lwrocctrl --file... options, it should be an instance which has a > > >> --file-writer specified. > > >> > > >> You can run the lwrocctrl also from another machine (e.g. your PC), but > > >> then instead of 'localhost' give the name (or IP) of the machine where > > the > > >> instance is running. > > >> > > >> For the communication to work, both have to find a directory > > >> ~/.drasi_tokens/ with one or more common files which it will do a cheap > > >> hash of.? That is just some very minor protection against mistakes (users > > >> talking with the wrong machine.? It is not a security measure as such. > > >> > > >> To see if an instance is willing to talk, you can try > > >> > > >> PATH-TO-DRASI/bin/bin/lwrocctrl --file-status [node] > > >> > > >> > > > >> > while : > > >> > do > > >> > ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ > > >> >???? stream://localhost \ > > >> >???? --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 > > >> > sleep 5 > > >> > done > > >> > > >> That connects to the server above (lwrocmerge) started with > > >> --server=stream. > > >> > > >> And its --server option means it will act as a kind of proxy server.? > > I.e. > > >> other users that want data can connect to that instead of directly to the > > >> DAQ process. > > >> > > >> > Moreover, to read in the online data stream as well as the LMD files > > from > > >> > disk, to us it looks like Bastian used a programm called UCESB_IN which > > is > > >> > using a mapping that is defined within UPEXPS to interpret the content > > of > > >> > the LMD files. To us it looks like UCESB_IN is like a wrapper for UCESB > > to > > >> > do a mapping of the content of the LMD events and to send out a data > > stream > > >> > of some of this content. Attached please find the configuration file > > for > > >> > UCESB_IN. > > >> > > >> The attached .cfg file looks like a setup for Bastii's nupeline, which I > > >> have very little clue about. > > >> > > >> Indeed it sure looks like it in turn uses an UCESB unpacker.? With the > > >> source in upexps.? That (upexps) has maintenance issues. > > >> > > >> Perhaps someone else reading this mailing list is also using unpackers > > >> from the upexps?? If so, now would be a good time to speak up, because I > > >> think we need to figure out how to have something backwards compatible > > and > > >> maintainable for you, without being 'encouraged' to do the maintenance > > >> work that other users at GSI (R3B) refuse to do... > > >> > > >> > Here, we are not sure up to which point there is a common approach to > > read > > >> > experimental data and beyond that everybody is on his own. > > >> > > >> ... while still sharing as much as possible with other users. > > >> > > >> > Many thanks and best greetings from Jena > > >> > G?nter > > >> > > >> Cheers, > > >> H?kan > > > > > > -- > > > subexp-daq mailing list > > > subexp-daq at lists.chalmers.se > > > https://lists.chalmers.se/mailman/listinfo/subexp-daq > > > > -- Dr. Bastian L?her Data acquisition Experiment controls Detector development R3B - Relativistic reactions with radioactive beams Gamma spectroscopy -- GSI ------------------------------------------------------------------------ Room / Raum: SB3 3.198 (R3B), SB3 4.162 (Gamma spectroscopy) Phone / Telefon: +49 6159 71 3272 (Office), 1317 (Messh?tte), 2934 (Cave C) Fax: +49 6159 71 2902 Mobile / Mobil: +49 162 5467038 E-Mail: b.loeher at gsi.de GSI Helmholtzzentrum f?r Schwerionenforschung GmbH Planckstra?e 1, 64291 Darmstadt, Germany, www.gsi.de Commercial Register / Handelsregister: Amtsgericht Darmstadt, HRB 1528 Managing Directors / Gesch?ftsf?hrung: Professor Dr. Paolo Giubellino, J?rg Blaurock Chairman of the GSI Supervisory Board / Vorsitzender des GSI-Aufsichtsrats: Ministerialdirigent Dr. Volkmar Dietz -- TU Darmstadt --------------------------------------------------------------- Room / Raum: S2|14 418 Phone / Telefon: +49 6151 23532 Mobile / Mobil: +49 162 5467038 E-Mail: loeher at ikp.tu-darmstadt.de Institut f?r Kernphysik Technische Universit?t Darmstadt Schlossgartenstrasse 9, 64289 Darmstadt http://www.ikp.tu-darmstadt.de From f96hajo at chalmers.se Thu Apr 4 23:08:07 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Thu, 4 Apr 2024 23:08:07 +0200 Subject: [subexp-daq] Question on UCESB In-Reply-To: <175903985aa0446e8502a40b06ecec43@hi-jena.gsi.de> References: <9915e48ab12d433da8d117409071b138@hi-jena.gsi.de>, <175903985aa0446e8502a40b06ecec43@hi-jena.gsi.de> Message-ID: <882bddbe-eb5c-21ca-bf90-c1905d378741@chalmers.se> Dear G?nter, the easiest way is probably to use the json dump from the ntuple writer. How to get there is not very well documented...: Example with dummy data: file_input/empty_file --lmd | \ empty/empty --file=- --ntuple=STRUCT,- | \ hbook/struct_writer - --dump=json It can also be operated in a 'server' mode for the 'external' data: file_input/empty_file --lmd | \ empty/empty --file=- --ntuple=STRUCT,SERVER And then the dumper could be started like this: hbook/struct_writer localhost --dump=json Instead of json also compact_json exist, which will produce less whitespace. Cheers, H?kan On Thu, 4 Apr 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > we now (think that we have) understoof how *.spec-Files work. For a minimum > setup with just the VULOM (Timestamp and 16 scaler channels) we compiled out > own UCESB example. The output of an event looks like this: > > > Event?????????? 203 Type/Subtype?? 10??? 1 Size????? 140 Trigger? 1 > ?SubEv ProcID???? 1 Type/Subtype?? 10??? 1 Size?????? 24 Ctrl?? 9 Subcrate?? > 1 > ?00000200 03e1a48c 04e1e9dd 05e109e1 06e10000 f1a2000a > ?SubEv ProcID???? 1 Type/Subtype?? 20??? 2 Size?????? 84 Ctrl?? 9 Subcrate?? > 1 > ?80000000 660ebf44 000009e1 e9dda48c 00000010 0001a871 00000000 00000000 > ?00000000 00000000 00000000 00000000 00000000 00000001 00000001 00000001 > ?00000001 00000001 00000001 00000001 00000001 > > Event???????? 203 Trigger? 1 > > .RAW.TIMESTAMP.VULOM.HI: 0x000009e1=2529 > .RAW.TIMESTAMP.VULOM.LO: 0xe9dda48c=-371350388 > .RAW.VULOM.SCALER[0]: 0x0001a871=108657 > .RAW.VULOM.SCALER[1]: 0x00000000=0 > .RAW.VULOM.SCALER[2]: 0x00000000=0 > .RAW.VULOM.SCALER[3]: 0x00000000=0 > .RAW.VULOM.SCALER[4]: 0x00000000=0 > .RAW.VULOM.SCALER[5]: 0x00000000=0 > .RAW.VULOM.SCALER[6]: 0x00000000=0 > .RAW.VULOM.SCALER[7]: 0x00000000=0 > .RAW.VULOM.SCALER[8]: 0x00000001=1 > .RAW.VULOM.SCALER[9]: 0x00000001=1 > .RAW.VULOM.SCALER[10]: 0x00000001=1 > .RAW.VULOM.SCALER[11]: 0x00000001=1 > .RAW.VULOM.SCALER[12]: 0x00000001=1 > .RAW.VULOM.SCALER[13]: 0x00000001=1 > .RAW.VULOM.SCALER[14]: 0x00000001=1 > .RAW.VULOM.SCALER[15]: 0x00000001=1 > > (produced with "--data --dump=RAW --print") > > We now would like to take the easisest possible route to transport the RAW > data to Pyhton, where our main analysis is living. Unfortunately, > ext_data_client.h and the code behind it does not really feel inviting to be > converted into Python. Is there any other way to generate a data stream from > UCESB? So far, we had only success with writing the data into a ROOT file > and then using uproot in Pyhton to read the file. But this is no solution > for online analysis where we would need a data stream. > > We also had a look how Bastian did this with UCESB_IN (part of NUPELINE), > but we felt a bit overwhelmed. Idealy, we could access the data stream from > UCESB with such a simple Python code: > > import socket > import sys > import numpy as np > > sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) > server_address = ("10.141.184.131", 8001) > print(sys.stderr, 'connecting to %s port %s' % server_address) > sock.connect(server_address) > print("Connected") > data = sock.recv(80) > print( data ) > t = np.dtype('u4, u4, u8, (16)u4')? /* for our test data: trigger type, > event number, timestamp, 16 scaler channels */ > a = np.frombuffer(data, dtype=t) > sock.close() > > However, of course just get 'a magic word' from UCESB as we have not > implemented the correct protocoll to acccess the data. In an idea case, we > would be able to avoid implementing this protocoll (or find an easy way to > do it). > > > > Thank you very much and best greetings from Jena. > > > G?nter > > > > > > > > > > > > > > > > ---------------- > > G?nter Weber > > Helmholtz-Institut Jena > Fr?belstieg 3 > 07743 Jena > Germany > Phone: +49-3641-947605 > www.hi-jena.de > > GSI Helmholtzzentrum f?r Schwerionenforschung > Planckstrasse 1 > 64291 Darmstadt > Germany > www.gsi.de > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan > T Johansson > Gesendet: Donnerstag, 4. April 2024 06:39:32 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] Question on UCESB ? > > On Wed, 3 Apr 2024, Weber, Guenter Dr. wrote: > > > > > Dear friends, > > > > > > we now had a brief look into UCESB and UPEXPS. > > > > > > Is our intepretation correct, that *.spec-Files are used for mapping > between > > the raw data within an LMD event and "interpreted" data that is then used > > for further analysis? > > Yes.? The .spec files contain the data format descriptions, and also the > mappings of channel names (in the SIGNAL statements). > > > If true, why is the folder SPEC containing only spec > > files for a few of the modules available in NURDLIB? > > The ucesb/spec/ directory comntain files where I or users have sent me > patches/commits with those data format specifications. > > > Is it just the case > > that nobody found time yet or is there a design decision behind this? > > If users place / keep them elsewhere (like e.g. upexps) longterm, there is > not much I can do...? :-) > > Not a design decision.? Except that the stuff in (the generic spec/ > directory) should not be experiment specific. > > > We are > > now ondering what is the best wyo add a spec file for the new module that > we > > added to NURDLIB. > > Sure!? Yes, please! > > > Also, if this made sense, we could add a spec file for the > > STRUCK digitizers whcih currently does only exist within UPEXPS. > > Yes.? But we also need to know where it came from, since ucesb is > publically available, and just for good form want to keep the license in > order.? I do want to make a mess like this, but to avoid issues down the > road. > > > To us there it is not really clear where UCESB ends and UPEXPS begins. > Could > > you explain what exactly is the purpose of both packages? What is UPEXPS > > doing that could/should not be a part of UCESB? > > Generally, ucesb/ is (expect for the fast that it has some (old) example > and test directories, not experiment-specific. > > upexps (or any other user repo) would contain the signal mappings for > sure. > > Some .spec files would likely be better to have somewhere under > ucesb/spec/ > > Cheers, > H?kan > > From f96hajo at chalmers.se Thu Apr 4 23:12:58 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Thu, 4 Apr 2024 23:12:58 +0200 Subject: [subexp-daq] Question on UCESB In-Reply-To: References: <9915e48ab12d433da8d117409071b138@hi-jena.gsi.de>, , <175903985aa0446e8502a40b06ecec43@hi-jena.gsi.de> Message-ID: <233bb180-7238-c19b-2a3c-d471246dba66@chalmers.se> I think/hope you'll get away with the json in the previous mail, but for completeness: Cool that you found that example! That write-up is unfortunately out of date... (Though most things should still work, this is hopefully one of the few that does not.) An example of such an external reader can be found here: hbook/example/ext_data_reader.c It now transmits the data layout in other ways instead, which is a bit more flexible. Cheers, H?kan On Thu, 4 Apr 2024, Weber, Guenter Dr. wrote: > > P.S. > > > A follow-up question: > > > In UCESB manual there is some example code on page 65 (listing 6.2), where > we find: > > > #define EXT_EVENT_STRUCT EXT_STR_h101 > #define EXT_EVENT_STRUCT_LAYOUT EXT_STR_h101_layout > #define EXT_EVENT_STRUCT_LAYOUT_INIT EXT_STR_h101_LAYOUT_INIT > > > However, the jena_test.hh created by our UCESB does only have > > > typedef struct EXT_STR_h101_t > > and > typedef struct EXT_STR_h101_onion_t. > > From where could we get _layout and LAYOUT_INIT for our test case? > > > > Thank you very much! > > > > > Best greetings > > G?nter > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von Weber, > Guenter Dr. > Gesendet: Donnerstag, 4. April 2024 20:47:19 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] Question on UCESB ? > > Dear friends, > > > we now (think that we have) understoof how *.spec-Files work. For a minimum > setup with just the VULOM (Timestamp and 16 scaler channels) we compiled out > own UCESB example. The output of an event looks like this: > > > Event?????????? 203 Type/Subtype?? 10??? 1 Size????? 140 Trigger? 1 > ?SubEv ProcID???? 1 Type/Subtype?? 10??? 1 Size?????? 24 Ctrl?? 9 Subcrate?? > 1 > ?00000200 03e1a48c 04e1e9dd 05e109e1 06e10000 f1a2000a > ?SubEv ProcID???? 1 Type/Subtype?? 20??? 2 Size?????? 84 Ctrl?? 9 Subcrate?? > 1 > ?80000000 660ebf44 000009e1 e9dda48c 00000010 0001a871 00000000 00000000 > ?00000000 00000000 00000000 00000000 00000000 00000001 00000001 00000001 > ?00000001 00000001 00000001 00000001 00000001 > > Event???????? 203 Trigger? 1 > > .RAW.TIMESTAMP.VULOM.HI: 0x000009e1=2529 > .RAW.TIMESTAMP.VULOM.LO: 0xe9dda48c=-371350388 > .RAW.VULOM.SCALER[0]: 0x0001a871=108657 > .RAW.VULOM.SCALER[1]: 0x00000000=0 > .RAW.VULOM.SCALER[2]: 0x00000000=0 > .RAW.VULOM.SCALER[3]: 0x00000000=0 > .RAW.VULOM.SCALER[4]: 0x00000000=0 > .RAW.VULOM.SCALER[5]: 0x00000000=0 > .RAW.VULOM.SCALER[6]: 0x00000000=0 > .RAW.VULOM.SCALER[7]: 0x00000000=0 > .RAW.VULOM.SCALER[8]: 0x00000001=1 > .RAW.VULOM.SCALER[9]: 0x00000001=1 > .RAW.VULOM.SCALER[10]: 0x00000001=1 > .RAW.VULOM.SCALER[11]: 0x00000001=1 > .RAW.VULOM.SCALER[12]: 0x00000001=1 > .RAW.VULOM.SCALER[13]: 0x00000001=1 > .RAW.VULOM.SCALER[14]: 0x00000001=1 > .RAW.VULOM.SCALER[15]: 0x00000001=1 > > (produced with "--data --dump=RAW --print") > > We now would like to take the easisest possible route to transport the RAW > data to Pyhton, where our main analysis is living. Unfortunately, > ext_data_client.h and the code behind it does not really feel inviting to be > converted into Python. Is there any other way to generate a data stream from > UCESB? So far, we had only success with writing the data into a ROOT file > and then using uproot in Pyhton to read the file. But this is no solution > for online analysis where we would need a data stream. > > We also had a look how Bastian did this with UCESB_IN (part of NUPELINE), > but we felt a bit overwhelmed. Idealy, we could access the data stream from > UCESB with such a simple Python code: > > import socket > import sys > import numpy as np > > sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) > server_address = ("10.141.184.131", 8001) > print(sys.stderr, 'connecting to %s port %s' % server_address) > sock.connect(server_address) > print("Connected") > data = sock.recv(80) > print( data ) > t = np.dtype('u4, u4, u8, (16)u4')? /* for our test data: trigger type, > event number, timestamp, 16 scaler channels */ > a = np.frombuffer(data, dtype=t) > sock.close() > > However, of course just get 'a magic word' from UCESB as we have not > implemented the correct protocoll to acccess the data. In an idea case, we > would be able to avoid implementing this protocoll (or find an easy way to > do it). > > > > Thank you very much and best greetings from Jena. > > > G?nter > > > > > > > > > > > > > > > > ---------------- > > G?nter Weber > > Helmholtz-Institut Jena > Fr?belstieg 3 > 07743 Jena > Germany > Phone: +49-3641-947605 > www.hi-jena.de > > GSI Helmholtzzentrum f?r Schwerionenforschung > Planckstrasse 1 > 64291 Darmstadt > Germany > www.gsi.de > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan > T Johansson > Gesendet: Donnerstag, 4. April 2024 06:39:32 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] Question on UCESB ? > > On Wed, 3 Apr 2024, Weber, Guenter Dr. wrote: > > > > > Dear friends, > > > > > > we now had a brief look into UCESB and UPEXPS. > > > > > > Is our intepretation correct, that *.spec-Files are used for mapping > between > > the raw data within an LMD event and "interpreted" data that is then used > > for further analysis? > > Yes.? The .spec files contain the data format descriptions, and also the > mappings of channel names (in the SIGNAL statements). > > > If true, why is the folder SPEC containing only spec > > files for a few of the modules available in NURDLIB? > > The ucesb/spec/ directory comntain files where I or users have sent me > patches/commits with those data format specifications. > > > Is it just the case > > that nobody found time yet or is there a design decision behind this? > > If users place / keep them elsewhere (like e.g. upexps) longterm, there is > not much I can do...? :-) > > Not a design decision.? Except that the stuff in (the generic spec/ > directory) should not be experiment specific. > > > We are > > now ondering what is the best wyo add a spec file for the new module that > we > > added to NURDLIB. > > Sure!? Yes, please! > > > Also, if this made sense, we could add a spec file for the > > STRUCK digitizers whcih currently does only exist within UPEXPS. > > Yes.? But we also need to know where it came from, since ucesb is > publically available, and just for good form want to keep the license in > order.? I do want to make a mess like this, but to avoid issues down the > road. > > > To us there it is not really clear where UCESB ends and UPEXPS begins. > Could > > you explain what exactly is the purpose of both packages? What is UPEXPS > > doing that could/should not be a part of UCESB? > > Generally, ucesb/ is (expect for the fast that it has some (old) example > and test directories, not experiment-specific. > > upexps (or any other user repo) would contain the signal mappings for > sure. > > Some .spec files would likely be better to have somewhere under > ucesb/spec/ > > Cheers, > H?kan > > From g.weber at hi-jena.gsi.de Wed Apr 10 11:05:18 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Wed, 10 Apr 2024 09:05:18 +0000 Subject: [subexp-daq] Question on UCESB In-Reply-To: <882bddbe-eb5c-21ca-bf90-c1905d378741@chalmers.se> References: <9915e48ab12d433da8d117409071b138@hi-jena.gsi.de>, <175903985aa0446e8502a40b06ecec43@hi-jena.gsi.de>, <882bddbe-eb5c-21ca-bf90-c1905d378741@chalmers.se> Message-ID: <76b14bfdbcfb42e39e2f04310d03a8d6@hi-jena.gsi.de> Dear H?kan, thank you very much for the hint to the JSON implementation. We now wrote a PYTHON script that streams the JSON output of UCESB/HBOOK/STRUCT_WRITER. It looks like this: hbookproc = subprocess.Popen(r'../../ucesb/jena_test/jena_test stream://localhost:8001 --ntuple=UNPACK,STRUCT,- | ../../ucesb/hbook/struct_writer - --dump=compact_json', executable=r'/bin/bash', shell=True, stdout=subprocess.PIPE) while not self._stop_event.is_set() and (currline := hbookproc.stdout.readline()): # generate content to be streamed msg = 'data: '+currline.decode('utf-8')+'\n\n' self._announcer.announce(msg) The client code looks like this: import sseclient import json messages = sseclient.SSEClient('http://10.141.184.131:5000/listen') for msg in messages: #TODO customize json.loads to account for unchanging packet structure try: data = json.loads(msg.data.encode()) except Exception as e: print(f"Got error: {msg.data}") else: print(data) On the receiving end we now get the events in the following form: {'TRIGGER': 1, 'EVENTNO': 4271780, 'ts_wr_subsystem_id': 0, 'ts_wr_t1': 0, 'ts_wr_t2': 0, 'ts_wr_t3': 0, 'ts_wr_t4': 0, 'vme_header_failure': 2147483648, 'vme_header_continous_event_counter': 0, 'vme_header_time_stamp': 1712669650, 'vme_header_clock_counter_stamp': 0, 'vme_header_iped': 0, 'vme_header_multi_events': 0, 'vme_header_multi_trlo_ii_counter0': 0, 'vme_header_multi_scaler_counter0': 0, 'vme_header_multi_adctdc_counter0': 0, 'vme_timestamps_time_hi': 101985, 'vme_timestamps_time_lo': 1356225930, 'vme_scaler_n': 16, 'vme_scaler_nI': [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16], 'vme_scaler_data': [4380234, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1]} This is really great. The only remaining question for now is if there is a way to get the content of an array (in the above case the counts in the 16 scaler channels) without the additional information on the scaler channel numbers? In case of the SIS3316 digitizers a single pulse trace can have a length of tens of thousands of samples. Somehow I do not like the idea that without necessity we always transfer an additional array with just the numbers from 1 to n. Bottom line: is there an easy way to get rid of the '..._nI' part of the array object in the JSON output? Thank you very much and best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Donnerstag, 4. April 2024 23:08:07 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] Question on UCESB Dear G?nter, the easiest way is probably to use the json dump from the ntuple writer. How to get there is not very well documented...: Example with dummy data: file_input/empty_file --lmd | \ empty/empty --file=- --ntuple=STRUCT,- | \ hbook/struct_writer - --dump=json It can also be operated in a 'server' mode for the 'external' data: file_input/empty_file --lmd | \ empty/empty --file=- --ntuple=STRUCT,SERVER And then the dumper could be started like this: hbook/struct_writer localhost --dump=json Instead of json also compact_json exist, which will produce less whitespace. Cheers, H?kan On Thu, 4 Apr 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > we now (think that we have) understoof how *.spec-Files work. For a minimum > setup with just the VULOM (Timestamp and 16 scaler channels) we compiled out > own UCESB example. The output of an event looks like this: > > > Event 203 Type/Subtype 10 1 Size 140 Trigger 1 > SubEv ProcID 1 Type/Subtype 10 1 Size 24 Ctrl 9 Subcrate > 1 > 00000200 03e1a48c 04e1e9dd 05e109e1 06e10000 f1a2000a > SubEv ProcID 1 Type/Subtype 20 2 Size 84 Ctrl 9 Subcrate > 1 > 80000000 660ebf44 000009e1 e9dda48c 00000010 0001a871 00000000 00000000 > 00000000 00000000 00000000 00000000 00000000 00000001 00000001 00000001 > 00000001 00000001 00000001 00000001 00000001 > > Event 203 Trigger 1 > > .RAW.TIMESTAMP.VULOM.HI: 0x000009e1=2529 > .RAW.TIMESTAMP.VULOM.LO: 0xe9dda48c=-371350388 > .RAW.VULOM.SCALER[0]: 0x0001a871=108657 > .RAW.VULOM.SCALER[1]: 0x00000000=0 > .RAW.VULOM.SCALER[2]: 0x00000000=0 > .RAW.VULOM.SCALER[3]: 0x00000000=0 > .RAW.VULOM.SCALER[4]: 0x00000000=0 > .RAW.VULOM.SCALER[5]: 0x00000000=0 > .RAW.VULOM.SCALER[6]: 0x00000000=0 > .RAW.VULOM.SCALER[7]: 0x00000000=0 > .RAW.VULOM.SCALER[8]: 0x00000001=1 > .RAW.VULOM.SCALER[9]: 0x00000001=1 > .RAW.VULOM.SCALER[10]: 0x00000001=1 > .RAW.VULOM.SCALER[11]: 0x00000001=1 > .RAW.VULOM.SCALER[12]: 0x00000001=1 > .RAW.VULOM.SCALER[13]: 0x00000001=1 > .RAW.VULOM.SCALER[14]: 0x00000001=1 > .RAW.VULOM.SCALER[15]: 0x00000001=1 > > (produced with "--data --dump=RAW --print") > > We now would like to take the easisest possible route to transport the RAW > data to Pyhton, where our main analysis is living. Unfortunately, > ext_data_client.h and the code behind it does not really feel inviting to be > converted into Python. Is there any other way to generate a data stream from > UCESB? So far, we had only success with writing the data into a ROOT file > and then using uproot in Pyhton to read the file. But this is no solution > for online analysis where we would need a data stream. > > We also had a look how Bastian did this with UCESB_IN (part of NUPELINE), > but we felt a bit overwhelmed. Idealy, we could access the data stream from > UCESB with such a simple Python code: > > import socket > import sys > import numpy as np > > sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) > server_address = ("10.141.184.131", 8001) > print(sys.stderr, 'connecting to %s port %s' % server_address) > sock.connect(server_address) > print("Connected") > data = sock.recv(80) > print( data ) > t = np.dtype('u4, u4, u8, (16)u4') /* for our test data: trigger type, > event number, timestamp, 16 scaler channels */ > a = np.frombuffer(data, dtype=t) > sock.close() > > However, of course just get 'a magic word' from UCESB as we have not > implemented the correct protocoll to acccess the data. In an idea case, we > would be able to avoid implementing this protocoll (or find an easy way to > do it). > > > > Thank you very much and best greetings from Jena. > > > G?nter > > > > > > > > > > > > > > > > ---------------- > > G?nter Weber > > Helmholtz-Institut Jena > Fr?belstieg 3 > 07743 Jena > Germany > Phone: +49-3641-947605 > www.hi-jena.de > > GSI Helmholtzzentrum f?r Schwerionenforschung > Planckstrasse 1 > 64291 Darmstadt > Germany > www.gsi.de > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan > T Johansson > Gesendet: Donnerstag, 4. April 2024 06:39:32 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] Question on UCESB > > On Wed, 3 Apr 2024, Weber, Guenter Dr. wrote: > > > > > Dear friends, > > > > > > we now had a brief look into UCESB and UPEXPS. > > > > > > Is our intepretation correct, that *.spec-Files are used for mapping > between > > the raw data within an LMD event and "interpreted" data that is then used > > for further analysis? > > Yes. The .spec files contain the data format descriptions, and also the > mappings of channel names (in the SIGNAL statements). > > > If true, why is the folder SPEC containing only spec > > files for a few of the modules available in NURDLIB? > > The ucesb/spec/ directory comntain files where I or users have sent me > patches/commits with those data format specifications. > > > Is it just the case > > that nobody found time yet or is there a design decision behind this? > > If users place / keep them elsewhere (like e.g. upexps) longterm, there is > not much I can do... :-) > > Not a design decision. Except that the stuff in (the generic spec/ > directory) should not be experiment specific. > > > We are > > now ondering what is the best wyo add a spec file for the new module that > we > > added to NURDLIB. > > Sure! Yes, please! > > > Also, if this made sense, we could add a spec file for the > > STRUCK digitizers whcih currently does only exist within UPEXPS. > > Yes. But we also need to know where it came from, since ucesb is > publically available, and just for good form want to keep the license in > order. I do want to make a mess like this, but to avoid issues down the > road. > > > To us there it is not really clear where UCESB ends and UPEXPS begins. > Could > > you explain what exactly is the purpose of both packages? What is UPEXPS > > doing that could/should not be a part of UCESB? > > Generally, ucesb/ is (expect for the fast that it has some (old) example > and test directories, not experiment-specific. > > upexps (or any other user repo) would contain the signal mappings for > sure. > > Some .spec files would likely be better to have somewhere under > ucesb/spec/ > > Cheers, > H?kan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Wed Apr 10 12:57:19 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Wed, 10 Apr 2024 12:57:19 +0200 Subject: [subexp-daq] Question on UCESB In-Reply-To: <76b14bfdbcfb42e39e2f04310d03a8d6@hi-jena.gsi.de> References: <9915e48ab12d433da8d117409071b138@hi-jena.gsi.de>, <175903985aa0446e8502a40b06ecec43@hi-jena.gsi.de>, <882bddbe-eb5c-21ca-bf90-c1905d378741@chalmers.se> <76b14bfdbcfb42e39e2f04310d03a8d6@hi-jena.gsi.de> Message-ID: On Wed, 10 Apr 2024, Weber, Guenter Dr. wrote: > This is really great. The only remaining question for now is if there is a > way to get the content of an array (in the above case the counts in the 16 > scaler channels) without the additional information on the scaler channel > numbers? In case of the SIS3316 digitizers a single pulse trace can have a > length of tens of thousands of samples. Somehow I do not like the idea that > without necessity we always transfer an additional array with just the > numbers from 1 to n. > > Bottom line: is there an easy way to get rid of the '..._nI' part of the > array object in the JSON output? Nice that it worked. I think the only 'easy' way to avoid the '..._nI' entries is to not use zero-suppression for the array. However, then it would/should appear fully in all events. Since the scaler module might not always be read, it would then contain the value 0 when nothing filled the array for that event. That may (or not) be more confusing. Cheers, H?kan From g.weber at hi-jena.gsi.de Wed Apr 10 14:47:40 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Wed, 10 Apr 2024 12:47:40 +0000 Subject: [subexp-daq] Question on UCESB In-Reply-To: References: <9915e48ab12d433da8d117409071b138@hi-jena.gsi.de>, <175903985aa0446e8502a40b06ecec43@hi-jena.gsi.de>, <882bddbe-eb5c-21ca-bf90-c1905d378741@chalmers.se> <76b14bfdbcfb42e39e2f04310d03a8d6@hi-jena.gsi.de>, Message-ID: Dear H?kan, next thing is that we would like to teach the HBOOK part to work with 64-bit uints (to not have the timestamp as two 32-bit words). We noticed there is a pearl script: make_external_struct_sender.pl Is this an integral part that we would need to touch? Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Mittwoch, 10. April 2024 12:57:19 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] Question on UCESB On Wed, 10 Apr 2024, Weber, Guenter Dr. wrote: > This is really great. The only remaining question for now is if there is a > way to get the content of an array (in the above case the counts in the 16 > scaler channels) without the additional information on the scaler channel > numbers? In case of the SIS3316 digitizers a single pulse trace can have a > length of tens of thousands of samples. Somehow I do not like the idea that > without necessity we always transfer an additional array with just the > numbers from 1 to n. > > Bottom line: is there an easy way to get rid of the '..._nI' part of the > array object in the JSON output? Nice that it worked. I think the only 'easy' way to avoid the '..._nI' entries is to not use zero-suppression for the array. However, then it would/should appear fully in all events. Since the scaler module might not always be read, it would then contain the value 0 when nothing filled the array for that event. That may (or not) be more confusing. Cheers, H?kan -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.tornqvist at chalmers.se Wed Apr 10 15:07:01 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Wed, 10 Apr 2024 15:07:01 +0200 Subject: [subexp-daq] Question on UCESB In-Reply-To: References: <9915e48ab12d433da8d117409071b138@hi-jena.gsi.de> <175903985aa0446e8502a40b06ecec43@hi-jena.gsi.de> <882bddbe-eb5c-21ca-bf90-c1905d378741@chalmers.se> <76b14bfdbcfb42e39e2f04310d03a8d6@hi-jena.gsi.de> Message-ID: <1d3f47ec-e756-43de-9bb7-f525e2762490@chalmers.se> Dear G?nter, Apparently this would lead to major surgery with all the complications that can lead to. The surgery would be all over the place in many files inside the hbook/ directory. Merging 2 32-bit words is a lot easier, until we need to unpack a lot more than just timestamps :) Cheers, H?kan & Hans On 2024-04-10 14:47, Weber, Guenter Dr. wrote: > Dear H?kan, > > > next thing is that we would like to teach the HBOOK part to work with > 64-bit uints (to not have the timestamp as two 32-bit words). We noticed > there is a pearl script: make_external_struct_sender.pl > > Is this an integral part that we would need to touch? > > > > > Best greetings > > G?nter > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > H?kan T Johansson > *Gesendet:* Mittwoch, 10. April 2024 12:57:19 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > *Betreff:* Re: [subexp-daq] Question on UCESB > > On Wed, 10 Apr 2024, Weber, Guenter Dr. wrote: > >> This is really great. The only remaining question for now is if there is a >> way to get the content of an array (in the above case the counts in the 16 >> scaler channels) without the additional information on the scaler channel >> numbers? In case of the SIS3316 digitizers a single pulse trace can have a >> length of tens of thousands of samples. Somehow I do not like the idea that >> without necessity we always transfer an additional array with just the >> numbers from 1 to n. >> >> Bottom line: is there an easy way to get rid of the '..._nI' part of the >> array object in the JSON output? > > Nice that it worked. > > I think the only 'easy' way to avoid the '..._nI' entries is to not use > zero-suppression for the array. > > However, then it would/should appear fully in all events.? Since the > scaler module might not always be read, it would then contain the value 0 > when nothing filled the array for that event.? That may (or not) be more > confusing. > > Cheers, > H?kan > From f96hajo at chalmers.se Thu Apr 11 11:56:46 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Thu, 11 Apr 2024 11:56:46 +0200 Subject: [subexp-daq] VULOM4 instead of 4B In-Reply-To: <5b4de40c21e04d279bdbb502b53999d0@hi-jena.gsi.de> References: <5b4de40c21e04d279bdbb502b53999d0@hi-jena.gsi.de> Message-ID: <794ecf43-520b-89f2-1c1a-6846e6398809@chalmers.se> Dear G?nter, On Thu, 11 Apr 2024, Weber, Guenter Dr. wrote: > > Dear Hans, dear Hakan, > > > while migrating an existing DAQ system to the new software, I noticed that this system has a VULOM4 instead if 4B. > > > RIO4L-2 mbsdaq > bin/vulomflash --addr=3 --readprogs > VULOM base address: 0x03000000 > hwmap_mapvme.c:419: LOG: Virtual address for VULOM/TRIDI @ VME 0x03000000 is 0x3005e000. > Performing command 'readprogs'... > ========================================================================= > Rng 0: TRLO II? ver/vulom4_trlo???????? 2023-01-08 20:45:08 ( 9.491ns) 6e4ba1a9 > Rng 1: TRLO II? ver/vulom4_trlo???????? 2023-01-08 20:45:08 ( 9.491ns) 6e4ba1a9 > 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. > RIO4L-2 mbsdaq > bin/vulomflash --addr=3 --prog=2 fw/vulom4b_trlo/vlogic_4b.rbt > VULOM base address: 0x03000000 > hwmap_mapvme.c:419: LOG: Virtual address for VULOM/TRIDI @ VME 0x03000000 is 0x3005e000. > Firmware: fw/vulom4b_trlo/vlogic_4b.rbt > Comments: fw/vulom4b_trlo/trlo_compile.txt > From file: firmware: 7819904 bits, comments: 329 bytes. > INFO: File firmware heuristically identified as: VULOM4B > INFO: Module heuristically identified (from flash comments) as: VULOM4 > FATAL: Refusing to program firmware with different identification than other flash firmwares. > Released vme ptr. > > > What is the correct procedure to equip the VULOM with the most recent firmware? Note that this checking is based on the image files already staored in the flash memory of the board. There is no board-level identification. I.e., on a board where enough information to 'determine' which kind of board it is by looking at previously programmed images this mistake-avoidance feature would not work. > The first thing I did is to run firmwares.pl and the (hopefully) pick the right one for compilation: > > > RIO4L-2 mbsdaq > find_firmwares.pl > 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 > 5e8f5ef4 ../fw/tridi1_trlo/tridi_defs.h > 6e4ba1a9 ../fw/vulom4_trlo/trlo_defs.h > 68f8955e ../fw/vulom4_trlo_all_in/trlo_all_in_defs.h > af33ed35 ../fw/vulom4_trlo_big/trlo_big_defs.h > a73c5093 ../fw/vulom4_trlo_led/trlo_defs.h > 1409285e ../fw/vulom4b_trlo/trlo_defs.h > RIO4L-2 mbsdaq > make fw_6e4ba1a9_trlo_build > make? -C fw_6e4ba1a9_trlo -f ../trlolib/Makefile \ > ????????? TRLOBASENAME=`cat fw_6e4ba1a9_trlo/trlobasename` FILTERSRC=1 > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_6e4ba1a9_trlo' > ? DEPS?? bld_ppc-linux_4.2.2/src/trlo_check_version.d > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_6e4ba1a9_trlo' > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_6e4ba1a9_trlo' > make[1]: Warning: File `bld_ppc-linux_4.2.2/src/trlo_check_version.d' has modification time 35 s in the future > ?? CC??? bld_ppc-linux_4.2.2/src/trlo_check_version.o > ?? AR??? lib_ppc-linux_4.2.2/libtrlo_ctrl.a > ? LINK?? bin_ppc-linux_4.2.2/trlo_test > ? LINK?? bin_ppc-linux_4.2.2/trlo_ctrl > ? LINK?? bin_ppc-linux_4.2.2/trlo_trimi_test > ? LINK?? bin_ppc-linux_4.2.2/trlo_trigbus_test > ? LINK?? bin_ppc-linux_4.2.2/trlo_tstamp_test > ? LINK?? bin_ppc-linux_4.2.2/trlo_tstamp_sample > ? LINK?? bin_ppc-linux_4.2.2/trlo_slew_counter_test > ? LINK?? bin_ppc-linux_4.2.2/trlo_multi_scaler_test > ? TEST?? bld_ppc-linux_4.2.2/do_trlo_test > ?ALIAS-T bld_ppc-linux_4.2.2/do_trlo_alias_test > make[1]: warning:? Clock skew detected.? Your build may be incomplete. > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_6e4ba1a9_trlo' > > But which of the *.rbt files is now the correct one to be transferred as firmware to the VULOM4? And why the VULOM4 seems to have four different firmware versions when 4B just has one? > > > ./fw/vulom4_trlo/vlogic_1.rbt > ./fw/vulom4_trlo_led/vlogic_1.rbt > ./fw/vulom4_trlo_big/vlogic_1.rbt > ./fw/tridi1_trlo/tlogic_1.rbt > ./fw/vulom4b_trlo/vlogic_4b.rbt > ./fw/vulom4_trlo_all_in/vlogic_1.rbt The vulom4b_trlo/vlogic_4b.rbt and vulom4_trlo/vlogic_1.rbt would be the ones having the same functionality for the two different boards. The FPGA on the VULOM boards is rather small (used to the limit as far as I am able to), so if one want more or less of some logic functions, there need to be synthesis-time configuration changes. This is as far as I know not really used by anyone, so I only build that for the VULOM4, as kind of testing/keeping it in shape. Cheers, H?kan > > > Thank you very much! > > > > > Best greetings > > G?nter > > > > > > From g.weber at hi-jena.gsi.de Thu Apr 11 12:23:10 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Thu, 11 Apr 2024 10:23:10 +0000 Subject: [subexp-daq] problem with R3BFUSER compilation: llwroc_mbscompat not found In-Reply-To: <794ecf43-520b-89f2-1c1a-6846e6398809@chalmers.se> References: <5b4de40c21e04d279bdbb502b53999d0@hi-jena.gsi.de>, <794ecf43-520b-89f2-1c1a-6846e6398809@chalmers.se> Message-ID: <2d204271da304c3984dabc410777a2c1@hi-jena.gsi.de> Dear friends, with the most recent versions of all software packages, I got stuck when doing "make drasi" on the RIO: RIO4L-2 mbsdaq > make drasi NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. 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 -I. -Ibuild_cc_ppc-linux_4.2.2_debug -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/daq/2024_polarimeter/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/daq/2024_polarimeter/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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ggdb 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/ -I. -Ibuild_cc_ppc-linux_4.2.2_debug -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/daq/2024_polarimeter/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/daq/2024_polarimeter/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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ggdb -L../nurdlib/build_cc_ppc-linux_4.2.2_debug /mbs/driv/white_rabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -L/mbsusr/mbsdaq/daq/2024_polarimeter/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/daq/2024_polarimeter/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -llwroc_hwmap_error -lnurdlib /usr/bin/ld: cannot find -llwroc_mbscompat collect2: ld returned 1 exit status 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 -I. -Ibuild_cc_ppc-linux_4.2.2_debug -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/daq/2024_polarimeter/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/daq/2024_polarimeter/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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ggdb 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/ -I. -Ibuild_cc_ppc-linux_4.2.2_debug -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/daq/2024_polarimeter/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/daq/2024_polarimeter/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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ggdb -L../nurdlib/build_cc_ppc-linux_4.2.2_debug /mbs/driv/white_rabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -L/mbsusr/mbsdaq/daq/2024_polarimeter/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/daq/2024_polarimeter/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -llwroc_hwmap_error -lnurdlib /usr/bin/ld: cannot find -llwroc_mbscompat collect2: ld returned 1 exit status 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 -I. -Ibuild_cc_ppc-linux_4.2.2_debug -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/daq/2024_polarimeter/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/daq/2024_polarimeter/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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ggdb 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/ -I. -Ibuild_cc_ppc-linux_4.2.2_debug -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/daq/2024_polarimeter/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/daq/2024_polarimeter/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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ggdb -L../nurdlib/build_cc_ppc-linux_4.2.2_debug /mbs/driv/white_rabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -L/mbsusr/mbsdaq/daq/2024_polarimeter/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/daq/2024_polarimeter/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -llwroc_hwmap_error -lnurdlib /usr/bin/ld: cannot find -llwroc_mbscompat collect2: ld returned 1 exit status Failed. make: *** [build_cc_ppc-linux_4.2.2_debug/nconf.args] Error 1 I did not remember that I saw this problem previously. Is there maybe any special environment variable that needs to set before compiling (like for example TRLOII_PATH in case of NURDLIB compilation)? Thank you very much! Best greetings G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.tornqvist at chalmers.se Thu Apr 11 16:13:41 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Thu, 11 Apr 2024 16:13:41 +0200 Subject: [subexp-daq] problem with R3BFUSER compilation: llwroc_mbscompat not found In-Reply-To: <2d204271da304c3984dabc410777a2c1@hi-jena.gsi.de> References: <5b4de40c21e04d279bdbb502b53999d0@hi-jena.gsi.de> <794ecf43-520b-89f2-1c1a-6846e6398809@chalmers.se> <2d204271da304c3984dabc410777a2c1@hi-jena.gsi.de> Message-ID: <106ea226-6769-4e32-980b-83ab1b0d90be@chalmers.se> Dear G?nter, Looks like the liblwroc_mbscompat.a library provided by drasi is missing. Is that drasi (/mbsusr/mbsdaq/daq/2024_polarimeter/drasi?) up-to-date? Did it compile completely? Cheers, Hans On 2024-04-11 12:23, Weber, Guenter Dr. wrote: > Dear friends, > > with the most recent versions of all software packages, I got stuck when > doing "make drasi" on the RIO: > > RIO4L-2 mbsdaq > make drasi > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. > 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 -I. > -Ibuild_cc_ppc-linux_4.2.2_debug -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/daq/2024_polarimeter/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/daq/2024_polarimeter/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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ggdb > 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/ -I. > -Ibuild_cc_ppc-linux_4.2.2_debug -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/daq/2024_polarimeter/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/daq/2024_polarimeter/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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ggdb -L../nurdlib/build_cc_ppc-linux_4.2.2_debug /mbs/driv/white_rabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -L/mbsusr/mbsdaq/daq/2024_polarimeter/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/daq/2024_polarimeter/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -llwroc_hwmap_error -lnurdlib > /usr/bin/ld: cannot find -llwroc_mbscompat > collect2: ld returned 1 exit status > 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 -I. > -Ibuild_cc_ppc-linux_4.2.2_debug -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/daq/2024_polarimeter/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/daq/2024_polarimeter/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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ggdb > 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/ -I. > -Ibuild_cc_ppc-linux_4.2.2_debug -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/daq/2024_polarimeter/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/daq/2024_polarimeter/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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ggdb -L../nurdlib/build_cc_ppc-linux_4.2.2_debug /mbs/driv/white_rabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -L/mbsusr/mbsdaq/daq/2024_polarimeter/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/daq/2024_polarimeter/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -llwroc_hwmap_error -lnurdlib > /usr/bin/ld: cannot find -llwroc_mbscompat > collect2: ld returned 1 exit status > 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 -I. > -Ibuild_cc_ppc-linux_4.2.2_debug -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/daq/2024_polarimeter/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/daq/2024_polarimeter/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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ggdb > 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/ -I. > -Ibuild_cc_ppc-linux_4.2.2_debug -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/daq/2024_polarimeter/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/daq/2024_polarimeter/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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ggdb -L../nurdlib/build_cc_ppc-linux_4.2.2_debug /mbs/driv/white_rabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -L/mbsusr/mbsdaq/daq/2024_polarimeter/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/daq/2024_polarimeter/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -llwroc_hwmap_error -lnurdlib > /usr/bin/ld: cannot find -llwroc_mbscompat > collect2: ld returned 1 exit status > Failed. > make: *** [build_cc_ppc-linux_4.2.2_debug/nconf.args] Error 1 > > I did not remember that I saw this problem previously. Is there maybe > any special environment variable that needs to set before compiling > (like for example TRLOII_PATH in case of NURDLIB compilation)? > > > Thank you very much! > > > > Best greetings > G?nter > > > > > > > > From g.weber at hi-jena.gsi.de Thu Apr 11 17:30:52 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Thu, 11 Apr 2024 15:30:52 +0000 Subject: [subexp-daq] problem with R3BFUSER compilation: llwroc_mbscompat not found In-Reply-To: <106ea226-6769-4e32-980b-83ab1b0d90be@chalmers.se> References: <5b4de40c21e04d279bdbb502b53999d0@hi-jena.gsi.de> <794ecf43-520b-89f2-1c1a-6846e6398809@chalmers.se> <2d204271da304c3984dabc410777a2c1@hi-jena.gsi.de>, <106ea226-6769-4e32-980b-83ab1b0d90be@chalmers.se> Message-ID: Dear Hans, this is the output when compiling DRASI: RIO4L-2 mbsdaq > make ACC_MAKEFLAGS="" make -C build_rules CC ../dtc_arch/make_acc_auto_def_ppc-linux_4.2.2 ACCRULE gen_ppc-linux_4.2.2/acc_auto_def/mkdir_p.mk ACCRULE gen_ppc-linux_4.2.2/acc_auto_def/warn_flags.mk Warning: working option found, but produces output! ACCRULE gen_ppc-linux_4.2.2/acc_auto_def/cpu_platform.mk Warning: working option found, but produces output! ACCRULE gen_ppc-linux_4.2.2/acc_auto_def/hw_access.mk Warning: working option found, but produces output! ACCRULE gen_ppc-linux_4.2.2/acc_auto_def/perl_path.mk ACCRULE gen_ppc-linux_4.2.2/acc_auto_def/md5sum_path.mk ACCRULE gen_ppc-linux_4.2.2/acc_auto_def/has_ncurses.mk Warning: working option found, but produces output! ACCRULE gen_ppc-linux_4.2.2/acc_auto_def/has_tsmapi.mk Warning: working option found, but produces output! ACCRULE gen_ppc-linux_4.2.2/acc_auto_def/bison_noyacc_flag.mk make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/build_rules' make[1]: Warning: File `gen_ppc-linux_4.2.2/acc_auto_def/bison_noyacc_flag.mk' has modification time 36 s in the future make[1]: Nothing to be done for `all'. make[1]: warning: Clock skew detected. Your build may be incomplete. make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/build_rules' make -C hwmap COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/mkdir_p.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/warn_flags.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/cpu_platform.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/hw_access.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/perl_path.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/md5sum_path.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/has_ncurses.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/has_tsmapi.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/bison_noyacc_flag.mk make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/hwmap' make[1]: Warning: File `gen_ppc-linux_4.2.2/acc_auto_def/bison_noyacc_flag.mk' has modification time 35 s in the future DEPS bld_ppc-linux_4.2.2/hwmap_vme_linux.d DEPS bld_ppc-linux_4.2.2/hwmap_mapvme.d make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/hwmap' make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/hwmap' make[1]: Warning: File `bld_ppc-linux_4.2.2/hwmap_vme_linux.d' has modification time 35 s in the future ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/typedef_func_attrib.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/mystdint.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/myinttypes.h DEPS bld_ppc-linux_4.2.2/hwmap_mapvme.d make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/hwmap' make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/hwmap' make[1]: Warning: File `bld_ppc-linux_4.2.2/hwmap_vme_linux.d' has modification time 34 s in the future CC bld_ppc-linux_4.2.2/hwmap_mapvme.o CC bld_ppc-linux_4.2.2/hwmap_vme_linux.o FULLDEP lib_ppc-linux_4.2.2/libhwmap.dep BASEDEP lib_ppc-linux_4.2.2/libhwmap.base.dep AR lib_ppc-linux_4.2.2/libhwmap.a TOUCH lib_ppc-linux_4.2.2/hwmap_libs.stamp make[1]: warning: Clock skew detected. Your build may be incomplete. make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/hwmap' make -C lwroc COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/mkdir_p.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/warn_flags.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/cpu_platform.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/hw_access.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/perl_path.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/md5sum_path.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/has_ncurses.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/has_tsmapi.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/bison_noyacc_flag.mk make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwroc' make[1]: Warning: File `gen_ppc-linux_4.2.2/acc_auto_def/bison_noyacc_flag.mk' has modification time 36 s in the future DEPS bld_ppc-linux_4.2.2/test_crc32.d DEPS bld_ppc-linux_4.2.2/test_format_prefix.d DEPS bld_ppc-linux_4.2.2/test_track_timestamp.d DEPS bld_ppc-linux_4.2.2/lwroc_hwmap_error.d DEPS bld_ppc-linux_4.2.2/lwroc_mbscompat.d DEPS bld_ppc-linux_4.2.2/lwroc_parse_util.d DEPS bld_ppc-linux_4.2.2/lwroc_net_badrequest.d DEPS bld_ppc-linux_4.2.2/lwroc_hostname_util.d DEPS bld_ppc-linux_4.2.2/lwroc_net_io_util.d DEPS bld_ppc-linux_4.2.2/lwroc_merge_analyse.d DEPS bld_ppc-linux_4.2.2/lwroc_merge_sort.d DEPS bld_ppc-linux_4.2.2/lwroc_merge_in.d DEPS bld_ppc-linux_4.2.2/lwroc_merge.d DEPS bld_ppc-linux_4.2.2/lwroc_filter_none.d DEPS bld_ppc-linux_4.2.2/lwroc_triva_access.d DEPS bld_ppc-linux_4.2.2/lwroc_triva_control.d DEPS bld_ppc-linux_4.2.2/lwroc_triva_readout.d DEPS bld_ppc-linux_4.2.2/lwroc_readout.d DEPS bld_ppc-linux_4.2.2/lwroc_filter.d DEPS bld_ppc-linux_4.2.2/lwroc_main.d DEPS bld_ppc-linux_4.2.2/lwroc_accum_sort.d DEPS bld_ppc-linux_4.2.2/lwroc_calc_mean_sigma.d DEPS bld_ppc-linux_4.2.2/lwroc_leap_seconds.d DEPS bld_ppc-linux_4.2.2/lwroc_net_ntp.d DEPS bld_ppc-linux_4.2.2/lwroc_net_conn_monitor.d DEPS bld_ppc-linux_4.2.2/lwroc_triva_state.d DEPS bld_ppc-linux_4.2.2/lwroc_map_pexor.d DEPS bld_ppc-linux_4.2.2/lwroc_triva_sim.d DEPS bld_ppc-linux_4.2.2/lwroc_triva.d DEPS bld_ppc-linux_4.2.2/lwroc_net_trigbus.d DEPS bld_ppc-linux_4.2.2/lwroc_net_reverse_link.d DEPS bld_ppc-linux_4.2.2/lwroc_net_outgoing.d DEPS bld_ppc-linux_4.2.2/lwroc_net_trans_loop.d DEPS bld_ppc-linux_4.2.2/lwroc_net_trans.d DEPS bld_ppc-linux_4.2.2/lwroc_delayed_eb.d DEPS bld_ppc-linux_4.2.2/lwroc_cpu_affinity.d DEPS bld_ppc-linux_4.2.2/lwroc_net_in_rev_link.d DEPS bld_ppc-linux_4.2.2/lwroc_net_control.d DEPS bld_ppc-linux_4.2.2/lwroc_net_mon.d DEPS bld_ppc-linux_4.2.2/lwroc_net_message.d DEPS bld_ppc-linux_4.2.2/lwroc_net_incoming.d DEPS bld_ppc-linux_4.2.2/lwroc_udp_awaken_hints.d DEPS bld_ppc-linux_4.2.2/lwroc_net_portmap.d DEPS bld_ppc-linux_4.2.2/lwroc_net_client_base.d DEPS bld_ppc-linux_4.2.2/lwroc_net_io.d DEPS bld_ppc-linux_4.2.2/lwroc_slow_async_loop.d DEPS bld_ppc-linux_4.2.2/lwroc_timeout_util.d DEPS bld_ppc-linux_4.2.2/lwroc_tsm_writer.d DEPS bld_ppc-linux_4.2.2/lwroc_fd_writer.d DEPS bld_ppc-linux_4.2.2/lwroc_file_functions.d DEPS bld_ppc-linux_4.2.2/lwroc_crc32.d DEPS bld_ppc-linux_4.2.2/lwroc_file_writer.d DEPS bld_ppc-linux_4.2.2/lwroc_filter_ts.d DEPS bld_ppc-linux_4.2.2/lwroc_filter_loop.d DEPS bld_ppc-linux_4.2.2/hld/lwroc_hld_util.d DEPS bld_ppc-linux_4.2.2/ebye/lwroc_ebye_util.d DEPS bld_ppc-linux_4.2.2/lmd/lwroc_lmd_sticky_store.d DEPS bld_ppc-linux_4.2.2/lmd/lwroc_lmd_ev_sev.d DEPS bld_ppc-linux_4.2.2/lmd/lwroc_lmd_util.d DEPS bld_ppc-linux_4.2.2/gdf/lwroc_gdf_util.d DEPS bld_ppc-linux_4.2.2/lwroc_data_pipe_alloc.d DEPS bld_ppc-linux_4.2.2/lwroc_data_pipe.d DEPS bld_ppc-linux_4.2.2/lwroc_select_util.d DEPS bld_ppc-linux_4.2.2/lwroc_format_prefix.d DEPS bld_ppc-linux_4.2.2/lwroc_serializer_util.d DEPS bld_ppc-linux_4.2.2/lwroc_serializers.d DEPS bld_ppc-linux_4.2.2/lwroc_control.d DEPS bld_ppc-linux_4.2.2/lwroc_mon_block.d DEPS bld_ppc-linux_4.2.2/lwroc_two_copy.d DEPS bld_ppc-linux_4.2.2/lwroc_message_wait.d DEPS bld_ppc-linux_4.2.2/lwroc_message_internal.d DEPS bld_ppc-linux_4.2.2/lwroc_item_buffer.d DEPS bld_ppc-linux_4.2.2/lwroc_thread_util.d DEPS bld_ppc-linux_4.2.2/lwroc_thread_block.d DEPS bld_ppc-linux_4.2.2/lwroc_pipe_buffer.d make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwroc' make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwroc' make[1]: Warning: File `bld_ppc-linux_4.2.2/test_crc32.d' has modification time 23 s in the future ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/mystdint.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/byteorder_include.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/byteswap_include.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/myinttypes.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/myprizd.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/time_include.h DEPS bld_ppc-linux_4.2.2/test_crc32.d ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/has_snprintf.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/myisfinite.h DEPS bld_ppc-linux_4.2.2/test_format_prefix.d ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/mynan.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/variadic_macros.h DEPS bld_ppc-linux_4.2.2/test_track_timestamp.d ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/select_include.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/mfence.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/typedef_func_attrib.h DEPS bld_ppc-linux_4.2.2/lwroc_hwmap_error.d DEPS bld_ppc-linux_4.2.2/lwroc_mbscompat.d ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/mystrndup.h DEPS bld_ppc-linux_4.2.2/lwroc_parse_util.d ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/netinet_in_include.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/socket_include.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/socket_types.h DEPS bld_ppc-linux_4.2.2/lwroc_net_badrequest.d ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/has_getifaddrs.h DEPS bld_ppc-linux_4.2.2/lwroc_hostname_util.d DEPS bld_ppc-linux_4.2.2/lwroc_net_io_util.d ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/cpu_affinity.h DEPS bld_ppc-linux_4.2.2/lwroc_merge_analyse.d ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/fall_through.h DEPS bld_ppc-linux_4.2.2/lwroc_merge_sort.d DEPS bld_ppc-linux_4.2.2/lwroc_merge_in.d DEPS bld_ppc-linux_4.2.2/lwroc_merge.d DEPS bld_ppc-linux_4.2.2/lwroc_filter_none.d DEPS bld_ppc-linux_4.2.2/lwroc_triva_access.d DEPS bld_ppc-linux_4.2.2/lwroc_triva_control.d DEPS bld_ppc-linux_4.2.2/lwroc_triva_readout.d DEPS bld_ppc-linux_4.2.2/lwroc_readout.d DEPS bld_ppc-linux_4.2.2/lwroc_filter.d DEPS bld_ppc-linux_4.2.2/lwroc_main.d DEPS bld_ppc-linux_4.2.2/lwroc_accum_sort.d DEPS bld_ppc-linux_4.2.2/lwroc_calc_mean_sigma.d DEPS bld_ppc-linux_4.2.2/lwroc_leap_seconds.d DEPS bld_ppc-linux_4.2.2/lwroc_net_ntp.d DEPS bld_ppc-linux_4.2.2/lwroc_net_conn_monitor.d DEPS bld_ppc-linux_4.2.2/lwroc_triva_state.d DEPS bld_ppc-linux_4.2.2/lwroc_map_pexor.d DEPS bld_ppc-linux_4.2.2/lwroc_triva_sim.d DEPS bld_ppc-linux_4.2.2/lwroc_triva.d DEPS bld_ppc-linux_4.2.2/lwroc_net_trigbus.d DEPS bld_ppc-linux_4.2.2/lwroc_net_reverse_link.d DEPS bld_ppc-linux_4.2.2/lwroc_net_outgoing.d DEPS bld_ppc-linux_4.2.2/lwroc_net_trans_loop.d DEPS bld_ppc-linux_4.2.2/lwroc_net_trans.d DEPS bld_ppc-linux_4.2.2/lwroc_delayed_eb.d DEPS bld_ppc-linux_4.2.2/lwroc_cpu_affinity.d DEPS bld_ppc-linux_4.2.2/lwroc_net_in_rev_link.d DEPS bld_ppc-linux_4.2.2/lwroc_net_control.d ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/has_msg_nosignal.h DEPS bld_ppc-linux_4.2.2/lwroc_net_mon.d DEPS bld_ppc-linux_4.2.2/lwroc_net_message.d DEPS bld_ppc-linux_4.2.2/lwroc_net_incoming.d DEPS bld_ppc-linux_4.2.2/lwroc_udp_awaken_hints.d DEPS bld_ppc-linux_4.2.2/lwroc_net_portmap.d DEPS bld_ppc-linux_4.2.2/lwroc_net_client_base.d DEPS bld_ppc-linux_4.2.2/lwroc_net_io.d DEPS bld_ppc-linux_4.2.2/lwroc_slow_async_loop.d DEPS bld_ppc-linux_4.2.2/lwroc_timeout_util.d ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/has_tsmapi.h DEPS bld_ppc-linux_4.2.2/lwroc_tsm_writer.d DEPS bld_ppc-linux_4.2.2/lwroc_fd_writer.d DEPS bld_ppc-linux_4.2.2/lwroc_file_functions.d DEPS bld_ppc-linux_4.2.2/lwroc_crc32.d DEPS bld_ppc-linux_4.2.2/lwroc_file_writer.d DEPS bld_ppc-linux_4.2.2/lwroc_filter_ts.d DEPS bld_ppc-linux_4.2.2/lwroc_filter_loop.d DEPS bld_ppc-linux_4.2.2/hld/lwroc_hld_util.d DEPS bld_ppc-linux_4.2.2/ebye/lwroc_ebye_util.d DEPS bld_ppc-linux_4.2.2/lmd/lwroc_lmd_sticky_store.d DEPS bld_ppc-linux_4.2.2/lmd/lwroc_lmd_ev_sev.d DEPS bld_ppc-linux_4.2.2/lmd/lwroc_lmd_util.d DEPS bld_ppc-linux_4.2.2/gdf/lwroc_gdf_util.d ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/has_valloc.h DEPS bld_ppc-linux_4.2.2/lwroc_data_pipe_alloc.d DEPS bld_ppc-linux_4.2.2/lwroc_data_pipe.d DEPS bld_ppc-linux_4.2.2/lwroc_select_util.d DEPS bld_ppc-linux_4.2.2/lwroc_format_prefix.d ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/has_curses.h DEPS bld_ppc-linux_4.2.2/lwroc_serializer_util.d DEPS bld_ppc-linux_4.2.2/lwroc_serializers.d DEPS bld_ppc-linux_4.2.2/lwroc_control.d ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/has_getrusage.h DEPS bld_ppc-linux_4.2.2/lwroc_mon_block.d DEPS bld_ppc-linux_4.2.2/lwroc_two_copy.d DEPS bld_ppc-linux_4.2.2/lwroc_message_wait.d ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/has_pthread_getname_np.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/has_strerror_r.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/has_vsnprintf.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/has_backtrace.h DEPS bld_ppc-linux_4.2.2/lwroc_message_internal.d DEPS bld_ppc-linux_4.2.2/lwroc_item_buffer.d DEPS bld_ppc-linux_4.2.2/lwroc_thread_util.d DEPS bld_ppc-linux_4.2.2/lwroc_thread_block.d DEPS bld_ppc-linux_4.2.2/lwroc_pipe_buffer.d make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwroc' make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwroc' make[1]: Warning: File `bld_ppc-linux_4.2.2/test_crc32.d' has modification time 15 s in the future CC bld_ppc-linux_4.2.2/lwroc_pipe_buffer.o CC bld_ppc-linux_4.2.2/lwroc_thread_block.o CC bld_ppc-linux_4.2.2/lwroc_thread_util.o CC bld_ppc-linux_4.2.2/lwroc_item_buffer.o CC bld_ppc-linux_4.2.2/lwroc_message_internal.o lwroc_message_internal.c: In function 'lwroc_do_message_internal': lwroc_message_internal.c:1526: warning: declaration of 'timeout' shadows a global declaration /usr/include/ncurses/curses.h:757: warning: shadowed declaration is here CC bld_ppc-linux_4.2.2/lwroc_message_wait.o CC bld_ppc-linux_4.2.2/lwroc_two_copy.o CC bld_ppc-linux_4.2.2/lwroc_mon_block.o CC bld_ppc-linux_4.2.2/lwroc_control.o CC bld_ppc-linux_4.2.2/lwroc_serializers.o CC bld_ppc-linux_4.2.2/lwroc_serializer_util.o CC bld_ppc-linux_4.2.2/lwroc_format_prefix.o CC bld_ppc-linux_4.2.2/lwroc_select_util.o CC bld_ppc-linux_4.2.2/lwroc_data_pipe.o CC bld_ppc-linux_4.2.2/lwroc_data_pipe_alloc.o CC bld_ppc-linux_4.2.2/gdf/lwroc_gdf_util.o CC bld_ppc-linux_4.2.2/lmd/lwroc_lmd_util.o CC bld_ppc-linux_4.2.2/lmd/lwroc_lmd_ev_sev.o CC bld_ppc-linux_4.2.2/lmd/lwroc_lmd_sticky_store.o CC bld_ppc-linux_4.2.2/ebye/lwroc_ebye_util.o CC bld_ppc-linux_4.2.2/hld/lwroc_hld_util.o CC bld_ppc-linux_4.2.2/lwroc_filter_loop.o CC bld_ppc-linux_4.2.2/lwroc_filter_ts.o CC bld_ppc-linux_4.2.2/lwroc_file_writer.o CC bld_ppc-linux_4.2.2/lwroc_crc32.o CC bld_ppc-linux_4.2.2/lwroc_file_functions.o CC bld_ppc-linux_4.2.2/lwroc_fd_writer.o CC bld_ppc-linux_4.2.2/lwroc_tsm_writer.o CC bld_ppc-linux_4.2.2/lwroc_timeout_util.o CC bld_ppc-linux_4.2.2/lwroc_slow_async_loop.o CC bld_ppc-linux_4.2.2/lwroc_net_io.o CC bld_ppc-linux_4.2.2/lwroc_net_client_base.o CC bld_ppc-linux_4.2.2/lwroc_net_portmap.o CC bld_ppc-linux_4.2.2/lwroc_udp_awaken_hints.o CC bld_ppc-linux_4.2.2/lwroc_net_incoming.o CC bld_ppc-linux_4.2.2/lwroc_net_message.o CC bld_ppc-linux_4.2.2/lwroc_net_mon.o CC bld_ppc-linux_4.2.2/lwroc_net_control.o CC bld_ppc-linux_4.2.2/lwroc_net_in_rev_link.o CC bld_ppc-linux_4.2.2/lwroc_cpu_affinity.o CC bld_ppc-linux_4.2.2/lwroc_delayed_eb.o CC bld_ppc-linux_4.2.2/lwroc_net_trans.o CC bld_ppc-linux_4.2.2/lwroc_net_trans_loop.o CC bld_ppc-linux_4.2.2/lwroc_net_outgoing.o CC bld_ppc-linux_4.2.2/lwroc_net_reverse_link.o CC bld_ppc-linux_4.2.2/lwroc_net_trigbus.o CC bld_ppc-linux_4.2.2/lwroc_triva.o CC bld_ppc-linux_4.2.2/lwroc_triva_sim.o CC bld_ppc-linux_4.2.2/lwroc_map_pexor.o CC bld_ppc-linux_4.2.2/lwroc_triva_state.o CC bld_ppc-linux_4.2.2/lwroc_net_conn_monitor.o CC bld_ppc-linux_4.2.2/lwroc_net_ntp.o CC bld_ppc-linux_4.2.2/lwroc_leap_seconds.o CC bld_ppc-linux_4.2.2/lwroc_calc_mean_sigma.o CC bld_ppc-linux_4.2.2/lwroc_accum_sort.o AR lib_ppc-linux_4.2.2/liblwroc.a CC bld_ppc-linux_4.2.2/lwroc_main.o CC bld_ppc-linux_4.2.2/lwroc_filter.o AR lib_ppc-linux_4.2.2/liblwroc_main.a CC bld_ppc-linux_4.2.2/lwroc_readout.o CC bld_ppc-linux_4.2.2/lwroc_triva_readout.o CC bld_ppc-linux_4.2.2/lwroc_triva_control.o CC bld_ppc-linux_4.2.2/lwroc_triva_access.o AR lib_ppc-linux_4.2.2/liblwroc_readout.a CC bld_ppc-linux_4.2.2/lwroc_filter_none.o AR lib_ppc-linux_4.2.2/liblwroc_nofilter.a CC bld_ppc-linux_4.2.2/lwroc_net_io_util.o CC bld_ppc-linux_4.2.2/lwroc_hostname_util.o CC bld_ppc-linux_4.2.2/lwroc_net_badrequest.o AR lib_ppc-linux_4.2.2/liblwroc_netutil.a CC bld_ppc-linux_4.2.2/lwroc_parse_util.o AR lib_ppc-linux_4.2.2/liblwroc_parseutil.a CC bld_ppc-linux_4.2.2/lwroc_mbscompat.o AR lib_ppc-linux_4.2.2/liblwroc_mbscompat.a CC bld_ppc-linux_4.2.2/lwroc_hwmap_error.o AR lib_ppc-linux_4.2.2/liblwroc_hwmap_error.a CC bld_ppc-linux_4.2.2/lwroc_merge.o CC bld_ppc-linux_4.2.2/lwroc_merge_in.o CC bld_ppc-linux_4.2.2/lwroc_merge_sort.o CC bld_ppc-linux_4.2.2/lwroc_merge_analyse.o AR lib_ppc-linux_4.2.2/liblwroc_merge.a CONFIG lib_ppc-linux_4.2.2/lwroc_libs.config CC bld_ppc-linux_4.2.2/test_crc32.o LINK bin_ppc-linux_4.2.2/test_crc32 CHECK bin_ppc-linux_4.2.2/test_crc32.test TOUCH lib_ppc-linux_4.2.2/lwroc_libs.stamp CC bld_ppc-linux_4.2.2/test_track_timestamp.o LINK bin_ppc-linux_4.2.2/test_track_timestamp CC bld_ppc-linux_4.2.2/test_format_prefix.o LINK bin_ppc-linux_4.2.2/test_format_prefix make[1]: warning: Clock skew detected. Your build may be incomplete. make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwroc' make -C lwrocmon COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/mkdir_p.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/warn_flags.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/cpu_platform.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/hw_access.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/perl_path.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/md5sum_path.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/has_ncurses.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/has_tsmapi.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/bison_noyacc_flag.mk make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwrocmon' make[1]: Warning: File `gen_ppc-linux_4.2.2/acc_auto_def/bison_noyacc_flag.mk' has modification time 36 s in the future DEPS bld_ppc-linux_4.2.2/lwrocdt.d DEPS bld_ppc-linux_4.2.2/lwrocctrl.d DEPS bld_ppc-linux_4.2.2/lwroclog.d DEPS bld_ppc-linux_4.2.2/lwroc_mon_status.d DEPS bld_ppc-linux_4.2.2/lwroc_mon_tree.d DEPS bld_ppc-linux_4.2.2/lwroc_mon_detail.d DEPS bld_ppc-linux_4.2.2/lwroc_mon_rate.d DEPS bld_ppc-linux_4.2.2/lwroc_mon_basic.d DEPS bld_ppc-linux_4.2.2/lwroc_mon_msg.d DEPS bld_ppc-linux_4.2.2/lwroc_mon_udp_hint.d DEPS bld_ppc-linux_4.2.2/lwroc_mon_conn.d DEPS bld_ppc-linux_4.2.2/lwroc_mon_buffer.d DEPS bld_ppc-linux_4.2.2/lwrocmon.d make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwrocmon' make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwrocmon' make[1]: Warning: File `bld_ppc-linux_4.2.2/lwrocdt.d' has modification time 33 s in the future ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/myinttypes.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/mystdint.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/variadic_macros.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/time_include.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/select_include.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/mfence.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/myprizd.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/has_curses.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/mystrndup.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/mynan.h DEPS bld_ppc-linux_4.2.2/lwrocdt.d ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/netinet_in_include.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/socket_include.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/socket_types.h DEPS bld_ppc-linux_4.2.2/lwrocctrl.d DEPS bld_ppc-linux_4.2.2/lwroclog.d DEPS bld_ppc-linux_4.2.2/lwroc_mon_status.d DEPS bld_ppc-linux_4.2.2/lwroc_mon_tree.d DEPS bld_ppc-linux_4.2.2/lwroc_mon_detail.d ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/has_tiocgwinsz.h DEPS bld_ppc-linux_4.2.2/lwroc_mon_rate.d ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/fall_through.h DEPS bld_ppc-linux_4.2.2/lwroc_mon_basic.d DEPS bld_ppc-linux_4.2.2/lwroc_mon_msg.d DEPS bld_ppc-linux_4.2.2/lwroc_mon_udp_hint.d DEPS bld_ppc-linux_4.2.2/lwroc_mon_conn.d ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/has_msg_nosignal.h DEPS bld_ppc-linux_4.2.2/lwroc_mon_buffer.d DEPS bld_ppc-linux_4.2.2/lwrocmon.d make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwrocmon' make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwrocmon' make[1]: Warning: File `bld_ppc-linux_4.2.2/lwrocdt.d' has modification time 32 s in the future DEPS bld_ppc-linux_4.2.2/lwroc_mon_tree.d make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwrocmon' make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwrocmon' make[1]: Warning: File `bld_ppc-linux_4.2.2/lwrocdt.d' has modification time 31 s in the future CC bld_ppc-linux_4.2.2/lwrocmon.o CC bld_ppc-linux_4.2.2/lwroc_mon_buffer.o CC bld_ppc-linux_4.2.2/lwroc_mon_conn.o CC bld_ppc-linux_4.2.2/lwroc_mon_udp_hint.o CC bld_ppc-linux_4.2.2/lwroc_mon_msg.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 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 CC bld_ppc-linux_4.2.2/lwrocdt.o LINK bin_ppc-linux_4.2.2/lwrocdt LINK bin_ppc-linux_4.2.2/lwrocmerge make[1]: warning: Clock skew detected. Your build may be incomplete. make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwrocmon' make -C nulldaq make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/nulldaq' DEPS bld_ppc-linux_4.2.2/nulldaq.d make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/nulldaq' make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/nulldaq' make[1]: Warning: File `bld_ppc-linux_4.2.2/nulldaq.d' has modification time 36 s in the future CC bld_ppc-linux_4.2.2/nulldaq.o LINK bin_ppc-linux_4.2.2/nulldaq make[1]: warning: Clock skew detected. Your build may be incomplete. make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/nulldaq' make -C testdaq make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/testdaq' DEPS bld_ppc-linux_4.2.2/testdaq.d make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/testdaq' make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/testdaq' make[1]: Warning: File `bld_ppc-linux_4.2.2/testdaq.d' has modification time 36 s in the future CC bld_ppc-linux_4.2.2/testdaq.o LINK bin_ppc-linux_4.2.2/testdaq make[1]: warning: Clock skew detected. Your build may be incomplete. make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/testdaq' make -C f_user_daq COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/mkdir_p.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/warn_flags.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/cpu_platform.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/hw_access.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/perl_path.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/md5sum_path.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/has_ncurses.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/has_tsmapi.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/bison_noyacc_flag.mk make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/f_user_daq' make[1]: Warning: File `gen_ppc-linux_4.2.2/acc_auto_def/bison_noyacc_flag.mk' has modification time 36 s in the future DEPS bld_ppc-linux_4.2.2/./f_user_daq.d make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/f_user_daq' make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/f_user_daq' make[1]: Warning: File `bld_ppc-linux_4.2.2/./f_user_daq.d' has modification time 36 s in the future ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/mystdint.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/variadic_macros.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/time_include.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/select_include.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/mfence.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/cpu_affinity.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/myinttypes.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/byteorder_include.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/myprizd.h DEPS bld_ppc-linux_4.2.2/./f_user_daq.d make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/f_user_daq' make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/f_user_daq' make[1]: Warning: File `bld_ppc-linux_4.2.2/./f_user_daq.d' has modification time 35 s in the future CC bld_ppc-linux_4.2.2/./f_user_daq.o make[1]: warning: Clock skew detected. Your build may be incomplete. make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/f_user_daq' make -C trigbussim COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/mkdir_p.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/warn_flags.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/cpu_platform.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/hw_access.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/perl_path.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/md5sum_path.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/has_ncurses.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/has_tsmapi.mk COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/bison_noyacc_flag.mk make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/trigbussim' make[1]: Warning: File `gen_ppc-linux_4.2.2/acc_auto_def/bison_noyacc_flag.mk' has modification time 36 s in the future DEPS bld_ppc-linux_4.2.2/message_internal.d DEPS bld_ppc-linux_4.2.2/port_help.d DEPS bld_ppc-linux_4.2.2/test_tbs.d DEPS bld_ppc-linux_4.2.2/trigbussim.d make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/trigbussim' make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/trigbussim' make[1]: Warning: File `bld_ppc-linux_4.2.2/message_internal.d' has modification time 35 s in the future ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/mystdint.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/variadic_macros.h DEPS bld_ppc-linux_4.2.2/message_internal.d ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/myinttypes.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/netinet_in_include.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/socket_include.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/socket_types.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/time_include.h ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/select_include.h DEPS bld_ppc-linux_4.2.2/port_help.d ACCDEF gen_ppc-linux_4.2.2/acc_auto_def/myprizd.h DEPS bld_ppc-linux_4.2.2/test_tbs.d DEPS bld_ppc-linux_4.2.2/trigbussim.d make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/trigbussim' make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/trigbussim' make[1]: Warning: File `bld_ppc-linux_4.2.2/message_internal.d' has modification time 31 s in the future CC bld_ppc-linux_4.2.2/trigbussim.o CC bld_ppc-linux_4.2.2/message_internal.o LINK bin_ppc-linux_4.2.2/trigbussim CC bld_ppc-linux_4.2.2/test_tbs.o LINK bin_ppc-linux_4.2.2/test_tbs CC bld_ppc-linux_4.2.2/port_help.o LINK bin_ppc-linux_4.2.2/port_help make[1]: warning: Clock skew detected. Your build may be incomplete. make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/trigbussim' make -C f_user_example -f makefile.drasi make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/f_user_example' make[1]: Warning: File `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../f_user_daq/bld_ppc-linux_4.2.2/f_user_daq.o' has modification time 25 s in the future CC ppc-linux_4.2.2-f_user_example.o LINK ppc-linux_4.2.2-f_user_example CC ppc-linux_4.2.2-f_user_regress.o LINK ppc-linux_4.2.2-f_user_regress CC ppc-linux_4.2.2-f_user_speed.o LINK ppc-linux_4.2.2-f_user_speed CC ppc-linux_4.2.2-filter_example.o LINK ppc-linux_4.2.2-filter_example CC ppc-linux_4.2.2-filter_trbts2lmdwr.o LINK ppc-linux_4.2.2-filter_trbts2lmdwr CC ppc-linux_4.2.2-filter_lmd2ebye.o LINK ppc-linux_4.2.2-filter_lmd2ebye make[1]: warning: Clock skew detected. Your build may be incomplete. make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/f_user_example' Within this we have the following line: AR lib_ppc-linux_4.2.2/liblwroc_mbscompat.a I used the most recent DRASI package (downloaded from GITLAB this morning.) Best greetings G?nter ________________________________ Von: Hans Toshihide T?rnqvist Gesendet: Donnerstag, 11. April 2024 16:13:41 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr. Betreff: Re: [subexp-daq] problem with R3BFUSER compilation: llwroc_mbscompat not found Dear G?nter, Looks like the liblwroc_mbscompat.a library provided by drasi is missing. Is that drasi (/mbsusr/mbsdaq/daq/2024_polarimeter/drasi?) up-to-date? Did it compile completely? Cheers, Hans On 2024-04-11 12:23, Weber, Guenter Dr. wrote: > Dear friends, > > with the most recent versions of all software packages, I got stuck when > doing "make drasi" on the RIO: > > RIO4L-2 mbsdaq > make drasi > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. > 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 -I. > -Ibuild_cc_ppc-linux_4.2.2_debug -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/daq/2024_polarimeter/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/daq/2024_polarimeter/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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ggdb > 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/ -I. > -Ibuild_cc_ppc-linux_4.2.2_debug -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/daq/2024_polarimeter/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/daq/2024_polarimeter/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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ggdb -L../nurdlib/build_cc_ppc-linux_4.2.2_debug /mbs/driv/white_rabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -L/mbsusr/mbsdaq/daq/2024_polarimeter/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/daq/2024_polarimeter/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -llwroc_hwmap_error -lnurdlib > /usr/bin/ld: cannot find -llwroc_mbscompat > collect2: ld returned 1 exit status > 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 -I. > -Ibuild_cc_ppc-linux_4.2.2_debug -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/daq/2024_polarimeter/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/daq/2024_polarimeter/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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ggdb > 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/ -I. > -Ibuild_cc_ppc-linux_4.2.2_debug -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/daq/2024_polarimeter/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/daq/2024_polarimeter/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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ggdb -L../nurdlib/build_cc_ppc-linux_4.2.2_debug /mbs/driv/white_rabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -L/mbsusr/mbsdaq/daq/2024_polarimeter/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/daq/2024_polarimeter/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -llwroc_hwmap_error -lnurdlib > /usr/bin/ld: cannot find -llwroc_mbscompat > collect2: ld returned 1 exit status > 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 -I. > -Ibuild_cc_ppc-linux_4.2.2_debug -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/daq/2024_polarimeter/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/daq/2024_polarimeter/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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ggdb > 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/ -I. > -Ibuild_cc_ppc-linux_4.2.2_debug -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/daq/2024_polarimeter/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/daq/2024_polarimeter/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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ggdb -L../nurdlib/build_cc_ppc-linux_4.2.2_debug /mbs/driv/white_rabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -L/mbsusr/mbsdaq/daq/2024_polarimeter/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/daq/2024_polarimeter/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -llwroc_hwmap_error -lnurdlib > /usr/bin/ld: cannot find -llwroc_mbscompat > collect2: ld returned 1 exit status > Failed. > make: *** [build_cc_ppc-linux_4.2.2_debug/nconf.args] Error 1 > > I did not remember that I saw this problem previously. Is there maybe > any special environment variable that needs to set before compiling > (like for example TRLOII_PATH in case of NURDLIB compilation)? > > > Thank you very much! > > > > Best greetings > G?nter > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Thu Apr 11 17:53:40 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Thu, 11 Apr 2024 17:53:40 +0200 Subject: [subexp-daq] problem with R3BFUSER compilation: llwroc_mbscompat not found In-Reply-To: References: <5b4de40c21e04d279bdbb502b53999d0@hi-jena.gsi.de> <794ecf43-520b-89f2-1c1a-6846e6398809@chalmers.se> <2d204271da304c3984dabc410777a2c1@hi-jena.gsi.de>, <106ea226-6769-4e32-980b-83ab1b0d90be@chalmers.se> Message-ID: In the r3bfuser compile issue logs the paths to drasi start with: /mbsusr/mbsdaq/... but its compile seems to be in /LynxOS/mbsusr/mbsdaq/... Something is mismatching? Cheers, H?kan On Thu, 11 Apr 2024, Weber, Guenter Dr. wrote: > > Dear Hans, > > > this is the output when compiling DRASI: > > > RIO4L-2 mbsdaq > make > ACC_MAKEFLAGS="" make -C build_rules > ? ?CC? ? ../dtc_arch/make_acc_auto_def_ppc-linux_4.2.2 > ?ACCRULE gen_ppc-linux_4.2.2/acc_auto_def/mkdir_p.mk > ?ACCRULE gen_ppc-linux_4.2.2/acc_auto_def/warn_flags.mk > Warning: working option found, but produces output! > ?ACCRULE gen_ppc-linux_4.2.2/acc_auto_def/cpu_platform.mk > Warning: working option found, but produces output! > ?ACCRULE gen_ppc-linux_4.2.2/acc_auto_def/hw_access.mk > Warning: working option found, but produces output! > ?ACCRULE gen_ppc-linux_4.2.2/acc_auto_def/perl_path.mk > ?ACCRULE gen_ppc-linux_4.2.2/acc_auto_def/md5sum_path.mk > ?ACCRULE gen_ppc-linux_4.2.2/acc_auto_def/has_ncurses.mk > Warning: working option found, but produces output! > ?ACCRULE gen_ppc-linux_4.2.2/acc_auto_def/has_tsmapi.mk > Warning: working option found, but produces output! > ?ACCRULE gen_ppc-linux_4.2.2/acc_auto_def/bison_noyacc_flag.mk > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/build_rules' > make[1]: Warning: File `gen_ppc-linux_4.2.2/acc_auto_def/bison_noyacc_flag.mk' has modification time 36 s in the future > make[1]: Nothing to be done for `all'. > make[1]: warning:? Clock skew detected.? Your build may be incomplete. > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/build_rules' > make -C hwmap > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/mkdir_p.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/warn_flags.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/cpu_platform.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/hw_access.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/perl_path.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/md5sum_path.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/has_ncurses.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/has_tsmapi.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/bison_noyacc_flag.mk > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/hwmap' > make[1]: Warning: File `gen_ppc-linux_4.2.2/acc_auto_def/bison_noyacc_flag.mk' has modification time 35 s in the future > ? DEPS? ?bld_ppc-linux_4.2.2/hwmap_vme_linux.d > ? DEPS? ?bld_ppc-linux_4.2.2/hwmap_mapvme.d > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/hwmap' > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/hwmap' > make[1]: Warning: File `bld_ppc-linux_4.2.2/hwmap_vme_linux.d' has modification time 35 s in the future > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/typedef_func_attrib.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/mystdint.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/myinttypes.h > ? DEPS? ?bld_ppc-linux_4.2.2/hwmap_mapvme.d > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/hwmap' > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/hwmap' > make[1]: Warning: File `bld_ppc-linux_4.2.2/hwmap_vme_linux.d' has modification time 34 s in the future > ? ?CC? ? bld_ppc-linux_4.2.2/hwmap_mapvme.o > ? ?CC? ? bld_ppc-linux_4.2.2/hwmap_vme_linux.o > ?FULLDEP lib_ppc-linux_4.2.2/libhwmap.dep > ?BASEDEP lib_ppc-linux_4.2.2/libhwmap.base.dep > ? ?AR? ? lib_ppc-linux_4.2.2/libhwmap.a > ? TOUCH? lib_ppc-linux_4.2.2/hwmap_libs.stamp > make[1]: warning:? Clock skew detected.? Your build may be incomplete. > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/hwmap' > make -C lwroc > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/mkdir_p.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/warn_flags.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/cpu_platform.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/hw_access.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/perl_path.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/md5sum_path.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/has_ncurses.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/has_tsmapi.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/bison_noyacc_flag.mk > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwroc' > make[1]: Warning: File `gen_ppc-linux_4.2.2/acc_auto_def/bison_noyacc_flag.mk' has modification time 36 s in the future > ? DEPS? ?bld_ppc-linux_4.2.2/test_crc32.d > ? DEPS? ?bld_ppc-linux_4.2.2/test_format_prefix.d > ? DEPS? ?bld_ppc-linux_4.2.2/test_track_timestamp.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_hwmap_error.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_mbscompat.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_parse_util.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_badrequest.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_hostname_util.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_io_util.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_merge_analyse.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_merge_sort.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_merge_in.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_merge.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_filter_none.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_triva_access.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_triva_control.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_triva_readout.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_readout.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_filter.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_main.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_accum_sort.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_calc_mean_sigma.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_leap_seconds.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_ntp.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_conn_monitor.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_triva_state.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_map_pexor.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_triva_sim.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_triva.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_trigbus.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_reverse_link.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_outgoing.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_trans_loop.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_trans.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_delayed_eb.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_cpu_affinity.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_in_rev_link.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_control.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_mon.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_message.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_incoming.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_udp_awaken_hints.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_portmap.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_client_base.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_io.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_slow_async_loop.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_timeout_util.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_tsm_writer.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_fd_writer.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_file_functions.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_crc32.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_file_writer.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_filter_ts.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_filter_loop.d > ? DEPS? ?bld_ppc-linux_4.2.2/hld/lwroc_hld_util.d > ? DEPS? ?bld_ppc-linux_4.2.2/ebye/lwroc_ebye_util.d > ? DEPS? ?bld_ppc-linux_4.2.2/lmd/lwroc_lmd_sticky_store.d > ? DEPS? ?bld_ppc-linux_4.2.2/lmd/lwroc_lmd_ev_sev.d > ? DEPS? ?bld_ppc-linux_4.2.2/lmd/lwroc_lmd_util.d > ? DEPS? ?bld_ppc-linux_4.2.2/gdf/lwroc_gdf_util.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_data_pipe_alloc.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_data_pipe.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_select_util.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_format_prefix.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_serializer_util.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_serializers.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_control.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_mon_block.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_two_copy.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_message_wait.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_message_internal.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_item_buffer.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_thread_util.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_thread_block.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_pipe_buffer.d > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwroc' > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwroc' > make[1]: Warning: File `bld_ppc-linux_4.2.2/test_crc32.d' has modification time 23 s in the future > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/mystdint.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/byteorder_include.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/byteswap_include.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/myinttypes.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/myprizd.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/time_include.h > ? DEPS? ?bld_ppc-linux_4.2.2/test_crc32.d > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/has_snprintf.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/myisfinite.h > ? DEPS? ?bld_ppc-linux_4.2.2/test_format_prefix.d > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/mynan.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/variadic_macros.h > ? DEPS? ?bld_ppc-linux_4.2.2/test_track_timestamp.d > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/select_include.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/mfence.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/typedef_func_attrib.h > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_hwmap_error.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_mbscompat.d > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/mystrndup.h > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_parse_util.d > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/netinet_in_include.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/socket_include.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/socket_types.h > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_badrequest.d > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/has_getifaddrs.h > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_hostname_util.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_io_util.d > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/cpu_affinity.h > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_merge_analyse.d > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/fall_through.h > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_merge_sort.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_merge_in.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_merge.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_filter_none.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_triva_access.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_triva_control.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_triva_readout.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_readout.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_filter.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_main.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_accum_sort.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_calc_mean_sigma.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_leap_seconds.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_ntp.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_conn_monitor.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_triva_state.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_map_pexor.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_triva_sim.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_triva.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_trigbus.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_reverse_link.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_outgoing.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_trans_loop.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_trans.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_delayed_eb.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_cpu_affinity.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_in_rev_link.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_control.d > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/has_msg_nosignal.h > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_mon.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_message.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_incoming.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_udp_awaken_hints.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_portmap.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_client_base.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_net_io.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_slow_async_loop.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_timeout_util.d > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/has_tsmapi.h > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_tsm_writer.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_fd_writer.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_file_functions.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_crc32.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_file_writer.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_filter_ts.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_filter_loop.d > ? DEPS? ?bld_ppc-linux_4.2.2/hld/lwroc_hld_util.d > ? DEPS? ?bld_ppc-linux_4.2.2/ebye/lwroc_ebye_util.d > ? DEPS? ?bld_ppc-linux_4.2.2/lmd/lwroc_lmd_sticky_store.d > ? DEPS? ?bld_ppc-linux_4.2.2/lmd/lwroc_lmd_ev_sev.d > ? DEPS? ?bld_ppc-linux_4.2.2/lmd/lwroc_lmd_util.d > ? DEPS? ?bld_ppc-linux_4.2.2/gdf/lwroc_gdf_util.d > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/has_valloc.h > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_data_pipe_alloc.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_data_pipe.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_select_util.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_format_prefix.d > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/has_curses.h > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_serializer_util.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_serializers.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_control.d > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/has_getrusage.h > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_mon_block.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_two_copy.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_message_wait.d > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/has_pthread_getname_np.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/has_strerror_r.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/has_vsnprintf.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/has_backtrace.h > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_message_internal.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_item_buffer.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_thread_util.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_thread_block.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_pipe_buffer.d > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwroc' > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwroc' > make[1]: Warning: File `bld_ppc-linux_4.2.2/test_crc32.d' has modification time 15 s in the future > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_pipe_buffer.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_thread_block.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_thread_util.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_item_buffer.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_message_internal.o > lwroc_message_internal.c: In function 'lwroc_do_message_internal': > lwroc_message_internal.c:1526: warning: declaration of 'timeout' shadows a global declaration > /usr/include/ncurses/curses.h:757: warning: shadowed declaration is here > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_message_wait.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_two_copy.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_mon_block.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_control.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_serializers.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_serializer_util.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_format_prefix.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_select_util.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_data_pipe.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_data_pipe_alloc.o > ? ?CC? ? bld_ppc-linux_4.2.2/gdf/lwroc_gdf_util.o > ? ?CC? ? bld_ppc-linux_4.2.2/lmd/lwroc_lmd_util.o > ? ?CC? ? bld_ppc-linux_4.2.2/lmd/lwroc_lmd_ev_sev.o > ? ?CC? ? bld_ppc-linux_4.2.2/lmd/lwroc_lmd_sticky_store.o > ? ?CC? ? bld_ppc-linux_4.2.2/ebye/lwroc_ebye_util.o > ? ?CC? ? bld_ppc-linux_4.2.2/hld/lwroc_hld_util.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_filter_loop.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_filter_ts.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_file_writer.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_crc32.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_file_functions.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_fd_writer.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_tsm_writer.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_timeout_util.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_slow_async_loop.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_net_io.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_net_client_base.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_net_portmap.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_udp_awaken_hints.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_net_incoming.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_net_message.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_net_mon.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_net_control.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_net_in_rev_link.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_cpu_affinity.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_delayed_eb.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_net_trans.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_net_trans_loop.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_net_outgoing.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_net_reverse_link.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_net_trigbus.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_triva.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_triva_sim.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_map_pexor.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_triva_state.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_net_conn_monitor.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_net_ntp.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_leap_seconds.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_calc_mean_sigma.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_accum_sort.o > ? ?AR? ? lib_ppc-linux_4.2.2/liblwroc.a > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_main.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_filter.o > ? ?AR? ? lib_ppc-linux_4.2.2/liblwroc_main.a > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_readout.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_triva_readout.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_triva_control.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_triva_access.o > ? ?AR? ? lib_ppc-linux_4.2.2/liblwroc_readout.a > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_filter_none.o > ? ?AR? ? lib_ppc-linux_4.2.2/liblwroc_nofilter.a > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_net_io_util.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_hostname_util.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_net_badrequest.o > ? ?AR? ? lib_ppc-linux_4.2.2/liblwroc_netutil.a > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_parse_util.o > ? ?AR? ? lib_ppc-linux_4.2.2/liblwroc_parseutil.a > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_mbscompat.o > ? ?AR? ? lib_ppc-linux_4.2.2/liblwroc_mbscompat.a > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_hwmap_error.o > ? ?AR? ? lib_ppc-linux_4.2.2/liblwroc_hwmap_error.a > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_merge.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_merge_in.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_merge_sort.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_merge_analyse.o > ? ?AR? ? lib_ppc-linux_4.2.2/liblwroc_merge.a > ?CONFIG? lib_ppc-linux_4.2.2/lwroc_libs.config > ? ?CC? ? bld_ppc-linux_4.2.2/test_crc32.o > ? LINK? ?bin_ppc-linux_4.2.2/test_crc32 > ? CHECK? bin_ppc-linux_4.2.2/test_crc32.test > ? TOUCH? lib_ppc-linux_4.2.2/lwroc_libs.stamp > ? ?CC? ? bld_ppc-linux_4.2.2/test_track_timestamp.o > ? LINK? ?bin_ppc-linux_4.2.2/test_track_timestamp > ? ?CC? ? bld_ppc-linux_4.2.2/test_format_prefix.o > ? LINK? ?bin_ppc-linux_4.2.2/test_format_prefix > make[1]: warning:? Clock skew detected.? Your build may be incomplete. > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwroc' > make -C lwrocmon > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/mkdir_p.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/warn_flags.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/cpu_platform.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/hw_access.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/perl_path.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/md5sum_path.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/has_ncurses.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/has_tsmapi.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/bison_noyacc_flag.mk > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwrocmon' > make[1]: Warning: File `gen_ppc-linux_4.2.2/acc_auto_def/bison_noyacc_flag.mk' has modification time 36 s in the future > ? DEPS? ?bld_ppc-linux_4.2.2/lwrocdt.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwrocctrl.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroclog.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_mon_status.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_mon_tree.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_mon_detail.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_mon_rate.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_mon_basic.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_mon_msg.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_mon_udp_hint.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_mon_conn.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_mon_buffer.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwrocmon.d > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwrocmon' > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwrocmon' > make[1]: Warning: File `bld_ppc-linux_4.2.2/lwrocdt.d' has modification time 33 s in the future > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/myinttypes.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/mystdint.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/variadic_macros.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/time_include.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/select_include.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/mfence.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/myprizd.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/has_curses.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/mystrndup.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/mynan.h > ? DEPS? ?bld_ppc-linux_4.2.2/lwrocdt.d > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/netinet_in_include.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/socket_include.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/socket_types.h > ? DEPS? ?bld_ppc-linux_4.2.2/lwrocctrl.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroclog.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_mon_status.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_mon_tree.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_mon_detail.d > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/has_tiocgwinsz.h > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_mon_rate.d > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/fall_through.h > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_mon_basic.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_mon_msg.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_mon_udp_hint.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_mon_conn.d > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/has_msg_nosignal.h > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_mon_buffer.d > ? DEPS? ?bld_ppc-linux_4.2.2/lwrocmon.d > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwrocmon' > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwrocmon' > make[1]: Warning: File `bld_ppc-linux_4.2.2/lwrocdt.d' has modification time 32 s in the future > ? DEPS? ?bld_ppc-linux_4.2.2/lwroc_mon_tree.d > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwrocmon' > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwrocmon' > make[1]: Warning: File `bld_ppc-linux_4.2.2/lwrocdt.d' has modification time 31 s in the future > ? ?CC? ? bld_ppc-linux_4.2.2/lwrocmon.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_mon_buffer.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_mon_conn.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_mon_udp_hint.o > ? ?CC? ? bld_ppc-linux_4.2.2/lwroc_mon_msg.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 > ? ?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 > ? ?CC? ? bld_ppc-linux_4.2.2/lwrocdt.o > ? LINK? ?bin_ppc-linux_4.2.2/lwrocdt > ? LINK? ?bin_ppc-linux_4.2.2/lwrocmerge > make[1]: warning:? Clock skew detected.? Your build may be incomplete. > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/lwrocmon' > make -C nulldaq > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/nulldaq' > ? DEPS? ?bld_ppc-linux_4.2.2/nulldaq.d > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/nulldaq' > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/nulldaq' > make[1]: Warning: File `bld_ppc-linux_4.2.2/nulldaq.d' has modification time 36 s in the future > ? ?CC? ? bld_ppc-linux_4.2.2/nulldaq.o > ? LINK? ?bin_ppc-linux_4.2.2/nulldaq > make[1]: warning:? Clock skew detected.? Your build may be incomplete. > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/nulldaq' > make -C testdaq > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/testdaq' > ? DEPS? ?bld_ppc-linux_4.2.2/testdaq.d > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/testdaq' > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/testdaq' > make[1]: Warning: File `bld_ppc-linux_4.2.2/testdaq.d' has modification time 36 s in the future > ? ?CC? ? bld_ppc-linux_4.2.2/testdaq.o > ? LINK? ?bin_ppc-linux_4.2.2/testdaq > make[1]: warning:? Clock skew detected.? Your build may be incomplete. > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/testdaq' > make -C f_user_daq > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/mkdir_p.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/warn_flags.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/cpu_platform.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/hw_access.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/perl_path.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/md5sum_path.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/has_ncurses.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/has_tsmapi.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/bison_noyacc_flag.mk > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/f_user_daq' > make[1]: Warning: File `gen_ppc-linux_4.2.2/acc_auto_def/bison_noyacc_flag.mk' has modification time 36 s in the future > ? DEPS? ?bld_ppc-linux_4.2.2/./f_user_daq.d > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/f_user_daq' > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/f_user_daq' > make[1]: Warning: File `bld_ppc-linux_4.2.2/./f_user_daq.d' has modification time 36 s in the future > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/mystdint.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/variadic_macros.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/time_include.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/select_include.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/mfence.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/cpu_affinity.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/myinttypes.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/byteorder_include.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/myprizd.h > ? DEPS? ?bld_ppc-linux_4.2.2/./f_user_daq.d > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/f_user_daq' > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/f_user_daq' > make[1]: Warning: File `bld_ppc-linux_4.2.2/./f_user_daq.d' has modification time 35 s in the future > ? ?CC? ? bld_ppc-linux_4.2.2/./f_user_daq.o > make[1]: warning:? Clock skew detected.? Your build may be incomplete. > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/f_user_daq' > make -C trigbussim > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/mkdir_p.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/warn_flags.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/cpu_platform.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/hw_access.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/perl_path.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/md5sum_path.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/has_ncurses.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/has_tsmapi.mk > COPYRULE gen_ppc-linux_4.2.2/acc_auto_def/bison_noyacc_flag.mk > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/trigbussim' > make[1]: Warning: File `gen_ppc-linux_4.2.2/acc_auto_def/bison_noyacc_flag.mk' has modification time 36 s in the future > ? DEPS? ?bld_ppc-linux_4.2.2/message_internal.d > ? DEPS? ?bld_ppc-linux_4.2.2/port_help.d > ? DEPS? ?bld_ppc-linux_4.2.2/test_tbs.d > ? DEPS? ?bld_ppc-linux_4.2.2/trigbussim.d > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/trigbussim' > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/trigbussim' > make[1]: Warning: File `bld_ppc-linux_4.2.2/message_internal.d' has modification time 35 s in the future > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/mystdint.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/variadic_macros.h > ? DEPS? ?bld_ppc-linux_4.2.2/message_internal.d > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/myinttypes.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/netinet_in_include.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/socket_include.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/socket_types.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/time_include.h > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/select_include.h > ? DEPS? ?bld_ppc-linux_4.2.2/port_help.d > ?ACCDEF? gen_ppc-linux_4.2.2/acc_auto_def/myprizd.h > ? DEPS? ?bld_ppc-linux_4.2.2/test_tbs.d > ? DEPS? ?bld_ppc-linux_4.2.2/trigbussim.d > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/trigbussim' > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/trigbussim' > make[1]: Warning: File `bld_ppc-linux_4.2.2/message_internal.d' has modification time 31 s in the future > ? ?CC? ? bld_ppc-linux_4.2.2/trigbussim.o > ? ?CC? ? bld_ppc-linux_4.2.2/message_internal.o > ? LINK? ?bin_ppc-linux_4.2.2/trigbussim > ? ?CC? ? bld_ppc-linux_4.2.2/test_tbs.o > ? LINK? ?bin_ppc-linux_4.2.2/test_tbs > ? ?CC? ? bld_ppc-linux_4.2.2/port_help.o > ? LINK? ?bin_ppc-linux_4.2.2/port_help > make[1]: warning:? Clock skew detected.? Your build may be incomplete. > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/trigbussim' > make -C f_user_example -f makefile.drasi > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/f_user_example' > make[1]: Warning: File `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../f_user_daq/bld_ppc-linux_4.2.2/f_user_daq.o' has modification time 25 s in the future > ? ?CC? ? ppc-linux_4.2.2-f_user_example.o > ? LINK? ?ppc-linux_4.2.2-f_user_example > ? ?CC? ? ppc-linux_4.2.2-f_user_regress.o > ? LINK? ?ppc-linux_4.2.2-f_user_regress > ? ?CC? ? ppc-linux_4.2.2-f_user_speed.o > ? LINK? ?ppc-linux_4.2.2-f_user_speed > ? ?CC? ? ppc-linux_4.2.2-filter_example.o > ? LINK? ?ppc-linux_4.2.2-filter_example > ? ?CC? ? ppc-linux_4.2.2-filter_trbts2lmdwr.o > ? LINK? ?ppc-linux_4.2.2-filter_trbts2lmdwr > ? ?CC? ? ppc-linux_4.2.2-filter_lmd2ebye.o > ? LINK? ?ppc-linux_4.2.2-filter_lmd2ebye > make[1]: warning:? Clock skew detected.? Your build may be incomplete. > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/drasi/f_user_example' > > Within this we have the following line: > > > ? ?AR? ? lib_ppc-linux_4.2.2/liblwroc_mbscompat.a > > > I used the most recent DRASI package (downloaded from GITLAB this morning.) > > > > > Best greetings > > G?nter > > > ______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > Von: Hans Toshihide T?rnqvist > Gesendet: Donnerstag, 11. April 2024 16:13:41 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr. > Betreff: Re: [subexp-daq] problem with R3BFUSER compilation: llwroc_mbscompat not found ? > Dear G?nter, > > Looks like the liblwroc_mbscompat.a library provided by drasi is missing. > > Is that drasi (/mbsusr/mbsdaq/daq/2024_polarimeter/drasi?) up-to-date? > > Did it compile completely? > > Cheers, > Hans > > On 2024-04-11 12:23, Weber, Guenter Dr. wrote: > > Dear friends, > > > > with the most recent versions of all software packages, I got stuck when > > doing "make drasi" on the RIO: > > > > RIO4L-2 mbsdaq > make drasi > > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > > For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. > > 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 -I. > > -Ibuild_cc_ppc-linux_4.2.2_debug -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/daq/2024_polarimeter/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/daq/2024_polarimeter/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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing > -Wextra -ggdb > > 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/ -I. > > -Ibuild_cc_ppc-linux_4.2.2_debug -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/daq/2024_polarimeter/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/daq/2024_polarimeter/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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing > -Wextra -ggdb -L../nurdlib/build_cc_ppc-linux_4.2.2_debug /mbs/driv/white_rabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -L/mbsusr/mbsdaq/daq/2024_polarimeter/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/daq/2024_polarimeter/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -llwroc_hwmap_error -lnurdlib > > /usr/bin/ld: cannot find -llwroc_mbscompat > > collect2: ld returned 1 exit status > > 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 -I. > > -Ibuild_cc_ppc-linux_4.2.2_debug -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/daq/2024_polarimeter/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/daq/2024_polarimeter/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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing > -Wextra -ggdb > > 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/ -I. > > -Ibuild_cc_ppc-linux_4.2.2_debug -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/daq/2024_polarimeter/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/daq/2024_polarimeter/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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing > -Wextra -ggdb -L../nurdlib/build_cc_ppc-linux_4.2.2_debug /mbs/driv/white_rabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -L/mbsusr/mbsdaq/daq/2024_polarimeter/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/daq/2024_polarimeter/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -llwroc_hwmap_error -lnurdlib > > /usr/bin/ld: cannot find -llwroc_mbscompat > > collect2: ld returned 1 exit status > > 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 -I. > > -Ibuild_cc_ppc-linux_4.2.2_debug -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/daq/2024_polarimeter/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/daq/2024_polarimeter/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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing > -Wextra -ggdb > > 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/ -I. > > -Ibuild_cc_ppc-linux_4.2.2_debug -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/daq/2024_polarimeter/drasi/bin/../lwroc/gen_ppc-linux_4.2.2 -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc -I /mbsusr/mbsdaq/daq/2024_polarimeter/drasi/bin/../lwroc/../mbscompat -I /mbsusr/mbsdaq/daq/2024_polarimeter/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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing > -Wextra -ggdb -L../nurdlib/build_cc_ppc-linux_4.2.2_debug /mbs/driv/white_rabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread -L/mbsusr/mbsdaq/daq/2024_polarimeter/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/daq/2024_polarimeter/drasi/bin/../lwroc/../hwmap/lib_ppc-linux_4.2.2 -lhwmap -llwroc_hwmap_error -lnurdlib > > /usr/bin/ld: cannot find -llwroc_mbscompat > > collect2: ld returned 1 exit status > > Failed. > > make: *** [build_cc_ppc-linux_4.2.2_debug/nconf.args] Error 1 > > > > I did not remember that I saw this problem previously. Is there maybe > > any special environment variable that needs to set before compiling > > (like for example TRLOII_PATH in case of NURDLIB compilation)? > > > > > > Thank you very much! > > > > > > > > Best greetings > > G?nter > > > > > > > > > > > > > > > > > > From g.weber at hi-jena.gsi.de Fri Apr 12 11:03:18 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Fri, 12 Apr 2024 09:03:18 +0000 Subject: [subexp-daq] Possible problem with VULOM4 (instead of 4B) Message-ID: Dear friends, when starting the DAQ with the VULOM4 module, I get the following error from DRASI: 10: crate/crate.c:350: crate_create { 10: crate/crate.c:678: crate_create(POLARIMETER) } 10: crate/crate.c:986: crate_init(POLARIMETER) { 10: crate/crate.c:1010: .Slow-init module[0]=GSI_VULOM. 5: module/gsi_vulom/gsi_vulom.c:14: .gsi_vulom_init_slow not implemented. 5: module/gsi_vulom/gsi_vulom.c:14: .Calling abort()... Attached, I send you the complete output as well as the vulom.trlo file (which probably contains some old syntax). Maybe you have an idea what went wrong here? Thank you very much! Best greetings G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- SECTION(main) { /* pulse generator on LEMO_OUT(1) */ // period(1) = 1000 us; // LEMO_OUT(1) = PULSER(1); // TRIG_LMU_AUX(1) = PULSER(1); /* Trigger input setup. */ // Enable this for detector input on ECL_IN(1) // all_or_mask(1) = LEMO_IN(1) | ECL_IN(1) | ECL_IN(2) | ECL_IN(3) | ECL_IN(4) | ECL_IN(5); all_or_mask(1) = LEMO_IN(1); TRIG_LMU_AUX(1) = ALL_OR(1); TRIG_LMU_OUT(1) = TRIG_LMU_AUX(1); // Enable this for pulser trigger (setup / debug) // TRIG_LMU_OUT(1) = TRIG_LMU_AUX(1); /* Default coincidence windows of 50 ns. */ accept_window_len = 50 ns; /* Default trigger stretch of 50 ns. */ trig_stretch(1) = 50ns; /* tpat -> trig mapping. */ tpat_trig(1) = 1; /* Enable all tpats. */ tpat_enable = mask 0xffff; /* Gate generator for ADC */ GATE_DELAY(1) = MASTER_START; stretch(1) = 13 us; delay(1) = 10 us; LEMO_OUT(2) = GATE_DELAY(1); /* Nice lights! */ FRONT_LED(1) = TRIMI_TDT; FRONT_LED(2) = MASTER_START; /* deadtime from TRIMI */ // disabled to run with TRIVA instead // DEADTIME_IN(1) = TRIMI_TDT; /* deadtime from TRIVA */ DEADTIME_IN(1) = ECL_IO_IN(4); fast_busy_len = 100 ns; 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); /* master start output */ sum_out_stretch = 50 ns; fast_busy_len = 1000 ns; LEMO_OUT(1) = MASTER_START; } -------------- next part -------------- RIO4L-2 mbsdaq > ./start.sh hwmap_mapvme.c:419: LOG: Virtual address for TRLO II @ VME 0x03000000 is 0x3005e000. LOG: TRLO: MD5SUM: 0x6e4ba1a9 (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) Clear module setup. Loading config file 'vulom.trlo'. vulom.trlo:12: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:13: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:14: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:34: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:37: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:41: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:42: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:49: 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:54: WARNING: Use of deprecated signal assignment '=', use '<='. vulom.trlo:59: WARNING: Use of deprecated signal assignment '=', use '<='. Executing 'main'. CPUS: 1 delay: 1 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: 7000). Message not logged - thread has no error buffer yet... CPUS: 1 delay: 1 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: 7000). Message not logged - thread has no error buffer yet... HOST: RIO4L-2 Token: 21301afe (21301afe:21301afe) [/mbsusr/mbsdaq/.drasi_tokens/blub] 10: lwroc_hostname_util.c:460: Own address: 192.168.1.72/255.255.255.0 (eth1). cfg: 'master, at 0x02,fctime=10,ctime=300' => 33554432 10: lwroc_data_pipe.c:146: Data buffer READOUT_PIPE, fmt LMD, size 209715200 = 0x0c800000, 3 consumers. 10: lwroc_triva_readout.c:66: Silence TRIVA (HALT) 10: lwroc_net_io.c:168: Started server on port 56583 (data port 59293). 10: lwroc_net_trans.c:1808: [stream:8003] Started stream server on port 8003, data 45908. client union size: 244 240 188 508 640 204 204 => 640 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: /tmp/drasi.u1001/drasi.hints.u1001.RIO4L-2:56583 10: lwroc_main.c:709: Log message rate limit not in effect. 10: lwroc_readout.c:112: call readout_init... 10: lwroc_thread_util.c:118: This is the triva control thread! 10: lwroc_thread_util.c:118: This is the net io thread! 10: lwroc_thread_util.c:118: This is the slow_async thread! 10: lwroc_thread_util.c:118: This is the data server thread! 8: lwroc_message_wait.c:86: Waited 1 seconds for msg client. 8: lwroc_triva_state.c:414: Waited 1 seconds for initial slave and EB connection(s): 8: lwroc_triva_state.c:422: [EB lyserv:7000] (state 0) 10: lwroc_message_internal.c:485: Message client connected! 10: lwroc_net_trans.c:1153: [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(30000)+1*rd(694)+3*wr(634)+fctime(1000)=33596 ns (29.765 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 29.8 kHz) 10: lwroc_triva_readout.c:376: Trigger 14 seen. 10: printm:0: NURDLIB_DEF_PATH not set, let's see... 10: printm:0: Gonna try NURDLIB_DEF_PATH=/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default. 2024-04-12,08:52:02:INFO: Setting default config path '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default'. [config/config.c:191] 10: config/parser.c:283: Opened '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default/global.cfg' { 10: config/parser.c:295: Closed '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/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:7000] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 10: config/parser.c:283: Opened './main.cfg' { 10: config/config.c:1381: .Global log level=verbose. 10: config/parser.c:283: .Opened '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default/crate.cfg' { 10: config/parser.c:295: .Closed '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default/crate.cfg' } 10: config/parser.c:283: .Opened '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default/tags.cfg' { 10: config/parser.c:295: .Closed '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default/tags.cfg' } 10: config/parser.c:283: .Opened '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default/gsi_vulom.cfg' { 10: config/parser.c:295: .Closed '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default/gsi_vulom.cfg' } 10: config/parser.c:283: .Opened '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default/module_log_level.cfg' { 10: config/parser.c:295: .Closed '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default/module_log_level.cfg' } 10: config/parser.c:283: .Opened '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default/caen_v785.cfg' { 10: config/parser.c:295: .Closed '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default/caen_v785.cfg' } 10: config/parser.c:283: .Opened '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default/module_log_level.cfg' { 10: config/parser.c:295: .Closed '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default/module_log_level.cfg' } 10: config/parser.c:283: .Opened '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default/caen_v785.cfg' { 10: config/parser.c:295: .Closed '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default/caen_v785.cfg' } 10: config/parser.c:283: .Opened '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default/module_log_level.cfg' { 10: config/parser.c:295: .Closed '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default/module_log_level.cfg' } 10: config/parser.c:283: .Opened '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default/caen_v1190.cfg' { 10: config/parser.c:295: .Closed '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default/caen_v1190.cfg' } 10: config/parser.c:283: .Opened '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default/module_log_level.cfg' { 10: config/parser.c:295: .Closed '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default/module_log_level.cfg' } 10: config/parser.c:283: .Opened '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default/caen_v560.cfg' { 10: config/parser.c:295: .Closed '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default/caen_v560.cfg' } 10: config/parser.c:283: .Opened '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default/module_log_level.cfg' { 10: config/parser.c:295: .Closed '/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/nurdlib/cfg/default/module_log_level.cfg' } 10: config/parser.c:295: Closed './main.cfg' } 10: crate/crate.c:350: crate_create { 10: crate/crate.c:678: crate_create(POLARIMETER) } 10: crate/crate.c:986: crate_init(POLARIMETER) { 10: crate/crate.c:1010: .Slow-init module[0]=GSI_VULOM. 5: module/gsi_vulom/gsi_vulom.c:14: .gsi_vulom_init_slow not implemented. 5: module/gsi_vulom/gsi_vulom.c:14: .Calling abort()... ./start.sh: line 12: 5356 Aborted ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi --triva=master, at 0x02,fctime=10,ctime=300 --log-no-rate-limit --server=stream:8003 --server=drasi,dest=lyserv:7000 --buf=size=200Mi --max-ev-size=0x100000 --eb=lyserv:7000 --subev=crate=0,type=88,subtype=8800,control=0,procid=12 "$@" From hans.tornqvist at chalmers.se Fri Apr 12 11:13:17 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Fri, 12 Apr 2024 11:13:17 +0200 Subject: [subexp-daq] Possible problem with VULOM4 (instead of 4B) In-Reply-To: References: Message-ID: Dear G?nter, Looks like trloii was not compiled into nurdlib, please have a look at the following file: nurdlib/build_*/nconf/include/nurdlib/trloii.h.log (Better error output now in the todo...) Cheers, Hans On 2024-04-12 11:03, Weber, Guenter Dr. wrote: > Dear friends, > > > when starting the DAQ with the VULOM4 module, I get the following error > from DRASI: > > > 10: crate/crate.c:350: crate_create { > 10: crate/crate.c:678: crate_create(POLARIMETER) } > 10: crate/crate.c:986: crate_init(POLARIMETER) { > 10: crate/crate.c:1010: .Slow-init module[0]=GSI_VULOM. > 5: module/gsi_vulom/gsi_vulom.c:14: .gsi_vulom_init_slow not implemented. > 5: module/gsi_vulom/gsi_vulom.c:14: .Calling abort()... > > Attached, I send you the complete output as well as the vulom.trlo file > (which probably contains some old syntax). > > > Maybe you have an idea what went wrong here? > > > > > Thank you very much! > > > > > Best greetings > > G?nter > > > > > > From g.weber at hi-jena.gsi.de Fri Apr 12 15:09:12 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Fri, 12 Apr 2024 13:09:12 +0000 Subject: [subexp-daq] Possible problem with VULOM4 (instead of 4B) In-Reply-To: References: , , Message-ID: <4751293780ac43a881abfb75e46bdc3c@hi-jena.gsi.de> P.S. I killed everything and started from scratch. Now the log file looks like this. === TRIDI:NO === run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mTRIDI=1 -Ibuild_cc_ppc-linux_4.2.2_debug/replacements -Ibuild_cc_ppc-linux_4.2.2_debug -Iinclude -I. -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -DTRLOII_ARCH_SUFFIX=ppc-linux_4.2.2 -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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ansi -pedantic-errors -Wall -Wcast-qual -Werror -Wformat=2 -Wmissing-prototypes -Wshadow -Wstrict-prototypes -ggdb Success! === VULOM4:YES === run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mVULOM4=1 -Ibuild_cc_ppc-linux_4.2.2_debug/replacements -Ibuild_cc_ppc-linux_4.2.2_debug -Iinclude -I. -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -DTRLOII_ARCH_SUFFIX=ppc-linux_4.2.2 -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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/dtc_arch -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_6e4ba1a9_trlo -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_6e4ba1a9_trlo/gen_ppc-linux_4.2.2 -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ansi -pedantic-errors -Wall -Wcast-qual -Werror -Wformat=2 -Wmissing-prototypes -Wshadow -Wstrict-prototypes -ggdb run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.bin build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.o -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -Ibuild_cc_ppc-linux_4.2.2_debug/replacements -Ibuild_cc_ppc-linux_4.2.2_debug -Iinclude -I. -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -DTRLOII_ARCH_SUFFIX=ppc-linux_4.2.2 -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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/dtc_arch -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_6e4ba1a9_trlo -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_6e4ba1a9_trlo/gen_ppc-linux_4.2.2 -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ansi -pedantic-errors -Wall -Wcast-qual -Werror -Wformat=2 -Wmissing-prototypes -Wshadow -Wstrict-prototypes -ggdb -L/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap/lib_ppc-linux_4.2.2 /LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_6e4ba1a9_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a -lhwmap /LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /mbs/driv/white_rabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread Success! === RFX1:YES === run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mRFX1=1 -Ibuild_cc_ppc-linux_4.2.2_debug/replacements -Ibuild_cc_ppc-linux_4.2.2_debug -Iinclude -I. -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -DTRLOII_ARCH_SUFFIX=ppc-linux_4.2.2 -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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_6e4ba1a9_trlo -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_6e4ba1a9_trlo/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/dtc_arch -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_0866c243_rfx1 -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_0866c243_rfx1/gen_ppc-linux_4.2.2 -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ansi -pedantic-errors -Wall -Wcast-qual -Werror -Wformat=2 -Wmissing-prototypes -Wshadow -Wstrict-prototypes -ggdb In file included from build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c:1: ./include/nurdlib/trloii.h:61:37: error: include/rfx1_functions.h: No such file or directory In file included from build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c:1: ./include/nurdlib/trloii.h:109: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'volatile' Failed. === RFX1:NO === run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mRFX1=1 -Ibuild_cc_ppc-linux_4.2.2_debug/replacements -Ibuild_cc_ppc-linux_4.2.2_debug -Iinclude -I. -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -DTRLOII_ARCH_SUFFIX=ppc-linux_4.2.2 -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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/dtc_arch -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_6e4ba1a9_trlo -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_6e4ba1a9_trlo/gen_ppc-linux_4.2.2 -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ansi -pedantic-errors -Wall -Wcast-qual -Werror -Wformat=2 -Wmissing-prototypes -Wshadow -Wstrict-prototypes -ggdb Success! Unfortunately, I do not know what I did different this time. Reporting compilation errors when they happen and why they happen would be really very much appreciated ? Best greetings G?nter ________________________________ Von: Weber, Guenter Dr. Gesendet: Freitag, 12. April 2024 11:23:53 An: Hans Toshihide T?rnqvist Betreff: AW: [subexp-daq] Possible problem with VULOM4 (instead of 4B) Dear Hans, indeed, some stuff failed there. In file included from /LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap/hwmap_access.h:28, from /LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap/hwmap_mapvme.h:28, from ./include/nurdlib/trloii.h:80, from build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c:1: /LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap/../dtc_arch/acc_def/mystdint.h:25:36: error: acc_auto_def/mystdint.h: No such file or directory In file included from build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c:1: ./include/nurdlib/trloii.h:113: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'volatile' cc1: warnings being treated as errors build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c: In function 'main': build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c:5: warning: implicit declaration of function 'tridi_setup_map_hardware' Failed. === TRIDI:NO === run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mTRIDI=1 -Ibuild_cc_ppc-linux_4.2.2_debug/replacements -Ibuild_cc_ppc-linux_4.2.2_debug -Iinclude -I. -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -DTRLOII_ARCH_SUFFIX=ppc-linux_4.2.2 -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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ansi -pedantic-errors -Wall -Wcast-qual -Werror -Wformat=2 -Wmissing-prototypes -Wshadow -Wstrict-prototypes -ggdb Success! === VULOM4:YES === run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mVULOM4=1 -Ibuild_cc_ppc-linux_4.2.2_debug/replacements -Ibuild_cc_ppc-linux_4.2.2_debug -Iinclude -I. -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -DTRLOII_ARCH_SUFFIX=ppc-linux_4.2.2 -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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/dtc_arch -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_1409285e 68f8955e 6e4ba1a9 a73c5093 af33ed35_trlo -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_1409285e 68f8955e 6e4ba1a9 a73c5093 af33ed35_trlo/gen_ppc-linux_4.2.2 -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ansi -pedantic-errors -Wall -Wcast-qual -Werror -Wformat=2 -Wmissing-prototypes -Wshadow -Wstrict-prototypes -ggdb In file included from build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c:1: ./include/nurdlib/trloii.h:42:37: error: include/trlo_functions.h: No such file or directory In file included from /LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap/hwmap_access.h:28, from /LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap/hwmap_mapvme.h:28, from ./include/nurdlib/trloii.h:80, from build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c:1: /LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap/../dtc_arch/acc_def/mystdint.h:25:36: error: acc_auto_def/mystdint.h: No such file or directory In file included from build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c:1: ./include/nurdlib/trloii.h:117: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'volatile' cc1: warnings being treated as errors build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c: In function 'main': build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c:5: warning: implicit declaration of function 'trlo_setup_map_hardware' Failed. === VULOM4:NO === run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mVULOM4=1 -Ibuild_cc_ppc-linux_4.2.2_debug/replacements -Ibuild_cc_ppc-linux_4.2.2_debug -Iinclude -I. -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -DTRLOII_ARCH_SUFFIX=ppc-linux_4.2.2 -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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ansi -pedantic-errors -Wall -Wcast-qual -Werror -Wformat=2 -Wmissing-prototypes -Wshadow -Wstrict-prototypes -ggdb Success! === RFX1:YES === run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mRFX1=1 -Ibuild_cc_ppc-linux_4.2.2_debug/replacements -Ibuild_cc_ppc-linux_4.2.2_debug -Iinclude -I. -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -DTRLOII_ARCH_SUFFIX=ppc-linux_4.2.2 -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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/dtc_arch -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_0866c243_rfx1 -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_0866c243_rfx1/gen_ppc-linux_4.2.2 -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ansi -pedantic-errors -Wall -Wcast-qual -Werror -Wformat=2 -Wmissing-prototypes -Wshadow -Wstrict-prototypes -ggdb In file included from build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c:1: ./include/nurdlib/trloii.h:61:37: error: include/rfx1_functions.h: No such file or directory In file included from build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c:1: ./include/nurdlib/trloii.h:109: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'volatile' Failed. === RFX1:NO === run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mRFX1=1 -Ibuild_cc_ppc-linux_4.2.2_debug/replacements -Ibuild_cc_ppc-linux_4.2.2_debug -Iinclude -I. -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -DTRLOII_ARCH_SUFFIX=ppc-linux_4.2.2 -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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ansi -pedantic-errors -Wall -Wcast-qual -Werror -Wformat=2 -Wmissing-prototypes -Wshadow -Wstrict-prototypes -ggdb Success! Any idea, what might be the problem? To compile TRLOII, I did the following: git clone git at gitlab.com:chalmers-subexp/trloii.git cd $MYDAQ/trloii wget http://fy.chalmers.se/~f96hajo/trloii/trloii_firmwares_f13d071c.tar.gz tar -zxvf trloii_firmwares_f13d071c.tar.gz ###################################################################### # 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_6e4ba1a9_trlo_build # choose the vulom4_trlo ... Thank you so much! Best greetings G?nter ________________________________ Von: Hans Toshihide T?rnqvist Gesendet: Freitag, 12. April 2024 11:13:17 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr. Betreff: Re: [subexp-daq] Possible problem with VULOM4 (instead of 4B) Dear G?nter, Looks like trloii was not compiled into nurdlib, please have a look at the following file: nurdlib/build_*/nconf/include/nurdlib/trloii.h.log (Better error output now in the todo...) Cheers, Hans On 2024-04-12 11:03, Weber, Guenter Dr. wrote: > Dear friends, > > > when starting the DAQ with the VULOM4 module, I get the following error > from DRASI: > > > 10: crate/crate.c:350: crate_create { > 10: crate/crate.c:678: crate_create(POLARIMETER) } > 10: crate/crate.c:986: crate_init(POLARIMETER) { > 10: crate/crate.c:1010: .Slow-init module[0]=GSI_VULOM. > 5: module/gsi_vulom/gsi_vulom.c:14: .gsi_vulom_init_slow not implemented. > 5: module/gsi_vulom/gsi_vulom.c:14: .Calling abort()... > > Attached, I send you the complete output as well as the vulom.trlo file > (which probably contains some old syntax). > > > Maybe you have an idea what went wrong here? > > > > > Thank you very much! > > > > > Best greetings > > G?nter > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.weber at hi-jena.gsi.de Fri Apr 12 15:38:39 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Fri, 12 Apr 2024 13:38:39 +0000 Subject: [subexp-daq] Possible problem with VULOM4 (instead of 4B) In-Reply-To: <4751293780ac43a881abfb75e46bdc3c@hi-jena.gsi.de> References: , , , <4751293780ac43a881abfb75e46bdc3c@hi-jena.gsi.de> Message-ID: P.P.S. Now DRASI compilation fails: RIO4L-2 mbsdaq > make drasi NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. UDP:ARPA_INET_H build_cc_ppc-linux_4.2.2_debug/nconf.args done. CC build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o f_user.c: In function 'f_user_init': f_user.c:777: error: 'TRIDI_PULSE_MULTI_LATCH_CLEAR_ALL' undeclared (first use in this function) f_user.c:777: error: (Each undeclared identifier is reported only once f_user.c:777: error: for each function it appears in.) f_user.c: In function 'f_user_readout': f_user.c:1141: error: 'TRIDI_PULSE_TRIG_SCALER_LATCH' undeclared (first use in this function) f_user.c:1142: error: 'TRIDI_PULSE_MUX_SRC_SCALER_LATCH' undeclared (first use in this function) make: *** [build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o] Error 1 As I did not encounter these problems with the DAQ systems that have VULOM4B instead of VULOM4, I assume this might be related to the VULOM version. But this is just my wild guess. I am sorry :-( Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von Weber, Guenter Dr. Gesendet: Freitag, 12. April 2024 15:09:12 An: Hans Toshihide T?rnqvist; Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] Possible problem with VULOM4 (instead of 4B) P.S. I killed everything and started from scratch. Now the log file looks like this. === TRIDI:NO === run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mTRIDI=1 -Ibuild_cc_ppc-linux_4.2.2_debug/replacements -Ibuild_cc_ppc-linux_4.2.2_debug -Iinclude -I. -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -DTRLOII_ARCH_SUFFIX=ppc-linux_4.2.2 -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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ansi -pedantic-errors -Wall -Wcast-qual -Werror -Wformat=2 -Wmissing-prototypes -Wshadow -Wstrict-prototypes -ggdb Success! === VULOM4:YES === run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mVULOM4=1 -Ibuild_cc_ppc-linux_4.2.2_debug/replacements -Ibuild_cc_ppc-linux_4.2.2_debug -Iinclude -I. -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -DTRLOII_ARCH_SUFFIX=ppc-linux_4.2.2 -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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/dtc_arch -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_6e4ba1a9_trlo -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_6e4ba1a9_trlo/gen_ppc-linux_4.2.2 -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ansi -pedantic-errors -Wall -Wcast-qual -Werror -Wformat=2 -Wmissing-prototypes -Wshadow -Wstrict-prototypes -ggdb run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.bin build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.o -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -Ibuild_cc_ppc-linux_4.2.2_debug/replacements -Ibuild_cc_ppc-linux_4.2.2_debug -Iinclude -I. -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -DTRLOII_ARCH_SUFFIX=ppc-linux_4.2.2 -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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/dtc_arch -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_6e4ba1a9_trlo -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_6e4ba1a9_trlo/gen_ppc-linux_4.2.2 -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ansi -pedantic-errors -Wall -Wcast-qual -Werror -Wformat=2 -Wmissing-prototypes -Wshadow -Wstrict-prototypes -ggdb -L/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap/lib_ppc-linux_4.2.2 /LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_6e4ba1a9_trlo/lib_ppc-linux_4.2.2/trlo_ctrllib.a -lhwmap /LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/common/lib_ppc-linux_4.2.2/trcomlib.a /mbs/driv/white_rabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/lib/libetherbone.a -lcesXpcLib -lcesDma -lm -lrt -pthread Success! === RFX1:YES === run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mRFX1=1 -Ibuild_cc_ppc-linux_4.2.2_debug/replacements -Ibuild_cc_ppc-linux_4.2.2_debug -Iinclude -I. -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -DTRLOII_ARCH_SUFFIX=ppc-linux_4.2.2 -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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_6e4ba1a9_trlo -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_6e4ba1a9_trlo/gen_ppc-linux_4.2.2 -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/dtc_arch -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_0866c243_rfx1 -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_0866c243_rfx1/gen_ppc-linux_4.2.2 -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ansi -pedantic-errors -Wall -Wcast-qual -Werror -Wformat=2 -Wmissing-prototypes -Wshadow -Wstrict-prototypes -ggdb In file included from build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c:1: ./include/nurdlib/trloii.h:61:37: error: include/rfx1_functions.h: No such file or directory In file included from build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c:1: ./include/nurdlib/trloii.h:109: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'volatile' Failed. === RFX1:NO === run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mRFX1=1 -Ibuild_cc_ppc-linux_4.2.2_debug/replacements -Ibuild_cc_ppc-linux_4.2.2_debug -Iinclude -I. -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -DTRLOII_ARCH_SUFFIX=ppc-linux_4.2.2 -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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/dtc_arch -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_6e4ba1a9_trlo -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_6e4ba1a9_trlo/gen_ppc-linux_4.2.2 -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ansi -pedantic-errors -Wall -Wcast-qual -Werror -Wformat=2 -Wmissing-prototypes -Wshadow -Wstrict-prototypes -ggdb Success! Unfortunately, I do not know what I did different this time. Reporting compilation errors when they happen and why they happen would be really very much appreciated ? Best greetings G?nter ________________________________ Von: Weber, Guenter Dr. Gesendet: Freitag, 12. April 2024 11:23:53 An: Hans Toshihide T?rnqvist Betreff: AW: [subexp-daq] Possible problem with VULOM4 (instead of 4B) Dear Hans, indeed, some stuff failed there. In file included from /LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap/hwmap_access.h:28, from /LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap/hwmap_mapvme.h:28, from ./include/nurdlib/trloii.h:80, from build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c:1: /LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap/../dtc_arch/acc_def/mystdint.h:25:36: error: acc_auto_def/mystdint.h: No such file or directory In file included from build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c:1: ./include/nurdlib/trloii.h:113: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'volatile' cc1: warnings being treated as errors build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c: In function 'main': build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c:5: warning: implicit declaration of function 'tridi_setup_map_hardware' Failed. === TRIDI:NO === run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mTRIDI=1 -Ibuild_cc_ppc-linux_4.2.2_debug/replacements -Ibuild_cc_ppc-linux_4.2.2_debug -Iinclude -I. -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -DTRLOII_ARCH_SUFFIX=ppc-linux_4.2.2 -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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ansi -pedantic-errors -Wall -Wcast-qual -Werror -Wformat=2 -Wmissing-prototypes -Wshadow -Wstrict-prototypes -ggdb Success! === VULOM4:YES === run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mVULOM4=1 -Ibuild_cc_ppc-linux_4.2.2_debug/replacements -Ibuild_cc_ppc-linux_4.2.2_debug -Iinclude -I. -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -DTRLOII_ARCH_SUFFIX=ppc-linux_4.2.2 -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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/dtc_arch -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_1409285e 68f8955e 6e4ba1a9 a73c5093 af33ed35_trlo -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_1409285e 68f8955e 6e4ba1a9 a73c5093 af33ed35_trlo/gen_ppc-linux_4.2.2 -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ansi -pedantic-errors -Wall -Wcast-qual -Werror -Wformat=2 -Wmissing-prototypes -Wshadow -Wstrict-prototypes -ggdb In file included from build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c:1: ./include/nurdlib/trloii.h:42:37: error: include/trlo_functions.h: No such file or directory In file included from /LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap/hwmap_access.h:28, from /LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap/hwmap_mapvme.h:28, from ./include/nurdlib/trloii.h:80, from build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c:1: /LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap/../dtc_arch/acc_def/mystdint.h:25:36: error: acc_auto_def/mystdint.h: No such file or directory In file included from build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c:1: ./include/nurdlib/trloii.h:117: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'volatile' cc1: warnings being treated as errors build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c: In function 'main': build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c:5: warning: implicit declaration of function 'trlo_setup_map_hardware' Failed. === VULOM4:NO === run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mVULOM4=1 -Ibuild_cc_ppc-linux_4.2.2_debug/replacements -Ibuild_cc_ppc-linux_4.2.2_debug -Iinclude -I. -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -DTRLOII_ARCH_SUFFIX=ppc-linux_4.2.2 -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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ansi -pedantic-errors -Wall -Wcast-qual -Werror -Wformat=2 -Wmissing-prototypes -Wshadow -Wstrict-prototypes -ggdb Success! === RFX1:YES === run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mRFX1=1 -Ibuild_cc_ppc-linux_4.2.2_debug/replacements -Ibuild_cc_ppc-linux_4.2.2_debug -Iinclude -I. -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -DTRLOII_ARCH_SUFFIX=ppc-linux_4.2.2 -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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/dtc_arch -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/hwmap -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_0866c243_rfx1 -I/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii/trloctrl/fw_0866c243_rfx1/gen_ppc-linux_4.2.2 -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ansi -pedantic-errors -Wall -Wcast-qual -Werror -Wformat=2 -Wmissing-prototypes -Wshadow -Wstrict-prototypes -ggdb In file included from build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c:1: ./include/nurdlib/trloii.h:61:37: error: include/rfx1_functions.h: No such file or directory In file included from build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c:1: ./include/nurdlib/trloii.h:109: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'volatile' Failed. === RFX1:NO === run: cc -o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.o build_cc_ppc-linux_4.2.2_debug/nconfing/nconf/include/nurdlib/trloii.h.c -I. -I build_cc_ppc-linux_4.2.2_debug/nconfing/ -c -DNCONFING_mRFX1=1 -Ibuild_cc_ppc-linux_4.2.2_debug/replacements -Ibuild_cc_ppc-linux_4.2.2_debug -Iinclude -I. -DTRLOII_PATH=/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/trloii -DTRLOII_ARCH_SUFFIX=ppc-linux_4.2.2 -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/enigma/RIO4_Linux_OSV_2_6_33_SuHa/include -maltivec -mregnames -Wstrict-overflow -fstrict-aliasing -Wstrict-aliasing -Wextra -ansi -pedantic-errors -Wall -Wcast-qual -Werror -Wformat=2 -Wmissing-prototypes -Wshadow -Wstrict-prototypes -ggdb Success! Any idea, what might be the problem? To compile TRLOII, I did the following: git clone git at gitlab.com:chalmers-subexp/trloii.git cd $MYDAQ/trloii wget http://fy.chalmers.se/~f96hajo/trloii/trloii_firmwares_f13d071c.tar.gz tar -zxvf trloii_firmwares_f13d071c.tar.gz ###################################################################### # 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_6e4ba1a9_trlo_build # choose the vulom4_trlo ... Thank you so much! Best greetings G?nter ________________________________ Von: Hans Toshihide T?rnqvist Gesendet: Freitag, 12. April 2024 11:13:17 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr. Betreff: Re: [subexp-daq] Possible problem with VULOM4 (instead of 4B) Dear G?nter, Looks like trloii was not compiled into nurdlib, please have a look at the following file: nurdlib/build_*/nconf/include/nurdlib/trloii.h.log (Better error output now in the todo...) Cheers, Hans On 2024-04-12 11:03, Weber, Guenter Dr. wrote: > Dear friends, > > > when starting the DAQ with the VULOM4 module, I get the following error > from DRASI: > > > 10: crate/crate.c:350: crate_create { > 10: crate/crate.c:678: crate_create(POLARIMETER) } > 10: crate/crate.c:986: crate_init(POLARIMETER) { > 10: crate/crate.c:1010: .Slow-init module[0]=GSI_VULOM. > 5: module/gsi_vulom/gsi_vulom.c:14: .gsi_vulom_init_slow not implemented. > 5: module/gsi_vulom/gsi_vulom.c:14: .Calling abort()... > > Attached, I send you the complete output as well as the vulom.trlo file > (which probably contains some old syntax). > > > Maybe you have an idea what went wrong here? > > > > > Thank you very much! > > > > > Best greetings > > G?nter > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.weber at hi-jena.gsi.de Fri Apr 12 16:27:21 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Fri, 12 Apr 2024 14:27:21 +0000 Subject: [subexp-daq] Possible problem in Makefile of NURDLIB Message-ID: Dear friends, on line 108 to 110 of the Makefile there is an automatic setting of the VULOM4_FW parameter: ifeq (,$(VULOM4_FW)) VULOM4_FW:=$(shell ls $(TRLOII_PATH)/trloctrl | grep _trlo | $(SED) 's,fw_,,;s,_trlo.*,,') endif However, if I let this run (i.e. VULOM4_FW is not set by hand) the outcome is as follows: VULOM4_FW = "1409285e 68f8955e 6e4ba1a9 a73c5093 af33ed35" My understandig is that there should only be a single number selected (1409285e for VULOM4B and 6e4ba1a9 for VULOM4). I checked what the "ls" command produces on two systems: RIO4L-2 mbsdaq > ls $TRLOII_PATH/trloctrl Makefile examples/ find_firmwares.pl* firmwaredirs fw_0866c243_rfx1/ fw_1409285e_trlo@ fw_5e8f5ef4_tridi/ fw_68f8955e_trlo_all_in/ fw_6e4ba1a9_trlo/ fw_a1729cda_rfx0/ fw_a73c5093_trlo@ fw_af33ed35_trlo_big/ trloctrl.sh* trlolib/ RIO4-MCAL-1 mbsdaq > ls $TRLOII_PATH/trloctrl Makefile examples/ find_firmwares.pl* firmwaredirs fw_0866c243_rfx1/ fw_1409285e_trlo@ fw_5e8f5ef4_tridi/ fw_68f8955e_trlo_all_in/ fw_6e4ba1a9_trlo/ fw_a1729cda_rfx0/ fw_a73c5093_trlo@ fw_af33ed35_trlo_big/ tridi_log.txt trloctrl.sh* trlolib/ vulom_log.txt RIO4L-2 is the one I am working on right now with the VULOM4, whereas RIO4-MCAL-1 is the system already running with VULOM4B. To me it looks like the code in the Makefile is not working as intended, right? Best greetings G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Fri Apr 12 18:47:36 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Fri, 12 Apr 2024 18:47:36 +0200 Subject: [subexp-daq] DAQ compile from scratch In-Reply-To: References: Message-ID: <2ad2ceab-e492-74a8-439e-f90738a1bc1e@chalmers.se> The attachment was missing. Now also updated ;) Cheers, H?kan On Thu, 11 Jan 2024, H?kan T Johansson wrote: > > (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 -------------- 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 make fw_5e8f5ef4_tridi_build # and for tridi ## cd $MYDAQ/drasi make ## export TRLOII_PATH=$MYDAQ/trloii # for nurdlib to find trloii 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 f96hajo at chalmers.se Sat Apr 13 03:35:09 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Sat, 13 Apr 2024 03:35:09 +0200 Subject: [subexp-daq] DAQ compile from scratch In-Reply-To: <2ad2ceab-e492-74a8-439e-f90738a1bc1e@chalmers.se> References: <2ad2ceab-e492-74a8-439e-f90738a1bc1e@chalmers.se> Message-ID: And another small update to the compile instructions. Cheers, H?kan -------------- 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 make fw_5e8f5ef4_tridi_build # and for tridi ## cd $MYDAQ/drasi make ## export TRLOII_PATH=$MYDAQ/trloii # for nurdlib to find trloii cd $MYDAQ/nurdlib make ## cd $MYDAQ/r3bfuser make fuser_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 f96hajo at chalmers.se Sat Apr 13 03:50:36 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Sat, 13 Apr 2024 03:50:36 +0200 Subject: [subexp-daq] Possible problem in Makefile of NURDLIB In-Reply-To: References: Message-ID: <14162460-f6cb-2735-4d52-6f9b0d69e77f@chalmers.se> Dear G?nter, we think that we have managed to solve the issues at hand (there were multiple): - The missing TRIDI compile: r3bfuser compiles (unconditionally) with both tridi and vulom support if it compiles with one of them. (tridi is a module with similar hardware as the vulom). Now the compile instructions also include to get the tridi things compiles. - The VULOM4_FW now only picks one version, which should be enough. Those named _trlo actually have the same register layout, and find_firmwares.pl point them to the same, so any should do. (Please see the updated instructions in the other mail. Only the compilation sequence had additions, not the download parts. But nurdlib and r3bfuser repositores need to be updated. For this: > Reporting compilation errors when they happen and why they happen would > be really very much appreciated I am not sure what can be done when the issues are within the feature-finding builds. I.e., when those fail, it just means that certains options are not available. Problem is when later programs rely on them. if anything, the later programs should then produce more specific errors telling what they are missing. That might be doable with some #error macros, if they do not have complex makefiles to find features. The other thing might be that 'make showconfig' is too cluttered. There are essentially two kinds of features. The uninteresting ones where the systems need to find one working option out of many. If no option works, things will stop, as it cannot continue. The more interesting selections are the ones where it can get away with no support, i. this case e.g. not compiling tridi support. Perhaps one should have a 'make showconfig_all' which works as the one now, and 'make showconfig' only giving the important ones. Cheers, H?kan On Fri, 12 Apr 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > on line 108 to 110 of the Makefile there is an automatic setting of the > VULOM4_FW parameter: > > > ? ifeq (,$(VULOM4_FW)) > ?? VULOM4_FW:=$(shell ls $(TRLOII_PATH)/trloctrl | grep _trlo | $(SED) > 's,fw_,,;s,_trlo.*,,') > ? endif > > However, if I let this run (i.e. VULOM4_FW is not set by hand) the outcome > is as follows: > > > VULOM4_FW = "1409285e 68f8955e 6e4ba1a9 a73c5093 af33ed35" > > > My understandig is that there should only be a single number selected > (1409285e for VULOM4B and 6e4ba1a9 for VULOM4). I checked what the "ls" > command produces on two systems: > > > RIO4L-2 mbsdaq > ls $TRLOII_PATH/trloctrl > Makefile? examples/? find_firmwares.pl*? firmwaredirs? fw_0866c243_rfx1/? > fw_1409285e_trlo@? fw_5e8f5ef4_tridi/? fw_68f8955e_trlo_all_in/? > fw_6e4ba1a9_trlo/? fw_a1729cda_rfx0/? fw_a73c5093_trlo@? > fw_af33ed35_trlo_big/? trloctrl.sh*? trlolib/ > > RIO4-MCAL-1 mbsdaq > ls $TRLOII_PATH/trloctrl > Makefile? examples/? find_firmwares.pl*? firmwaredirs? fw_0866c243_rfx1/? > fw_1409285e_trlo@? fw_5e8f5ef4_tridi/? fw_68f8955e_trlo_all_in/? > fw_6e4ba1a9_trlo/? fw_a1729cda_rfx0/? fw_a73c5093_trlo@? > fw_af33ed35_trlo_big/? tridi_log.txt? trloctrl.sh*? trlolib/? vulom_log.txt > > > RIO4L-2 is the one I am working on right now with the VULOM4, whereas > RIO4-MCAL-1 is the system already running with VULOM4B. > > > To me it looks like the code in the Makefile is not working as intended, > right? > > > > > > Best greetings > > G?nter > > > > From g.weber at hi-jena.gsi.de Mon Apr 15 12:51:07 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Mon, 15 Apr 2024 10:51:07 +0000 Subject: [subexp-daq] Possible problem in Makefile of NURDLIB In-Reply-To: <14162460-f6cb-2735-4d52-6f9b0d69e77f@chalmers.se> References: , <14162460-f6cb-2735-4d52-6f9b0d69e77f@chalmers.se> Message-ID: <693c3261caaa4719bcd3f34321dadeff@hi-jena.gsi.de> Dear H?kan, thank you very much for the explanations and the modifications. I see that you updated the automatic determination of the VULOM4_FW variable in the NURDLIB Makefile. Just for clarification: it will always come up with the VULOM4B version, even though there might be a VULOM4 module in the setup, as the firmware for both modules is identical for the purpose of this compilation, right? Moreover, to make things more comfortable for the user, I added the following code to the Makefile: ifeq (,$(TRLOII_PATH)) TRLOII_PATH_TEST:=$(shell pwd)/../trloii ifeq ("$(wildcard $(TRLOII_PATH_TEST))", "") TRLOII_ERROR:=WARNING: Makefile guessed $(TRLOII_PATH_TEST), but folder does not exist! $(call infovar,TRLOII_ERROR) else TRLOII_PATH:=$(TRLOII_PATH_TEST) endif endif This assumes that it is unlikey that you want to compile NURDLIB without TRLOII being present. But maybe, if it is desired to decide if NURDLIB should compile with or without TRLOII it is better to have this as an explict option for "make" instead of doing it implicitly by having the TRLOII_PATH variable being set by hand or not. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Samstag, 13. April 2024 03:50:36 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] Possible problem in Makefile of NURDLIB Dear G?nter, we think that we have managed to solve the issues at hand (there were multiple): - The missing TRIDI compile: r3bfuser compiles (unconditionally) with both tridi and vulom support if it compiles with one of them. (tridi is a module with similar hardware as the vulom). Now the compile instructions also include to get the tridi things compiles. - The VULOM4_FW now only picks one version, which should be enough. Those named _trlo actually have the same register layout, and find_firmwares.pl point them to the same, so any should do. (Please see the updated instructions in the other mail. Only the compilation sequence had additions, not the download parts. But nurdlib and r3bfuser repositores need to be updated. For this: > Reporting compilation errors when they happen and why they happen would > be really very much appreciated I am not sure what can be done when the issues are within the feature-finding builds. I.e., when those fail, it just means that certains options are not available. Problem is when later programs rely on them. if anything, the later programs should then produce more specific errors telling what they are missing. That might be doable with some #error macros, if they do not have complex makefiles to find features. The other thing might be that 'make showconfig' is too cluttered. There are essentially two kinds of features. The uninteresting ones where the systems need to find one working option out of many. If no option works, things will stop, as it cannot continue. The more interesting selections are the ones where it can get away with no support, i. this case e.g. not compiling tridi support. Perhaps one should have a 'make showconfig_all' which works as the one now, and 'make showconfig' only giving the important ones. Cheers, H?kan On Fri, 12 Apr 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > on line 108 to 110 of the Makefile there is an automatic setting of the > VULOM4_FW parameter: > > > ifeq (,$(VULOM4_FW)) > VULOM4_FW:=$(shell ls $(TRLOII_PATH)/trloctrl | grep _trlo | $(SED) > 's,fw_,,;s,_trlo.*,,') > endif > > However, if I let this run (i.e. VULOM4_FW is not set by hand) the outcome > is as follows: > > > VULOM4_FW = "1409285e 68f8955e 6e4ba1a9 a73c5093 af33ed35" > > > My understandig is that there should only be a single number selected > (1409285e for VULOM4B and 6e4ba1a9 for VULOM4). I checked what the "ls" > command produces on two systems: > > > RIO4L-2 mbsdaq > ls $TRLOII_PATH/trloctrl > Makefile examples/ find_firmwares.pl* firmwaredirs fw_0866c243_rfx1/ > fw_1409285e_trlo@ fw_5e8f5ef4_tridi/ fw_68f8955e_trlo_all_in/ > fw_6e4ba1a9_trlo/ fw_a1729cda_rfx0/ fw_a73c5093_trlo@ > fw_af33ed35_trlo_big/ trloctrl.sh* trlolib/ > > RIO4-MCAL-1 mbsdaq > ls $TRLOII_PATH/trloctrl > Makefile examples/ find_firmwares.pl* firmwaredirs fw_0866c243_rfx1/ > fw_1409285e_trlo@ fw_5e8f5ef4_tridi/ fw_68f8955e_trlo_all_in/ > fw_6e4ba1a9_trlo/ fw_a1729cda_rfx0/ fw_a73c5093_trlo@ > fw_af33ed35_trlo_big/ tridi_log.txt trloctrl.sh* trlolib/ vulom_log.txt > > > RIO4L-2 is the one I am working on right now with the VULOM4, whereas > RIO4-MCAL-1 is the system already running with VULOM4B. > > > To me it looks like the code in the Makefile is not working as intended, > right? > > > > > > Best greetings > > G?nter > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Mon Apr 15 12:59:46 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Mon, 15 Apr 2024 12:59:46 +0200 Subject: [subexp-daq] Possible problem in Makefile of NURDLIB In-Reply-To: <693c3261caaa4719bcd3f34321dadeff@hi-jena.gsi.de> References: , <14162460-f6cb-2735-4d52-6f9b0d69e77f@chalmers.se> <693c3261caaa4719bcd3f34321dadeff@hi-jena.gsi.de> Message-ID: <348b557c-67fd-e7fa-0e73-c61a34a241ec@chalmers.se> On Mon, 15 Apr 2024, Weber, Guenter Dr. wrote: > > Dear H?kan, > > > thank you very much for the explanations and the modifications. > > > I see that you updated the automatic determination of the VULOM4_FW variable > in the NURDLIB Makefile. Just for clarification: it will always come up with > the VULOM4B version, even though there might be a VULOM4 module in the > setup, as the firmware for both modules is identical for the purpose of this > compilation, right? Yes, that is the idea. If the trloii/trloctrl/ contain several incompatible versions, it will just pick the first, which might not work. But in that case, at least the setup routines will complain about alias not in list, and then one has to clean up. I think we can live with that. The rest below is for Hans :-) Cheers, H?kan > Moreover, to make things more comfortable for the user, I added the > following code to the Makefile: > > > ifeq (,$(TRLOII_PATH)) > TRLOII_PATH_TEST:=$(shell pwd)/../trloii > ifeq ("$(wildcard $(TRLOII_PATH_TEST))", "") > TRLOII_ERROR:=WARNING: Makefile guessed $(TRLOII_PATH_TEST), but folder does > not exist! > $(call infovar,TRLOII_ERROR) > else > TRLOII_PATH:=$(TRLOII_PATH_TEST) > endif > endif > > This assumes that it is unlikey that you want to compile NURDLIB without > TRLOII being present. But maybe, if it is desired to decide if NURDLIB > should compile with or without TRLOII it is better to have this as an > explict option for "make" instead of doing it implicitly by having the > TRLOII_PATH variable being set by hand or not. > > > > > > > Best greetings > > G?nter > > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan > T Johansson > Gesendet: Samstag, 13. April 2024 03:50:36 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] Possible problem in Makefile of NURDLIB ? > > Dear G?nter, > > we think that we have managed to solve the issues at hand (there were > multiple): > > - The missing TRIDI compile: r3bfuser compiles (unconditionally) with both > ?? tridi and vulom support if it compiles with one of them.? (tridi is a > ?? module with similar hardware as the vulom).? Now the compile > ?? instructions also include to get the tridi things compiles. > > - The VULOM4_FW now only picks one version, which should be enough. > ?? Those named _trlo actually have the same register layout, and > ?? find_firmwares.pl point them to the same, so any should do. > > (Please see the updated instructions in the other mail.? Only the > compilation sequence had additions, not the download parts.? But nurdlib > and r3bfuser repositores need to be updated. > > For this: > > > Reporting compilation errors when they happen and why they happen would > > be really very much appreciated > > I am not sure what can be done when the issues are within the > feature-finding builds.? I.e., when those fail, it just means that > certains options are not available.? Problem is when later programs rely > on them. > > if anything, the later programs should then produce more specific errors > telling what they are missing.? That might be doable with some #error > macros, if they do not have complex makefiles to find features. > > The other thing might be that 'make showconfig' is too cluttered.? There > are essentially two kinds of features.? The uninteresting ones where the > systems need to find one working option out of many.? If no option works, > things will stop, as it cannot continue. > > The more interesting selections are the ones where it can get away with no > support, i. this case e.g. not compiling tridi support. > > Perhaps one should have a 'make showconfig_all' which works as the one > now, and 'make showconfig' only giving the important ones. > > Cheers, > H?kan > > > > On Fri, 12 Apr 2024, Weber, Guenter Dr. wrote: > > > > > Dear friends, > > > > > > on line 108 to 110 of the Makefile there is an automatic setting of the > > VULOM4_FW parameter: > > > > > > ? ifeq (,$(VULOM4_FW)) > > ?? VULOM4_FW:=$(shell ls $(TRLOII_PATH)/trloctrl | grep _trlo | $(SED) > > 's,fw_,,;s,_trlo.*,,') > > ? endif > > > > However, if I let this run (i.e. VULOM4_FW is not set by hand) the outcome > > is as follows: > > > > > > VULOM4_FW = "1409285e 68f8955e 6e4ba1a9 a73c5093 af33ed35" > > > > > > My understandig is that there should only be a single number selected > > (1409285e for VULOM4B and 6e4ba1a9 for VULOM4). I checked what the "ls" > > command produces on two systems: > > > > > > RIO4L-2 mbsdaq > ls $TRLOII_PATH/trloctrl > > Makefile? examples/? find_firmwares.pl*? firmwaredirs? fw_0866c243_rfx1/? > > fw_1409285e_trlo@? fw_5e8f5ef4_tridi/? fw_68f8955e_trlo_all_in/? > > fw_6e4ba1a9_trlo/? fw_a1729cda_rfx0/? fw_a73c5093_trlo@? > > fw_af33ed35_trlo_big/? trloctrl.sh*? trlolib/ > > > > RIO4-MCAL-1 mbsdaq > ls $TRLOII_PATH/trloctrl > > Makefile? examples/? find_firmwares.pl*? firmwaredirs? fw_0866c243_rfx1/? > > fw_1409285e_trlo@? fw_5e8f5ef4_tridi/? fw_68f8955e_trlo_all_in/? > > fw_6e4ba1a9_trlo/? fw_a1729cda_rfx0/? fw_a73c5093_trlo@? > > fw_af33ed35_trlo_big/? tridi_log.txt? trloctrl.sh*? trlolib/? > vulom_log.txt > > > > > > RIO4L-2 is the one I am working on right now with the VULOM4, whereas > > RIO4-MCAL-1 is the system already running with VULOM4B. > > > > > > To me it looks like the code in the Makefile is not working as intended, > > right? > > > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > > > > From g.weber at hi-jena.gsi.de Mon Apr 15 13:25:36 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Mon, 15 Apr 2024 11:25:36 +0000 Subject: [subexp-daq] Possible problem in Makefile of NURDLIB In-Reply-To: <348b557c-67fd-e7fa-0e73-c61a34a241ec@chalmers.se> References: , <14162460-f6cb-2735-4d52-6f9b0d69e77f@chalmers.se> <693c3261caaa4719bcd3f34321dadeff@hi-jena.gsi.de>, <348b557c-67fd-e7fa-0e73-c61a34a241ec@chalmers.se> Message-ID: Dear H?kan, does this also mean that I can just do the following make fw_1409285e_trlo_build # choose the vulom4b trlo even if I have a VULOM4 instead of VULOM4B in my setup? My understanding was that I should use make fw_6e4ba1a9_trlo_build # choose the vulom4 trlo instead. Thank you very much! Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Montag, 15. April 2024 12:59:46 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] Possible problem in Makefile of NURDLIB On Mon, 15 Apr 2024, Weber, Guenter Dr. wrote: > > Dear H?kan, > > > thank you very much for the explanations and the modifications. > > > I see that you updated the automatic determination of the VULOM4_FW variable > in the NURDLIB Makefile. Just for clarification: it will always come up with > the VULOM4B version, even though there might be a VULOM4 module in the > setup, as the firmware for both modules is identical for the purpose of this > compilation, right? Yes, that is the idea. If the trloii/trloctrl/ contain several incompatible versions, it will just pick the first, which might not work. But in that case, at least the setup routines will complain about alias not in list, and then one has to clean up. I think we can live with that. The rest below is for Hans :-) Cheers, H?kan > Moreover, to make things more comfortable for the user, I added the > following code to the Makefile: > > > ifeq (,$(TRLOII_PATH)) > TRLOII_PATH_TEST:=$(shell pwd)/../trloii > ifeq ("$(wildcard $(TRLOII_PATH_TEST))", "") > TRLOII_ERROR:=WARNING: Makefile guessed $(TRLOII_PATH_TEST), but folder does > not exist! > $(call infovar,TRLOII_ERROR) > else > TRLOII_PATH:=$(TRLOII_PATH_TEST) > endif > endif > > This assumes that it is unlikey that you want to compile NURDLIB without > TRLOII being present. But maybe, if it is desired to decide if NURDLIB > should compile with or without TRLOII it is better to have this as an > explict option for "make" instead of doing it implicitly by having the > TRLOII_PATH variable being set by hand or not. > > > > > > > Best greetings > > G?nter > > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan > T Johansson > Gesendet: Samstag, 13. April 2024 03:50:36 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] Possible problem in Makefile of NURDLIB > > Dear G?nter, > > we think that we have managed to solve the issues at hand (there were > multiple): > > - The missing TRIDI compile: r3bfuser compiles (unconditionally) with both > tridi and vulom support if it compiles with one of them. (tridi is a > module with similar hardware as the vulom). Now the compile > instructions also include to get the tridi things compiles. > > - The VULOM4_FW now only picks one version, which should be enough. > Those named _trlo actually have the same register layout, and > find_firmwares.pl point them to the same, so any should do. > > (Please see the updated instructions in the other mail. Only the > compilation sequence had additions, not the download parts. But nurdlib > and r3bfuser repositores need to be updated. > > For this: > > > Reporting compilation errors when they happen and why they happen would > > be really very much appreciated > > I am not sure what can be done when the issues are within the > feature-finding builds. I.e., when those fail, it just means that > certains options are not available. Problem is when later programs rely > on them. > > if anything, the later programs should then produce more specific errors > telling what they are missing. That might be doable with some #error > macros, if they do not have complex makefiles to find features. > > The other thing might be that 'make showconfig' is too cluttered. There > are essentially two kinds of features. The uninteresting ones where the > systems need to find one working option out of many. If no option works, > things will stop, as it cannot continue. > > The more interesting selections are the ones where it can get away with no > support, i. this case e.g. not compiling tridi support. > > Perhaps one should have a 'make showconfig_all' which works as the one > now, and 'make showconfig' only giving the important ones. > > Cheers, > H?kan > > > > On Fri, 12 Apr 2024, Weber, Guenter Dr. wrote: > > > > > Dear friends, > > > > > > on line 108 to 110 of the Makefile there is an automatic setting of the > > VULOM4_FW parameter: > > > > > > ifeq (,$(VULOM4_FW)) > > VULOM4_FW:=$(shell ls $(TRLOII_PATH)/trloctrl | grep _trlo | $(SED) > > 's,fw_,,;s,_trlo.*,,') > > endif > > > > However, if I let this run (i.e. VULOM4_FW is not set by hand) the outcome > > is as follows: > > > > > > VULOM4_FW = "1409285e 68f8955e 6e4ba1a9 a73c5093 af33ed35" > > > > > > My understandig is that there should only be a single number selected > > (1409285e for VULOM4B and 6e4ba1a9 for VULOM4). I checked what the "ls" > > command produces on two systems: > > > > > > RIO4L-2 mbsdaq > ls $TRLOII_PATH/trloctrl > > Makefile examples/ find_firmwares.pl* firmwaredirs fw_0866c243_rfx1/ > > fw_1409285e_trlo@ fw_5e8f5ef4_tridi/ fw_68f8955e_trlo_all_in/ > > fw_6e4ba1a9_trlo/ fw_a1729cda_rfx0/ fw_a73c5093_trlo@ > > fw_af33ed35_trlo_big/ trloctrl.sh* trlolib/ > > > > RIO4-MCAL-1 mbsdaq > ls $TRLOII_PATH/trloctrl > > Makefile examples/ find_firmwares.pl* firmwaredirs fw_0866c243_rfx1/ > > fw_1409285e_trlo@ fw_5e8f5ef4_tridi/ fw_68f8955e_trlo_all_in/ > > fw_6e4ba1a9_trlo/ fw_a1729cda_rfx0/ fw_a73c5093_trlo@ > > fw_af33ed35_trlo_big/ tridi_log.txt trloctrl.sh* trlolib/ > vulom_log.txt > > > > > > RIO4L-2 is the one I am working on right now with the VULOM4, whereas > > RIO4-MCAL-1 is the system already running with VULOM4B. > > > > > > To me it looks like the code in the Makefile is not working as intended, > > right? > > > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Mon Apr 15 13:31:16 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Mon, 15 Apr 2024 13:31:16 +0200 Subject: [subexp-daq] Possible problem in Makefile of NURDLIB In-Reply-To: References: , <14162460-f6cb-2735-4d52-6f9b0d69e77f@chalmers.se> <693c3261caaa4719bcd3f34321dadeff@hi-jena.gsi.de>, <348b557c-67fd-e7fa-0e73-c61a34a241ec@chalmers.se> Message-ID: On Mon, 15 Apr 2024, Weber, Guenter Dr. wrote: > > Dear H?kan, > > > does this also mean that I can just do the following > > > make fw_1409285e_trlo_build????? # choose the vulom4b trlo > > > even if I have a VULOM4 instead of VULOM4B in my setup? > > > My understanding was that I should use > > > make fw_6e4ba1a9_trlo_build ?? # choose the vulom4 trlo > > instead. Yes. find_firmwares.pl set most directories up as symlinks to each other when they have the same register layout. Cheers, H?kan > > > > > Thank you very much! > > > > > > Best greetings > > G?nter > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan > T Johansson > Gesendet: Montag, 15. April 2024 12:59:46 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] Possible problem in Makefile of NURDLIB ? > > On Mon, 15 Apr 2024, Weber, Guenter Dr. wrote: > > > > > Dear H?kan, > > > > > > thank you very much for the explanations and the modifications. > > > > > > I see that you updated the automatic determination of the VULOM4_FW > variable > > in the NURDLIB Makefile. Just for clarification: it will always come up > with > > the VULOM4B version, even though there might be a VULOM4 module in the > > setup, as the firmware for both modules is identical for the purpose of > this > > compilation, right? > > Yes, that is the idea. > > If the trloii/trloctrl/ contain several incompatible versions, it will > just pick the first, which might not work.? But in that case, at least the > setup routines will complain about alias not in list, and then one has > to clean up.? I think we can live with that. > > The rest below is for Hans :-) > > Cheers, > H?kan > > > Moreover, to make things more comfortable for the user, I added the > > following code to the Makefile: > > > > > > ifeq (,$(TRLOII_PATH)) > > TRLOII_PATH_TEST:=$(shell pwd)/../trloii > > ifeq ("$(wildcard $(TRLOII_PATH_TEST))", "") > > TRLOII_ERROR:=WARNING: Makefile guessed $(TRLOII_PATH_TEST), but folder > does > > not exist! > > $(call infovar,TRLOII_ERROR) > > else > > TRLOII_PATH:=$(TRLOII_PATH_TEST) > > endif > > endif > > > > This assumes that it is unlikey that you want to compile NURDLIB without > > TRLOII being present. But maybe, if it is desired to decide if NURDLIB > > should compile with or without TRLOII it is better to have this as an > > explict option for "make" instead of doing it implicitly by having the > > TRLOII_PATH variable being set by hand or not. > > > > > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > >___________________________________________________________________________ > _ > > Von: subexp-daq im Auftrag von > H?kan > > T Johansson > > Gesendet: Samstag, 13. April 2024 03:50:36 > > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > Betreff: Re: [subexp-daq] Possible problem in Makefile of NURDLIB ? > > > > Dear G?nter, > > > > we think that we have managed to solve the issues at hand (there were > > multiple): > > > > - The missing TRIDI compile: r3bfuser compiles (unconditionally) with both > > ?? tridi and vulom support if it compiles with one of them.? (tridi is a > > ?? module with similar hardware as the vulom).? Now the compile > > ?? instructions also include to get the tridi things compiles. > > > > - The VULOM4_FW now only picks one version, which should be enough. > > ?? Those named _trlo actually have the same register layout, and > > ?? find_firmwares.pl point them to the same, so any should do. > > > > (Please see the updated instructions in the other mail.? Only the > > compilation sequence had additions, not the download parts.? But nurdlib > > and r3bfuser repositores need to be updated. > > > > For this: > > > > > Reporting compilation errors when they happen and why they happen would > > > be really very much appreciated > > > > I am not sure what can be done when the issues are within the > > feature-finding builds.? I.e., when those fail, it just means that > > certains options are not available.? Problem is when later programs rely > > on them. > > > > if anything, the later programs should then produce more specific errors > > telling what they are missing.? That might be doable with some #error > > macros, if they do not have complex makefiles to find features. > > > > The other thing might be that 'make showconfig' is too cluttered.? There > > are essentially two kinds of features.? The uninteresting ones where the > > systems need to find one working option out of many.? If no option works, > > things will stop, as it cannot continue. > > > > The more interesting selections are the ones where it can get away with no > > support, i. this case e.g. not compiling tridi support. > > > > Perhaps one should have a 'make showconfig_all' which works as the one > > now, and 'make showconfig' only giving the important ones. > > > > Cheers, > > H?kan > > > > > > > > On Fri, 12 Apr 2024, Weber, Guenter Dr. wrote: > > > > > > > > Dear friends, > > > > > > > > > on line 108 to 110 of the Makefile there is an automatic setting of the > > > VULOM4_FW parameter: > > > > > > > > > ? ifeq (,$(VULOM4_FW)) > > > ?? VULOM4_FW:=$(shell ls $(TRLOII_PATH)/trloctrl | grep _trlo | $(SED) > > > 's,fw_,,;s,_trlo.*,,') > > > ? endif > > > > > > However, if I let this run (i.e. VULOM4_FW is not set by hand) the > outcome > > > is as follows: > > > > > > > > > VULOM4_FW = "1409285e 68f8955e 6e4ba1a9 a73c5093 af33ed35" > > > > > > > > > My understandig is that there should only be a single number selected > > > (1409285e for VULOM4B and 6e4ba1a9 for VULOM4). I checked what the "ls" > > > command produces on two systems: > > > > > > > > > RIO4L-2 mbsdaq > ls $TRLOII_PATH/trloctrl > > > Makefile? examples/? find_firmwares.pl*? firmwaredirs? > fw_0866c243_rfx1/? > > > fw_1409285e_trlo@? fw_5e8f5ef4_tridi/? fw_68f8955e_trlo_all_in/? > > > fw_6e4ba1a9_trlo/? fw_a1729cda_rfx0/? fw_a73c5093_trlo@? > > > fw_af33ed35_trlo_big/? trloctrl.sh*? trlolib/ > > > > > > RIO4-MCAL-1 mbsdaq > ls $TRLOII_PATH/trloctrl > > > Makefile? examples/? find_firmwares.pl*? firmwaredirs? > fw_0866c243_rfx1/? > > > fw_1409285e_trlo@? fw_5e8f5ef4_tridi/? fw_68f8955e_trlo_all_in/? > > > fw_6e4ba1a9_trlo/? fw_a1729cda_rfx0/? fw_a73c5093_trlo@? > > > fw_af33ed35_trlo_big/? tridi_log.txt? trloctrl.sh*? trlolib/? > > vulom_log.txt > > > > > > > > > RIO4L-2 is the one I am working on right now with the VULOM4, whereas > > > RIO4-MCAL-1 is the system already running with VULOM4B. > > > > > > > > > To me it looks like the code in the Makefile is not working as intended, > > > right? > > > > > > > > > > > > > > > > > > Best greetings > > > > > > G?nter > > > > > > > > > > > > > > > > > > From g.weber at hi-jena.gsi.de Mon Apr 15 14:31:15 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Mon, 15 Apr 2024 12:31:15 +0000 Subject: [subexp-daq] Question un UCESB compilation Message-ID: Dear friends, on the new system I get the following message when trying to compile UCESB: RIO4L-2 mbsdaq > make empty which: no cernlib in (/mbs/driv/white_rabbit/enigma/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) which: no cernlib in (/mbs/driv/white_rabbit/enigma/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) make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/ucesb/empty' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/ucesb/empty' On the PC there is no obvious problem, but on the RIO it looks like this. Is the missing cernlib an issue? Thank you very much! Best greetings G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.tornqvist at chalmers.se Mon Apr 15 15:01:15 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Mon, 15 Apr 2024 15:01:15 +0200 Subject: [subexp-daq] Possible problem in Makefile of NURDLIB In-Reply-To: <693c3261caaa4719bcd3f34321dadeff@hi-jena.gsi.de> References: <14162460-f6cb-2735-4d52-6f9b0d69e77f@chalmers.se> <693c3261caaa4719bcd3f34321dadeff@hi-jena.gsi.de> Message-ID: Dear G?nter, On 2024-04-15 12:51, Weber, Guenter Dr. wrote: > Dear H?kan, > > > thank you very much for the explanations and the modifications. > > > I see that you updated the automatic determination of the VULOM4_FW > variable in the NURDLIB Makefile. Just for clarification: it will always > come up with the VULOM4B version, even though there might be a VULOM4 > module in the setup, as the firmware for both modules is identical for > the purpose of this compilation, right? > > > Moreover, to make things more comfortable for the user, I added the > following code to the Makefile: > > > ifeq (,$(TRLOII_PATH)) > TRLOII_PATH_TEST:=$(shell pwd)/../trloii > ifeq ("$(wildcard $(TRLOII_PATH_TEST))", "") > TRLOII_ERROR:=WARNING: Makefile guessed $(TRLOII_PATH_TEST), but folder > does not exist! > $(call infovar,TRLOII_ERROR) > else > TRLOII_PATH:=$(TRLOII_PATH_TEST) > endif > endif > > This assumes that it is unlikey that you want to compile NURDLIB without > TRLOII being present. But maybe, if it is desired to decide if NURDLIB > should compile with or without TRLOII it is better to have this as an > explict option for "make" instead of doing it implicitly by having the > TRLOII_PATH variable being set by hand or not. If ../trloii exists and nconf runs as expected this works also on non-VME systems. But I'm not too keen on having this warning where this is an expected outcome. Will think about it. Cheers, Hans > Best greetings > > G?nter > > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > H?kan T Johansson > *Gesendet:* Samstag, 13. April 2024 03:50:36 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > *Betreff:* Re: [subexp-daq] Possible problem in Makefile of NURDLIB > > Dear G?nter, > > we think that we have managed to solve the issues at hand (there were > multiple): > > - The missing TRIDI compile: r3bfuser compiles (unconditionally) with both > ?? tridi and vulom support if it compiles with one of them.? (tridi is a > ?? module with similar hardware as the vulom).? Now the compile > ?? instructions also include to get the tridi things compiles. > > - The VULOM4_FW now only picks one version, which should be enough. > ?? Those named _trlo actually have the same register layout, and > ?? find_firmwares.pl point them to the same, so any should do. > > (Please see the updated instructions in the other mail.? Only the > compilation sequence had additions, not the download parts.? But nurdlib > and r3bfuser repositores need to be updated. > > For this: > >> Reporting compilation errors when they happen and why they happen would >> be really very much appreciated > > I am not sure what can be done when the issues are within the > feature-finding builds.? I.e., when those fail, it just means that > certains options are not available.? Problem is when later programs rely > on them. > > if anything, the later programs should then produce more specific errors > telling what they are missing.? That might be doable with some #error > macros, if they do not have complex makefiles to find features. > > The other thing might be that 'make showconfig' is too cluttered.? There > are essentially two kinds of features.? The uninteresting ones where the > systems need to find one working option out of many.? If no option works, > things will stop, as it cannot continue. > > The more interesting selections are the ones where it can get away with no > support, i. this case e.g. not compiling tridi support. > > Perhaps one should have a 'make showconfig_all' which works as the one > now, and 'make showconfig' only giving the important ones. > > Cheers, > H?kan > > > > On Fri, 12 Apr 2024, Weber, Guenter Dr. wrote: > >> >> Dear friends, >> >> >> on line 108 to 110 of the Makefile there is an automatic setting of the >> VULOM4_FW parameter: >> >> >> ? ifeq (,$(VULOM4_FW)) >> ?? VULOM4_FW:=$(shell ls $(TRLOII_PATH)/trloctrl | grep _trlo | $(SED) >> 's,fw_,,;s,_trlo.*,,') >> ? endif >> >> However, if I let this run (i.e. VULOM4_FW is not set by hand) the outcome >> is as follows: >> >> >> VULOM4_FW = "1409285e 68f8955e 6e4ba1a9 a73c5093 af33ed35" >> >> >> My understandig is that there should only be a single number selected >> (1409285e for VULOM4B and 6e4ba1a9 for VULOM4). I checked what the "ls" >> command produces on two systems: >> >> >> RIO4L-2 mbsdaq > ls $TRLOII_PATH/trloctrl >> Makefile? examples/? find_firmwares.pl*? firmwaredirs? fw_0866c243_rfx1/ >> fw_1409285e_trlo@? fw_5e8f5ef4_tridi/? fw_68f8955e_trlo_all_in/ >> fw_6e4ba1a9_trlo/? fw_a1729cda_rfx0/? fw_a73c5093_trlo@ >> fw_af33ed35_trlo_big/? trloctrl.sh*? trlolib/ >> >> RIO4-MCAL-1 mbsdaq > ls $TRLOII_PATH/trloctrl >> Makefile? examples/? find_firmwares.pl*? firmwaredirs? fw_0866c243_rfx1/ >> fw_1409285e_trlo@? fw_5e8f5ef4_tridi/? fw_68f8955e_trlo_all_in/ >> fw_6e4ba1a9_trlo/? fw_a1729cda_rfx0/? fw_a73c5093_trlo@ >> fw_af33ed35_trlo_big/? tridi_log.txt? trloctrl.sh*? trlolib/? vulom_log.txt >> >> >> RIO4L-2 is the one I am working on right now with the VULOM4, whereas >> RIO4-MCAL-1 is the system already running with VULOM4B. >> >> >> To me it looks like the code in the Makefile is not working as intended, >> right? >> >> >> >> >> >> Best greetings >> >> G?nter >> >> >> >> > From f96hajo at chalmers.se Mon Apr 15 16:15:32 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Mon, 15 Apr 2024 16:15:32 +0200 Subject: [subexp-daq] Question un UCESB compilation In-Reply-To: References: Message-ID: <57620d41-0499-bbd6-20ec-b10309678b4d@chalmers.se> Dear G?nter, the missing cernlib would not be an issue. Though, this compile would not be needed, since UCESB should normally not be run o the RIO. (The RIO has only one CPU-core, so running an unpacker there will take time from the DAQ.) In fact, I think I never tried even to compile it on such slow systems :-) Cheers, H?kan On Mon, 15 Apr 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > on the new system I get the following message when trying to compile UCESB: > > > RIO4L-2 mbsdaq > make empty > which: no cernlib in(/mbs/driv/white_rabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/bin:/bin:/bin/ces:/usr/bin:/mbsusr/mbsdaq/bin:/usr/local/bin:/usr/bi > n/X11:/etc:/usr/etc:.:/mbsusr/mbsdaq/tools) > which: no cernlib in(/mbs/driv/white_rabbit/enigma/RIO4_Linux_OSV_2_6_33_SuHa/bin:/bin:/bin/ces:/usr/bin:/mbsusr/mbsdaq/bin:/usr/local/bin:/usr/bi > n/X11:/etc:/usr/etc:.:/mbsusr/mbsdaq/tools) > make[1]: Entering directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/ucesb/empty' > make[1]: Nothing to be done for `all'. > make[1]: Leaving directory `/LynxOS/mbsusr/mbsdaq/daq/2024_polarimeter/ucesb/empty' > > > On the PC there is no obvious problem, but on the RIO it looks like this. Is the missing cernlib an issue? > > > > > > Thank you very much! > > > > > Best greetings > > G?nter > > > > > From f96hajo at chalmers.se Mon Apr 15 23:56:39 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Mon, 15 Apr 2024 23:56:39 +0200 Subject: [subexp-daq] Possible problem in Makefile of NURDLIB In-Reply-To: References: <14162460-f6cb-2735-4d52-6f9b0d69e77f@chalmers.se> <693c3261caaa4719bcd3f34321dadeff@hi-jena.gsi.de> Message-ID: <22a0ec8b-63c4-84bd-971a-11476e0acbad@chalmers.se> On Mon, 15 Apr 2024, Hans Toshihide T?rnqvist wrote: > Dear G?nter, > > On 2024-04-15 12:51, Weber, Guenter Dr. wrote: >> Dear H?kan, >> >> >> thank you very much for the explanations and the modifications. >> >> >> I see that you updated the automatic determination of the VULOM4_FW >> variable in the NURDLIB Makefile. Just for clarification: it will always >> come up with the VULOM4B version, even though there might be a VULOM4 >> module in the setup, as the firmware for both modules is identical for >> the purpose of this compilation, right? >> >> >> Moreover, to make things more comfortable for the user, I added the >> following code to the Makefile: >> >> >> ifeq (,$(TRLOII_PATH)) >> TRLOII_PATH_TEST:=$(shell pwd)/../trloii >> ifeq ("$(wildcard $(TRLOII_PATH_TEST))", "") >> TRLOII_ERROR:=WARNING: Makefile guessed $(TRLOII_PATH_TEST), but folder >> does not exist! >> $(call infovar,TRLOII_ERROR) >> else >> TRLOII_PATH:=$(TRLOII_PATH_TEST) >> endif >> endif >> >> This assumes that it is unlikey that you want to compile NURDLIB without >> TRLOII being present. But maybe, if it is desired to decide if NURDLIB >> should compile with or without TRLOII it is better to have this as an >> explict option for "make" instead of doing it implicitly by having the >> TRLOII_PATH variable being set by hand or not. > > If ../trloii exists and nconf runs as expected this works also on > non-VME systems. But I'm not too keen on having this warning where this > is an expected outcome. Will think about it. I would agree that warnings are very distracting, and whenever I see them I have an urge to fix them. So they should not be issued when it is ok that a feature is 'missing'. Since Nurdlib can be well used for systems where no VULOM / TRLOII is around, it would not be nice to warn by default. The automatic configuration of features I like, but indeed, sometimes the easily missing pieces are quite irritating. How about not making it mandatory to ask for features, but one could have some additional make targets that check for the existence of certian features. In this case, e.g. make require-trloii # (or require_trloii) which would depend on the default (all) target, but also fail with an error code if (in this case) nurdlib did not find trloii. The other critical piece (also in trloii / drasi) would be the hardware mapping method that is compiled in. That has a tendency to go missing, in case the needed library is not in the include path. -- In drasi and trloii I changed the 'showconfig' target to only show a few options (actually one - the harware mapping method). showconfig_all as before shows all autoconfiguration results. Cheers, H?kan From g.weber at hi-jena.gsi.de Tue Apr 16 06:46:59 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 16 Apr 2024 04:46:59 +0000 Subject: [subexp-daq] Possible problem in Makefile of NURDLIB In-Reply-To: <22a0ec8b-63c4-84bd-971a-11476e0acbad@chalmers.se> References: <14162460-f6cb-2735-4d52-6f9b0d69e77f@chalmers.se> <693c3261caaa4719bcd3f34321dadeff@hi-jena.gsi.de> , <22a0ec8b-63c4-84bd-971a-11476e0acbad@chalmers.se> Message-ID: <4c7096b9811545bd94d814b5fca0d6a7@hi-jena.gsi.de> Looks like a good 'compromise' to me :-) ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Montag, 15. April 2024 23:56:39 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] Possible problem in Makefile of NURDLIB On Mon, 15 Apr 2024, Hans Toshihide T?rnqvist wrote: > Dear G?nter, > > On 2024-04-15 12:51, Weber, Guenter Dr. wrote: >> Dear H?kan, >> >> >> thank you very much for the explanations and the modifications. >> >> >> I see that you updated the automatic determination of the VULOM4_FW >> variable in the NURDLIB Makefile. Just for clarification: it will always >> come up with the VULOM4B version, even though there might be a VULOM4 >> module in the setup, as the firmware for both modules is identical for >> the purpose of this compilation, right? >> >> >> Moreover, to make things more comfortable for the user, I added the >> following code to the Makefile: >> >> >> ifeq (,$(TRLOII_PATH)) >> TRLOII_PATH_TEST:=$(shell pwd)/../trloii >> ifeq ("$(wildcard $(TRLOII_PATH_TEST))", "") >> TRLOII_ERROR:=WARNING: Makefile guessed $(TRLOII_PATH_TEST), but folder >> does not exist! >> $(call infovar,TRLOII_ERROR) >> else >> TRLOII_PATH:=$(TRLOII_PATH_TEST) >> endif >> endif >> >> This assumes that it is unlikey that you want to compile NURDLIB without >> TRLOII being present. But maybe, if it is desired to decide if NURDLIB >> should compile with or without TRLOII it is better to have this as an >> explict option for "make" instead of doing it implicitly by having the >> TRLOII_PATH variable being set by hand or not. > > If ../trloii exists and nconf runs as expected this works also on > non-VME systems. But I'm not too keen on having this warning where this > is an expected outcome. Will think about it. I would agree that warnings are very distracting, and whenever I see them I have an urge to fix them. So they should not be issued when it is ok that a feature is 'missing'. Since Nurdlib can be well used for systems where no VULOM / TRLOII is around, it would not be nice to warn by default. The automatic configuration of features I like, but indeed, sometimes the easily missing pieces are quite irritating. How about not making it mandatory to ask for features, but one could have some additional make targets that check for the existence of certian features. In this case, e.g. make require-trloii # (or require_trloii) which would depend on the default (all) target, but also fail with an error code if (in this case) nurdlib did not find trloii. The other critical piece (also in trloii / drasi) would be the hardware mapping method that is compiled in. That has a tendency to go missing, in case the needed library is not in the include path. -- In drasi and trloii I changed the 'showconfig' target to only show a few options (actually one - the harware mapping method). showconfig_all as before shows all autoconfiguration results. Cheers, H?kan -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.weber at hi-jena.gsi.de Tue Apr 16 07:11:32 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 16 Apr 2024 05:11:32 +0000 Subject: [subexp-daq] NURDLIB - Problem in parser of caen_v1n90 Message-ID: Dear friends, yesterday I managed to get the DAQ starting (using the updated software and howto instructions). However, the readout of the TDC module V1190A failed: 2024-04-15 14:29:36.979260 i RIO4L-2/MAIN crate_init(POLARIMETER) } +0200 CEST :f_user.c:1257: 2024-04-15 14:29:36.979280 E RIO4L-2/MAIN had readout error, ret=0x2, trigger=1, prev=1 +0200 CEST :module/caen_v1n90/caen_v1n90.c:651: 2024-04-15 14:29:36.979684 E RIO4L-2/MAIN Trailer corrupt (ofs=0x00000010,u8[4]=0x0900032f). +0200 CEST :crate/crate.c:2074: 2024-04-15 14:29:36.979712 E RIO4L-2/MAIN POLARIMETER[3]=CAEN_V1190 parse error=0x00000002, dumping data: +0200 CEST :crate/crate.c:2083: 2024-04-15 14:29:36.979724 i RIO4L-2/MAIN ---[ Dump begin ]--- +0200 CEST :crate/crate.c:2083: 2024-04-15 14:29:36.979734 i RIO4L-2/MAIN Start=0x3005ef08 Bytes=44=0x2c +0200 CEST :crate/crate.c:2083: 2024-04-15 14:29:36.979755 i RIO4L-2/MAIN 0: 40000003 0800032f 00702106 18000003 0900032f 19000002 0a00032f 1a000002 +0200 CEST :crate/crate.c:2083: 2024-04-15 14:29:36.979770 i RIO4L-2/MAIN 20: 0b00032f 1b000002 80000163 +0200 CEST :crate/crate.c:2083: 2024-04-15 14:29:36.979780 i RIO4L-2/MAIN ---[ Dump end ]--- +0200 CEST :crate/crate.c:1554: 2024-04-15 14:29:36.979810 E RIO4L-2/MAIN POLARIMETER: readout failed! +0200 CEST :crate/crate.c:1598: 2024-04-15 14:29:36.979823 E RIO4L-2/MAIN POLARIMETER: had problems, re-initializing. To us it looks like the parser does not account for the fact that the module contains several individual TDC units which each will produce a TDC header plus payload. And only after all TDC units were readout, finally the trailer will appear. (As I can see, the 1n90 series ranges from 16 channels to 128 channels with the high channel number modules having several individual TDC units. Maybe, this whole issue was overlooked when writing the parser code?) In the attachment, I send a modified version of the parser where for testing purposes it is assumed that the module has four TDC units (as should be the case for our module). Compilation of this code works, but it fails in the unit test with the following errors: make: Warning: File `build_cc_ppc-linux_4.2.2_debug/module/caen_v1n90/caen_v1n90.d' has modification time 45 s in the future CC build_cc_ppc-linux_4.2.2_debug/module/caen_v1n90/caen_v1n90.o LD build_cc_ppc-linux_4.2.2_debug/test TEST build_cc_ppc-linux_4.2.2_debug/test_ok [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-04-15,20:11:37:ERRR: Invalid pointer to advance event buffer. [tests/base.c:47] 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:47] 2024-04-15,20:11:37:ERRR: Invalid pointer to advance event buffer. [tests/base.c:56] 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:56] 2024-04-15,20:11:37:ERRR: Tried to advance outside event buffer. [tests/base.c:72] 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:72] [tests/base.c:112: EventBufferInvariant] 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae008:11 != 0x103ae008:10). [tests/base.c:87] 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:87] 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae008:9 != 0x103ae008:10). [tests/base.c:91] 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:91] 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae009:10 != 0x103ae008:10). [tests/base.c:95] 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:95] 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae007:10 != 0x103ae008:10). [tests/base.c:99] 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:99] For comparison, I also send the parser from the NURDLIB version that Bastian had set up for us. It would be really great if you could have a look into this. Most probably this is the last issue that we are facing, before the DAQ is fine again. Thank you very much! Best greetings G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- uint32_t caen_v1n90_parse_data(struct CaenV1n90Module const *a_v1n90, struct EventConstBuffer const *a_event_buffer, int a_do_pedestals) { uint32_t const *p; uint32_t const *end; uint32_t result; unsigned event_no; (void)a_v1n90; (void)a_do_pedestals; LOGF(spam)(LOGL, NAME" parse_data {"); result = 0; if (0 != a_event_buffer->bytes % sizeof(uint32_t)) { log_error(LOGL, "Event buffer size not 32-bit aligned."); result = CRATE_READOUT_FAIL_DATA_CORRUPT; goto caen_v1n90_parse_data_done; } /* TODO: This parser is horrible. */ p = a_event_buffer->ptr; end = p + a_event_buffer->bytes / sizeof(uint32_t); while (end > p && DMA_FILLER == *p) { ++p; } for (event_no = 0;; ++event_no) { uint32_t const *event_start; unsigned count; if (end == p) { break; } event_start = p; if (0x40000000 != (TYPE_MASK & *p)) { module_parse_error(LOGL, event_no, a_event_buffer, p, "Global header corrupt"); result = CRATE_READOUT_FAIL_DATA_CORRUPT; goto caen_v1n90_parse_data_done; } ++p; for (;;) { uint32_t top; if (end <= p) { log_error(LOGL, "Unexpected end of data."); result = CRATE_READOUT_FAIL_DATA_MISSING; goto caen_v1n90_parse_data_done; } top = TYPE_MASK & *p; if (0x08000000 == top) { /*module_parse_error(LOGL, event_no, a_event_buffer, p, "TDC headers should be disabled"); result = CRATE_READOUT_FAIL_DATA_CORRUPT; goto caen_v1n90_parse_data_done;*/ } else if (0x00000000 == top) { /* Data. */ } else if (0x18000000 == top) { /*module_parse_error(LOGL, event_no, a_event_buffer, p, "TDC footers should be disabled"); result = CRATE_READOUT_FAIL_DATA_CORRUPT; goto caen_v1n90_parse_data_done;*/ } else if (0x20000000 == top) { /* TODO: Is this really enough? No. */ LOGF(info)(LOGL, NAME" TDC error 0x%8x.", *p); } else if (0x40000000 == top) { /* TODO: Is this really enough? No. */ LOGF(info)(LOGL, NAME" Header again ?? 0x%8x 0x%8x.", *p, *(p-1)); } else if (0x88000000 == top) { /* Extended trigger time tag. */ } else if (0x80000000 == top) { break; } else { module_parse_error(LOGL, event_no, a_event_buffer, p, "TDC data corrupt"); result = CRATE_READOUT_FAIL_DATA_CORRUPT; goto caen_v1n90_parse_data_done; } ++p; } count = (0x001fffe0 & *p) >> 5; ++p; if ((unsigned)(p - event_start) != count) { log_error(LOGL, "EOB count=%d != actual count=%d.", (int)(p - event_start), count); result = CRATE_READOUT_FAIL_DATA_CORRUPT; goto caen_v1n90_parse_data_done; } } caen_v1n90_parse_data_done: LOGF(spam)(LOGL, NAME" parse_data(0x%08x) }", result); return result; } -------------- next part -------------- uint32_t caen_v1n90_parse_data(struct CaenV1n90Module *a_v1n90, struct EventConstBuffer const *a_event_buffer, int a_do_pedestals) { uint32_t const *p32; uint32_t const *end; uint32_t result; uint32_t tdc_num; (void)a_do_pedestals; LOGF(spam)(LOGL, NAME" parse_data {"); result = 0; if (0 != a_event_buffer->bytes % sizeof(uint32_t)) { log_error(LOGL, "Event buffer size not 32-bit aligned."); result = CRATE_READOUT_FAIL_DATA_CORRUPT; goto caen_v1n90_parse_data_done; } p32 = a_event_buffer->ptr; end = p32 + a_event_buffer->bytes / sizeof(uint32_t); tdc_num = 0; for (; p32 < end; ++p32) { uint32_t u32; u32 = *p32; switch (a_v1n90->parse.expect) { case EXPECT_DMA_HEADER: if (DMA_FILLER == u32) { } else if (0x40000000 == (TYPE_MASK & u32)) { uint32_t count; count = (u32 & BITS_MASK(5, 26)) >> 5; (void)count; /* TODO: Check this counter + GEO? */ /* TODO: If disabled, go to payload. */ a_v1n90->parse.expect = EXPECT_TDC_HEADER; tdc_num++; } else { module_parse_error(LOGL, a_event_buffer, p32, "Global header corrupt"); result = CRATE_READOUT_FAIL_DATA_CORRUPT; goto caen_v1n90_parse_data_done; } break; case EXPECT_TDC_HEADER: if (0x08000000 == (TYPE_MASK & u32)) { /* TODO: Check Event-ID and Bunch-ID? */ a_v1n90->parse.expect = EXPECT_TDC_PAYLOAD; } else { module_parse_error(LOGL, a_event_buffer, p32, "TDC header corrupt"); result = CRATE_READOUT_FAIL_DATA_CORRUPT; goto caen_v1n90_parse_data_done; } break; case EXPECT_TDC_PAYLOAD: if (0x00000000 == (TYPE_MASK & u32)) { } else if (0x20000000 == (TYPE_MASK & u32)) { /* TODO: This is optional. */ LOGF(info)(LOGL, NAME" TDC [%1x] reports error 0x%4x.", ((u32 >> 24) & 0x3), (u32 & 0x3FF)); } else if (0x18000000 == (TYPE_MASK & u32)) { /* TODO: Check event-ID and word-count! */ if ( tdc_num == 4 ) a_v1n90->parse.expect = EXPECT_TIMETAG_TRAILER; else a_v1n90->parse.expect = EXPECT_TDC_HEADER; } else { module_parse_error(LOGL, a_event_buffer, p32, "TDC payload corrupt"); result = CRATE_READOUT_FAIL_DATA_CORRUPT; goto caen_v1n90_parse_data_done; } break; case EXPECT_TIMETAG_TRAILER: if (0x88000000 == (TYPE_MASK & u32)) { } else if (0x80000000 == (TYPE_MASK & u32)) { /* TODO: Check word-count and geo! */ a_v1n90->parse.expect = EXPECT_DMA_HEADER; } else { module_parse_error(LOGL, a_event_buffer, p32, "Trailer corrupt"); result = CRATE_READOUT_FAIL_DATA_CORRUPT; goto caen_v1n90_parse_data_done; } break; } } caen_v1n90_parse_data_done: LOGF(spam)(LOGL, NAME" parse_data(0x%08x) }", result); return result; } From g.weber at hi-jena.gsi.de Tue Apr 16 15:23:41 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 16 Apr 2024 13:23:41 +0000 Subject: [subexp-daq] NURDLIB - Problem in parser of caen_v1n90 In-Reply-To: References: Message-ID: <4384b9515b76421b881cef0127933b1f@hi-jena.gsi.de> Dear friends, we have (most probably fixed) the issue by modifying the parser a bit. See attachment. Unfortunately, before doing the changes, I did not open a new branch. Am I allowed to commit our changes to the master branch? Or do you want to implement the new parser (if you think it is fine this way)? Best greetings G?nter ________________________________ Von: Weber, Guenter Dr. Gesendet: Dienstag, 16. April 2024 07:11:32 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: NURDLIB - Problem in parser of caen_v1n90 Dear friends, yesterday I managed to get the DAQ starting (using the updated software and howto instructions). However, the readout of the TDC module V1190A failed: 2024-04-15 14:29:36.979260 i RIO4L-2/MAIN crate_init(POLARIMETER) } +0200 CEST :f_user.c:1257: 2024-04-15 14:29:36.979280 E RIO4L-2/MAIN had readout error, ret=0x2, trigger=1, prev=1 +0200 CEST :module/caen_v1n90/caen_v1n90.c:651: 2024-04-15 14:29:36.979684 E RIO4L-2/MAIN Trailer corrupt (ofs=0x00000010,u8[4]=0x0900032f). +0200 CEST :crate/crate.c:2074: 2024-04-15 14:29:36.979712 E RIO4L-2/MAIN POLARIMETER[3]=CAEN_V1190 parse error=0x00000002, dumping data: +0200 CEST :crate/crate.c:2083: 2024-04-15 14:29:36.979724 i RIO4L-2/MAIN ---[ Dump begin ]--- +0200 CEST :crate/crate.c:2083: 2024-04-15 14:29:36.979734 i RIO4L-2/MAIN Start=0x3005ef08 Bytes=44=0x2c +0200 CEST :crate/crate.c:2083: 2024-04-15 14:29:36.979755 i RIO4L-2/MAIN 0: 40000003 0800032f 00702106 18000003 0900032f 19000002 0a00032f 1a000002 +0200 CEST :crate/crate.c:2083: 2024-04-15 14:29:36.979770 i RIO4L-2/MAIN 20: 0b00032f 1b000002 80000163 +0200 CEST :crate/crate.c:2083: 2024-04-15 14:29:36.979780 i RIO4L-2/MAIN ---[ Dump end ]--- +0200 CEST :crate/crate.c:1554: 2024-04-15 14:29:36.979810 E RIO4L-2/MAIN POLARIMETER: readout failed! +0200 CEST :crate/crate.c:1598: 2024-04-15 14:29:36.979823 E RIO4L-2/MAIN POLARIMETER: had problems, re-initializing. To us it looks like the parser does not account for the fact that the module contains several individual TDC units which each will produce a TDC header plus payload. And only after all TDC units were readout, finally the trailer will appear. (As I can see, the 1n90 series ranges from 16 channels to 128 channels with the high channel number modules having several individual TDC units. Maybe, this whole issue was overlooked when writing the parser code?) In the attachment, I send a modified version of the parser where for testing purposes it is assumed that the module has four TDC units (as should be the case for our module). Compilation of this code works, but it fails in the unit test with the following errors: make: Warning: File `build_cc_ppc-linux_4.2.2_debug/module/caen_v1n90/caen_v1n90.d' has modification time 45 s in the future CC build_cc_ppc-linux_4.2.2_debug/module/caen_v1n90/caen_v1n90.o LD build_cc_ppc-linux_4.2.2_debug/test TEST build_cc_ppc-linux_4.2.2_debug/test_ok [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-04-15,20:11:37:ERRR: Invalid pointer to advance event buffer. [tests/base.c:47] 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:47] 2024-04-15,20:11:37:ERRR: Invalid pointer to advance event buffer. [tests/base.c:56] 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:56] 2024-04-15,20:11:37:ERRR: Tried to advance outside event buffer. [tests/base.c:72] 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:72] [tests/base.c:112: EventBufferInvariant] 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae008:11 != 0x103ae008:10). [tests/base.c:87] 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:87] 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae008:9 != 0x103ae008:10). [tests/base.c:91] 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:91] 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae009:10 != 0x103ae008:10). [tests/base.c:95] 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:95] 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae007:10 != 0x103ae008:10). [tests/base.c:99] 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:99] For comparison, I also send the parser from the NURDLIB version that Bastian had set up for us. It would be really great if you could have a look into this. Most probably this is the last issue that we are facing, before the DAQ is fine again. Thank you very much! Best greetings G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- uint32_t caen_v1n90_parse_data(struct CaenV1n90Module *a_v1n90, struct EventConstBuffer const *a_event_buffer, int a_do_pedestals) { uint32_t const *p32; uint32_t const *end; uint32_t result; (void)a_do_pedestals; LOGF(spam)(LOGL, NAME" parse_data {"); result = 0; if (0 != a_event_buffer->bytes % sizeof(uint32_t)) { log_error(LOGL, "Event buffer size not 32-bit aligned."); result = CRATE_READOUT_FAIL_DATA_CORRUPT; goto caen_v1n90_parse_data_done; } p32 = a_event_buffer->ptr; end = p32 + a_event_buffer->bytes / sizeof(uint32_t); for (; p32 < end; ++p32) { uint32_t u32; u32 = *p32; switch (a_v1n90->parse.expect) { case EXPECT_DMA_HEADER: if (DMA_FILLER == u32) { } else if (0x40000000 == (TYPE_MASK & u32)) { uint32_t count; count = (u32 & BITS_MASK(5, 26)) >> 5; (void)count; /* TODO: Check this counter + GEO? */ /* TODO: If disabled, go to payload. */ a_v1n90->parse.expect = EXPECT_TDC_HEADER; } else { module_parse_error(LOGL, a_event_buffer, p32, "Global header corrupt"); result = CRATE_READOUT_FAIL_DATA_CORRUPT; goto caen_v1n90_parse_data_done; } break; case EXPECT_TDC_HEADER: if (0x08000000 == (TYPE_MASK & u32)) { /* TODO: Check Event-ID and Bunch-ID? */ a_v1n90->parse.expect = EXPECT_TDC_PAYLOAD; } else { module_parse_error(LOGL, a_event_buffer, p32, "TDC header corrupt"); result = CRATE_READOUT_FAIL_DATA_CORRUPT; goto caen_v1n90_parse_data_done; } break; case EXPECT_TDC_PAYLOAD: if (0x00000000 == (TYPE_MASK & u32)) { } else if (0x20000000 == (TYPE_MASK & u32)) { /* TODO: This is optional. */ LOGF(info)(LOGL, NAME" TDC [%1x] reports error 0x%4x.", ((u32 >> 24) & 0x3), (u32 & 0x7FFF)); } else if (0x18000000 == (TYPE_MASK & u32)) { /* TODO: Check event-ID and word-count! */ a_v1n90->parse.expect = EXPECT_TIMETAG_OR_TRAILER_OR_TDC_HEADER; } else { module_parse_error(LOGL, a_event_buffer, p32, "TDC payload corrupt"); result = CRATE_READOUT_FAIL_DATA_CORRUPT; goto caen_v1n90_parse_data_done; } break; case EXPECT_TIMETAG_OR_TRAILER_OR_TDC_HEADER: if (0x88000000 == (TYPE_MASK & u32)) { a_v1n90->parse.expect = EXPECT_TRAILER; } else if (0x80000000 == (TYPE_MASK & u32)) { /* TODO: Check word-count and geo! */ a_v1n90->parse.expect = EXPECT_DMA_HEADER; } else if (0x08000000 == (TYPE_MASK & u32)) { /* TODO: Check Event-ID and Bunch-ID? */ a_v1n90->parse.expect = EXPECT_TDC_PAYLOAD; } else { module_parse_error(LOGL, a_event_buffer, p32, "Trailer or next TDC event corrupt"); result = CRATE_READOUT_FAIL_DATA_CORRUPT; goto caen_v1n90_parse_data_done; } break; case EXPECT_TRAILER: if (0x80000000 == (TYPE_MASK & u32)) { /* TODO: Check word-count and geo! */ a_v1n90->parse.expect = EXPECT_DMA_HEADER; } else { module_parse_error(LOGL, a_event_buffer, p32, "Trailer corrupt"); result = CRATE_READOUT_FAIL_DATA_CORRUPT; goto caen_v1n90_parse_data_done; } break; } } caen_v1n90_parse_data_done: LOGF(spam)(LOGL, NAME" parse_data(0x%08x) }", result); return result; } From f96hajo at chalmers.se Tue Apr 16 16:52:55 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Tue, 16 Apr 2024 16:52:55 +0200 Subject: [subexp-daq] NURDLIB - Problem in parser of caen_v1n90 In-Reply-To: <4384b9515b76421b881cef0127933b1f@hi-jena.gsi.de> References: <4384b9515b76421b881cef0127933b1f@hi-jena.gsi.de> Message-ID: <7d2738d5-63e5-01c6-0979-1a08e77784bb@chalmers.se> Dear G?nter, if you are able to push to the master branch, we actually have a configuration problem. But also we do not push to the (remote) master branch of each other's projects. But in any case, please do not. It is easy to push to a branch with another name: git push : e.g. git push origin master:fixes-of-something ... Or you can just creat a new local branch name first git branch git checkout and the do a git push origin Cheers, H?kan On Tue, 16 Apr 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > we have (most probably fixed) the issue by modifying the parser a bit. See > attachment. > > > Unfortunately, before doing the changes, I did not open a new branch. Am I > allowed to commit our changes to the master branch? Or do? you want to > implement the new parser (if you think it is fine this way)? > > > > > Best greetings > > G?nter > > ____________________________________________________________________________ > Von: Weber, Guenter Dr. > Gesendet: Dienstag, 16. April 2024 07:11:32 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: NURDLIB - Problem in parser of caen_v1n90 ? > > Dear friends, > > > yesterday I managed to get the DAQ starting (using the updated software and > howto instructions). However, the readout of the TDC module V1190A?failed: > > > 2024-04-15 14:29:36.979260 i? RIO4L-2/MAIN? ? crate_init(POLARIMETER) } > +0200 CEST :f_user.c:1257: > 2024-04-15 14:29:36.979280 E? RIO4L-2/MAIN? ? had readout error, ret=0x2, > trigger=1, prev=1 > +0200 CEST :module/caen_v1n90/caen_v1n90.c:651: > 2024-04-15 14:29:36.979684 E? RIO4L-2/MAIN? ? Trailer corrupt > (ofs=0x00000010,u8[4]=0x0900032f). > +0200 CEST :crate/crate.c:2074: > 2024-04-15 14:29:36.979712 E? RIO4L-2/MAIN? ? POLARIMETER[3]=CAEN_V1190 > parse error=0x00000002, dumping data: > +0200 CEST :crate/crate.c:2083: > 2024-04-15 14:29:36.979724 i? RIO4L-2/MAIN? ? ---[ Dump begin ]--- > +0200 CEST :crate/crate.c:2083: > 2024-04-15 14:29:36.979734 i? RIO4L-2/MAIN? ? Start=0x3005ef08? > Bytes=44=0x2c > +0200 CEST :crate/crate.c:2083: > 2024-04-15 14:29:36.979755 i? RIO4L-2/MAIN? ? ? ? 0: 40000003 0800032f > 00702106 18000003 0900032f 19000002 0a00032f 1a000002 > +0200 CEST :crate/crate.c:2083: > 2024-04-15 14:29:36.979770 i? RIO4L-2/MAIN? ? ? ?20: 0b00032f 1b000002 > 80000163 > +0200 CEST :crate/crate.c:2083: > 2024-04-15 14:29:36.979780 i? RIO4L-2/MAIN? ? ---[? Dump end? ]--- > +0200 CEST :crate/crate.c:1554: > 2024-04-15 14:29:36.979810 E? RIO4L-2/MAIN? ? POLARIMETER: readout failed! > +0200 CEST :crate/crate.c:1598: > 2024-04-15 14:29:36.979823 E? RIO4L-2/MAIN? ? POLARIMETER: had problems, > re-initializing. > > > To us it looks like the parser does not account for the fact that the module > contains?several individual TDC units which each will produce a TDC header > plus payload. And only after all TDC units were readout, finally the trailer > will appear. > > > (As I can see, the 1n90 series ranges from 16 channels to 128 channels with > the high channel number modules having several individual TDC units. Maybe, > this whole issue was overlooked when writing the parser code?) > > > In the attachment, I send a?modified version of the parser where for testing > purposes it is assumed that the module has four TDC units (as should be the > case for our module). Compilation of this code works, but it fails in the > unit test with the following errors: > > > make: Warning: File > `build_cc_ppc-linux_4.2.2_debug/module/caen_v1n90/caen_v1n90.d' has > modification time 45 s in the future > CC? ? build_cc_ppc-linux_4.2.2_debug/module/caen_v1n90/caen_v1n90.o > LD? ? build_cc_ppc-linux_4.2.2_debug/test > TEST? build_cc_ppc-linux_4.2.2_debug/test_ok > [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-04-15,20:11:37:ERRR: Invalid pointer to advance event buffer. > [tests/base.c:47] > 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:47] > 2024-04-15,20:11:37:ERRR: Invalid pointer to advance event buffer. > [tests/base.c:56] > 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:56] > 2024-04-15,20:11:37:ERRR: Tried to advance outside event buffer. > [tests/base.c:72] > 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:72] > [tests/base.c:112: EventBufferInvariant] > 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae008:11 != > 0x103ae008:10). [tests/base.c:87] > 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:87] > 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae008:9 != > 0x103ae008:10). [tests/base.c:91] > 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:91] > 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae009:10 != > 0x103ae008:10). [tests/base.c:95] > 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:95] > 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae007:10 != > 0x103ae008:10). [tests/base.c:99] > 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:99] > > For comparison,?I also send the parser from the NURDLIB version that Bastian > had set up for us. > > > > It would be really great if you could have a look into this. Most probably > this is the last issue that we are facing, before the DAQ is fine again. > > > > > Thank you very much! > > > > Best greetings > > G?nter > > > > > > > > From g.weber at hi-jena.gsi.de Tue Apr 16 18:55:29 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 16 Apr 2024 16:55:29 +0000 Subject: [subexp-daq] Question on DRASI and R3BFUSER Message-ID: <51ad3e0dad2a4969b6ef27b4d772da65@hi-jena.gsi.de> Dear friends, I have a question about the timestamp that can be created from the VULOM and/or the VETAR2 module. On the first system that we set up with the new software, we had the following command to start the DAQ: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/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 addition there is a file r3bfuser.cfg with a single entry: wr_id=0x200 Moreover, in the main.cfg we have the entry defining the VULOM functionality: GSI_VULOM(0x03000000) { timestamp = true # needed to get timestamps in the data output ecl=0..15 } As I understand, the entry in main.cfg is not enough to activate the VULOM timestamp, but need also the (a bit obsucre looking) entry in the r3bfuser.cfg, right? And both together result in the creation of an additional LMD subevent with hardcoded type=10 where the time stamp information is written. Is there a good reason why the VULOM timestamp (and also VETAR2 if available) is not simply written to the subevent defined in the command that starts DRASI? And why is the existence of the timestamp defined in two different files? To make the situation more puzzling (to us), in the second system that is now finally running again, we don't have a r3bfuser.cfg at all. Here the command to start the DAQ looks like this: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi \ --triva=master, at 0x02,fctime=10,ctime=300 \ --log-no-rate-limit \ --server=stream:8003 \ --server=drasi,dest=lyserv:7000 \ --buf=size=200Mi \ --max-ev-size=0x100000 \ --eb=lyserv:7000 \ --subev=crate=0,type=88,subtype=8800,control=0,procid=12 \ "$@" Is the "@0x02" in this command replacing the r3bfuser.cfg? If yes, 0x2 instead of 0x200 tells us that there is no timestamp, yes? Ok, so the bottom line is, that we basicly don't understand this timestamp thing :-) Could you give us a hint? Thank you so much! Best greetings G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.tornqvist at chalmers.se Wed Apr 17 09:47:55 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Wed, 17 Apr 2024 09:47:55 +0200 Subject: [subexp-daq] Question on DRASI and R3BFUSER In-Reply-To: <51ad3e0dad2a4969b6ef27b4d772da65@hi-jena.gsi.de> References: <51ad3e0dad2a4969b6ef27b4d772da65@hi-jena.gsi.de> Message-ID: <8d499e7d-d810-4bd8-9ef0-09f2009a2065@chalmers.se> Dear G?nter, On 2024-04-16 18:55, Weber, Guenter Dr. wrote: > Dear friends, > > ... > > In addition there is a file r3bfuser.cfg with a single entry: > > wr_id=0x200 > > Moreover, in the main.cfg we have the entry defining the VULOM > functionality: > > GSI_VULOM(0x03000000) { > timestamp = true # needed to get timestamps in the data output > ecl=0..15 > } > > As I understand, the entry in main.cfg is not enough to activate the > VULOM timestamp, but need also the (a bit obsucre looking) entry in the > r3bfuser.cfg, right? And both together result in the creation of an > additional LMD subevent with hardcoded?type=10 where the time stamp > information is written. > > Is there a good reason why the VULOM timestamp (and also VETAR2 if > available) is not simply written to the subevent defined in the command > that starts DRASI? And why is the existence of the timestamp defined in > two different files? I would love to find a way to clean this up, but the gist is: - nurdlib reads out and verifies module data and does not know how to present them to the outside world. - r3bfuser provides the glue between the nurdlib module data and the DAQ backend. This way nurdlib is not married to MBS or drasi and could be used by "any" such code. It will read e.g. timestamps from a vulom or vetar in single- or multi-even mode or whatever and dump that straight into an event buffer, no further processing done (well, timestamps must be saved in big-endian form). Nurdlib has no idea about how the DAQ backend needs the timestamp to be presented. The config in main.cfg for the trlo ii modules tells nurdlib that we expect and want to read out timestamps for every trigger, which is not something we always want from such a module. The vetar only delivers timestamps so that is not configurable. So, r3bfuser has to convert the raw data from nurdlib to something the backend understands. MBS/drasi expects a unique timestamp ID for every timestamped system which is what one sets in r3bfuser.cfg. The code then asks nurdlib for a timestamping module (I think there's a priority-selection, like try first vetar then vulom then tridi...), and for every event gets the region in the event buffer with the raw data from the module. It takes the first 64-bit number and creates the first 10/1 sub-event with the configured timestamp ID, error bits, the formatted timestamp etc. The behaviour of this part can be defined in many ways, which is why it's not done in the simple built-in f-user in nurdlib but confined to the external r3bfuser. I'm open to suggestions on how to simplify this without making the code sentient :) > To make the situation more puzzling (to us), in the second system that > is now finally running again, we don't have a r3bfuser.cfg at all. Here > the command to start the DAQ looks like this: > > ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi \ > --triva=master, at 0x02,fctime=10,ctime=300 \ > --log-no-rate-limit \ > --server=stream:8003 \ > --server=drasi,dest=lyserv:7000 \ > --buf=size=200Mi \ > --max-ev-size=0x100000 \ > --eb=lyserv:7000 \ > --subev=crate=0,type=88,subtype=8800,control=0,procid=12 \ > "$@" > > Is the "@0x02" in this command replacing the r3bfuser.cfg? If yes, 0x2 > instead of 0x200 tells us that there is no timestamp, yes? No, the @0x02 is the short-hand address for the trigger module (triva), and really means "address = 0x02 << 24 = 0x02000000". Drasi needs to know which module to talk to to know there are accepted triggers, to release deadtime etc. Best regards, Hans > Ok, so the bottom line is, that we basicly?don't understand this > timestamp thing :-) > > Could you give us a hint? > > Thank you so much! > > Best greetings > > G?nter > > > > > From f96hajo at chalmers.se Wed Apr 17 10:16:41 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Wed, 17 Apr 2024 10:16:41 +0200 Subject: [subexp-daq] Question on DRASI and R3BFUSER In-Reply-To: <8d499e7d-d810-4bd8-9ef0-09f2009a2065@chalmers.se> References: <51ad3e0dad2a4969b6ef27b4d772da65@hi-jena.gsi.de> <8d499e7d-d810-4bd8-9ef0-09f2009a2065@chalmers.se> Message-ID: <96786e01-89d4-f94d-2b8a-4c7d487f44c4@chalmers.se> On Wed, 17 Apr 2024, Hans Toshihide T?rnqvist wrote: > I would love to find a way to clean this up, but the gist is: > > - nurdlib reads out and verifies module data and does not know how to > present them to the outside world. > > - r3bfuser provides the glue between the nurdlib module data and the DAQ > backend. > > This way nurdlib is not married to MBS or drasi and could be used by > "any" such code. It will read e.g. timestamps from a vulom or vetar in > single- or multi-even mode or whatever and dump that straight into an > event buffer, no further processing done (well, timestamps must be saved > in big-endian form). Nurdlib has no idea about how the DAQ backend needs > the timestamp to be presented. The config in main.cfg for the trlo ii > modules tells nurdlib that we expect and want to read out timestamps for > every trigger, which is not something we always want from such a module. > The vetar only delivers timestamps so that is not configurable. > > So, r3bfuser has to convert the raw data from nurdlib to something the > backend understands. MBS/drasi expects a unique timestamp ID for every > timestamped system which is what one sets in r3bfuser.cfg. The code then > asks nurdlib for a timestamping module (I think there's a > priority-selection, like try first vetar then vulom then tridi...), I think a scary part here is that r3bfuser auto-finds a module to provide the time. It would perhaps be possible to encourage to user to specify which (kind of) source (vetar, vulom, tridi...) one would like to use for the special formatting into the DAQ-readable location, and if not available, it errors out. There could also be an option 'auto' for the lazy, who then get to keep both pieces when it breaks (or rather - be confused as to which timestamp source is used). > and > for every event gets the region in the event buffer with the raw data > from the module. It takes the first 64-bit number and creates the first > 10/1 sub-event with the configured timestamp ID, This is the 'wr_id' specified in the r3bfuser.cfg. > error bits, the > formatted timestamp etc. The behaviour of this part can be defined in > many ways, which is why it's not done in the simple built-in f-user in > nurdlib but confined to the external r3bfuser. > > I'm open to suggestions on how to simplify this without making the code > sentient :) > >> To make the situation more puzzling (to us), in the second system that >> is now finally running again, we don't have a r3bfuser.cfg at all. Here >> the command to start the DAQ looks like this: >> >> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi \ >> --triva=master, at 0x02,fctime=10,ctime=300 \ >> --log-no-rate-limit \ >> --server=stream:8003 \ >> --server=drasi,dest=lyserv:7000 \ >> --buf=size=200Mi \ >> --max-ev-size=0x100000 \ >> --eb=lyserv:7000 \ >> --subev=crate=0,type=88,subtype=8800,control=0,procid=12 \ >> "$@" >> >> Is the "@0x02" in this command replacing the r3bfuser.cfg? If yes, 0x2 >> instead of 0x200 tells us that there is no timestamp, yes? > > No, the @0x02 is the short-hand address for the trigger module (triva), > and really means "address = 0x02 << 24 = 0x02000000". Drasi needs to > know which module to talk to to know there are accepted triggers, to > release deadtime etc. > > Best regards, > Hans Cheers, H?kan > >> Ok, so the bottom line is, that we basicly?don't understand this >> timestamp thing :-) >> >> Could you give us a hint? >> >> Thank you so much! >> >> Best greetings >> >> G?nter >> >> >> >> >> > -- > 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 Apr 17 11:05:24 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Wed, 17 Apr 2024 09:05:24 +0000 Subject: [subexp-daq] Question on DRASI and R3BFUSER In-Reply-To: <96786e01-89d4-f94d-2b8a-4c7d487f44c4@chalmers.se> References: <51ad3e0dad2a4969b6ef27b4d772da65@hi-jena.gsi.de> <8d499e7d-d810-4bd8-9ef0-09f2009a2065@chalmers.se>, <96786e01-89d4-f94d-2b8a-4c7d487f44c4@chalmers.se> Message-ID: <812243d0af9e44aa9486a6e7a1be0b78@hi-jena.gsi.de> Dear Hans and H?kan, thank you very much for the detailed explanation. Now I have two remaining questions: 1) To tell the second DAQ system to also put a timestamp in the output LMD data, we would need to create r3bfuser.cfg with the wr_id entry, right? (I am surprised that r3bfuser.cfg does not need to exist. I imagine a user getting crazy over changes made in his r3dfuser.cfg not having any effect on the DAQ, before realizing that there is a typo in the filename.) And then also tell the VULOM in main.cfg to produce the timestamp (i.e. basicly copy the settings from the first DAQ system). 2a) Why does in our first DAQ system the address of the TRIVA not need to be set? --triva=master,fctime=10,ctime=50 \ versus --triva=master, at 0x02,fctime=10,ctime=300 \ 2b) What are fctime (fast clear time) and ctime (conversion time) actually doing? Thanks a lot! Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Mittwoch, 17. April 2024 10:16:41 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Cc: Weber, Guenter Dr. Betreff: Re: [subexp-daq] Question on DRASI and R3BFUSER On Wed, 17 Apr 2024, Hans Toshihide T?rnqvist wrote: > I would love to find a way to clean this up, but the gist is: > > - nurdlib reads out and verifies module data and does not know how to > present them to the outside world. > > - r3bfuser provides the glue between the nurdlib module data and the DAQ > backend. > > This way nurdlib is not married to MBS or drasi and could be used by > "any" such code. It will read e.g. timestamps from a vulom or vetar in > single- or multi-even mode or whatever and dump that straight into an > event buffer, no further processing done (well, timestamps must be saved > in big-endian form). Nurdlib has no idea about how the DAQ backend needs > the timestamp to be presented. The config in main.cfg for the trlo ii > modules tells nurdlib that we expect and want to read out timestamps for > every trigger, which is not something we always want from such a module. > The vetar only delivers timestamps so that is not configurable. > > So, r3bfuser has to convert the raw data from nurdlib to something the > backend understands. MBS/drasi expects a unique timestamp ID for every > timestamped system which is what one sets in r3bfuser.cfg. The code then > asks nurdlib for a timestamping module (I think there's a > priority-selection, like try first vetar then vulom then tridi...), I think a scary part here is that r3bfuser auto-finds a module to provide the time. It would perhaps be possible to encourage to user to specify which (kind of) source (vetar, vulom, tridi...) one would like to use for the special formatting into the DAQ-readable location, and if not available, it errors out. There could also be an option 'auto' for the lazy, who then get to keep both pieces when it breaks (or rather - be confused as to which timestamp source is used). > and > for every event gets the region in the event buffer with the raw data > from the module. It takes the first 64-bit number and creates the first > 10/1 sub-event with the configured timestamp ID, This is the 'wr_id' specified in the r3bfuser.cfg. > error bits, the > formatted timestamp etc. The behaviour of this part can be defined in > many ways, which is why it's not done in the simple built-in f-user in > nurdlib but confined to the external r3bfuser. > > I'm open to suggestions on how to simplify this without making the code > sentient :) > >> To make the situation more puzzling (to us), in the second system that >> is now finally running again, we don't have a r3bfuser.cfg at all. Here >> the command to start the DAQ looks like this: >> >> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi \ >> --triva=master, at 0x02,fctime=10,ctime=300 \ >> --log-no-rate-limit \ >> --server=stream:8003 \ >> --server=drasi,dest=lyserv:7000 \ >> --buf=size=200Mi \ >> --max-ev-size=0x100000 \ >> --eb=lyserv:7000 \ >> --subev=crate=0,type=88,subtype=8800,control=0,procid=12 \ >> "$@" >> >> Is the "@0x02" in this command replacing the r3bfuser.cfg? If yes, 0x2 >> instead of 0x200 tells us that there is no timestamp, yes? > > No, the @0x02 is the short-hand address for the trigger module (triva), > and really means "address = 0x02 << 24 = 0x02000000". Drasi needs to > know which module to talk to to know there are accepted triggers, to > release deadtime etc. > > Best regards, > Hans Cheers, H?kan > >> Ok, so the bottom line is, that we basicly don't understand this >> timestamp thing :-) >> >> Could you give us a hint? >> >> Thank you so 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 Wed Apr 17 11:21:27 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Wed, 17 Apr 2024 11:21:27 +0200 Subject: [subexp-daq] Question on DRASI and R3BFUSER In-Reply-To: <812243d0af9e44aa9486a6e7a1be0b78@hi-jena.gsi.de> References: <51ad3e0dad2a4969b6ef27b4d772da65@hi-jena.gsi.de> <8d499e7d-d810-4bd8-9ef0-09f2009a2065@chalmers.se>, <96786e01-89d4-f94d-2b8a-4c7d487f44c4@chalmers.se> <812243d0af9e44aa9486a6e7a1be0b78@hi-jena.gsi.de> Message-ID: On Wed, 17 Apr 2024, Weber, Guenter Dr. wrote: > > Dear Hans and H?kan, 1) Left for Hans :-) > 2a) Why does in our first DAQ system the address of the TRIVA not need to be > set? > > > --triva=master,fctime=10,ctime=50 \ > > > versus > > > --triva=master, at 0x02,fctime=10,ctime=300 \ 0x2 is the default address. Just updated --triva=help to reflect that. > 2b) What are fctime (fast clear time) and ctime (conversion time) actually > doing? The conversion time is the time between the triva gets the actual trigger signal until it tells the VME side that an event is ready. Either by VME interupt, or by having the flag set in the status word (read via VME): The fast clear time is the acceptance time for a fast clear (i.e. a revoked trigger). I never used that. Details: https://www.gsi.de/fileadmin/EE/Module/TRIVA/triva7_1.pdf Cheers, H?kan From hans.tornqvist at chalmers.se Wed Apr 17 13:59:08 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Wed, 17 Apr 2024 13:59:08 +0200 Subject: [subexp-daq] Question on DRASI and R3BFUSER In-Reply-To: <812243d0af9e44aa9486a6e7a1be0b78@hi-jena.gsi.de> References: <51ad3e0dad2a4969b6ef27b4d772da65@hi-jena.gsi.de> <8d499e7d-d810-4bd8-9ef0-09f2009a2065@chalmers.se> <96786e01-89d4-f94d-2b8a-4c7d487f44c4@chalmers.se> <812243d0af9e44aa9486a6e7a1be0b78@hi-jena.gsi.de> Message-ID: On 2024-04-17 11:05, Weber, Guenter Dr. wrote: > Dear Hans and H?kan, > > thank you very much for the detailed explanation. Now I have two > remaining questions: > > 1) To tell the second DAQ system to also put a timestamp in the output > LMD data, we would need to create r3bfuser.cfg with the wr_id entry, right? Yes, with another number! > (I am surprised that r3bfuser.cfg does not need to exist. I imagine a > user getting crazy over changes made in his r3dfuser.cfg not having any > effect on the DAQ, before realizing that there is a typo in the filename.) There's also the possibility that the wrong r3bfuser.cfg is being edited, or that r3dfuser.cfg is edited next to the real r3bfuser.cfg. In my experience over many use-cases the best approach is discipline and checking the data. And avoiding stressful situations with people breathing over your shoulder :) > And then also tell the VULOM in main.cfg to produce the timestamp (i.e. > basicly copy the settings from the first DAQ system). Yes. Cheers, Hans From g.weber at hi-jena.gsi.de Wed Apr 17 14:49:40 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Wed, 17 Apr 2024 12:49:40 +0000 Subject: [subexp-daq] NURDLIB - Problem in parser of caen_v1n90 In-Reply-To: <7d2738d5-63e5-01c6-0979-1a08e77784bb@chalmers.se> References: <4384b9515b76421b881cef0127933b1f@hi-jena.gsi.de>, <7d2738d5-63e5-01c6-0979-1a08e77784bb@chalmers.se> Message-ID: Dear friends, I just pushed a fixed version of the CAEN V1n90 to Gitlab. Please note that in the parser I had to comment out a check if the number of TDC words in the TDC trailer is equal to the number of words corresponding to this TDC that were actually read by the parser. Otherwise the automatic testing during NURDLIB compilation fails. Thus, to implement this check, the test data needs to be reworked to actually match the structure of the data from the real module. See around page 70 in the manual of the V1190 module. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Dienstag, 16. April 2024 16:52:55 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] NURDLIB - Problem in parser of caen_v1n90 Dear G?nter, if you are able to push to the master branch, we actually have a configuration problem. But also we do not push to the (remote) master branch of each other's projects. But in any case, please do not. It is easy to push to a branch with another name: git push : e.g. git push origin master:fixes-of-something ... Or you can just creat a new local branch name first git branch git checkout and the do a git push origin Cheers, H?kan On Tue, 16 Apr 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > we have (most probably fixed) the issue by modifying the parser a bit. See > attachment. > > > Unfortunately, before doing the changes, I did not open a new branch. Am I > allowed to commit our changes to the master branch? Or do you want to > implement the new parser (if you think it is fine this way)? > > > > > Best greetings > > G?nter > > ____________________________________________________________________________ > Von: Weber, Guenter Dr. > Gesendet: Dienstag, 16. April 2024 07:11:32 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: NURDLIB - Problem in parser of caen_v1n90 > > Dear friends, > > > yesterday I managed to get the DAQ starting (using the updated software and > howto instructions). However, the readout of the TDC module V1190A failed: > > > 2024-04-15 14:29:36.979260 i RIO4L-2/MAIN crate_init(POLARIMETER) } > +0200 CEST :f_user.c:1257: > 2024-04-15 14:29:36.979280 E RIO4L-2/MAIN had readout error, ret=0x2, > trigger=1, prev=1 > +0200 CEST :module/caen_v1n90/caen_v1n90.c:651: > 2024-04-15 14:29:36.979684 E RIO4L-2/MAIN Trailer corrupt > (ofs=0x00000010,u8[4]=0x0900032f). > +0200 CEST :crate/crate.c:2074: > 2024-04-15 14:29:36.979712 E RIO4L-2/MAIN POLARIMETER[3]=CAEN_V1190 > parse error=0x00000002, dumping data: > +0200 CEST :crate/crate.c:2083: > 2024-04-15 14:29:36.979724 i RIO4L-2/MAIN ---[ Dump begin ]--- > +0200 CEST :crate/crate.c:2083: > 2024-04-15 14:29:36.979734 i RIO4L-2/MAIN Start=0x3005ef08 > Bytes=44=0x2c > +0200 CEST :crate/crate.c:2083: > 2024-04-15 14:29:36.979755 i RIO4L-2/MAIN 0: 40000003 0800032f > 00702106 18000003 0900032f 19000002 0a00032f 1a000002 > +0200 CEST :crate/crate.c:2083: > 2024-04-15 14:29:36.979770 i RIO4L-2/MAIN 20: 0b00032f 1b000002 > 80000163 > +0200 CEST :crate/crate.c:2083: > 2024-04-15 14:29:36.979780 i RIO4L-2/MAIN ---[ Dump end ]--- > +0200 CEST :crate/crate.c:1554: > 2024-04-15 14:29:36.979810 E RIO4L-2/MAIN POLARIMETER: readout failed! > +0200 CEST :crate/crate.c:1598: > 2024-04-15 14:29:36.979823 E RIO4L-2/MAIN POLARIMETER: had problems, > re-initializing. > > > To us it looks like the parser does not account for the fact that the module > contains several individual TDC units which each will produce a TDC header > plus payload. And only after all TDC units were readout, finally the trailer > will appear. > > > (As I can see, the 1n90 series ranges from 16 channels to 128 channels with > the high channel number modules having several individual TDC units. Maybe, > this whole issue was overlooked when writing the parser code?) > > > In the attachment, I send a modified version of the parser where for testing > purposes it is assumed that the module has four TDC units (as should be the > case for our module). Compilation of this code works, but it fails in the > unit test with the following errors: > > > make: Warning: File > `build_cc_ppc-linux_4.2.2_debug/module/caen_v1n90/caen_v1n90.d' has > modification time 45 s in the future > CC build_cc_ppc-linux_4.2.2_debug/module/caen_v1n90/caen_v1n90.o > LD build_cc_ppc-linux_4.2.2_debug/test > TEST build_cc_ppc-linux_4.2.2_debug/test_ok > [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-04-15,20:11:37:ERRR: Invalid pointer to advance event buffer. > [tests/base.c:47] > 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:47] > 2024-04-15,20:11:37:ERRR: Invalid pointer to advance event buffer. > [tests/base.c:56] > 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:56] > 2024-04-15,20:11:37:ERRR: Tried to advance outside event buffer. > [tests/base.c:72] > 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:72] > [tests/base.c:112: EventBufferInvariant] > 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae008:11 != > 0x103ae008:10). [tests/base.c:87] > 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:87] > 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae008:9 != > 0x103ae008:10). [tests/base.c:91] > 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:91] > 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae009:10 != > 0x103ae008:10). [tests/base.c:95] > 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:95] > 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae007:10 != > 0x103ae008:10). [tests/base.c:99] > 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:99] > > For comparison, I also send the parser from the NURDLIB version that Bastian > had set up for us. > > > > It would be really great if you could have a look into this. Most probably > this is the last issue that we are facing, before the DAQ is fine again. > > > > > Thank you very much! > > > > Best greetings > > G?nter > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.weber at hi-jena.gsi.de Wed Apr 17 22:41:02 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Wed, 17 Apr 2024 20:41:02 +0000 Subject: [subexp-daq] NURDLIB - Problem in parser of caen_v1n90 In-Reply-To: References: <4384b9515b76421b881cef0127933b1f@hi-jena.gsi.de>, <7d2738d5-63e5-01c6-0979-1a08e77784bb@chalmers.se>, Message-ID: <4d0517c5b62b48c781daad9d05883efe@hi-jena.gsi.de> P.S. We learned that also in UCESB/SPEC the vme_caen_v1290.spec file needs a small modification. The "Extended Trigger Time Tag" is optional (see around page 70 of the manual) and is not present with the standard settings of the module. Thus at lines 128 and 222 the "optional" should be used: optional UINT32 trigger With this final modification, the second DAQ system is working as expected. Let's see if I can set up our third DAQ system on my own now ? Many thanks again for your help! Best greetings G?nter ________________________________ Von: Weber, Guenter Dr. Gesendet: Mittwoch, 17. April 2024 14:49:40 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: AW: [subexp-daq] NURDLIB - Problem in parser of caen_v1n90 Dear friends, I just pushed a fixed version of the CAEN V1n90 to Gitlab. Please note that in the parser I had to comment out a check if the number of TDC words in the TDC trailer is equal to the number of words corresponding to this TDC that were actually read by the parser. Otherwise the automatic testing during NURDLIB compilation fails. Thus, to implement this check, the test data needs to be reworked to actually match the structure of the data from the real module. See around page 70 in the manual of the V1190 module. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Dienstag, 16. April 2024 16:52:55 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] NURDLIB - Problem in parser of caen_v1n90 Dear G?nter, if you are able to push to the master branch, we actually have a configuration problem. But also we do not push to the (remote) master branch of each other's projects. But in any case, please do not. It is easy to push to a branch with another name: git push : e.g. git push origin master:fixes-of-something ... Or you can just creat a new local branch name first git branch git checkout and the do a git push origin Cheers, H?kan On Tue, 16 Apr 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > we have (most probably fixed) the issue by modifying the parser a bit. See > attachment. > > > Unfortunately, before doing the changes, I did not open a new branch. Am I > allowed to commit our changes to the master branch? Or do you want to > implement the new parser (if you think it is fine this way)? > > > > > Best greetings > > G?nter > > ____________________________________________________________________________ > Von: Weber, Guenter Dr. > Gesendet: Dienstag, 16. April 2024 07:11:32 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: NURDLIB - Problem in parser of caen_v1n90 > > Dear friends, > > > yesterday I managed to get the DAQ starting (using the updated software and > howto instructions). However, the readout of the TDC module V1190A failed: > > > 2024-04-15 14:29:36.979260 i RIO4L-2/MAIN crate_init(POLARIMETER) } > +0200 CEST :f_user.c:1257: > 2024-04-15 14:29:36.979280 E RIO4L-2/MAIN had readout error, ret=0x2, > trigger=1, prev=1 > +0200 CEST :module/caen_v1n90/caen_v1n90.c:651: > 2024-04-15 14:29:36.979684 E RIO4L-2/MAIN Trailer corrupt > (ofs=0x00000010,u8[4]=0x0900032f). > +0200 CEST :crate/crate.c:2074: > 2024-04-15 14:29:36.979712 E RIO4L-2/MAIN POLARIMETER[3]=CAEN_V1190 > parse error=0x00000002, dumping data: > +0200 CEST :crate/crate.c:2083: > 2024-04-15 14:29:36.979724 i RIO4L-2/MAIN ---[ Dump begin ]--- > +0200 CEST :crate/crate.c:2083: > 2024-04-15 14:29:36.979734 i RIO4L-2/MAIN Start=0x3005ef08 > Bytes=44=0x2c > +0200 CEST :crate/crate.c:2083: > 2024-04-15 14:29:36.979755 i RIO4L-2/MAIN 0: 40000003 0800032f > 00702106 18000003 0900032f 19000002 0a00032f 1a000002 > +0200 CEST :crate/crate.c:2083: > 2024-04-15 14:29:36.979770 i RIO4L-2/MAIN 20: 0b00032f 1b000002 > 80000163 > +0200 CEST :crate/crate.c:2083: > 2024-04-15 14:29:36.979780 i RIO4L-2/MAIN ---[ Dump end ]--- > +0200 CEST :crate/crate.c:1554: > 2024-04-15 14:29:36.979810 E RIO4L-2/MAIN POLARIMETER: readout failed! > +0200 CEST :crate/crate.c:1598: > 2024-04-15 14:29:36.979823 E RIO4L-2/MAIN POLARIMETER: had problems, > re-initializing. > > > To us it looks like the parser does not account for the fact that the module > contains several individual TDC units which each will produce a TDC header > plus payload. And only after all TDC units were readout, finally the trailer > will appear. > > > (As I can see, the 1n90 series ranges from 16 channels to 128 channels with > the high channel number modules having several individual TDC units. Maybe, > this whole issue was overlooked when writing the parser code?) > > > In the attachment, I send a modified version of the parser where for testing > purposes it is assumed that the module has four TDC units (as should be the > case for our module). Compilation of this code works, but it fails in the > unit test with the following errors: > > > make: Warning: File > `build_cc_ppc-linux_4.2.2_debug/module/caen_v1n90/caen_v1n90.d' has > modification time 45 s in the future > CC build_cc_ppc-linux_4.2.2_debug/module/caen_v1n90/caen_v1n90.o > LD build_cc_ppc-linux_4.2.2_debug/test > TEST build_cc_ppc-linux_4.2.2_debug/test_ok > [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-04-15,20:11:37:ERRR: Invalid pointer to advance event buffer. > [tests/base.c:47] > 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:47] > 2024-04-15,20:11:37:ERRR: Invalid pointer to advance event buffer. > [tests/base.c:56] > 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:56] > 2024-04-15,20:11:37:ERRR: Tried to advance outside event buffer. > [tests/base.c:72] > 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:72] > [tests/base.c:112: EventBufferInvariant] > 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae008:11 != > 0x103ae008:10). [tests/base.c:87] > 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:87] > 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae008:9 != > 0x103ae008:10). [tests/base.c:91] > 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:91] > 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae009:10 != > 0x103ae008:10). [tests/base.c:95] > 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:95] > 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae007:10 != > 0x103ae008:10). [tests/base.c:99] > 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:99] > > For comparison, I also send the parser from the NURDLIB version that Bastian > had set up for us. > > > > It would be really great if you could have a look into this. Most probably > this is the last issue that we are facing, before the DAQ is fine again. > > > > > Thank you very much! > > > > Best greetings > > G?nter > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Wed Apr 17 23:23:15 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Wed, 17 Apr 2024 23:23:15 +0200 Subject: [subexp-daq] NURDLIB - Problem in parser of caen_v1n90 In-Reply-To: <4d0517c5b62b48c781daad9d05883efe@hi-jena.gsi.de> References: <4384b9515b76421b881cef0127933b1f@hi-jena.gsi.de>, <7d2738d5-63e5-01c6-0979-1a08e77784bb@chalmers.se>, <4d0517c5b62b48c781daad9d05883efe@hi-jena.gsi.de> Message-ID: <0da5b4df-5069-c11b-f271-475bd1c1c4d4@chalmers.se> vme_caen_v1290.spec updated. Thanks! H?kan On Wed, 17 Apr 2024, Weber, Guenter Dr. wrote: > > P.S. > > > We learned that also in UCESB/SPEC the vme_caen_v1290.spec file needs a > small modification. > > > The "Extended Trigger Time Tag" is optional (see around page 70 of the > manual)?and is?not present with the standard settings of the module. Thus at > lines 128 and 222 the "optional" should be used: > > > optional UINT32 trigger From g.weber at hi-jena.gsi.de Thu Apr 18 13:49:35 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Thu, 18 Apr 2024 11:49:35 +0000 Subject: [subexp-daq] Question on JSON output from UCESB: handling of DATA12_OVERFLOW Message-ID: Dear friends, were found some unexpected (at least to us) behaviour when looking at the JSON output from UCESB. We are using the following command to generate the JSON outout: ../../ucesb/jena_polarimeter/jena_polarimeter stream://localhost:8003 --ntuple=UNPACK,STRUCT,- | ../../ucesb/hbook/struct_writer - --dump=compact_json In our DAQ, there are sitting CAEN V785 modules. The *.spec file for these modules looks like this: #define VME_CAEN_V792 VME_CAEN_V775 #define VME_CAEN_V785 VME_CAEN_V775 VME_CAEN_V775(geom, crate) { MEMBER(DATA12_OVERFLOW data[32] ZERO_SUPPRESS); UINT32 header NOENCODE { // 0_7: undefined; 8_13: count; 16_23: crate = MATCH(crate); 24_26: 0b010; 27_31: geom = MATCH(geom); } list(0<=index From f96hajo at chalmers.se Thu Apr 18 13:59:00 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Thu, 18 Apr 2024 13:59:00 +0200 Subject: [subexp-daq] Question on JSON output from UCESB: handling of DATA12_OVERFLOW In-Reply-To: References: Message-ID: <2f82951d-ce01-c0af-fa9f-17ff49b78852@chalmers.se> Dear G?nter, yes, the DATA12_OVERFLOW is stored as rawdata12 (see eventloop/raw_data.hh) which has the overflow mark in the highest bit (0x8000). The value is in the usual bits. Cheers, H?kan On Thu, 18 Apr 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > were found some unexpected (at least to us) behaviour when looking at the > JSON output from UCESB. > > > We are using the following command to generate the JSON outout: > > > ../../ucesb/jena_polarimeter/jena_polarimeter stream://localhost:8003 > --ntuple=UNPACK,STRUCT,- | ../../ucesb/hbook/struct_writer - > --dump=compact_json > > In our DAQ, there are sitting CAEN V785 modules. The *.spec file for these > modules looks like this: > > > #define VME_CAEN_V792 VME_CAEN_V775 > #define VME_CAEN_V785 VME_CAEN_V775 > > VME_CAEN_V775(geom, > ?? ?????? crate) > { > ? MEMBER(DATA12_OVERFLOW data[32] ZERO_SUPPRESS); > > ? UINT32 header NOENCODE > ??? { > ????? // 0_7: undefined; > ????? 8_13:? count; > ????? 16_23: crate = MATCH(crate); > ????? 24_26: 0b010; > ????? 27_31: geom = MATCH(geom); > ??? } > > ? list(0<=index ??? { > ????? UINT32 ch_data NOENCODE > ?? ?{ > ?? ?? 0_11:? value; > > ?? ?? 12:??? overflow; > ?? ?? 13:??? underflow; > ?? ?? 14:??? valid; > > ?? ?? // 15: undefined; > > ?? ?? 16_20: channel; > > ?? ?? 24_26: 0b000; > ?? ?? 27_31: geom = CHECK(geom); > > ?? ?? ENCODE(data[channel],(value=value,overflow=overflow)); > ?? ?} > ??? } > > ? UINT32 eob > ??? { > ????? 0_23:? event_number; > ????? 24_26: 0b100; > ????? 27_31: geom = CHECK(geom); > ????? // NOENCODE; > ??? } > } > > Now comes the strange part: from time to time we get values greater than > 2^12 in the arrays belonging to the 12-bit ADC data (the values are than > usually in the 36xxx ballpark). We assume that these are the overflow events > and for some reason they are translated to values of 2^15 + something in the > JSON output data. > > > Is our interprtation correct and if yes, is this intended behaviour? > > > > > Many thanks! > > > > > Best greetings > > G?nter > > > > > > From g.weber at hi-jena.gsi.de Fri Apr 19 11:03:45 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Fri, 19 Apr 2024 09:03:45 +0000 Subject: [subexp-daq] Question: what is GEOM? Message-ID: Dear friends, in my DAQ, I have three modules that are defined in main.cfg as follows: # ADCs CAEN_V785(0x11110000) { threshold = (0 {32}) } CAEN_V785(0x44440000) { threshold = (0 {32}) } # TDC BARRIER CAEN_V1190(0x22220000) { blt_mode = noblt edge = leading resolution = 100 ps deadtime = 5 ns # with 100 ps resolution, max window size: 50 us GATE { time_after_trigger = -1us width = 2us } } In the corresponding *.spec file, the data is matched via this commands: adc[0] = VME_CAEN_V785(geom=1, crate=0); adc[1] = VME_CAEN_V785(geom=2, crate=0); b2 = BARRIER(); tdc = VME_CAEN_V1190(geom=3); My question is now, where is the GEOM number coming from? How do the modules 'know' that they should have GEOM numbers 1 to 3? Thank you very much! Best greetings G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Fri Apr 19 12:07:59 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Fri, 19 Apr 2024 12:07:59 +0200 Subject: [subexp-daq] Question: what is GEOM? In-Reply-To: References: Message-ID: Dear G?nter, I think nurdlib will assign the geom numbers (for modules which have that kind of identifier settable) in order for the modules that are configured. Unless not already implemented, it might be on Hans todo-list to be able to override that default, i.e. manually specify the module identifier that appears in the data. That would be useful such that an unpacker can be used unchanged even if some detector/module is not present for some runs / experiments. Cheers, H?kan On Fri, 19 Apr 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > in my DAQ, I have three modules that are defined in main.cfg as follows: > > > ? ? # ADCs > ? ? CAEN_V785(0x11110000) { > ? ? ? ? threshold = (0 {32}) > ? ? } > ? ? CAEN_V785(0x44440000) { > ? ? ? ? threshold = (0 {32}) > ? ? } > ? ? # TDC > ? ? BARRIER > ? ? CAEN_V1190(0x22220000) { > ? ? ? ? ? ?blt_mode = noblt > ? ? ? ? ? ?edge = leading > ? ? ? ? ? ?resolution = 100 ps > ? ? ? ? ? ?deadtime = 5 ns > ? ? ? ? # with 100 ps resolution, max window size: 50 us > ? ? ? ? ? ?GATE { > ? ? ? ? ? ? time_after_trigger = -1us > ? ? ? ? ? ? width = 2us > ? ? ? ? ? ?} > ? ? } > > In the corresponding *.spec file, the data is matched via this commands: > > > ??? adc[0] = VME_CAEN_V785(geom=1, crate=0); > ?? ?adc[1] = VME_CAEN_V785(geom=2, crate=0); > ?? ?b2 = BARRIER(); > ?? ?tdc = VME_CAEN_V1190(geom=3); > > My question is now, where is the GEOM number coming from? How do the modules > 'know' that they should have GEOM numbers 1 to 3? > > > > Thank you very much! > > > > Best greetings > G?nter > > > > From hans.tornqvist at chalmers.se Mon Apr 22 16:12:56 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Mon, 22 Apr 2024 16:12:56 +0200 Subject: [subexp-daq] Question: what is GEOM? In-Reply-To: References: Message-ID: <0c8fd98d-7c9b-4bd8-8a19-665cf55e36b1@chalmers.se> Dear G?nter, To add to H?kan's response, some Caen modules (maybe others?) can assign its geom via the middle PAUX connector if that's available. I think there's a config to make nurdlib aware that the module will have an externally assigned geom number, but maybe also via a flag in a status register. These are checked against the automatically assigned geom's, so the step to overriding is not very big. Mostly fyi :) Cheers, Hans On 2024-04-19 12:07, H?kan T Johansson wrote: > > Dear G?nter, > > I think nurdlib will assign the geom numbers (for modules which have > that kind of identifier settable) in order for the modules that are > configured. > > Unless not already implemented, it might be on Hans todo-list to be able > to override that default, i.e. manually specify the module identifier > that appears in the data.? That would be useful such that an unpacker > can be used unchanged even if some detector/module is not present for > some runs / experiments. > > Cheers, > H?kan > > > > On Fri, 19 Apr 2024, Weber, Guenter Dr. wrote: > >> >> Dear friends, >> >> >> in my DAQ, I have three modules that are defined in main.cfg as follows: >> >> >> ? ? # ADCs >> ? ? CAEN_V785(0x11110000) { >> ? ? ? ? threshold = (0 {32}) >> ? ? } >> ? ? CAEN_V785(0x44440000) { >> ? ? ? ? threshold = (0 {32}) >> ? ? } >> ? ? # TDC >> ? ? BARRIER >> ? ? CAEN_V1190(0x22220000) { >> ? ? ? ? ? ?blt_mode = noblt >> ? ? ? ? ? ?edge = leading >> ? ? ? ? ? ?resolution = 100 ps >> ? ? ? ? ? ?deadtime = 5 ns >> ? ? ? ? # with 100 ps resolution, max window size: 50 us >> ? ? ? ? ? ?GATE { >> ? ? ? ? ? ? time_after_trigger = -1us >> ? ? ? ? ? ? width = 2us >> ? ? ? ? ? ?} >> ? ? } >> >> In the corresponding *.spec file, the data is matched via this commands: >> >> >> ??? adc[0] = VME_CAEN_V785(geom=1, crate=0); >> ?? ?adc[1] = VME_CAEN_V785(geom=2, crate=0); >> ?? ?b2 = BARRIER(); >> ?? ?tdc = VME_CAEN_V1190(geom=3); >> >> My question is now, where is the GEOM number coming from? How do the >> modules >> 'know' that they should have GEOM numbers 1 to 3? >> >> >> >> Thank you very much! >> >> >> >> Best greetings >> G?nter >> >> >> >> > From g.weber at hi-jena.gsi.de Mon Apr 22 16:40:51 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Mon, 22 Apr 2024 14:40:51 +0000 Subject: [subexp-daq] Question: what is GEOM? In-Reply-To: <0c8fd98d-7c9b-4bd8-8a19-665cf55e36b1@chalmers.se> References: , <0c8fd98d-7c9b-4bd8-8a19-665cf55e36b1@chalmers.se> Message-ID: <1bb7151d8acf4b8b9e24f4ffb854f008@hi-jena.gsi.de> Dear Hans, dear H?kan, thank you for the explanations. Maybe my questions don't make much sense as I have not correctly understood the concept of this GEO number. As I see it, the DAQ software is (automaticly) assigning a GEO number to (some of?) the modules that is then readout from the module again by the same DAQ. We then need to know this number to configure the matching procedure in the *.spec file. And just by guessing and looking what Bastian provided us, we assumed that this number is assigned according to the order that the modules appear in the main.cfg file. I get that it is nice to have a unique number for each module to make sure that if there are many, you are always looking at the right one. So, is the GEO number just a way to avoid identifying the modules by tthe lengthy address that is set using the rotary switches (which also should be unique for each crate, right?)? If possible and not already implemented, I think it would be really good to have the option to set a GEO number in main.cfg for each module. This would avoid having to deal with new GEO numbers for everything once modules are added or removed (as H?kan already mentioned). But maybe I simply do not understand yet, how this GEO thing actually works ? Many thanks and best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von Hans Toshihide T?rnqvist Gesendet: Montag, 22. April 2024 16:12:56 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.; H?kan T Johansson Betreff: Re: [subexp-daq] Question: what is GEOM? Dear G?nter, To add to H?kan's response, some Caen modules (maybe others?) can assign its geom via the middle PAUX connector if that's available. I think there's a config to make nurdlib aware that the module will have an externally assigned geom number, but maybe also via a flag in a status register. These are checked against the automatically assigned geom's, so the step to overriding is not very big. Mostly fyi :) Cheers, Hans On 2024-04-19 12:07, H?kan T Johansson wrote: > > Dear G?nter, > > I think nurdlib will assign the geom numbers (for modules which have > that kind of identifier settable) in order for the modules that are > configured. > > Unless not already implemented, it might be on Hans todo-list to be able > to override that default, i.e. manually specify the module identifier > that appears in the data. That would be useful such that an unpacker > can be used unchanged even if some detector/module is not present for > some runs / experiments. > > Cheers, > H?kan > > > > On Fri, 19 Apr 2024, Weber, Guenter Dr. wrote: > >> >> Dear friends, >> >> >> in my DAQ, I have three modules that are defined in main.cfg as follows: >> >> >> # ADCs >> CAEN_V785(0x11110000) { >> threshold = (0 {32}) >> } >> CAEN_V785(0x44440000) { >> threshold = (0 {32}) >> } >> # TDC >> BARRIER >> CAEN_V1190(0x22220000) { >> blt_mode = noblt >> edge = leading >> resolution = 100 ps >> deadtime = 5 ns >> # with 100 ps resolution, max window size: 50 us >> GATE { >> time_after_trigger = -1us >> width = 2us >> } >> } >> >> In the corresponding *.spec file, the data is matched via this commands: >> >> >> adc[0] = VME_CAEN_V785(geom=1, crate=0); >> adc[1] = VME_CAEN_V785(geom=2, crate=0); >> b2 = BARRIER(); >> tdc = VME_CAEN_V1190(geom=3); >> >> My question is now, where is the GEOM number coming from? How do the >> modules >> 'know' that they should have GEOM numbers 1 to 3? >> >> >> >> 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 hans.tornqvist at chalmers.se Mon Apr 22 17:44:17 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Mon, 22 Apr 2024 17:44:17 +0200 Subject: [subexp-daq] Question: what is GEOM? In-Reply-To: <1bb7151d8acf4b8b9e24f4ffb854f008@hi-jena.gsi.de> References: <0c8fd98d-7c9b-4bd8-8a19-665cf55e36b1@chalmers.se> <1bb7151d8acf4b8b9e24f4ffb854f008@hi-jena.gsi.de> Message-ID: Dear G?nter, In the beginning of development, like you said, it made sense to have an incrementing counter as a simple way to make sure every module has a unique ID. The address is not something that automatically shows up in the event payload. For this, nurdlib would have to write a custom header for every module which we want to avoid. I am also not a fan of "should be unique" esp. with humans involved, it's better if the code forces/verifies unique identifiers. Barriers are indeed extras, but not needed e.g. with a crate with 20 Caen modules which can have a unique Geo in every header. (Never mind the real-life issues with such a setup...) Many modules have some sort of Geo in the event header, esp. Caen and Mesytec modules, so that comes for free. Eventually someone had a crate with the PAUX connectors which messed up the Geo numbering :) So nurdlib had to grow the ability to re-assign and avoid collisions. And now the need for overriding Geo is cropping up, so it will happen soon. I just moved it up in my todo... Cheers, Hans On 2024-04-22 16:40, Weber, Guenter Dr. wrote: > Dear Hans, dear H?kan, > > > thank you for the explanations. Maybe my questions don't make much sense > as I have not correctly?understood the concept of this GEO number. > > > As I see it, the DAQ software?is (automaticly)?assigning a GEO?number to > (some of?) the?modules that is then readout from the module again by the > same DAQ. We then need to know this number to configure the matching > procedure in the *.spec file. And just by guessing and looking what > Bastian provided us, we assumed that this number is assigned according > to the order that the modules appear in the main.cfg file. > > > I get that it is nice to have a unique number for each module to make > sure that if there are many, you are always looking at the right one. > So, is the GEO number just a way to avoid identifying the modules by > tthe lengthy address that is set using the rotary switches (which > also?should be unique for each crate, right?)? > > > If possible and not already implemented, I think it would be really?good > to have the option to set a GEO number in main.cfg for each module. This > would avoid having to deal with new GEO numbers for everything once > modules are added or removed (as H?kan already mentioned). > > > But maybe I simply do not understand yet, how this GEO thing actually > works ? > > > > > Many thanks and best greetings > > G?nter > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > Hans Toshihide T?rnqvist > *Gesendet:* Montag, 22. April 2024 16:12:56 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.; H?kan T Johansson > *Betreff:* Re: [subexp-daq] Question: what is GEOM? > Dear G?nter, > > To add to H?kan's response, some Caen modules (maybe others?) can assign > its geom via the middle PAUX connector if that's available. I think > there's a config to make nurdlib aware that the module will have an > externally assigned geom number, but maybe also via a flag in a status > register. These are checked against the automatically assigned geom's, > so the step to overriding is not very big. > > Mostly fyi :) > > Cheers, > Hans > > On 2024-04-19 12:07, H?kan T Johansson wrote: >> >> Dear G?nter, >> >> I think nurdlib will assign the geom numbers (for modules which have >> that kind of identifier settable) in order for the modules that are >> configured. >> >> Unless not already implemented, it might be on Hans todo-list to be able >> to override that default, i.e. manually specify the module identifier >> that appears in the data.? That would be useful such that an unpacker >> can be used unchanged even if some detector/module is not present for >> some runs / experiments. >> >> Cheers, >> H?kan >> >> >> >> On Fri, 19 Apr 2024, Weber, Guenter Dr. wrote: >> >>> >>> Dear friends, >>> >>> >>> in my DAQ, I have three modules that are defined in main.cfg as follows: >>> >>> >>> ? ? # ADCs >>> ? ? CAEN_V785(0x11110000) { >>> ? ? ? ? threshold = (0 {32}) >>> ? ? } >>> ? ? CAEN_V785(0x44440000) { >>> ? ? ? ? threshold = (0 {32}) >>> ? ? } >>> ? ? # TDC >>> ? ? BARRIER >>> ? ? CAEN_V1190(0x22220000) { >>> ? ? ? ? ? ?blt_mode = noblt >>> ? ? ? ? ? ?edge = leading >>> ? ? ? ? ? ?resolution = 100 ps >>> ? ? ? ? ? ?deadtime = 5 ns >>> ? ? ? ? # with 100 ps resolution, max window size: 50 us >>> ? ? ? ? ? ?GATE { >>> ? ? ? ? ? ? time_after_trigger = -1us >>> ? ? ? ? ? ? width = 2us >>> ? ? ? ? ? ?} >>> ? ? } >>> >>> In the corresponding *.spec file, the data is matched via this commands: >>> >>> >>> ??? adc[0] = VME_CAEN_V785(geom=1, crate=0); >>> ?? ?adc[1] = VME_CAEN_V785(geom=2, crate=0); >>> ?? ?b2 = BARRIER(); >>> ?? ?tdc = VME_CAEN_V1190(geom=3); >>> >>> My question is now, where is the GEOM number coming from? How do the >>> modules >>> 'know' that they should have GEOM numbers 1 to 3? >>> >>> >>> >>> 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 > > From g.weber at hi-jena.gsi.de Tue Apr 23 17:45:48 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 23 Apr 2024 15:45:48 +0000 Subject: [subexp-daq] Question on NURDLIB - what is 'pedestal'? Message-ID: Dear friends, I came across 'pedestal' in module V7nn (while trying to implement the missing 16 channel module 785N into NURDLIB). Is there an easy explanation what this is? Thank you very much! Best greetings G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Tue Apr 23 19:06:51 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Tue, 23 Apr 2024 19:06:51 +0200 Subject: [subexp-daq] Question on NURDLIB - what is 'pedestal'? In-Reply-To: References: Message-ID: <1d74c003-9fa7-4b8b-c28d-9e8b71138fb9@chalmers.se> Dear G?nter, that ought to be for ADCs or QDCs. On the trigger they typically convert all channels. But most are just noise. Then the storage of values only happens if they are above the threshold. It is sometimes convenient to set those cut thresholds automatically. That requires knowing that some triggers happen randomly, and thus should only by chance be associated with 'non-noise' data. With the auto-pedestal setting, such noise data would be collected and analysed (mean and std.dev.), and then a threshold setting is calculated a few sigma above. I think the name pedestal would refer to the mean value of the noise as such. The analysis presumably happens once-in-a-while, and might also warn if the pedestals change more than some std.dev. fraction. I hope Hans will fill in more details if needed (and tell if I'm completely off). Cheers, H?kan On Tue, 23 Apr 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > I came across 'pedestal' in module V7nn (while trying to implement the > missing 16 channel module 785N into NURDLIB). Is there an easy explanation > what this is? > > > > > Thank you very much! > > > > > Best greetings > > G?nter > > > > From g.weber at hi-jena.gsi.de Tue Apr 23 23:40:55 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 23 Apr 2024 21:40:55 +0000 Subject: [subexp-daq] NURDLIB - working with arrays of variable length (e. g. for different channel numbers) Message-ID: <3f3e5fb800464033bd46d146891ad81b@hi-jena.gsi.de> Dear friends, I am having trouble to correctly implement the possibility of various numbers of channels in caen_v7nn.c. For example in INIT_FAST, I wanted to change uint16_t threshold_array[32]; to uint16_t* threshold_array; threshold_array = calloc(a_v7nn->number_of_channels, sizeof(uint16_t)); However, at some points in the code, the length of the array is determined by something like sizeof array / sizeof array[0] and this fails if we just have the pointer. I found some explanations and possible solutions here: https://stackoverflow.com/questions/37538/how-do-i-determine-the-size-of-my-array-in-c However, I assume this is much too complicated and I should just try to implement this differently. Maybe this issue came already up for some other module and was solved long time ago. Could you give me a hint? Thank you very much! Best greetings G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.tornqvist at chalmers.se Wed Apr 24 12:45:55 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Wed, 24 Apr 2024 12:45:55 +0200 Subject: [subexp-daq] Question on NURDLIB - what is 'pedestal'? In-Reply-To: <1d74c003-9fa7-4b8b-c28d-9e8b71138fb9@chalmers.se> References: <1d74c003-9fa7-4b8b-c28d-9e8b71138fb9@chalmers.se> Message-ID: Dear all, All correct, but I should add that this has so far only been a nice-to-have feature which nobody else has touched as far as I know. I would not rely on it for anything other than having fun trying to revive it, or to clean up the festering v7nn code. Cheers, Hans On 2024-04-23 19:06, H?kan T Johansson wrote: > > Dear G?nter, > > that ought to be for ADCs or QDCs.? On the trigger they typically > convert all channels.? But most are just noise.? Then the storage of > values only happens if they are above the threshold. > > It is sometimes convenient to set those cut thresholds automatically. > That requires knowing that some triggers happen randomly, and thus > should only by chance be associated with 'non-noise' data.? With the > auto-pedestal setting, such noise data would be collected and analysed > (mean and std.dev.), and then a threshold setting is calculated a few > sigma above.? I think the name pedestal would refer to the mean value of > the noise as such. > > The analysis presumably happens once-in-a-while, and might also warn if > the pedestals change more than some std.dev. fraction. > > I hope Hans will fill in more details if needed (and tell if I'm > completely off). > > Cheers, > H?kan > > > > On Tue, 23 Apr 2024, Weber, Guenter Dr. wrote: > >> >> Dear friends, >> >> >> I came across 'pedestal' in module V7nn (while trying to implement the >> missing 16 channel module 785N into NURDLIB). Is there an easy >> explanation >> what this is? >> >> >> >> >> Thank you very much! >> >> >> >> >> Best greetings >> >> G?nter >> >> >> >> > From hans.tornqvist at chalmers.se Wed Apr 24 13:22:29 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Wed, 24 Apr 2024 13:22:29 +0200 Subject: [subexp-daq] NURDLIB - working with arrays of variable length (e. g. for different channel numbers) In-Reply-To: <3f3e5fb800464033bd46d146891ad81b@hi-jena.gsi.de> References: <3f3e5fb800464033bd46d146891ad81b@hi-jena.gsi.de> Message-ID: <43fa5c72-0e3f-4bc9-a3f6-fdf62cca7766@chalmers.se> Dear G?nter, On 2024-04-23 23:40, Weber, Guenter Dr. wrote: > Dear friends, > > I am having trouble to correctly implement the possibility of various > numbers of channels in caen_v7nn.c. > > For example in INIT_FAST, I wanted to change > > uint16_t threshold_array[32]; > > to > > uint16_t* threshold_array; > threshold_array = calloc(a_v7nn->number_of_channels, sizeof(uint16_t)); > > However, at some points in the code, the length of the array is > determined by something like > > sizeof array / sizeof array[0] > > and this fails if we just have the pointer. This seems to happen in SET_THRESHOLDS, which just passes on the length to set_thresholds. This is a weird contraption, one of many reasons I refer to this code as festering... Just remove the macro and call the function directly: set_thresholds(a_v7nn, threshold_array, a_v7nn->number_of_channels); The worst offender to me is that I have tried hard to only have byte size interfaces, no array lengths. Mixing the two in a code-base is a very common source of bugs... Hope that helps! Cheers, Hans > I found some explanations and possible solutions here: > https://stackoverflow.com/questions/37538/how-do-i-determine-the-size-of-my-array-in-c > > However, I assume this is much too complicated and I should just try to > implement this differently. Maybe this issue came already up for some > other module and was solved long time ago. > > Could you give me a hint? > > Thank you very much! > > Best greetings > > G?nter From g.weber at hi-jena.gsi.de Thu Apr 25 14:20:07 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Thu, 25 Apr 2024 12:20:07 +0000 Subject: [subexp-daq] NURDLIB - CAEN V785N added plus spec file for UCESB Message-ID: Dear friends, we just pushed a new version to GITLAB. On top of the bugfixed V1n90 code, we now also added the 16 channel ADC V985N. Attached please find an updated *.spec file for UCESB. Best greetings G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vme_caen_v775.spec Type: application/octet-stream Size: 2093 bytes Desc: vme_caen_v775.spec URL: From f96hajo at chalmers.se Thu Apr 25 14:34:40 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Thu, 25 Apr 2024 14:34:40 +0200 Subject: [subexp-daq] NURDLIB - CAEN V785N added plus spec file for UCESB In-Reply-To: References: Message-ID: Dear G?nter, is taht the branch v1n90_fixed_plus_V785N_added ? That however contains just one commit (774cb158), and I do not see something V985N-related in that. Cheers, H?kan On Thu, 25 Apr 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > we just pushed a new version to GITLAB. On top of the bugfixed V1n90 code, > we now also added the 16 channel ADC V985N. Attached please find an updated > *.spec file for UCESB. > > > > > Best greetings > > G?nter > > > > > From g.weber at hi-jena.gsi.de Thu Apr 25 15:36:35 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Thu, 25 Apr 2024 13:36:35 +0000 Subject: [subexp-daq] NURDLIB - CAEN V785N added plus spec file for UCESB In-Reply-To: References: , Message-ID: <9697391614bc48559d8ba08662ac371f@hi-jena.gsi.de> Yes, sorry. Of course, I forgot to commit before pushing. This should be fixed now. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Donnerstag, 25. April 2024 14:34:40 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] NURDLIB - CAEN V785N added plus spec file for UCESB Dear G?nter, is taht the branch v1n90_fixed_plus_V785N_added ? That however contains just one commit (774cb158), and I do not see something V985N-related in that. Cheers, H?kan On Thu, 25 Apr 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > we just pushed a new version to GITLAB. On top of the bugfixed V1n90 code, > we now also added the 16 channel ADC V985N. Attached please find an updated > *.spec file for UCESB. > > > > > Best greetings > > G?nter > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Thu Apr 25 19:54:56 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Thu, 25 Apr 2024 19:54:56 +0200 Subject: [subexp-daq] NURDLIB - CAEN V785N added plus spec file for UCESB In-Reply-To: References: Message-ID: Dear G?nter, On Thu, 25 Apr 2024, Weber, Guenter Dr. wrote: > Attached please find an updated *.spec file for UCESB. thanks for the .spec file update for V785N. I changed it a bit and merged. Please check that it works. Cheers, H?kan From g.weber at hi-jena.gsi.de Fri Apr 26 09:34:45 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Fri, 26 Apr 2024 07:34:45 +0000 Subject: [subexp-daq] NURDLIB - CAEN V785N added plus spec file for UCESB In-Reply-To: References: , Message-ID: <1d3dc54d8ecf406f9f5962679325df33@hi-jena.gsi.de> Dear H?kan, the new SPEC files for v7nn and v1n90 work fine. Best greetings and have a nice weekend G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Donnerstag, 25. April 2024 19:54:56 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] NURDLIB - CAEN V785N added plus spec file for UCESB Dear G?nter, On Thu, 25 Apr 2024, Weber, Guenter Dr. wrote: > Attached please find an updated *.spec file for UCESB. thanks for the .spec file update for V785N. I changed it a bit and merged. Please check that it works. Cheers, H?kan -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.weber at hi-jena.gsi.de Fri Apr 26 18:52:28 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Fri, 26 Apr 2024 16:52:28 +0000 Subject: [subexp-daq] UCESB - SPEC file for CAEN V767 Message-ID: <54a488b2931d40eaa85d39a10eacac7c@hi-jena.gsi.de> Dear friends, attached please find a first version of the SPEC file for the TDC module we added to NURDLIB a while ago. Best greetings G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vme_caen_v767.spec Type: application/octet-stream Size: 2440 bytes Desc: vme_caen_v767.spec URL: From hans.tornqvist at chalmers.se Sat Apr 27 13:20:17 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Sat, 27 Apr 2024 13:20:17 +0200 Subject: [subexp-daq] NURDLIB - CAEN V785N added plus spec file for UCESB In-Reply-To: <9697391614bc48559d8ba08662ac371f@hi-jena.gsi.de> References: <9697391614bc48559d8ba08662ac371f@hi-jena.gsi.de> Message-ID: Dear all, All the recent versions have been merged together into master, please have a look if it still works! Best regards, Hans On 2024-04-25 15:36, Weber, Guenter Dr. wrote: > Yes, sorry. Of course, I forgot to commit before pushing. This should be > fixed now. > > > > > Best greetings > > G?nter > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > H?kan T Johansson > *Gesendet:* Donnerstag, 25. April 2024 14:34:40 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > *Betreff:* Re: [subexp-daq] NURDLIB - CAEN V785N added plus spec file > for UCESB > > Dear G?nter, > > is taht the branch v1n90_fixed_plus_V785N_added ? > > That however contains just one commit (774cb158), and I do not see > something V985N-related in that. > > Cheers, > H?kan > > > On Thu, 25 Apr 2024, Weber, Guenter Dr. wrote: > >> >> Dear friends, >> >> >> we just pushed a new version to GITLAB. On top of the bugfixed V1n90 code, >> we now also added the 16 channel ADC V985N. Attached please find an updated >> *.spec file for UCESB. >> >> >> >> >> Best greetings >> >> G?nter >> >> >> >> >> > From f96hajo at chalmers.se Sat Apr 27 15:41:21 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Sat, 27 Apr 2024 15:41:21 +0200 Subject: [subexp-daq] UCESB - SPEC file for CAEN V767 In-Reply-To: <54a488b2931d40eaa85d39a10eacac7c@hi-jena.gsi.de> References: <54a488b2931d40eaa85d39a10eacac7c@hi-jena.gsi.de> Message-ID: <07a76ac2-e20b-2170-78b1-8bdf132115d6@chalmers.se> Hi G?nter, thanks for the V767 .spec file. I have added it, with some modifications: The 0x767a767a marker word does as far as I see in the V767 manual not come from the module, but I suspect is a barrier inserted in the nurdlib configuration. That should be matched outside the module in the unpacker. The geom bits MATCH would be used for unpacking to find the correct module, independent of how the module 'learnt' which number it should have. I removed the #ifdefs around that. I suppose that the 64-channel version always has a zero in bit 30 of the data words? I hope I managed to put the CHECK_COUNT and MARK_COUNT correctly, such that the lngth checking passes for actual data... Please test. Cheers, H?kan On Fri, 26 Apr 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > attached please find a first version of the SPEC file for the TDC module we > added to NURDLIB a while ago. > > > > > Best greetings > > G?nter > > > > > > From f96hajo at chalmers.se Sat Apr 27 15:58:13 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Sat, 27 Apr 2024 15:58:13 +0200 Subject: [subexp-daq] SIS3316 implementation in NURDLIB fixed In-Reply-To: <094829a7-9155-a738-50a9-7d1f2cc65f1f@chalmers.se> References: <491be67cb51542f78f084ac5c8a51d08@hi-jena.gsi.de>, <4eac8d00-c1a5-407e-39e6-05f2cfbacb87@chalmers.se> <70134907f22c4314936cbbdb39a62d51@hi-jena.gsi.de> <094829a7-9155-a738-50a9-7d1f2cc65f1f@chalmers.se> Message-ID: I think this was the most recent mail regarding the SIS3316. To not let this drop, I rebased 'rebasing_sis3316_dma_align' on top of current master (no conflicts). In the hope that this gets tested and then merged. Cheers, H?kan On Sat, 23 Mar 2024, H?kan T Johansson wrote: > > Dear G?nter, > > I just pushed a new branch 'rebasing_sis3316_dma_align' to gitlab which > changes to use that method instead. It also moved the calculation of > bytes_to_read up, as otherwise warnings for possibly uninitialised variable > use were generated. > > I am not sure if the check for buffer overflow is taking into account other > data already added to the output. This I think Hans is better to figure out. > > Perhaps too many variables at once, but this new branch has been rebased on > top of current nurdlib master. > > Cheers, > H?kan > > > > > On Fri, 22 Mar 2024, Weber, Guenter Dr. wrote: > >> >> Yes, I think you are right. >> >> >> ____________________________________________________________________________ >> Von: subexp-daq im Auftrag von H?kan >> T Johansson >> Gesendet: Freitag, 22. M?rz 2024 17:37:42 >> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> Betreff: Re: [subexp-daq] SIS3316 implementation in NURDLIB fixed ? >> >> Dear G?nter, >> >> just had a quick look: >> >> This old code with +1 is surely not good: >> >> ??????????????? bytes_to_read = >> ??????????????????? ((a_words_to_read * sizeof(uint32_t)) + 1) & ~0x7; >> >> Since sizeof(uint32_t) is 4, the addition of 1 would not have any effect. >> >> However, I'm a bit wondering about addint 8 (and 16 in the case of ~0xf). >> >> How about the following: >> >> ??????????????? bytes_to_read = >> ??????????????????? ((a_words_to_read * sizeof(uint32_t)) + 0x7) & ~0x7; >> >> (and '+ 0xf' with '& ~0xf') ? >> >> That ought to bring it up to the next boundary if the read count was >> unaligned.? And the if-statements would not be needed. >> >> Cheers, >> H?kan >> >> >> >> >> On Fri, 22 Mar 2024, Weber, Guenter Dr. wrote: >> >> > >> > Dear friends, >> > >> > >> > we just pushed a fixed version of the SIS3316 implementation. Compared to >> > the original version of REBASING_SIS3316 a lot of glitches in the code >> were >> > fixed in a first run a few days ago and now we finally also fixed a >> > long-standing problem with the readout of the averaged traces. >> > >> > >> > >> > >> > >> > Best greetings and have a nice weekend everybody >> > >> > G?nter >> > >> > >> > >> > >> > >> > >> >> > From g.weber at hi-jena.gsi.de Sun Apr 28 14:49:28 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Sun, 28 Apr 2024 12:49:28 +0000 Subject: [subexp-daq] UCESB - SPEC file for CAEN V767 In-Reply-To: <07a76ac2-e20b-2170-78b1-8bdf132115d6@chalmers.se> References: <54a488b2931d40eaa85d39a10eacac7c@hi-jena.gsi.de>, <07a76ac2-e20b-2170-78b1-8bdf132115d6@chalmers.se> Message-ID: Dear H?kan, if I understand correctly, if the GEO address is not set via software this number is determined by the position of a module in the VME crate. Thus, even if you have access to the main.cfg of a certain measurement, it is still unclear what the right GEO number is. The only chance to determine the right number for a module would be to either have the information where the module was (and how this translates to the GEO number) or to look into the raw LMD data and search for the data block of the module in question. This is not very convenient, in particular as in our most people will use the DAQ and the corresponding software as a black box. If this is correct, maybe it would be a good idea to make the GEO check optional (if this is possible within the code, i. e. by defining geom = -1 as a wild card). Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Samstag, 27. April 2024 15:41:21 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] UCESB - SPEC file for CAEN V767 Hi G?nter, thanks for the V767 .spec file. I have added it, with some modifications: The 0x767a767a marker word does as far as I see in the V767 manual not come from the module, but I suspect is a barrier inserted in the nurdlib configuration. That should be matched outside the module in the unpacker. The geom bits MATCH would be used for unpacking to find the correct module, independent of how the module 'learnt' which number it should have. I removed the #ifdefs around that. I suppose that the 64-channel version always has a zero in bit 30 of the data words? I hope I managed to put the CHECK_COUNT and MARK_COUNT correctly, such that the lngth checking passes for actual data... Please test. Cheers, H?kan On Fri, 26 Apr 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > attached please find a first version of the SPEC file for the TDC module we > added to NURDLIB a while ago. > > > > > Best greetings > > G?nter > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.weber at hi-jena.gsi.de Sun Apr 28 15:04:34 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Sun, 28 Apr 2024 13:04:34 +0000 Subject: [subexp-daq] SIS3316 implementation in NURDLIB fixed In-Reply-To: References: <491be67cb51542f78f084ac5c8a51d08@hi-jena.gsi.de>, <4eac8d00-c1a5-407e-39e6-05f2cfbacb87@chalmers.se> <70134907f22c4314936cbbdb39a62d51@hi-jena.gsi.de> <094829a7-9155-a738-50a9-7d1f2cc65f1f@chalmers.se>, Message-ID: <6e5e6b43e2dd409f9b79b95eb82ab49e@hi-jena.gsi.de> Dear friends, who are the other users of the 3316 module? As I understand, most other groups are using the faster 250 MHz, 14-bit version, while we are (the only) ones who are using the 125 MHz, 16-bit version. If there is an interest to use the software version that was bugfixed as a common standard for the future, we should not be the only ones testing it. ? (But if we are the only user of the software for now, we could have a look if we want to adjust the output of the module better to our needs. For example, at the moment the temperature of the module is written to the data of every individual channel. Even though it is a global variable, whose more suitable place would be in the header(s) information.) Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Samstag, 27. April 2024 15:58:13 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] SIS3316 implementation in NURDLIB fixed I think this was the most recent mail regarding the SIS3316. To not let this drop, I rebased 'rebasing_sis3316_dma_align' on top of current master (no conflicts). In the hope that this gets tested and then merged. Cheers, H?kan On Sat, 23 Mar 2024, H?kan T Johansson wrote: > > Dear G?nter, > > I just pushed a new branch 'rebasing_sis3316_dma_align' to gitlab which > changes to use that method instead. It also moved the calculation of > bytes_to_read up, as otherwise warnings for possibly uninitialised variable > use were generated. > > I am not sure if the check for buffer overflow is taking into account other > data already added to the output. This I think Hans is better to figure out. > > Perhaps too many variables at once, but this new branch has been rebased on > top of current nurdlib master. > > Cheers, > H?kan > > > > > On Fri, 22 Mar 2024, Weber, Guenter Dr. wrote: > >> >> Yes, I think you are right. >> >> >> ____________________________________________________________________________ >> Von: subexp-daq im Auftrag von H?kan >> T Johansson >> Gesendet: Freitag, 22. M?rz 2024 17:37:42 >> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> Betreff: Re: [subexp-daq] SIS3316 implementation in NURDLIB fixed >> >> Dear G?nter, >> >> just had a quick look: >> >> This old code with +1 is surely not good: >> >> bytes_to_read = >> ((a_words_to_read * sizeof(uint32_t)) + 1) & ~0x7; >> >> Since sizeof(uint32_t) is 4, the addition of 1 would not have any effect. >> >> However, I'm a bit wondering about addint 8 (and 16 in the case of ~0xf). >> >> How about the following: >> >> bytes_to_read = >> ((a_words_to_read * sizeof(uint32_t)) + 0x7) & ~0x7; >> >> (and '+ 0xf' with '& ~0xf') ? >> >> That ought to bring it up to the next boundary if the read count was >> unaligned. And the if-statements would not be needed. >> >> Cheers, >> H?kan >> >> >> >> >> On Fri, 22 Mar 2024, Weber, Guenter Dr. wrote: >> >> > >> > Dear friends, >> > >> > >> > we just pushed a fixed version of the SIS3316 implementation. Compared to >> > the original version of REBASING_SIS3316 a lot of glitches in the code >> were >> > fixed in a first run a few days ago and now we finally also fixed a >> > long-standing problem with the readout of the averaged traces. >> > >> > >> > >> > >> > >> > Best greetings and have a nice weekend everybody >> > >> > G?nter >> > >> > >> > >> > >> > >> > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Sun Apr 28 18:21:53 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Sun, 28 Apr 2024 18:21:53 +0200 Subject: [subexp-daq] UCESB - SPEC file for CAEN V767 In-Reply-To: References: <54a488b2931d40eaa85d39a10eacac7c@hi-jena.gsi.de>, <07a76ac2-e20b-2170-78b1-8bdf132115d6@chalmers.se> Message-ID: <1b41d369-2aff-ae28-9132-3ad7dd0c0c00@chalmers.se> Dear G?nter, I see. But I suspect this is then not a difference between the V767 and V767A, but rather between if the module has a JAUX connector (short one between the big P0 and P1 connectors) on the back. With the JAUX, it should indeed take this field from the position in the crate, and the corresponding config register is only readable. The manual I find only talks about a 128 ch version, and then V767 and V767B, where B does not have the JAUX connector... (I do find a 64-channel V767A module referenced in an old sales catalogue. Seems CAEN's naming scheme leaves a bit to be desired...) I've added recognition of VME_CAEN_V767x_NO_GEOM_MATCH, which, if defined before the .spec file is included, avoids the MATCH/CHECK of that header field. Cheers, H?kan On Sun, 28 Apr 2024, Weber, Guenter Dr. wrote: > > Dear?H?kan, > > > if I understand correctly, if the GEO address is not set via software this > number is determined by the position of a module in the VME crate. Thus, > even if you have access to the main.cfg of a certain measurement, it is > still unclear what the right GEO number is. The only chance to determine the > right number for a module would be to either have the information where the > module was (and how this translates to the GEO number) or to look into the > raw LMD data and search for the data block of the module in question. This > is not very convenient, in particular as in our most people will use the DAQ > and the corresponding software as a black box. > > > If this is correct, maybe it would be a good idea to make the GEO check > optional (if this is possible within the code, i. e. by?defining geom = -1 > as a wild card). > > > > Best greetings > > G?nter > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan > T Johansson > Gesendet: Samstag, 27. April 2024 15:41:21 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] UCESB - SPEC file for CAEN V767 ? > > Hi G?nter, > > thanks for the V767 .spec file.? I have added it, with some modifications: > > The 0x767a767a marker word does as far as I see in the V767 manual not > come from the module, but I suspect is a barrier inserted in the nurdlib > configuration.? That should be matched outside the module in the unpacker. > > The geom bits MATCH would be used for unpacking to find the correct > module, independent of how the module 'learnt' which number it should > have.? I removed the #ifdefs around that. > > I suppose that the 64-channel version always has a zero in bit 30 of the > data words? > > I hope I managed to put the CHECK_COUNT and MARK_COUNT correctly, such > that the lngth checking passes for actual data... > > Please test. > > Cheers, > H?kan > > > > On Fri, 26 Apr 2024, Weber, Guenter Dr. wrote: > > > > > Dear friends, > > > > > > attached please find a first version of the SPEC file for the TDC module > we > > added to NURDLIB a while ago. > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > > > > > > > > From g.weber at hi-jena.gsi.de Sun Apr 28 18:32:00 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Sun, 28 Apr 2024 16:32:00 +0000 Subject: [subexp-daq] UCESB - SPEC file for CAEN V767 In-Reply-To: <1b41d369-2aff-ae28-9132-3ad7dd0c0c00@chalmers.se> References: <54a488b2931d40eaa85d39a10eacac7c@hi-jena.gsi.de>, <07a76ac2-e20b-2170-78b1-8bdf132115d6@chalmers.se> , <1b41d369-2aff-ae28-9132-3ad7dd0c0c00@chalmers.se> Message-ID: Dear H?kan, thank you for the prompt reply. Attached please find the manual for the V767A module. On page 25 the GEO REGISTER is discussed. And is I understand, your interpretation is correct that only V767AB is the outlier where the GEO address can be set via software. Thanks a lot for paying attention to these details! Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Sonntag, 28. April 2024 18:21:53 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] UCESB - SPEC file for CAEN V767 Dear G?nter, I see. But I suspect this is then not a difference between the V767 and V767A, but rather between if the module has a JAUX connector (short one between the big P0 and P1 connectors) on the back. With the JAUX, it should indeed take this field from the position in the crate, and the corresponding config register is only readable. The manual I find only talks about a 128 ch version, and then V767 and V767B, where B does not have the JAUX connector... (I do find a 64-channel V767A module referenced in an old sales catalogue. Seems CAEN's naming scheme leaves a bit to be desired...) I've added recognition of VME_CAEN_V767x_NO_GEOM_MATCH, which, if defined before the .spec file is included, avoids the MATCH/CHECK of that header field. Cheers, H?kan On Sun, 28 Apr 2024, Weber, Guenter Dr. wrote: > > Dear H?kan, > > > if I understand correctly, if the GEO address is not set via software this > number is determined by the position of a module in the VME crate. Thus, > even if you have access to the main.cfg of a certain measurement, it is > still unclear what the right GEO number is. The only chance to determine the > right number for a module would be to either have the information where the > module was (and how this translates to the GEO number) or to look into the > raw LMD data and search for the data block of the module in question. This > is not very convenient, in particular as in our most people will use the DAQ > and the corresponding software as a black box. > > > If this is correct, maybe it would be a good idea to make the GEO check > optional (if this is possible within the code, i. e. by defining geom = -1 > as a wild card). > > > > Best greetings > > G?nter > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan > T Johansson > Gesendet: Samstag, 27. April 2024 15:41:21 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] UCESB - SPEC file for CAEN V767 > > Hi G?nter, > > thanks for the V767 .spec file. I have added it, with some modifications: > > The 0x767a767a marker word does as far as I see in the V767 manual not > come from the module, but I suspect is a barrier inserted in the nurdlib > configuration. That should be matched outside the module in the unpacker. > > The geom bits MATCH would be used for unpacking to find the correct > module, independent of how the module 'learnt' which number it should > have. I removed the #ifdefs around that. > > I suppose that the 64-channel version always has a zero in bit 30 of the > data words? > > I hope I managed to put the CHECK_COUNT and MARK_COUNT correctly, such > that the lngth checking passes for actual data... > > Please test. > > Cheers, > H?kan > > > > On Fri, 26 Apr 2024, Weber, Guenter Dr. wrote: > > > > > Dear friends, > > > > > > attached please find a first version of the SPEC file for the TDC module > we > > added to NURDLIB a while ago. > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: WEB_UMV767A_rev3.pdf Type: application/pdf Size: 1251268 bytes Desc: WEB_UMV767A_rev3.pdf URL: From f96hajo at chalmers.se Sun Apr 28 18:38:46 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Sun, 28 Apr 2024 18:38:46 +0200 Subject: [subexp-daq] SIS3316 implementation in NURDLIB fixed In-Reply-To: <6e5e6b43e2dd409f9b79b95eb82ab49e@hi-jena.gsi.de> References: <491be67cb51542f78f084ac5c8a51d08@hi-jena.gsi.de>, <4eac8d00-c1a5-407e-39e6-05f2cfbacb87@chalmers.se> <70134907f22c4314936cbbdb39a62d51@hi-jena.gsi.de> <094829a7-9155-a738-50a9-7d1f2cc65f1f@chalmers.se>, <6e5e6b43e2dd409f9b79b95eb82ab49e@hi-jena.gsi.de> Message-ID: Dear G?nter, I am just looking for a positive report about some/any actual use if the code such that there is enough confidence in the branch to get it merged. That would also give a much better reference point for anyone wanting to do further improvements. (I am pushing since having unmerged branches stalls other development since one is more reluctant to do global improvements that potentially would break in a branch...) Best regards, H?kan On Sun, 28 Apr 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > who are the other users of the 3316 module? As I understand, most other > groups are using the faster 250 MHz, 14-bit version, while we are (the only) > ones who are using the 125 MHz, 16-bit version. > > > If there is an interest to use the software version?that was bugfixed as a > common standard for the future, we should not be the only ones testing > it.?? > > (But if we are the only user of the software for now, we could have a look > if we want to adjust the output of the module better to our needs. For > example, at the moment the temperature of the module is written to the data > of?every individual?channel. Even though it is a global variable, whose more > suitable place would be in the header(s) information.) > > > > Best greetings > > G?nter > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan > T Johansson > Gesendet: Samstag, 27. April 2024 15:58:13 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] SIS3316 implementation in NURDLIB fixed ? > > I think this was the most recent mail regarding the SIS3316. > > To not let this drop, I rebased 'rebasing_sis3316_dma_align' on top of > current master (no conflicts).? In the hope that this gets tested and > then merged. > > Cheers, > H?kan > > > > On Sat, 23 Mar 2024, H?kan T Johansson wrote: > > > > > Dear G?nter, > > > > I just pushed a new branch 'rebasing_sis3316_dma_align' to gitlab which > > changes to use that method instead.? It also moved the calculation of > > bytes_to_read up, as otherwise warnings for possibly uninitialised > variable > > use were generated. > > > > I am not sure if the check for buffer overflow is taking into account > other > > data already added to the output.? This I think Hans is better to figure > out. > > > > Perhaps too many variables at once, but this new branch has been rebased > on > > top of current nurdlib master. > > > > Cheers, > > H?kan > > > > > > > > > > On Fri, 22 Mar 2024, Weber, Guenter Dr. wrote: > > > >> > >> Yes, I think you are right. > >> > >> > >>___________________________________________________________________________ > _ > >> Von: subexp-daq im Auftrag von > H?kan > >> T Johansson > >> Gesendet: Freitag, 22. M?rz 2024 17:37:42 > >> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > >> Betreff: Re: [subexp-daq] SIS3316 implementation in NURDLIB fixed ? > >> > >> Dear G?nter, > >> > >> just had a quick look: > >> > >> This old code with +1 is surely not good: > >> > >> ??????????????? bytes_to_read = > >> ??????????????????? ((a_words_to_read * sizeof(uint32_t)) + 1) & ~0x7; > >> > >> Since sizeof(uint32_t) is 4, the addition of 1 would not have any effect. > >> > >> However, I'm a bit wondering about addint 8 (and 16 in the case of ~0xf). > >> > >> How about the following: > >> > >> ??????????????? bytes_to_read = > >> ??????????????????? ((a_words_to_read * sizeof(uint32_t)) + 0x7) & ~0x7; > >> > >> (and '+ 0xf' with '& ~0xf') ? > >> > >> That ought to bring it up to the next boundary if the read count was > >> unaligned.? And the if-statements would not be needed. > >> > >> Cheers, > >> H?kan > >> > >> > >> > >> > >> On Fri, 22 Mar 2024, Weber, Guenter Dr. wrote: > >> > >> > > >> > Dear friends, > >> > > >> > > >> > we just pushed a fixed version of the SIS3316 implementation. Compared > to > >> > the original version of REBASING_SIS3316 a lot of glitches in the code > >> were > >> > fixed in a first run a few days ago and now we finally also fixed a > >> > long-standing problem with the readout of the averaged traces. > >> > > >> > > >> > > >> > > >> > > >> > Best greetings and have a nice weekend everybody > >> > > >> > G?nter > >> > > >> > > >> > > >> > > >> > > >> > > >> > >> > > > > From g.weber at hi-jena.gsi.de Mon Apr 29 10:25:29 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Mon, 29 Apr 2024 08:25:29 +0000 Subject: [subexp-daq] UCESB - follow-up question on CAEN V767 Message-ID: <34e5f8b018704139976e3b0f8e598e4d@hi-jena.gsi.de> Dear friends, one thing I don't understand yet: MEMBER(DATA24 data[VME_CAEN_V767x_NUM_CH] ZERO_SUPPRESS_MULTI(128)); This generate a 2D array with 64 x 128 fields, right? I just copied the code from the V1n90 module. But in the manual of V767, I did not find a restriction on how many hits for each channel can be stored. The only limitation I came accross is right on the first page: the FIFO buffer is 32k words deep. 32.000 hits sounds like a crazy amount to me, but ok. Would it be better to put the data into a list of unspecified length, coding the channel number with higher bits that are not used by the hit time? Otherwise we have a problem if (in a very hypothetic case) the 129th hit for a given channel appears in the data. Best greetings G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Mon Apr 29 10:53:05 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Mon, 29 Apr 2024 10:53:05 +0200 Subject: [subexp-daq] UCESB - follow-up question on CAEN V767 In-Reply-To: <34e5f8b018704139976e3b0f8e598e4d@hi-jena.gsi.de> References: <34e5f8b018704139976e3b0f8e598e4d@hi-jena.gsi.de> Message-ID: Dear G?nter, our description of the issue is to the point! This is indeed a problem with ucesb and multi-entry data sources. Using one long list would indeed solve the initial problem, but then the functionality to map unpack channels to detector channels no longer work. The data structures would need some serious rethinking to solve this problem in a satisfactory manner. We are actually having quite serious issues with this also in larger setups, where there are too many of these crazy-sized arrays... Ucesb will at least give an error for events which overflow the number of entries per channel. How many hits would you normally expect in a channel when the experiment configuration is reasonable? Cheers, H?kan On Mon, 29 Apr 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > one thing I don't understand yet: > > > ? MEMBER(DATA24 data[VME_CAEN_V767x_NUM_CH] ZERO_SUPPRESS_MULTI(128)); > > > This generate a 2D array with 64 x 128 fields, right? I just copied the code from the V1n90 module. But in the > manual of V767, I did not find a restriction on how many hits for each channel can be stored. The only > limitation I came accross is right on the first page: the FIFO buffer is 32k words deep. 32.000 hits sounds like > a crazy amount to me, but ok. > > > Would it be better to put the data into a list of unspecified length, coding the channel number with higher bits > that are not used by the hit time? Otherwise we have a problem if (in a very hypothetic case) the 129th hit for > a given channel appears in the data. > > > > > > Best greetings > > G?nter > > > > > From g.weber at hi-jena.gsi.de Mon Apr 29 12:37:36 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Mon, 29 Apr 2024 10:37:36 +0000 Subject: [subexp-daq] UCESB - follow-up question on CAEN V767 In-Reply-To: References: <34e5f8b018704139976e3b0f8e598e4d@hi-jena.gsi.de>, Message-ID: <25420a1bfb5c4824bcafadf5a20a81e7@hi-jena.gsi.de> Dear H?kan, for our purposes, more than a handful of hits is unlikely (this could only be caused by triggering in the noise, which is fine to cause trouble). I just wanted to be sure, that my understanding is correct. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Montag, 29. April 2024 10:53:05 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] UCESB - follow-up question on CAEN V767 Dear G?nter, our description of the issue is to the point! This is indeed a problem with ucesb and multi-entry data sources. Using one long list would indeed solve the initial problem, but then the functionality to map unpack channels to detector channels no longer work. The data structures would need some serious rethinking to solve this problem in a satisfactory manner. We are actually having quite serious issues with this also in larger setups, where there are too many of these crazy-sized arrays... Ucesb will at least give an error for events which overflow the number of entries per channel. How many hits would you normally expect in a channel when the experiment configuration is reasonable? Cheers, H?kan On Mon, 29 Apr 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > one thing I don't understand yet: > > > MEMBER(DATA24 data[VME_CAEN_V767x_NUM_CH] ZERO_SUPPRESS_MULTI(128)); > > > This generate a 2D array with 64 x 128 fields, right? I just copied the code from the V1n90 module. But in the > manual of V767, I did not find a restriction on how many hits for each channel can be stored. The only > limitation I came accross is right on the first page: the FIFO buffer is 32k words deep. 32.000 hits sounds like > a crazy amount to me, but ok. > > > Would it be better to put the data into a list of unspecified length, coding the channel number with higher bits > that are not used by the hit time? Otherwise we have a problem if (in a very hypothetic case) the 129th hit for > a given channel appears in the data. > > > > > > Best greetings > > G?nter > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: