A previous decision was that set_condition gets implemented and handled by each service with no commands send back and forth to other services. For the DAQ, in practice this means that the DAQ run interface does very little, and underlying services actually have to stop the run.
We implemented this for the RSA as follows:
the daq_run_interface generically places the DAQ in safe_mode for all DAQ implementations
the rsa_provider actually executes the end_run
the rsa_daq_run_interface does nothing; it's _stop_data_taking method just calls rsa_provider.end_run, and this would require one service to talk with another
This remains partially unresolved for ROACH+psyllid, but I would envision the following solution"
[x] the daq_run_interface generically places the DAQ in safe_mode for all DAQ implementations
[ ] all psyllid instances catch the condition and attempt to stop-run
[x] psyllid_interface (dragonfly) does nothing; it's stop_run method only passes on to psyllid's stop-run
[x] roach_daq_run_interface does nothing; it's _stop_data_taking method would only unblock the channel in addition to calling psyllid_interface to stop the run; cleanup can happen later
We should maybe then be explicit about this in the documentation so we don't forget when this occurs for
A previous decision was that set_condition gets implemented and handled by each service with no commands send back and forth to other services. For the DAQ, in practice this means that the DAQ run interface does very little, and underlying services actually have to stop the run.
We implemented this for the RSA as follows:
This remains partially unresolved for ROACH+psyllid, but I would envision the following solution"
stop-runWe should maybe then be explicit about this in the documentation so we don't forget when this occurs for