The Partition transition notifies all front end crates and other RunControl clients that they are included now in this particular partitions. The trigger and return crosspoints are configured according to the partition's crates, and L3 configures the selected subfarms. If you add or remove any crates or clients from your RunConfiguration, you must go through the Partition transition to have the changes take effect.

To return to the Start state, where RunControl clients may be added or removed from the partition, use the Reset transition. The Reset transition is always available, in case there is an unresolved issue with one of the RunControl clients. Unless you are in the Idle state, use the Reset transition only in such emergencies.

The bulk of system configuration occurs during the Config transition. Front end readout and trigger hardware are downloaded and initialized during this transition. L3 completes its initialization according to the specified TriggerTable and calibration constants. The Config transition initiates a new run with a brand new and unique runNumber.

Any configuration changes require the user to restart a run and proceed through the Config transition. For example, changing the TriggerTable means a new run must be started. However, if no clients or crates are added or removed from the partition's configuration, it is not necessary to go all the way back to the Start state.

The Config transition takes the longest of all the transitions − up to five minutes if L3 is using a new TriggerTable.

The Activate transition is the final step before data taking is finally initiated. The TriggerSupervsior enables its L1, L2, and readout state machines on Activate, thus enabling trigger and data flow. Other clients do minimal or no processing on Activate. Activate is a fast transition that should take no more than a few seconds.

During the Activate transition, the user will be presented with a RunComment pop-up window, as shown below. Any pertinent beginning of run informations should be noted. The user does not have to enter the comments immediately, but can save the window for later use. RunComments will show up in the runSummary pages as well as the shiftcrew e-log.

The Pause transition provides a gentle way of temporarily stopping triggers and readout. When paused, the TriggerSupervisor turns all L1 Accept signals into L1 Rejects. The system is allowed to quietly drain, with no loss of triggers or events.

The Pause transition is useful during most trigger inhibits to allow the high voltage system to recover while the data acquisition is quiescent. The exception is Silicon detector related inhibits; the silicon experts prefer to be in the Halted state while their system is being recovered.

The Resume transition reenables the acceptance of L1 Accept triggers and thus resumes data acquisition after a Pause.

The Halt transition causes the TriggerSupervisor to abruptly halt the L1, L2 and readout state machines. Some pipelined triggers and buffered events are usually lost during a Halt. The Halt transition is the first step in a Halt-Recover-Run sequence, which is the user's first line of defense to repair data acquisition faults. The sequence exists to provide a quick system-wide reset in lieu of restarting the run and doing a relatively time-consumer full reconfiguration via the Config transition.

During the Recover transition, all systems issue a fast reset of their associated hardware in hopes of establishing subsequent normal data acquisition flow. A full redownload/configure is not done in order to save time.

After the Recover transition is successful, the system should be ready to resume data acquisition. On Recover, the TriggerSupervisor reenable its state machines, essentially identical to the Activate transition. If the Halt-Recover-Run sequence fails to clear the system fault, another sequence may be necessary. If HRR fails two or three times to recover the system, a crate shepherd or a run restart may be necessary.

The HRR Halt-Recover-Run composite transition is a short cut for the user when the sequence of three transition is needed in quick succession.

When the RunControl session has collected the desired amount of data, or the run configuration needs to be changed, then the user issues the End transition to terminate the active run. End is available from the Active, Paused, Halted and Recovered states. The End transition gently stops the flow of triggers and events, and turns off the TriggerSupervisor state machines. Front end crates and other clients collect and generate end of run summaries at this time.

The End transition is always preferrable to the Abort transition, as careful transition sequencing is done during End to bring data acquisition to a sensible close.

Note that the End transition will be automatically issued if the NEvents RunSetting parameter is set to a non-zero value.

The user will be prompted for RunComments in a pop-up box presented during the End transition, as shown below. After colliding beam runs, the additional check boxes for RunStatus at the bottom of the window will appear; the user must choose either Potentially Useful, send to offline farms or Definitely Bad, do not send to farms. When in doubt, choose Potentially Useful, otherwise the data may be lost. Additional comments may be added via the Parameters pull-down menu Add Comment to e-Log and Run Database option.

The Abort transition is similar to the End transition, except that it is always available when at or past the Idle state. The Abort transition will terminate the current run, but does not perform many of the end of run summary activities; Abort also does not gently bring the run to a close through transition sequence. The user should only use Abort if no other option is available.

The Calib_Load transition is available only on the QIECalibStateManager, and instructs the frontEnd crates to load the previously computed QIE calibration constants into the ADMEM hardware. This process takes about fifteen to twenty minutes; during this time frontEnd crates are unresponsive and may turn red in the VxMonitor display.

Calib_Load requires other special settings in order to be useable, and should only be done under the direction of the appropriate component experts.

The tag at the bottom left corner of the StateManager display panel indicates which StateManager has been chosen. Select the StateManager via the Enable pull-down menu of RunControl.