when setting both hsi options to false in daqconf configuration:
"use_timing_hsi": false
"use_fake_hsi": false
the daqconf throws and error:
ValueError: Connection with name hsievents has no producers!
The issue is that the hsi input is set to true (hardcoded) in trigger_gen:
USE_HSI_INPUT = True, in trigger_gen
and it is not actually loaded from set values in daqconf_multiru_gen.
This means that a hsievent consume connection is made when there are no producers.
The USE_HSI_INPUT should be passed from daqconf_multiru_gen to trigger_gen, depending on how the hsi options are set in the configuration.
The HSI configuration is now properly passed from (fd/ns) daqconf gen script to trigger gen in daqconf (previously just hardcoded true)
Inside trigger gen:
the Timing Trigger Candidate Maker (TTCM) - and its associated TCTee (to MLT and TC Buffer) - is now only constructed when there is an HSI source
there is an additional function now that checks for any TC source. The possible TC sources are:
Any TP source (which always involves TAMaker and TCMaker)
TTCM
Random Trigger Candidate Maker (RTCM)
Custom Trigger Candidate Maker (CTCM)
the reason for this is that a TCBuffer is always expected by other portions of the DAQ (for data requests) regardless of other configuration and it cannot be created without any queue connections. This ensures that the system does not break. Regardless, a TC source is sensible, and for simple tests can be simply a TTCM or RTCM (even with 0 rates if preferred).
Finally, when the TTCM is not present (no HSI source), there can be a situation when there are no subscribers for TimeSync messages from readout DLHs. The agreed solution during release prep meeting was that the requirement for subscribers for any source can be dropped: ie we now allow producers with no subscribers.
Tests:
Test #
Fake HSI
Timing HSI
RTCM
CTCM
Result
Status
Note
Log
1
0
0
0
0
Daqconf: RuntimeError
✓
RuntimeError: There are no TC sources!
2
1
0
0
0
config, run
✓
no issues
Run 111: Received 11 TCs. Sent 10 TDs consisting of 10 TCs. 1 TDs (1 TCs) were created during pause, and 0 TDs (0 TCs) were inhibited.
3
0
1
0
0
Daqconf: Exception
✓
Exception: If --use-hsi-hw flag is set to true, --hsi-device-name must be specified!
4
1
1
0
0
Daqconf: Exception
✓
Exception: If --use-hsi-hw flag is set to true, --hsi-device-name must be specified!
5
0
0
0
1
config, run
✓
no issues
Run 115: Received 88 TCs. Sent 37 TDs consisting of 37 TCs. 23 TDs (23 TCs) were created during pause, and 27 TDs (27 TCs) were inhibited.
6
0
0
1
0
config, run
✓
no issues
Run 116: Received 14 TCs. Sent 10 TDs consisting of 10 TCs. 4 TDs (4 TCs) were created during pause, and 0 TDs (0 TCs) were inhibited.
7
1
0
1
0
config, run
✓
no issues
Run 117: Received 21 TCs. Sent 20 TDs consisting of 20 TCs. 1 TDs (1 TCs) were created during pause, and 0 TDs (0 TCs) were inhibited.
when setting both hsi options to false in daqconf configuration:
the daqconf throws and error:
The issue is that the hsi input is set to true (hardcoded) in trigger_gen:
USE_HSI_INPUT = True,
in trigger_gen and it is not actually loaded from set values in daqconf_multiru_gen.This means that a hsievent consume connection is made when there are no producers. The USE_HSI_INPUT should be passed from daqconf_multiru_gen to trigger_gen, depending on how the hsi options are set in the configuration.
The fix for this are 3 PRs:
The solution:
Tests:
Also passes integration tests: