From g.weber at hi-jena.gsi.de Tue May 7 17:20:43 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 7 May 2024 15:20:43 +0000 Subject: [subexp-daq] NURDLIB - CAEN V785N added plus spec file for UCESB In-Reply-To: References: <9697391614bc48559d8ba08662ac371f@hi-jena.gsi.de>, Message-ID: Dear Hans, I had a brief check with the new NURDLIB and our DAQ (consisting of V785 ADCs and a V1190 TDC) is still working fine. Unfortunately, we will not be able to check the implementation of the SIS3316 modules within the next few weeks. Right now I am polishing the V767 implementation that was our starting point for adding things to NURDLIB. We did a few unnecessary things at that time. Best greetings G?nter ________________________________ Von: Hans Toshihide T?rnqvist Gesendet: Samstag, 27. April 2024 13:20 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr. Betreff: Re: [subexp-daq] NURDLIB - CAEN V785N added plus spec file for UCESB 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 >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.tornqvist at chalmers.se Tue May 7 22:22:19 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Tue, 7 May 2024 22:22:19 +0200 Subject: [subexp-daq] NURDLIB - CAEN V785N added plus spec file for UCESB In-Reply-To: References: <9697391614bc48559d8ba08662ac371f@hi-jena.gsi.de> Message-ID: <5eebb637-dc12-4007-9431-6d056f4012b1@chalmers.se> Dear G?nter, Thanks for the update, that gives me some relief :) (One item off the todo...) Best regards, Hans On 2024-05-07 17:20, Weber, Guenter Dr. wrote: > Dear Hans, > > > I had a brief check with the new NURDLIB and our DAQ (consisting of V785 > ADCs and a V1190 TDC) is still working fine. Unfortunately, we will not > be able to check the implementation of the SIS3316 modules within the > next few weeks. > > > Right now I am polishing the V767 implementation that was our starting > point for adding things to NURDLIB. We did a few unnecessary things at > that time. > > > > > > Best greetings > > G?nter > > > > > > > ------------------------------------------------------------------------ > *Von:* Hans Toshihide T?rnqvist > *Gesendet:* Samstag, 27. April 2024 13:20 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr. > *Betreff:* Re: [subexp-daq] NURDLIB - CAEN V785N added plus spec file > for UCESB > 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 g.weber at hi-jena.gsi.de Wed May 8 10:17:27 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Wed, 8 May 2024 08:17:27 +0000 Subject: [subexp-daq] NURDLIB - CAEN V785N added plus spec file for UCESB In-Reply-To: <5eebb637-dc12-4007-9431-6d056f4012b1@chalmers.se> References: <9697391614bc48559d8ba08662ac371f@hi-jena.gsi.de> , <5eebb637-dc12-4007-9431-6d056f4012b1@chalmers.se> Message-ID: <3342e5e546634a1e850444da65548d56@hi-jena.gsi.de> Dear Hans, my only issue with the new NURDLIB version is that the built-in test of the V1n90 module is failing once the following check starting from line 648 is implemented: /* uint32_t word_count; word_count = (u32 & BITS_MASK(0, 11)); printf("word count = %u, word counter = %u\n", word_count, tdc_word_cnt); if (word_count != tdc_word_cnt) { module_parse_error(LOGL, a_event_buffer, p32, "TDC trailer word count does not " "match actual number of words."); result = CRATE_READOUT_FAIL_DATA_CORRUPT; goto caen_v1n90_parse_data_done; } */ Either in the test case the data is not really conforming with the manual (I checked for the case of V1190), i. e. the word count number is wrong, or different modul versions have a different structure and the test case was constructed for a different version of the V1n90 familiy. For the moment, we can implement a check of the correct word count only on the UCESB level. Best greetings 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: Hans Toshihide T?rnqvist Gesendet: Dienstag, 7. Mai 2024 22:22:19 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr. Betreff: Re: [subexp-daq] NURDLIB - CAEN V785N added plus spec file for UCESB Dear G?nter, Thanks for the update, that gives me some relief :) (One item off the todo...) Best regards, Hans On 2024-05-07 17:20, Weber, Guenter Dr. wrote: > Dear Hans, > > > I had a brief check with the new NURDLIB and our DAQ (consisting of V785 > ADCs and a V1190 TDC) is still working fine. Unfortunately, we will not > be able to check the implementation of the SIS3316 modules within the > next few weeks. > > > Right now I am polishing the V767 implementation that was our starting > point for adding things to NURDLIB. We did a few unnecessary things at > that time. > > > > > > Best greetings > > G?nter > > > > > > > ------------------------------------------------------------------------ > *Von:* Hans Toshihide T?rnqvist > *Gesendet:* Samstag, 27. April 2024 13:20 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr. > *Betreff:* Re: [subexp-daq] NURDLIB - CAEN V785N added plus spec file > for UCESB > 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 >>> >>> >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.weber at hi-jena.gsi.de Mon May 13 16:47:27 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Mon, 13 May 2024 14:47:27 +0000 Subject: [subexp-daq] problem when running two DAQs in parallel on one server Message-ID: <77410e9c210e497dada45a595d599075@hi-jena.gsi.de> Dear friends, I am trying to run two DAQ systems from a single server. For this I first copied the experiment folder, than compiled everything one the second RIO and finally did some adjustments to the settings. The first system is started with the follwing command and runs just fine: ../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 \ "$@" For the second system (which is very similar) I tried to just increase the port numbers by 1000: ../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:9003 \ --server=drasi,dest=lyserv:8000 \ --buf=size=200Mi \ --max-ev-size=0x100000 \ --eb=lyserv:8000 \ --subev=crate=0,type=88,subtype=8800,control=0,procid=12 \ "$@" In the various auxiliary scripts I also updated the ports numbers. For example in the event builder: ../drasi/bin/lwrocmerge \ --label=EB \ --port=8000 \ --merge-mode=event \ --server=trans \ --server=stream,flush=1 \ --buf=size=500Mi \ --max-ev-size=1Mi \ --eb-master=rio4l-1 \ --drasi=rio4l-1 \ --file-writer \ "$@" However, it seems that something is missing because the DAQ fails at startup: Executing 'main'. CPUS: 1 delay: 1 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: 8000). 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: 8000). Message not logged - thread has no error buffer yet... HOST: RIO4L-1 Token: 21301afe (21301afe:21301afe) [/mbsusr/mbsdaq/.drasi_tokens/blub] 10: lwroc_hostname_util.c:460: Own address: 192.168.1.71/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:169: Started server on port 56583 (data port 34116). 10: lwroc_net_trans.c:1808: [stream:9003] Started stream server on port 9003, data 56265. 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-1:56583 10: lwroc_main.c:706: Log message rate limit not in effect. 10: lwroc_readout.c:112: call readout_init... 10: lwroc_thread_util.c: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:8000] (state 0) 10: lwroc_message_internal.c:485: Message client connected! 8: lwroc_triva_state.c:414: Waited 5 seconds for initial slave and EB connection(s): 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 8: lwroc_triva_state.c:414: Waited 10 seconds for initial slave and EB connection(s): 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 8: lwroc_triva_state.c:414: Waited 20 seconds for initial slave and EB connection(s): 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 8: lwroc_triva_state.c:414: Waited 40 seconds for initial slave and EB connection(s): 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. ^C8: lwroc_main.c:105: SIGINT received. 10: lwroc_thread_util.c:62: Set terminate first! (main) 10: lwroc_thread_util.c:82: main thread done! (Next term: data server) 10: lwroc_thread_util.c:82: data server thread done! (Next term: slow_async) 10: lwroc_thread_util.c:82: slow_async thread done! (Next term: net io) 10: lwroc_thread_util.c:82: net io thread done! (Next term: triva control) Performing hardware cleanup (TRIVA HALT, RESET)... I would really appreciate if you could give me a hint what is going on. Many thanks! Best greetings G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Mon May 13 17:22:28 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Mon, 13 May 2024 17:22:28 +0200 Subject: [subexp-daq] problem when running two DAQs in parallel on one server In-Reply-To: <77410e9c210e497dada45a595d599075@hi-jena.gsi.de> References: <77410e9c210e497dada45a595d599075@hi-jena.gsi.de> Message-ID: <6a706c02-aacc-24ea-389c-b8793cdb94ef@chalmers.se> Dear G?nter, I think the issue with the master-eb connection ("Waited ... seconds for initial slave and EB connection(s)"), i.e. the lines on the readout: --server=drasi,dest=lyserv:8000 \ --eb=lyserv:8000 \ or on the EB: ?--eb-master=rio4l-1 \ ?--drasi=rio4l-1 \ Questions: what is the 'names' of the two different readout computers as seen from the EB machine? I see rio4l-1, is that the 2nd (not-yet working node)? How does the EB script look for the first (running) DAQ? If this does not help, please also provide the log of the EB process. Cheers, H?kan On Mon, 13 May 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > I am trying to run two DAQ systems from a single server. For this I first copied the experiment folder, than compiled everything one the second > RIO and finally did some adjustments to the settings. > > > The first system is started with the follwing command and runs just fine: > > > ../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 \ > ?? ?"$@" > > For the second system (which is very similar) I tried to just increase the port numbers by 1000: > > > ../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:9003 \ > ?? ?--server=drasi,dest=lyserv:8000 \ > ?? ?--buf=size=200Mi \ > ?? ?--max-ev-size=0x100000 \ > ?? ?--eb=lyserv:8000 \ > ?? ?--subev=crate=0,type=88,subtype=8800,control=0,procid=12 \ > ?? ?"$@" > > > In the various auxiliary scripts I also updated the ports numbers. For example in the event builder: > > > ../drasi/bin/lwrocmerge \ > ?? ?--label=EB \ > ?? ?--port=8000 \ > ?? ?--merge-mode=event \ > ?? ?--server=trans \ > ?? ?--server=stream,flush=1 \ > ?? ?--buf=size=500Mi \ > ?? ?--max-ev-size=1Mi \ > ?? ?--eb-master=rio4l-1 \ > ?? ?--drasi=rio4l-1 \ > ?? ?--file-writer \ > ?? ?"$@" > > However, it seems that something is missing because the DAQ fails at startup: > > > Executing 'main'. > CPUS: 1 > delay: 1 > 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: 8000). > 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: 8000). > Message not logged - thread has no error buffer yet... > HOST: RIO4L-1 > Token: 21301afe (21301afe:21301afe) [/mbsusr/mbsdaq/.drasi_tokens/blub] > 10: lwroc_hostname_util.c:460: Own address: 192.168.1.71/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:169: Started server on port 56583 (data port 34116). > 10: lwroc_net_trans.c:1808: [stream:9003] Started stream server on port 9003, data 56265. > 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-1:56583 > 10: lwroc_main.c:706: Log message rate limit not in effect. > 10: lwroc_readout.c:112: call readout_init... > 10: lwroc_thread_util.c: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:8000] (state 0) > 10: lwroc_message_internal.c:485: Message client connected! > 8: lwroc_triva_state.c:414: Waited 5 seconds for initial slave and EB connection(s): > 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 8: lwroc_triva_state.c:414: Waited 10 seconds for initial slave and EB connection(s): > 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 8: lwroc_triva_state.c:414: Waited 20 seconds for initial slave and EB connection(s): > 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 8: lwroc_triva_state.c:414: Waited 40 seconds for initial slave and EB connection(s): > 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > ^C8: lwroc_main.c:105: SIGINT received. > 10: lwroc_thread_util.c:62: Set terminate first!? (main) > 10: lwroc_thread_util.c:82: main thread done!? (Next term: data server) > 10: lwroc_thread_util.c:82: data server thread done!? (Next term: slow_async) > 10: lwroc_thread_util.c:82: slow_async thread done!? (Next term: net io) > 10: lwroc_thread_util.c:82: net io thread done!? (Next term: triva control) > Performing hardware cleanup (TRIVA HALT, RESET)... > > I would really appreciate if you could give me a hint what is going on. Many thanks! > > > > > > Best greetings > > G?nter > > > > > > > From f96hajo at chalmers.se Mon May 13 17:24:19 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Mon, 13 May 2024 17:24:19 +0200 Subject: [subexp-daq] problem when running two DAQs in parallel on one server In-Reply-To: <77410e9c210e497dada45a595d599075@hi-jena.gsi.de> References: <77410e9c210e497dada45a595d599075@hi-jena.gsi.de> Message-ID: <8ea31a3c-649c-890e-dcde-594ff34c4c26@chalmers.se> Possily, your second EB has not started if the first is already running, the --server=trans and --server=stream,... lines below use the default ports. And if already in use by the first process, it cannot start. Try to add port=... > ../drasi/bin/lwrocmerge \ > ?? ?--label=EB \ > ?? ?--port=8000 \ > ?? ?--merge-mode=event \ > ?? ?--server=trans \ > ?? ?--server=stream,flush=1 \ > ?? ?--buf=size=500Mi \ > ?? ?--max-ev-size=1Mi \ > ?? ?--eb-master=rio4l-1 \ > ?? ?--drasi=rio4l-1 \ > ?? ?--file-writer \ > ?? ?"$@" Cheers, H?kan > > However, it seems that something is missing because the DAQ fails at startup: > > > Executing 'main'. > CPUS: 1 > delay: 1 > 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: 8000). > 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: 8000). > Message not logged - thread has no error buffer yet... > HOST: RIO4L-1 > Token: 21301afe (21301afe:21301afe) [/mbsusr/mbsdaq/.drasi_tokens/blub] > 10: lwroc_hostname_util.c:460: Own address: 192.168.1.71/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:169: Started server on port 56583 (data port 34116). > 10: lwroc_net_trans.c:1808: [stream:9003] Started stream server on port 9003, data 56265. > 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-1:56583 > 10: lwroc_main.c:706: Log message rate limit not in effect. > 10: lwroc_readout.c:112: call readout_init... > 10: lwroc_thread_util.c: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:8000] (state 0) > 10: lwroc_message_internal.c:485: Message client connected! > 8: lwroc_triva_state.c:414: Waited 5 seconds for initial slave and EB connection(s): > 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 8: lwroc_triva_state.c:414: Waited 10 seconds for initial slave and EB connection(s): > 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 8: lwroc_triva_state.c:414: Waited 20 seconds for initial slave and EB connection(s): > 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 8: lwroc_triva_state.c:414: Waited 40 seconds for initial slave and EB connection(s): > 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > ^C8: lwroc_main.c:105: SIGINT received. > 10: lwroc_thread_util.c:62: Set terminate first!? (main) > 10: lwroc_thread_util.c:82: main thread done!? (Next term: data server) > 10: lwroc_thread_util.c:82: data server thread done!? (Next term: slow_async) > 10: lwroc_thread_util.c:82: slow_async thread done!? (Next term: net io) > 10: lwroc_thread_util.c:82: net io thread done!? (Next term: triva control) > Performing hardware cleanup (TRIVA HALT, RESET)... > > I would really appreciate if you could give me a hint what is going on. Many thanks! > > > > > > Best greetings > > G?nter > > > > > > > From g.weber at hi-jena.gsi.de Tue May 14 12:13:01 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 14 May 2024 10:13:01 +0000 Subject: [subexp-daq] problem when running two DAQs in parallel on one server In-Reply-To: <8ea31a3c-649c-890e-dcde-594ff34c4c26@chalmers.se> References: <77410e9c210e497dada45a595d599075@hi-jena.gsi.de>, <8ea31a3c-649c-890e-dcde-594ff34c4c26@chalmers.se> Message-ID: <242149e6d4d446af8ce5470530d0c113@hi-jena.gsi.de> Dear H?kan, thank you very much for the reply. The explanation makes sense. This is the EB command for the DAQ already running: ../drasi/bin/lwrocmerge \ --label=EB \ --port=7000 \ --merge-mode=event \ --server=trans \ --server=stream,flush=1 \ --buf=size=500Mi \ --max-ev-size=1Mi \ --eb-master=rio4l-2 \ --drasi=rio4l-2 \ --file-writer \ "$@" So, the only difference is the name "rio4l-2" in the old system vs. "rio4l-1" in the new system. And the port number "7000" vs. "8000". If "--server=trans" implicitly assumes a standard port, then this will be the same for both commands. Is there somewhere an illustration/explanation how exactly LWROCMERGE and M_READ_MEB work together? This would help a lot. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Montag, 13. Mai 2024 17:24:19 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] problem when running two DAQs in parallel on one server Possily, your second EB has not started if the first is already running, the --server=trans and --server=stream,... lines below use the default ports. And if already in use by the first process, it cannot start. Try to add port=... > ../drasi/bin/lwrocmerge \ > --label=EB \ > --port=8000 \ > --merge-mode=event \ > --server=trans \ > --server=stream,flush=1 \ > --buf=size=500Mi \ > --max-ev-size=1Mi \ > --eb-master=rio4l-1 \ > --drasi=rio4l-1 \ > --file-writer \ > "$@" Cheers, H?kan > > However, it seems that something is missing because the DAQ fails at startup: > > > Executing 'main'. > CPUS: 1 > delay: 1 > 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: 8000). > 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: 8000). > Message not logged - thread has no error buffer yet... > HOST: RIO4L-1 > Token: 21301afe (21301afe:21301afe) [/mbsusr/mbsdaq/.drasi_tokens/blub] > 10: lwroc_hostname_util.c:460: Own address: 192.168.1.71/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:169: Started server on port 56583 (data port 34116). > 10: lwroc_net_trans.c:1808: [stream:9003] Started stream server on port 9003, data 56265. > 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-1:56583 > 10: lwroc_main.c:706: Log message rate limit not in effect. > 10: lwroc_readout.c:112: call readout_init... > 10: lwroc_thread_util.c: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:8000] (state 0) > 10: lwroc_message_internal.c:485: Message client connected! > 8: lwroc_triva_state.c:414: Waited 5 seconds for initial slave and EB connection(s): > 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 8: lwroc_triva_state.c:414: Waited 10 seconds for initial slave and EB connection(s): > 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 8: lwroc_triva_state.c:414: Waited 20 seconds for initial slave and EB connection(s): > 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 8: lwroc_triva_state.c:414: Waited 40 seconds for initial slave and EB connection(s): > 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > ^C8: lwroc_main.c:105: SIGINT received. > 10: lwroc_thread_util.c:62: Set terminate first! (main) > 10: lwroc_thread_util.c:82: main thread done! (Next term: data server) > 10: lwroc_thread_util.c:82: data server thread done! (Next term: slow_async) > 10: lwroc_thread_util.c:82: slow_async thread done! (Next term: net io) > 10: lwroc_thread_util.c:82: net io thread done! (Next term: triva control) > Performing hardware cleanup (TRIVA HALT, RESET)... > > I would really appreciate if you could give me a hint what is going on. Many thanks! > > > > > > Best greetings > > G?nter > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.weber at hi-jena.gsi.de Tue May 14 12:53:32 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 14 May 2024 10:53:32 +0000 Subject: [subexp-daq] problem when running two DAQs in parallel on one server In-Reply-To: <242149e6d4d446af8ce5470530d0c113@hi-jena.gsi.de> References: <77410e9c210e497dada45a595d599075@hi-jena.gsi.de>, <8ea31a3c-649c-890e-dcde-594ff34c4c26@chalmers.se>, <242149e6d4d446af8ce5470530d0c113@hi-jena.gsi.de> Message-ID: <2fcd56a77c9e49f59c1efad5b08eb7ae@hi-jena.gsi.de> Dear all, I now found in an old folder from Bastian something helpful that I modified a bit: name=2024_Na22 rio=rio4l-1 EXP_NAME=2023_na22 EXP_PATH=/LynxOS/mbsusr/mbsdaq/daq/${EXP_NAME} MAIN_STREAM_PORT=8010 EB_TRANS_PORT=8011 EB_STREAM_PORT=8012 SERV_PORT=8013 EB_DRASI_PORT=7010 EB_MAIN=${rio} Starting DRASI now 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:${SERV_PORT} \ --server=drasi,dest=lyserv:${EB_DRASI_PORT} \ --buf=size=200Mi \ --max-ev-size=0x100000 \ --eb=lyserv:${EB_DRASI_PORT} \ --subev=crate=0,type=88,subtype=8800,control=0,procid=12 \ "$@" The EVENT BUILDER: ../drasi/bin/lwrocmerge \ --label=EB \ --port=${EB_DRASI_PORT} \ --merge-mode=event \ --server=trans:${EB_TRANS_PORT} \ --server=stream:${EB_STREAM_PORT},flush=1 \ --buf=size=500Mi \ --max-ev-size=1Mi \ --eb-master=${EB_MAIN} \ --drasi=${EB_MAIN} \ --file-writer \ "$@" The LOGGING: $EXP_PATH/drasi/bin/lwrocmon ${EB_MAIN} localhost:${EB_DRASI_PORT} --log The SERVER: while : ; do ../ucesb/empty/empty \ stream://localhost:${EB_STREAM_PORT} \ --server=stream:${SERV_PORT},flush=1 sleep 5 done It looks like the DAQ is running now. However, unfortunately, I still do not fully understand what I am doing here. Fore example, the MAIN_STREAM_PORT defined above is not used. And why is DRASI using the SERV_PORT as well as the UCESB SERVER? Sorry for all the question. And thank you so much! Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von Weber, Guenter Dr. Gesendet: Dienstag, 14. Mai 2024 12:13:01 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] problem when running two DAQs in parallel on one server Dear H?kan, thank you very much for the reply. The explanation makes sense. This is the EB command for the DAQ already running: ../drasi/bin/lwrocmerge \ --label=EB \ --port=7000 \ --merge-mode=event \ --server=trans \ --server=stream,flush=1 \ --buf=size=500Mi \ --max-ev-size=1Mi \ --eb-master=rio4l-2 \ --drasi=rio4l-2 \ --file-writer \ "$@" So, the only difference is the name "rio4l-2" in the old system vs. "rio4l-1" in the new system. And the port number "7000" vs. "8000". If "--server=trans" implicitly assumes a standard port, then this will be the same for both commands. Is there somewhere an illustration/explanation how exactly LWROCMERGE and M_READ_MEB work together? This would help a lot. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Montag, 13. Mai 2024 17:24:19 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] problem when running two DAQs in parallel on one server Possily, your second EB has not started if the first is already running, the --server=trans and --server=stream,... lines below use the default ports. And if already in use by the first process, it cannot start. Try to add port=... > ../drasi/bin/lwrocmerge \ > --label=EB \ > --port=8000 \ > --merge-mode=event \ > --server=trans \ > --server=stream,flush=1 \ > --buf=size=500Mi \ > --max-ev-size=1Mi \ > --eb-master=rio4l-1 \ > --drasi=rio4l-1 \ > --file-writer \ > "$@" Cheers, H?kan > > However, it seems that something is missing because the DAQ fails at startup: > > > Executing 'main'. > CPUS: 1 > delay: 1 > 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: 8000). > 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: 8000). > Message not logged - thread has no error buffer yet... > HOST: RIO4L-1 > Token: 21301afe (21301afe:21301afe) [/mbsusr/mbsdaq/.drasi_tokens/blub] > 10: lwroc_hostname_util.c:460: Own address: 192.168.1.71/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:169: Started server on port 56583 (data port 34116). > 10: lwroc_net_trans.c:1808: [stream:9003] Started stream server on port 9003, data 56265. > 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-1:56583 > 10: lwroc_main.c:706: Log message rate limit not in effect. > 10: lwroc_readout.c:112: call readout_init... > 10: lwroc_thread_util.c: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:8000] (state 0) > 10: lwroc_message_internal.c:485: Message client connected! > 8: lwroc_triva_state.c:414: Waited 5 seconds for initial slave and EB connection(s): > 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 8: lwroc_triva_state.c:414: Waited 10 seconds for initial slave and EB connection(s): > 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 8: lwroc_triva_state.c:414: Waited 20 seconds for initial slave and EB connection(s): > 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 8: lwroc_triva_state.c:414: Waited 40 seconds for initial slave and EB connection(s): > 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for outgoing link establishment. > ^C8: lwroc_main.c:105: SIGINT received. > 10: lwroc_thread_util.c:62: Set terminate first! (main) > 10: lwroc_thread_util.c:82: main thread done! (Next term: data server) > 10: lwroc_thread_util.c:82: data server thread done! (Next term: slow_async) > 10: lwroc_thread_util.c:82: slow_async thread done! (Next term: net io) > 10: lwroc_thread_util.c:82: net io thread done! (Next term: triva control) > Performing hardware cleanup (TRIVA HALT, RESET)... > > I would really appreciate if you could give me a hint what is going on. Many thanks! > > > > > > Best greetings > > G?nter > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Tue May 14 12:55:27 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Tue, 14 May 2024 12:55:27 +0200 Subject: [subexp-daq] problem when running two DAQs in parallel on one server In-Reply-To: <242149e6d4d446af8ce5470530d0c113@hi-jena.gsi.de> References: <77410e9c210e497dada45a595d599075@hi-jena.gsi.de>, <8ea31a3c-649c-890e-dcde-594ff34c4c26@chalmers.se> <242149e6d4d446af8ce5470530d0c113@hi-jena.gsi.de> Message-ID: <0ec0a255-0a22-5856-090e-d82633a3b082@chalmers.se> Dear G?nter, On Tue, 14 May 2024, Weber, Guenter Dr. wrote: > > > Dear H?kan, > > > thank you very much for the reply. The explanation makes sense. > > > This is the EB command for the DAQ already running: > > > ../drasi/bin/lwrocmerge \ > ?? ?--label=EB \ > ?? ?--port=7000 \ > ?? ?--merge-mode=event \ > ?? ?--server=trans \ > ?? ?--server=stream,flush=1 \ > ?? ?--buf=size=500Mi \ > ?? ?--max-ev-size=1Mi \ > ?? ?--eb-master=rio4l-2 \ > ?? ?--drasi=rio4l-2 \ > ?? ?--file-writer \ > ?? ?"$@" > > So, the only difference is the name "rio4l-2" in the old system vs. > "rio4l-1" in the new system. And the port number "7000" vs. "8000". > If > "--server=trans" implicitly assumes a standard port, then this will be the > same for both commands. A TCP port is an exclusive resource and can only be bound by one process (socket file descriptor) at a time. That should have given some error messages in the second started process like: 5: lwroc_net_io_util.c:85: Failure binding trans pmap socket to port 7234. 8: lwroc_net_io_util.c:87: Trying again in 10 s, attempt 3/20. or 5: lwroc_net_io_util.c:85: Failure binding stream socket to port 6002. 8: lwroc_net_io_util.c:87: Trying again in 10 s, attempt 3/20. > Is there somewhere an illustration/explanation how exactly LWROCMERGE and > M_READ_MEB work together? This would help a lot. Not an illustration, these may be the closest descriptions: https://fy.chalmers.se/~f96hajo/drasi/doc/drasi_getting_started.html#single-node-operation-with-trigger-module-and-event-builder and https://fy.chalmers.se/~f96hajo/drasi/doc/drasi_security.html#tcp-port-verification where I added a table at least. Agreed, a figure would be nice... Cheers, H?kan > > > > > > > > Best greetings > > G?nter > > > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan > T Johansson > Gesendet: Montag, 13. Mai 2024 17:24:19 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] problem when running two DAQs in parallel on one > server ? > > Possily, your second EB has not started if the first is already running, > the > > --server=trans? and? --server=stream,... > > lines below use the default ports.? And if already in use by the first > process, it cannot start.? Try to add port=... > > > ../drasi/bin/lwrocmerge \ > > ?? ?--label=EB \ > > ?? ?--port=8000 \ > > ?? ?--merge-mode=event \ > > ?? ?--server=trans \ > > ?? ?--server=stream,flush=1 \ > > ?? ?--buf=size=500Mi \ > > ?? ?--max-ev-size=1Mi \ > > ?? ?--eb-master=rio4l-1 \ > > ?? ?--drasi=rio4l-1 \ > > ?? ?--file-writer \ > > ?? ?"$@" > > Cheers, > H?kan > > > > > However, it seems that something is missing because the DAQ fails at > startup: > > > > > > Executing 'main'. > > CPUS: 1 > > delay: 1 > > 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: > 8000). > > 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: > 8000). > > Message not logged - thread has no error buffer yet... > > HOST: RIO4L-1 > > Token: 21301afe (21301afe:21301afe) [/mbsusr/mbsdaq/.drasi_tokens/blub] > > 10: lwroc_hostname_util.c:460: Own address: 192.168.1.71/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:169: Started server on port 56583 (data port 34116). > > 10: lwroc_net_trans.c:1808: [stream:9003] Started stream server on port > 9003, data 56265. > > 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-1:56583 > > 10: lwroc_main.c:706: Log message rate limit not in effect. > > 10: lwroc_readout.c:112: call readout_init... > > 10: lwroc_thread_util.c: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:8000] (state 0) > > 10: lwroc_message_internal.c:485: Message client connected! > > 8: lwroc_triva_state.c:414: Waited 5 seconds for initial slave and EB > connection(s): > > 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 8: lwroc_triva_state.c:414: Waited 10 seconds for initial slave and EB > connection(s): > > 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 8: lwroc_triva_state.c:414: Waited 20 seconds for initial slave and EB > connection(s): > > 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 8: lwroc_triva_state.c:414: Waited 40 seconds for initial slave and EB > connection(s): > > 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > ^C8: lwroc_main.c:105: SIGINT received. > > 10: lwroc_thread_util.c:62: Set terminate first!? (main) > > 10: lwroc_thread_util.c:82: main thread done!? (Next term: data server) > > 10: lwroc_thread_util.c:82: data server thread done!? (Next term: > slow_async) > > 10: lwroc_thread_util.c:82: slow_async thread done!? (Next term: net io) > > 10: lwroc_thread_util.c:82: net io thread done!? (Next term: triva > control) > > Performing hardware cleanup (TRIVA HALT, RESET)... > > > > I would really appreciate if you could give me a hint what is going on. > Many thanks! > > > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > > > > > > > > > > From f96hajo at chalmers.se Tue May 14 14:51:05 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Tue, 14 May 2024 14:51:05 +0200 Subject: [subexp-daq] problem when running two DAQs in parallel on one server In-Reply-To: <2fcd56a77c9e49f59c1efad5b08eb7ae@hi-jena.gsi.de> References: <77410e9c210e497dada45a595d599075@hi-jena.gsi.de>, <8ea31a3c-649c-890e-dcde-594ff34c4c26@chalmers.se>, <242149e6d4d446af8ce5470530d0c113@hi-jena.gsi.de> <2fcd56a77c9e49f59c1efad5b08eb7ae@hi-jena.gsi.de> Message-ID: On Tue, 14 May 2024, Weber, Guenter Dr. wrote: > > Dear all, > > > I now found in an old folder from Bastian something helpful that I modified > a bit: > > > name=2024_Na22 > rio=rio4l-1 > EXP_NAME=2023_na22 > EXP_PATH=/LynxOS/mbsusr/mbsdaq/daq/${EXP_NAME} > MAIN_STREAM_PORT=8010 > EB_TRANS_PORT=8011 > EB_STREAM_PORT=8012 > SERV_PORT=8013 > EB_DRASI_PORT=7010 > EB_MAIN=${rio} > > Starting DRASI now 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 \ --log-no-rate-limit should not really be used. And things have changed so I'd suggest to remove it. If a DAQ produces messages, then typically something is wrong... And the DAQ will now limit the speed of produced messages. > ?? ?--server=stream:${SERV_PORT} \ This above is just used to 'spy' on the data, so not strictly needed. > ?? ?--server=drasi,dest=lyserv:${EB_DRASI_PORT} \ > ?? ?--buf=size=200Mi \ > ?? ?--max-ev-size=0x100000 \ > ?? ?--eb=lyserv:${EB_DRASI_PORT} \ > ?? ?--subev=crate=0,type=88,subtype=8800,control=0,procid=12 \ > ?? ?"$@" > > The EVENT BUILDER: > > > ../drasi/bin/lwrocmerge \ > ?? ?--label=EB \ > ?? ?--port=${EB_DRASI_PORT} \ > ?? ?--merge-mode=event \ > ?? ?--server=trans:${EB_TRANS_PORT} \ > ?? ?--server=stream:${EB_STREAM_PORT},flush=1 \ > ?? ?--buf=size=500Mi \ > ?? ?--max-ev-size=1Mi \ > ?? ?--eb-master=${EB_MAIN} \ > ?? ?--drasi=${EB_MAIN} \ > ?? ?--file-writer \ > ?? ?"$@" > > The LOGGING: > > > $EXP_PATH/drasi/bin/lwrocmon ${EB_MAIN} localhost:${EB_DRASI_PORT} --log > > > The SERVER: > > > while : ; do > ../ucesb/empty/empty \ > ?? ?stream://localhost:${EB_STREAM_PORT} \ > ????? ??? ?--server=stream:${SERV_PORT},flush=1 > sleep 5 > done > > It looks like the DAQ is running now. However, unfortunately, I still do not > fully understand what I am doing here. Fore example, the MAIN_STREAM_PORT > defined above is not used. I guess it was used as the port for the stream server from the readout node (the one for 'spy' use above). > And why is DRASI using the SERV_PORT as well as > the UCESB SERVER? Up to the user :-) --- With several systems running partially on the same machine, it is probably a good idea to define the ports explicitly for all systems. Cheers, H?kan > > > > Sorry for all the question. And thank you so much! > > > > > > > Best greetings > > G?nter > > > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von Weber, > Guenter Dr. > Gesendet: Dienstag, 14. Mai 2024 12:13:01 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] problem when running two DAQs in parallel on one > server ? > > > Dear H?kan, > > > thank you very much for the reply. The explanation makes sense. > > > This is the EB command for the DAQ already running: > > > ../drasi/bin/lwrocmerge \ > ?? ?--label=EB \ > ?? ?--port=7000 \ > ?? ?--merge-mode=event \ > ?? ?--server=trans \ > ?? ?--server=stream,flush=1 \ > ?? ?--buf=size=500Mi \ > ?? ?--max-ev-size=1Mi \ > ?? ?--eb-master=rio4l-2 \ > ?? ?--drasi=rio4l-2 \ > ?? ?--file-writer \ > ?? ?"$@" > > So, the only difference is the name "rio4l-2" in the old system vs. > "rio4l-1" in the new system. And the port number "7000" vs. "8000". If > "--server=trans" implicitly assumes a standard port, then this will be the > same for both commands. > > > Is there somewhere an illustration/explanation how exactly LWROCMERGE and > M_READ_MEB work together? This would help a lot. > > > > > > > > Best greetings > > G?nter > > > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan > T Johansson > Gesendet: Montag, 13. Mai 2024 17:24:19 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] problem when running two DAQs in parallel on one > server ? > > Possily, your second EB has not started if the first is already running, > the > > --server=trans? and? --server=stream,... > > lines below use the default ports.? And if already in use by the first > process, it cannot start.? Try to add port=... > > > ../drasi/bin/lwrocmerge \ > > ?? ?--label=EB \ > > ?? ?--port=8000 \ > > ?? ?--merge-mode=event \ > > ?? ?--server=trans \ > > ?? ?--server=stream,flush=1 \ > > ?? ?--buf=size=500Mi \ > > ?? ?--max-ev-size=1Mi \ > > ?? ?--eb-master=rio4l-1 \ > > ?? ?--drasi=rio4l-1 \ > > ?? ?--file-writer \ > > ?? ?"$@" > > Cheers, > H?kan > > > > > However, it seems that something is missing because the DAQ fails at > startup: > > > > > > Executing 'main'. > > CPUS: 1 > > delay: 1 > > 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: > 8000). > > 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: > 8000). > > Message not logged - thread has no error buffer yet... > > HOST: RIO4L-1 > > Token: 21301afe (21301afe:21301afe) [/mbsusr/mbsdaq/.drasi_tokens/blub] > > 10: lwroc_hostname_util.c:460: Own address: 192.168.1.71/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:169: Started server on port 56583 (data port 34116). > > 10: lwroc_net_trans.c:1808: [stream:9003] Started stream server on port > 9003, data 56265. > > 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-1:56583 > > 10: lwroc_main.c:706: Log message rate limit not in effect. > > 10: lwroc_readout.c:112: call readout_init... > > 10: lwroc_thread_util.c: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:8000] (state 0) > > 10: lwroc_message_internal.c:485: Message client connected! > > 8: lwroc_triva_state.c:414: Waited 5 seconds for initial slave and EB > connection(s): > > 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 8: lwroc_triva_state.c:414: Waited 10 seconds for initial slave and EB > connection(s): > > 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 8: lwroc_triva_state.c:414: Waited 20 seconds for initial slave and EB > connection(s): > > 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 8: lwroc_triva_state.c:414: Waited 40 seconds for initial slave and EB > connection(s): > > 8: lwroc_triva_state.c:422: [EB lyserv:8000] (state 0) > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > 10: lwroc_net_outgoing.c:383: [revlink: lyserv:8000] Timeout waiting for > outgoing link establishment. > > ^C8: lwroc_main.c:105: SIGINT received. > > 10: lwroc_thread_util.c:62: Set terminate first!? (main) > > 10: lwroc_thread_util.c:82: main thread done!? (Next term: data server) > > 10: lwroc_thread_util.c:82: data server thread done!? (Next term: > slow_async) > > 10: lwroc_thread_util.c:82: slow_async thread done!? (Next term: net io) > > 10: lwroc_thread_util.c:82: net io thread done!? (Next term: triva > control) > > Performing hardware cleanup (TRIVA HALT, RESET)... > > > > I would really appreciate if you could give me a hint what is going on. > Many thanks! > > > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > > > > > > > > > > From g.weber at hi-jena.gsi.de Tue May 14 17:50:55 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 14 May 2024 15:50:55 +0000 Subject: [subexp-daq] NURDLIB - V767 output was cleaned up Message-ID: <49501a5b4c3348528ce13b6823cec64b@hi-jena.gsi.de> Dear all, a few unnecessary output words were removed from the V767A implementation. This was pushed into a new branch. Best greetings G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Tue May 14 18:00:27 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Tue, 14 May 2024 18:00:27 +0200 Subject: [subexp-daq] NURDLIB - V767 output was cleaned up In-Reply-To: <49501a5b4c3348528ce13b6823cec64b@hi-jena.gsi.de> References: <49501a5b4c3348528ce13b6823cec64b@hi-jena.gsi.de> Message-ID: <78999c89-414c-44ad-d05f-90f6287615d9@chalmers.se> Hmm, I think the ID, revision, serial number etc, typically would go to log level, so that a user need not enable verbose mode for that. (Also helps to get it into trouble reports when a log is provided.) However, to not be so spammy, those values could be printed in just on line together? I guess Hans may have some standard strategy? Cheers, H?kan On Tue, 14 May 2024, Weber, Guenter Dr. wrote: > > Dear all, > > > a few unnecessary output words were removed from the V767A implementation. > This was pushed into a new branch. > > > > > > > Best greetings > > G?nter > > > > From g.weber at hi-jena.gsi.de Tue May 14 18:34:12 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 14 May 2024 16:34:12 +0000 Subject: [subexp-daq] NURDLIB - V767 output was cleaned up In-Reply-To: <78999c89-414c-44ad-d05f-90f6287615d9@chalmers.se> References: <49501a5b4c3348528ce13b6823cec64b@hi-jena.gsi.de>, <78999c89-414c-44ad-d05f-90f6287615d9@chalmers.se> Message-ID: Sure. Just modify as necessary to conform with the standard. ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Dienstag, 14. Mai 2024 18:00:27 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] NURDLIB - V767 output was cleaned up Hmm, I think the ID, revision, serial number etc, typically would go to log level, so that a user need not enable verbose mode for that. (Also helps to get it into trouble reports when a log is provided.) However, to not be so spammy, those values could be printed in just on line together? I guess Hans may have some standard strategy? Cheers, H?kan On Tue, 14 May 2024, Weber, Guenter Dr. wrote: > > Dear all, > > > a few unnecessary output words were removed from the V767A implementation. > This was pushed into a new branch. > > > > > > > Best greetings > > G?nter > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.tornqvist at chalmers.se Wed May 15 18:28:57 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Wed, 15 May 2024 18:28:57 +0200 Subject: [subexp-daq] NURDLIB - V767 output was cleaned up In-Reply-To: References: <49501a5b4c3348528ce13b6823cec64b@hi-jena.gsi.de> <78999c89-414c-44ad-d05f-90f6287615d9@chalmers.se> Message-ID: Dear G?nter, Thanks for the fixes, I'll take a look soon. I'm currently trying to finish putting a licence and attributing authors on all files so nurdlib can go public. Cleaning up logs for all modules is a long-standing todo... Best regards, Hans On 2024-05-14 18:34, Weber, Guenter Dr. wrote: > Sure. Just modify as necessary to conform with the standard. > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > H?kan T Johansson > *Gesendet:* Dienstag, 14. Mai 2024 18:00:27 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > *Betreff:* Re: [subexp-daq] NURDLIB - V767 output was cleaned up > > Hmm, I think the ID, revision, serial number etc, typically would go to > log level, so that a user need not enable verbose mode for that.? (Also > helps to get it into trouble reports when a log is provided.) > > However, to not be so spammy, those values could be printed in just on > line together? > > I guess Hans may have some standard strategy? > > Cheers, > H?kan > > > > On Tue, 14 May 2024, Weber, Guenter Dr. wrote: > >> >> Dear all, >> >> >> a few unnecessary output words were removed from the V767A implementation. >> This was pushed into a new branch. >> >> >> >> >> >> >> Best greetings >> >> G?nter >> >> >> >> > From hans.tornqvist at chalmers.se Thu May 16 23:20:04 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Thu, 16 May 2024 23:20:04 +0200 Subject: [subexp-daq] nurdlib now under lgpl-2.1 and public Message-ID: <00402f6e-c2d5-42b2-bc3e-059b3e26d77b@chalmers.se> Dear all, I have finally parsed all nurdlib files and slapped the LGPL-2.1 on the ones that need it, reset the git history, and put the whole thing in several public places: https://github.com/hanstt/nurdlib https://git.gsi.de/r3b/nurdlib https://gitlab.com/chalmers-subexp/nurdlib https://git.chalmers.se/expsubphys/nurdlib I have extracted all authors for every file and the years of modifications according to the git history, then I reset the history to not have to worry about old mishaps (current and future ones I will have to answer for...). The old repositories were renamed to nurdlib.pregpl21 but are otherwise available in the previous locations, just not publicly. For the curious, I personally push to git.chalmers.se, which has lots of CI images that are quite painful to reproduce elsewhere. That repo then mirrors automatically to the other three. The large number of options is mainly a test to see what works. Eventually I would like to settle on "the one" or "the two" repos where pull requests, issues, and possibly even a wiki, will be maintained. I am open to suggestions and arguments! I know of some recent changes (and not so recent ones...) by others while I was doing this, those should be implemented soon, but please remind me if I seem to have forgotten. I wanted to get this live and done with after having postponed this for too long. r3bfuser... Suppose that needs to happen too. Best regards, Hans From f96hajo at chalmers.se Fri May 17 07:16:26 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Fri, 17 May 2024 07:16:26 +0200 Subject: [subexp-daq] wrtclk timestamps Message-ID: On Thu, 16 May 2024, Philipp Klenze wrote: > PPS: The wrtclk can either run with a clock of an upstream system (rataclock > 25MHz, Butis) or with an internal clock. One thing which I found is that when > the inputs get disconnected, the timestamps still increase at approximately > the correct rate when the internal clock is used. I think the main advantage > of running with the upstream clock is that it is impossible to oversee this > condition, while for the free-running clock it would depend on the precision > of the exploder oscillator how long it takes to see the drift in treeview. Or > do ratatime/rataclock transmit a "bad timestamp"-bit in these cases? The free-running (internal) clock could indeed give some 'interesting' (i.e. possibly difficult to debug) timestamp issues. The timestamp receivers (decoders) likely (when things are connected) are able to decode time, even if they would actually see things jumping and set their error outputs. But those I think are not carried further... Hmmm, the rataclock decoder should have a hard time, as it also needs the phase to stay good, but the Schakel (butis) may be quick enough... The rataclock protocol as such does not contain any error information. One could define e.g. the first aux bit to mean that upstream is locked and 'good', but for that to be useful it would require that one detect the situation well also... The T5NS measured in a clock-based VFTX or TAMEX would detect all those situations immediately however. A shift by one course counter, and any code checking it would scream 'jump'. Even a good nominal oscillator (typical within +/- 100 ppm), let's say it is great and just 0.01 ppm off, would drift by two cycles per second. Cheers, H?kan From pklenze at ph.tum.de Fri May 17 00:44:23 2024 From: pklenze at ph.tum.de (Philipp Klenze) Date: Fri, 17 May 2024 00:44:23 +0200 Subject: [subexp-daq] nurdlib now under lgpl-2.1 and public In-Reply-To: <00402f6e-c2d5-42b2-bc3e-059b3e26d77b@chalmers.se> References: <00402f6e-c2d5-42b2-bc3e-059b3e26d77b@chalmers.se> Message-ID: <95dbe0c4-17e4-9d6d-9e2e-0c3d3bcd8cf9@ph.tum.de> Dear Hans, that is great! I would prefer using either github or gitlab.com for discussion as users are more likely to already have credentials for these platforms. Also, in the docs there is one .tex file (by you) and one sphinx-file (which uses a python configuration, so possibly not by you)? It might be better to remove one of them -- I can handle pdf, I can handle rst or html, but not knowing which docs to read might not be ideal. (Also, putting the pdf on the web instead of telling people to just git clone and run make to compile the latex might be nice). Other than r3bfuser (which you mentioned) and the silly R3BRoot parameter repositories, the only thing which remains closed source is upexps. I think the two reasons blocking upexps are that (a) it is not entirely clear who contributed and (b) in the present state it would be a bit like open sourcing the Necronomicon. :) Cheers, Philipp PS: I think I have managed to figure out the rest of how wrtclk exploders operate. I have crafted nice labels for the lemo ports as well as a few caveats (for example, Bastii's serial/jumper adapter board also fits in with an offset of +/-2.54mm). The plan is to document all of this tomorrow. PPS: The wrtclk can either run with a clock of an upstream system (rataclock 25MHz, Butis) or with an internal clock. One thing which I found is that when the inputs get disconnected, the timestamps still increase at approximately the correct rate when the internal clock is used. I think the main advantage of running with the upstream clock is that it is impossible to oversee this condition, while for the free-running clock it would depend on the precision of the exploder oscillator how long it takes to see the drift in treeview. Or do ratatime/rataclock transmit a "bad timestamp"-bit in these cases? On 16/05/2024 23.20, Hans Toshihide T?rnqvist wrote: > Dear all, > > > I have finally parsed all nurdlib files and slapped the LGPL-2.1 on the > ones that need it, reset the git history, and put the whole thing in > several public places: > > https://github.com/hanstt/nurdlib > https://git.gsi.de/r3b/nurdlib > https://gitlab.com/chalmers-subexp/nurdlib > https://git.chalmers.se/expsubphys/nurdlib > > I have extracted all authors for every file and the years of > modifications according to the git history, then I reset the history to > not have to worry about old mishaps (current and future ones I will have > to answer for...). The old repositories were renamed to nurdlib.pregpl21 > but are otherwise available in the previous locations, just not publicly. > > > For the curious, I personally push to git.chalmers.se, which has lots of > CI images that are quite painful to reproduce elsewhere. That repo then > mirrors automatically to the other three. > > > The large number of options is mainly a test to see what works. > Eventually I would like to settle on "the one" or "the two" repos where > pull requests, issues, and possibly even a wiki, will be maintained. I > am open to suggestions and arguments! > > > I know of some recent changes (and not so recent ones...) by others > while I was doing this, those should be implemented soon, but please > remind me if I seem to have forgotten. I wanted to get this live and > done with after having postponed this for too long. > > > r3bfuser... Suppose that needs to happen too. > > > Best regards, > Hans From h.toernqvist at gsi.de Fri May 17 13:42:09 2024 From: h.toernqvist at gsi.de (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Fri, 17 May 2024 13:42:09 +0200 Subject: [subexp-daq] nurdlib now under lgpl-2.1 and public In-Reply-To: <95dbe0c4-17e4-9d6d-9e2e-0c3d3bcd8cf9@ph.tum.de> References: <00402f6e-c2d5-42b2-bc3e-059b3e26d77b@chalmers.se> <95dbe0c4-17e4-9d6d-9e2e-0c3d3bcd8cf9@ph.tum.de> Message-ID: <20103733-3c1c-4f7e-bd88-b39131f22af1@gsi.de> Dear Philipp et al., That was enough suggestions for me regarding the online repos, I will consider the following two in the future: https://github.com/nustardaq/nurdlib https://gitlab.com/chalmers-subexp/nurdlib The others are available for now and should be synced, but if they break they will probably be removed. I created the 'nustardaq' Github team for this and am currently the leader I suppose. Definitely not intentional, I will happily relinquish that role :) The docu needs a kick I agree. I will keep the current options, but will move towards the Sphinx page being a cheat sheet and the pdf the dry reference. The pdf should be easier to get, yes. I see quite a few names in the upexps git history, so that should not be the obstacle. Best regards, Hans On 2024-05-17 00:44, Philipp Klenze wrote: > Dear Hans, > that is great! > > I would prefer using either github or gitlab.com for discussion as users > are more likely to already have credentials for these platforms. > > Also, in the docs there is one .tex file (by you) and one sphinx-file > (which uses a python configuration, so possibly not by you)? It might be > better to remove one of them -- I can handle pdf, I can handle rst or > html, but not knowing which docs to read might not be ideal. (Also, > putting the pdf on the web instead of telling people to just git clone > and run make to compile the latex might be nice). > > Other than r3bfuser (which you mentioned) and the silly R3BRoot > parameter repositories, the only thing which remains closed source is > upexps. I think the two reasons blocking upexps are that (a) it is not > entirely clear who contributed and (b) in the present state it would be > a bit like open sourcing the Necronomicon. :) > > Cheers, > Philipp > > PS: I think I have managed to figure out the rest of how wrtclk > exploders operate. I have crafted nice labels for the lemo ports as well > as a few caveats (for example, Bastii's serial/jumper adapter board also > fits in with an offset of +/-2.54mm). The plan is to document all of > this tomorrow. > > PPS: The wrtclk can either run with a clock of an upstream system > (rataclock 25MHz, Butis) or with an internal clock. One thing which I > found is that when the inputs get disconnected, the timestamps still > increase at approximately the correct rate when the internal clock is > used. I think the main advantage of running with the upstream clock is > that it is impossible to oversee this condition, while for the > free-running clock it would depend on the precision of the exploder > oscillator how long it takes to see the drift in treeview. Or do > ratatime/rataclock transmit a "bad timestamp"-bit in these cases? > > On 16/05/2024 23.20, Hans Toshihide T?rnqvist wrote: >> Dear all, >> >> >> I have finally parsed all nurdlib files and slapped the LGPL-2.1 on >> the ones that need it, reset the git history, and put the whole thing >> in several public places: >> >> https://github.com/hanstt/nurdlib >> https://git.gsi.de/r3b/nurdlib >> https://gitlab.com/chalmers-subexp/nurdlib >> https://git.chalmers.se/expsubphys/nurdlib >> >> I have extracted all authors for every file and the years of >> modifications according to the git history, then I reset the history >> to not have to worry about old mishaps (current and future ones I will >> have to answer for...). The old repositories were renamed to >> nurdlib.pregpl21 but are otherwise available in the previous >> locations, just not publicly. >> >> >> For the curious, I personally push to git.chalmers.se, which has lots >> of CI images that are quite painful to reproduce elsewhere. That repo >> then mirrors automatically to the other three. >> >> >> The large number of options is mainly a test to see what works. >> Eventually I would like to settle on "the one" or "the two" repos >> where pull requests, issues, and possibly even a wiki, will be >> maintained. I am open to suggestions and arguments! >> >> >> I know of some recent changes (and not so recent ones...) by others >> while I was doing this, those should be implemented soon, but please >> remind me if I seem to have forgotten. I wanted to get this live and >> done with after having postponed this for too long. >> >> >> r3bfuser... Suppose that needs to happen too. >> >> >> Best regards, >> Hans From g.weber at hi-jena.gsi.de Fri May 24 16:42:33 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Fri, 24 May 2024 14:42:33 +0000 Subject: [subexp-daq] Question on trlo_ctrl with option --trig-status In-Reply-To: <21a0486d-cd94-a93a-f677-2bd1e2bf4bb5@chalmers.se> References: <36c79ac1-dcce-052e-ce02-1783a3fb383e@chalmers.se> <0ff5bfa61f5544fa93742c4ff2da59a3@hi-jena.gsi.de> <743E497D-9BBD-418C-A40C-1EA2FDBBFCCA@chalmers.se> <5cdf2fcf92bf432bad243eca8e917b4a@hi-jena.gsi.de> <93276dae-2037-4c8a-b247-5b065336089d@chalmers.se> <53bcb3db-1ea5-43db-9e4e-7a77238dd899@chalmers.se> <62267106fb284e50b805b9dba09b8483@hi-jena.gsi.de>, <423e14dd-73a9-4fbc-b106-4856cb1e1997@chalmers.se> <3c091e0197404e4b85562bb5a0559906@hi-jena.gsi.de>, <21a0486d-cd94-a93a-f677-2bd1e2bf4bb5@chalmers.se> Message-ID: Dear H?kan, to me it looks like $VULOM4_CTRL --addr=$addr --trig-status starts a never ending printout of the current status of the VULOM. Is there a possibility to just get the status a single time and then stop the execution? My intention is to check, after setting up the VULOM, when synchronization is done and it is safe to start the DAQ. Many thanks and best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Donnerstag, 22. Februar 2024 17:06 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] Report of a possible bug of the CAEN_V560 module On Thu, 22 Feb 2024, Weber, Guenter Dr. wrote: > > Dear Hans, > > > many thanks! And in particular for all the detailed explanations. > > > For the VULOM "sleep 1" did not do the trick, but "sleep 10" worked. Is > there any chance to ask the VULOM if it feels ready to do the job, instead > of using a random waiting time? Now there is! Update trloii and recompile trlo_ctrl, --trig-status will at the end show some extra lines: Serial timestamp status:(0x000a8004) words: 4 badbits: 0 CHKsum:0x00 Serial timestamp: Sync: no Bitstr. sync: no, had loss Data ptn: no, had loss Where it should say "Sync: ok" when the receiver has locked. The 'had loss' and bad bits count can be cleared (when locked) by issuing "pulse = SERIAL_TSTAMP_FAIL_CLEAR" > Also I noticed that when aksing the VULOM which firmware it is using, we get > a slightly different reply than the actual firmware number: > > RIO4-MCAL-1 mbsdaq > vulomflash --addr=3 --read > VULOM base address: 0x03000000 > hwmap_mapvme.c:398: LOG: Virtual address for VULOM/TRIDI @ VME 0x03000000 is > 0x3005e000. > Performing command 'read'... > VOLUM+0 => 0x14091f20 > VOLUM+RANGE_REG(0x800000) => 0x0000006a > Released vme ptr. > But the actual firmware number is 1409285e. > > For comparison should one look only at the first four hex numbers? Or is > there more to take into account? Yes, vulomflash --read reads at offset 0, and at that offset is also a TRIVA module mimic, which only uses the low 16 bits however. So the high 16 bits give part of the firmware hash. > For the V560 module, misusing the bitmask for the counter resolved the > issue. At the end of this mail, I attach the new log. Maybe you find > something notable, but to me it looks fine now. > > > Our next steps would be as follows: > > > 1) Wait for you to implement the bugfixes of the last days into NURDLIB. > > 2) Setting up the test system with the most recent version of NURDLIB and > checking, if our minimal system with VULOM and V560 is now running smoothly. > > 3) Hammering the V767 TDC into NURDLIB. > > 4) Once we have achieved this, we would go back to testing the SIS3316 > modules. > > > > Best greetings > > G?nter Cheers, H?kan -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.weber at hi-jena.gsi.de Fri May 24 17:45:47 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Fri, 24 May 2024 15:45:47 +0000 Subject: [subexp-daq] Question on NURDLIB - where SIS3316_rebased went? Message-ID: <482985fc673d4d3f926eb9d69a86c5a0@hi-jena.gsi.de> Dear friends, I just pulled the most recent NURDLIB version and noticed that it comes with the very old SIS3316 implementation. My uderstanding was that all our fixes and changes were sitting in the other branch and where not (finally) merged with the main branch as testing was still pending on our side. Is there a chance to get the old branch back? Otherwise I will copy everything regarding SIS3316 from our test system into the new NUPELINE version and give it a go. Best greetings G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Fri May 24 20:50:01 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Fri, 24 May 2024 20:50:01 +0200 Subject: [subexp-daq] Question on trlo_ctrl with option --trig-status In-Reply-To: References: <36c79ac1-dcce-052e-ce02-1783a3fb383e@chalmers.se> <0ff5bfa61f5544fa93742c4ff2da59a3@hi-jena.gsi.de> <743E497D-9BBD-418C-A40C-1EA2FDBBFCCA@chalmers.se> <5cdf2fcf92bf432bad243eca8e917b4a@hi-jena.gsi.de> <93276dae-2037-4c8a-b247-5b065336089d@chalmers.se> <53bcb3db-1ea5-43db-9e4e-7a77238dd899@chalmers.se> <62267106fb284e50b805b9dba09b8483@hi-jena.gsi.de>, <423e14dd-73a9-4fbc-b106-4856cb1e1997@chalmers.se> <3c091e0197404e4b85562bb5a0559906@hi-jena.gsi.de>, <21a0486d-cd94-a93a-f677-2bd1e2bf4bb5@chalmers.se> Message-ID: On Fri, 24 May 2024, Weber, Guenter Dr. wrote: > > Dear H?kan, > > > to me it looks like > > > $VULOM4_CTRL --addr=$addr --trig-status > > starts a never ending printout of the current status of the VULOM. > > Is there a possibility to just get the status a single time and then stop > the execution? > > My intention is to check, after setting up the VULOM, when synchronization > is done and it is safe to start the DAQ. --trig-status=0 apparently does that. I have documented that in the --help text now. Thanks! H?kan > > > > Many thanks and best greetings > G?nter > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan > T Johansson > Gesendet: Donnerstag, 22. Februar 2024 17:06 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] Report of a possible bug of the CAEN_V560 module ? > > On Thu, 22 Feb 2024, Weber, Guenter Dr. wrote: > > > > > Dear Hans, > > > > > > many thanks! And in particular for all the detailed explanations. > > > > > > For the VULOM "sleep 1" did not do the trick, but "sleep 10" worked. Is > > there any chance to ask the VULOM if it feels ready to do the job, instead > > of using a random waiting time? > > Now there is!? Update trloii and recompile trlo_ctrl, > > ?? --trig-status?? will at the end show some extra lines: > > Serial timestamp status:(0x000a8004) words:? 4 badbits: 0 CHKsum:0x00 > Serial timestamp: Sync: no? Bitstr. sync: no, had loss? Data ptn: no, had > loss > > Where it should say "Sync: ok" when the receiver has locked. > > The 'had loss' and bad bits count can be cleared (when locked) by issuing > ?? "pulse = SERIAL_TSTAMP_FAIL_CLEAR" > > > Also I noticed that when aksing the VULOM which firmware it is using, we > get > > a slightly different reply than the actual firmware number: > > > > RIO4-MCAL-1 mbsdaq > vulomflash --addr=3 --read > > VULOM base address: 0x03000000 > > hwmap_mapvme.c:398: LOG: Virtual address for VULOM/TRIDI @ VME 0x03000000 > is > > 0x3005e000. > > Performing command 'read'... > > VOLUM+0 => 0x14091f20 > > VOLUM+RANGE_REG(0x800000) => 0x0000006a > > Released vme ptr. > > But the actual firmware number is 1409285e. > > > > For comparison should one look only at the first four hex numbers? Or is > > there more to take into account? > > Yes, vulomflash --read reads at offset 0, and at that offset is also a > TRIVA module mimic, which only uses the low 16 bits however.? So the high > 16 bits give part of the firmware hash. > > > For the V560 module, misusing the bitmask for the counter?resolved the > > issue. At the end of this mail, I attach the new log. Maybe you find > > something notable, but to me it looks fine now. > > > > > > Our next steps would be as follows: > > > > > > 1) Wait for you to implement the bugfixes of the last days into NURDLIB. > > > > 2) Setting up the test system with the most recent version of NURDLIB and > > checking, if our minimal system with VULOM and V560 is now running > smoothly. > > > > 3) Hammering the V767 TDC into NURDLIB. > > > > 4) Once we have achieved this, we would go back to testing the SIS3316 > > modules. > > > > > > > > Best greetings > > > > G?nter > > Cheers, > H?kan > > > > > From f96hajo at chalmers.se Fri May 24 21:22:20 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Fri, 24 May 2024 21:22:20 +0200 Subject: [subexp-daq] Question on NURDLIB - where SIS3316_rebased went? In-Reply-To: <482985fc673d4d3f926eb9d69a86c5a0@hi-jena.gsi.de> References: <482985fc673d4d3f926eb9d69a86c5a0@hi-jena.gsi.de> Message-ID: Dear G?nter, I have transplanted the commit series from the old repository with 'git format-patch' and 'git 'am'. Only one commit that just added an limits.h include had issues, so I hope it should be fine. Pushed to the new repository as branch 'sis3316_reborn'. Please test. Cheers, H?kan On Fri, 24 May 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > I just pulled the most recent NURDLIB version and noticed that it comes with > the very old SIS3316 implementation. My uderstanding was that all our fixes > and changes were sitting in the other branch and where not (finally) merged > with the main branch as testing was still pending on our side. > > > Is there a chance to get the old branch back? Otherwise I will copy > everything regarding SIS3316 from our test system into the new NUPELINE > version and give it a go. > > > > > > > Best greetings > > G?nter > > > > From g.weber at hi-jena.gsi.de Wed May 29 14:47:57 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Wed, 29 May 2024 12:47:57 +0000 Subject: [subexp-daq] NURDLIB - SIS3316 - problem with RATACLOCK Message-ID: <4c182daf7e4e4450bd929a5a2adbc203@hi-jena.gsi.de> Dear friends, in the merged SIS3316 code we found RATACLOCK, which does not exist (at least not under this name) in the module interface that we took over from Bastian. I also cannot find RATACLOCK in the manual from STRUCK. For a bunch of firmware versions it is hardcoded that HAS_RATACLOCK_RECEIVER is true. if (firmware == 0x33165010 || firmware == 0x3316b011 || firmware == 0x3316a012 || firmware == 0x3316b012) { m->config.has_rataclock_receiver = 1; } It happens that one of our modules has indeed firmware version 0x3316a012. So, this variable is set to true. This results in the following check: void sis_3316_test_clock_sync(struct Sis3316Module *self) { /* test, if all clocks are still synced */ if (self->config.has_rataclock_receiver == 1) { int tries_left = 3; int ok = 1; while (tries_left > 0) { int i; for (i = 0; i < N_ADCS; ++i) { uint32_t status = MAP_READ(self->sicy_map, fpga_adc_rataser_status1(i)); int sync = status & 0x7; int lost = (status >> 4) & 0x7; int auto_edge = self->config.rataclock_use_auto_edge; if (sync != 7) { log_error(LOGL, NAME " ADC%d clock not synced " "(sync = %d) " "(tries_left = %d)", i, sync, tries_left); ok = 0; } if (lost != 0) { log_error(LOGL, NAME " ADC%d clock lost sync" "(lost = %d)", i, lost); ok = 0; MAP_WRITE(self->sicy_map, fpga_adc_rataser_control2(i), (1 << 31) | (auto_edge << 2)); } } if (ok == 0) { tries_left -= 1; time_sleep(1e-3); } else { LOGF(debug)(LOGL, "rataser clock synced."); break; } MAP_WRITE(self->sicy_map, reset_adc_clock, 0x0); time_sleep(30e-3); } } } And we receive an error message that our ADCs are not synchronized. As I have no idea what RATACLOCK is, it is hard for me to figure out what is happening. However, there is also the parameter USE_RATACLOCK. It is set to 0 by default. So, maybe it is simply a bug that the check for synchronization is executed just on the basis of if (self->config.has_rataclock_receiver == 1), while not also checking for if (self->config.use_rataclock == 1)? But shouldn't the expectation be that the ADCs are always synchronized? So, maybe this is still a problem with the configuration of our module? Sorry for this confusion. I would really appreciate if someone could explain what is going on here ? Best greetings from Jena G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Wed May 29 17:05:13 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Wed, 29 May 2024 17:05:13 +0200 Subject: [subexp-daq] NURDLIB - SIS3316 - problem with RATACLOCK In-Reply-To: <4c182daf7e4e4450bd929a5a2adbc203@hi-jena.gsi.de> References: <4c182daf7e4e4450bd929a5a2adbc203@hi-jena.gsi.de> Message-ID: Dear G?nter, Background: Rataclock is a one-wire serial protocol to distribute clock _and_ time. It sends a clock signal where the leading edges are periodic and can be used to drive PLL (e.g. inside the main and ADC FPGAs) and the trailing edges are made shorter and longer to encode information about the time. Thus modules can collect data synchronously, without the need to 'reset' the time or such means. Since the clock is PLL-recovered in each ADC FPGA, it also needs to be checked that ist works in each of them. More below inline...: On Wed, 29 May 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > in the merged SIS3316 code we found RATACLOCK, which does not exist (at > least not under this name) in the module interface that we took over from > Bastian. I also cannot find RATACLOCK in the manual from STRUCK. > > > For a bunch of firmware versions it is hardcoded that HAS_RATACLOCK_RECEIVER > is true. > > > ??? if (firmware == 0x33165010 || firmware == 0x3316b011 > ?? ???? || firmware == 0x3316a012 || firmware == 0x3316b012) { > ?? ??? ?m->config.has_rataclock_receiver = 1; > ?? ?} > > It happens that one of our modules has indeed firmware version 0x3316a012. > So, this variable is set to true. This results in the following check: > > > void > sis_3316_test_clock_sync(struct Sis3316Module *self) > { > ?? ?/* test, if all clocks are still synced */ > ?? ?if (self->config.has_rataclock_receiver == 1) { > ?? ??? ?int tries_left = 3; > ?? ??? ?int ok = 1; > > ?? ??? ?while (tries_left > 0) { > ?? ??? ??? ?int i; > > ?? ??? ??? ?for (i = 0; i < N_ADCS; ++i) { > ?? ??? ??? ??? ?uint32_t status = MAP_READ(self->sicy_map, > ?? ??? ??? ??? ???? fpga_adc_rataser_status1(i)); > ?? ??? ??? ??? ?int sync = status & 0x7; > ?? ??? ??? ??? ?int lost = (status >> 4) & 0x7; > ?? ??? ??? ??? ?int auto_edge = > ?? ??? ??? ??? ???? self->config.rataclock_use_auto_edge; > ?? ??? ??? ??? ?if (sync != 7) { > ?? ??? ??? ??? ??? ?log_error(LOGL, NAME > ?? ??? ??? ??? ??? ???? " ADC%d clock not synced " > ?? ??? ??? ??? ??? ???? "(sync = %d) " > ?? ??? ??? ??? ??? ???? "(tries_left = %d)", i, sync, > ?? ??? ??? ??? ??? ???? tries_left); > ?? ??? ??? ??? ??? ?ok = 0; > ?? ??? ??? ??? ?} > ?? ??? ??? ??? ?if (lost != 0) { > ?? ??? ??? ??? ??? ?log_error(LOGL, NAME > ?? ??? ??? ??? ??? ???? " ADC%d clock lost sync" > ?? ??? ??? ??? ??? ???? "(lost = %d)", i, lost); > ?? ??? ??? ??? ??? ?ok = 0; > ?? ??? ??? ??? ??? ?MAP_WRITE(self->sicy_map, > ?? ??? ??? ??? ??? ???? fpga_adc_rataser_control2(i), > ?? ??? ??? ??? ??? ???? (1 << 31) | (auto_edge << 2)); > > ?? ??? ??? ??? ?} > ?? ??? ??? ?} > ?? ??? ??? ?if (ok == 0) { > ?? ??? ??? ??? ?tries_left -= 1; > ?? ??? ??? ??? ?time_sleep(1e-3); > ?? ??? ??? ?} else { > ?? ??? ??? ??? ?LOGF(debug)(LOGL, "rataser clock synced."); > ?? ??? ??? ??? ?break; > ?? ??? ??? ?} > ?? ??? ??? ?MAP_WRITE(self->sicy_map, reset_adc_clock, 0x0); > ?? ??? ??? ?time_sleep(30e-3); > ?? ??? ?} > ?? ?} > } > > And we receive an error message that our ADCs are not synchronized. As I > have no idea what RATACLOCK is, it is hard for me to figure out what is > happening. > > > However, there is also the parameter USE_RATACLOCK. It is set to 0 by > default. So, maybe it is simply a bug that the check for synchronization is > executed just on the basis of if (self->config.has_rataclock_receiver == 1), > while not also checking for if (self->config.use_rataclock == 1)? It sounds like it. Could you see if things work if you add such a check (i.e. only do that rataclock sync check if use_rataclock == 1)? > But shouldn't the expectation be that the ADCs are always synchronized? So, > maybe this is still a problem with the configuration of our module? > > > Sorry for this confusion. I would really appreciate if someone could explain > what is going on here ? Cheers, H?kan From g.weber at hi-jena.gsi.de Thu May 30 17:35:51 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Thu, 30 May 2024 15:35:51 +0000 Subject: [subexp-daq] NURDLIB - SIS3316 - problem with RATACLOCK In-Reply-To: References: <4c182daf7e4e4450bd929a5a2adbc203@hi-jena.gsi.de>, Message-ID: <9d832296fd54497eacaca3426b22175a@hi-jena.gsi.de> Dear H?kan, thank you very much for explanation. I pushed a new NURDLIB version with a corrected if-statement at the beginning of the RATACLOCK ADC snyc test. Also for aesthetics, I moved the firmware check to a separate function. Please have a look, if this makes sense. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Mittwoch, 29. Mai 2024 17:05:13 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] NURDLIB - SIS3316 - problem with RATACLOCK Dear G?nter, Background: Rataclock is a one-wire serial protocol to distribute clock _and_ time. It sends a clock signal where the leading edges are periodic and can be used to drive PLL (e.g. inside the main and ADC FPGAs) and the trailing edges are made shorter and longer to encode information about the time. Thus modules can collect data synchronously, without the need to 'reset' the time or such means. Since the clock is PLL-recovered in each ADC FPGA, it also needs to be checked that ist works in each of them. More below inline...: On Wed, 29 May 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > in the merged SIS3316 code we found RATACLOCK, which does not exist (at > least not under this name) in the module interface that we took over from > Bastian. I also cannot find RATACLOCK in the manual from STRUCK. > > > For a bunch of firmware versions it is hardcoded that HAS_RATACLOCK_RECEIVER > is true. > > > if (firmware == 0x33165010 || firmware == 0x3316b011 > || firmware == 0x3316a012 || firmware == 0x3316b012) { > m->config.has_rataclock_receiver = 1; > } > > It happens that one of our modules has indeed firmware version 0x3316a012. > So, this variable is set to true. This results in the following check: > > > void > sis_3316_test_clock_sync(struct Sis3316Module *self) > { > /* test, if all clocks are still synced */ > if (self->config.has_rataclock_receiver == 1) { > int tries_left = 3; > int ok = 1; > > while (tries_left > 0) { > int i; > > for (i = 0; i < N_ADCS; ++i) { > uint32_t status = MAP_READ(self->sicy_map, > fpga_adc_rataser_status1(i)); > int sync = status & 0x7; > int lost = (status >> 4) & 0x7; > int auto_edge = > self->config.rataclock_use_auto_edge; > if (sync != 7) { > log_error(LOGL, NAME > " ADC%d clock not synced " > "(sync = %d) " > "(tries_left = %d)", i, sync, > tries_left); > ok = 0; > } > if (lost != 0) { > log_error(LOGL, NAME > " ADC%d clock lost sync" > "(lost = %d)", i, lost); > ok = 0; > MAP_WRITE(self->sicy_map, > fpga_adc_rataser_control2(i), > (1 << 31) | (auto_edge << 2)); > > } > } > if (ok == 0) { > tries_left -= 1; > time_sleep(1e-3); > } else { > LOGF(debug)(LOGL, "rataser clock synced."); > break; > } > MAP_WRITE(self->sicy_map, reset_adc_clock, 0x0); > time_sleep(30e-3); > } > } > } > > And we receive an error message that our ADCs are not synchronized. As I > have no idea what RATACLOCK is, it is hard for me to figure out what is > happening. > > > However, there is also the parameter USE_RATACLOCK. It is set to 0 by > default. So, maybe it is simply a bug that the check for synchronization is > executed just on the basis of if (self->config.has_rataclock_receiver == 1), > while not also checking for if (self->config.use_rataclock == 1)? It sounds like it. Could you see if things work if you add such a check (i.e. only do that rataclock sync check if use_rataclock == 1)? > But shouldn't the expectation be that the ADCs are always synchronized? So, > maybe this is still a problem with the configuration of our module? > > > Sorry for this confusion. I would really appreciate if someone could explain > what is going on here ? Cheers, H?kan -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Thu May 30 17:59:28 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Thu, 30 May 2024 17:59:28 +0200 Subject: [subexp-daq] NURDLIB - SIS3316 - problem with RATACLOCK In-Reply-To: <9d832296fd54497eacaca3426b22175a@hi-jena.gsi.de> References: <4c182daf7e4e4450bd929a5a2adbc203@hi-jena.gsi.de>, <9d832296fd54497eacaca3426b22175a@hi-jena.gsi.de> Message-ID: <9ed2a659-b652-de4d-698a-2fbc5e30ce76@chalmers.se> Dear G?nter, to me it makes sense. Also, since has_rataclock_receiver is checked elsewhere when user tries to have use_rataclock, only checking for that looks good. (Only would be that stdbool.h seems not needed. But Hans will remove that then :) ) The big question: does it work? Cheers, H?kan On Thu, 30 May 2024, Weber, Guenter Dr. wrote: > > Dear H?kan, > > > thank you very much for explanation. I pushed a new NURDLIB version with a > corrected if-statement at the beginning of the RATACLOCK ADC snyc test. Also > for aesthetics, I moved the firmware check to a separate function. > > > Please have a look, if this makes sense. > > > > > > Best greetings > > G?nter > > > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan > T Johansson > Gesendet: Mittwoch, 29. Mai 2024 17:05:13 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] NURDLIB - SIS3316 - problem with RATACLOCK ? > > Dear G?nter, > > Background: > > Rataclock is a one-wire serial protocol to distribute clock _and_ time. > It sends a clock signal where the leading edges are periodic and can be > used to drive PLL (e.g. inside the main and ADC FPGAs) and the trailing > edges are made shorter and longer to encode information about the time. > > Thus modules can collect data synchronously, without the need to 'reset' > the time or such means. > > Since the clock is PLL-recovered in each ADC FPGA, it also needs to be > checked that ist works in each of them. > > More below inline...: > > On Wed, 29 May 2024, Weber, Guenter Dr. wrote: > > > > > Dear friends, > > > > > > in the merged SIS3316 code we found RATACLOCK, which does not exist (at > > least not under this name) in the module interface that we took over from > > Bastian. I also cannot find RATACLOCK in the manual from STRUCK. > > > > > > For a bunch of firmware versions it is hardcoded that > HAS_RATACLOCK_RECEIVER > > is true. > > > > > > ??? if (firmware == 0x33165010 || firmware == 0x3316b011 > > ?? ???? || firmware == 0x3316a012 || firmware == 0x3316b012) { > > ?? ??? ?m->config.has_rataclock_receiver = 1; > > ?? ?} > > > > It happens that one of our modules has indeed firmware version 0x3316a012. > > So, this variable is set to true. This results in the following check: > > > > > > void > > sis_3316_test_clock_sync(struct Sis3316Module *self) > > { > > ?? ?/* test, if all clocks are still synced */ > > ?? ?if (self->config.has_rataclock_receiver == 1) { > > ?? ??? ?int tries_left = 3; > > ?? ??? ?int ok = 1; > > > > ?? ??? ?while (tries_left > 0) { > > ?? ??? ??? ?int i; > > > > ?? ??? ??? ?for (i = 0; i < N_ADCS; ++i) { > > ?? ??? ??? ??? ?uint32_t status = MAP_READ(self->sicy_map, > > ?? ??? ??? ??? ???? fpga_adc_rataser_status1(i)); > > ?? ??? ??? ??? ?int sync = status & 0x7; > > ?? ??? ??? ??? ?int lost = (status >> 4) & 0x7; > > ?? ??? ??? ??? ?int auto_edge = > > ?? ??? ??? ??? ???? self->config.rataclock_use_auto_edge; > > ?? ??? ??? ??? ?if (sync != 7) { > > ?? ??? ??? ??? ??? ?log_error(LOGL, NAME > > ?? ??? ??? ??? ??? ???? " ADC%d clock not synced " > > ?? ??? ??? ??? ??? ???? "(sync = %d) " > > ?? ??? ??? ??? ??? ???? "(tries_left = %d)", i, sync, > > ?? ??? ??? ??? ??? ???? tries_left); > > ?? ??? ??? ??? ??? ?ok = 0; > > ?? ??? ??? ??? ?} > > ?? ??? ??? ??? ?if (lost != 0) { > > ?? ??? ??? ??? ??? ?log_error(LOGL, NAME > > ?? ??? ??? ??? ??? ???? " ADC%d clock lost sync" > > ?? ??? ??? ??? ??? ???? "(lost = %d)", i, lost); > > ?? ??? ??? ??? ??? ?ok = 0; > > ?? ??? ??? ??? ??? ?MAP_WRITE(self->sicy_map, > > ?? ??? ??? ??? ??? ???? fpga_adc_rataser_control2(i), > > ?? ??? ??? ??? ??? ???? (1 << 31) | (auto_edge << 2)); > > > > ?? ??? ??? ??? ?} > > ?? ??? ??? ?} > > ?? ??? ??? ?if (ok == 0) { > > ?? ??? ??? ??? ?tries_left -= 1; > > ?? ??? ??? ??? ?time_sleep(1e-3); > > ?? ??? ??? ?} else { > > ?? ??? ??? ??? ?LOGF(debug)(LOGL, "rataser clock synced."); > > ?? ??? ??? ??? ?break; > > ?? ??? ??? ?} > > ?? ??? ??? ?MAP_WRITE(self->sicy_map, reset_adc_clock, 0x0); > > ?? ??? ??? ?time_sleep(30e-3); > > ?? ??? ?} > > ?? ?} > > } > > > > And we receive an error message that our ADCs are not synchronized. As I > > have no idea what RATACLOCK is, it is hard for me to figure out what is > > happening. > > > > > > However, there is also the parameter USE_RATACLOCK. It is set to 0 by > > default. So, maybe it is simply a bug that the check for synchronization > is > > executed just on the basis of if (self->config.has_rataclock_receiver == > 1), > > while not also checking for if (self->config.use_rataclock == 1)? > > It sounds like it.? Could you see if things work if you add such a check > (i.e. only do that rataclock sync check if use_rataclock == 1)? > > > But shouldn't the expectation be that the ADCs are always synchronized? > So, > > maybe this is still a problem with the configuration of our module? > > > > > > Sorry for this confusion. I would really appreciate if someone could > explain > > what is going on here ? > > Cheers, > H?kan > > From g.weber at hi-jena.gsi.de Thu May 30 18:28:09 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Thu, 30 May 2024 16:28:09 +0000 Subject: [subexp-daq] NURDLIB - SIS3316 - problem with RATACLOCK In-Reply-To: <9ed2a659-b652-de4d-698a-2fbc5e30ce76@chalmers.se> References: <4c182daf7e4e4450bd929a5a2adbc203@hi-jena.gsi.de>, <9d832296fd54497eacaca3426b22175a@hi-jena.gsi.de>, <9ed2a659-b652-de4d-698a-2fbc5e30ce76@chalmers.se> Message-ID: <4dd5487913f84b048532bb3c8ef4a1e0@hi-jena.gsi.de> Yes, bool is not used anywhere. It was a remnant from playing around with the code. Sorry. DAQ is running now without error messages. If also the output data is correct, I will check tomorrow. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Donnerstag, 30. Mai 2024 17:59:28 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] NURDLIB - SIS3316 - problem with RATACLOCK Dear G?nter, to me it makes sense. Also, since has_rataclock_receiver is checked elsewhere when user tries to have use_rataclock, only checking for that looks good. (Only would be that stdbool.h seems not needed. But Hans will remove that then :) ) The big question: does it work? Cheers, H?kan On Thu, 30 May 2024, Weber, Guenter Dr. wrote: > > Dear H?kan, > > > thank you very much for explanation. I pushed a new NURDLIB version with a > corrected if-statement at the beginning of the RATACLOCK ADC snyc test. Also > for aesthetics, I moved the firmware check to a separate function. > > > Please have a look, if this makes sense. > > > > > > Best greetings > > G?nter > > > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan > T Johansson > Gesendet: Mittwoch, 29. Mai 2024 17:05:13 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] NURDLIB - SIS3316 - problem with RATACLOCK > > Dear G?nter, > > Background: > > Rataclock is a one-wire serial protocol to distribute clock _and_ time. > It sends a clock signal where the leading edges are periodic and can be > used to drive PLL (e.g. inside the main and ADC FPGAs) and the trailing > edges are made shorter and longer to encode information about the time. > > Thus modules can collect data synchronously, without the need to 'reset' > the time or such means. > > Since the clock is PLL-recovered in each ADC FPGA, it also needs to be > checked that ist works in each of them. > > More below inline...: > > On Wed, 29 May 2024, Weber, Guenter Dr. wrote: > > > > > Dear friends, > > > > > > in the merged SIS3316 code we found RATACLOCK, which does not exist (at > > least not under this name) in the module interface that we took over from > > Bastian. I also cannot find RATACLOCK in the manual from STRUCK. > > > > > > For a bunch of firmware versions it is hardcoded that > HAS_RATACLOCK_RECEIVER > > is true. > > > > > > if (firmware == 0x33165010 || firmware == 0x3316b011 > > || firmware == 0x3316a012 || firmware == 0x3316b012) { > > m->config.has_rataclock_receiver = 1; > > } > > > > It happens that one of our modules has indeed firmware version 0x3316a012. > > So, this variable is set to true. This results in the following check: > > > > > > void > > sis_3316_test_clock_sync(struct Sis3316Module *self) > > { > > /* test, if all clocks are still synced */ > > if (self->config.has_rataclock_receiver == 1) { > > int tries_left = 3; > > int ok = 1; > > > > while (tries_left > 0) { > > int i; > > > > for (i = 0; i < N_ADCS; ++i) { > > uint32_t status = MAP_READ(self->sicy_map, > > fpga_adc_rataser_status1(i)); > > int sync = status & 0x7; > > int lost = (status >> 4) & 0x7; > > int auto_edge = > > self->config.rataclock_use_auto_edge; > > if (sync != 7) { > > log_error(LOGL, NAME > > " ADC%d clock not synced " > > "(sync = %d) " > > "(tries_left = %d)", i, sync, > > tries_left); > > ok = 0; > > } > > if (lost != 0) { > > log_error(LOGL, NAME > > " ADC%d clock lost sync" > > "(lost = %d)", i, lost); > > ok = 0; > > MAP_WRITE(self->sicy_map, > > fpga_adc_rataser_control2(i), > > (1 << 31) | (auto_edge << 2)); > > > > } > > } > > if (ok == 0) { > > tries_left -= 1; > > time_sleep(1e-3); > > } else { > > LOGF(debug)(LOGL, "rataser clock synced."); > > break; > > } > > MAP_WRITE(self->sicy_map, reset_adc_clock, 0x0); > > time_sleep(30e-3); > > } > > } > > } > > > > And we receive an error message that our ADCs are not synchronized. As I > > have no idea what RATACLOCK is, it is hard for me to figure out what is > > happening. > > > > > > However, there is also the parameter USE_RATACLOCK. It is set to 0 by > > default. So, maybe it is simply a bug that the check for synchronization > is > > executed just on the basis of if (self->config.has_rataclock_receiver == > 1), > > while not also checking for if (self->config.use_rataclock == 1)? > > It sounds like it. Could you see if things work if you add such a check > (i.e. only do that rataclock sync check if use_rataclock == 1)? > > > But shouldn't the expectation be that the ADCs are always synchronized? > So, > > maybe this is still a problem with the configuration of our module? > > > > > > Sorry for this confusion. I would really appreciate if someone could > explain > > what is going on here ? > > Cheers, > H?kan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: