FSM

Schematic

The FSM operates the DAQ infrastructure. The FSM commands are executed as

<command> <options>

for which is one of the FSMCommands (black arrow) defined here and each state (green box) is an FSMConfiguration defined here. FSMCommands can be run as FSMSequences (yellow lines) which execute a series of FSMCommands, as described here. These are ran analogously to FSMCommands.

Before and after certain transitions, there are FSMactions that are associated with certain FSMCommands, as defined here.

Three configurations are currently available:

• fsmConf-test
• fsmConf-prod
• FSMConfiguration_noAction

FSMconfiguration states

• none - apps have not been booted
• initial - app constructors have been ran
• configured - queues and connections have been initialized
• ready - TPs are being generated, but dropped at the DFO
• running - TPs are being generated and stored to disk
• dataflow_drained - TPs are being generated, but not propagated to the TRBs. DFO and DQM aplications stopped. Requests and fragments drained from queues
• trigger_sources_stopped - TPs are no longer being generated. HSI, sources, and readout fully stopped.

FSMCommands

These are the black arrows defined in the diagram. They are:

Transition name	Corresponding drunc command	Note
	(same with .replace("_","-").lower()
conf	conf	configure the apps by ingesting the parameters from the configuration file
start	start	start a run, allocating a run number. Initializes queues and connections
enable_triggers	enable-triggers	start generating TPs, TDs are not propagated to the DFO
disable_triggers	disable-triggers	stop collecting generated TPs to file
drain_dataflow	drain-dataflow	stop propagating TDs to the TRBs
stop_trigger_sources	stop-trigger-sources	stop generating TPs
stop	stop	stop the rest of the apps
scrap	scrap	basically no op (PL thinks?), intended to remove all the configuration parameters from the applications

actions

• usvc-provided-run-number - microservice (usvc) generates the run number. Will be used in production, not so much at the moment.
• file-logbook - generates a logbook as a file in the directory from which drunc was spawned. Takes the file name as an argument.
• elisa-logbook - pushes an entry to the ELisA logbook (instructions)
• db-run-registry -
• thread-pinning - has a pre-conf, post-conf, and post-start variable. Contains the file with the thread pinning configuration to attach specific processes to specific threads.

Transitions with pre- and post- sequences

The listings provide the actions in the order of execution. Any actions presented with parentheses e.g. (file-logbook) are optional.

start-prod

• pre - usvc-provided-run-number and db-run-registry
• post - (file-logbook), thread-pinning, and elisa-logbook

start-test

• pre - usvc-provided-run-number and file-run-registry
• post - (file-logbook) and thread-pinning

conf

• pre - thread-pinning
• post - thread-pinning

drain_dataflow-prod

• post- (db-run-registry), (file-logbook), (elisa-logbook)

drain_dataflow-test

• post- (file-logbook)

FSMsequence

These define a sequence of FSM commands pregrouped. These are executed in the order that they are presented in. They are currently only defined on the client side. They are executed as normal FSM commands. The existing sequences are in yellow in the diagram at the top of the screen. The sequences are

• start_run - executes conf, start, and enable_triggers
• stop_run - executes disable_triggers, drain_dataflow, stop_trigger_sources, and stop
• shutdown - executes disable_triggers, drain_dataflow, stop_trigger_sources, stop, and scrap