Closed bieryAtFnal closed 1 year ago
In testing recent nightly builds with DUNE-WIB TPs, I noticed several problems. One of them was the absence of an output TPStream file and associated complaints from the TPBundleHandler about duplicate TPSets.
To reproduce the problem, one can create a software area based on a recently nightly, such as described in steps 1-3 here. Then create a daqconf.json
file with the following contents:
{
"boot": {
"use_connectivity_service": true,
"start_connectivity_service": true,
"connectivity_service_host": "localhost",
"connectivity_service_port": 15432
},
"dataflow": {
"apps": [
{ "app_name": "dataflow0" },
{ "app_name": "dataflow1" }
]
},
"readout": {
"enable_tpg": true,
"clock_speed_hz": 62500000,
"data_rate_slowdown_factor": 10,
"tpg_threshold": 500,
"use_fake_cards": true,
"data_files": [
{"detector_id": 3, "data_file": "asset://?label=DuneWIB&subsystem=readout"}
]
},
"trigger": {
"enable_tpset_writing": true,
"trigger_activity_config": {"prescale":1000},
"trigger_window_before_ticks": 1000,
"trigger_window_after_ticks": 1000,
"trigger_rate_hz": 1.0
}
}
and, create a my_dro_map.json
file with the following contents:
[
{
"src_id": 100,
"geo_id": {
"det_id": 3,
"crate_id": 1,
"slot_id": 0,
"stream_id": 0
},
"kind": "flx",
"parameters": {
"protocol": "full",
"mode": "fix_rate",
"host": "localhost",
"card": 0,
"slr": 0,
"link": 0
}
},
{
"src_id": 101,
"geo_id": {
"det_id": 3,
"crate_id": 1,
"slot_id": 0,
"stream_id": 1
},
"kind": "flx",
"parameters": {
"protocol": "full",
"mode": "fix_rate",
"host": "localhost",
"card": 0,
"slr": 0,
"link": 1
}
}
]
then, run the following commands:
daqconf_multiru_gen -c ./daqconf.json --detector-readout-map-file ./my_dro_map.json my_test_config
nanorc my_test_config ${USER}-test boot conf start_run 101 wait 20 stop_run scrap terminate
egrep 'ERROR|WARNING' log_*
I believe that the problem was caused by the removal of the TP_DataLinkHandler in recent daqconf changes. This tripped a bug in WIB2TPHandler in which the presence of the queue between the DataLinkHandler and the TP_DataLinkHandler was required before any TPs would be added to TPSets.
The code changes associated with this PR attempt to fix this bug by allowing TPs to be added to TPSets independent of whether a queue for sending TPs to the TP_DataLinkHandler is available.
Thanks for catching (and fixing) this bug I introduced. The patch looks good to me
…independent of whether the tp_out connection is available.
Draft PR; I'll add more description soon.