The StateManager flow diagram controls which transitions are sent to the RunControl clients and the sychronization across all clients. The most popular StateManager diagram is DAQ, which is sued to physics, cosmic ray and system testing runs. The GenericCalibration StateManager is used for most calibrations; QIECalibration is used for the several QIE type calibrations. The CentralSourceCalibration and WallSourceCalibration are used by the source calibration experts during source runs, and are not generally used by the casual user or shiftcrew members. TDCTest controls basic tests of TDC functionality, and is mainly used by TDC experts. In summary:

StateManager	Runs
DAQ	Physics Cosmic Rays DAQ Testing Silicon DMode PMT Spike Run
QIECalibration	Calorimeter QIE SMX QIE CLC QIE BSC QIE Roman Pot SMQIE TOF QIE
TDCTest	TDC Testing (experts)
CentralSourceCalibration	Central Calorimeter Source (experts only)
GenericCalibration	Plug Laser CEM LED COT CEM XEF Muon TOF TAC
WallSourceCalibration	Central Calorimeter Source (experts only)

The StateManager is selected via the Enable pull-down menu at the top of the main RunControl window. One and only one StateManager is enabled at all times.

The DAQ StateManager is the standard and default StateManager for a wide array of RunTypes, including colliding beams, cosmic rays, DAQ testing, Calorimeter spike runs (RickRuns), etc. When you first start up RunControl, the DAQ StateManager will be enabled.

The user initiates the Partition - Setup - Activate sequence of transitions in order at the appropriate times in order to start a data acquisition run. When the DAQ StateManager reaches the Active state, the system is taking data. The user should follow the updating of the event counters at the bottom of the main RunControl window to make sure events are being collected.

When an error occurs, the first line of defense the the Halt - Recover - Run transition sequence. This may be issued with three separate transition commands, or by the single HRR composite transition. These two methods are completely equivalent. If HRR fails, then you may need to Reset and Shepherd a particular crate in order to provide a crate-wide hardware reset. Failing these options after a couple tries, you must notify the component expert and restart the run.

The Pause - Resume sequence may be used in order to quietly pause the data acquisition system without any hard resets. In this case, the system will be allowed to drain, an no events or triggers will be lost. In contrast, HRR will purge the system when it resets the hardware, and some triggers and/or events will be lost.

When the run is complete, the user chooses the End transition. The user should end the run when, for example: enough data has been taken for a particular purpose; the store is about to end; or some serious hardware problem has surfaced. In some cases, predefined RunConfigurations will set a limit on the number of events for the run &minus in this case, RunControl will automatically end the run when at least that number of events has been collected, without intervention from the user.

Sometimes transitions such as Config will not succeed due to the lack of response from one or more of the RunControl clients. In this case, the user must issue the Abort transition to regain control. Likewise, this may happen during HRR or Pause-Resume sequences. NB:Always try to use the End transition rather than Abort. Abort does not perform nice transition sequencing, and does not provide all end-of-run summary informations.

To add or remove RunControl crates or clients, the user must first return to the Start state via the Reset transition. Reset should only be issued while in the Idle state. When in other states or transitions, use Reset only as a last-ditch desperate measure. The system is not properly cleaned up if you go directly to Start from any other state then Idle

The QIE Calib StateManager is used during all QIE channel calibrations, including AdMem and SMXR cards. In this case the calibration takes place entirely within the frontEnd crates, without the control of the TriggerSupervisor. Therefore, only a software partition is required during these runs. As well, the number of transitions available is reduced. In particular, note that the Halt, Recover, Run sequence is not available, as it makes no sense in a software partition. Any failures during this run may leave the frontEnd crates in an unknown state, and so require the user to start over from the beginning.

The Setup transition configures the frontEnd crate processors in preparation for the QIE calibration. In practice Setup and Config are identical (cf. DAQ StateManager). The control flow directed by the user continues in a standard fashion until the Activate transition is issued from the Ready state. After Activate, the crate processors begin their stand-alone calibration procedure. Events and D-banks are not sent to the event builder, but rather the data are processed locally and a C-bank (calibration summary bank ending in the letter C) is sent when the frontEnd crate processor has completed the calibration. The C-bank is sent to the event builder, and later on to the calibration consumers via the Consumer/Server-Logger (CSL). The calibration consumers enter the results into the calibration database.

The Calibrating state is a fall-through state &minus while the frontEnd crate processors are calibrating, they are in the Calibrating state. When they complete, the frontEnd crates notify RunContol that they are in the Done state without any intervention from the user. When all frontEnd crates are Done, then the calibration is complete. Other RunControl clients are not required to respond with the Done state notification, only the frontEnd crates. Do not be alarmed if the SoftEvb remains yellows in the ReplyAck window, you are still free to press the End transition button to finish the run.

If the calibration was successful, you have the option of downloading the calibration constants into the flash RAMs of the cards in question. To do this, press the Calib_Load transition button. This transition is for expert use only, as it requires vetting the calibration results. If Calib_Load is selected, the frontEnd crates will begin the lengthy flash-RAM download procedure; be patient, as it takes around fifteen minutes to complete. In the meantime, you may see warnings from monitoring programs (e.g. vxmon or VxMonitor) that the crate is unresponsive &minus this is normal, as the crate is very busy. The response errors will clear after the download is complete.

The Generic Calib StateManager is used for most calibration runs beside the QIE type. In most cases, the calibrations require a TriggerSupervisor and a hardware partitiob. Thus the Generic Calib Statemanager has the Halt - Recover - Run sequence present as a user option.

The Partition - Setup - Activate sequence proceeds as normal, each transition issued by the user at the appropriate time, in order. As with the QIE StateManager, the Calibrating state is a fall-through type. The frontEnd crates will notify RunControl with a Done state notification. The non-frontEnd crates are not requiring to issue the Done notification.

When all frontEnd crates have responded with the Done notification, the user should press the End transition button to complete the run. Some mid-run problems can be resolved with a Halt - Recover - Run sequence, but this is not guaranteed in all instances.

Some calibration procedures send the D-banks (events) to the event builder; others produce a C-bank (calibration summary bank) and send it to the event builder only once at the end of the run.