V4 Use Cases

Overview

These are example use cases where we need to assert that each layer of EPICS V4 handles them:

1. Can the CA client user API articulate the request?

2. Can the network protocol transfer the request?

3. Do the database & drivers understand the request and provide the necessary data?

4. Does the data get back up to the client in the appropriate form and at the requested time?

Use Cases

Command-line tools for debugging and scripting

1. List all channels that match a given name pattern.

2. Dump the current "value" property of the channel "fred".

3. Dump all properties, their type, and current value for a given channel.

4. Dump the timestamp, value, units, status, severity of "fred" once a second.

5. ... whenever any of the timestamp, ... severity change.

6. List all events that a PV supports: On change, 1Hz, RF Pulse, Beam Pulse, ...

7. Dump the value of the cavity waveform for every beam pulse.

Display Manager

1. Display an analog input value on a bar:
Get limits, subscribe to values, receive value & display it, receive change-of-display-range notification,...

2. Display a menu output for a 2 state valve on a text update:
Get state strings, subscribe to (numeric?) value, display incoming data, receive state string updates, ...

3. Give a controller for a 2 state valve controller on a radio button.
Handle same as 2?

4. Display a waveform on an xy plot.
Similar to 1, but array data?

5. Attempt to display a string on a bar

6. Universal PV Inspector:
Get properties, allow user to select properties.
If writeable string -> display text entry field.
If read-only string -> display text update field.
If writeable numeric with limits -> display slider with range of number.
....

7. Display as bars, a list of BPMs where I can set the offset in time to fetch (assuming that these BPMs are read as arrays that are all triggered at one time – but I want to see them at different points in time as it goes down the beamline).

Physics Application

BPM-related ideas

1. List all channels available that are BPMs.

2. Select all of them in sector 6

3. Get the values of all BPMs in a sector, once, as a snapshot. This means all the BPMs must be read at the same time, for the same beam pulse, or whatever a specific site considers "at once". A variant would be: Display them when the beam is going to the end station A (one of 8 destinations possible)

4. Same, but display them periodically, for example on the .1 Hz event

5. Find the corrector magnet PVs that belong to a list of BPMs. Read the BPMs and current maget settings "at once", compute new settings, write the new settings "at once".

  Scan a probe in the beam line 1. Find PVs for some beam line device:
Stepper motors for probe's X & Y position, intensity of beam transmitted by probe, beam shutter open/close, beam available 2. Scan sequence:
Assert shutter is closed; move X/Y to 0/0, wait for completion until done: open shutter, wait until open measure intensity for 1 second while beam_available close shutter move to next position, wait until you get there

Archiver

1. Get value, timestamp, status/severity of a channel once per second

2. Archive default properties of a channel using the default deadband.
How are they defined? How does the archiver learn about them?

3. Given that there is a new view defined in the stepper motor that includes all motor readback data:Subscribe to counterClockWiseLimit, clockWiseLimit, moving, doneRetries, homeLimit at 10 Hz.

Infrastructure for various applications

1. Serialize and de-serialize the data type description in human-readable form.

1.1 Used to get common syntax for user-input to command line tools or for the archiver config file, where users need to describe what to get/put/archive and how:

'value' as double, 'units' as string, ...

1.2 Used to get common output from tools that 'dump' the data type for info or debug purposes.

2. Serialize and de-... in rather compact form

2.1 Used by data storage tools to store the type information in the header of data blocks.

2.2 Maybe also used by the network layer to initially xfer the data types.

Could those formats be the same, i.e. a short yet human readable format?

  "{d:value,s:units,{d:low,d:high}limits}"

could describe this structure:

  {
    double value;
    string units;
    struct
    {
      double low;
      double high;
    }      limits;
  }

3. Need to provide standard serialization of the data type description _and_ the data? Or should the developers of the network layer and archiver each invent their own?