|
|
Scaler - bridge scaler buffers to TclServer |
|
Scaler is a program which makes it possible for Scaler readout status to be displayed on a Tcl Server.
Background
The scaler client for tclserver accepts run
state and scaler buffers from the data acquisition system and interacts with a
tclserver to provide information which describes the run state, as well as
incremental and run totals for scalers. The block diagram below shows how the
scaler client fits into the data acquisition system.
The scaler client takes scaler and state
change buffers from the spectrodaq routing server. It:
o Analyzes these buffers. It updates a specific
tclserver’s variable set to reflect new counts
o Updates a specific tclservers’s variable set to
reflect changes in the state of the run.
o Requests that the tclserver execute specific
procedures in response to buffers including:
- Updates in scaler
values.
- Changes in run
state.
The following command line invokes the scaler
client:
sclclient [-hhostname] [-pportnum] [-ssourceurl]
The switches have the following meanings,
values and defaults:
|
Switch |
Meaning |
Value |
Default |
|
-h |
Set the host on which tclserver runs. |
Either a hostname (e.g. thing.nscl.msu.edu) or an ip address (e.g. 35.8.32.33) |
Localhost |
|
-p |
Sets the server port to which sclclient attempts to connect |
A service name in the service file or a service port number (e.g. statusserver). |
statusserver if defined in /etc/services else 2700 |
|
-s |
Sets the URL of the data source spectrodaq server |
e.g. TCP://spdaq01:2602/ |
TCP://localhost:2602/ |
sclclient switches may be either spaced or unspaced from their parameters, e.g.:
sclclient -s TCP://spdaq02:2602/
Is the same as:
sclclient -sTCP://spdaq02:2602/
Sclclient does not require any interaction with a terminal and can be run as a background process.
The sclserver runs a two level state machine as shown below.
The outer states indicate whether or not the scaler program is connected with a
Tcl client. The inner states indicate the state of the data acquisition system
and are only maintained when the client is connected.
Design Question: Assumption is that in almost all cases the scaler program is
connected. Should we relax this assumption and instead maintain the run state
independently of the connection state?
Outer level state transitions are all triggered by
events on the Tcp/Ip connection between the program and the TclServer. Inner
level state transitions are triggered by receipt of buffer types in the event
stream.
Execution starts in the disconnected state. In that
state Scaler periodically attempts to connect with a tclserver. When the
connection is honored, it enters the connection state, and unknown run state
and attaches to the data acquisition system, accepting buffers. Commands are
sent to the tclserver setting up server variables as shown in the table below:
|
Variable |
Type |
Initialization |
|
Scaler_Totals |
Array indexed from zero |
0 |
|
Scaler_Increments |
Array indexed from zero |
0 |
|
ScalerDeltaTime |
Scalar |
0 |
|
ElapsedRunTime |
Scalar |
0 |
|
RunNumber |
Scalar |
">Unknown<" |
|
RunState |
Scalar |
">Unknown<" |
|
RunTitle |
Scalar |
">Unknown<" |
When the connection is lost, it disconnects from the
data acquisition system and re-enters the disconnected state.
Figure 1 State transition diagram for Scaler
Once in the connected state, data buffers from the daq
system trigger transitions within the substate diagram shown.
Note:
In version 2, the state diagrams will be decoupled so that
the run state is independent of the connection state.
The following Tcl commands (procedures written by the
server provider) are also invoked:
|
Command |
When invoked |
|
Update |
Display should be updated. |
|
BeginRun |
A new run has begun. |
|
EndRun |
A run has ended |
|
PauseRun |
Active run has been paused |
|
ResumeRun |
A paused run has been resumed. |
|
RunInProgress |
An active run was detected by a non transition buffer while in the Unknown run state. |