Tevatron BPM Requirementsbeamdocs.fnal.gov/AD/DocDB/0008/000860/031/bpm_sw.doc · Web viewFor this...

Tevatron BPM Software Specifications for Data Acquisition, Version 6.7231452, 5/18/202363231102/17/04

Fermilab/ABD/TEV

Beams-doc-860-v15v231452May 18, 2023March 25June 23February 17, 2004

Version 6.7312542

Tevatron Beam Position Monitor UpgradeSoftware Specifications for

Data Acquisition

DRAFT DRAFT DRAFT

Margaret Votava, Luciano Piccoli, Dehong ZhangFermilab, Computing Division, CEPA

Brian HendricksFermilab, Beams Accelerator Division, Accelerator Controls Department

Jim SteimelFermilab, Accelerator Division, Tevatron Department

Abstract

This document contains the specifications for the BPM/BLM upgrade data acquisition software. Expected operating modes and interactions to the BPM/BLM hardware are

1 5/18/23


described. Data structures for communication with the online software via ACNET are defined. Calibration and diagnostics procedures are also specified in this document. Table of Content

1 Overview ......................................................................................................................31.1 Measurement Types .............................................................................................31.2 Hardware Configuration .......................................................................................41.3 Requirements on the DA Software ......................................................................6

2 Data Acquisition ...........................................................................................................72.1 Arm Signals ..........................................................................................................72.2 Timing and Trigger Signals .................................................................................82.3 Data Acquisition Modes .....................................................................................10

2.3.1 Idle Mode ...............................................................................................112.3.2 Closed Orbit Mode .................................................................................112.3.3 Turn by Turn ..........................................................................................152.3.4 First Turn ...............................................................................................162.3.5 Asynchronous Injection .........................................................................172.3.6 Calibration Mode ...................................................................................172.3.7 Diagnostic Mode ....................................................................................17

2.4 State Diagram .....................................................................................................192.5 Alarms ................................................................................................................212.6 Configuration Parameters ...................................................................................21

2.6.1 DAQ Parameters ....................................................................................212.6.2 Timing Parameters .................................................................................222.6.3 Diagnostic Parameters ...........................................................................22

3 Interface to Online Software ......................................................................................233.1 SSDN / ACNET Device Mapping .....................................................................23

3.1.1 SSDN Mapping for FTP devices ...........................................................243.1.2 SSDN Mapping for RETDAT devices ..................................................243.1.3 SSDN Mapping for SETDAT devices ...................................................25

3.2 Data Structures (Output Date) ............................................................................253.2.1 Generic Headers .....................................................................................253.2.2 BPM Non Turn By Turn ........................................................................263.2.3 BPM Time Slice Data ............................................................................273.2.4 BPM Turn By Turn ................................................................................273.2.5 Calibration Constant Data ......................................................................28

4 Interface to BPM Hardware ........................................................................................284.1 Operation of the Echotek ADC Boards ..............................................................284.2 Operation of the Timing Generator Fanout Board .............................................29

5 Calibration ..................................................................................................................316 Diagnostics, Test Suite, and Simulation .....................................................................32

6.1 Diagnostics .........................................................................................................326.2 Self-Testing Procedures .....................................................................................32

7 Monitoring ..................................................................................................................328 Appendix ....................................................................................................................33

8.1 Current BPM Data Structures ............................................................................33

2 5/18/23


8.1.1 BPM Turn By Turn ................................................................................338.1.2 BPM Closed Orbit ..................................................................................33

1 Overview ........................................................................................................................1.1 Requirements ..................................................................................................................1.2 Goals ...............................................................................................................................2 Data Acquisition ...........................................................................................................52.1 Clock Signals ................................................................................................................52.2 BPM Measurement types .............................................................................................72.3 BPM Data Acquisition Modes ......................................................................................82.3.1 ...........................................................................................................Normal operation

82.3.2 .........................................................................................................................Injection

102.3.3 ..................................................................................................................Turn by Turn

101.1.1 ...........................................................................................................Calibration Mode

112.3.4 ...................................................................................................................................112.3.5 ...............................................Diagnostic Mode – we don’t know what this means yet

112.4 BLM Data Acquisition Modes ...................................................................................112.5 Alarms ........................................................................................................................112.6 State Diagram .............................................................................................................123 Configuration Parameters ...........................................................................................143.1 DAQ Parameters .........................................................................................................143.2 Timing Parameters ......................................................................................................143.3 Diagnostic Parameters ................................................................................................154 Interface to Online Software ......................................................................................154.1 SSDN/ACNET Device Mapping ................................................................................164.1.1 ...................................................................................SSDN Mapping for FTP devices

164.1.2 ..........................................................................SSDN Mapping for RETDAT devices

174.1.3 ...........................................................................SSDN Mapping for SETDAT devices

184.2 Data Structures (Output Data) ....................................................................................184.2.1 .............................................................................................................Generic Headers

194.2.2 ................................................................................................BPM Non Turn By Turn

194.2.3 ....................................................................................................BPM Time Slice Data

204.2.4 ........................................................................................................BPM Turn By Turn

204.2.5 .....................................................................................................BLM Data Structures

21

3 5/18/23


4.2.6 ....................................................................................................BLM Time Slice Data21

4.2.7 ..............................................................................................Calibration Constant Data21

5 Interface to BPM/BLM Hardware ............................................................................226 Calibration ..................................................................................................................227 Diagnostics, test suite, and simulation .......................................................................237.1 Diagnostics .................................................................................................................237.2 Self-Testing Procedures ..............................................................................................238 Monitoring ..................................................................................................................239 Appendix ....................................................................................................................259.1 Current BPM data structures ......................................................................................259.1.1 ...............................................................................................BPM Single Turn (Flash)

259.1.2 .........................................................................................................BPM Closed Orbit

259.1.3 .......................................................................................................BPM Data Structure

25344556788101011111111111314141415151617181818192019201920194.2.6

................................................................................BLM Time Slice Data ................................................................................................................21

76Calibration ConstantBLM Time Slice2119211922192219221922192319241924192419241924191 ....................................................................................................Overview ..................................................................................................................4

1.1 Requirements ...............................................................................................51.2 Goals ............................................................................................................52 Data Acquisition ..........................................................................................62.1 Clock Signals ...............................................................................................72.2 BPM Measurement types .............................................................................82.3 BPM Data Acquisition Modes .....................................................................92.3.1Normal operation .........................................................................................92.3.2Injection .....................................................................................................112.3.3Turn by turn ...............................................................................................112.3.4Turn by turn ...............................................................................................122.3.5Calibration Mode – we don’t know what this means yet ..........................122.3.6Diagnostic Mode – we don’t know what this means yet ...........................122.4 BLM Data Acquisition Modes ...................................................................122.5 Alarms ........................................................................................................122.6 State Diagram ............................................................................................123 Configuration Parameters ..........................................................................143.1 DAQ Parameters ........................................................................................143.2 Timing Parameters .....................................................................................153.3 Diagnostic Parameters ...............................................................................154 Interface to Online Software ......................................................................154.1 SSDN/ACNET Device Mapping ...............................................................164.1.1SSDN Mapping for FTP devices ...............................................................16

4 5/18/23


4.1.2SSDN Mapping for RETDAT devices ......................................................174.1.3SSDN Mapping for SETDAT devices .......................................................184.2 Data Structures (Output Data) ...................................................................194.2.1Generic Headers .........................................................................................194.2.2BPM Non Turn By Turn ............................................................................194.2.3BPM Time Slice Data ................................................................................204.2.4BPM Turn By Turn ....................................................................................204.2.5BLM Data Structures .................................................................................204.2.6BLM Time Slice Data ................................................................................215 Interface to BPM/BLM Hardware ............................................................216 Calibration .................................................................................................217 Diagnostics, test suite, and simulation .......................................................227.1 Diagnostics ................................................................................................227.2 Self-Testing Procedures .............................................................................228 Monitoring .................................................................................................229 Appendix ....................................................................................................249.1 Current BPM data structures .....................................................................249.1.1BPM Single Turn (Flash) ...........................................................................249.1.2BPM Closed Orbit .....................................................................................249.1.3BPM Data Structure ...................................................................................24

1 Overview

In compliance with the existing Accelerator Controls software architecture, the software pieces surrounding the BPM hardware are divided into 3 layers: the data acquisition (DA) software running on the individual front-end computers in the readout crates in the service buildings (usually referred to as “houses”), user applications running on analysis nodes (Windows or Linux), and online software running on a central server (VAX) and a few DAQ engines (Sun) providing the primary (but not exclusive) bridge between user applications and the DA software. Shown in Figure 1 are tThis note documents accumulated knowledge about the software and data formats needed for the data acquisition part of the Tevatron BPM upgrade project. The data acquisition software will run on the VME front-end computers. Figure 1 shows the overall software structure and the variousdifferent layerelements involved with the BPM upgrade project. This document will focus on the bottom layer, the DA software.

5 5/18/23ACNET

BPMUTI

Sequencer T pages

CLIB

VAX (1)

ACNET

MOOC

DAQ Front-end Applications

Front-End (N) Sun (DAQ engines) (N)

DAQ Jobs

Windows/Linux (N)

Java Application

Ethernet/RMI

ACNET java

BPM UTI java

Ethernet

ACNET

BPMUTI

Sequencer T pages

CLIB

VAX

ACNET

MOOC

DAQ Front-end Applications

DAQ Jobs

Java Application

Ethernet/RMI

ACNET java

BPM UTI java

Ethernet


Figure 1 –- Overall software architecture

In the remaining part of this section, we will briefly outline the required measurement types, the hardware configuration and the requirements on the DA software. In section 2, we will describe the controls, configurations and data buffering within one front-end crate. In section 3 we will define the interface to the online software. In sections 4 through ?? we will elaborate on calibration, debugging, alarms and monitoring.

1.1 Measurement Types

The different types of measurements to be handled by the upgraded Tevatron BPM system are summarized as follows:

Closed Orbit Measurements. The closed orbit is a measurement of the beam position and intensity with the betatron motion, around 20 kHz as seen by the pick- ups, averaged out but including the ~ 60 Hz synchrotron motion component.

Average Closed Orbit Measurements. The average closed orbit is a measurement of the beam position and intensity with both the betatron motion and synchrotron motion averaged out. Compare to the closed orbit measurement, this measurement should average over a longer time in order to eliminate the beam motion due to synchrotron oscillations. In the Tevatron the synchrotron frequency is about 30 Hz at its lowest, so the beam position should be averaged over 3 synchrotron periods or for about 0.1 seconds.

Injection Closed Orbit Measurement. The is a measurement of the closed orbit immediately after injection of beam into the Tevatron.

Injection First Turn Measurement. This is a measurement of the beam position and intensity on the first pass after it enters the Tevatron from the injection beam lines.

Turn By Turn (TBT) Measurement. The TBT is a sequence of 8192 beam positions and intensities measured for 8192 consecutive turns, one measurement per turn at the same relative phase. For this measurement all of the BPMs are synchronized to begin collecting data on the same turn, and there should be no missing turns.

Asynchronous Injection Measurment. This is a failsafe mode for the situation when beam is not injected into the correct bucket, and beam fails to make many

6 5/18/23


revolutions in the Tevatron, and none of the previous modes will be able to produce a reliable measurement.

It is important to note that for all variations of the TBT measurement, all BPMs should be triggered off the same bunch passing with about the same time advances.

1.2 Hardware Configuration

Based on experience from the Recycler BPM system, the upgraded Tevatron BPM readout system is designed to be This document describes the portion of code that resides on the front-end microprocessors also referred to as the Data Acquisition (DA) software. Online software resides on the VAX and DAQ engines, and forms the primary (but not exclusive) bridge between user code and BPM data.

Each front-end depicted in Figure 1 is a VME crate holding a crate controller with a PMCUCD daughter board, a Timing Generator Fanout (TGF) board and up to 6 ADC boards and their corresponding filter boards. a series of BPM VME digitizing boards and BLM digitizing hardware. One crate can may also beis referred as a house; however a house may have two crates in some cases for historical reasons.. There are 24 27 houses around the Tevatron ring, each havcontaining one BPM crate to. A crate has, and each house has up to 8 EchoTek boards (which can handle 16 BPMs) and 2 BLM chassis, containing 12 channels each6 EchoTek boards (which can handle up to 12 BPMs) and 2 BLM chassis, containing 12 channels each. Illustrated in Figure 2 is tFigure 2 illustrates the hardware organization of the cards within athe VME crate (see document #XXX 1070 for hardware specifications). The makes and main functions of the boards are briefly described in the following.

The TGF Board is a re-design based on a previous version being used on the Recycler ring. Its functionalities include:

phase lock to the 53.1 MHz Tevatron RF frequency to generate the 74.3466 MHz clock signals for up to 8 ADC boards;

decode the events transmitted through the Tevatron TCLK system to provide advanced arming signals to the crate controller so that the hardware can be configured in time for different measurement types, or present pre-defined requests for data transfers from the crate controller to the online software;

decode the events transmitted through the Tevatron TVBS system to derive accurate timing/triggering signals to synchronize up to 8 ADC boards with respect to the different beam arrivals;

phase lock to the 53.1 MHz Tevatron RF frequency to generate continuous, or train-of-7, diagnostic TTL pulses at 53.1 MHz on the VME backplane to feed the filter boards; The train-of-7 pulses are triggered by the Tevatron turn makers with an adjustable time delay;

7 5/18/23


control the switching of the diagnostic signal relays on up to 8 filter boards so that the 53.1 MHz diagnostic pulses can be directed to the ADCs, or back to the BPM pick-ups, or both.

Figure 2 – Elements within a crate

The Filter Boards are also designed at Fermilab. They perform analog filtering and attenuation so that the 53.1 MHz components of the proton and antiproton signals have approximately the same dynamic range when they reach the ADCs. The filter boards also have mechanic relays to switch the diagnostic signals to different paths as mentioned above.

The BPM ADCdigitizing Bboards have been chosen to be are EchoTek modulel ECDF-GC814/8-ECDF-GC814-FV-A from the Echotek Cooperation. /8-XX, and eEach ADC boardmodule hasdigitizes data from 8 channelchannelsinputs which are paired together to share 4 channel-pair delays. Naturally, channels 1 and 2 are connected to digitize the proton signals from the A and B plates of a BPM pick-up with a certain channel-pair delay so that the digitization, and digital down-conversion and filtering if set up, will start just before the proton bunches arrive at this pick-up, while channels 3 and 4 digitize the antiproton signals from the same pick-up with a different channel-pair delay to account for the different arrival time of the antiproton bunches. Channels 4 through 8 repeat this pattern. (a BPM/BLM input is also referred as channel). A given BPM sensor generates data on 4 channels inputs – the A and B plates for the proton position and the A and B plates for the antiproton position. The digitized outputs can be that results from each channel input is raw ADC counts or digitally down-converted and filtered to extract the strengths of the 53.1 MHz components. In the later case, the output of each channel data

8 5/18/23

CPUTGFimingGenerator

ADCDigital BoardsReceivers

PMCUCD

Tevatron Filter Bboards

Front-end crateTiming Module

Crate Controller BPM Cards

Filter Cards…


and each channel input is actually represented by two components: a real (QI for in-phase) and an imaginary (IQ for quadrature) part. The (Q)I and (I)Q components from the 4 channels channelinputs of a single BPM pick-up are then used by the DA softwarefront-end to calculate the proton and antiproton positions and intensitiesy.

The BLM hardware is described in document #764#764. Notice on figure 2 that the BLM hardware is not connected to the VME back plane. The communication with the crate controller is done via a digital PMC module.

Figure 2 - Elements within a crate

The Crate Controller has been decided to be model MVME2400 from Motorola. It is responsible for the communications between the online software and the TGF, filter and Echotek ADC boards. All controls and data transfers to/from the boards are performed by the crate controller, with the exception of the controls for the diagnostic signal control relays on the filter boards. Their controls are done by the crate controller via the TGF board.

The PMCUCD daughter board is from TechnoBox Inc. It also decodes the TCLK signal and triggers the standard ACNET/MOOC software applications accordingly. Since this board belongs to the Accelerator Controls infrastructure, it will not be discussed any further in this document.

The crate controller board is responsible for establishing the communication link between user applications and the EchoTek modules. All control and data transferred to/from the modules pass through the crate controller, with the exception of the diagnostic signal control relays on the filter card. Their control comes straight from the timing module.

1.3 Requirements on the DA Software

In order to comply with the existing Accelerator Controls software architecture and minimize the time needed for development and debugging, the DA software must meet Because of the following requirementscode base of existing applications, the BPM replacement system must continue to support the existing architecture. This implies:

9 5/18/23


Front-end crate

Timing Module

BLM Hardware (non VME)

Front-end crate

Timing Module


Filter Cards


As of now, different measurement types require different setups in the Echotek boards. The front-end DA software is responsible for setting up the various boards according to user requests coming from the online software.

From the online application perspective, all communication with the front-ends is via

ACNET devices. This includes data readout as well as setting readout and acquisition parameters. Internal diagnostics, however, do not have this constraint.

All communication with the front-ends is via ACNET devices. This includes data readout as well as setting acquisition and readout parameters. Internal diagnostics, however, do not have this constraint.

Data acquiscollectition happens asynchronously from data readout, i.e., the BPMs can be configured to take data continuously on certain triggers, but the data may is not be read out until later. Not all data that is collected is read out. This implies that the DA must have buffers for each measurement type and manage readout requests from the online software.

“Event assembly” is done by the online software, not by the by DA. Therefore a given BPM cratehouse does not need to have any knowledge about any other BPM cratehouse(s). The data sent by the houses will however include ways for having the data synchronized by the online software. That will be provided through time stamps and/or turn counts from the timing boards. The data sent by the cratehouses will however include informationways for having the data synchronized by the online software. That information includeswill be provided through time stamps and/or turn counts from the TGFtiming boards.

Embedded boards will run VxWorks There is one VME processor in each crate running the front-end DA, which will be

responsible for handling multiple BPM and BLM cards. Goals The front-ends should detect state changes via the state devices (in the old system, the

sequencer would notify the crate controller of changes). This will help to reduce the complexity of the sequencer, allow for faster builds and testing of softwareBPM changes, and push the knowledge of BPM behavior to the BPMs themselves.

The front ends software will use the Recycler BPM software and Echotek driver

as a starting point for the software design. The crate controller should run VxWorks.

The front ends software will use the Recycler BPM software and EchoTek drivers as a starting point for the software design. Guarantee time to arm for a TBT request to < 100 msec.

Guarantee time to arm for a TBT request to < 100 msec.

2 Data Acquisition

10 5/18/23


The front-end data acquisition system is located between the online softwareuser applications and the BPM/BLM digitizing hardware (see Figure 3). Any access to information and controls on the electronicsBPM/BLM boards will pass through the front-end processor. The information includes beam positioning data, loss information, calibration data and diagnostics data among other configuration parameters.

Figure 3 - – Data acquisition scheme

The communication between the online softwareuser applications and the front-end processorcard is ACNET/MOOC based, while t.he communication between the front-end processor and other electronics boards (right side on Figure 3) happens through the VME backplane.

During a measurement, the digitized (and digitally down-converted) data is first stored in memory on the Echotek boards and then transferred to the crate controller until all the data has been collected. The data is saved in a set of buffers in the crate controller for later readouts. The SSDN data structures are defined in the following sections and contain data defined by the Tevatron BPM Upgrade Requirements document (#554).

The communication between the front-end and the EchoTek (right side on Figure 3) modules happens through the VME backplane. For the BLMs, data is exchanged through a digital I/O module on a PMC board.

Data coming from the BPM and BLM digitizers are stored into a set of buffers in the crate controller. The depth and number of logical buffers that reside on the crate controller is defined in document #903. The actual physical implementation of the crate controller buffers will be described in the front-end software design document.At least some of the buffers, most notable the turn by turn data, is first stored in memory on the EchoTek boards and then transferred to the crate controller on demand, as the processor/backplane does not have the bandwidth to acquire it in real time. The actual physical implementation of the crate controller buffers will be described in the front-end software design document.

2.1 ArmClock Signals

There are two TCLK decoders in a given house – one PCMCUCD and one IPUCD. The ACNET/MOOC software infrastructure and applications are triggered by TCLK signals

11 5/18/23

Crate Controller

UserApplication

EchoTek/BLM

- Data request- Command


- Position data- Loss data

- Position data- Loss data

Crate Controller

OnlineUserApplicationS

oftware

TGF Filter EchotTek/

BLM



- Position data

- Loss data- Position data

- Loss data


that are decoded by the PMCCMUCD card. The other card will be discussed in subsequent sections. The crate controller can be programmed to read out BPM/BLM values based on a specific TCLK signal (e.g. TCLK $75). The crate controller does not receive BSYNCH TVBS (Tevatron Beam Synch) events. State device transition events are generated when a registered device changes its status, and a central service broadcasts the transition to predefined listeners. As an example of state device transition, the front-end can be waiting on the device V:CLDRST to switch to the “squeeze” state.

The preparation for read outdata acquisition from the EchotTek bocards is signaled by an arm event. An arm event may be triggered by a TCLK event detected by the TGF, or by a state device transition. A state device transition is generated when a registered device changes its status, and a central service broadcasts the transition to predefined listeners. As an example of state device transition, the front-end can be waiting on the device V:CLDRST to switch to the “squeeze” state.

State transitions are not as reliable as TCLK events. For that reason they are not intended to be used as triggers. Table 1 describes a list of originated by events generated by the above triggers. For example, a turn by turn measurement could be armed by TCLK. A list of relevant TCLK eventtriggers, most of which are for arming purposes while a few, e.g. TCLK $75, can be used to signal the crate controller to transmit certain types of data is given in Table 1..

State transitions are not as reliable as TCLK events. For that reason they are not intended to be used as arming events.

Table 1 – TCLK and, MIBS, and TBS clock events associated with the BPM system

Evenent Description Comment$71 TCLK Tev:BPM Prepare for beam Presently issued 0.01 secs after $4D.

Will be issued once before shot setup.$73 TCLK Tev:BPM High field Issued half way up the energy ramp.

Was used to change alarm limits for BPMs.Not needed for the new system.

$74 TCLK Tev:BPM Low field Issued after a $4D.Was used to change alarm limits for BPMs.Not needed for new system.

$75 TCLK Tev:BPM Write profile memory

Trigger times programmed into aCAMAC 070 Card.Used to collect profiles up the ramp.

$76 C1 TCLK

Tev:Tevatron BLM Write display framereset for collider operations

Variable time and trigger.Enabled by sequencer and triggered by $41. Used to reset display frame pointer.

$77 C2 TCLK

Tev:BPM Flash triggerPrepare to accelerate collider beams.

Delayed from the MIBS injection event.Delay is in units of TREV (including fractions of a revolution.)Referenced to $41 event. Used

12 5/18/23


to reset the profile frame pointer.$78 TCLK Tev:BPM Write display

frameVariable time and trigger.Typically set to 2.71 secs after a $4D.

$40 TCLK Tev:Reset for Pbar pbar Inj injection @150GeVv

Start of Pbar injection from MI->Tev.Occurs about 2.7 seconds before the actual injection.

$5B TCLK Collider pbar beam transfer trigger from MI to TevatronMI:Ini MI->Tev p-bars coli

TCLK echo of MIBS $7B.MI->Tev transfer of pbars happens on the MIBS $7B which is about 2.7 seconds after the $40.

$4D TCLK Tev:Reset pProton Inj injection @150Gev

Start of proton injection from MI->Tev.Occurs about 2.7 seconds before the actual injection.

$5C TCLK Collider proton beam transfer trigger from MI to TevatronMI:Ini MI->Tev proton coli

TCLK echo of MIBS $7C.MI->Tev transfer or protons happens on the MIBS $7C which is about 2.7 seconds aafter the $4D.

$47 TCLK Tev:Beam has been aborted TCLK event generated when the BSSB pulls the Tevatron abort.TCLK event which happens on every time the Tevatron abort is triggered.

$4B TCLK Tev:Abort clean up TCLK event used to trigger the Tev abort kickers and intentionally remove beam.(Every time beam is removed from the Tevatron either a $47 or $4B is issued.)TCLK event which happens on every time the Tevatron abort is triggered.

$7C? TVBS MI:Ini MI->Tev proton coli Tevatron Beam Sync event at injection. Similar toDerived from the MIBS $7C.

$xx77?DA TVBS

Trigger TBT data collection.

Tevatron Beam Sync used to trigger TBT data collection. Used to synchronize all BPMs to the same turn.

2.2 Timing and Trigger Signals

The DA system will be configured to operate in one of two basic running modes: repetitive and one-shot. The former will be used for closed orbit measurements, while the later will be used for the various types of TBT measurements.

13 5/18/23


Figure 4 – Timing for closed orbit mode

For closed-orbit measurements, the front-ends do not need to be synchronized to the same turns/bunch passings, they only need to cover the same length in time. In this mode, the TGF simply decimates the Tevatron revolution/turn markers, generates an interrupt to inform the crate controller of a pending data acquisition, applies appropriate time delays to account for the different bunch arrivals at different BPM pick-ups so that data from all the BPMs have the same phase, and generates trigger (SYNC) signals for the Echotek boards. When the pre-set number of samples (burst counts) has been collected, the first Echotek board will issue a collection-done interrupt to notify the crate controller for data transfer. The timing relations are visualized in Figure 4.

For TBT measurements, the front-ends in all the houses will need to be synchronized to the same specific turns, so that the measurements they make correspond to the same turns. This is achieved by setting the TGF to wait for a particular “start_event”. Upon the occurrence of this “start_event”, the TGF generates an interrupt to inform the crate controller of a pending data acquisition, then repeats the following steps for the desired number of turns: wait for the next “turn_event”, be it the turn markers, apply appropriate time delays and generate trigger signals for the Echotek boards. When the pre-set number of triggers has been received, the first Echotek board will issue a trigger-counter interrupt. These timing relations can be seen in Figure 5. The descriptions of the relevant TVBS events are listed in Table 2.

It should be noted that in a given running state of the Tevatron, the time delay from the Tevatron turn marker (TVBS $AA) as seen by the TGF till the actual bunch passing is fixed at each BPM location. In order to ensure that the ADCs are triggered at the same time relative to the actual bunch passing of the same turn, 4 layers of delays are implemented. These delays are global delay, house delay, Echotek board delay and channel pair delay. For different states of the Tevatron, especially if the beam is injected

14 5/18/23

Turn Marker

TGF Turn Modulus

TGF Interrupt

TGF Trigger Outs

DataECDR Collections

CollectionDone Int

VME Transfer

Repetition Period

Data Processing


to different buckets, these delays may need to be adjusted if the same timing relationship is required.

Figure 5 – Timing for TBT modes

Table 2 – TVBS events associated with the BPM system

Event Description Comment$AA TVBS Tev:Beam $7C TVBS MI:Ini MI->Tev proton coli Tevatron Beam Sync event at injection.

Derived from the MIBS $7C.$DA TVBS Trigger TBT data collection. Tevatron Beam Sync used to trigger TBT

data collection. Used to synchronize all BPMs to the same turn.

2.3 BPM Measurement types

2.4 The EchoTek cards can be configured to return different types of measurements. The front-end DA software is responsible for setting up the cards according to user requests coming from the online software. The different measurement types to be handled by the software are:In addition to the modes, there are two different types of measurements that can be made from the data in the digitizing cards. The data types are:

Closed Orbit Measurements (aka Frame data). Closed Orbit Measurements. The Closed Orbit is a measurement of the average position of the beam with the betatron motion averaged out. This is the position of the beam as measured by the EchoTek boards while making closed orbit measurements. For the Closed Orbit Measurements the BPM signal

15 5/18/23

Turn Marker

Bsync Start Event

TGF Interrupt

TGF Trigger Outs

DataECDR Collections

TriggerCounter Int

VME Transfer

Desired Number of Turns

Data Processing


is filtered in order to remove the betatron motion, but the synchrotron motion is not filtered out.Average Closed Orbit Measurements. The Average Closed Orbit is a measurement of the average position of the beam with both the betatron motion and synchrotron motion averaged out. This is different from the Closed Orbit Measurement since the beam position is essentially “averaged” over a longer time in order to eliminate the beam motion due to synchrotron oscillations. (In the Tevatron the synchrotron frequency is about 30 Hz at its lowest, so the beam position should be “averaged” over 10 3 synchrotron periods or for about 0.3 1 seconds.)Injection Closed Orbit Measurement. The injection closed orbit is a closed orbit measurement of the beam immediately after injection of beam into the Tevatron. The closed orbit is determined from the 8192 measurements taken during the injection TBT. A simple algorithm for determining the Injection Closed Orbit is to take the average of all 8192100 positions. A more sophisticated (but as yet undetermined) algorithm might be used.Single Injection First Turn Measurement. This is the measurement of the beam position and intensity on a single pass of the beam as it enters the Tevatron from the injection beam lines.Turn by Turn (TBT) Measurement. The TBT Measurement is a sequence of 8192 sSingle tTurn mMeasurements. For this measurement all of the BPMs are synchronized to begin collecting the sSingle tTurn data on the same turn, and will measure the position of the beam on 8192 consecutive turns without missing any turns.Turn Data (or snapshot) is the instantaneous single value (i.e., not averaged over n readings) of the sensors once the trigger is receivedAsynchronous Injection Measurment. This is the failsafe injection position measurement mode. If beam is not injected into the correct bucket, and beam fails to make many revolutions in the Tevatron, none of the previous measurement types will produce a reliable position. This measurement mode is wideband and covers all of the beam revolution through multiple revolutions. Data is analyzed off-line to determine injection positions.

It is important to note that for turn every measurement except for Asynchronous Injection Measurments, all BPMs are triggered off the same bunch. However, for closed orbit measurements, the specific bunchesmeasurements, the specific bunch used in the averaging can be different across BPMs.one trigger causes the measurement to take data for multiple bunches/multiple revolutions.

The data acquisition system must support buffers of N events for both of these data types. For turn buffers, the arrays are of N consecutive measurements (i.e., Turn by Turn). On the other hand, closed orbit buffers are built by N triggers of a specific type.

The measurement types require different setups in the EchoTek modules, and, therefore have a time penalty associated with them. In general, one needs to switch data acquisition modes, to acquire a different type of measurement.

16 5/18/23


2.5 BPM Data Acquisition Modes

Corresponding to the various measurement types it needs to handle, There are different modes ofthe BPM data acquisition system has a few different operation modes. These modes are mutually exclusive due to the need for specific necessity to configurations ofe the triggering and filterings and timing in the EchotTek boardmodules for a specific mode. These modes are:

Idle Normal operationClosed OrbitInjectionIdle Injection Turn by Turn First Turn Asynchronous Injection Diagnostic Calibration Diagnostic

where Idle and Closed Orbit are two default modes. When not in any of the other modes, which default mode the DA system should enter is dictated by the Tevatron state device V:TBPMM – Tevatron BPM Mode. The OOC (??) will set this device to “closed orbit” after some fixed delay from a proton injection event (TCLK $4D), will change it to “no beam” after a Tevatron clean-up event (TCLK $4B) to signal the Idle mode.

These modes are elaborateddescribed in more detail in the following sections.

2.5.1 Idle Mode

The Idle mode is the “no-function” mode of the BPM operation that occurs when there is no beam in the Tevatron. During this mode, all operational data buffers are frozen, and the TGF should be set to wait for TCLK $4D. Upon the detection of TCLK $4D, the TGF interrupts the crate controller and the system should transit into the First Turn mode.

2.5.2 Normal Closed Orbit Modeoperation

This is one of the default modes of operation when there is beam in the Tevatron and the data acquisition system is not requested to take any other types of measurements(the other being the Idle mode), and controls the filling of several different data buffers.

2.5.2.1 EchotTek Setup and Timing

17 5/18/23


I n closed orbit mode, tThe EchotTek bocards will beis set up to operate in the split I-Q mode for this configuration. Two of the 4 Graychip sub-channels are of a GC4016 chip processing the in-phase and quadrature signals in parallel, and their outputs are mergecombinding them into one stream of interlaced I’s and Q’s, 16 bits eachoutput. The CIC is set to decimate by 1024 making the total decimation rate is set tto be 4096. This corresponds to a PFIR output data rate of about 18 kHz while the re-sampler is by-passed. Both CFIR and PFIR are set to take rolling averages, with 9 and 23 tabs respectively. The PFIR dictates the bandwidth of the system in this configuration, and it is set up as a rolling 23 point average. Combining the CIC, CFIR and PFIR, the overalled with the decimation rate, this gives a 3 dB final bandwidth isof about 700 Hz (see Figure 6), which is dominated by the PFIR.

The GC4016raychip has a latency of 7 PFIR output data cycles before any data reaches the memory and one additional PFIR output data cycle delay for every two PFIR taps before the PFIR filter output settles. For the presentis configurationconfiguration, the output stabilizes after 20 output clock cycleticks. The system is currently set to takeburst 24 PFIR outputs and skip the first 23 to minimize the data volume to be transferred over the VME backplane. The points for a total data acquisitionprocessing time is about of 1.3 ms per trigger.

18 5/18/23


The position measurements are triggered at a 500Hz rate. The 500Hz clock is sourced by the

Figure 6 – GC4016 frequency response for the closed orbit mode

2.5.2.2 Triggering

The measurements are triggered at a 500 Hz rate. This rate is sourced by the TGF board through a decimate-by-N counter to down-sample the 47 kHz Tevatron turn marker (TVBS $AA). The value of N, and thus the trigger rate, can be adjusted through the turn modulus/decimation register on the TGF board. At 500 Hz, the DA system has about 200 us idle time between triggers.

2.5.2.3 Data Processing

trigger module. The clock is derived from TVBS $AA triggers. The trigger card uses a divide by 94 counter to convert the 47kHz $AA triggers to 500Hz triggers. Each closed orbit trigger interrupts the processor to inform the system that a measurement is taking place. The Echotek module interrupts the processor once the burst count measurement is completed, so the processor can safely retrieve for the measurement data.

After the Echotek boardsmodule haves completed data acquisitionits measurement, the crate controller will read out, through VME single reads, oneprocessor accesses the final I-Q pair (the 24th PFIR burstpoint) from each channel, 4 pairs for each BPM in the crate.

19 5/18/23


The proton contaminations on the antiproton signal will then be removed from the raw antiproton I’s and Q’s (A and B plates) according to:

where subscripts P and Pb denote proton and antiproton signals respectively, and are the in-phase and quadrature components of the coupling coefficient.

The raw data from each I-Q pair is stored in a 1024 point deep circular buffer. Each channel has a separate buffer. Each I-Q pair then goes through a correction process. The first correction deconvolves the proton component of the pbar signal and the pbar component of the proton signal in [or from?] the raw I-Q values. Once the proton and pbar signals have been separated, tThe modulus of each channel (M) is then calculated:

where and are the gain and offset of the electronics. . The inputs to an Echotek module are configured so that the first two channels are connected to opposing plates on the proton end of a single BPM. The next two channels are connected to the corresponding opposing plates on the pbar end of the same BPM. The next four channels are copies of the first four channels, but from a different BPM. Finally tThe beam positions ( ) and intensities ( ) can be determined according to:

where is calculated by dividing the difference between the modulus of two opposing plates on one end by the sum of the modulus of the two opposing plates. The ratio is multiplied by a scale factor to convert the unit-less quantity to millimeters (nominally 26 mm), is the mechanical offset that was surveyed relative to the BPM’s electrical center before the BPM was installed in the ring.

For each BPM, the 2 . This positions ( ) and 2 intensities ( ) are put into a data structure together with the 4 raw I and Q pairs (see data structure section) is then offset by two corrections, an electrical offset that compensates for differences in signal path attenuation, and a mechanical offset that was surveyed relative to the BPMs electrical center before the BPM was installed in the ring. This data structurefinal corrected position is then stored in a 1024 point deep circular buffer, the (Fast Aabort buffer, and propagates to the other buffers discussed later). Also, the sum of the two moduli is stored with the position in the same circular buffer. These are:2.5.2.4 Data Buffer Organization

In closed orbit mode, the DA software maintains the following data buffers:

20 5/18/23


Figure 1: Buffer diagram for closed orbit measurments.

Fast Aabort buffer -– circular buffer, 1024 points deep. One element in the fast abort buffer is referred to as a frame. The crate controller takes measurements data from all BPMschannels inputs on all EchoTek modules every 2 milliseconds, and puts them into the fast abort buffer.

The process stops on Tevatron aborts (TCLK $47 or $4B), and re-starts automatically after the Injection mode.

Slow Aabort buffer – circular buffer, 1024 points deep. Ddata is copied from the newest frame in the fast abort buffer every n 500 readings where n the 500 is configurable. This is also a circular buffer that has a depth of 1024 frames.

Profile Fframe buffer – FIFO, 128 points deep. dData is copied from the latest frame in the fast abort buffer every time a TCLK $75 (shot data event) is received, i.e. each index in the profile frame corresponds to a particular shot data event. The profile frame buffer is a FIFO buffer with a depth of 128 frames. If the profile frame buffer overflows, new values will be discarded and an alarm condition will be flagged -- o. Nnly one alarm will be sent per crate. ote that indices in the profile frame have specific meaning. If a $75 event arrives when in a mode other than Normal OperationClosed Orbit, then this particular profile frame needs to be filled, (maybe with a bad status.) . Only one alarm will be sent per crate.

Display Fframe buffer – single frame. Ddata is copied from the latest frame in the fast abort buffer every time a TCLK $78 (display event) is received. This buffer is not an array, but is just a single frame.

21 5/18/23

Digital FilterMode Switch Closed Orbit Mode

FastAbortBuffer

SlowAbortBuffer

Profile Frame Buffer

DisplayFrameBuffer

- Switch activatedevery 2ms Switch deac-tivated on abort $47 or $4B- Switch reac-tivated after 1st turn acquisition

Switchactivatedby TCLK $75shot dataevent

Switchactivatedby userconfigur-able event ($78)Data at

end of FIFO is dicardeed

Data at end of FIFO is dicarded

FIFO full generates error. Pointer reset on TCLK $C2.

1024 pts

1024 pts 128 pts

All Closed Orbit Mode switches are interrupted by TBT mode.

TBTMode

Switch activated every 2ms

FastTimePlot

Buffer

UserData

BufferData at end of FIFO is discarded

128 pts

Switchactivatedby userconfigur-able event

- Switch changed by change in Tevatron state device that listens to $4B and $5C events.

- Switch activatedevery 1sec Switch deac-tivated on abort $47 or $4B-Switch reac-tivated after 1st turn acquisition


Fast Ttime Pplot (FTP) buffer(s) – data is copied from the latest frame in the fast abort buffer every 2 milliseconds. There is no depth to this buffer, but since fast time devices plot only single values, it will be a series of devices to plot:

o A particular BPM’s proton positiono A particular BPM’s antiproton positiono A particular BPM’s proton intensityo A particular BPM’s antiproton intensityo A particular channel’s input’s I valueo A particular channel’s input’s Q valueo Sum signal for each channel (magnitude of A + magnitude of B)

Snapshot Data request – the most recent frame in the fast abort buffer is copied to the request’s buffer.

Figure 7 – Buffer diagram for closed orbit measurements.

Requests for snapshot (single turn) data return the most recent frame in the fast abort buffer.

WhenIn the event that a TCLK $47 (abort) or TCLK $4B (no beam left in machine) is received, the DA system shouldnormal operationclosed orbit mode will:

22 5/18/23

Digital FilterMode Switch Closed Orbit Mode

FastAbortBuffer

SlowAbortBuffer

Profile Frame Buffer

DisplayFrameBuffer

- Switch activatedevery 2ms Switch deac-tivated on abort $47 or $4B- Switch reac-tivated after 1st turn acquisition

Switchactivatedby TCLK $75shot dataevent

Switchactivatedby userconfigur-able event ($78)Data at

end of FIFO is dicardeed

Data at end of FIFO is dicarded

FIFO full generates error. Pointer reset on TCLK $C2.

1024 pts

1024 pts 128 pts

All Closed Orbit Mode switches are interrupted by TBT mode.

TBTMode

Switch activated every 2ms

FastTimePlot

Buffer

UserData

BufferData at end of FIFO is discarded

128 pts

Switchactivatedby userconfigur-able event

- Switch changed by change in Tevatron state device that listens to $4B and $5C events.

- Switch activatedevery 1sec Switch deac-tivated on abort $47 or $4B-Switch reac-tivated after 1st turn acquisition


freeze Freeze data in the fast and slow abort buffers, the profile frame buffer, and the display frame buffer. and slow abort buffer,

, and fFill the FTPf buffers with a status indicating no beam. will AWill acquire a few more measurements and fill data points in aAfter the fast

abort buffer, and then freeze it. D isable all data acquisition modes until the next prepare for beam TCLK event is

detectedChange the mode of operation to the Idle mode.

2.5.3 Turn by Turn

During turn-by-turn operation, the BPM system samples the position of the beam at every BPM, at every turn for 8192 turns. Data from these arrays of measurements is analyzed to determine Tevatron lattice information such as beta functions, phase advance, local coupling, etc. Normally, for turn-by-turn measurements, there is only one proton bunch in the machine, and some kicker magnet is fired synchronously with the trigger of the turn-by-turn measurement.

In turn-by-turn mode, the Echotek boards will also be running in the split I-Q fashion. The total decimation rate is however changed to 16 for a wide bandwidth. The corresponding data output rate is about 4.65 MHz. Both CFIR and PFIR are again set to take rolling averages, but with 11 and 13 tabs now. The combined overall 3 dB bandwidth is about 360 kHz (see Figure 8), which is again dominated by the PFIR.

23 5/18/23


Figure 8 – GC4016 frequency response for the turn-by-turn mode

For this configuration, the output stabilizes after 14 output clock ticks, the system will therefore be set to take 16 PFIR outputs and skip the first 15 for every turn.

The turn-by-turn mode can occur at any user specified arm and start events. For example it can be armed by a TCLK event $77, started by BSYNC event $DA which is derived from the TCLK $77, and triggered by the Tevatron turn markers (BSYNC event $AA). The time advance from the arm event to the start event must be long enough to allow time for the system to change mode before triggering.

Upon the successful completion of a turn-by-turn daq, the data will be transferred to the crate controller through DMA. The positions and intensities of the proton bunch at each BPM location will be calculated in the same fashion as in the closed orbit mode. The data structure will then be stored in a 8192 point deep TBT buffer for later access.

After a turn-by-turn measurement, it is very important that the DA system change to closed orbit mode as soon as possible. Due to the large data volume, there is inevitably a dead time of about ?? ms. Studies are being carried out to see whether: a) the FPGA firmware can be modified to accommodate multiple operation modes in the same time so that there is no need for mode change at all, for example two of the 4 sub-channels run in turn-by-turn mode, while the other 2 sub-channels run in the closed orbit mode; or b) the

24 5/18/23


electronics can run in turn-by-turn mode in a repetitive fashion and the crate controller calculates the closed orbit by averaging, so that a mode change would only involve changing the number of turns to trigger and probably changing the time delays with the TGF.

2.5.4 do Do nothing to the turn by turn buffer data

2.5.5

2.5.6

2.5.7 Idle

2.5.8 The Idle mode is the “no-function” mode of the BPM operation that occurs when there is no beam in the Tevatron. During this mode, all operational data buffers are frozen. The Echotek modules are programmed to be prepared for first turn injection. The first TCLK $4D detected by the system in Idle mode changes the mode of operation to the Injection mode.Upon receipt of a TCLK $71 (prepare for beam), if the DA is running, any acquisition mode is halted. If there is no DA active the fast and slow abort buffers are cleared, the profile frame buffer cleared and the pointer is reset to zero, injection mode is enabled, and normal operation mode (re)started. When restarting in normal operation mode, the DA will flag each data point with a low intensity threshold status until real beam is actually detected. The TBT buffer is not cleared on the prepare for beam event.Upon receipt of a TCLK $71 (prepare for beam), if the DA is running, any acquisition mode is halted. If there is no DA active, time, the fast and slow abort buffers are cleared, the profile frame buffer cleared and the pointer is reset to zero, injection mode is enabled, and normal operation mode (re)started. When restarting in normal operation mode, the da will flag each data point with a low intensity threshold status until real beam is actually detected. The TBT buffer is not cleared on the prepare for beam event.

[2.5.9] InjectionFirst TurnFirst Turn

The first turn mode is a special case of the turn-by-turn mode. Itoperation is intendedused to capture the immediate position of the beam at each BPM location as the beam travels its first revolution around the ring immediately after injection, and obtain the closed orbit while the injection bumps are still active. Theise position information

25 5/18/23


isis used to diagnose errors in injection position and angle in order to tune the magnets in the injection beam lines.

The key to successful first turn acquisition is a well timed trigger and timely conversion of closed orbit data quickly after injection. The closed orbit data must be collected before there are changes to the Tevatron injection lattice. This is a relatively short period of time, becauseSince the “injection bump” magnets that are used for each injection are only activated briefly, it is not feasible to take a one-turn turn-by-turn measurement, then re-configure the electronics and switch to closed orbit mode to catch the injection closed orbit. Instead, the DA system will take a normal 8192-turn turn-by-turn measurement, retrieve the first turn position, and obtain the injection closed orbit by simply averaging over the first 100 turns in the crate controller. A more sophisticated (but as yet undetermined) algorithm might be used.

The first turn mode is armed if the TGF receives a proton injection event (TCLK $4D) and the Tevatron state device indicates “no beam”. The start event for the TGF is TVBS $7C which corresponds to the kickers being fired for main injector to Tevatron transfer. The TCLK $4D occurs about 2.5 seconds before TVBS $7C, allowing ample time for the DA system to configure the electronics.

The first turn measurement will be stored in the First Turn buffer for later readout.The Greychip must operate at a high bandwidth, initially, in first turn acquisition mode. Once the data is acquired, it must switch back to closed orbit mode as quickly as possible. It is important to compare the first turn orbit to the closed orbit with the injection bumps activated. There is some question as to whether all of the BPMs can be configured to run in closed orbit mode quickly enough to measure the closed orbit before the injection bumps are deactivated. To be safe, instead of trying to change the mode of operation quickly after the first turn is acquired, the system will be placed in a first turn/turn-by-turn mode. It will continue to take wideband position measurements every turn, for 8192 points. From this data, the first turn position will be retrieved, and the data will be averaged by the processor to determine an injection closed orbit.

The EchoTek card is set up in split I-Q mode for this configuration. Two of the Greychip channels are processing the in-phase and quadrature signals in parallel and combining them into one output. The total decimation rate is set to 16. This corresponds to a data output rate of about 4.65MHz. The PFIR dictates the bandwidth of the system is this configuration, and it is set up as a rolling 13 point average. Combined with the decimation rate, this gives a 3dB final bandwidth of about 360kHz. The Greychip has a 7 output clock tick latency before any data reaches the memory. After that, every two PFIR taps requires one output clock tick before the taps contribute to the output. For this configuration, the output stabilizes after 14 output clock ticks. The system will be set to burst 20 points for a total processing time of 4.3s per trigger. The Greychip will be programmed to only output the last point into memory to preserve the total EchoTek memory and achieve 8192 point storage before data is transferred to the processor.

26 5/18/23


The default mode of operation for the system is dictated by a Tevatron states device V:TBPMM (Tevatron BPM Mode). There are two possible states for this device: closed orbit data collection, or no beam. An OOC will drive the BPM states device. When the OOC sees a clean-up event (TCLK $4B) it will change states to no beam. It will set itself to closed orbit mode after some fixed delay from a proton injection event (TCLK $4D). The system needs time to prepare all of the EchoTek modules and trigger cards for first-turn measurement. It will arm itself for first turn measurement if it receives a $4D and the BPM states device is in no beam mode. The $4D occurs about 2.5 seconds before injection and is enough time to prepare the system for injection turn-by-turn acquisition.

2.5.9[2.5.10] Asynchronous Injection

In this mode the Echotek boards should be configured to take 262144 raw data samples (16 bit) for each channel. This is the maximum allowed by the internal buffers of 128k 32-bit words. At a sampling frequency of 74.3466 MHz, these samples can cover a time window of about 3.5 ms.

The TGF should be set to trigger at the first Tevatron turn marker after a specific start event. The global (coarse) delay should be used to make sure the 3.5 ms window covers the first turn. Fine (short time) delays like house delays, Echotek board delays and Echotek channel pair delays can be used but not required.

The raw data can be used online to determine the aggregate time delays for each BPM location through certain pattern recognition. It can also be used offline to calculate the beam positions and intensities so as to help diagnosing the injection beam lines.Triggering is critical for accurate acquisition of first turn data. There is a Tevatron beam synch event (TVBS $7C) that corresponds to the same main injector beam sync event that fires the kickers for main injector to Tevatron transfer. This event will always occur at the same time relative to the TVBS $AA marker. It will move relative to the injected beam if the injected beam goes to different buckets in the Tevatron. The BPM trigger cards are configured to listen for the $7C event and start a train of 8192 $AA based sync triggers for the EchoTek card. We can assume that the delay timing of the $AA markers is set so that the EchoTek cards sample bunch 1 correctly every time there is a trigger. However, it is also important that the memory index that refers to the first turn of beam be consistent from house to house. The way to accomplish this is to strategically delay the $7C event on a house by house basis, so that the BPM at F0 is the first BPM to see an $AA trigger after a $7C and then sequentially from F0-downstream to F0-upstream through F, A, B, C, D, and E sectors.

After the 8192 samples have been taken, the EchoTek card interrupts the processor to tell it that it completed the measurement. It is very important that the system be returned to closed orbit mode as soon as possible. My proposal for minimizing the amount of time between first turn acquisition and closed orbit is to set up the Greychip to operate with all 4 channels in split I/Q mode. One pair of channels is set-up for closed orbit decimation, and one set is set up for turn-by-turn decimation. During closed orbit operation, the turn-by-turn channel output is deactivated. After an abort, the processor deactivates the closed

27 5/18/23


orbit outputs and activates the turn-by-turn outputs. After the measurement is complete, the processor reverses the process and reactivates the trigger card for closed orbit sample rates. This keeps the integrity of the turn-by-turn data on the EchoTek memory while closed orbit measurements take place, allowing the processor to retrieve the data at its earliest convenience.Injection mode has the highest priority of all data acquisition modes and will supercede supersede any other acquisition mode in progress. It is a specialized mode whichmode that needs to take turn by turn data followed quickly by a closed orbit measurement. It happens automatically on receipt of a TCLK $4D (proton injection event). (This might be extended in the future to occur on a $40 (pbar injection event) as well...) There is a 2.7 second delay between the TCLK $4D event and the trigger to actually take the data (Bsynch BSYNC injection event). The actual mode switch will occur somewhere in this interval instead of the beginning to allow normal mode monitoring to run as long as possible.

Injection mode has the highest priority of all data acquisition modes and will supercede any other acquisition mode in progress. Shortly after the TCLK $4D is received, all other modes will halt and the EchoTek modules will arm themselves waiting for the corresponding trigger, $5C (injection event main injector/tev beam synchBSYNC). Once a turn by turn measurement of 8K consecutive turns has been completed, the crate controller will then calculate a closed orbit measurement using the data from the turn by turn buffer. The crate controller knows that the readout is complete after receiving an interrupt from the timing card signaling one of the EchoTek cards is ready to be read out.

Once the calculation is complete, the mode automatically returns to normal operation. If the corresponding BSYNC does not occur in a specified amount of time, an error status will be returned and the normal operation mode restarted.

Injection mode needs to be disabled and reenabled again on request because there are times when closed orbit data is preferred during proton injection.

Note that for a given BPM, the turn by turn buffer on the EchoTek board will have the data from the first turn in a fixed slot in the array, but not necessarily the first element in the array (e.g., 3). This needs to be configurable on a BPM by BPM basis.

28 5/18/23


2.5.10[2.5.11] Note that for a given BPM, the turn by turn buffer The enabling and disabling of on the EchoTek board will have the data from the first turn in a fixed slot in the array, but not necessarily the first element in the array (e.g., 3). This needs to be configurable on a BPM by BPM basis (or is it a channel basis?) Injection Mode is done with a state device T:BPINJE.

2.5.11[2.5.12]

2.5.12[2.5.13] How do we know when readout is complete?

2.5.13[2.5.14]

2.5.14[2.5.15]

2.5.15[2.5.16] Turn by turnTurn by Turn

2.5.16[2.5.17] The turn-by-turn mode of operation for the Tevatron BPMs is very similar to the first turn mode of operation. The major difference between the two modes is that first turn mode occurs only when the first protons are injected, and turn-by-turn acquisition can occur at any user specified event. During turn-by-turn acquisition, the BPM system samples the position of the beam at every BPM, at every revolution for 8192 turns. Data from these arrays of points is analyzed to determine Tevatron lattice information such as beta functions, phase advance, local coupling, etc. Normally, for turn-by-turn measurements, there is only one proton bunch in the machine, and some kicker magnet is fired synchronously with the trigger of the turn-by-turn measurement.

The EchoTek card is configured in the exact same way for turn-by-turn mode and first turn mode. The mode is armed by a TCLK event $77. A separate Tevatron beam synch event (TVBS $DA), that is derived from a delayed TCLK $77, triggers the system to start taking data on the next turn marker. The delay must be set long enough to allow time for the system to change modes before triggering. The $DA trigger should be timed the same way as the $7C trigger in the first turn acquisition mode. This ensures consistent correlation between data arrays of different houses.Turn by turn mode is very similar to injection mode in that an 8K consecutive turns are taken when a turn by turn request is made. A turn by turn request comes through an ACNET SETDAT request, and contains any user specification for the measurement.

The turn by turn mode is armed with a TCLK event $77 and the data collection is started on a TeV BSYNC (event $77.). The crate controller is informed that the measurement is complete by an interrupt from the timing system (same as the injection mode).

How do user’s make a TxT request? How do we know when complete?

29 5/18/23


Note that for a given BPM, the turn by turn buffer on the EchoTek board will have the data from the first turn in a fixed slot in the array, but not necessarily the first element in the array (e.g., 3). This needs to be configurable on a BPM by BPM basis basis (or is it a channel basis?) .How do we know when readout is complete?

Calibration Mode – we don’t know what this means yet

2.5.17[2.5.18]

The calibration mode is basically a normal run mode where data collected is tagged as calibration data. These data specially marked is used on the offline processing for defining the calibration constants to be used by the front-end when calculating the position of the beam.

The user via online software sets the calibration mode. That information is passed to the front-end DAQ system through ACNET variables. All data read out from EchoTek cards are tagged as calibration data, until the calibration mode is disabled.

2.5.18[2.5.19] Injection mode is disabled.

2.5.19[2.5.20] Diagnostic Mode – we don’t know what this means yet

When there is no beam in the machine, the crate controller can be configured to set up one BPM channel to receive a 53MHz tone while remaining channels in the BPM can be digitized and analyzed (can be readout as Turn-by-Turn data with header set to diagnostics). The controller should be able to handle this type of request for one BPM in the system.The first level of diagnostics for the system involves verifying the signal path of the detectors, cables, filters, and A/D converter. The tools for performing this diagnostic are the diagnostic signal and the filter card relays. The diagnostic signal is a 53MHz TTL waveform that is distributed to every channel on the filter card. There are two filter card relays per channel. These relays can be configured for four possible states: diagnostic signal deactivated, diagnostic signal direct to EchoTek input through attenuator and filter, diagnostic signal direct to detector, and diagnostic signal to both EchoTek input and tunnel. Sending the signal in both directions will reduce its intensity compared to the direct connections.

There are three modes of EchoTek operation required to take advantage of the test signal diagnostics. First, the modules can be set up in raw A/D mode. This mode bypasses the Greychip and routes the A/D data directly into memory. The memory values can be inspected to insure that some reasonable signal is getting into the EchoTek module with the diagnostic signals activated. Second, the modules can be set up in standard closed

30 5/18/23


orbit mode. This mode can be used when the signal is passed through the detector before reaching and EchoTek input. Third, the modules can be set up in a reduced gain closed orbit mode. This mode is required for when the diagnostic signal goes directly through the attenuator and filter and into the EchoTek module. The continuous diagnostic signal will have a much higher fundamental frequency component than the beam, and the standard closed orbit configuration will saturate in the Greychip processing.

There are four different measurements that can be made to verify the operation of a channel. First, isolate the channel from the pickup and the diagnostic signal and verify a zero amplitude result in standard closed orbit configuration. Second, switch the diagnostic signal into the input channel directly in reduced gain closed orbit configuration. Verify proper operation of filter, attenuator, and A/D. Third, activate diagnostic signal into input channel and detector cable to verify operation of A/D with different amplitude signal. This operation also requires the reduced gain closed orbit configuration. Fourth, connect input channel directly to tunnel and connect opposing channel diagnostic switch (channel connected to same BPM plate but opposite side) to tunnel cable only. Verify A/D with different amplitude signal and verify cable, detector, attenuator, and filter chain integrity.

The diagnostic application program should have the ability to control the filter board switches individually. To simplify the configuration to the user, there should be four possible relay configurations: diagnostic off, diagnostic to EchoTek only, diagnostic to tunnel only, diagnostic to EchoTek and tunnel. The application should also allow the tests above to be generated automatically for a single house upon a user request. Only the magnitudes of the different channel measurements need to be recorded. These measurements are compared to baseline measurements for possible variations that are out of tolerance. Those measurements that are out of tolerance by more than 1% in magnitude are flagged as potentially requiring a new calibration. The user also has the option of saving the results as the new baseline.

The next level of diagnostics for the system is monitoring and control of the VME crate. We will take advantage of the RS232 interface on the crate to control and monitor the voltage levels and fan speeds on each of the crates. An Ethernet to RS232 adapter will be utilized as the communication bridge to the internal crate monitoring and control. The adapter will be powered independently from the crate to allow a remote user to power down the crate without losing communication to the adapter. The remote control of the crates will include the ability to perform a SYSRST on the backplane, a SYSFAIL on the backplane, and power down the crate. The application for controlling and monitoring the crate will be T?? (title?).

A third level of diagnostics for the system is the verification of proper events and triggers. There are four types of events that need to be monitored for diagnostics purposes: state transitions, TCLK events, the TVBS $AA marker, and the other TVBS events. The system needs a means of monitoring the order of critical events that the timing card and processor will react to. The timing card will keep a circular buffer of the last 256 events (TCLK, TVBS $7C & $DA, measurement complete, etc.) that it uses to generate interrupts or triggers, excluding TVBS $AA events. The timing card does not

31 5/18/23


need to record all TCLK events, only the events that it uses to generate interrupts to the processor. The processor, in turn, will have a circular buffer of the last 256 events of interrupts that it receives from the timing card as well as any other events that it will cause a change in system configuration (change in state device V:TEVBPM, request for change into diagnostic mode, etc.). These two buffers will be accessible from the Tev BPM diagnostics application and will be used to verify that the processor is receiving the proper interrupts and that the events are happening in the proper order. The final event diagnostic will be $AA marker verification. This will be done on every turn-by-turn and first turn data acquisition. While triggering the turn-by-turn measurement, the timing card will verify that the $AA markers are being triggered every turn by comparing the time between markers with a divide by 1113 counter clocked by the 53 MHz. If a trigger is missed, the turn number that has a skip is loaded into a buffer. The data user can then reconstruct the proper sequence of data for analysis.

The fourth level of diagnostics is verification of the EchoTek and Greychip setup. The diagnostic application will be able to override the default EchoTek configurations and force it into closed orbit mode, turn-by-turn mode, or raw A/D mode. There will be a means to override the trigger card configuration as well, so that the system can be configured to trigger the EchoTek module on after an arbitrary TCLK event and delay. The software will retrieve data from all active channels of the Greychip, from up to two EchoTek channels. The data from separate Greychip channels will be organized and plotted after each trigger. The application will also have the means for saving channel data for offline analysis, either by saving to a file, or e-mailing the data to a users e-mail account.

The final level of diagnostics is the ability to halt and examine all of the processor data buffers. There will be an option on the diagnostic application page to halt data acquisition into the buffers for the EchoTek channels selected (up to two). The application will then allow comparisons between the processor buffers and any associated ACNET variables that mirror the buffers. Discrepancies will be flagged.

When there is no beam in the machine, the crate controller can be configured to set up one BPM channel to receive a 53MHz tone while remaining channels in the BPM can be digitized and analyzed (can be readout as Turn-by-Turn data with header set to diagnostics). The controller should be able to handle this type of request for one BPM in the system.

2.6 BLM Data Acquisition Modes

The BLMs on the other hand are much simpler. There is no need for mode switching for BLMs, and there are no turn-by-turn requirements. Internal sBLM oftware timers periodically trigger the BLM read outvalues are read out periodically on triggers of the type described above. The trigger periodicity is given by the BLM integration time, which according to the document #764, is a 63 ms time constant.

32 5/18/23


Every 63 ms a new BLM channel value is read out and stored in an internal buffer, dimensioned to hold enough data for a given time frame. The online software can request data from the front-end DA BLM buffer. Those requests specify a range, which can vary from a single entry or to the whole buffer. The entire buffer may be requested in events such a Tevatron abort.

There is no need for mode switching for BLMs, and there are no turn by turn requirements.

There should be a data buffer for BLM data capable of storing a given time frame worth of data. These data can be read in full in the event of a TeV abort.

2.7 Alarms

In order to avoid flooding the operations alarm screen with several repetitious alarm conditions, there will be a single alarm device for a given BPM/BLM house. The device will alarm on any condition that implies that the house is in trouble. One must then go to the diagnostics page to determine the exact source of the problem. Alarm conditions include, but are not limited to:

Any dead channel Power supply problems Profile frame buffer overflow Timeouts when getting injection data Detection of raw signals above or below thresholds (same thresholds across the

machine) What diagnostics can we get about the EchoTek boards?

2.8 State Diagram

The crate controller’s only interest inuses the Tevatron state devices for two purposes. It uses V:TBPMM to determine which mode of operation to return to after a reboot or a change from diagnostic mode. IAlso, it is to also fetchesincludes various pieces of information from them other states devices to include in the metadata that is returned. Please refer to URL: http://www-bdnew.fnal.gov/tevatron/adcon/tev_states.html

for a detailed description of the Tevatron state diagram). In the current old system the sequencer is responsible for informing the BPM system about a TeV state change. The new system should be able to detect such changes by itselfindependently, freeing the sequencer from thise task of informing the BPMs about TeV state changes.

Are we sure we don’t want to return status when somebody asks for something that shouldn’t be – e.g., pbar data in a proton injection state?

33 5/18/23

http://www-bdnew.fnal.gov/tevatron/adcon/tev_states.html


The state device containing the current Tevatron state is V:CLDRST. The BPM system is interested in some of the possible states assumed by this device. The following is a list of states for V:CLDRST:

1. 1 - Proton injection porch 2. 2 - Proton injection tune up3. 3 - Reverse injection4. 4 - Inject protons5. 5 - Pbar injection porch6. 6 - Inject pbars7. 7 - Cogging8. 8 - Before ramp9. 9 - Acceleration10. 10 - Flattop11. 11 - Squeeze12. 12 - Remove halo

13. 14 - ???HEP14. HEP15. 15 - Pause HEP16. 16 - Proton removal17. 17 - Unsqueeze18. 18 - Flattop219. 19 - Deceleration20. 20 - Extraction porch21. 21 - Extract pbars22. 22 - Reset23. 23 - Recovery24. 24 - Ramping

The following states will require functionality from the BPMs:

Proton Injection Porch (1)From the time the Tevatron is in recovery until it reaches either the proton injection porch (event $43), the BPMs are not required to be doing anything. The system can do an inventory of the current BPMs, checking whether they working or not. Problems detected must be reported to operators and data taken has to be tagged with the BPM status for later analysis.

Proton Injection Tuneup (2)Only proton data is needed in this state. Take both single turn, in particular, first turn, as well as triggered (either on a TCLK ($2B+$4D) event or a TCLK event + delay) closed orbit data in this state. No pbar data available. Reverse Injection (3)Currently Old system uses only uses Main Injector BPM data taking closed orbit data triggered on a TCLK. Triggered by event $2A+$5D.Inject Protons (4)Switch now to coalesced beam depending on the operational mode (the device V:COALP should be checked). SDA is collecting closed orbit data on demand. Triggered by event $2B+$4D.Pbar Injection Porch (5) SDA collecting proton closed orbit data on demand. Inject Pbar (6)Both proton and pbar data are needed here. Collecting closed orbit data on TCLK events as well as on demand. There may be unique cogging values for each BPM.Acceleration (9)Profiling data taken. Profiling is a closed orbit measurement taken at n points during the acceleration process at 100GeV, 200GeV,... , 980GeV. Right now p only – pbar would be nice. Currently generated by a TCLK event that is coming from the CAMAC timing modules.

34 5/18/23


Besides the device V:CLDRST, other state devices that should be checked by the BPM system are:

V:TBPMM – Tevatron BPM mode of operation. Use this device to determine the mode of operation for the BPM system after power-down, reboot, or diagnostics exercise.1. Closed orbit2. idle

1. 1 – closed orbit2. 2 – idle3. V:NXBNCH – Next bunch injected into Tevatron (1 - 36). Use this device to set

different trigger delays for first turn injection mode if first bunch goes anywhere besides bunch 1.

V:NXTBKT – Next bucket injected into Tevatron (1 - 1113), for metadata only. V:TEVMOD – Tevatron high-level mode

1. colliding beams2. proton only3. dry squeeze4. ramping5. recovery / turn on6. off

V:TEVMOD – Tevatron high-level mode1 - colliding beams: take closed orbit data

1. 2 - proton only: take proton closed orbit data

3 - dry squeeze: take closed orbit data

4 – ramping: take closed orbit data

5 - recovery/turn on: run diagnostics 6 - off: run diagnostics when machine is off

V:COALP – Proton coalescing state for meta data only1. 1 - coalescing off2. 2 - coalescing on

V:COALA – Antiproton coalescing state for meta data only1. coalescing off2. coalescing on

35 5/18/23


V:COALA – Pbar coalescing state for metadata only1. 1 - coalescing off2. 2 - coalescing on

V:TVBEAM – Particles present in the Tevatron1. 1 - no beam: run diagnostics while no beam in machine2. 2 - protons: take proton closed orbit data3. 3 - pbars: take pbar closed orbit data4. 4 - protons and pbars: take proton and pbar closed orbit data

V:HELIX – Helix state for metadata only V:PBKTC – Number of Proton bBunches for metadata only

V:ABKTC – Number of Pbar bBunches for metadata only

2.9 Alarms

In order to avoid flooding the operations alarm screen with several repetitious alarm conditions, there will be a single alarm device for a given BPM crate. The device will alarm on any condition that implies that the house is in trouble. One must then go to the diagnostics page to determine the exact source of the problem. Alarm conditions include, but are not limited to:

Any dead channel Power supply problems Profile frame buffer overflow Timeouts when getting injection data Detection of raw signals above or below thresholds (same thresholds across the

machine)

2.10 Configuration Parameters

1. Configuration Parameters

These are a some configuration parameters identified that should be used for setting up the BPM software DAQ. Changes to all parameters implemented as ACNET devices will take effect immediately, i.e., they will not be delayed and they will not synchronized across houses.

2.10.1 DAQ Parameters

36 5/18/23


a. DAQ Parameters

Description Scope Type RangeDisable automatic triggering of injection

mode on TCLK $4D System ACNETOperator pages

State deviceRestore last value

Define the current mode of operation of the BPMs House ACNET

Operator pages

DADiagnosticsCalibration

The number of fast abortnumber of fast abort buffers frames that are taken after the abort is

received.System Compilation

The minimum intensity threshold needed to be considered real beam System ACNET

Engineering pagesNumber of samples used in closed orbit “averaging” in normal operation mode System Call argument 1, 100

ConstanstsConstants used to compute “averages” in normalin normal operation

modeSystem

Compilation (need to keep track of versions)

how to track changes – set version info in snapshot

data header?Number of samples used in closed orbit

averaging in injection modeinjection mode System ACNETEngineering pages 2-8k?

ConstanstsConstants used to compute “averages” in injectionin injection mode System

Compilation (need to keep track of versions)

how to track changes – set version info in snapshot data header?

Number of fast abort samples needed for each slow abort sample System Compilation 1 - 1024

Buffer DepthsAbort Buffers, Turn, Turn by Turn, Profile System Compilation

TCLK needed to arm TbT request System Compilation/Configuration File (?)

2.10.2 Timing Parameters

2.10.3 Timing Parameters

Description Scope Type RangeDelay for trigging after specific TCLK House ACNET

Engineering pages msec

EchoTek moduleChannel

Delay for arming after specific BSYNCHTVBS System ACNET

Engineering pages msec

TCLK $4D + <value> until hardware moduleshardware modules are switched into

TBT mode.System Compilation/Configuration

File (?) msec

TBT readout must complete in <value> System Compilation msec

37 5/18/23


2.10.4 Diagnostic Parameters

2.10.5 Diagnostic Parameters

Description Scope When can Change RangeDebug Level House ACNET

Diagnostic pagesDefines the type of trigger injecting data into

the bufferHouse ACNET

Diagnostic pagesAccelerator clock

External clockDefines what is the source for the buffer

incoming dataHouse ACNET

Diagnostic pagesBPM single turn, BPM

closed orbit or BLMSoftware self triggering for first turn (ie, not

on bsynch)System ACNET

Operator pages

3 Interface to Online Software

2. Interface to Online Software

This section defines how data and commands are exchanged between the front-end DAQ software and the online software. ACNET will be the means of transportation of data and commands between peersthe front-end DA and the online software. Commands are:

Arm turn by turn – prepare BPMs for turn by turn data taking Mode Select (Diagnostics, Calibration, Data Acquisition) Enable/Disable injection mode Get BPM /BLM data

Requests may be made in parallel by disjoint applications, and some mechanism for avoiding conflicts must be designed and implemented.

These types of conflicts can specifically occur with turn by turn arm commands. When the crate controller receives multiple turn by turn arm commands, it will process only the last request received. Any turn by turn request already in progress will be aborted.

BPM and BLM data read by the online software will be organized according to the data structures defined a subsequent in the following section section b. Online applications that make use of the old system must be changed to handle new data formats (see document #1060 – Online Software Specifications).

38 5/18/23


Current online applications do not need to be rewritten in order to comply with the structures. The necessary changes will be made at the BPMUTI library level. (move to online spec document)

The supported ACNET protocols will be SETDAT, RETDAT and Fast Time Plot (FTP). The snapshot protocol (nNot to be confused with a BPM snapshot) will not be supported by the front-end DAQ. The front-end must be able to generate FTP data at a rate up to 500 Hz.

3.1 SSDN / ACNET Device Mapping

a. SSDN/ACNET Device Mapping

The following suggested SSDN numbers will be used to map to the appropriate ACNET devices. There is at least one ACNET device associated with each SSDN number.

The SSDN number is an 8 byte field split into 4 2-byte pairs. See the Mooc MOOC Front-Ends documentURL for a detailed field description:,

http://www-bd.fnal.gov/controls/micro_p/mooc_front_ends.html

For reading BPM and BLM data, this project will use the recycler BPM model of object id:

0x0021 for BPM retdat/setdat and 0x0022 for BPM FTP data 0x0026 for setdat 0x0041 for BLM retdat/setdat 0x0042 for BPM FTP data Timing and ADC settings not yet defined.

3.1.1 SSDN Mapping for FTP devices

i. SSDN Mapping for FTP devices

Each channel can have an I and Q value. Data from a pair of channels (i.e., A and B plates) can be manipulated to generate in a corresponding intensity and position. There will be a position and intensity measurement for a horizontal and vertical position for both proton and antiproton data. One EchoTek card contains eight channels, allowing 2 BPM to be read out (e.g. one horizontal and one vertical). A complete house, with 6 6 EchoTek boards can read out 12 12 BPMs, each one with 4 channels. The total channels in a house is 4848, and each channel has an I and Q value associated.

39 5/18/23

http://www-bd.fnal.gov/controls/micro_p/mooc_front_ends.html


The following FTP devices are associated with these 48 48 channels:0000/0022/000X/22YY

where X is 0 for I, Q and the sum signal, where I is the first, Q is the second and the sum is the third element on the device; and YY is the channel number, which can vary from 00 to 2F 2F (47 47 decimal).

Position and Intensity values can also be accessed through FTP devices. Each house will provide at most 24 24 positions and 24 24 intensities that can be accessed via these SSDN numbers:

0000/0022/000X/22YY

where X is 1 for proton position and intensity and 2 for pbar information, where position is the first and intensity is the second element on the device; and YY is the BPM number, which can vary from 00 to 0C 0C (12 12 decimal).

A house also is responsible for reading out the Beam Loss Monitor system, which will consist up to 48 24 channels. These channels can also be read out via FTP devices through the following configuration:

0000/0027/0000/27YY

where YY is the BLM channel number, varying from 00 to 17 (243 decimal). The maximum number of FTP devices provided by one house is 729672:

1 I/Q/Sum x 48 48 channels + 2 p/pbar x 12 12 position/intensity + 24 BLM = 729672

3.1.2 SSDN Mapping for RETDAT devices

ii. SSDN Mapping for RETDAT devices

The RETDAT protocol is used to retrieve most data read out by the BPM and BLM systems. Through RETDAT it is possible to read the following BPM data:

Fast abort buffer (array) Slow abort buffer (array) Profile frame buffer (array) Display frame buffer Snapshot buffer (first element of the fast abort buffer) Average snapshot buffer (10Hz average of fast abort buffer) Injection turn-by-turn buffer (array) Injection closed orbit frame Turn-by-Turn buffer (array)

And the following BLM data

40 5/18/23


Abort buffer (array) Display buffer Injection turn-by-turn buffer (array) Profile frame buffer

The BPM data will contain information from all EchoTek cards present in the system; except when handling turn-by-turn requests, which can specify a single BPM. The BLM devices will return data from all BLMs managed by the system. All array buffers above can return any number of frames.

The SSDN for the RETDAT BPM devices are:0000/0021/000X/210Y

where X is 0 for raw data (I and Q) or 1 for scaled data (position/intensity); and YY is the data being read out:

0 - Fast abort buffer1 - Slow abort buffer2 - Profile frame buffer3 - Display frame buffer4 - Snapshot buffer5 - Average snapshot buffer6 - Injection turn-by-turn buffer7 - Injection closed orbit buffer8 - Turn-by-turn buffer

3.1.3 SSDN Mapping for SETDAT devices

41 5/18/23


iii. The SSDN for the RETDAT BLM devices are:

iv.

v. 0000/0026/000X/260Y

vi.

vii. where X is 0 for raw data (I and Q) or 1 for scaled data (position/intensity); and YY is the data being read out:

viii.

ix. 0 – Abort buffer

x. 1 – Display buffer

xi. 2 – Profile buffer

xii. 3 – Injection turn-by-turn buffer

xiii. SSDN Mapping for SETDAT devices

SETDAT devices are used for setting modes of operation of the BPM system and also to specify the data acquisition and change configuration values. For changing the mode of operation the following SSDN are defined:

0000/0021/0000/218X

where X is 0 for enabling Turn-by-Turn mode and 1 for turning on system diagnostics. The remaining SSDN are use for:

DAQ specifications System configuration

3.2 Data Structures (Output Date)

b. Data Structures (Output Data)

The data sent from the front-end DAQ to the BPM library and/or applications is based in the following C data structures. For compatibility, the BPM libraries on the online side will be responsible for extracting subsets from these data, which are required by existing application programs.

42 5/18/23


3.2.1 Generic Headers

i. Generic Headers

typedef struct BPM_TIME { ulong timestamp; /* timestamp in seconds (GMT) */ ulong nanoseconds; /* nanoseconds */}

typedef struct TRIGGER_INFO { long type; /* Periodic, TCLK */ to be defined;}

typedef struct TEVATRON_BPM_HEADER { long endian_type; /* 0 -> little endian,

else -> big endian */ long version; /* data structure version */ long status; /* overall status: zero = OK */ BPM_TIME time; /* time stamp */ ulong turn_number; /* starting turn number */ ulong num_turns; /* number of turns in data */ double time_in_cycle; /* starting time in cycle */ long data_type; /* flash/snapshot/profile/TBT/etc */ TRIGGER_INFO trigger_info; /* trigger information */ long data_source; /* 0 -> beam,

1 -> calibration system, 2 -> software diag,

3 -> hardware diag */ long particle_type; /* 0 -> proton, 1 -> pbar */ long bunch_type; /* 0 -> uncoalesced, 1 -> coalesced */ long scaled_data; /* 0 -> raw data, n -> scaling version algorithm */ long calibration_id; /* calibration data ID number */ long machine_state; /* value of V:CLDRST */ long helix_state; /* value of V:HELIX */ long num_proton_bunches; /* value of V:PBKTC */ long num_pbar_bunches; /* value of V:ABKTC */}

status – returns non zero value if there is some problem at the crate level. The online side will ignore the data.time – should be the time stamp of the first data frame.turn_number – comes from the timing module.

Suggestions of new fields:algorithm_version: version of the algorithm used for calculating the closed orbitfirmware_version: version of the EchoTek firmware

typedef struct TEVATRON_BPM_STATE_DATA { long machine_state; /* value of V:CLDRST */ long helix_state; /* value of V:HELIX */ long num_proton_bunches; /* value of V:PBKTC */ long num_pbar_bunches; /* value of V:ABKTC */ long bpm_state; /* BPM state (not yet defined) */ unsigned long narrow_gate_mask; /* narrow gate measurement mask */}

3.2.2 BPM Non Turn By Turn

BPM Non Turn By Turn

43 5/18/23


typedef struct TEVATRON_BPM_FRAME_DATA { long frame_number; /* ordinal number in front-end */ BPM_TIME time; /* time stamp */ ulong turn_number; /* starting turn number */ double time_in_cycle; /* starting time in cycle */ TEVATRON_BPM_STATE_DATA state_data; /* machine/BPM state information */ long num_detectors; /* number of detectors present */ long status[1212]; /* status values */ float positions[1212]; /* position values in mm */ float intensities[1212]; /* intensity values */}

For raw data requests (I and Q), the returning structure is the same, except for the positions and intensities arrays that are replaced by: long i[1224]; long q[1224];

Proposed status values:OK = 0invalid reading = 1 (too little beam intensity?)alarm level = 3 (if we want alarm limits)saturated = 5error = -1 (error reading value (hardware error?))unequipped = -2 (channel is not in use)

This would be the final structure of the ACNET device for display, snapshot, profile, and flash frames:.typedef struct TEVATRON_BPM_ORBIT_DATA { TEVATRON_BPM_HEADER header; long num_frames; /* number of frames returned */ TEVATRON_BPM_FRAME_DATA frame_data[];}

3.2.3 BPM Time Slice Data

BPM Time Slice Data

This structure is used for sending an entry (frame) from the BPM buffers.typedef struct TEVATRON_BPM_TIME_SLICE_VALUE { longshort status; /* detector status */ unsigned long milliseconds; /* milliseconds since first frame */ float position; /* position in mm */ float intensity; /* beam intensity */}

For raw data requests (I and Q), the returning structure is the same, except for the positions and intensities arrays that are replaced by: long ii[2]; long q[2];

typedef struct TEVATRON_BPM_TIME_SLICE_DATA { TEVATRON_BPM_HEADER header; TEVATRON_BPM_STATE_DATA state_data; /* machine/BPM state information */ Long num_frames; /* number of frames returned */ TEVATRON_BPM_SLICE_VALUE frame_data[];}

44 5/18/23


3.2.4 BPM Turn By Turn

ii. BPM Turn By Turn

typedef struct TEVATRON_BPM_TBT_TURN { ulong turn_number; /* turn number */ float position; /* position in mm */ float intensity; /* beam intensity */}

For raw data requests (I and Q), the returning structure is the same, except for the positions and intensities arrays that are replaced by: long i; long q;

This would be the final structure of the ACNET device for turn by turn data:.typedef struct TEVATRON_BPM_TBT_DATA { TEVATRON_BPM_HEADER header; TEVATRON_BPM_STATE_DATA state_data; /* machine/BPM state information */ long status; /* detector status */ long num_turns; /* number of turns returned */ TEVATRON_BPM_TBT_TURN turn_data[];}

3.2.5 Calibration Constant Data

45 5/18/23


iii. BLM Data Structures

iv.

v. typedef struct TEVATRON_BLM_FRAME_DATA {

vi. long frame_number; /* ordinal number in front-end */

vii. BPM_TIME time; /* time stamp */

viii. ulong turn_number; /* starting turn number */

ix. double time_in_cycle; /* starting time in cycle */

x. long num_detectors;/* number of detectors present */

xi. float losses[24]; /* loss values in rads/sec */

xii. long status[24]; /* status values */

xiii. }

xiv.

xv. Proposed status values:

xvi.

xvii. OK = 0

xviii. alarm level = 3 (if we want alarm limits)

xix. saturated = 5

xx. error = -1 (error reading value (hardware error?))

xxi. unequipped = -2 (channel is not in use)

xxii.

46 5/18/23


xxiii. This would be the final structure of the ACNET device for display, snapshot, profile, and flash frames.

xxiv.

xxv. typedef struct TEVATRON_BLM_DATA {

xxvi. TEVATRON_BPM_HEADER header;

xxvii. long num_frames; /* number of frames returned */

xxviii. TEVATRON_BLM_FRAME_DATA frame_data[];

xxix. }

xxx. BLM Time Slice Data

xxxi.

xxxii. This structure is used for sending an entry (frame) from the BLM buffers.

xxxiii.

xxxiv. typedef struct TEVATRON_BLM_TIME_SLICE_VALUE {

xxxv. long status; /* detector status */

xxxvi. unsigned long milliseconds; /* milliseconds since first frame */

xxxvii. float loss; /* loss value in rads/sec */

xxxviii. }

xxxix.

xl. typedef struct TEVATRON_BLM_TIME_SLICE_DATA {

xli. TEVATRON_BPM_HEADER header;

47 5/18/23


xlii. TEVATRON_BPM_STATE_DATA state_data;/* machine/BPM state information */

xliii. long num_frames; /* number of frames returned */

xliv. TEVATRON_BLM_SLICE_VALUE frame_data[];

xlv. }

xlvi. BLM Time SliceCalibration Constant Data

xlvii.This structure is used for sending an entry (frame) from the BLM buffersreading and setting calibration constant data:.typedef struct TEVATRON_BPLM_CALIBRATION_DATATIME_SLICE_VALUE { short long statuscalibration_id; /* calibration ID numberdetector status */ unsigned long millisecondsstate_value; /* corresponding BPM state valuemilliseconds since first frame */ long num_constants_per_detector; /* number of constants per detector */ float lossconstants[][12]; /* loss value in rads/seccalibration constants */ }

4 Interface to BPM Hardwaretypedef struct TEVATRON_BLM_TIME_SLICE_DATA { TEVATRON_BPM_HEADER header; long num_frames; /* number of frames returned */ TEVATRON_BLM_SLICE_VALUE frame_data[]; }

3. Interface to BPM/BLM Hardware

The front-end software will access data from the BPM hardware through VME memory mapped buffers. Information about protons and pbars will be available in different addresses, and each type of particle will have at least two streams of information. One type containsing the latest position information (for Turn By Turn measurements) while the other has average position information (Closed Orbit measurements).

Additionally, there will be other memory mapped regions used to pass configuration and diagnostics data from the front-end to the hardware and vice-versa.

48 5/18/23


4.1 Operation of the Echotek ADC Boards Each Echotek board provides 8 receiver channels of 14-bit, 80 MHz (maximum) analog-to-digital conversion and digital processing in a single 6U VME slot. It supports 3 operating modes:

1. Gate Mode – data is collected as long as the external sync signal is active;2. Trigger & Free Run – data collection begins at the rising edge of the external sync

signal, or when the Software Sync Bit is written, and continues until the Trigger Clear bit is written;

3. Trigger & Counted Burst – A preprogrammed number of samples (burst counts) is acquired and processed with each occurrence of an external sync pulse, or writing to the software bit – This is the mode the Tevatron BPM system will be using.

In the trigger modes, the external sync signal can be delayed to each pair of channels (0 & 1, 2 & 3, 4 & 5, 6 & 7). The SYNC_DELAY registers are 12-bit counters that are clocked at the ADC sample rate.

The 8 channels on each board can be independently configured to output one of 3 types of data:

1. Count Data – the on-board FPGA generates a continuous counting sequence and puts the data directly into the memory. This bypasses the whole chain of analog-to-digital conversion and digital processing, is hence intended for checking the data handling within the board and checking the VME interactions.

2. Raw Data – the ADC counts are stored into the memory directly, bypassing the digital processing. The samples are right justified with the two least significant bits always set to zero. Every two samples are packed together to form a 32-bit word.

3. Receiver Data – the ADC counts are digitally down-converted, decimated and fil-tered to output an interlaced sequence of 24-bit I’s and Q’s. The 24-bit I’s and Q’s can be either truncated to 16-bit then packed into 32-bit words each consist-ing one I and the corresponding Q, or directly output in 32-bit words.

The memory for each channel is a 128 K x 32 bits SRAM operating in a FIFO fashion.

The procedure to initialize the boards is as follows:1. read in all the setup files (.ini and .ch files), parse the files then create an array of

“ghSetup” structures in the crate controller’s memory by calling “ecdr814gcRead-Setup” in the startup script;

2. install a driver for each board by calling “ecdr814gcInstall”;3. open the driver by calling “open”;4. allocate data buffers in the crate controller’s memory;5. set the buffer pointers in the driver to the buffers in the crate controller’s memory

by calling “ecdr814gcSetBufferBrd”;6. copy the desired setup from the “ghSetup” array to all the boards by calling “ec-

dr814gcCopySetupAll”;

49 5/18/23


7. set the channel-pair delays by calling “ecdr814gcIoctlCopysyncDelayAll”;8. program all the Gray chips by calling “ecdr814gcProgramGrayAll”;9. set up the daq conditions by calling “ecdr814gcRdSetupAll”;10. set the trigger counters by calling “ecdr814gcSetNumTrigsAll”;11. reset the boards by calling “ecdr814gcIoctlClearAll”.

Steps 4 through 11 need to be repeated when changing to a different operation mode.

After initialization, the boards need to be enabled by calling “ecdr814gcEnableSyncAll”. Then the boards can be disabled and read out by calling “ecdr814gcReadAll”. These two function calls form a complete daq cycle.

4.2 Operation of the Timing Generator Fanout Board

Within the Tevatron BPM system, the TGF has four function blocks: a clock generator, a TCLK decoder, a timing block and a diagnostic block. It has 2 interrupt channels each with a separate multiplexer to select the interrupt source.

The clock generation automatically starts after power-up, provided that the Tevatron RF input is present. For standalone applications, the FPGA firmware can be modified to multiply the clock output with 5/7 and route it back to the input so that the board works in a freerun fashion without the Tevatron RF input.

The TCLK decoder can be set to wait for up to 16 TCLK events, and generates a VME interrupt upon the receival of any of them. It stores the most recent event in a register for user reference. The procedure to set up the TCLK decoder is as follows:

1. install an interrupt handler for vector 198;2. set one of the 2 IRQ Vector registers, e.g. Reg 1 at offset

0x60 for interrupt channel one, to fire at one of the 2 interrupt levels (5 & 6), e.g. 5, with an interrupt vector 198;

3. set the corresponding IRQ Source Mux register, e.g. offset 0x70, to choose the interrupt source to be TGF_SOURCE_TCLK (0x0A);

4. set the desired TCLK events in the TSG registers, offsets 0x80 through 0x9E – at power up, these registers are set to the invalid value of “0xFE”;

5. enable the TCLK decoder by writing to bit 8 of the Control And Mode register;

6. enable the interrupt by writing to bit 12 of the corresponding IRQ Vector register.

The timing part uses two timebases: the Tevatron turn marker event from the BSYNC system as a coarse clock, and the 53.104696 MHz Tevatron RF clock, multiplied by 2, as a fine clock.

50 5/18/23


The start of the synchronization sequence can be triggered by a turn scaler, or by the receival of a specified “start event”. The selection is made by a “start source” multiplexer, and the start can be delayed by a “pre-trigger delay” in units of “turns”. Through another multiplexer, the “trigger source”, the delay timer can be activated by the receival of the “start event” itself, or by the receival of the “start event” delayed by the “pre-trigger delay”, or by an the external input.

When the “activate” condition is met, or external trigger received, the TGF uses the Tevatron turn maker events as references, outputs 8 sequences of synchronization signals through 8 spigots. Each synchronization sequence can have its own 0.5-bucket delay with respect to the turn makers. In closed orbit mode, one sequence consists of only one pulse; in turn-by-turn mode, it has 8192 pulses with the same 0.5-bucket delay with respect to 8192 consecutive turn makers.

The procedure to set up the timing part is as follows:1. install interrupt handlers, e.g. vector 160 for closed orbit

mode and 161 for turn-by-turn mode;2. set the Turn Event register;3. for closed orbit mode, set the Turn Scaler/Modulus register;

for turn-by-turn mode, set the Start Event register;4. set the Gate Count register to 1 for closed orbit mode, 8192

for turn-by-turn mode;5. set the other IRQ Vector register, e.g. Reg 2 at offset 0x62

for interrupt channel two, to fire at the other interrupt level, e.g. 6, with an inter-rupt vector 160, interrupt auto-clear “false” for closed orbit mode and interrupt vector 161, interrupt auto-clear “true” for turn-by-turn mode – when the auto-clear is “true”, the interrupt will disable itself after the first occurence;

6. set the other IRQ Source Mux register, e.g. offset 0x72, to choose the interrupt source to be TGF_SOURCE_PERIODIC (9) for closed orbit mode and to be TGF_SOURCE_START (1) for turn-by-turn mode;

7. write to the Control and Mode register to: enable the BSYNC decoder, the pre-trigger delay counter and the delay timer, set the Start Source to be Turn Scaler/Modulus for closed orbit mode and Start Event for turn-by-turn mode, set the Trigger Source to be Pre-Trigger Delay, and set the Single Strobe bit;

8. enable the interrupt by writing to bit 12 of the corresponding IRQ Vector register.

The diagnostic part ???

At present, the TGF is configured to output only one sync pulse for each closed orbit cycle. It is possible to output multiple sync pulses if the Gate Count register is set to a value more than 1. This way, a closed orbit measurement can be derived from a few turns of turn-by-turn data in the front-end processor, and the closed orbit mode and the turn-by-turn mode only differ in the start event and the gate count. This should eliminate

51 5/18/23


the need to re-load the Echotek boards when switching modes, and hence significantly simplify the DA package.A complete specification of the communication channels will require interaction and agreement between the BPM FPGA code and the front-end software. During the software development, data from the EchoTek board may be simulated using the agreed interface.

5 Calibration

4. Access to BLM data and commands will happen through a PMC-DIO64 card that connects the crate controller to the BLM hardware. Commands sent and data read from the BLM hardware are defined in the documents #764. BLM buffers contain single values and are buffered on the front-end board.

5. Calibration

The front-end DAQ is able to return raw data as well as calculated beam position to the online applications. Raw data does not require any processing on the front-end whereas calculated beam position requires the use of calibration constants.

Calibration constants are defined by offline processing. Data used for calibration will be collected from the front-end systems, running on calibration mode, and will have its data type marked as calibration data.

At startup time the front-end downloads current calibration constants. The calibration constants are retrieved by the front-end system via ACNET variables. The use of ACNET insures that the front-end automatically receives the latest calibration set.

The calibration set used by the front-end is identified by a database ID. This ID should be included in the metadata that is returned when calculated data is requested by an online application.

The system should be able to handle different calibration constants for different machine states (e.g. 150 GeV, 980 GeV). The tevatron state device (V:CLDRST) may be used to define what calibration set should be used.

6 Diagnostics, Test Suite, and Simulation6.1 Diagnostics

52 5/18/23


The BPM front-end system must be able to perform and handle calibration operations. Each BPM card will have its own set of constants, which can be, for instance, mechanical offsets.

6. Diagnostics, test suite, and simulation a. Diagnostics

The DAQ software will provide diagnostics data via ACNET devices. It will provide means for operators or programs to detect a bad or misbehaving BPM.

Some diagnostics operations follow: Generate close orbit: return known closed orbit values. Generate turn by turn: return known values for a turn by turn measurement. Generate single turn: return known values for a single turn measurement. Check BPM hardware: run test procedures in the BPM hardware (one or all the

BPM boardscards) – if supported by the hardware. Check BLM hardware: run test procedures in the BLM hardware (one or all the

BLM cboards) – if supported by the hardware. Get buffers: return current contents of all (or selected) data buffers.

6.2 Self-Testing Procedures

b. Self-Testing Procedures

The front-end DAQ should be able to perform tests on itself and on the associated BPM hardware. Results from self-tests should be available to user applications.

Hardware tests will be performed if supported, i.e., the hardware should have the capability of receiving triggers from the front-end and generate data for self-tests.

Software self-testing will be used for validating the data path from the time data is read out from the BPM until it is ready to be read via ACNET devices.

7 Monitoring

53 5/18/23


7. Monitoring

The front-end DAQ should periodically send status and statistics messages to a monitor, via ACNET devices. There should be a central monitoring application whichapplication that receives data from all BPM front-ends and points out BPMs that have problems.

Data from the front-end include: Buffer usage Up time Available memory Status of processes

Number of requests Tevatron status

8 Appendix8.1 Current BPM Data Structures

8.1.1 BPM Turn By Turn

54 5/18/23


Appendix

a. Current BPM data structures

i. BPM Single Turn (Flash)#define HOUSE_CHANNELS 12

typedef struct BPM_FLASH_DATA { char positions[HOUSE_CHANNELS];/* raw position data (ADC counts) */ uchar intensities[HOUSE_CHANNELS]; /* raw intensity data */ ushort valid; /* valid data bits */ char timestamp[3]; /* base timestamp in inverted byte order */ uchar timeoff; /* BCD encoded timestamp offset */} BPM_FLASH_DATA;

8.1.2 BPM Closed Orbit

ii. BPM Closed Orbit

typedef struct BPM_ORBIT_DATA { char positions[HOUSE_CHANNELS]; /* raw position data(ADC counts) */ ushort valid; /* valid data bits (bit #7 indicates alarm */ /* limits used - 0-low, 1-high) */ uchar abort; /* abort status bits */ uchar alarm_abort; /* alarm status in low nibble and */ /* abort status in high nibble */ uchar alarm; /* alarm status bits */ char timestamp[3]; /* timestamp in inverted byte order * 1000.0 */} BPM_ORBIT_DATA;

iii. BPM Data Structure

typedef struct BLM_DATA { uchar raw_losses[HOUSE_CHANNELS]; /* raw loss data */ uchar status; /* BLM status */ char timestamp[3]; /* timestamp in inverted byte order * 1000.0 */} BLM_DATA;

55 5/18/23

Tevatron BPM Requirementsbeamdocs.fnal.gov/AD/DocDB/0008/000860/031/bpm_sw.doc · Web viewFor this...

Documents

Transcript of Tevatron BPM Requirementsbeamdocs.fnal.gov/AD/DocDB/0008/000860/031/bpm_sw.doc · Web viewFor this...