From g.weber at hi-jena.gsi.de Fri Mar 1 16:16:23 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Fri, 1 Mar 2024 15:16:23 +0000 Subject: [subexp-daq] Strange instability of the event counter register of the CAEN V767 module Message-ID: Dear friends, we just noticed that the value that is read from the event counter register (Base + %004C) of V767 is not stable during times when the module does internal operations. To demonstrate this we used the following code: last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter); write_op(caen_v767a->sicy_map, 0x1000); /* set mode of operation */ t = time_getd(); while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, event_counter) ) { usleep(1); } t = time_getd() - t; LOGF(info)(LOGL, NAME" TIME is %f", t); last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter); window_setting = config_get_int32(caen_v767a->module.config, KW_WIDTH, CONFIG_UNIT_NONE, 0x0001, 0x84D0); write_op(caen_v767a->sicy_map, 0x3000); /* set time window length */ write_op(caen_v767a->sicy_map, window_setting); t = time_getd(); while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, event_counter) ) { usleep(1); } t = time_getd() - t; LOGF(info)(LOGL, NAME" TIME is %f", t); last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter); window_setting = config_get_int32(caen_v767a->module.config, KW_OFFSET, CONFIG_UNIT_NONE, 1 - 320000, window_setting + 2000 - 1); write_op(caen_v767a->sicy_map, 0x3200); /* set time window offset */ write_op(caen_v767a->sicy_map, window_setting); t = time_getd(); while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, event_counter) ) { usleep(1); } t = time_getd() - t; LOGF(info)(LOGL, NAME" TIME is %f", t); last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter); write_op(caen_v767a->sicy_map, 0x7000); /* set data ready status to event ready */ t = time_getd(); while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, event_counter) ) { usleep(1); } t = time_getd() - t; LOGF(info)(LOGL, NAME" TIME is %f", t); And the output in two trials was the following: 10: module/caen_v767a/caen_v767a.c:143: ..CEAN_V767A TIME is 0.000002 10: module/caen_v767a/caen_v767a.c:155: ..CEAN_V767A TIME is 0.000002 10: module/caen_v767a/caen_v767a.c:167: ..CEAN_V767A TIME is 0.055224 10: module/caen_v767a/caen_v767a.c:177: ..CEAN_V767A TIME is 0.000354 10: module/caen_v767a/caen_v767a.c:143: ....CEAN_V767A TIME is 0.000002 10: module/caen_v767a/caen_v767a.c:155: ....CEAN_V767A TIME is 0.000002 10: module/caen_v767a/caen_v767a.c:167: ....CEAN_V767A TIME is 0.055223 10: module/caen_v767a/caen_v767a.c:177: ....CEAN_V767A TIME is 0.000387 Thus, we can conclude that the event counter register is set to some fake value for up to almost 60 ms as a result of an internal operation of the module. Only after this time, the register goes back to the real value. We will now take care of this effect and after each WRITE_OP call wait for the event counter to to gack to the original value. However, who knows what happens in the other registers of the module (and for how long). As the event counter value is used as a sanity check in CRATE.C it might make sense to check if some of the other CAEN modules also exhibit this 'fascinating feature'. Best greetings G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.tornqvist at chalmers.se Fri Mar 1 18:27:59 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Fri, 1 Mar 2024 18:27:59 +0100 Subject: [subexp-daq] Strange instability of the event counter register of the CAEN V767 module In-Reply-To: References: Message-ID: Dear G?nter, It looks to me like this happens when configuring the module, i.e. setting windows, operating mode etc? And not in the "inner" readout loop? From the manual, it seems like one has to wait 2 seconds (oof) after the soft-reset, and do polling of the the micro-controller communication. An additional sleep of 100 ms after the complete setup seems fine. Some Caen and Mesytec implementations already sleep in many places during initialization, and the v1n90 modules also have the TDC micro-controller support. A small schematic for an idea what registers are touched in the modules: init { init_slow { mapping, one-time settings } init_fast { all other settings sleep to let the module settle } (post_init optional) } loop { readout_dt { read module counter, typically a 32-bit reg-read if available, read buffer size, another 16/32-bit reg-read } (release dt optional) readout { read buffer { either a loop with 32-bit reg-reads from event-fifo, or block transfer } } } So during the readout loop the tests you made should not be a concern, if I understood it correctly? Two requests: - Could you make the 2 seconds soft-reset sleep a config with the default value 2 s? Software tests can then set it to 0 s. - I'm guessing it's sufficient to wait for ~100 ms at the end of init_fast for the internals to be ready, please make also this configurable. Since an increasing event-counter relies on external triggers, I don't see how it could be used while setting up the DAQ before running, a "time_sleep(0.1);" or a bit longer ought to work. Happy weekend, Hans On 2024-03-01 16:16, Weber, Guenter Dr. wrote: > Dear friends, > > > we just noticed that the value that is read from the event counter > register (Base + %004C) of V767 is not stable during times when the > module does internal operations. To demonstrate this we used the > following code: > > > last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter); > write_op(caen_v767a->sicy_map, 0x1000); /* set mode of operation */ > t = time_getd(); > while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, > event_counter) ) > { > ?? ?usleep(1); > } > t = time_getd() - t; > LOGF(info)(LOGL, NAME" TIME is %f", t); > > last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter); > window_setting = config_get_int32(caen_v767a->module.config, KW_WIDTH, > CONFIG_UNIT_NONE, 0x0001, 0x84D0); > write_op(caen_v767a->sicy_map, 0x3000); /* set time window length */ > write_op(caen_v767a->sicy_map, window_setting); > t = time_getd(); > while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, > event_counter) ) > { > ?? ?usleep(1); > } > t = time_getd() - t; > LOGF(info)(LOGL, NAME" TIME is %f", t); > > last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter); > window_setting = config_get_int32(caen_v767a->module.config, KW_OFFSET, > CONFIG_UNIT_NONE, 1 - 320000, window_setting + 2000 - 1); > write_op(caen_v767a->sicy_map, 0x3200); /* set time window offset */ > write_op(caen_v767a->sicy_map, window_setting); > t = time_getd(); > while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, > event_counter) ) > { > ?? ?usleep(1); > } > t = time_getd() - t; > LOGF(info)(LOGL, NAME" TIME is %f", t); > > last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter); > write_op(caen_v767a->sicy_map, 0x7000); /* set data ready status to > event ready */ > t = time_getd(); > while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, > event_counter) ) > { > ?? ?usleep(1); > } > t = time_getd() - t; > LOGF(info)(LOGL, NAME" TIME is %f", t); > > And the output in two trials was the following: > > > 10: module/caen_v767a/caen_v767a.c:143: ..CEAN_V767A TIME is 0.000002 > 10: module/caen_v767a/caen_v767a.c:155: ..CEAN_V767A TIME is 0.000002 > 10: module/caen_v767a/caen_v767a.c:167: ..CEAN_V767A TIME is 0.055224 > 10: module/caen_v767a/caen_v767a.c:177: ..CEAN_V767A TIME is 0.000354 > > 10: module/caen_v767a/caen_v767a.c:143: ....CEAN_V767A TIME is 0.000002 > 10: module/caen_v767a/caen_v767a.c:155: ....CEAN_V767A TIME is 0.000002 > 10: module/caen_v767a/caen_v767a.c:167: ....CEAN_V767A TIME is 0.055223 > 10: module/caen_v767a/caen_v767a.c:177: ....CEAN_V767A TIME is 0.000387 > > Thus, we can conclude that the event counter register is set to some > fake value for up to almost 60 ms as a result of an internal operation > of the module. Only after this time, the register goes back to the real > value. > > > We will now take care of this effect and after each WRITE_OP call wait > for the event counter to to gack to the original value. However, who > knows what happens in the other registers of the module (and for how long). > > > As the event counter value is used as a sanity check in CRATE.C it might > make sense to check if some of the other CAEN modules also exhibit this > 'fascinating feature'. > > > > > > Best greetings > > G?nter > > > > From g.weber at hi-jena.gsi.de Fri Mar 1 19:28:36 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Fri, 1 Mar 2024 18:28:36 +0000 Subject: [subexp-daq] Strange instability of the event counter register of the CAEN V767 module In-Reply-To: References: , Message-ID: <71e06db813bc419eaa44d1a8f7de51ba@hi-jena.gsi.de> Dear Hans, indeed, this modification of the event counter register only happens in the init routines. However, part of init is clearing the module and also setting the event counter to zero. If one does this right after the commands that somehow 'touch' the event counter value, it is possible that after clearing the event counter the zero value is then overwritten. Thus, it is necessary to organize init like this: 1) Doing all the settings. 2) Waiting an approbiate amount of time. 3) Clearing the module, setting counter to zero. We now also learned that at least one command sets the counter register permanently to 1. Thus, it is not possible to execute this command 'on-the-fly' and still have a consistent value of the event counter afterwards. This means the counter comparision in crate.c will no longer work. Instead one needs a complete restart. (But as I understand, the fast init is meant to be executed also without a complete restart of everything, right?) If I understood the manual correct, there is the possibility to send a software trigger. With this it might be possible to readout the current event counter, do the programming commands, then clear the module, set counter to zero and now send software triggers to increment the counter value to the original value. Ok, I hope thise explanation/though process is understandable. Best greetings and have a nice weekend G?nter ________________________________ Von: Hans Toshihide T?rnqvist Gesendet: Freitag, 1. M?rz 2024 18:27:59 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr. Betreff: Re: [subexp-daq] Strange instability of the event counter register of the CAEN V767 module Dear G?nter, It looks to me like this happens when configuring the module, i.e. setting windows, operating mode etc? And not in the "inner" readout loop? From the manual, it seems like one has to wait 2 seconds (oof) after the soft-reset, and do polling of the the micro-controller communication. An additional sleep of 100 ms after the complete setup seems fine. Some Caen and Mesytec implementations already sleep in many places during initialization, and the v1n90 modules also have the TDC micro-controller support. A small schematic for an idea what registers are touched in the modules: init { init_slow { mapping, one-time settings } init_fast { all other settings sleep to let the module settle } (post_init optional) } loop { readout_dt { read module counter, typically a 32-bit reg-read if available, read buffer size, another 16/32-bit reg-read } (release dt optional) readout { read buffer { either a loop with 32-bit reg-reads from event-fifo, or block transfer } } } So during the readout loop the tests you made should not be a concern, if I understood it correctly? Two requests: - Could you make the 2 seconds soft-reset sleep a config with the default value 2 s? Software tests can then set it to 0 s. - I'm guessing it's sufficient to wait for ~100 ms at the end of init_fast for the internals to be ready, please make also this configurable. Since an increasing event-counter relies on external triggers, I don't see how it could be used while setting up the DAQ before running, a "time_sleep(0.1);" or a bit longer ought to work. Happy weekend, Hans On 2024-03-01 16:16, Weber, Guenter Dr. wrote: > Dear friends, > > > we just noticed that the value that is read from the event counter > register (Base + %004C) of V767 is not stable during times when the > module does internal operations. To demonstrate this we used the > following code: > > > last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter); > write_op(caen_v767a->sicy_map, 0x1000); /* set mode of operation */ > t = time_getd(); > while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, > event_counter) ) > { > usleep(1); > } > t = time_getd() - t; > LOGF(info)(LOGL, NAME" TIME is %f", t); > > last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter); > window_setting = config_get_int32(caen_v767a->module.config, KW_WIDTH, > CONFIG_UNIT_NONE, 0x0001, 0x84D0); > write_op(caen_v767a->sicy_map, 0x3000); /* set time window length */ > write_op(caen_v767a->sicy_map, window_setting); > t = time_getd(); > while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, > event_counter) ) > { > usleep(1); > } > t = time_getd() - t; > LOGF(info)(LOGL, NAME" TIME is %f", t); > > last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter); > window_setting = config_get_int32(caen_v767a->module.config, KW_OFFSET, > CONFIG_UNIT_NONE, 1 - 320000, window_setting + 2000 - 1); > write_op(caen_v767a->sicy_map, 0x3200); /* set time window offset */ > write_op(caen_v767a->sicy_map, window_setting); > t = time_getd(); > while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, > event_counter) ) > { > usleep(1); > } > t = time_getd() - t; > LOGF(info)(LOGL, NAME" TIME is %f", t); > > last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter); > write_op(caen_v767a->sicy_map, 0x7000); /* set data ready status to > event ready */ > t = time_getd(); > while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, > event_counter) ) > { > usleep(1); > } > t = time_getd() - t; > LOGF(info)(LOGL, NAME" TIME is %f", t); > > And the output in two trials was the following: > > > 10: module/caen_v767a/caen_v767a.c:143: ..CEAN_V767A TIME is 0.000002 > 10: module/caen_v767a/caen_v767a.c:155: ..CEAN_V767A TIME is 0.000002 > 10: module/caen_v767a/caen_v767a.c:167: ..CEAN_V767A TIME is 0.055224 > 10: module/caen_v767a/caen_v767a.c:177: ..CEAN_V767A TIME is 0.000354 > > 10: module/caen_v767a/caen_v767a.c:143: ....CEAN_V767A TIME is 0.000002 > 10: module/caen_v767a/caen_v767a.c:155: ....CEAN_V767A TIME is 0.000002 > 10: module/caen_v767a/caen_v767a.c:167: ....CEAN_V767A TIME is 0.055223 > 10: module/caen_v767a/caen_v767a.c:177: ....CEAN_V767A TIME is 0.000387 > > Thus, we can conclude that the event counter register is set to some > fake value for up to almost 60 ms as a result of an internal operation > of the module. Only after this time, the register goes back to the real > value. > > > We will now take care of this effect and after each WRITE_OP call wait > for the event counter to to gack to the original value. However, who > knows what happens in the other registers of the module (and for how long). > > > As the event counter value is used as a sanity check in CRATE.C it might > make sense to check if some of the other CAEN modules also exhibit this > 'fascinating feature'. > > > > > > Best greetings > > G?nter > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.weber at hi-jena.gsi.de Mon Mar 4 17:08:05 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Mon, 4 Mar 2024 16:08:05 +0000 Subject: [subexp-daq] Strange instability of the event counter register of the CAEN V767 module In-Reply-To: <71e06db813bc419eaa44d1a8f7de51ba@hi-jena.gsi.de> References: , , <71e06db813bc419eaa44d1a8f7de51ba@hi-jena.gsi.de> Message-ID: Dear friends, we just pushed a new branch to the NURDLIB repository which now contains the module CAEN V767A. Please have a look at our implementation, wether this makes sense to you or not. At the moment, the operation mode of the module is hard coded, but this can be changed easily. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von Weber, Guenter Dr. Gesendet: Freitag, 1. M?rz 2024 19:28:36 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] Strange instability of the event counter register of the CAEN V767 module Dear Hans, indeed, this modification of the event counter register only happens in the init routines. However, part of init is clearing the module and also setting the event counter to zero. If one does this right after the commands that somehow 'touch' the event counter value, it is possible that after clearing the event counter the zero value is then overwritten. Thus, it is necessary to organize init like this: 1) Doing all the settings. 2) Waiting an approbiate amount of time. 3) Clearing the module, setting counter to zero. We now also learned that at least one command sets the counter register permanently to 1. Thus, it is not possible to execute this command 'on-the-fly' and still have a consistent value of the event counter afterwards. This means the counter comparision in crate.c will no longer work. Instead one needs a complete restart. (But as I understand, the fast init is meant to be executed also without a complete restart of everything, right?) If I understood the manual correct, there is the possibility to send a software trigger. With this it might be possible to readout the current event counter, do the programming commands, then clear the module, set counter to zero and now send software triggers to increment the counter value to the original value. Ok, I hope thise explanation/though process is understandable. Best greetings and have a nice weekend G?nter ________________________________ Von: Hans Toshihide T?rnqvist Gesendet: Freitag, 1. M?rz 2024 18:27:59 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr. Betreff: Re: [subexp-daq] Strange instability of the event counter register of the CAEN V767 module Dear G?nter, It looks to me like this happens when configuring the module, i.e. setting windows, operating mode etc? And not in the "inner" readout loop? From the manual, it seems like one has to wait 2 seconds (oof) after the soft-reset, and do polling of the the micro-controller communication. An additional sleep of 100 ms after the complete setup seems fine. Some Caen and Mesytec implementations already sleep in many places during initialization, and the v1n90 modules also have the TDC micro-controller support. A small schematic for an idea what registers are touched in the modules: init { init_slow { mapping, one-time settings } init_fast { all other settings sleep to let the module settle } (post_init optional) } loop { readout_dt { read module counter, typically a 32-bit reg-read if available, read buffer size, another 16/32-bit reg-read } (release dt optional) readout { read buffer { either a loop with 32-bit reg-reads from event-fifo, or block transfer } } } So during the readout loop the tests you made should not be a concern, if I understood it correctly? Two requests: - Could you make the 2 seconds soft-reset sleep a config with the default value 2 s? Software tests can then set it to 0 s. - I'm guessing it's sufficient to wait for ~100 ms at the end of init_fast for the internals to be ready, please make also this configurable. Since an increasing event-counter relies on external triggers, I don't see how it could be used while setting up the DAQ before running, a "time_sleep(0.1);" or a bit longer ought to work. Happy weekend, Hans On 2024-03-01 16:16, Weber, Guenter Dr. wrote: > Dear friends, > > > we just noticed that the value that is read from the event counter > register (Base + %004C) of V767 is not stable during times when the > module does internal operations. To demonstrate this we used the > following code: > > > last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter); > write_op(caen_v767a->sicy_map, 0x1000); /* set mode of operation */ > t = time_getd(); > while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, > event_counter) ) > { > usleep(1); > } > t = time_getd() - t; > LOGF(info)(LOGL, NAME" TIME is %f", t); > > last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter); > window_setting = config_get_int32(caen_v767a->module.config, KW_WIDTH, > CONFIG_UNIT_NONE, 0x0001, 0x84D0); > write_op(caen_v767a->sicy_map, 0x3000); /* set time window length */ > write_op(caen_v767a->sicy_map, window_setting); > t = time_getd(); > while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, > event_counter) ) > { > usleep(1); > } > t = time_getd() - t; > LOGF(info)(LOGL, NAME" TIME is %f", t); > > last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter); > window_setting = config_get_int32(caen_v767a->module.config, KW_OFFSET, > CONFIG_UNIT_NONE, 1 - 320000, window_setting + 2000 - 1); > write_op(caen_v767a->sicy_map, 0x3200); /* set time window offset */ > write_op(caen_v767a->sicy_map, window_setting); > t = time_getd(); > while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, > event_counter) ) > { > usleep(1); > } > t = time_getd() - t; > LOGF(info)(LOGL, NAME" TIME is %f", t); > > last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter); > write_op(caen_v767a->sicy_map, 0x7000); /* set data ready status to > event ready */ > t = time_getd(); > while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, > event_counter) ) > { > usleep(1); > } > t = time_getd() - t; > LOGF(info)(LOGL, NAME" TIME is %f", t); > > And the output in two trials was the following: > > > 10: module/caen_v767a/caen_v767a.c:143: ..CEAN_V767A TIME is 0.000002 > 10: module/caen_v767a/caen_v767a.c:155: ..CEAN_V767A TIME is 0.000002 > 10: module/caen_v767a/caen_v767a.c:167: ..CEAN_V767A TIME is 0.055224 > 10: module/caen_v767a/caen_v767a.c:177: ..CEAN_V767A TIME is 0.000354 > > 10: module/caen_v767a/caen_v767a.c:143: ....CEAN_V767A TIME is 0.000002 > 10: module/caen_v767a/caen_v767a.c:155: ....CEAN_V767A TIME is 0.000002 > 10: module/caen_v767a/caen_v767a.c:167: ....CEAN_V767A TIME is 0.055223 > 10: module/caen_v767a/caen_v767a.c:177: ....CEAN_V767A TIME is 0.000387 > > Thus, we can conclude that the event counter register is set to some > fake value for up to almost 60 ms as a result of an internal operation > of the module. Only after this time, the register goes back to the real > value. > > > We will now take care of this effect and after each WRITE_OP call wait > for the event counter to to gack to the original value. However, who > knows what happens in the other registers of the module (and for how long). > > > As the event counter value is used as a sanity check in CRATE.C it might > make sense to check if some of the other CAEN modules also exhibit this > 'fascinating feature'. > > > > > > Best greetings > > G?nter > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans.tornqvist at chalmers.se Tue Mar 5 17:38:20 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Tue, 5 Mar 2024 17:38:20 +0100 Subject: [subexp-daq] Strange instability of the event counter register of the CAEN V767 module In-Reply-To: References: <71e06db813bc419eaa44d1a8f7de51ba@hi-jena.gsi.de> Message-ID: <10d85877-b9f8-4fbd-b2fb-38138d9bd7b6@chalmers.se> Dear G?nter, We had a look, was overall good! I added a few things in order to be able to test the software part, it's now in the 'master' branch. Please test to make sure that I didn't add "unforeseen features" :) Once this has been tested I have additional and larger updates, mainly to keep the re-init behaviour and some coding patterns in line with other modules (to let the crate re-init on failures and report proper error codes, having time-outs for potentially infinite loops etc). Best regards, Hans On 2024-03-04 17:08, Weber, Guenter Dr. wrote: > Dear friends, > > > we just pushed a new branch to the NURDLIB repository which now contains > the module CAEN V767A. Please have a look at our implementation, wether > this makes sense to you or not. At the moment, the operation mode of the > module is hard coded, but this can be changed easily. > > > > > Best greetings > > G?nter > > > > ------------------------------------------------------------------------ > *Von:* subexp-daq im Auftrag von > Weber, Guenter Dr. > *Gesendet:* Freitag, 1. M?rz 2024 19:28:36 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB. > *Betreff:* Re: [subexp-daq] Strange instability of the event counter > register of the CAEN V767 module > Dear Hans, > > indeed, this modification of the event counter register only happens in > the init routines. However, part of init is clearing the module and also > setting the event counter to zero. If one does this right after the > commands that somehow 'touch' the event counter value, it is possible > that after clearing the event counter the zero value is then overwritten. > > Thus, it is necessary to organize init like this: > > 1) Doing all the settings. > 2) Waiting an approbiate amount of time. > 3) Clearing the module, setting counter to zero. > > We now also learned that at least one command sets the counter register > permanently to 1. Thus, it is not possible to execute this command > 'on-the-fly' and still have a consistent value of the event counter > afterwards. This means the counter comparision in crate.c will no longer > work. Instead one needs a complete restart. (But as I understand, the > fast init is meant to be executed also without a complete restart of > everything, right?) > > If I understood the manual correct, there is the possibility to send a > software trigger. With this it might be possible to readout the current > event counter, do the programming commands, then clear the module, set > counter to zero and now send software triggers to increment the counter > value to the original value. > > Ok, I hope thise explanation/though process is understandable. > > > > Best greetings and have a nice weekend > G?nter > > > > > > > ------------------------------------------------------------------------ > *Von:* Hans Toshihide T?rnqvist > *Gesendet:* Freitag, 1. M?rz 2024 18:27:59 > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr. > *Betreff:* Re: [subexp-daq] Strange instability of the event counter > register of the CAEN V767 module > Dear G?nter, > > It looks to me like this happens when configuring the module, i.e. > setting windows, operating mode etc? And not in the "inner" readout loop? > > ?From the manual, it seems like one has to wait 2 seconds (oof) after > the soft-reset, and do polling of the the micro-controller > communication. An additional sleep of 100 ms after the complete setup > seems fine. > > Some Caen and Mesytec implementations already sleep in many places > during initialization, and the v1n90 modules also have the TDC > micro-controller support. > > A small schematic for an idea what registers are touched in the modules: > > init { > ? init_slow { > ??? mapping, one-time settings > ? } > ? init_fast { > ?? all other settings > ?? sleep to let the module settle > ? } > ? (post_init optional) > } > loop { > ? readout_dt { > ?? read module counter, typically a 32-bit reg-read > ?? if available, read buffer size, another 16/32-bit reg-read > ? } > ? (release dt optional) > ? readout { > ?? read buffer { > ??? either a loop with 32-bit reg-reads from event-fifo, > ??? or block transfer > ?? } > ? } > } > > So during the readout loop the tests you made should not be a concern, > if I understood it correctly? > > Two requests: > > - Could you make the 2 seconds soft-reset sleep a config with the > default value 2 s? Software tests can then set it to 0 s. > > - I'm guessing it's sufficient to wait for ~100 ms at the end of > init_fast for the internals to be ready, please make also this configurable. > > Since an increasing event-counter relies on external triggers, I don't > see how it could be used while setting up the DAQ before running, a > "time_sleep(0.1);" or a bit longer ought to work. > > Happy weekend, > Hans > > On 2024-03-01 16:16, Weber, Guenter Dr. wrote: >> Dear friends, >> >> >> we just noticed that the value that is read from the event counter >> register (Base + %004C) of V767 is not stable during times when the >> module does internal operations. To demonstrate this we used the >> following code: >> >> >> last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter); >> write_op(caen_v767a->sicy_map, 0x1000); /* set mode of operation */ >> t = time_getd(); >> while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, >> event_counter) ) >> { >>? ?? ?usleep(1); >> } >> t = time_getd() - t; >> LOGF(info)(LOGL, NAME" TIME is %f", t); >> >> last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter); >> window_setting = config_get_int32(caen_v767a->module.config, KW_WIDTH, >> CONFIG_UNIT_NONE, 0x0001, 0x84D0); >> write_op(caen_v767a->sicy_map, 0x3000); /* set time window length */ >> write_op(caen_v767a->sicy_map, window_setting); >> t = time_getd(); >> while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, >> event_counter) ) >> { >>? ?? ?usleep(1); >> } >> t = time_getd() - t; >> LOGF(info)(LOGL, NAME" TIME is %f", t); >> >> last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter); >> window_setting = config_get_int32(caen_v767a->module.config, KW_OFFSET, >> CONFIG_UNIT_NONE, 1 - 320000, window_setting + 2000 - 1); >> write_op(caen_v767a->sicy_map, 0x3200); /* set time window offset */ >> write_op(caen_v767a->sicy_map, window_setting); >> t = time_getd(); >> while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, >> event_counter) ) >> { >>? ?? ?usleep(1); >> } >> t = time_getd() - t; >> LOGF(info)(LOGL, NAME" TIME is %f", t); >> >> last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter); >> write_op(caen_v767a->sicy_map, 0x7000); /* set data ready status to >> event ready */ >> t = time_getd(); >> while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, >> event_counter) ) >> { >>? ?? ?usleep(1); >> } >> t = time_getd() - t; >> LOGF(info)(LOGL, NAME" TIME is %f", t); >> >> And the output in two trials was the following: >> >> >> 10: module/caen_v767a/caen_v767a.c:143: ..CEAN_V767A TIME is 0.000002 >> 10: module/caen_v767a/caen_v767a.c:155: ..CEAN_V767A TIME is 0.000002 >> 10: module/caen_v767a/caen_v767a.c:167: ..CEAN_V767A TIME is 0.055224 >> 10: module/caen_v767a/caen_v767a.c:177: ..CEAN_V767A TIME is 0.000354 >> >> 10: module/caen_v767a/caen_v767a.c:143: ....CEAN_V767A TIME is 0.000002 >> 10: module/caen_v767a/caen_v767a.c:155: ....CEAN_V767A TIME is 0.000002 >> 10: module/caen_v767a/caen_v767a.c:167: ....CEAN_V767A TIME is 0.055223 >> 10: module/caen_v767a/caen_v767a.c:177: ....CEAN_V767A TIME is 0.000387 >> >> Thus, we can conclude that the event counter register is set to some >> fake value for up to almost 60 ms as a result of an internal operation >> of the module. Only after this time, the register goes back to the real >> value. >> >> >> We will now take care of this effect and after each WRITE_OP call wait >> for the event counter to to gack to the original value. However, who >> knows what happens in the other registers of the module (and for how long). >> >> >> As the event counter value is used as a sanity check in CRATE.C it might >> make sense to check if some of the other CAEN modules also exhibit this >> 'fascinating feature'. >> >> >> >> >> >> Best greetings >> >> G?nter >> >> >> >> > From hans.tornqvist at chalmers.se Tue Mar 5 18:03:18 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Tue, 5 Mar 2024 18:03:18 +0100 Subject: [subexp-daq] sis3316 updates In-Reply-To: References: Message-ID: Dear all, We have rebased the Sis3316 changes from Bastian on top of the current master which has the V767 support also. This branch called 'rebasing_sis3316' can be found on gitlab.com: https://gitlab.com/chalmers-subexp/nurdlib/-/tree/rebasing_sis3316 Best regards, Hans On 2024-02-20 19:59, H?kan T Johansson wrote: > > Dear G?nter, all sis3316 nurdlib user, > > the changes to the nurdlib sis3316-code that have been used at Jena (and > possibly other places), which was a branch that had its branch point > about three years ago has been forward-ported to approximately current > master. > > It is available as the 'rebasing_sis3316' branch at > https://gitlab.com/chalmers-subexp/nurdlib > > Since we have no direct access or own experience with those modules, the > testing needs to be done by some/anyone with access to sis3316 hardware. > > Note: it is not necessary to have used the forked branch to provide > helpful test results!? Knowing that the new changes do not break other > sis3316-behaviour would also be very helpful. > > Thus, this is a call for help!? ;) > > As can be seen in the repository graph > > https://gitlab.com/chalmers-subexp/nurdlib/-/network/master?ref_type=heads > > there are about 20 commits.? Some of them are followed by fixup commits, > where we just kept a minimal merge first, and then fixed compilation > issues separately, in order to more easily follow any mistakes.? I.e.: > when a commit is followed by fixup commits, it only makes sense to test > the last fixup commit in that sequence. > > I would suggest the following test strategy: > > 0) First test the 'rebasing_sis3316' branch. > ?? If we are lucky - it just works! > > 1) If 0) fails, then test the fork point, i.e. the currently the > ?? commit e2163738.? This is an close ancestor of the nurdlib master > ?? branch, and thus contains no additional sis3316 changes than has been > ?? in the master branch so far. > > ?? When testing that, it will probably be necessary to comment out some > ?? settings, which have been implemented in the new branch. > > ?? If this fails, nurdlib master has a problem, which I think should be > ?? looked into before proceeding further. > > 2) Move forward, commit by commit (in steps to fixup commits where they > ?? follow other commits).? For each such commit, test and see if it still > ?? works.? If a commit implements a new option, also test that one. > > This way, we should hopefully be able to pin-point any issues. > > Best regards, > H?kan > From g.weber at hi-jena.gsi.de Fri Mar 22 12:20:09 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Fri, 22 Mar 2024 11:20:09 +0000 Subject: [subexp-daq] Question on UCESB / UPEXPS Message-ID: Dear friends, we have now checked the code for the SIS3316 module and will push a version with some bug fixes soon. The next thing on our list is to understand how we can access and store the data that we produce. Bastian told us the following command to write LMD files to hard disk: /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/drasi/bin/lwrocctrl localhost --file-open=auto=1Gi,${file} How does this LWROCCTRL work together with the Event Builder and UCESB which are started by the following commands? ../drasi/bin/lwrocmerge \ --label=MCAL_EB \ --merge-mode=event \ --server=trans,flush=1 \ --server=stream,flush=1 \ --buf=size=800Mi \ --max-ev-size=10Mi \ --eb-master=rio4-mcal-2 \ --file-writer \ --drasi=rio4-mcal-2 ------------------------------------ while : do ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ stream://localhost \ --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 sleep 5 done Moreover, to read in the online data stream as well as the LMD files from disk, to us it looks like Bastian used a programm called UCESB_IN which is using a mapping that is defined within UPEXPS to interpret the content of the LMD files. To us it looks like UCESB_IN is like a wrapper for UCESB to do a mapping of the content of the LMD events and to send out a data stream of some of this content. Attached please find the configuration file for UCESB_IN. Here, we are not sure up to which point there is a common approach to read experimental data and beyond that everybody is on his own. Many thanks and best greetings from Jena G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ucesb_in.cfg Type: application/octet-stream Size: 2687 bytes Desc: ucesb_in.cfg URL: From f96hajo at chalmers.se Fri Mar 22 13:06:25 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Fri, 22 Mar 2024 13:06:25 +0100 Subject: [subexp-daq] Question on UCESB / UPEXPS In-Reply-To: References: Message-ID: <241125ce-60af-a7b7-f94a-096376b519b1@chalmers.se> Dear G?nter, feel free to respond to issues separately, it was quite a bunch of questions :-) (I like!) On Fri, 22 Mar 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > we have now checked the code for the SIS3316 module and will push a version > with some bug fixes soon. That is excellent news! > The next thing on our list is to understand how we can access and store the > data that we produce. Bastian told us the following command to write LMD > files to hard disk: > > > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/drasi/bin/lwrocctrl > localhost --file-open=auto=1Gi,${file} > > How does this LWROCCTRL work together with the Event Builder and UCESB which > are started by the following commands? > > ../drasi/bin/lwrocmerge \ > ?? ?--label=MCAL_EB \ > ?? ?--merge-mode=event \ > ?? ?--server=trans,flush=1 \ > ?? ?--server=stream,flush=1 \ > ?? ?--buf=size=800Mi \ > ?? ?--max-ev-size=10Mi \ > ?? ?--eb-master=rio4-mcal-2 \ > ?? ?--file-writer \ > ?? ?--drasi=rio4-mcal-2 > > ------------------------------------ lwrocctrl works by communicating with drasi instances. for the lwrocctrl --file... options, it should be an instance which has a --file-writer specified. You can run the lwrocctrl also from another machine (e.g. your PC), but then instead of 'localhost' give the name (or IP) of the machine where the instance is running. For the communication to work, both have to find a directory ~/.drasi_tokens/ with one or more common files which it will do a cheap hash of. That is just some very minor protection against mistakes (users talking with the wrong machine. It is not a security measure as such. To see if an instance is willing to talk, you can try PATH-TO-DRASI/bin/bin/lwrocctrl --file-status [node] > > while : > do > ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ > ? ? stream://localhost \ > ? ? --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 > sleep 5 > done ? ? That connects to the server above (lwrocmerge) started with --server=stream. And its --server option means it will act as a kind of proxy server. I.e. other users that want data can connect to that instead of directly to the DAQ process. > Moreover, to read in the online data stream as well as the LMD files from > disk, to us it looks like Bastian used a programm called UCESB_IN which is > using a mapping that is defined within UPEXPS to interpret the content of > the LMD files. To us it looks like UCESB_IN is like a wrapper for UCESB to > do a mapping of the content of the LMD events and to send out a data stream > of some of this content. Attached please find the configuration file for > UCESB_IN. The attached .cfg file looks like a setup for Bastii's nupeline, which I have very little clue about. Indeed it sure looks like it in turn uses an UCESB unpacker. With the source in upexps. That (upexps) has maintenance issues. Perhaps someone else reading this mailing list is also using unpackers from the upexps? If so, now would be a good time to speak up, because I think we need to figure out how to have something backwards compatible and maintainable for you, without being 'encouraged' to do the maintenance work that other users at GSI (R3B) refuse to do... > Here, we are not sure up to which point there is a common approach to read > experimental data and beyond that everybody is on his own. ... while still sharing as much as possible with other users. > Many thanks and best greetings from Jena > G?nter Cheers, H?kan From g.weber at hi-jena.gsi.de Fri Mar 22 17:24:35 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Fri, 22 Mar 2024 16:24:35 +0000 Subject: [subexp-daq] SIS3316 implementation in NURDLIB fixed Message-ID: <491be67cb51542f78f084ac5c8a51d08@hi-jena.gsi.de> Dear friends, we just pushed a fixed version of the SIS3316 implementation. Compared to the original version of REBASING_SIS3316 a lot of glitches in the code were fixed in a first run a few days ago and now we finally also fixed a long-standing problem with the readout of the averaged traces. Best greetings and have a nice weekend everybody G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Fri Mar 22 17:37:42 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Fri, 22 Mar 2024 17:37:42 +0100 Subject: [subexp-daq] SIS3316 implementation in NURDLIB fixed In-Reply-To: <491be67cb51542f78f084ac5c8a51d08@hi-jena.gsi.de> References: <491be67cb51542f78f084ac5c8a51d08@hi-jena.gsi.de> Message-ID: <4eac8d00-c1a5-407e-39e6-05f2cfbacb87@chalmers.se> Dear G?nter, just had a quick look: This old code with +1 is surely not good: bytes_to_read = ((a_words_to_read * sizeof(uint32_t)) + 1) & ~0x7; Since sizeof(uint32_t) is 4, the addition of 1 would not have any effect. However, I'm a bit wondering about addint 8 (and 16 in the case of ~0xf). How about the following: bytes_to_read = ((a_words_to_read * sizeof(uint32_t)) + 0x7) & ~0x7; (and '+ 0xf' with '& ~0xf') ? That ought to bring it up to the next boundary if the read count was unaligned. And the if-statements would not be needed. Cheers, H?kan On Fri, 22 Mar 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > we just pushed a fixed version of the SIS3316 implementation. Compared to > the original version of REBASING_SIS3316 a lot of glitches in the code were > fixed in a first run a few days ago and now we finally also fixed a > long-standing problem with the readout of the averaged traces. > > > > > > Best greetings and have a nice weekend everybody > > G?nter > > > > > > From g.weber at hi-jena.gsi.de Fri Mar 22 17:49:40 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Fri, 22 Mar 2024 16:49:40 +0000 Subject: [subexp-daq] Question on UCESB / UPEXPS In-Reply-To: <241125ce-60af-a7b7-f94a-096376b519b1@chalmers.se> References: , <241125ce-60af-a7b7-f94a-096376b519b1@chalmers.se> Message-ID: <6838bc02e7e44974939bcc385b4f1d02@hi-jena.gsi.de> Dear H?kan, thank you very much for the explanations. To be independent from Bastian's legacy code we have now our tailor made unpacker for some of the LMD data. If we found a way to feed it not only with files from hard disk but also the data stream provided by UCESB, we could also use it for online analysis. We could then adapt this unpacker to the specific structure of our experimental data. However, as UCESB itself is (as I understand) an unpacker for LMD data, probably the better way would be to use UCESB for basic unpacking into LMD events/subevents and then as a second stage a dedicated mapper (which in an ideal world would result from the settings of the modules in main.cfg) to interpret the data words. This is (again: as I understand it) the approach taken by Bastian. This second stage could then curate/organize the data and give it to subsequent programs in a more user-friendly data format than plain LMD structures. However, I see little use to invest time into the existing NUPELINE package if Bastian was basicly the only person maintaining it. Is there maybe something else 'on the market'? Or am I mistaken and there is somebody out there, who is also continuing to use NUPELINE? (Sorry, if this e-mail is a bit repetitive. I just want to make sure that my understanding of the situation is correct.) Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Freitag, 22. M?rz 2024 13:06 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] Question on UCESB / UPEXPS Dear G?nter, feel free to respond to issues separately, it was quite a bunch of questions :-) (I like!) On Fri, 22 Mar 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > we have now checked the code for the SIS3316 module and will push a version > with some bug fixes soon. That is excellent news! > The next thing on our list is to understand how we can access and store the > data that we produce. Bastian told us the following command to write LMD > files to hard disk: > > > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/drasi/bin/lwrocctrl > localhost --file-open=auto=1Gi,${file} > > How does this LWROCCTRL work together with the Event Builder and UCESB which > are started by the following commands? > > ../drasi/bin/lwrocmerge \ > --label=MCAL_EB \ > --merge-mode=event \ > --server=trans,flush=1 \ > --server=stream,flush=1 \ > --buf=size=800Mi \ > --max-ev-size=10Mi \ > --eb-master=rio4-mcal-2 \ > --file-writer \ > --drasi=rio4-mcal-2 > > ------------------------------------ lwrocctrl works by communicating with drasi instances. for the lwrocctrl --file... options, it should be an instance which has a --file-writer specified. You can run the lwrocctrl also from another machine (e.g. your PC), but then instead of 'localhost' give the name (or IP) of the machine where the instance is running. For the communication to work, both have to find a directory ~/.drasi_tokens/ with one or more common files which it will do a cheap hash of. That is just some very minor protection against mistakes (users talking with the wrong machine. It is not a security measure as such. To see if an instance is willing to talk, you can try PATH-TO-DRASI/bin/bin/lwrocctrl --file-status [node] > > while : > do > ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ > stream://localhost \ > --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 > sleep 5 > done That connects to the server above (lwrocmerge) started with --server=stream. And its --server option means it will act as a kind of proxy server. I.e. other users that want data can connect to that instead of directly to the DAQ process. > Moreover, to read in the online data stream as well as the LMD files from > disk, to us it looks like Bastian used a programm called UCESB_IN which is > using a mapping that is defined within UPEXPS to interpret the content of > the LMD files. To us it looks like UCESB_IN is like a wrapper for UCESB to > do a mapping of the content of the LMD events and to send out a data stream > of some of this content. Attached please find the configuration file for > UCESB_IN. The attached .cfg file looks like a setup for Bastii's nupeline, which I have very little clue about. Indeed it sure looks like it in turn uses an UCESB unpacker. With the source in upexps. That (upexps) has maintenance issues. Perhaps someone else reading this mailing list is also using unpackers from the upexps? If so, now would be a good time to speak up, because I think we need to figure out how to have something backwards compatible and maintainable for you, without being 'encouraged' to do the maintenance work that other users at GSI (R3B) refuse to do... > Here, we are not sure up to which point there is a common approach to read > experimental data and beyond that everybody is on his own. ... while still sharing as much as possible with other users. > Many thanks and best greetings from Jena > G?nter Cheers, H?kan -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Fri Mar 22 18:06:13 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Fri, 22 Mar 2024 18:06:13 +0100 Subject: [subexp-daq] Question on UCESB / UPEXPS In-Reply-To: <6838bc02e7e44974939bcc385b4f1d02@hi-jena.gsi.de> References: , <241125ce-60af-a7b7-f94a-096376b519b1@chalmers.se> <6838bc02e7e44974939bcc385b4f1d02@hi-jena.gsi.de> Message-ID: <83117131-7677-81ed-382f-ade9b38e8006@chalmers.se> On Fri, 22 Mar 2024, Weber, Guenter Dr. wrote: > > Dear H?kan, > > > thank you very much for the explanations. > > > To be independent from Bastian's legacy code we have now our tailor made > unpacker for some of the LMD data. If we found a way to feed it not only > with files from hard disk but also the data stream provided by UCESB, we > could also use it for online analysis. We could then adapt this unpacker to > the specific structure of our experimental data. One could use ucesb in some kind of pass-through mode to read data from a network source. Roughly: empty/empty --stream=HOST:PORT --output=- | ./other_unpacker_program > However, as UCESB itself is (as I understand) an unpacker for LMD data, > probably the better way would be to use UCESB for basic unpacking into LMD UCESB is maily used to unpack _from_ LMD files. (The LMD -> LMD gymnastics that it can do are more like additions that turned out to be useful.) The UCESB empty/empty program is a compile of ucesb without any data mapping, so it only 'exposes' the LMD->LMD features. In the above case, just reading data from LMD stream (or transport) servers, and delivering it on stdout. > events/subevents and then as a second stage a dedicated mapper (which in an > ideal world would result from the settings of the modules in main.cfg) to > interpret the data words. This is (again: as I understand it) the approach > taken by Bastian. This second stage could then curate/organize the data and > give it to subsequent programs in a more user-friendly data format than > plain LMD structures. I think the more plain data structures that Bastii uses in e.g. nupeline (as referenced in ucesb_in.cfg) are from a UCESB-based unpacker, with the specifications (and mappings) in the upexps repository. > However, I see little use to invest time into the existing NUPELINE package > if Bastian was basicly the only person maintaining it. Is there maybe > something else 'on the market'? Or am I mistaken and there is somebody out > there, who is also continuing to use NUPELINE? > > > (Sorry, if this e-mail is a bit repetitive. I just want to make sure that my > understanding of the situation is correct.) > > > > > Best greetings > > G?nter Cheers, H?kan > > > > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan > T Johansson > Gesendet: Freitag, 22. M?rz 2024 13:06 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] Question on UCESB / UPEXPS ? > > Dear G?nter, > > feel free to respond to issues separately, it was quite a bunch of > questions :-)? (I like!) > > On Fri, 22 Mar 2024, Weber, Guenter Dr. wrote: > > > > > Dear friends, > > > > > > we have now checked the code for the SIS3316 module and will push a > version > > with some bug fixes soon. > > That is excellent news! > > > The next thing on our list is to understand how we can access and store > the > > data that we produce. Bastian told us the following command to write LMD > > files to hard disk: > > > > > > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/drasi/bin/lwrocctrl > > localhost --file-open=auto=1Gi,${file} > > > > How does this LWROCCTRL work together with the Event Builder and UCESB > which > > are started by the following commands? > > > > ../drasi/bin/lwrocmerge \ > > ?? ?--label=MCAL_EB \ > > ?? ?--merge-mode=event \ > > ?? ?--server=trans,flush=1 \ > > ?? ?--server=stream,flush=1 \ > > ?? ?--buf=size=800Mi \ > > ?? ?--max-ev-size=10Mi \ > > ?? ?--eb-master=rio4-mcal-2 \ > > ?? ?--file-writer \ > > ?? ?--drasi=rio4-mcal-2 > > > > ------------------------------------ > > lwrocctrl works by communicating with drasi instances. > for the lwrocctrl --file... options, it should be an instance which has a > --file-writer specified. > > You can run the lwrocctrl also from another machine (e.g. your PC), but > then instead of 'localhost' give the name (or IP) of the machine where the > instance is running. > > For the communication to work, both have to find a directory > ~/.drasi_tokens/ with one or more common files which it will do a cheap > hash of.? That is just some very minor protection against mistakes (users > talking with the wrong machine.? It is not a security measure as such. > > To see if an instance is willing to talk, you can try > > PATH-TO-DRASI/bin/bin/lwrocctrl --file-status [node] > > > > > while : > > do > > ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ > > ? ? stream://localhost \ > > ? ? --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 > > sleep 5 > > done ? ? > > That connects to the server above (lwrocmerge) started with > --server=stream. > > And its --server option means it will act as a kind of proxy server.? I.e. > other users that want data can connect to that instead of directly to the > DAQ process. > > > Moreover, to read in the online data stream as well as the LMD files from > > disk, to us it looks like Bastian used a programm called UCESB_IN which is > > using a mapping that is defined within UPEXPS to interpret the content of > > the LMD files. To us it looks like UCESB_IN is like a wrapper for UCESB to > > do a mapping of the content of the LMD events and to send out a data > stream > > of some of this content. Attached please find the configuration file for > > UCESB_IN. > > The attached .cfg file looks like a setup for Bastii's nupeline, which I > have very little clue about. > > Indeed it sure looks like it in turn uses an UCESB unpacker.? With the > source in upexps.? That (upexps) has maintenance issues. > > Perhaps someone else reading this mailing list is also using unpackers > from the upexps?? If so, now would be a good time to speak up, because I > think we need to figure out how to have something backwards compatible and > maintainable for you, without being 'encouraged' to do the maintenance > work that other users at GSI (R3B) refuse to do... > > > Here, we are not sure up to which point there is a common approach to read > > experimental data and beyond that everybody is on his own. > > ... while still sharing as much as possible with other users. > > > Many thanks and best greetings from Jena > > G?nter > > Cheers, > H?kan > > From opapst at ikp.tu-darmstadt.de Fri Mar 22 19:28:40 2024 From: opapst at ikp.tu-darmstadt.de (Oliver Papst) Date: Fri, 22 Mar 2024 19:28:40 +0100 Subject: [subexp-daq] Question on UCESB / UPEXPS In-Reply-To: <6838bc02e7e44974939bcc385b4f1d02@hi-jena.gsi.de> References: , <241125ce-60af-a7b7-f94a-096376b519b1@chalmers.se> <6838bc02e7e44974939bcc385b4f1d02@hi-jena.gsi.de> Message-ID: <5816b34eeacbe0edbdc93f889c9c34d1c145f613.camel@ikp.tu-darmstadt.de> Dear G?nter, I am another user of nupeline. We use it both in Darmstadt for the DHIPS setup and at HI?S, Duke University, for our experiments using the Clover array setup. I have created several boxes myself, but I don?t have the capacity to put any work into nupeline myself. I just use it as-it-is. For lack of a better alternative that is known to us, we will continue to use it for now. I would also prefer using something that is actively maintained, though. Cheers, Oliver On Fri, 2024-03-22 at 16:49 +0000, Weber, Guenter Dr. wrote: > Dear H?kan, > > > thank you very much for the explanations. > > > To be independent from Bastian's legacy code we have now our tailor made unpacker for some of the LMD data. If we found a way to feed it not only with files from hard disk but also the data stream provided by UCESB, we could also use it for online analysis. We could then adapt this unpacker to the specific structure of our experimental data. > > > However, as UCESB itself is (as I understand) an unpacker for LMD data, probably the better way would be to use UCESB for basic unpacking into LMD events/subevents and then as a second stage a dedicated mapper (which in an ideal world would result from the settings of the modules in main.cfg) to interpret the data words. This is (again: as I understand it) the approach taken by Bastian. This second stage could then curate/organize the data and give it to subsequent programs in a more user-friendly data format than plain LMD structures. > > > However, I see little use to invest time into the existing NUPELINE package if Bastian was basicly the only person maintaining it. Is there maybe something else 'on the market'? Or am I mistaken and there is somebody out there, who is also continuing to use NUPELINE? > > > (Sorry, if this e-mail is a bit repetitive. I just want to make sure that my understanding of the situation is correct.) > > > > > Best greetings > > G?nter > > > > > ________________________________ > Von: subexp-daq im Auftrag von H?kan T Johansson > Gesendet: Freitag, 22. M?rz 2024 13:06 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] Question on UCESB / UPEXPS > > > Dear G?nter, > > feel free to respond to issues separately, it was quite a bunch of > questions :-) (I like!) > > On Fri, 22 Mar 2024, Weber, Guenter Dr. wrote: > > > > > Dear friends, > > > > > > we have now checked the code for the SIS3316 module and will push a version > > with some bug fixes soon. > > That is excellent news! > > > The next thing on our list is to understand how we can access and store the > > data that we produce. Bastian told us the following command to write LMD > > files to hard disk: > > > > > > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2021_mcalstruck/drasi/bin/lwrocctrl > > localhost --file-open=auto=1Gi,${file} > > > > How does this LWROCCTRL work together with the Event Builder and UCESB which > > are started by the following commands? > > > > ../drasi/bin/lwrocmerge \ > > --label=MCAL_EB \ > > --merge-mode=event \ > > --server=trans,flush=1 \ > > --server=stream,flush=1 \ > > --buf=size=800Mi \ > > --max-ev-size=10Mi \ > > --eb-master=rio4-mcal-2 \ > > --file-writer \ > > --drasi=rio4-mcal-2 > > > > ------------------------------------ > > lwrocctrl works by communicating with drasi instances. > for the lwrocctrl --file... options, it should be an instance which has a > --file-writer specified. > > You can run the lwrocctrl also from another machine (e.g. your PC), but > then instead of 'localhost' give the name (or IP) of the machine where the > instance is running. > > For the communication to work, both have to find a directory > ~/.drasi_tokens/ with one or more common files which it will do a cheap > hash of. That is just some very minor protection against mistakes (users > talking with the wrong machine. It is not a security measure as such. > > To see if an instance is willing to talk, you can try > > PATH-TO-DRASI/bin/bin/lwrocctrl --file-status [node] > > > > > while : > > do > > ~/mbsrun/rio4/mcalstruck/ucesb/empty/empty \ > > stream://localhost \ > > --server=stream:8001,bufsize=10Mi,flush=1,dataport:7001 > > sleep 5 > > done > > That connects to the server above (lwrocmerge) started with > --server=stream. > > And its --server option means it will act as a kind of proxy server. I.e. > other users that want data can connect to that instead of directly to the > DAQ process. > > > Moreover, to read in the online data stream as well as the LMD files from > > disk, to us it looks like Bastian used a programm called UCESB_IN which is > > using a mapping that is defined within UPEXPS to interpret the content of > > the LMD files. To us it looks like UCESB_IN is like a wrapper for UCESB to > > do a mapping of the content of the LMD events and to send out a data stream > > of some of this content. Attached please find the configuration file for > > UCESB_IN. > > The attached .cfg file looks like a setup for Bastii's nupeline, which I > have very little clue about. > > Indeed it sure looks like it in turn uses an UCESB unpacker. With the > source in upexps. That (upexps) has maintenance issues. > > Perhaps someone else reading this mailing list is also using unpackers > from the upexps? If so, now would be a good time to speak up, because I > think we need to figure out how to have something backwards compatible and > maintainable for you, without being 'encouraged' to do the maintenance > work that other users at GSI (R3B) refuse to do... > > > Here, we are not sure up to which point there is a common approach to read > > experimental data and beyond that everybody is on his own. > > ... while still sharing as much as possible with other users. > > > Many thanks and best greetings from Jena > > G?nter > > Cheers, > H?kan From g.weber at hi-jena.gsi.de Fri Mar 22 23:01:29 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Fri, 22 Mar 2024 22:01:29 +0000 Subject: [subexp-daq] SIS3316 implementation in NURDLIB fixed In-Reply-To: <4eac8d00-c1a5-407e-39e6-05f2cfbacb87@chalmers.se> References: <491be67cb51542f78f084ac5c8a51d08@hi-jena.gsi.de>, <4eac8d00-c1a5-407e-39e6-05f2cfbacb87@chalmers.se> Message-ID: <70134907f22c4314936cbbdb39a62d51@hi-jena.gsi.de> Yes, I think you are right. ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Freitag, 22. M?rz 2024 17:37:42 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] SIS3316 implementation in NURDLIB fixed Dear G?nter, just had a quick look: This old code with +1 is surely not good: bytes_to_read = ((a_words_to_read * sizeof(uint32_t)) + 1) & ~0x7; Since sizeof(uint32_t) is 4, the addition of 1 would not have any effect. However, I'm a bit wondering about addint 8 (and 16 in the case of ~0xf). How about the following: bytes_to_read = ((a_words_to_read * sizeof(uint32_t)) + 0x7) & ~0x7; (and '+ 0xf' with '& ~0xf') ? That ought to bring it up to the next boundary if the read count was unaligned. And the if-statements would not be needed. Cheers, H?kan On Fri, 22 Mar 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > we just pushed a fixed version of the SIS3316 implementation. Compared to > the original version of REBASING_SIS3316 a lot of glitches in the code were > fixed in a first run a few days ago and now we finally also fixed a > long-standing problem with the readout of the averaged traces. > > > > > > Best greetings and have a nice weekend everybody > > G?nter > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Sat Mar 23 09:25:11 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Sat, 23 Mar 2024 09:25:11 +0100 Subject: [subexp-daq] SIS3316 implementation in NURDLIB fixed In-Reply-To: <70134907f22c4314936cbbdb39a62d51@hi-jena.gsi.de> References: <491be67cb51542f78f084ac5c8a51d08@hi-jena.gsi.de>, <4eac8d00-c1a5-407e-39e6-05f2cfbacb87@chalmers.se> <70134907f22c4314936cbbdb39a62d51@hi-jena.gsi.de> Message-ID: <094829a7-9155-a738-50a9-7d1f2cc65f1f@chalmers.se> Dear G?nter, I just pushed a new branch 'rebasing_sis3316_dma_align' to gitlab which changes to use that method instead. It also moved the calculation of bytes_to_read up, as otherwise warnings for possibly uninitialised variable use were generated. I am not sure if the check for buffer overflow is taking into account other data already added to the output. This I think Hans is better to figure out. Perhaps too many variables at once, but this new branch has been rebased on top of current nurdlib master. Cheers, H?kan On Fri, 22 Mar 2024, Weber, Guenter Dr. wrote: > > Yes, I think you are right. > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan > T Johansson > Gesendet: Freitag, 22. M?rz 2024 17:37:42 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] SIS3316 implementation in NURDLIB fixed ? > > Dear G?nter, > > just had a quick look: > > This old code with +1 is surely not good: > > ??????????????? bytes_to_read = > ??????????????????? ((a_words_to_read * sizeof(uint32_t)) + 1) & ~0x7; > > Since sizeof(uint32_t) is 4, the addition of 1 would not have any effect. > > However, I'm a bit wondering about addint 8 (and 16 in the case of ~0xf). > > How about the following: > > ??????????????? bytes_to_read = > ??????????????????? ((a_words_to_read * sizeof(uint32_t)) + 0x7) & ~0x7; > > (and '+ 0xf' with '& ~0xf') ? > > That ought to bring it up to the next boundary if the read count was > unaligned.? And the if-statements would not be needed. > > Cheers, > H?kan > > > > > On Fri, 22 Mar 2024, Weber, Guenter Dr. wrote: > > > > > Dear friends, > > > > > > we just pushed a fixed version of the SIS3316 implementation. Compared to > > the original version of REBASING_SIS3316 a lot of glitches in the code > were > > fixed in a first run a few days ago and now we finally also fixed a > > long-standing problem with the readout of the averaged traces. > > > > > > > > > > > > Best greetings and have a nice weekend everybody > > > > G?nter > > > > > > > > > > > > > >