From g.weber at hi-jena.gsi.de Wed Jun 5 18:16:14 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Wed, 5 Jun 2024 16:16:14 +0000 Subject: [subexp-daq] NURDLIB - possible bug in SIS3316 Message-ID: Dear friends, when we switch on the DISCARD_DATA feature, we get a failed memory access error in line 2905 of sis_3316.c. The discard option triggers the if clause starting in line 2855. We think that the problem lies in the value of ADC_MEM_I in MAP_READ_OFS(a_sis3316->sicy_map, adc_fifo_memory_fifo(adc), adc_mem_i); ADC_MEM_I is incremented by one after each memory access after line 2886. However, we think it should be incremented by the size of the element that we read. Here is what Bastian did in 2021: volatile uint32_t *adc_mem; ... adc_mem = a_sis3316->arr->adc_fifo_memory_fifo[adc]; *outp++ = *adc_mem++; /* timestamp 1 */ *outp++ = *adc_mem++; /* timestamp 2 */ if (a_sis3316->config.use_accumulator2 == 1 || a_sis3316->config.use_accumulator6 == 1) { int i; /* both must be set! */ assert(a_sis3316->config.use_accumulator2 == 1); assert(a_sis3316->config.use_accumulator6 == 1); for (i = 0; i < 9; ++i) { *outp++ = *adc_mem++; /* peak + gates */ } } Incrementing the pointer ADC_MEM in Bastian's code should shift the address by SIZEOF(UINT32_T), right? Maybe you could look into this issue. Thank you very much! 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Wed Jun 5 20:30:47 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Wed, 5 Jun 2024 20:30:47 +0200 Subject: [subexp-daq] NURDLIB - possible bug in SIS3316 In-Reply-To: References: Message-ID: Dear G?nter, to me it looks like your suspicion is right and adc_mem_i is not incremented properly. Could you please try to replace all occurences of '++adc_mem_i;' with 'adc_mem_i += sizeof (uint32_t);' and see if that works? Cheers, H?kan On Wed, 5 Jun 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > when we switch on the DISCARD_DATA feature, we get a failed memory access error in line 2905 of sis_3316.c. The discard option > triggers the if clause starting in line 2855. > > > We think that the problem lies in the value of ADC_MEM_I in > > > MAP_READ_OFS(a_sis3316->sicy_map, adc_fifo_memory_fifo(adc), adc_mem_i); > > > ADC_MEM_I is incremented by one after each memory access after line 2886. However, we think it should be incremented by the size > of the element that we read. Here is what Bastian did in 2021: > > > ?? ???? volatile uint32_t *adc_mem; > ... > ?? ??? ?adc_mem = a_sis3316->arr->adc_fifo_memory_fifo[adc]; > ?? ??? ?*outp++ = *adc_mem++; /* timestamp 1 */ > ?? ??? ?*outp++ = *adc_mem++; /* timestamp 2 */ > > ?? ??? ?if (a_sis3316->config.use_accumulator2 == 1 || > ?? ??? ???? a_sis3316->config.use_accumulator6 == 1) { > ?? ??? ??? ?int i; > ?? ??? ??? ?/* both must be set! */ > ?? ??? ??? ?assert(a_sis3316->config.use_accumulator2 == 1); > ?? ??? ??? ?assert(a_sis3316->config.use_accumulator6 == 1); > ?? ??? ??? ?for (i = 0; i < 9; ++i) { > ?? ??? ??? ??? ?*outp++ = *adc_mem++; /* peak + gates */ > ?? ??? ??? ?} > ?? ??? ?} > > Incrementing the pointer ADC_MEM in Bastian's code should shift the address by SIZEOF(UINT32_T), right? > > > Maybe you could look into this issue. > > > > > Thank you very much! > > > > 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 > > From g.weber at hi-jena.gsi.de Thu Jun 6 13:52:47 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Thu, 6 Jun 2024 11:52:47 +0000 Subject: [subexp-daq] Question on DRASI Message-ID: <9ee9ab24698e4394944421bc0e8fda26@hi-jena.gsi.de> Dear friends, is it possible to tell the DAQ that it should send out each event right after it was collected? To us it looks like our DAQ is releasing the collected data in 'bursts'. Thank you very much! Best greetings G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Thu Jun 6 16:50:34 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Thu, 6 Jun 2024 16:50:34 +0200 Subject: [subexp-daq] Question on DRASI In-Reply-To: <9ee9ab24698e4394944421bc0e8fda26@hi-jena.gsi.de> References: <9ee9ab24698e4394944421bc0e8fda26@hi-jena.gsi.de> Message-ID: <4f637c47-97d1-1925-0416-2526a3968951@chalmers.se> Dear G?nter, how long delays are you experiencing? The default partial buffer timeouts of drasi transport/stream network servers looks like they should be 2 or 4 s, depending on the buffer size (larger for > 4 MB). The file writing partial buffer timeout is 30 s. There are flush=Ns options both for the --server=... and --file-writer=... commands. The modules are read out event-by-event? Or there might be some buffering going on there as well? Cheers, H?kan On Thu, 6 Jun 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > is it possible to tell the DAQ that it should send out each event right > after it was collected? To us it looks like our DAQ is releasing the > collected data in 'bursts'. > > > > > Thank you very much! > > > > Best greetings > > G?nter > > > > > From g.weber at hi-jena.gsi.de Thu Jun 6 18:18:04 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Thu, 6 Jun 2024 16:18:04 +0000 Subject: [subexp-daq] Question on DRASI In-Reply-To: <4f637c47-97d1-1925-0416-2526a3968951@chalmers.se> References: <9ee9ab24698e4394944421bc0e8fda26@hi-jena.gsi.de>, <4f637c47-97d1-1925-0416-2526a3968951@chalmers.se> Message-ID: Dear H?kan, at the moment, we are characterizing our DAQ and have an event every ~0.1 seconds. We would then immediatly like to check if this event agrees with what we fed into the DAQ system. Would flush=1 force the DAQ to send out each event after it was recorded? And if yes, where should I put here? ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi \ --label=MCAL2 \ --triva=master,fctime=10,ctime=50 \ --server=drasi,dest=lyserv \ --buf=size=400Mi \ --max-ev-size=0x1000000 \ --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ --eb=lyserv \ Thank you very much! Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Donnerstag, 6. Juni 2024 16:50:34 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] Question on DRASI Dear G?nter, how long delays are you experiencing? The default partial buffer timeouts of drasi transport/stream network servers looks like they should be 2 or 4 s, depending on the buffer size (larger for > 4 MB). The file writing partial buffer timeout is 30 s. There are flush=Ns options both for the --server=... and --file-writer=... commands. The modules are read out event-by-event? Or there might be some buffering going on there as well? Cheers, H?kan On Thu, 6 Jun 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > is it possible to tell the DAQ that it should send out each event right > after it was collected? To us it looks like our DAQ is releasing the > collected data in 'bursts'. > > > > > Thank you very much! > > > > Best greetings > > G?nter > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Thu Jun 6 18:22:22 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Thu, 6 Jun 2024 18:22:22 +0200 Subject: [subexp-daq] Question on DRASI In-Reply-To: References: <9ee9ab24698e4394944421bc0e8fda26@hi-jena.gsi.de>, <4f637c47-97d1-1925-0416-2526a3968951@chalmers.se> Message-ID: <0daca064-54e4-1345-7c92-26002cb32b2f@chalmers.se> On Thu, 6 Jun 2024, Weber, Guenter Dr. wrote: > > Dear H?kan, > > > at the moment, we are characterizing our DAQ and have an event every ~0.1 > seconds. We would then immediatly like to check if this event agrees with > what we fed into the DAQ system. > > > Would flush=1 force the DAQ to send out each event after it was recorded? No, after 1 s at most in that case. At the moment there is no 'immediate' flush. The --server=drasi,... would be the one. But that by default has a 0.5 s timeout, so can only be made worse wioth the --flush option. > And if yes, where should I put here? > > > ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi \ > ??????? --label=MCAL2 \ > ??????? --triva=master,fctime=10,ctime=50 \ > ??????? --server=drasi,dest=lyserv \ > ??????? --buf=size=400Mi \ > ??????? --max-ev-size=0x1000000 \ > ?? ?--subev=crate=1,type=20,subtype=2,control=9,procid=1 \ > ????? ??? ?--eb=lyserv \ Please try to add it in the --server=... options of the event builder. Cheers, H?kan > > > Thank you very much! > > > > > Best greetings > > G?nter > > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan > T Johansson > Gesendet: Donnerstag, 6. Juni 2024 16:50:34 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] Question on DRASI ? > > Dear G?nter, > > how long delays are you experiencing? > > The default partial buffer timeouts of drasi transport/stream network > servers looks like they should be 2 or 4 s, depending on the buffer size > (larger for > 4 MB). > > The file writing partial buffer timeout is 30 s. > > There are flush=Ns options both for the --server=... and --file-writer=... > commands. > > The modules are read out event-by-event? > Or there might be some buffering going on there as well? > > Cheers, > H?kan > > > > On Thu, 6 Jun 2024, Weber, Guenter Dr. wrote: > > > > > Dear friends, > > > > > > is it possible to tell the DAQ that it should send out each event right > > after it was collected? To us it looks like our DAQ is releasing the > > collected data in 'bursts'. > > > > > > > > > > Thank you very much! > > > > > > > > Best greetings > > > > G?nter > > > > > > > > > > > > From g.weber at hi-jena.gsi.de Fri Jun 7 09:56:44 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Fri, 7 Jun 2024 07:56:44 +0000 Subject: [subexp-daq] Question on DRASI In-Reply-To: <0daca064-54e4-1345-7c92-26002cb32b2f@chalmers.se> References: <9ee9ab24698e4394944421bc0e8fda26@hi-jena.gsi.de>, <4f637c47-97d1-1925-0416-2526a3968951@chalmers.se> , <0daca064-54e4-1345-7c92-26002cb32b2f@chalmers.se> Message-ID: <3fe5d8c7a5cf40bc9b4607fa3b69a843@hi-jena.gsi.de> Dear H?kan, thanks a lot for the explanation. If possible, I would like to add 'flush=immediatly' to the wish list. For them moment, we will work around this issue. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Donnerstag, 6. Juni 2024 18:22:22 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] Question on DRASI On Thu, 6 Jun 2024, Weber, Guenter Dr. wrote: > > Dear H?kan, > > > at the moment, we are characterizing our DAQ and have an event every ~0.1 > seconds. We would then immediatly like to check if this event agrees with > what we fed into the DAQ system. > > > Would flush=1 force the DAQ to send out each event after it was recorded? No, after 1 s at most in that case. At the moment there is no 'immediate' flush. The --server=drasi,... would be the one. But that by default has a 0.5 s timeout, so can only be made worse wioth the --flush option. > And if yes, where should I put here? > > > ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi \ > --label=MCAL2 \ > --triva=master,fctime=10,ctime=50 \ > --server=drasi,dest=lyserv \ > --buf=size=400Mi \ > --max-ev-size=0x1000000 \ > --subev=crate=1,type=20,subtype=2,control=9,procid=1 \ > --eb=lyserv \ Please try to add it in the --server=... options of the event builder. Cheers, H?kan > > > Thank you very much! > > > > > Best greetings > > G?nter > > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan > T Johansson > Gesendet: Donnerstag, 6. Juni 2024 16:50:34 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] Question on DRASI > > Dear G?nter, > > how long delays are you experiencing? > > The default partial buffer timeouts of drasi transport/stream network > servers looks like they should be 2 or 4 s, depending on the buffer size > (larger for > 4 MB). > > The file writing partial buffer timeout is 30 s. > > There are flush=Ns options both for the --server=... and --file-writer=... > commands. > > The modules are read out event-by-event? > Or there might be some buffering going on there as well? > > Cheers, > H?kan > > > > On Thu, 6 Jun 2024, Weber, Guenter Dr. wrote: > > > > > Dear friends, > > > > > > is it possible to tell the DAQ that it should send out each event right > > after it was collected? To us it looks like our DAQ is releasing the > > collected data in 'bursts'. > > > > > > > > > > Thank you very much! > > > > > > > > Best greetings > > > > G?nter > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.weber at hi-jena.gsi.de Mon Jun 10 18:54:58 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Mon, 10 Jun 2024 16:54:58 +0000 Subject: [subexp-daq] NURDLIB - SIS3316 - major rework of check_hit Message-ID: <2c3831fdce994d1b8d166f1b02275ba0@hi-jena.gsi.de> Dear all, I just pushed a new version of the sis3316.c, where check_hit was rewritten. The reason was that the existing code did not work together with the discard option for the channel readout. Please note that in readout_dma I am now using an excess bit (not necessary to represent even the largest number of raw sample words possible) to store the information that an event was discarded. This is then used in check_event. As I did a lot of changes, please have an extra close look at the code. If everyone is happy with the new check_event, I will also make changes to the discard routine in readout_dma as at the moment, some assumptions on the settings of the module are hard coded - at least that is my impression at the moment. Thanks a lot! Best greetings G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.tornqvist at chalmers.se Fri Jun 14 19:40:27 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Fri, 14 Jun 2024 19:40:27 +0200 Subject: [subexp-daq] NURDLIB - SIS3316 - major rework of check_hit In-Reply-To: <2c3831fdce994d1b8d166f1b02275ba0@hi-jena.gsi.de> References: <2c3831fdce994d1b8d166f1b02275ba0@hi-jena.gsi.de> Message-ID: <25eb8fb4-5175-4e80-beca-369124e99a64@chalmers.se> Dear G?nter, I had a look, it seemed fine. There is a rebased version against the current main: SIS3316_check_hit_reworked_rebased Due to some new safety checks, I had to remove a sis3316-only config function and instead rely on common existing config functions, so please try it out and see that it works ok. If this runs I will put all of it in 'main'! Best regards, Hans On 2024-06-10 18:54, Weber, Guenter Dr. wrote: > Dear all, > > > I just pushed a new version of the sis3316.c, where check_hit was > rewritten. The reason was that the existing code did not work together > with the discard option for the channel readout. Please note that in > readout_dma I am now using an excess bit (not necessary to represent > even the largest number of raw sample words possible) to store the > information that an event was discarded. This is then used in check_event. > > > As I did a lot of changes, please have an extra close look at the code. > > > If everyone is happy with the new check_event, I will also make changes > to the discard routine in readout_dma as at the moment, some assumptions > on the settings of the module are hard coded - at least that is my > impression at the moment. > > > > > Thanks a lot! > > > > > Best greetings > > G?nter > > >