SLC Functional Description Template

SLC Functional Description of Multiknobs

The purpose of this document is to specify the functionality of the existing SLC/PEP-II control software multiknob subsystem and applications.

Multiknobs

Purpose

A. What is the application for and why is it necessary?

The Multiknob subsystem allows devices to be grouped together and modified as synchronously as possible. The two applications which use this grouping capability are assignment to a knob and accessing from Correlation Plots. Multiknobs provides the mechanism for the best approximation to moving devices in a coordinated manner.

B. Who uses it?

Directly or indirectly:

People: Operators and Machine physicists.
Other applications: Correlation plots, PEP-II closed-bump generation.

Operating Environment

A. Where does it run? Is this an on-line or off-line application?

Multiknobs is an online application which runs in the Alpha. The devices listed in individual Multiknob files are controlled by driver code in the micros, with the Multiknob system providing the coordinated behaviour.

B. What services or other applications does it depend on?

The Multiknob files exist as text files on the host Alpha file system. Many multiknob file names are hard-coded in SCP panels. Some applications (PEP-II bumps, for example) generate multiknob files with momentarily valid, highly accurate coefficients. The interrupt driven software which interfaces to the knob hardware is an integral part of Multiknobs. The multiknob file parsing is achieved with a CLI interface (VMS DCL syntax). The control of individual devices is achieved by calling the appropriate low-level routines to effect control from the Micros.

Functional Requirements

Two types of specifications must be provided, examples of which are provided below. The first set defines the characteristics of the knob and the second set describes the individual devices.

A) Overall behaviour:

/RAMP - supply the knob ramp delta and timeout between maximum steps
/LABEL - supply the text for labelling the associated knob
/LIMITS - supply knob limits (which override those calculated from individual devices)
/START - supply a starting value
/ABS - use the knob in absolute mode (default is RELATIVE)
/TRIM - trim devices instead of perturbing where applicable
/TIMEOUT - time after which the knob is no longer valid (short-lived bump knobs, for example)
as well as defaults for any of the below-mentioned device specific items.

B) Per-device specifications:

/DEV - identify a device
/COEF - supply the linear coefficient
/POLY - supply polynomial coefficients

Performance Requirements

The Multiknob software should provide as much synchronicity as possible. The underlying support must provide a method of first setting up an action, then implementing it upon a second command.

Resource Dependencies

DATA
When devices are updated, corroborating data must be returned quickly enough that any subsequent actions are based upon good data and good status.

CPU

This application is NOT cpu intensive.

Access to Accelerator Hardware
This application uses indirect access to hardware, and requires data and status readback. It should support a 2 to 5 Hz update rate.

Access to Processed Data
This system can drive psuedo devices such as feedback setpoints.

Hindsight & Foresight [optional]

One of the most interesting problems for Multiknobs is device contention. This has been addressed in an ad hoc fashion in the current software. For contending knobs, a warning is issued that something has been changed. For contention with Feedback, the Multiknob refuses to update any devices on the Multiknob until the feedback gives up control of any device in the Multiknob file it is controlling. One concept to investigate is a device priority reservation system, which would allow a high priority client to force a lower priority client to give up a reserved device in an orderly fashion.

There is also a diagnostic knob facility, which allows an individual device to be assigned to a knob and moved. The support code for the diagnostic knobbing and multiknobbing is NOT the same. Maintenance would be much easier if both diagnostic device- and multidevice-knobbing used the same processing routines.