You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 28 Current »

ASOT-1 - Getting issue details... STATUS

Objectives

This module introduces the RTBSA GUI. After completing this module, an operator should be able to:

  • Plot and interpret a signal vs. time
  • Plot and interpret two signals against each other
  • Plot and interpret the Fast Fourier Transform (FFT) of a signal
  • Tune a signal using the plots (either visually or using linear/polynomial fit)
  • Use the standard deviation filter

Introduction

Beam Synchronous Process Variables (PVs) are signals that are tied to the beam pulse that generated them. RTBSA uses this feature to build a pulse by pulse "picture" of the beam so that we can see correlations between signals that would otherwise be hidden.

Background

What is a PV?

PV stands for "Process Variable." We have a lot of devices on site, and those devices generate a lot of data. BPMs (beam position monitors), for example, constantly monitor where the beam is relative to the center of the beam pipe. One singular BPM, however, has a lot of signals that it reads out (chief among them x position, y position, and charge), and each one of those signals has a channel dedicated to reading it. It's kinda analogous to TV channels for a BPM TV - x position is on channel 2, y position is on channel 3, etc (except that the channel names are a little more complicated, like BPMS:LI24:801:X). Those channels are PVs.

Note: There are some devices that only have one signal that they read out (and therefore only on PV associated with them)

What does it mean to be tagged to a pulse?

Say that we have a train of pulses with pulse IDs 1 through 4, and say that we have a BPM somewhere watching them go by:

pulseTrain

That BPM is going to send out data packets for each of its measurement channels every time it sees a pulse. Say that we care specifically about the beam's x position, so we tune into that specific channel. The data packets sent over that channel contain not only the raw beam position value, but also metadata like the timestamp and PV name. Crucially, the timestamp has the pulse ID encoded into it (one of 1 through 4 in our illustrated example) so that we know which pulse this data packet belongs to. Not all PVs have this encoding, but the ones that do are said to be beam synchronous.

What does this have to do with RTBSA?

Well, RTBSA stands for Real Time Beam Synchronous Acquisition, and it's a tool to help us correlate signals (PVs) in real time. 

How it Works

Data Buffers

A selected BSA PV is given a dedicated data buffer to hold its most recent values. Using the example above, let's say that we have a buffer size of 4 (so that we only store the 4 most recent values):

1234
-0.04-0.020.020.04

Where the first row is the pulse ID and the second row is the x position that the BPM saw for that pulse. While the PV is selected, the data buffer keeps getting written to modulo the buffer size so that when it sees pulse 5, it would become:

5234
0.00-0.020.020.04

This is pretty much the backbone of the whole program.

A vs. Time

The simplest use case, where we have one PV with one associated data buffer. The default (and maximum) buffer size is 2800, but that can be reduced if desired. Whatever the buffer size n, we display the n most recent points as long as a kind of rolling EKG:

Playback Note

You will need to download the file and view on VLC (not the default video player) on the OPIs. If you're on a machine that has internet, you can view it here

A vs. Time.mp4

This is useful for seeing erraticisms in a signal (maybe you suspect a klystron phase is wandering), or to see how it's trending (maybe you're messing with a quad and you want to see if that's increasing/decreasing/doing nothing to the pulse intensity). Feel free to play with it! This is a read-only GUI, so none of the buttons will change anything in the machine.

FFT

TODO ask Ahmed

B vs. A

The crown jewel of RTBSA. If there are two PV selected at once, there are two data buffers getting filled simultaneously. Given the pulse tagging, we can line up both buffers so that we can tease out a true pulse-by-pulse correlation between the two signals: 

Playback Note

You will need to download the file and view on VLC (not the default video player) on the OPIs. If you're on a machine that has internet, you can view it here 

B vs. A.mp4

This is useful for real-time optimization, or for diagnosing issues. 

Fit Types

A feature for all three of the plot types (A vs Time, FFT, and B vs A)! The default fit is a linear fit, but we can request higher order polynomial fits if we'd like (sometimes the correlation looks parabolic).

Standard Deviation Filter

Sometimes one (or both) of the signals has a lot of dropouts, which can mess with the correlation fit. If that's the case, we can institute a standard deviation filter that filters out anything outside of n (default is 3) standard deviations from the mean of both signals (or only the one if we're using A vs Time).

Playback Note

You will need to download the file and view on VLC (not the default video player) on the OPIs. If you're on a machine that has internet, you can view it here  

Standard Deviation Filter.mp4

  • No labels