With the connectivity service changes, it is now possible for DAQ modules to generate their own connection names, as long as both ends of the connection agree on the naming convention in use. This document shows an example of using these dynamic connection names for the TriggerRecordBuilder.
void
TriggerRecordBuilder::init(const data_t& init_data)
{
TLOG_DEBUG(TLVL_ENTER_EXIT_METHODS) << get_name() << ": Entering init() method";
//--------------------------------
// Get single queues
//---------------------------------
auto ci = appfwk::connection_index(init_data, { "trigger_decision_input", "trigger_record_output" });
auto iom = iomanager::IOManager::get();
m_trigger_decision_input = iom->get_receiver<dfmessages::TriggerDecision>(ci["trigger_decision_input"]);
m_trigger_record_output =
iom->get_sender<std::unique_ptr<daqdataformats::TriggerRecord>>(ci["trigger_record_output"]);
//----------------------
// Get dynamic queues
//----------------------
// set names for the fragment connections
auto ini = init_data.get<appfwk::app::ModInit>();
// get the names for the fragment connections
// there is an optional connection, which is the connection to DQM
// Since it's optional, we need to loop over all the connections
// to check if it's there and act accordingly
for (const auto& ref : ini.conn_refs) {
if (ref.name.rfind("data_fragment_") == 0) {
m_fragment_inputs.push_back(iom->get_receiver<std::unique_ptr<daqdataformats::Fragment>>(ref.uid));
} else if (ref.name == "mon_connection") {
m_mon_receiver = iom->get_receiver<dfmessages::TRMonRequest>(ref.uid);
}
}
TLOG_DEBUG(TLVL_ENTER_EXIT_METHODS) << get_name() << ": Exiting init() method";
}
void
TriggerRecordBuilder::init(const data_t& init_data)
{
TLOG_DEBUG(TLVL_ENTER_EXIT_METHODS) << get_name() << ": Entering init() method";
m_trigger_decision_input = get_iom_receiver<dfmessages::TriggerDecision>("trigger_decisions_for_" + m_this_trb_source_id.to_string());
m_trigger_record_output = get_iom_sender<std::unique_ptr<daqdataformats::TriggerRecord>>(appfwk::connection_inst(init_data, "trigger_record_output"));
// Only one Fragment input now, maybe change this to a single Receiver?
m_fragment_inputs.push_back(get_iom_receiver<std::unique_ptr<daqdataformats::Fragment>>("fragments_for_" + m_this_trb_source_id.to_string())); // This will also be put into DataRequests, no need for readout to worry about it
m_mon_receiver = get_iom_receiver<dfmessages:TRMonRequest>("trmon_requests_for_" + m_this_trb_source_id.to_string()); // No harm in always listening
TLOG_DEBUG(TLVL_ENTER_EXIT_METHODS) << get_name() << ": Exiting init() method";
}
Types of Sender/Receiver instances are not changed, so m_trigger_decision_input
is still an iomanager::Receiver<dfmessages::TriggerDecision>
, and will only receive TriggerDecision objects.
The "Current" style of retrieving connection information from configuration is still perfectly valid, and should be used where appropriate. (For example, the trigger_record_output connection above.)
Names such as "trigger_decsisions_for_" are for human readability, and are not required, as long as the generated portion (e.g. m_this_trb_source_id.to_string()) will be unique for that data type.