[subexp-daq] Question on DRASI and R3BFUSER

[Weber, Guenter Dr.]

Dear Hans and Håkan,


thank you very much for the detailed explanation. Now I have two remaining questions:


1) To tell the second DAQ system to also put a timestamp in the output LMD data, we would need to create r3bfuser.cfg with the wr_id entry, right?

(I am surprised that r3bfuser.cfg does not need to exist. I imagine a user getting crazy over changes made in his r3dfuser.cfg not having any effect on the DAQ, before realizing that there is a typo in the filename.)

And then also tell the VULOM in main.cfg to produce the timestamp (i.e. basicly copy the settings from the first DAQ system).


2a) Why does in our first DAQ system the address of the TRIVA not need to be set?


--triva=master,fctime=10,ctime=50 \


versus


--triva=master, at 0x02,fctime=10,ctime=300 \


2b) What are fctime (fast clear time) and ctime (conversion time) actually doing?




Thanks a lot!




Best greetings

Günter



________________________________
Von: subexp-daq <subexp-daq-bounces at lists.chalmers.se> im Auftrag von Håkan T Johansson <f96hajo at chalmers.se>
Gesendet: Mittwoch, 17. April 2024 10:16:41
An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.
Cc: Weber, Guenter Dr.
Betreff: Re: [subexp-daq] Question on DRASI and R3BFUSER


On Wed, 17 Apr 2024, Hans Toshihide Törnqvist wrote:

> I would love to find a way to clean this up, but the gist is:
>
> - nurdlib reads out and verifies module data and does not know how to
> present them to the outside world.
>
> - r3bfuser provides the glue between the nurdlib module data and the DAQ
> backend.
>
> This way nurdlib is not married to MBS or drasi and could be used by
> "any" such code. It will read e.g. timestamps from a vulom or vetar in
> single- or multi-even mode or whatever and dump that straight into an
> event buffer, no further processing done (well, timestamps must be saved
> in big-endian form). Nurdlib has no idea about how the DAQ backend needs
> the timestamp to be presented. The config in main.cfg for the trlo ii
> modules tells nurdlib that we expect and want to read out timestamps for
> every trigger, which is not something we always want from such a module.
> The vetar only delivers timestamps so that is not configurable.
>
> So, r3bfuser has to convert the raw data from nurdlib to something the
> backend understands. MBS/drasi expects a unique timestamp ID for every
> timestamped system which is what one sets in r3bfuser.cfg. The code then
> asks nurdlib for a timestamping module (I think there's a
> priority-selection, like try first vetar then vulom then tridi...),

I think a scary part here is that r3bfuser auto-finds a module to provide
the time.  It would perhaps be possible to encourage to user to specify
which (kind of) source (vetar, vulom, tridi...) one would like to use for
the special formatting into the DAQ-readable location, and if not
available, it errors out.  There could also be an option 'auto' for the
lazy, who then get to keep both pieces when it breaks (or rather - be
confused as to which timestamp source is used).

> and
> for every event gets the region in the event buffer with the raw data
> from the module. It takes the first 64-bit number and creates the first
> 10/1 sub-event with the configured timestamp ID,

This is the 'wr_id' specified in the r3bfuser.cfg.

> error bits, the
> formatted timestamp etc. The behaviour of this part can be defined in
> many ways, which is why it's not done in the simple built-in f-user in
> nurdlib but confined to the external r3bfuser.
>
> I'm open to suggestions on how to simplify this without making the code
> sentient :)
>
>> To make the situation more puzzling (to us), in the second system that
>> is now finally running again, we don't have a r3bfuser.cfg at all. Here
>> the command to start the DAQ looks like this:
>>
>> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi \
>> --triva=master, at 0x02,fctime=10,ctime=300 \
>> --log-no-rate-limit \
>> --server=stream:8003 \
>> --server=drasi,dest=lyserv:7000 \
>> --buf=size=200Mi \
>> --max-ev-size=0x100000 \
>> --eb=lyserv:7000 \
>> --subev=crate=0,type=88,subtype=8800,control=0,procid=12 \
>> "$@"
>>
>> Is the "@0x02" in this command replacing the r3bfuser.cfg? If yes, 0x2
>> instead of 0x200 tells us that there is no timestamp, yes?
>
> No, the @0x02 is the short-hand address for the trigger module (triva),
> and really means "address = 0x02 << 24 = 0x02000000". Drasi needs to
> know which module to talk to to know there are accepted triggers, to
> release deadtime etc.
>
> Best regards,
> Hans

Cheers,
Håkan


>
>> Ok, so the bottom line is, that we basicly don't understand this
>> timestamp thing :-)
>>
>> Could you give us a hint?
>>
>> Thank you so much!
>>
>> Best greetings
>>
>> Günter
>>
>>
>>
>>
>>
> --
> subexp-daq mailing list
> subexp-daq at lists.chalmers.se
> https://lists.chalmers.se/mailman/listinfo/subexp-daq
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chalmers.se/pipermail/subexp-daq/attachments/20240417/626583eb/attachment.html>