Contents of Vol. 8, No. 2

1. BPM Orbit Fitting
2. Fast feedback knobs update
3. Analog Status Gray Tolerance Limit Checking
4. PDU Diagnostics
5. Display Latest Wire Scan
6. The Realtime CUD now plots history data
7. MPS Trip Logic Verification

Page contact and owner at end of this issue.

BPM Orbit Fitting

February 8, 1994

An orbit fitting option has been added to the BPM panel which does a least squares fit of the BPM position data to a modelled betatron oscillation. The fit is performed using the database values of the BPM RMAT values and is a coupled fit which should work in any machine section. Normally four launch parameters (x,x',y,y')are fitted unless the machine section includes significant bending in either plane. In this case, defined as {>20} mm dispersion in X or Y, the fit automatically includes a dE/E0fit parameter.

The BPM panel operation remains essentially unchanged. However, a new button

has been provided to toggle the fit OFF and ON. When fits are toggled ON, the graphic and values display change to show the fit results per orbit. The graphic display shows the X and Y BPM position data with color coded bars as usual, but also overlays the best fit trajectory as lines connecting the fitted BPM positions. The TMIT graphic is discarded in this case to provide room for the numeric launch parameter results at the top. The values display changes to show the measured position, the fitted position, and the difference (measured minus fitted), per plane at each BPM. The raw data are not shown unless the "Print All Text" button is pressed,

A panel button

is provided which toggles the graphic display mode between NORMAL and RESIDUAL display mode. This toggle is only relevant with BPM orbit fits ON. Normal mode produces the graphic display described above while residual mode displays the measured minus the fitted position at each BPM as a bar, similar to the standard BPM display with fits OFF. This mode is useful for identifying BPMs which may be reversed or are very noisy since their readbacks may differ strongly from the best fitted orbit. Note that the fits always work best when fitted to a DIFFERENCE orbit since BPM offsets, non-zero corrector strengths, and misaligned quadrupoles always make the absolute orbit deviate from a simple betatron oscillation. That is, fitting jitter around a reference orbit should fit very well, while fitting an absolute orbit may not necessarily fit so well.

The PRIMARY, MICRO, and UNIT of the fit point, defined as the point in the beamline where the launch parameters are evaluated, may be changed to any point which holds database RMAT values, presently XCOR,YCOR,WIRE,PROF, and MARK. In addition, the fit range may also be controlled. The fit range is the first and last BPMS MICRO and UNIT defining the range which is used in the fit. Any BPM outside this range is not used to calculate the best fit orbit, but it is still included in the display. If the BPM is not used in the fit, there is still a fitted position at this BPM which is based on BPMs which ARE included. This is a projection of how the orbit should look based solely on other BPMs either upstream or downstream. The graphic display indicates the fit range by changing the color of the fitted orbit. The BPMs inside the fit range have a white fitted orbit, while BPMs not included show a yellow fitted orbit.

Whenever the BPM display micro range (first and last MICROs) or the beamline section (BPMD) is changed, the fit point and fit range return to a default. The fit point defaults to the first BPM in the display range, while the fit range defaults to all BPMs in the display range. Furthermore, to keep from confusing those who are used to the old BPM display and do not care about the fit, the fits are turned OFF whenever a new micro range or beamline section is chosen.

A future addition may be the inclusion of a variable kick parameter inside the fit section so that induced oscillations may be fitted simultaneously with incoming trajectory jitter.

Fast feedback knobs update

December 16, 1993

In order to improve user control over fast feedback setpoint knobs, buttons have been added to the fast feedback STATE panel. For a selected fast feedback State element, the user may enter minimum and maximum knob limits. These control how far the user is able to knob the setpoint. In addition, the knob gain range is scaled by the difference in the maximum and minimum values.

Analog Status Gray Tolerance Limit Checking

December 6, 1993

The klystron disk-loaded waveguide temperatures are monitored by the analog status job in the SLC micro. A few of these temperatures normally run near the lower or upper limit defined for that channel. Measurement noise can cause the analog status channel to toggle between GOOD and OUT-OF-TOL on successive updates. This in turn causes the SIP process to log transition messages and the various CUD display boxes to toggle between red and green.

Based upon a suggestion by Keith Jobe, a new form of limit checking called "gray tolerances" can be turned on selected analog status channels by adding %GRAY to the appropriate CTRL entry in the database. The once sharp black lines for the absolute lower and upper limits for that channel as defined by LIMS become wider gray areas.

If the lower limit is defined as 0% and the upper limit as 100%, then the gray tolerance consists of a 10% hysteresis dead band centered about each limit. For example, a typical DL_WG analog status channel has a lower limit of 112.0 degrees and an upper limit of 114.0 degrees. The gray tolerance for the upper limit would be from 113.9 degrees to 114.1 degrees. If the current status for this channel is GOOD, then the next measurement must exceed 114.1 degrees to change the status to OUT-OF-TOL. If the current status is OUT-OF-TOL, then the next measurement must be less than 113.9 to change the status to GOOD. The lower limit works in a similar manner.

It must be emphasized that this change is not intended to increase the tolerances for channels that run near their limits. This change is intended to minimize the transitions in the state of an analog status channel due to measurement noise. This enhancement is not restricted to the disk-loaded waveguide temperatures, but can be used by any basically linear analog status channel. Setting the %GRAY flag on non-linear devices such as vacuum pumps is not recommended.

PDU Diagnostics

December 6, 1993

The advent of Regional Beams (RGBM) has changed the way that PDU channels are managed. This has caused some channels in a small number of PDUs to appear bad when using the PDU diagnostics when in fact they may be operating correctly. Several enhancements have been made to the PDU diagnostic software to maximize the reliability of this non-invasive diagnostic.

Prior to RGBM, the expected behavior of a PDU channel was entirely deterministic from the point of view of the Vax. Under RGBM, the expected behavior of a PDU channel is still deterministic, but under the dynamic pulse-by-pulse control of the micro. The Vax based PDU diagnostics have access to structures that define the expected behavior of a PDU channel, but cannot hope to deal with the pulse-by-pulse dynamics.

The behavior of a PDU channel in the absence of any beam code modifiers is defined by a channel mode (PP, YY, reuse, or base rate) and a timing value associated with a base beam code. However, the pulse-by-pulse behavior of an individual PDU channel can be changed by modifier bits in the PNET broadcast based upon an RGBM expression. An RGBM expression can change the timing delay for a PDU channel or even deactivate it depending on some combination of PNET modifier bits, all on a pulse-by-pulse basis.

RGBM expressions are mechanized by translating a base beam code in the range of 1 to 63 into a substitute beam code greater than 63 based upon the current PNET bit pattern broadcast by the MPG. For example TRIG:LI00,205 on base beam code 11 currently has 54 substitute beam codes defined which deactivate the trigger whenever the FLIP PNET modifier bit is not set. This trigger uses the default behavior for the balance of the substitute beam codes in the set defined for base beam code 11 in micro LI00.

The PDU diagnostics touch panel can be reached from most timing touch panels by selecting

and then

. The following steps perform a non-invasive test of the selected PDU.

1. ENTER  MICRO

   selects a micro.

• ENTER  PDU

  selects a PDU unit. If the PDU is offline, OFFLINE is displayed instead of the crate number and an error message is issued.

• ENTER  BEAM

  selects a base beam code number. Enter ALL* for all beam codes with rate. If a beam code is entered which has no rate, a warning is issued.

• ENTER  SUBST   BEAM

  selects a specific substitute beam code in the range appropriate for the selected base beam code. The substitute beam code must be entered in hexadecimal because that is the form the substitute beam code is displayed on the PNET 1 MICRO display. If the base beam code is ALL*, then no substitute beam code is displayed.

Once a specific PDU, base beam code, and substitute beam code have been selected, the user can select one of three actions:

1. FULL  PDU   TEST

   begins a test in which the actual timing delay for each PDU channel is measured by the STB. If either the base or substitute beam codes are ALL*, then the software looks for an active substitute beam code to make the measurements. The display shows the programmed value in the PDU and the actual measured delay by the STB which must agree within 2 counts. Delays are measured only for PDU channels that are programmed in PP or reuse mode.

• SHORT  PDU   TEST

  displays the base beam code settings from the TMATRIX and the values programmed into the PDU. The substitute beam code values are not checked. Any errors here indicate a PDU programming error or hardware failure.

• REINIT  PDU

  reinitializes the PDU and follows with a Short PDU Test.

Even with these enhancements it is still possible that a PDU channel fails the diagnostics. When a failure occurs, the channel could either be faulty or it could be inhibited from triggering under the current running conditions because of an RGBM expression. An RGBM expert should be consulted before declaring the PDU channel as bad.

Display Latest Wire Scan

February 17, 1994

After each successful wire scan is performed, the selected GADC readout and wire position data are now written to a file in directory SLC_WIRE_DATA. The filename is based on the wire database name (PRIMARY, MICRO, UNIT), wire name secondary (WNAM), and the beam (E for electrons, P for positrons, S for savanger) (ie, WIRE_LI28_0144_X1_E.DATA). This file is in ASCII format and can be viewed from a terminal window. A maximum of three files with the same name are kept. When the three file limit is reached, the file with the lowest version number is deleted and a new file is created.

The new button

located on every wire panel, recalls the last successful scan from these files. The data is put into correlation plots and a fit is performed. The type of fit depends on the fit type selected on the Scan Options Panel

button when the data is recalled. Since the data is in correlation plots, other fit types can be performed.

The same criteria exist for reading in wire data from these files as with performing a single scan. The selected wire must be on the panel the

button is pressed from and a valid BPM definition must be selected.

A timestamp check is performed when reading file data. The timestamp written to the file must match the timestamp that was put into the database when the fit results were loaded. Since this feature is meant to keep the file data and the database consistent, the user is asked if the file can still be used if the timestamps are different.

When the first fit is performed with the data retrieved from the files, the data acquisition time is displayed on the bottom left corner of the plot so users will know the age of the data. If a new fit is performed, the timestamp goes away so there is no way to tell from the plot that this is old data.

In order for this feature to work correctly, all SCPs running wire scans must run this new software. If the file data and database timestamp continually don't match, the SCP running the wire scans should be re-SCPed in case it is using old software and not writing out wire data to the files.

The Realtime CUD now plots history data

January 18, 1994

Have you ever been afraid to restart (i.e. warmslc) the RTPLOT CUD process on the VAX because the realtime displays are then erased and data already plotted is lost? A new feature has been added which will alleviate your fear. The RTPLOT process now gathers up and plots history buffer data at initialization time. When RTPLOT is restarted, the realtime CUD screens come up initialized with the last 3.5 hours of history data for each data item being plotted. RTPLOT then continues drawing current data as it's acquired just like it always has.

The history data used by RTPLOT is gathered by the history buffer process once every six minutes. However, the CUDs are usually set to update the screen once every 20 or 30 seconds. This means that the 3.5 hours of history data which are plotted at initialization time do not display the same granularity seen on the plot of the current data.

MPS Trip Logic Verification

February 23, 1994

Trip Logic Verification (TLV) has been added to the new Machine Protection System (MPS). TLV attempts to verify that the MPS system is properly responding to faulted devices. To accomplish this, TLV attempts to simulate faulted device conditions and verify that the MPS system correctly registers these faults and responds as designed.

TLV currently tests hardware paths from 1553 modules via the 1553 bus to the algorithm processor (AP) VME micros, and from there to the VAX. It is recommended that TLV be run after a new algorithm is downloaded and on some periodic basis like once a month. Unlike AP and CAMAC verification, which are automatically performed on a periodic basis, TLV can only be performed on user request since it is invasive. The TLV expiration time can be set up by the user so that MPS will automatically halt if TLV has not been run recently.

TLV does not test algorithm logic. However, the MPS Algorithm Simulator (available offline) can be used to test algorithm logic. Also, TLV does not test the connections between APs and the Supervisor, and between the Supervisor and MPG. Any problems with these connections are immediately detected and reported during normal MPS operation. Problems with these connections either result in rate-limiting to zero or loss of beam permit.

TLV accomplishes its job of simulating device faults by changing the trip registers in the 1553 modules supplying device input to the AP. These trip registers are set up by applying the proper configuration commands to the CAMAC port of a 1553 module. The data from the trip register then override the data from the device. In addition to the trip register, the polarity register on the LDIM module and the TLV threshhold on the PIC module are also be configured so that the bits are tripped to the correct state.

When TLV is run for an AP, each 1553 bit used for each device in the currently downloaded algorithm is tripped, one at a time. After a bit is tripped, TLV verifies that the bit value has changed appropriately in the data that is sent up to the VAX by the AP. The bit is then restored before the next bit is tripped. Any errors found during the test are logged and prevent the trip logic expiration time from being updated.

Certain circumstances can prevent TLV from testing a device. Devices that are bypassed cannot be tested by TLV, nor can PICSs that are currently tripped. These situations are also recorded in the error log.

Users must be aware that beam is suppressed during TLV since real device input is overridden by test input and the machine is not protected. Since running TLV takes a significant amount of time (on the order of 15 to 30 minutes depending on how many devices are in the algorithm), users will need to coordinate with operations for a good time to make the run, preferrably when beam is gone for other reasons.

The TLV panel can be reached from the AP Control Panel via the MPS System Panel. Buttons on this panel include:

1. Start  TLV

   starts trip logic verification for the selected AP.

2. Abort  TLV

   aborts trip logic verification for the selected AP.

3. Change  TLV   ExpTim

   changes the expiration time of the last trip logic verification run which will dictate when MPS halts due to TLV expiration.

Back to top of this issue

Translated from original PlainTeX by index2html.pl.