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
Use
Cases for Beam Synchronous Data
BSAC Facility Data Flow Diagrams
(PPYY)
SLC-aware
BPM Facility Interfaces
Runtime DB Access to EPICS BSAC
Facility
EPICS BSAC
Facility Interfaces
GADC modules and DUGADCs (WIRE, ARRY)
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.
· 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
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.
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
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 Reqed 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
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.
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.
See the SCP LCLS Index created by Mike Z
Insert screen shots
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
Patrick has a prioritized list. Refer to tables in Section 2.21 above.
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.
Fast feedback is supported with a special-purpose Fast Feedback hardware module in the LCLS IOCs.
Diagnostics is supported through EDM displays.
Other EPICS clients are supported such as:
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.
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
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.
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.
The LCLS beam rate is a maximum 120Hz.
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
· 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.
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.
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.
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 |
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.
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
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 BPMSs 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.
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
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 ADCs |
HSTA_GADC12BT |
0x00002000 |
GADC has 11-bit ADCs |
HSTA_GADCWVFM |
0x00004000 |
Module is a LeCroy 2267 Waveform Digitizer |
|
|
|
HSTA_GADCWVBB |
0x02000000 |
If LeCroy2262, chans 2 & 3 biphased together |
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 |
|
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 POLYs, 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 |
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. |
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 units recent data |
HSTA_TORONPRD |
0x00000100 |
Module has separate gates per channel |
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.
All BPM function codes are in file [REF_C_INC]:bpmfunc.hc.
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 |
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.
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 reqd 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 muxs (1or10) |
|
|
yy |
PNET bits to enable acq |
|
|
yyseq_type |
WIREYY2BIT-addl pre-posn scan step reqed |
|
|
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) reqed 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 stepd 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.
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 |
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] |
|
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 avging |
|
|
y_rms |
|
|
Unsigned short |
qraw[4] |
Raw vals (diagnostics) |
|
|
stat |
Pulse status |
|
|
goodmeas |
# pulses incled 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_tss or ws_bpm_data_tss, or ws_toro_data_tss; pulse ids are an exception.) Units whose HSTAs 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 units |
|
|
|
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 units |
|
|
|
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 units |
|
|
|
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 incled 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 units |
|
|
|
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 incled 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 units |
|
|
|
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 incled 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 units |
|
|
|
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 incled 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 |
|
|
|
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
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.
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:
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.
Bpm_pulseid_data_ts (non-scan) and ws_puid_ts (scan):
· EPICS Time Stamp
· Pulse id unsigned long
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.
.
Structure bpms-data_ts, required for SLC BPMS non-scan data, contains these fields:
Structure ws_bpm_data_ts, required for SLC BPMS scan data, contains these fields:
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 |
· 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.
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.
Note: In the current SLC micros, the number of wire channels is 3. LCLS requires X number of wire channels.
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:
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
Structure arry_data_ts, required for SLC WIRE non-scan data, contains these fields:
Structure ws_arry_data_ts, required for SLC ARRY scan data, contains these fields:
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 |
|
· 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)
Structure toro_data_ts, required for SLC TORO non-scan data, contains these fields:
Structure ws_toro-data_ts, required for SLC TORO scan data, contains these fields:
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 |
· 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