SLC Functional Description
Document Format
The purpose of this document is to specify the functionality
of the existing SLC/PEP-II control software subsystem and applications.
Not to be included here are any design related or implementation discussions.
Also, in order to distinguish SLC features from NLC requirements, any discussion
of anticipated NLC software should be limited to the last section of the
document.
-
SCP User Interface
This document is a functional description of the
existing SCP User Interface (SCPUI) for the SLC Control System (SLCCS).
-
Purpose
A. What is the application
for and why is it necessary?
To provide all users of the Control System with a
consistent interface for interacting with all of it's diverse functions.
B. Who uses it?
Almost everybody. The main users are Operators
who control almost all aspects of the accelerator. Machine Physicists use
it to take and analyze data to understand various aspects of the machine.
Programmers use it to test their S/W and also to take machine data relevant
to the functions that they are implementing or debugging.
Button Macros, which automatically run
a sequence of operations by emulating button pushes and data entry are
the main S/W user of the SCP touch panels. They are a key component and
one of the most used aspects of the entire SCP user interface.
-
Operating Environment
All that is required to run a SCP is an
X-Windows capable computer and an account on the MCC VMS machine.
In principle a SCP could be run from anywhere in the world. However, because
there is presently no built-in security, it is only allowed to run inside
of the SLAC domain.
-
Functional Requirements
Figures 1-4 show the four SCP windows
which are part of the user interface. Figure 1 is the Touch Panel window,
through which the user controls all of the SCP functions. The types
of functions asociated with buttons are ennumerated below.
Figure 1 SCP Touch Window
Figure 2 is the graphics window which is used to display
graphics or text output depending on the function selected via the buttons.
Figure 2 SCP Graphics Window
Figure 3 is the error message window which displays
global or local function messages.
Figure 3 SCP Error Message Window
Figure 4 is the knobs window which gives any user the
capabiliy to "knob" one or more devices.
Figure 4 Knobs Window
The following is a detailed list of functional requirements
for the SCP interface:
-
The SCPUI allows for unlimited menus of functions.
Any button in a matrix can call up another panel. There are presently 3348
panels in the panel reference directory.
-
Panel descriptions are simple ASCII files
with fixed fields that can be edited with any text editor. There is no
specialized panel editor that understands the syntax of a panel file.
-
Code to be invoked when the button is pressed
is dynamically determined at runtime.
-
Action on one button can alter the state of
other buttons on a panel.
-
Some buttons on a panel can be dynamically
defined at run time.
-
An ancillary window for graphical or list
output is always available.
-
Global and local error messages sent in response
to user actions are always available in another window.
-
Hardware knobs are associated with the primary
control panels in the Main Control Room.
-
A software knobs window is available for use
anywhere the is a SCPUI.
-
A Button Macro facility is available for the
recording and playback of a sequence of button pushes and data entry. A
program file is produced which can be edited to alter the function of the
macro.
-
A library of these macros is maintained and
available for display and selection for execution.
-
Maintain a separate environment for the development
and debugging of new panels and their code.
-
The are a set of Continuously Updating Displays
(CUDs) which provide an overview of the current accelerator status.
-
Performance Requirements
-
Speed. Any human interface must quickly provide an initial
response. Normal human tolerance is about 2 seconds. For Control Room operators
this reduces to about 0.5 seconds. Changing panels with the current SCP
interface has a normal response time of well under 1 second.
-
Functions provide some feedback that they are active.
-
Resource Dependencies
Rapid panel response depends on several resources:
-
Ethernet Network communication speed is the
main determinant. I notice a big difference at 28.8K!
-
Many functions are limited by SLCnet bandwidth
or can saturate the network resulting in total system performance impacts.
-
Local computer memory is fairly important.
You want sufficient memory for buffers again to minimize network traffic.
-
Local CPU speed is less important but you
probably don't want an 8086!
-
Performance on certain heavily loaded Feedback
micros is sometimes a problem with user response times.
-
Hindsight & Foresight [optional]
Despite its apparent primitiveness from
the contemporary viewpoint, this interface which combined a rapidly navigable
set of panels with separate graphical and error message windows has proved
surprisingly effective and durable. We certainly need to reproduce some
parts of it for the NLC User Interface (NLCUI).
To make up for its graphical shortfalls
and the lack of a monitor capability, the SLCCS uses CUD displays which
poll and process related sets of data. The monitor capability combined
with the power of the EPICS database essentially turns the CUDs into simple
DM displays.
For the NLC we need to capture the local
and global error message capability present with the SCPUI.
Since we'll have a large number of displays,
we also need a quick search facility so that one can quickly find the display(s)
needed to perform the desired function. Traversing a tree of panels to
find the button you're looking for can be painful. It will be more painful
if each panel is a complex display that takes longer to paint than a panel
though hopefully not much longer.
The button macro equivalent functionality
is absolutely essential and must be built into the NLCUI.
So here's a starter list of NLCUI requirements
that are an outgrowth of the SLCUI.
-
Present global and local error messages in
a standard way.
-
Implement the equivalent to the button macro
facility.
-
Each production display should have an entry
in a searchable database so that it's functions can be easily found by
keyword.
-
Implement the bookmark facility common to
Web browsers.
-
Provide a separate graphical window for certain
plotting functions?