Contents of Vol. 7, No. 6

1. Regional Beam Codes, BPMs and Fast feedback
2. User Entered Masks for BPM Software
3. BPM Rate and Beam Rate Displays
4. Feedback Mask and Rate Displays
5. Toroid Timing in the Calibration Mode
6. General User-defined Dithering with Buffered BPM Acquisition
7. MPG Rate Change History Display
8. Zen and the Art of Veto Bus Diagnostics
9. RTL Steering Watchdog

Page contact and owner at end of this issue.

Regional Beam Codes, BPMs and Fast feedback

September 3, 1993

This article tries to answer the burning question: ``How does BPM data acquisition work now that Regional Beam Codes software is in place?'' With Regional Beam Codes, there are schedulable beam code modifiers. These can be displayed or modified from the Beam Group Control Panel, available from the Beam Options panel. Several of the schedulable modifiers are associated with BPM and fast feedback acquisitions.

The BPM acquisition and fast feedback BPM acquisition software use inclusion and exclusion masks to determine on which pulses the data acquisition should occur. Every display group which is used for BPM acquisition should have an exclusion and an inclusion mask (DGRP database secondaries EXCM and INCM). With the Regional Beam Codes system, the beam codes are ordinarily generated at 120 Hz even when the machine is rate limited. The exclusion masks are used to prevent the BPM software from taking data when the beam is not present. For example, the ``NO_EXT_ELEC'' indicates that extracted electrons are not present. An additional complication for BPM acquisition is that a dumper or similar device may be in the middle of the display group. In this case, if the user is measuring only devices which are downstream of the dumper, it will ignore the dumper exclusion. However if the user is measuring BPMs which are downstream of a dumper, the measurement does not take place on dumpered pulses. The exception to this is if a dumper is firing all of the time, it is ignored to prevent software timeouts.

The inclusion mask also limits the rate of BPM acquisition; if a beam code modifier bit is in the inclusion mask, the acquisition will not take place for pulses on which that bit is not scheduled. Adding bits to either the inclusion or exclusion mask has the effect of limiting the rate of the acquisition.

BPM data acquisition for fast feedback has a separate database setup. Each micro has an exclusion mask and two inclusion masks (CSTR secondaries EXCM, INM1 and INM2). When a micro associated with fast feedback is IPLed, it begins acquiring data at a rate determined by these masks even if the feedback loops are off. In some micros, the BPMs are multiplexed. In other micros, the fast feedback needs to acquire electron and positron data on separate pulses. The INM1 inclusion mask indicates on which pulses the micro may begin a single acquisition. The INM2 mask applies to subsequent pulses required for the same acquisition.

In some cases, the feedback loop may need to limit the rate at which it runs beyond the rate of BPM acquisition. This is needed in order to provide synchronization for cascaded feedback loops and to limit CPU usage. In order to accomplish this, each feedback loop has an additional inclusion mask (FBCK database secondary INCM). This feedback loop inclusion mask limits the pulses on which feedback runs to those pulses in which the associated inclusion bits are scheduled. There have been recent problems with cascaded feedback loops which acquire both electron and positron data. The FBCK inclusion mask must include a beam code modifier bit which is scheduled at no faster than twice the beam period in order to provide adequate synchronization. (If this sounds complicated, maybe that's why it was so hard to get it right). When these masks are set up incorrectly, it is possible that the feedback will always have missing measurements and will not function.

User Entered Masks for BPM Software

September 1, 1993

A new function, called User Entered Inclusion and Exclusion Masks has been added to the BPM software to help predict Beam Rates and BPM Rates before implementing them on the SLC Control System. The Exclusion and Inclusion Masks entered by the user only affect BPM software in that SCP.

The new More BPM Diagnostics panel includes this function in addition to all of the functions from the old BPM Track-and-Hold Panel. One button exists to Toggle between DGRP which uses the Exclusion and Inclusion Masks as defined by the SLC database primary DGRP secondaries EXCM and INCM, and USER which uses the Exclusion and Inclusion Masks provided by the user with the buttons on this panel. Several other buttons allow the user to add and remove bits from the User Inclusion and Exclusion Masks. Help for the individual buttons exists on the SCP panel. Another button displays a listing of the Exclusion and Inclusion Masks. Both the hexadecimal values for the Masks and the Beam Modifier name(s) along with its corresponding PNET broadcast bit(s) are displayed. Buttons also exist to display the configured BPM Rate and the configured Beam Rate.

Please see the following article for an explanation of the BPM Rate and Beam Rate Displays

BPM Rate and Beam Rate Displays

September 1, 1993

Two new buttons have been added to the BPM Calibration Panel to help with the display of BPM and beam rates under the new regional beam codes system.

The

will display the rate at which BPMs can be read for the currently selected BPM Definition. It also shows the currently selected Rate Limiting Type from the MPG with an arrow. A rate and pattern is displayed for each Rate Limiting Type. If the BPM rate changes in the middle of the selected BPM definition, which it often will, then a new line is added indicating the rate and pattern change.

The

will display the rate in which the Beam passes through the currently selected BPM definition. It also shows the currently selected Rate Limiting Type from the MPG with an arrow. A rate and pattern is displayed for each Rate Limiting Type. If the Beam rate changes in the middle of the selected BPM definition, which it often will, then a new line is added indicating the rate and pattern change.

Both the BPM Rate and Beam Rate Displays will apply User Entered Exclusion and Inclusion Masks. The display header will indicate whether USER Masks or DGRP Masks are used. DGRP Exclusion and Inclusion Masks are defined in the SLC database primary DGRP. Please be aware that the User Masks are not run through the Regional Beam Codes Auxiliary Bit substitution algorithm.

Two special rate displays are available from the BPM Calibration Panel. The Extracted  Rate Display will display the beam rate for the NDR_ELEC display group and the Extracted  Rate Display will display the beam rate for the SDR_POSI display group.

Please see the previous articles for an explanation of User Entered Exclusion and Inclusion Masks. Help for the individual buttons exists on the SCP panels.

Feedback Mask and Rate Displays

September 1, 1993

Two new diagnostic buttons have been added to the Feedback Cascade + Calib Panel.

The

button displays the Inclusion mask for the selected feedback loop followed by the Exclusion and Inclusion Masks for each of the measurement micros in the selected feedback loop. Both the hexadecimal values for the Masks and the Beam Modifier name(s) along with its corresponding PNET broadcast bit(s) are displayed.

The

button displays the current Rate Limiting Type from the MPG along with the rate in which the currently selected feedback loop will take measurements. There is a rate and pattern displayed for each measurement micro.

Toroid Timing in the Calibration Mode

August 16, 1993

The BPM Timing Panel has been modified to allow timing of Toroids in Calibration Mode. The new

button allows the user to toggle between MEASUREMENT MODE and CALIBRATION MODE when TORO is the selected device.

In the past, one had to connect an oscilloscope to the Toroid's CAMAC module and use a local CALF to repeatedly run the Toroid Calibration from the BPM Diagnostics Panel while capturing the Timing System's Channel 11 pulse superimposed on the Toroid's damped sine oscillation. This operation may now be performed remotely from any SCP.

General User-defined Dithering with Buffered BPM Acquisition

September 1, 1993

``Dithering'' is a technique of rapidly varying some controlling device by some small amount while taking many samples of the resulting behavior using BPMs or some BPM-like device like a toroid, GADC, or PIOP. Typically one measures the slope of some parameter when plotted against the controlling device. Past uses of dithering have included a cathode saturation monitor which dithered the laser intensity and measured the beam current off the cathode, and the phase ramp feedback, which measured the phase of the beam with respect to the linac RF by dithering the phase ramp and measuring the beam energy in the BSY. Data acquisition is accomplished in much the same way as with wire scans and buffered BPM data taking. Advantages of dithering include speed, accuracy, and low invasiveness.

With this software release, there is now an easy and entirely general way for operators and machine physicists to define their own dither-based measurements from the SCP.

On the BPM BUFFER DATA panel, you'll notice a new button at the top labelled ``DITHER CONTRL PANEL .'' It takes you to a brand new panel where you can select the devices you wish to dither, the manner in which to dither them, and the maximum amount to dither. Everything's pretty straight-forward: there are buttons for entering up to four devices to dither, buttons below that to set the range (it dithers the specified amount about the value at which it finds the device initially), a button to take dither data, and a few other buttons that deserve more explanation (see below). Choose the BPM-like devices you want to read back on the ordinary buffered data, and the devices to dither on the dither panel. Note a weird idiosyncrasy of the acquisition software is that you must be requesting data from at least one BPM-like unit in a micro in order to dither devices in that micro.

You can plot the acquired BPM data in the normal ways on the old panel. Sorry, there are no displays of the dithered devices' values within the BPM buffer package, so you have to dump your data to correlation plot or to MATLAB to plot BPMs versus your dithered device. This isn't so bad, especially since you probably want to fit a line to your data anyway.

You can enter any prim, micr, unit you want as a dithering device, provided it's in the DGRP. If it can't dither that device for whatever reason, it will let you know in a fairly clear and reasonable manner when you ask it to take the dither data.

By the way, if you hit ``TAKE BUFFER DATA '' on the regular BPM Buffer Panel, it will not dither, regardless of what you have selected on the Dither Control Panel. I thought that was a necessary safety feature. Only the button marked ``TAKE DITHER DATA '' on the Dither Control Panel will dither the devices. However, once you have taken data with dithering, you can look at it using the display buttons on the BPM Buffer Panel, or dump to CRR or MATLAB on either panel.

Using this software, it should be possible to do many useful things in a non-invasive or mildly-invasive manner. Possibilities include parasitic measuring of R12's, fast dither-based eta measurements, and phasing of subboosters. One could imagine a macro attached to the master wire scanner loop which would track the slope of beam energy in the BSY vs. subbooster phase for each subbooster. It also may be worth considering as an alternative to correlation plots in some cases. Enjoy!

Two additional related concepts are explained below.

• Dither patterns -- for example $\{-1, +1, -1, +1, -1, ...\}$ or $\{0, 0.4, -0.6, 0.8, -1.0, 1.0, -0.7, 0.5\}$, or anything you can dream up -- are generally supported by reading in a ``pattern file'' which lists the values to be used at each step. The software provides for independent dithering of the devices. The values to use at each step (or sample, if you prefer) appear on a separate line (or row) in the file. If only one value is specified on a line, the same value is used for all dithered devices; if four values appear, each device gets its own value. (If fewer than four values appear on a line, the values are reused starting from the first one.) If your dither pattern is shorter than the number of samples requested (the usual case, I assume), it is repeated as you would expect.

• Note the values in the dither file are internally normalized, so that a pattern of $\{1, 0, -1, -2\}$ is equivalent to $\{0.5, 0, -0.5, -1\}$. This is so that the ``Maximum Excursion'' you specify is really the maximum, not just the amount of excursion for a value of 1 in the dither pattern file. (By excursion, I simply mean the amount of deviation from the initial value due to dithering.)

• Load Dither File is the button to read in a given dither pattern, and this must be done before you can take dithered data!\/(There is a reasonable error message if you fail to do this.) Currently, there is only one file defined, ``MKB:STANDARD.DIT'', a 7-pulse long sine-like thing. The file format is really obvious, so you should make your own files if a slow sine wave doesn't suit you. Like I said above, you should be able to have up to four columns of dither values which could be sine waves of different frequencies or random, linearly independent patterns -- this would let you measure the R-matrices from several correctors with a single acquisition, in theory.

• By the way, there is no default directory for these dither pattern files: it reads them from your SCP's current directory unless you specify otherwise.

• Dither mode -- DAC or DES -- In DAC mode, the amount of the excursion is specified in DAC bits; any PRIM with a DACL secondary in the database can be dithered in DAC mode. This includes subboosters, as they all have solid state phase shifters, so this is potentially a powerful and fast new way to phase sectors. In DES mode, the device must be a magnet-like primary; units of excursion are in kilo-gauss meters, or whatever the device's BDES or VDES units are.

MPG Rate Change History Display

August 27, 1993

To see a history of the MPG's rate limit type transitions, select the new

button on the BGRP CONTROL panel which is accessed from the Beam Option Control panel. This display shows up to the last few hundred MPG rate limiting changes. The display also attempts to show why the transition occurred, either via an MPS request (the MPS rate requested is also shown), or via an IDIM digital request (all the MPG IDIM bits are also shown) such as ``MC00 veto" or ``PLIC".

Online help completely describes the fields in the display.

Zen and the Art of Veto Bus Diagnostics

August 20, 1993

Most recently on the weekend of August 14/15 there were problems with diagnosing problems on the Veto system, unfortunately in Mike Browne's absence. This appeared first as a Cater concerning the Polarization Watchdog's reporting that the polarization error rate exceeded 10%. This article is the result of interviewing Mike after he repaired the system and explains how to diagnose problems in the veto system. Thanks also to Tony Gromme and Glenn Horton-Smith for their input.

The Polarization watchdog, running in PL01 was indeed getting error status (neither Left nor Right nor Zero polarization) on all pulses. This may be observed by selecting the following set of buttons:

$$

$$

$$

 This should reveal a random pattern of L and R. To verify that the data is truly bad, press the

button, then press

repeatedly and look at the veto word in the upper left. Normal values are 100000 and 200000 for L and R. 300000 means Zero, which is not good when running polarized beams, but which is NOT a Veto Bus problem.

Historical Hardware Background

To understand the diagnostics, it helps to know how the system works. The following paragraphs are from an article on the veto system by Tom Himel which appeared in the February 22, 1989 issue of the Index Panel.

The hardware consists of a new VETO CAMAC module in each micro. Each one of these has room for 16 veto inputs. In the typical linac micro eight of these are used, one for each klystron. Each input is generated by a PIOP which checks its klystron's performance and signals the veto module via the MKSU if full power wasn't generated. The VETO modules are connected together with two twisted pairs down which a 32 bit serial stream of data is transmitted after each beam pulse. Encoded in that stream is the geographical location of where the veto was generated.

In somewhat more detail, here is what happens. After each beam pulse (at 360 Hz) micro MP00 sends out a 32 bit word of all zeros on one of the twisted pairs known as the write bus. That word gets passed from one veto module to the next, going around the arc to the final focus and then back to LI00. Each veto module just passes the word on unless one of its enabled inputs indicates a veto. In that case it turns on a bit in the 32 bit word corresponding to the geographical location of the veto module (e.g. CID, LI00, NDR, LI20--30). The veto modules do not record the data at this time since it doesn't contain information from modules later in the daisy chain. They only record whether there was a parity error and the fact that the data arrived. At LI00 the data is taken off the write bus and put into the second twisted pair known as the read bus. The data gets passed back up towards MP00. Each veto module records the data word as it goes by so that its micro can later read it to find out whether a veto has occurred anywhere in the accelerator.

Software Diagnosis Procedure

Please read the whole of the article and attempt to understand the functioning of the Veto Bus system before attempting to diagnose the problem! The Zen in the title of the article refers to the holistic approach necessary to succeed.

Mike Browne starts with the

available via

$$

$$

 This steps through the veto path, starting in MP00 and following the FLNK secondary in the database, i.e. VETO, MP00, 1, FLNK points at MC00. The current order of the vetobus is: MP00, MC00, FB30, FB31, PL01, CA01, CA11, LI30-LI21, EP02, LI20- LI02, EP05, LI01, LI00. Additionally, the Final Focus and Arc group CA02, FB73, FB69, FF11, CA13, CA12 branch off at MC00, but have no VETO WRITE capability. The Damping Ring group DR11, DR12, DR13, DR01, DR02, and DR03 have the same limitation and are attached at EP05.

The Veto Bus works by propagating and modifying the WRITE signals from MP00 to LI00, then propagating the READ signals on the loop back. The two groups with no VETO WRITE are bypassed on the WRITE half of the loop and have the READ data echoed on the WRITE line for diagnostic purposes. The physical Veto Bus really connects MACH LINE boxes, and the ribbon cables to the Veto modules are plugged into these Mach boxes. If a VETO module is disconnected, the Mach box bypasses the disconnected cable; so removing a VETO module ribbon cable does not disconnect the whole system. One method of determining which VETO module is bad after localizing the problem to one of a few modules is to simply disconnect the ribbon cable and rerun the diagnostic.

Current VETO Status

Several Veto modules currently report OFFLINE (CA02, CA12, LI08, DR11, and DR01). This is NOT a problem. LI08 has deeper problems and will be fixed during the October Down, then have its VETO module turned back online. MP00 currently reports a spurious BAD CAMAC STATUS. Tony Gromme is looking at that annoyance. If there were a Veto problem, several micros would report READ errors and some micros would report WRITE errors. The bad VETO module is either the first reporting WRITE errors or the one preceding it. The most recent problem was unusual in that two VETO modules were broken at the same time, making diagnosis especially difficult. In that case, the first problem module was replaced, whereupon the symptoms changed, pointing at the second module, which was also replaced.

To see if the MPG is broadcasting PNET and VETO information, look at the MPG output via

$$

buttons. Tony also uses two buttons off the

panel. The

button prompts for a micro and displays what that micro sees, and the

button which is good for finding dropped bits, but delivers all too much data if a VETO module is broken. In that case use Mike Browne's method above.

Hardware Diagnosis Procedure

Other diagnostic tools are the ``RD MON" and ``WR MON" LEMO connectors on the front of the VETO modules themselves. An internally triggered oscilloscope plugged into one of these connectors should show two ``state" bits followed by whatever VETO data is present on the bus at that point. If the write bus is interrupted somewhere, there will be no read data present anywhere, however, write data will be present up to the point of interruption.

Other Failure Modes

Note that other failure modes involve MACH boxes and/or cabling rather than VETO module problems. It is also possible to have an interruption of the read bus without an interruption of the write bus, in which case the first micro reporting read errors or the one preceding it (on the backwards loop) may be the source of the problem.

RTL Steering Watchdog

August 24, 1993

An additional check has been added to the Damping Ring Watchdog which calculates a measure of the fractional energy offset of the beam relative to the energy for which the bend string is set. This should flag the problem caused by steering the RTL when the compressor is misphased. This calculation involves XCOR BDES values and weight factors for each. The watchdog feedback message is then: ``RTL XCOR Settings out of tolerance: - (NRTL or SRTL)". Please see the SLAC MEMORANDUM from W. Spence dated 30-July-1993 in the Damping Ring binder for further details.

Back to top of this issue

Translated from original PlainTeX by index2html.pl.