[subexp-daq] Question: what is GEOM?

[Hans Toshihide Törnqvist]

Dear Günter,

In the beginning of development, like you said, it made sense to have an 
incrementing counter as a simple way to make sure every module has a 
unique ID.

The address is not something that automatically shows up in the event 
payload. For this, nurdlib would have to write a custom header for every 
module which we want to avoid. I am also not a fan of "should be unique" 
esp. with humans involved, it's better if the code forces/verifies 
unique identifiers.

Barriers are indeed extras, but not needed e.g. with a crate with 20 
Caen modules which can have a unique Geo in every header. (Never mind 
the real-life issues with such a setup...)

Many modules have some sort of Geo in the event header, esp. Caen and 
Mesytec modules, so that comes for free.

Eventually someone had a crate with the PAUX connectors which messed up 
the Geo numbering :) So nurdlib had to grow the ability to re-assign and 
avoid collisions.

And now the need for overriding Geo is cropping up, so it will happen 
soon. I just moved it up in my todo...

Cheers,
Hans

On 2024-04-22 16:40, Weber, Guenter Dr. wrote:
> Dear Hans, dear Håkan,
> 
> 
> thank you for the explanations. Maybe my questions don't make much sense 
> as I have not correctly understood the concept of this GEO number.
> 
> 
> As I see it, the DAQ software is (automaticly) assigning a GEO number to 
> (some of?) the modules that is then readout from the module again by the 
> same DAQ. We then need to know this number to configure the matching 
> procedure in the *.spec file. And just by guessing and looking what 
> Bastian provided us, we assumed that this number is assigned according 
> to the order that the modules appear in the main.cfg file.
> 
> 
> I get that it is nice to have a unique number for each module to make 
> sure that if there are many, you are always looking at the right one. 
> So, is the GEO number just a way to avoid identifying the modules by 
> tthe lengthy address that is set using the rotary switches (which 
> also should be unique for each crate, right?)?
> 
> 
> If possible and not already implemented, I think it would be really good 
> to have the option to set a GEO number in main.cfg for each module. This 
> would avoid having to deal with new GEO numbers for everything once 
> modules are added or removed (as Håkan already mentioned).
> 
> 
> But maybe I simply do not understand yet, how this GEO thing actually 
> works 😊
> 
> 
> 
> 
> Many thanks and best greetings
> 
> Günter
> 
> 
> ------------------------------------------------------------------------
> *Von:* subexp-daq <subexp-daq-bounces at lists.chalmers.se> im Auftrag von 
> Hans Toshihide Törnqvist <hans.tornqvist at chalmers.se>
> *Gesendet:* Montag, 22. April 2024 16:12:56
> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Håkan T Johansson
> *Betreff:* Re: [subexp-daq] Question: what is GEOM?
> Dear Günter,
> 
> To add to Håkan's response, some Caen modules (maybe others?) can assign
> its geom via the middle PAUX connector if that's available. I think
> there's a config to make nurdlib aware that the module will have an
> externally assigned geom number, but maybe also via a flag in a status
> register. These are checked against the automatically assigned geom's,
> so the step to overriding is not very big.
> 
> Mostly fyi :)
> 
> Cheers,
> Hans
> 
> On 2024-04-19 12:07, Håkan T Johansson wrote:
>> 
>> Dear Günter,
>> 
>> I think nurdlib will assign the geom numbers (for modules which have 
>> that kind of identifier settable) in order for the modules that are 
>> configured.
>> 
>> Unless not already implemented, it might be on Hans todo-list to be able 
>> to override that default, i.e. manually specify the module identifier 
>> that appears in the data.  That would be useful such that an unpacker 
>> can be used unchanged even if some detector/module is not present for 
>> some runs / experiments.
>> 
>> Cheers,
>> Håkan
>> 
>> 
>> 
>> On Fri, 19 Apr 2024, Weber, Guenter Dr. wrote:
>> 
>>>
>>> Dear friends,
>>>
>>>
>>> in my DAQ, I have three modules that are defined in main.cfg as follows:
>>>
>>>
>>>     # ADCs
>>>     CAEN_V785(0x11110000) {
>>>         threshold = (0 {32})
>>>     }
>>>     CAEN_V785(0x44440000) {
>>>         threshold = (0 {32})
>>>     }
>>>     # TDC
>>>     BARRIER
>>>     CAEN_V1190(0x22220000) {
>>>            blt_mode = noblt
>>>            edge = leading
>>>            resolution = 100 ps
>>>            deadtime = 5 ns
>>>         # with 100 ps resolution, max window size: 50 us
>>>            GATE {
>>>             time_after_trigger = -1us
>>>             width = 2us
>>>            }
>>>     }
>>>
>>> In the corresponding *.spec file, the data is matched via this commands:
>>>
>>>
>>>     adc[0] = VME_CAEN_V785(geom=1, crate=0);
>>>     adc[1] = VME_CAEN_V785(geom=2, crate=0);
>>>     b2 = BARRIER();
>>>     tdc = VME_CAEN_V1190(geom=3);
>>>
>>> My question is now, where is the GEOM number coming from? How do the 
>>> modules
>>> 'know' that they should have GEOM numbers 1 to 3?
>>>
>>>
>>>
>>> Thank you very much!
>>>
>>>
>>>
>>> Best greetings
>>> Günter
>>>
>>>
>>>
>>>
>> 
> -- 
> subexp-daq mailing list
> subexp-daq at lists.chalmers.se
> https://lists.chalmers.se/mailman/listinfo/subexp-daq 
> <https://lists.chalmers.se/mailman/listinfo/subexp-daq>
>