# Presentation: 183529

## EPICS Channel Access Enhancements for LANSCE Timed and Flavored Data

- J. Hill

## Overview

- Introduction
- LANSCE Requirements
- Bounded Feature Set
- EPICS Event Queue
- Event Queue Upgrade
- Milestones

## LANSCE Requirements

- LANSCE timing and flavoring of data
- Flavoring
- Logical configuration of beam gates
- Timing
- Time offset of a sample within a beam pulse
- Many permutations
- Too many to, a priori, install EPICS records for all of them
- Channel Access client must somehow specify timing and flavoring when it subscribes

## Bounded Feature Set –Near Term Release

- Many features proposed for EPICS version 4
- Release schedule is uncertain
- LANSCE timeline requirements and EPICS version 4 timeline may not coincide
- The proposal is to add to EPICS strictly what LANSCE needs and thereby obtain a more predictable release schedule
- Nevertheless, an incremental step along the path to version 4 is desirable

## EPICS Fundamentals

- Channels and Process Variables
- A channel is a virtual communication link to a process variable
- We can perform read, write, and subscribe operations over a channel
- Publish and Subscribe
- Clients subscribe for updates
- Servers publish updates to multiple clients
- Records post state change events to servers

## EPICS Event Queue – A Pivotal Component

- Tying high priority deterministically scheduled activities to the low priority load non-deterministic server component
- The event queue guarntees that this value/alarm status/time stamp tuple are consistent
- It is *essential* that we minimize what impact client induced load has on record processing threads

## EPICS Event Queue – Theory of Operation

- Records execute at relatively high priority, server executes at relatively low priority
- Record processing *never* blocks for slow clients
- Record is producer and client is consumer
- Sever production rate might exceed consumption rate of client or network – queuing system needs to serve dual purposes
- Burst
- Attempts to avoid discarding updates
- Sustained
- Keep subscriptions current
- Intentionally discard intermediate updates
- Do not introduce time delays

## Current Event Queue is Quite Inflexible

- The *only *parameters that can be correlated together in time with any surety over Channel Access are
- Scalar Value, Time Stamp, Alarm Status
- The exception is of course after the fact correlation using the time stamp
- This is very inflexible
- It does not allow clients to specify their data capture constraints
- Array value change events are not recorded on the event queue
- It doesn’t allow for on the fly application driven experiments needed at LANSCE

## Event Queue Upgrade

- CA Server

- Record

- Event Queue

**Legacy Fixed Event Parameter Set**
**Scalar Value**
**Time Stamp**
**Alarm Status**

**Upgraded Record Specific  Event Parameter Set**
**Scalar or *****Vector***** Value**
**Time Stamp**
**Alarm Status**
**...**

**Upgraded Device Specific Event Parameter Set**
**LANSCE Beam Gate Specification**

## Event Queue Memory Management

- Smart Pointers to Data Access Interfaced Objects
- Reference counted
- Increments when smart pointer is copied
- Decrements when smart pointer is destroyed
- Release callback when count decrements to zero
- Memory Management
- Handled by event posting agent
- Can be free list based

## Event Filter Upgrade

- Record

- Event Queue

- Event Filter

- Discard

**Event Filter Expression**
**value < 10.0 and**
**value > log ( currentMonitor0007.current )  and**
**requireFlavor ( beamGateA | beamGateB ) and**
**excludeFlavor ( beamGateC )**

## Event Filter Implementation

- Could be based on the same library that the calc record uses
- Would prefer however to base expressions on property names instead of {A, B, C, ..} as is currently the case with the CALC library
- Another possibility is Majito
- Majito is open source and has JIT compiler

## Event Filter Configuration Upgrade

- Client Library

- Server Library

- Event Filter

**Moderate** **Interface Upgrade**

**Moderate Subscription Protocol Upgrade**

## Data Access Interfaces for DBR Types

| CA Type Code |
| --- |
| DBR_CHAR |
| DBR_SHORT |
| DBR_ENUM |
| DBR_LONG |
| DBR_FLOAT |
| DBR_DOUBLE |
| DBR_STRING |
| DBR_STS_<PRIMITIVE TYPE> |
| DBR_TIME_<PRIMITIVE TYPE> |
| DBR_GR_<PRIMITIVE TYPE> |
| DBR_CTRL_<PRIMITIVE TYPE> |
| DBR_PUT_ACKT |
| DBR_PUT_ACKS |
| DBR_STSACK_STRING |
| DBR_CLASS_NAME |

**Data Access Interfacing Adapter**

## Server Implementation Consolidation

**rsrv**

**database**

**dbAccess snap-in**

## LANSCE Capable Waveform Record

- LANSCE Capable Record

- Upgraded Event Queue

- Ordinary Record

- Upgraded Event Queue

- LANSCE Specific Device Support

- Ordinary Device Support

**Legacy db_post_events interface**

**Data Access based event posting interface**

**Legacy device support interface**

**Data Access based device**
**Support interface**

**Data Access based event posting interface**

## Milestones

- Internal Design
- Review

- Interface
- Description

- Retrofit Portable
- Server to
- New Interface

- LANSCE Specific
- Waveform Record

- Service Snap in
- for dbAccess

- Subscription
- Update Filter

- Data Access to
- DBR_XXX

- Data Access
- Close Out

- Retrofit Event
- Queue to New
- Interface

**Milestones**