LCLS Controls

SLC Aware IOC

Beam Synchronous Acquisition and Control (BSAC) Facility Software Requirements

---   DRAFT --- work in progress

­­­­­­­­­­Diane Fairley and Debbie Rogind

May 26, 2005;  Revised June 1, 2005

____________________________________________________________

 

Quick Links

Summary

Background

Use Cases for Beam Synchronous Data

          System Block Diagram

BSAC Facility Functionality

          BSAC Facility Data Flow Diagrams (PPYY)

          BSAC Facility Timing Diagrams

SLC-aware BPM Facility Interfaces

          Database Service

          Message Service

          Runtime DB Access to EPICS BSAC Facility

EPICS BSAC Facility Interfaces

          EVR

          BPM digitizer module

          GADC modules and DUGADCs (WIRE, ARRY)

          TORO Control Module

Glossary

1         Background

The SLC control system at SLAC is currently used on most of the LINAC. It is the only control system in sectors 20-30, which will be used by the LCLS mostly in tact. LCLS will replace all of the BPM electronics in these sectors to provide higher resolution. The Injector for LCLS will use all new control, except for the high power RF components, which are existing SLC klystrons and modulators. The corrector magnets in the LINAC that will be used for LCLS will all have new EPICS based controllers. From the undulator to the experimental stations, all new controls will be done in EPICS. Note that all SLC data from the existing LINAC will be available to the EPICS environment, but the time stamp information that allows data correlation to beam events is not available at the present.

 

The motivation to implement an SLC aware, EPICS IOC, is to allow the new elements of the LCLS control system to use EPICS, while still taking advantage of the high level applications on the SLC control systems. These high level applications include:

Correlation plots, energy management, beam steering, beam based alignment, emittance measurements, and slow feedback.

 

1.1       Assumptions

·        The SLC-aware IOCs are to support LCLS beams in the linac. There will be no interleaving of straight-ahead beams from the CID injector with LCLS operation. Straight ahead beams will only be run in a dedicated machine mode when LCLS is not operating. In the event that straight ahead beams are sent down the linac the BPMs in sectors 20 through 30 will be required to measure beam position using the LCLS processors operating on a beam code for the straight ahead beam. The straight ahead beam operation will not require simultaneous reading of both electrons and positrons on a single machine pulse, which used to be the case in the old SLC operation.

·        There will be no straight-ahead beam experiments supported by the SLC-aware IOCs or LCLS.

o       A bi-pass line will be built for LINAC supported End-Station experiments, or

o        existing electronics will remain and be swapped in/out.

·        SLC-aware IOCs will be present in the injector and linac portions of the LCLS beam line.

o       This allows gated data acquisition and correlation from all parts of the LCLS beam line

o        The LTU and Undulator may not require SLC-aware IOCs, as EPICS control may be complete by the time of LTU commissioning.

·        There will be only one public calibration setup at one time

o       When the experiment changes, a new calibration will be issued or previously stored calibration tables will be loaded.

o       Calibration will not be coordinated by SLC / SCP

2         Use Cases for Beam Synchronous Data

Requirements for the Beam Synchronous Acquisition Facility are derived from existing SLC applications and from expected future applications that will be made available as EPICS clients.  Each of these applications requires certain functionality of the BSAC Facility. 

 

The main interface between the SLC applications and the BSAC Facility is the Message Service interface.  All requests from the SLC applications are embodied in Message Service request messages, denoted by a function code. The BSAC Facility processes the request and data is returned in a data reply message.

 

All requests from EPICS clients are issued through the Channel Access interface, and data is returned through this same CA Interface.

 

The application requests are described in this document as Use Cases.  We have divided the Use Cases into two groups, those from the SLC Control System, and those from current and future EPICS Clients.

2.1       System Block Diagram

2.2       SLC Use Cases

All of the gated acquisition based applications available from the SLC Control System have options to acquire data at 120 Hz, or lower rate due to rate-limiting, or due to wire scan range, CPU, user preferences, etc.  The PNET broadcast is used to specify a pattern of pulses to exclude/include.

 

SLC Use Cases originate from the following applications on the VMS system:

·        SCP High Level Software Applications

·        Standalone Applications

·        SCP Diagnostics Panels

·        SLC Database Hardware Status and Configuration is stored in the SLC Database

 

2.2.1      SLC functionality to be used by LCLS

The following table references LCLS application software requirements found in:

Requirements for High-Level Software Applications Packages

by Patrick Krejcik

The first column of the table illustrates which of the required LCLS Software Applications Packages require beam synchronous data. The second column indicates whether the SLC Control system satisfies the LCLS requirement. The third column indicates that all LCLS required SCP applications will be replaced by EDM / EPICS.

 

Name of LCLS Req’ed App

Requires BSA

SCP/SLC

EDM/EPICS

 

 

 

 

Diagnostic

 

 

 

Beam Orbit Display

Yes

Yes

future

Wire Scanner

Yes

Yes

future

Profile Monitor

Yes

No

Yes – High Priority

BPM Timing

Yes

No

Yes – High Priority

 

 

 

 

Tuning-Generic

 

 

 

Multi-knob Facility

Yes

Yes

future

Correlation Plot

Yes

Yes

future

Buffered Acquisition

Yes

Yes

future

 

 

 

 

Tuning-Specialist

 

 

 

Transverse Emittance

Yes

Yes

future

Beta Matching

Yes

Yes

future

Bunch Length Meas.

Yes

No

Yes – High Priority

 

 

 

 

Beam Line On-line Modeling

 

 

 

Orbit fitting

Yes

Yes

future

 

 

 

 

Power Steering

Yes

Yes

future

 

 

 

 

Linac Energy Management - LEM

Yes

Yes

Yes-High Priority

 

 

 

 

Fast Feedback

Yes

No

Yes – High Priority

 

 

 

 

Related Software

 

 

 

Configuration Control

 

Yes

Yes

Data Archiver

 

Yes

Yes

Error Logging

 

Yes

Yes

Orbit Check

 

No

Yes – High Priority

 

*future – will be developed in-house or enhanced for LCLS from existing packages.

*Yes – High Priority – is not available thru SCP, required soon for LCLS

2.2.1.1  SLC Software Application to Function Code

The following table addresses the SLC applications that will be used by LCLS.  The table shows a mapping of SLC application to Message Service function code.  These function codes in effect represent Use Cases that apply to the BSAC Facility.  The table shows that the SLC applications required by LCLS have two important Use Cases.  They are the Measurement Prep request and the Wire Prep request.

 

In its simplest form, the Measurement Prep requests beam synchronous data to be provided on one beam pulse across all BPMs.  The Wire Prep requests beam synchronous data to be provided on multiple beam pulses in one area along the Linac, such as when doing a wire scan.

 

There are a few additional Use Cases that support SCP functionality during a beam synchronous acquisition.

 

Name

SCP Panel

Function Codes

Devices

 

 

 

 

Diagnostic

 

 

 

Beam Orbit Display

LCLS BPM Measurement

BPMO_MEAS_PREP

BPMS, TORO

 

LCLS BPM Diagnostics

BPMO_MEAS_PROC

 

 

 

BPMO_GETREMDAT

 

 

 

 

 

Wire Scanner

 

BPMO_WIRE_PREP

BPMS, TORO, WIRE, ARRY

 

 

BPMO_WIRE_PROC

 

 

 

BPMO_GETREMDAT

 

 

 

 

 

Tuning-Generic

 

 

 

Multi-knob Facility

Beam Orbit Display

BPMO_MEAS_PREP

BPMS, TORO

 

 

BPMO_MEAS_PROC

 

 

 

BPMO_GETREMDAT

 

 

 

 

 

Correlation Plot

Correlation Plot

BPMO_MEAS_PREP

ALL

 

 

BPMO_MEAS_PROC

 

 

 

BPMO_GETREMDAT

 

 

 

 

 

Buffered Acquisition

Buffered Data Acquisition

BPMO_WIRE_PREP

ALL

 

 

BPMO_WIRE_PROC

 

 

 

BPMO_GETREMDAT

 

 

 

 

 

Tuning-Specialist

 

 

 

Transverse Emittance

From previously measured

BPMO_WIRE_PREP

 

 

Wire scans

BPMO_WIRE_PROC

 

 

 

BPMO_GETREMDAT

 

 

 

 

 

Beta Matching

 

BPMO_WIRE_PREP

 

 

 

BPMO_WIRE_PROC

 

 

 

BPMO_GETREMDAT

 

 

 

 

 

Beam Line On-line Modeling

 

 

 

Orbit fitting

Beam orbit display

BPMO_MEAS_PREP

BPMS, Model

 

 

BPMO_MEAS_PROC

 

 

 

BPMO_GETREMDAT

 

 

 

 

 

Power Steering

Based on previous orbit

BPMO_MEAS_PREP

 

 

measurements

BPMO_MEAS_PROC

 

 

LCLS Index panel

BPMO_GETREMDAT

 

Additional Support

 

 

 

Clear SCP meas-preps

When SCP terminates

BPMO_CLR_SCP

 

Stop measurement

Ctrl-C during Start/Stop meas

BPMO_MEAS_STOP

 

Display all User Requested Meas

Buffer Ring Dsply

BPMO_SHO_RBUFS

(also with EPICS CA)

 

Status and Configuration

BPM Diagnostics

HSTAs

 

 

BSAC Facility is required to utilize and respond to the above request and reply message function codes with a minimum of changes to the applications making the requests.

2.2.2      SLC LCLS BPM Diagnostics / Data Collection Control

A basic SLC LCLS BPM diagnostics user interface is required in order to test, debug, and integrate the BPM job in the SLC-aware IOC. It is also necessary in order to specify the collection of data which may feed some of the SLC SCP-based high level software applications. The basic diagnostics use all of the function codes required by the SCP High Level Applications.

2.2.2.1  SLC LCLS BPM Measurement and Diagnostics Screens

See the SCP LCLS Index created by Mike Z

Insert screen shots…

2.3       LCLS EPICS Clients Use Cases

Use Cases for EPICS Clients are TBD, but the following clients are required to support LCLS.  EPICS Clients are required to be able to acquire beam synchronous data, and to control many aspects of the beam synchronous acquisition process.

·        High Level Software Applications – starting this year

·        Calibration will be implemented in EPICS only

·        Fast Feedback will be implemented in EPICS only

·        Diagnostics will be provided to EPICS clients

·        Hardware Status will be shared between EPICS Clients and the SLC Control system

·        Other EPICS Clients will be supported

2.3.1      EPICS High Level Software Application Packages

Patrick has a prioritized list. Refer to tables in Section 2.21 above.

2.3.2      Calibration

User-initiated control of calibration for beam synchronous devices which require calibration will be accomplished by EPICS EDM displays, and not by the SLC/SCP. 

2.3.3      Fast Feedback

Fast feedback is supported with a special-purpose Fast Feedback hardware module in the LCLS IOCs. 

2.3.4      Diagnostics

Diagnostics is supported through EDM displays. 

2.3.5      Hardware Status

2.3.6      Other EPICS clients

Other EPICS clients are supported such as:

3         BSAC Facility Functionality

The Beam Synchronous Acquisition and Control Facility (BSAC) is a combination of SLC-aware threads and EPICS records and device support.  The SLC-aware threads are referred to as the BPM Facility for continuity with existing SLC Micro naming.

 

At a high level, the BSAC Facility is required to:

·        Accept SLC data requests for beam synchronous data acquisition for all devices listed in this document to support SLC applications

·        Return beam synchronous data to the SLC Control system in the expected reply structure.

·        Return beam synchronous data to LCLS EDM displays.

·        Share hardware status between the SLC Control system and the LCLS EPICS system

·        Share calibration status between the SLC Control system and the LCLS EPICS system

·        Support Fast Feedback functionality, control, and diagnostics

·        Support calibration of devices in the IOC

·        Provide diagnostics from the BSAC Facility – including BPM Timing

 

The division of labor between the SLC-aware BPM Facility and the EPICS BSAC is a design issue, but some goals for this design are recorded here.

·        The SLC-aware threads should act as a “pass-through” facility as much as possible, placing most of the work into EPICS database records and device support.

·        Maintain a clean division between SLC-aware-only functionality and functionality that supports the short and long-term EPICS interface. The SLC-aware only code will eventually be stripped out.

3.1       BSAC Facility Data Flow Diagrams

3.1.1      Non-scan (One-shot)

SLC micros have double nested loop – multiplexing within data averaging

In SLC-aware IOC this becomes single loop – data averaging

Data packaged and sent to SCP when full measurement done

3.1.2      Non-scan (Start / Stop)

Acquisition continues according to measurement definition until YY code no longer appears (user presses “Stop”.  Measurement definition is stored in micro until it is replaced or deleted.

PPYY PNETs are repeated until user presses “Stop”.

3.1.3      Scan (Wire, Buffered Acq.)

SLC micros implement triple nested loop multiplexing within data averaging within scan stepping. In SLC-aware IOC this becomes double loop – data averaging with scan stepping. Data packaged and sent to SCP when full measurement done. Any or all (LCLS-supported) devices can be requested.

3.2       BSAC Facility Timing

3.2.1      General

The LCLS beam rate is a maximum 120Hz.

3.2.2      120Hz Beam Rate, several fiducial cycles

3.2.3      Pipelining

3.3       SLC-aware BPM Facility Requirements

SLC-aware BPM Facility Threads:

·        Accept all function codes listed above

·        Validate message contents,

o       As is done in micro code currently

·        Data Acquisition Request Message (BPMO_MEAS_PREP, BPMO_WIRE_PREP)

o       If all user criteria are used, send immediate “negative” reply message back to requesting SCP

o       Calculate # pulses requested; perhaps validiate that maximum number of “user collection” records allowed in EPICS BSAC Facility is not violated

o       Validate devices requested against SLC DB

§         Check for offline devices, etc

§         Check for GADC/DUGADC mapping inconsistencies as is done in micro code currently

o       If validation succeeds,

§         Send immediate “valid” reply with data word count calculations

§         Store BPMO_MEAS_PREP and BPMO_WIRE_PREP user criteria into empty epics user criteria records (using runtime db access)

§         User Criteria contains, at a minimum:

·        YY, PP (beam code), inclusion mask, exclusion mask, navg, nrpos, active flag

 

·        When signaled from EPICS BSAC Facility that user request has been satisfied, initiate reading and assembling the data acquisition reply message.

 

§         Track (at a course level) when user requests should be complete. If not signaled by the time request should have been satisfied, terminate the request (as is done in current micro).

 

·        Data Acquisition Reply Message (BPMO_MEAS_PROC, BPMO_WIRE_PROC)

o       Read navg*nrpos number of acquired data elements from completed user collection buffer (or assemble from various PVs in EPICS BSAC Facility)

o       Assemble reply into appropriate data reply records, in VMS format

§         Adjust stat bits per device to reflect HSTA mode

§         Order  data according to current requirements of SLC micros for non-scan and scanned data

§         Prefix data with identification structures for scanned data

§         Convert IEEE floating point format to VMS float format

§         Convert EPICS time stamps to VMS format (timeEpicsToVMS()) for pulse id data

§         Use exact VMS packing format

§         VMS (little) endian format

§         Checksum, total word count calculations

 

·        Clear user criteria message (BPMO_STOP_MEAS)

o       Clear appropriate user criteria  and its active indicator

 

·        Clear all requests from a single SCP (BPMO_CLR_SCP)

o       Clear all user criteria and current measurements for a specified SCP

 

·        Ring buffer request message (BPMO_SHO_RBUF)

o       Show current set of user requests this slc-aware IOC is managing

 

·        Monitor EPICS DB to know:

o       the state of calibration

o       the shared state of hardware

 

·        Error Logging

 

·        Diagnostics

3.4       EPICS BSAC Facility Requirements

 

·        Accept and store user criteria from SLC measurement requests for up to X number of users

o       User criteria DOES NOT need to be restored after a re-boot

·        Determine, within 1/360 sec (360Hz), when EB pattern matches any active user criteria

·        Collect matching (time stamped) acquired data into per-user collection records from all gated devices involved in criteria within less than 1/120 sec (1/120 sec minus time (by BPM Module) it takes for data to be ready ).

·        Acquired data must be associated with time stamp and pulse id from matching EB pattern that triggered the acquistion. (EB pattern which triggers each acquisition occurs three timing ficucials prior to beam pulse)

·        Indicate to SLC-aware threads when data collection is complete for each user criteria (using navg * nrpos)

·        Indicate to SLC-aware threads error conditions during data collection for each user criteria.

·        Provide SLC-aware threads access to collected data via runtime database access.

·        Provide acquired data to EDM displays via Channel Access

·        Provide diagnostics data to EDM displays via Channel Access

·        Maintain hardware configuration and status sharable with SLC-aware threads, and available to EDM displays via Channel Access.

·        Maintain status of calibration sharable with SLC-aware threads, and available to EDM displays via Channel Access.

·        Support Fast Feedback functionality

·        Support data collection for future LCLS high-level applications.

 

4         SLC-aware BPM Facility Interfaces

4.1       Database Service

4.1.1      Devices (Primaries) supported / not supported by SLC-Aware IOC

Beam Synchronous Gated Acquisition devices used by LCLS must be configured in the SLC database in order for the acquired data to be accessed by the SLC Control System. The following table lists the gated data acquisition devices used by LCLS that will be supported in the SLC-Aware IOC (and thus by the SLC-Aware IOC Database Service and DBEX on the Alpha).

 

Data Acquisition Devices

Requiring Beam Trigger

Needed by LCLS; All are EPICS Controlled

SLC-Aware IOC Supported

Cavity/Stripline BPM (BPMS)

Yes

Yes

Toroid (TORO) Charge Monitor

Yes

Yes

DUGADC – WIRE Wire Scanner

Yes

Yes

     1) FLY

No

No

     2) STEP

Yes

Yes

     3) Magnet moves beam wires

No

No

DUGADC – WVFM

No

No

DUGADC – SLIT (Collimator)

Yes

No (No integrated BPMs;  use BPMs downstream)

DUGADC – GAPM

No

No

DUGADC – ARRY

Yes

Yes

CSR  Bunch Length Monitor

Yes

Yes (ARRY only)

Beam Loss Monitor

Yes

Yes (ARRY only)

Beam Profile Monitor

Yes

Yes (ARRY only)

Image Acquisition

Yes

Yes (ARRY only)

Faraday Cups

Yes

Yes (ARRY only)

LLRF

Yes

Yes (ARRY only)

E/O Diagnostic (Pulse length meas)

Yes

Yes (ARRY only)

Anything else?

 

 

 

In summary, the SLC-Aware IOC BPM Facility supports the following primaries:

 

The SLC-Aware IOC will not be supporting the following devices/functions:

 

Notes:

·        The SLC Control system must establish other primaries besides the ones used by the SLC-Aware IOC BPM job, such as DGRP, for LCLS.

·        An attempt should be made for any new LCLS device to fit into an existing SLC DB structure if its data is desired to be accessed by the SLC Control System.

·        Unit numbers of these devices must be similar in numbering to support “old-style” contiguous unit range in request message.

 

4.1.2      Secondaries supported / not-supprted by SLC-Aware IOC

4.1.3      HSTA

In general, HSTA is a 32 bit Supertype 2 (ST2) secondary that describes the kind of device (e.g. for BPMP: HSTA_BPMPEP, for BPMS: HSTA_XONLY, for GADC: HSTA_GADC12BT, etc) for a given unit. For LCLS, we will most likely define a new BPMP HSTA, HSTA_BPMPLCLS since this is a new bpm processor. We may have to define a new HSTA_BPMSCAV for the cavity-type BPMS.

4.1.3.1  STAT and stat

The SLC DB (BPMS) STAT secondary will not be supported by the SLC Aware IOC. STAT is a place holder in the SLC DB for the history process (BPM Sampler reads the BPMS and puts the data into the SLC DB).

 

Status (stat), or the 16-bit stat field, present in all measured data returned to the Alpha, is used mainly for display and diagnostics. The bits that will be supported in data sent to the SCP reflect the current state of HSTA for any device, and appear in the low order nibble.

Stat fields common to all devices occupy the lower 4 bits (nibble):

status

Hex Value

Description

STAT_GOOD

0x0001

Completely Happy

STAT_OK

0x0002

Substandard, but OK

STAT_DEAD

0x0004 (out of service)

Out of Service

STAT_SICK

0x0008

In Trouble

 

The current HSTA mode is reflected into the BPMS stat field by ORing together certain bits to indicate maintenance, checkout, and offline modes.

status

Hex Value

Description

STAT_MAINTENANCE

0x0014

Maintenance Mode

STAT_CHECKOUT

0x0024

Checkout Mode

STAT_DEAD

0x0004

Out of service – offline

 

4.1.3.2  BPMP Device Specific SLC DB Requirements

The current code in the micro uses the following BPMP secondaries (dbgets):

Secondary

Supertype

Description

HSTA

2

Hardware status

ADCL

1

ADC location.

CCUT

1

CAL cuts: STD,gain of ADC0 and ADC2, gain of ADC1.

TNRM

2

Factor necessary to normalize TMIT

CALP

1

Cal pulse generator unit; GADC unit # if PGAD type

CMXS

1

Pulsed cal mux step #

PEDT

2

Timing offset in ticks for meas.ing pedestals (RINQ BPMP)

MODT

3

Module Type (if available)

SERN

3

Serial Number(if available)

OFFX

3

X offset read from module

OFFY

3

Y offset read from module

PDUC

1

PDU channel for gate (mode, crate #, chan #)

Only the HSTA BPMP Secondary will be used by the BSAC Facility.

4.1.3.3  BPMS Device Specific SLC DB Requirements

The current code in the micro uses the following BPMS secondaries (dbget):

Secondary

Supertype

Description

HSTA

2

Hardware status

SPTR

1

Unit # of other BPMS using EPBPMP module

VDLY

1

Vernier delay ext trig for EP type

MUXS

1

Multiplexer setting

SNRM

2

Stn normalization factor for tmit

ASCL

2

Atten scale factor wrt nominal for beam; > 1 for more atten

OFFS

1

Mech offsets x and y, units mm

ANGL

1

Angle from horiz to BPMS x-direc

XTOL

1

Tols on X and Y pos, cut on ABS of X, Y

PPTR

1

Pointer to BPMP

PCMM

1

MM conversion gain (X,Y) (PGAD, pep2 type)

MUXT

2

Time of BPM trig rel to TREF + BPMT

ANGL and XTOL may be used by the BSAC Facility

4.1.3.3.1   BPMS HSTA

 

Here are  HSTA bits for a BPMS:

BPMS:HSTA

Hex Value

Description

HSTA_3RDORD

0x00000010

 

HSTA_ROT

0x00000020

Electrodes rotated (e.g., 45 deg., not upright).

HSTA_XONLY

0x00000040

X only

HSTA_YONLY

0x00000080

Y only

HSTA_RVRS

0x00000200

 

HSTA_EMINUSOVR

0x00000200

 

HSTA_XINV

0x00000400

 

HSTA_POLOVRRIDE

0x00000800

 

HSTA_BTADD7T

0x00001000

 

HSTA_BMSTRELE

0x00004000

 

HSTA_EP2ND

0x00008000

 

HSTA_EPMUXTFF

0x00010000

 

HSTA_P2MUXSZRO

0x00020000

 

 

 

HSTA also describes the mode of a BPMS device, according to:

*:HSTA

Hex Value

Description

HSTA_MAINTENANCE

0x00040000

Maintenance mode

HSTA_CHECKOUT

0x00080000

Checkout mode

HSTA_OFFLINE

0x00000004

Dead, or off-line

 

The BPMS’s “mode” HSTA is operator selectable on the BPM Diagnostics panel. The HSTA for these modes will be supported in the SLC-Aware IOC.

 

In the SLC Aware IOC, HSTA must be read every acquisition and iteration (when continuing a scan) thereafter for all devices involved in the measurement.

4.1.3.4  GADC SLC DB Requirements

The current code in the micro uses the following GADC secondaries (dbgets):

Secondary

Supertype

Description

HSTA

2

Hardware status

ADCL

1

Camac module location CTLW (include lowest subaddr )

NCHN

1

Number of channels (subaddresses) in module.

RDLA

1

Readout delay in 360ths of a second.

PDUC

1

Timing gate or gates:

BEAM

1

List of beam codes to be used if HSTA %GADCRDLA

FPED

2

Fixed pedestals (per channel; see DUGADC:HSTA).

Only the HSTA secondary will be used by the BSAC Facility

4.1.3.4.1   GADC HSTA

It is likely that the LCLS VME GADC boards will have their own HSTA_* bit defined.

The following are examples of the current GADC:HSTA values.

 

GADC:HSTA

Hex Value

Description

HSTA_GADCTDC   

0x00000010

Module is a TDC (not ADC), or collecting pedestals at cal time is suppressed

HSTA_GADCNGAT

0x00000020

Module should be read with no gate

HSTA_GADCF0

0x00000040

Module should be read with F0, not F2

HSTA_SEPGATE

0x00000080

Module has separate gates per channel

HSTA_GADCNPRD

0x00000100

Omit pre-read (assuming gated)

HSTA_GADCRDLA

0x00000200

GADC should be read RDLA pulses late

HSTA_GADC3623

0x00000400

Module is Kenetic Systems 3623 scaler

HSTA_GADC7167

0x00000800

Module is Phillips Scientific 7167

HSTA_GADC11BT

0x00001000

GADC has 11-bit ADC’s

HSTA_GADC12BT

0x00002000

GADC has 11-bit ADC’s

HSTA_GADCWVFM

0x00004000

Module is a LeCroy 2267 Waveform Digitizer

  

 

 

HSTA_GADCWVBB

0x02000000

If LeCroy2262, chans 2 & 3 biphased together

 

 

4.1.3.5  DUGADC SLC DB Requirements

The current code in the micro uses the following ARRY secondaries (dbgets):

Secondary

Supertype

Description

HSTA

2

Hardware status

ADCC

1

Beg of GADC subaddr for each subblock

ADCN

1

 # of ADC channels; some units have < max channels

ADCP

1

GADC unit # for each subblock of channels

NORM

1

Normalization coefficients.

POLY

1

Unit #s of POLY, or 0

The NORM and POLY secondaries may be used by the BSAC Facility

 

The current code in the micro uses the following WIRE: secondaries (dbgets):

Secondary

Supertype

Description

ENCC

1

Position encoder readout camac address (cctlw).

ENCM

1

Millimeters per encoder readout lsb.

STOL

2

max integrated signal per scan, for either wire.

SPTR

1

STEP unit number.

STEP:DACL

1

SMC DAC location CTLW

STEP:SPED

1

Speed and Acceleration time

 

4.1.3.5.1   DUGADC HSTA

The following are currently used for DUGADC:HSTA. DUGADC is a generic name for GAPM, SLIT, WVFM, WIRE, ARRY, etc.

 

DUGADC:HSTA

Hex Value

Description

HSTA_FIXED_PED               

0x00000010

Use fixed pedestals from db, not cal

HSTA_NORM_POLY

0x00000020

Use POLY’s, if any, for channels

HSTA_ABKMONLER

0x00040000

LER as opposed to HER

HSTA_ABKMONINJ

0x00080000

Measures time to beamabort since preceding bunch injection (ring-indep)

HSTA_AVGEXCL

0x00001000

Exclude from avging vals below FPED

 

 

 

WIRE only:

 

 

HSTA_WIRE_DUMPTHIS

0x00000040

Dump this beam during scan

HSTA_WIRE_DUMPOTHER 

0x00000080

Dump other beam during scan

HSTA_WIRE_SLDLOCK

0x00000100

Obtain SLD LOCK before scan

HSTA_WIRE_WAIT

0x00000200

Wait for return after scan

HSTA_WIRE_POS_READOUT

0x00000400

Use wire transducer for posn

HSTA_WIRE_SBD

0x00000800

Dump beam while wire moves

HSTA_WIRE_SWINDOW

0x00010000

Allow SLD_WINDOW to be caused

ARRY only:

 

 

HSTA_ENERGY_FOIL

0x00002000

Energy foil spectrometer

HSTA_ENERGY_X

0x00004000

Spread in X-Z plane

HSTA_ENERGY_Y

0x00008000

Spread in Y-Z plane

HSTA_ABKMONDAT

0x00020000

Points to GADCs monitoring HER/LER beam abort kickers

 

4.1.3.6  TORO SLC DB Requirements

 

Secondary

Supertype

Description

HSTA

2

Hardware status

CALT

2

Calibration timing offset (in PDU ticks).

SERN

3

Module serial number.

MODT

3

Module type.

STOL

1

Tolerance on Sum pulse height.

TNRM

2

Electronic gain from calibration.

ADCL

1

ADC location.

 

4.1.3.6.1   TORO HSTA

The following are examples of the current TORO:HSTA values.

 

TORO:HSTA

Hex Value

Description

HSTA_TORO16BIT              

0x00000010

16-bit data (as opposed to 10-bit data)

HSTA_TORONGAT

0x00000020

Ungated

HSTA_TOROCIRC

0x00000080

Maintain circular buffer of this unit’s recent data

HSTA_TORONPRD

0x00000100

Module has separate gates per channel

4.1.4      SLC DB Nomenclature

Any EPICS PVs in a particular SLC-Aware IOC must map to the expected PRIM:MICRO:UNIT:SECN names established by the SLC Database for that SLC-Aware IOC.

4.2       Message Service

All BPM function codes are in file [REF_C_INC]:bpmfunc.hc.

4.2.1      Function Codes implemented in SLC-aware threads

The function codes used by the SLC-aware IOC BPM job are highlighted below in the table containing all BPM function codes.

 

Function Code

 

Action

BPMO_CALB_PREP

Prepare for a calibration

BPMO_CALB_PROC

Calibration prepare reply

BPMO_CALTOR_PREP

Prepare for calibration of a toroid

BPMO_CALTOR_PROC

Toroid calibration prepare reply

BPMO_CAL_RESTORE

Download calibration tables

BPMO_CLR_SCP

Delete structures created for a SCP

BPMO_BPMPINIT

 

BPMO_PSUINIT

 

BPMO_PDU_REINIT

 

BPMO_MEAS_STOP

Delete a measurement preparation

BPMO_CAN_DEF

Delete a calibration

BPMO_NOGATE_PREP

Prepare for measurement of non-gated ADCs

BPMO_NOGATE_PROC

Non-gated ADC measurement reply

BPMO_ACCEPT_PUBLIC

Make a private calibration be public

BPMO_GETREMDAT

Send next piece of large message

BPMO_BUFRING_CRE

Create a ring buffer

BPMO_BUFRING_DEL

Delete a ring buffer

BPMO_FDBK_CONNECT

Connect to a  public feedback buffer

BPMO_FDBK_DISCNCT

Disconnect from a public feedback buffer

BPMO_FDBK_SUSPEND

Suspend feedback

BPMO_TORO_CIRC_GET

Get a circular buffer of recent toroid data

BPMO_RINQABO_INIT

 

BPMO_RINQABO_SCAN

 

BPMO_RINQABO_MEAS

 

BPMO_MEAS_PREP

Prepare for non-scan BPM measurement

BPMO_MEAS_PROC

BPM non-scan measurement prepare reply

BPMO_WIRE_PREP

Prepare for scanning BPM measurement

BPMO_WIRE_PROC

BPM scanning measurement prepare reply

BPMO_RINQDSP_BOOT

 

BPMO_DUMP_RINQDSP

 

BPMO_SHO_RBUFS

Return summary of existing ring buffers

BPMO_CHK_PDUYYCHANS

 

BPMO_TIMING_ADJ

Adjust timing values in running acquisitions

BPMO_BUFRING_SUSP

Suspend a ring buffer

4.2.2      Request and Reply Structures

The SLC request and reply data structure definitions which follow are found in REF_C_INC:BPM_REQREPLY_STRUC.HC.  Also refer to REF_C_INC:BPMSTRUC.HC for data reply structures. These structures support request messages sent from the Alpha to the SLC-aware IOC and must be strictly adhered to by the SLC-Aware IOC. All messages are preceded with the fwd_hdr_ts and msgheader_ts (which contains the function code).  Messages may be sent in pieces (each piece with its own msgheader_ts followed by bpm_largreq_hdrr_ts) if total message is longer than message service's maximum. 

4.2.2.1  Data Acquisition Requests

All gated data acquisitions requested by any SCP are acknowledged back to requesting SCP. Request message structures (from the SCP) are described below. Immediate reply messages (yes / no, error) are described in Reply message structures below.

 

The SLC aware IOC must reply back with requested data as soon as the data for that request has been acquired. The data is packaged according to Section Reply message structures, below. For a (continuous) scan request, there may be further iterations of acquisition followed by its reply message(s).

 

There are X number of acquisition requests that can be queued by any one SLC-aware IOC at any time, due to memory limitations.

 

Data Acquisition Requests are sent via TCP/IP from the SCP to the SLC-aware IOC Message Service. The non-scan requests are sent with function code (in msgheader_ts) of BPMO_MEAS_PREP and have message structure bpm_measprep_reqh_ts. Scan requests are sent with function code BPMO_WIRE_PREP, and have message structure bpm_scanprep_reqh_ts, which is an open ended extension of the former. Both are defined in REF_C_INC:BPM_REQREPLY_STRUC.HC.

 

Message structures and fields within the structures are shown below for BPMO_MEAS_PREP and BPMO_WIRE_PREP. Fields “of interest” to the SLC-Aware IOC are highlighted. Other fields will accounted for, but ignored in the code.

 

Requests (Non-scan, Scan)

Stucture

Type

Name

Description

Msgheader_ts

Func  = BPM0_

 

 

 

MEAS_PREP

 

 

Bpm_largreq_hdrr_ts

 

 

 

 

unsigned long

reqmsgtotwc

Total req msg word cnt

 

 

reqmsgpartwc

Partial req msg word cnt

Bpm_measprep_req_ts

 

 

 

 

unsigned short

i_seg

Measdef id

 

 

nicals

# cals req’d by data reductn

 

 

i_cal[4]

Ids of cals

 

 

npp

Num of base beamcodes

 

unsigned char

pp[4]

Base beamcodes

 

 

long_pulse_

bpm_phas_type

For trav-wave BPMP cal op done at meas time

 

 

bunch[2]

deprecated; which bunch

 

 

eminus

e – bunch request P2

 

 

tryy_flag

Orsay BSM; NLCTA toro;

E150 foil scan

 

 

navg

# pulses to avg for ea resulting val

 

 

nmuxyy

Max num of mux’s (1or10)

 

 

yy

PNET bits to enable acq

 

 

yyseq_type

WIREYY2BIT-add’l pre-posn scan step req’ed

 

 

spareb[3]

spare bytes

 

unsigned long

measbits

See MEAS*_INDEX; which prims included

 

unsigned short

umin

Unit list 1 range beg

 

 

umax

Unit list 1 range end

 

 

umin2

Unit list 2 range beg

 

 

umax2

Unit list 2 range end

 

 

flip

specific flags - ignore

 

 

spare1

spare

 

 

long_pulse_

bpm_phas[2]

For trav-wave BPMP cal op done at meas time

 


Requests (Non-scan, Scan) Continued

Stucture

Type

Name

Description

 

float

bunchdel[4][2]

BPMP  gate timing adjustment (PEPII)

 

unsigned long

nopp_mindel

 

 

 

vetomask

 

 

float

beamstrength[2]

 

 

unsigned long

exclmask

[MAX_MODFR_MASK]

Exclusion mask

 

 

inclmask_strt[“]

Inclusion mask

 

 

inclmask_nxt[“]

Ignore this one

 

unsigned short

spare2

beginning of PEPII data:

 

 

drdel

Deprecated

 

 

nfwd_sec_max

Timeout measdef  (sec)

 

 

tryy_unit

PDU ch (TRYY) req’ed to fire

 

 

nturns

P2

 

 

nthturn

P2

 

 

rinq_dsp_mode

protocol bet micro & DSPs

 

 

rinq_dlymax

P2

 

unsigned long

start_turns_skip[2]

P2 ring turns to skip a start

 

unsigned short

rinq_bucket[]

P2 bucket number

 

unsigned long

rinq_sine_freq

P2 freq for sine fit

 

 

morflgs

P2 rtn phase, not tmit

 

unsigned short

spare4[8]

spare

 

 

 

 

Bpm_measulist_ts

 

 

 

 

Unsigned short

ulist

explicit unit list

End of Requests (Non-scan, Scan;  bpm_scanprep_reqh_ts)

Notes:

MEAS*_BITs supported by LCLS:

See [REF_C_INC]:bpmparam.hc ):

MEAS*_BIT requests device data

Primary

Hex value

MEASBPM_BIT     

BPMS

0x00000001

MEASTOR_BIT     

TORO

0x00000002

MEASARRY_BIT  

ARRY

0x00000040

MEASWIRE_BIT   

WIRE

0x00000080

MEASPUSID_BIT  

 None* (pulse id)

0x00000400

* Pulse id is not a “device” or primary, but is included in “device” bits as a convenient method of requesting that the data include pulse id.

 

Notes:

·        MAX_MODFR_MASK = (PNET_MODFBIT_HILIM - PNET_MODFBIT_LOLIM + 31)/32), where

PNET_MODFBIT_LOLIM = 32,   Bit offset in PNET message

PNET_MODFBIT_HILIM = 128,  Bit offset + 1 in PNET message of

 

 

For Scan Requests, all of above (function code = BPMO_WIRE_PREP), plus:

Structure

Type

Name

Description

Bpm_scanprep_exten_ts

 

 

 

 

unsigned short

wun

WIRE unit if wire scanning (only one!)

 

 

nrpos

# scan steps

 

 

wmovf

lsb =1 when moving WIRE unit

 

 

wire_bitid

not used by micro

 

unsigned long

wire_type

“FLY”, or “STEP” type

 

unsigned short

sped

adjustable scan rate (from op)

 

 

posdel[0]

fiduc cnt to get WC to initial posn

 

 

posdel[1]

fiduc cnt to get WC step’d nxt pos

 

 

posdel[2]

fiduc cnt to get WC out of way

 

 

posdel[3]

not used

 

 

fbvecflag

op initiated fast feedback req

 

 

wposrb_scalar_unit

GADC unit to read WC position

 

 

wposrb_scalar_sa

Subaddr

 

 

spare[8]

Spare

 

float

bunchdel_incr

Nanosecs

 

unsigned long

sbdctlw

single beam dumper ctl word

 

 

sbdbitns

single beam dumper command

 

 

wmovc[0]

SMC command to beg of WS

 

 

wmovc[1]

SMC command to step

 

 

wmovc[2]

SMC command to get to parked posn (adj at runtime upon err)

 

 

wmovc[3]

 Spare

 

 

magctlw[4]

mag corrector camac ctrl words

 

 

rbkctlw[4]

mag corrector rdbk

 

unsigned short

magdac[steps][4]

mag mover positions (val for ctlw)

 

 

 

 

Note: Fields whose text is highlighted in gray may be replaced with LCLS –implementation specific fields.

 

4.2.2.2  Other Request message structures

 

SLC Aware IOC Supported Function Code

 

Request Message Structure(s)

See: REF_C_INC:BPM_REQREPLY_STRUC.HC

BPMO_MEAS_STOP

bpm_meas_stop_req_ts

BPMO_GETREMDAT

Msgheader_ts

BPMO_CLR_SCP

bpm_clrscp_reqh_ts

BPMO_SHO_RBUFS

Msgheader_ts

 

4.2.2.3  Non-Data Reply message structures

SLC Aware IOC Supported Function Code

 

Reply Message Structure(s)

See: REF_C_INC:BPM_REQREPLY_STRUC.HC

REF_C_INC:BPMSTRUC.HC

BPMO_MEAS_PREP

Bpm_allprep_reply_ts

BPMO_WIRE_PREP

Bpm_allprep_reply_ts

BPMO_SHO_RBUFS

Bpm_shobufs_rplybeg_ts

 

Sho_1bufring_ts

 

Sho_1sampreq_ts

 

 

Sho_1fbconn_ts (dummy)

 

Sho_1calconst_ts (dummy)

 

The bpm_allprep_reply ts contains the following:

Stucture

Type

Name

Description

Bpm_allprep_reply_ts

 

 

 

 

Unsigned char

Iss

Vmsstat-t status

 

 

Spareb[3]

 

 

Unsigned long

Datrply-totwc

Total word count of data reply, when ready

 

 

Spare1

 

 

Unsigned short

Npulstep

# pulse steps

 

 

sparew

 

 

The sho_1sampreq_ts contains the following:

Stucture

Type

Name

Description

Sho_1sampreq_ts

 

 

 

 

Unsigned long

My_dest

 

 

Unsigned short

Id

 

 

 

Flagsr

 

 

 

Proctyp

 

 

 

Nscanpos

 

 

 

Sparew[2]

 

 

 

Nscampkts

 

 

 

Tryy_unit

 

 

Unsigned char

Enabyyval

 

 

 

Spareb

 

 

 

Nppvals

 

 

 

Tryynvals

 

 

 

Ppvals[BPM_MAXPP]

 

 

 

Tryyvals[26]

 

 

Unsigned long

Bpmsmap[(MBPMS+31)/32]

 

 

 

totomap[(MAXTOR+31)/32]

 

 

 

dugadcmap[(MDUGUNITS+31)/32]

 

 

4.2.2.4  Data Acquisition Reply Messages

Data reply messages package up the data requested by its associated request message.

 

For non-scan data acquisition:

Data included in the reply depends on the requested devices and unit numbers. There is a hard-coded order to the data because the data is not self-identifying; see bpmparam.hc MEAS*_INDEX order. Data is included regardless of HSTA , in explicit unit # list or within the requested unit # range if the explicit unit # list contains nothing. Data must be packed (no word padding) like VMS expects, and must be in little-endian prior to sending to Alpha. Total word count, partial message counts, and message checksum must be computed. Float data must be converted from IEEE to VMS.

 

Non-Scan Data Reply

All non-scan data highlighted in the following tables are supported. Data is shown in order of “packing”.

Stucture

Type

Name

Description

Fwd_hdr_ts

 

 

 

 

 

 

 

Msgheader_ts

Func  = BPM0_

 

 

 

MEAS_PROC

 

 

Bpm_alldata_replybeg_ts

 

 

 

 

vmsstat_t

iss

Status

 

unsigned long

measbits

Measbits

 

 

datrply_totwc

Total word count

 

 

datrply_partwc

Partial word count

 

unsigned short

ndatblks

Ignored for non-scan

 

 

nrpos

Ignored for non-scan

 

unsigned long

checksum

Checksum

Bpms_data_ts

 

 

 

 

float

x

Horizontal val

 

 

y

Veritcal val

      For first unit requested;

 

tmit

Beam current (i)

      DB order

 

x_rms

RMS val when avg’ing

 

 

y_rms

   

 

Unsigned short

qraw[4]

Raw vals (diagnostics)

 

 

stat

Pulse status

 

 

goodmeas

# pulses incl’ed in avg

Bpms_data_ts

 

 

 

      Until last unit

 

 

 

Toro_data_ts     

 

 

 

 

Float

tmit

 

     For first unit requested;

 

tmit_rms

 

     DB order

Unsigned short

qraw

 

 

 

stat

 

 

 

goodmeas

 

Toro_data_ts

 

 

 

      Until last unit

 

 

 

Arry_data_ts

 

 

 

 

float

data[12]

 

      For first unit requested;

 

drms[12]

 

      DB order

unsigned short

raw[12]

 

 

 

stat[12]

 

 

 

goodmeas[12]

 

Arry_data_ts

 

 

 

      Until last unit

 

 

 

Wire_data_ts

Not read for non-

scan

 

Bpm_pulseid_data__ts     

 

 

 

   

Unsigned short

navg

Num pulses averaged

   

 

nmuxmin

Num mux min = 1

    

Unsigned long

tstamp[2]

VMS timestamp

bpm_pulseid_data_ts

 

pulseid[1]

First of many

      Until navg # pulses

 

 

   Pulseids

 

 

 

 

 

For scanning data acquisition:

Unlike non-scan data reply, the scan data reply is self-identifying. For each included unit, there is a scanblk_prefix_ts followed by array of  nrpos number of data structures (eg ws_wire_data_ts’s or ws_bpm_data_ts’s, or ws_toro_data_ts’s; pulse ids are an exception.) Units whose HSTA’s are not good are omitted.

Data must be packed (no word padding) like VMS expects, and must be in little-endian prior to sending to Alpha. Total word count, partial message counts, and message checksum must be computed. Float data must be converted from IEEE to VMS.

 

Stucture

Type

Name

Description

Fwd_hdr_ts

 

 

 

 

 

 

 

Msgheader_ts

Func  = BPM0_

 

 

 

WIRE_PROC

 

 

Bpm_alldata_replybeg_ts

 

 

 

 

vmsstat_t

iss

vmsstat_ts

 

unsigned long

measbits

which devices

 

 

datrply_totwc

Total word count

 

 

datrply_partwc

Partial word count

 

unsigned short

ndatblks

Num of scanblk prefixes

 

 

nrpos

Num scan positions

 

unsigned long

checksum

Checksum

 

 

The following data is present if the associated measbits are set, according to (for LCLS):

MEASBPM_BIT      0x00000001

MEASTOR_BIT      0x00000002 (not shown below; same structure as bpm)

MEASARRY_BIT   0x00000040

MEASWIRE_BIT    0x00000080

MEASPUSID_BIT   0x00000400

 


Scan Data Reply Continued (ws_wire_data_ts)

 

Stucture

Type

Name

Description

scanblk_prefix_ts

 

 

 

   For WIRE:UN0x

unsigned long

prim

Primary

 

unsigned short

unit

Unit

 

 

wc

Word cnt of this unit’s

 

 

 

Data; not incl scanblk

ws_wire_data_ts * nrpos

 

 

 

 

float

value[3]

Val

   WIRE:UN0x

 

valrms[3]

RMS val

  nrpos of ws_wire_data_ts

unsigned short

stat[3]

Status, ea ws channel

    

 

goodmeas[3]

# pulses used in avg

  

float

position_smc

Dist SM moves to pos

 

 

position_opt

Optical count

ws_wire_data_ts

 

 

 

scanblk_prefix_ts

 

 

 

   For WIRE:UN0x+1

unsigned long

prim

Primary

 

unsigned short

unit

Unit

 

 

wc

Word cnt of this unit’s

 

 

 

Data; not incl scanblk

ws_wire_data_ts * nrpos

 

 

 

 

float

value[3]

Val

 nrpos of ws_wire_data_ts

 

valrms[3]

RMS val

    

unsigned short

stat[3]

Status, ea ws channel

  

 

goodmeas[3]

# pulses used in avg

 

float

position_smc

Dist SM moves to pos

ws_wire_data_ts

 

position_opt

Optical count

Repeats scanblk, nrpos

Ws_wire_data_ts for all WIRE units in meas prep unit(s) list

 

 

 

 


Scan Data Reply Continued (ws_bpm_data_ts)

 

Stucture

Type

Name

Description

scanblk_prefix_ts

 

 

 

   For BPMS:UN0x

unsigned long

prim

Primary

 

unsigned short

unit

Unit

 

 

wc

Word cnt of this unit’s

 

 

 

Data; not incl scanblk

ws_bpm_data_ts * nrpos

 

 

 

   BPMS:UN0x

float

x

Horizontal val

  nrpos of ws_bpm_data_ts

 

y

Veritcal val

  

 

ymit

Beam current (i)

 

 

stat

Pulse status

 

 

goodmeas

# pulses incl’ed in avg

ws_bpm_data_ts

 

 

 

scanblk_prefix_ts

 

 

 

   For BPMS:UN0x+1

unsigned long

prim

Primary

 

unsigned short

unit

Unit

 

 

wc

Word cnt of this unit’s

 

 

 

Data; not incl scanblk

ws_bpm_data_ts * nrpos

 

 

 

   BPMS:UN0x

float

x

Horizontal val

  nrpos of ws_bpm_data_ts

 

y

Veritcal val

  

 

tmit

Beam current (i)

 

 

stat

Pulse status

 

 

goodmeas

# pulses incl’ed in avg

ws_bpm_data_ts

 

 

 

Repeats scanblk, nrpos

Ws_bpm_data_ts for all BPMS units in  meas prep unit(s) list

 

 

 

 


Scan Data Reply Continued (ws_toro_data_ts)

 

Stucture

Type

Name

Description

scanblk_prefix_ts

 

 

 

   For TORO:x

unsigned long

prim

Primary

 

unsigned short

unit

Unit

 

 

wc

Word cnt of this unit’s

 

 

 

Data; not incl scanblk

ws_toro_data_ts * nrpos

 

 

 

   TORO:x

 

tmit

Beam current (i)

  nrpos of ws_toro_data_ts

 

stat

Pulse status

  

 

goodmeas

# pulses incl’ed in avg

 

 

 

 

ws_toro_data_ts

 

 

 

scanblk_prefix_ts

 

 

 

   For TORO:x+1

unsigned long

prim

Primary

 

unsigned short

unit

Unit

 

 

wc

Word cnt of this unit’s

 

 

 

Data; not incl scanblk

ws_toro_data_ts * nrpos

 

 

 

   TORO:x

 

tmit

Beam current (i)

  nrpos of ws_toro_data_ts

 

stat

Pulse status

  

 

goodmeas

# pulses incl’ed in avg

 

 

 

 

ws_toro_data_ts

 

 

 

Repeats scanblk, nrpos

Ws_toro_data_ts for all TORO units in  meas prep unit(s) list

 

 

 

 

The DUGADC ws_arry_data_ts would be oredered here
Pulse id Data Reply Continued (ws_puid_data_ts)

 

Stucture

Type

Name

Description

scanblk_prefix_ts

 

 

 

   For pulse id

unsigned long

prim = “PUID”

Primary

 

unsigned short

unit = 1

Unit

 

 

wc

Word cnt :

(sizeof(ws_puid_ts) – sizeof(ws_puid_data_ts) + (nrpos * navg) * sizeof ws_puid_data_ts )/ 2

ws_puid_ts

 

 

 

 

unsigned short

navg

# pulses to average

 

 

nmuxmin =1

# multiplexed pos

 

unsigned long

tstamp[2]

Time stamp

 

 

pulseid[1]

Beg of pulse id array

ws_puid_data_ts

 

 

       of nrpos * navg

 

unsigned long

pulseid

      

nrpos * navg pulseids

 

 

 

  

 

 

  

 

nrpos * navg

 

ws_puid_data_ts

 

 

 

1 scanblk_prefix_ts,

1 ws_puid_ts whose pulseid array contains

nrpos * navg long words

 

 

 

 

4.3       Runtime Database Access to EPICS BSAC Facility

It is thought that EPICS records will primarily be used to select acquired pulse data in order to satisfy the various user requests.

EPICS records:

·        Store BPMO_MEAS_PREP and BPMO_WIRE_PREP user criteria; include:

o       YY, beam code, exclusion mask, inclusion mask, navg, nrpos from message

o       Criteria active flag (when clear (empty), criteria can be overwritten)

·        Signal completion (or iteration) of any user request after navg*nrpos pulses acquired

·        Get per-user collection buffers of acquired data

·        Indicate any error conditions

·        Other DB records in place for

o       State of calibration

o       State of hardware

5         EPICS BSAC Facility to Device Support Interfaces

The interfaces between EPICS database records and device support must satisfy requirements imposed on them in order to support the SLC High Level Applications.  In general, these requirements flow from the acquisition data structures expected by the SLC High Level Applications and are specific to the device being measured and the pulse ID information provided by the timing system.

 

The SLC High level applications expect a rich and detailed amount of data from each device. In satisfying the requirements of the SLC system, it is expected that the applications developed later as EPICS clients can also provide a meaningful view of the performance of the LCLS system.

5.1       EVR Interface

5.1.1      EVR Module Interface Requirements

The entire SLC PNET pattern will be sent to the EVR by the EVG in a pattern referred to as the EB.  The EB, along with PNET bits, also contains an EPICs time stamp.  The SLC Aware IOC must have access to the EVR buffer (via db access) that stores the EB, because the “PNET bits” of the EB pattern are continuously compared with user request criteria previously sent via message service from SCP(s). Each EB pattern will be compared with all user request criteria on every 360Hz timing fiducial. The specific EB bits that are compared are the (YY) “meas def  enable”, on the first pulse of the measurement sequence only, the (PP) beam code, and exclusion/inclusion bits (32-127). 

 

When a match occurs, the matching EB data, including pulse id and EPICS time stamp, must be associated with the pulse data that will be acquired 120Hz (three 360Hz timing fiducials) later. Thus PNET patterns must be buffered for at least three fiducials.

 

EVR Interface Requirements Summary:

 

5.1.2      EVR SLC Data Requirements

5.1.2.1  Pulse id (from PNET broadcast)

Pulse ids (PUID) are requested by all SLC Control System high level applications. A bit in the meas field of the request message is set if PUIDs are desired. (The meas field has bits for other requested device data also, including DUGADCs and BPM data). Thus, PUIDs can be requested for both BPM and GADC acquisition. When the MEASPULSID_BIT is set in the meas field of a request message, the pulse id data is packaged with the following structures.

5.1.2.2  Pulse id Data Structure

Bpm_pulseid_data_ts (non-scan) and ws_puid_ts (scan):

·        EPICS Time Stamp

·        Pulse id unsigned long

5.2       BPM Module Interface

5.2.1      BPM Module Interface Requirements

Assume BPM processing module (BPMP) is measuring every LCLS beam pulse

·        The BPMP must associate acquired data with EPICS timestamp (for EPICS HL Apps)

·        Provide data access (runtime DB, CA) for all BPMS data (see next section)           

o       Beam pulse acquisition data

§         Floating point data per channel (x,y, tmit)

§         Unsigned short status per channel

§         Unsigned short raw data per channel

o       Hardware status and error indicators

o       Cal state indicator

·        The BPM data also needs to be stored in a circular buffer to allow the retrieval of consecutive pulses and also to allow access to earlier pulses when some non-synchronous event occurs.

·        Initiating the readout of the circular buffer should be both on demand from a user or triggered by a fault condition so that the data is written to a file for fault analysis.

.

5.2.2      BPMS SLC Data Requirements

5.2.2.1  Reply Data Structure – Non-scan

Structure bpms-data_ts, required for SLC BPMS non-scan data, contains these fields:

5.2.2.2  Reply Data Structure – Scan

Structure ws_bpm_data_ts, required for SLC BPMS scan data, contains these fields:

5.2.2.3  BPMS status

The following highlighted 16-bit status bits are returned by the SLC-aware IOC for each BPMS measurement (see c_inc/bpmstat.hc). Other TBD status bits, possibly new, possibly the same as those below, will be dependant upon the BPM processor module under development and will be coordinated with any SCP BPM Diagnostic Display development.

status

Hex Value

 

STAT_GOOD

0x0001

Completely Happy

STAT_OK

0x0002

Substandard, but OK

STAT_DEAD

0x0004

Out of Service

STAT_SICK

0x0008

In Trouble

STAT_XBAD             

0x0010       

 

STAT_YBAD   

0x0020         

 

STAT_XSAT   

0x0040

 

STAT_YSAT   

0x0080

 

STAT_SUMSAT 

0x0100

 

STAT_SUMLOW 

0x0200

 

STAT_SUMWILD

0x0400

 

STAT_VETOED 

0x0800        Not used

 

STAT_NOGATE 

0x1000       

 

STAT_ONEQ   

0x2000        camac

 

STAT_NOX    

0x4000        camac

 

STAT_MISREF 

0x8000

 

STAT_BADCAL

0x000C

 

STAT_MAINTENANCE

0x0014

Maintenance Mode

STAT_CHECKOUT

0x0024

Checkout Mode

 

5.3        GADC Modules and DUGADC (WIRE, ARRY)Interfaces

5.3.1      GADC Module Interface Requirements

·        Provide (runtime db, CA) access to acquired data

·        The GADC must associate acquired data with EPICS timestamp (for EPICS HL Apps)

·        Provide data access (runtime DB, CA) for all GADC data (see next section)

o       Beam pulse acquisition data

§         Floating point data per channel

§         Unsigned short status per channel

§         Unsigned short raw data per channel

o       Hardware status and error indicators

o       Cal state indicator ?

o       For WIRE, need stepper motor controller position

·        Current Stepper Motor Controller position must be made available to correlate with acquired data for wire scans.

5.3.2      GADC / DUGADC SLC Data Requirements

GADC modules are assigned one or more devices that must use gated ADC acquisition.  GADC is a SLC DB Primary which describes the kind of digitizer. The devices assigned to a GADC are referred to as “devices using gated ADC” (DUGADC). A SLC DUGADC can be the SLC DB primary WIRE, ARRY, GAPM, SLIT, OR WVFM. It is assumed that GAPM, SLIT, and WVFM will not be required by LCLS.

5.3.2.1  WIRE (DUGADC) SLC Data Requirements

Note: In the current SLC micros, the number of wire channels is 3. LCLS requires X number of wire channels.

5.3.2.1.1   WIRE Reply Data Structure – Non-scan

Question: will LCLS ever acquire current data from a non-scanning wire?

 

Structure wire_data_ts, required for SLC WIRE non-scan data, contains these fields:

5.3.2.1.2   WIRE Reply Data Structure – Scan

Question: will LCLS ever acquire current data from a scanning wire?

 

Structure wire_data_ts, required for SLC WIRE non-scan data, contains these fields, for the WIRE unit (wun) specified in user criteria:

 

Note that a WIRE must return the position of its associated SMC for each scan step

 

5.3.2.2  ARRY (DUGADC) SLC Data Requirements

5.3.2.2.1   ARRY Reply Data Structure – Non-scan

Structure arry_data_ts, required for SLC WIRE non-scan data, contains these fields:

5.3.2.2.2   ARRY Reply Data Structure – Scan

Structure ws_arry_data_ts, required for SLC ARRY scan data, contains these fields:

 

5.3.2.2.3   DUGADC status

The following highlighted 16-bit status bits are returned by the SLC-aware IOC for each DUGADC measurement (see c_inc/bpmstat.hc). Other TBD status bits, possibly new, possibly the same as those below, will be dependant upon the GADC processor module being used and will be coordinated with any SCP BPM Diagnostic Display development.

 

status

Hex Value

Description

STAT_GOOD

0x0001

Completely Happy

STAT_OK

0x0002

Substandard, but OK

STAT_DEAD

0x0004

Out of Service

STAT_SICK

0x0008

In Trouble

STAT_BADCAL

0x000C

 

STAT_BADCHKSUM

0x000E

 

STAT_XSAT

0x0040

 

STAT_SMCBAD

0x0100

Bad status bits read from stepper

STAT_BLWFPED

0x0400

HSTA_AVGEXCL set, and data below FPED

STAT_VETOED 

0x0800

 

STAT_NOGATE 

0x1000

 

STAT_NOX    

0x4000

 

 

5.4       TORO Control Module Interface

5.4.1      TORO Control Module Interface Requirements

·        Provide data access (runtime DB, CA) for all TORO data (see next section)

o       Beam pulse acquisition data

§         Floating point tmit

§         Unsigned short status

§         Unsigned short qraw data  

o       Hardware status and error indicators

o       Cal state indicator ?

·        The TORO must associate acquired data with EPICS timestamp (for EPICS HL Apps)

 

5.4.2      TORO SLC Data Requirements

5.4.2.1  TORO SLC Reply Data Structure – Non-scan

Structure toro_data_ts, required for SLC TORO non-scan data, contains these fields:

5.4.2.2  TORO SLC Reply Data Structure – Scan

Structure ws_toro-data_ts, required for SLC TORO scan data, contains these fields:

5.4.2.3  TORO status

The following highlighted 16-bit status bits are returned by the SLC-aware IOC for each TORO measurement (see c_inc/bpmstat.hc). Other TBD status bits, possibly new, possibly the same as those below, will be dependant upon the TORO Control module being used and will be coordinated with any SCP BPM Diagnostic Display development.

 

status

Hex Value

Description

STAT_GOOD

0x0001

Completely Happy

STAT_OK

0x0002

Substandard, but OK

STAT_DEAD

0x0004

Out of Service

STAT_SICK

0x0008

In Trouble

STAT_SUMSAT 

0x0100

 

STAT_STOL

0x0200

Data must be below this tolerance limit to be accepted as a good value

STAT_GAINLOW

0x0400

Gain too small

STAT_OVERSAT

0x0800

ADC Undersaturated

STAT_NOQ

0x1000

ADC Oversaturated

STAT_BADPHASE

0x2000

Bad Calibration

 

6         Glossary

·        Beam Synchronous Acquisition: Data acquired with gated ADCs: BPMs, Toroids, Wire-Scanners, Profile Monitors, etc using the SLC / LCLS Timing System.

·        BSAC: Beam Synchronous Acquisition and Control (control for wire carriage stepper motor)

·        Beam Position Monitor : (BPM) device which measures transverse position of  electron beam trajectory. Processor DB primary: BPMP, Stripline DB primary: BPMS

·        GADC – gated analog to digital converter (ADC); looks like a bpm to micro software; refers to beam synchronized (gated) ADC devices; DB primary GADC.

·        DUGADC – (D)evice (U)sing gated ADC; generic name to describe DB primaries WIRE, SLIT, ARRY, etc

·        ARRY – generic “catch all” gated ADC channel configurable in DB; DB primary ARRY; can be photomultiplier tube (PMT), beam loss monitor (BLM), etc.

·        TORO- Toroid;  Device which measures charge (Toroid Charge Monitor); DB primary TORO.

·        Wire Scanner: Wires which step through the beam under control of stepper motor; photons are deflected onto photomultiplier tubes (PMT) and digitized with gated ADCs. Data is used to calculate emittance.  Measured beam size (x,y) is averaged over approx. 100 pulses, and is non-invasive. Used to measure transverse beam size (beam monitor).

·        WIRE – Wire scanner; DB primary.

·        Photomultiplier Tube - device used in conjunction with wire scanners; photon to transducer amplifier which uses photelectric effect and secondary emissions in cascaded diode cells to produce a measurable electric current from photons.

·        SLIT -  Collimator  DB primary: SLIT;  mechanical device installed in beam line in order to reduce the aperature. LCLS has movable jaws (mostly in x); Used for beam profile measurement. No integrated bpms for LCLS SLIT.

·        Profile Monitor – uses invasive, single shot acquisition

·        Non-scanned acquisition - Single shot acquisition – one reading of all devices selected by user on a single pulse – synonymous with “MEAS_PREP”.  The reading can be averaged over N pulses.  See SCP LCLS BPM Measurement panel, One Shot Data and Start-Top Data buttons.

·        Scanned acquisition - Buffered acquisition – Many consecutive pulses acquired from user selected devices – synonymous with  WIRE_PREP”. See SCP Buffered Data Acquisition Panel Take Buffer Data button.

·        BPMD- DB primary which uniquely identifies measurement definitions for data acquisition; contains beam code (PP), DGRP, and other parameters

·        DGRP – DB primary containing named display group comprised of micros, locations within sector, regional beam code exclusion and inclusion masks, and other parameters.

·        BGRP – beam code scheduling group; holds definitions of scheduling patterns for up to four beamcodes, rate limiting, and modifiers. Any BGRP tells the MPG what (most of) the content should be of the PNET pattern for one 120Hz phase of 360Hz.

·        PPYY – 16 bit word used by timing software/hardware to select times at which devices should be triggered on an upcoming machine pulse. Generated by MPG and broadcast at 360 Hz as part of PNET message. PP is beam code used to select the time delays for devices such as klystrons and magnets. YY is used to synchronize additional devices, such as BPMs and DUADCs.

·        Meas Prep – (measurement preparations) – User measurement definitions (up to 20 in micro), or fast feedback definitions communicated from SCP/Alpha to define how to acquire gated data on upcoming beam pulses.

·        Inclusion /exclusion bits – specifies whether to acquire data on beam pulse. Bits 32-127 of PNET; also correspond bit-for-bit with meas prep inclusion/exclusion masks – “1” bits in inclusion mask indicate required “1” bits in PNET message; “1” bits in exclusion mask indicate required “0” bits in PNET message.

·        Inclusion/exclusion masks – downloaded in BPMO_*_PREP message, select beam pulses to be acquired. Exslusion mask is 64-bit mask of modifiers, the occurrence of any of which on the given beamcodwe causes the BPM code to skip any attempt to collect data on that pulse. An inclusion mask similarly specifies modifiers, all of which are required on the given beamcode for the BPM code to attempt to collect data on that pulse.

·        Beam loss monitor – contains photomultiplier tubes or ion chambers; new for LCLS; acquires voltage when beam goes past (beam synchronous). Data for LCLS will not be available via SCP.

·        CSR (Coherent Synchrotron Radiation) Bunch length monitor (new for LCLS)– measurements from RF transverse deflecting cavity scans. Used for slice emittance and energy spread calculations from deflection beam profiles. GADC required to read from pyroelectric detectors.

·        Beam profile monitor - A screen inserted in a beam transport line to view the beam cross section. The visible emission created by the beam exiting the screen's phosphor coating (usually zinc sulfide) is viewed by a video camera and the picture transmitted to the Control Room. Profile monitor screens can usually be inserted and removed remotely by the machine operators.

·        SLC DB Primary

·        SLC DB Secondary

·        SLC DB Unit