[subexp-daq] Question on DRASI and R3BFUSER

[Weber, Guenter Dr.]

Dear friends,


I have a question about the timestamp that can be created from the VULOM and/or the VETAR2 module.


On the first system that we set up with the new software, we had the following command to start the DAQ:


../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi \
        --label=MCAL1 \
        --triva=master,fctime=10,ctime=50 \
        --log-no-rate-limit \
        --server=drasi,dest=lyserv \
        --buf=size=400Mi \
        --max-ev-size=0x1000000 \
--subev=crate=1,type=20,subtype=2,control=9,procid=1 \
        --eb=lyserv \
"$@"


In addition there is a file r3bfuser.cfg with a single entry:


wr_id=0x200


Moreover, in the main.cfg we have the entry defining the VULOM functionality:


GSI_VULOM(0x03000000) {
timestamp = true # needed to get timestamps in the data output
ecl=0..15
}


As I understand, the entry in main.cfg is not enough to activate the VULOM timestamp, but need also the (a bit obsucre looking) entry in the r3bfuser.cfg, right? And both together result in the creation of an additional LMD subevent with hardcoded type=10 where the time stamp information is written.

Is there a good reason why the VULOM timestamp (and also VETAR2 if available) is not simply written to the subevent defined in the command that starts DRASI? And why is the existence of the timestamp defined in two different files?


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?


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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chalmers.se/pipermail/subexp-daq/attachments/20240416/a4dfbc7b/attachment.html>