October 23, 1997 All That Fits is News to Print Vol.10,No.5

Contents of Vol.10,No.5

  1. PEP-II Beam Abort System
  2. PEPII Beam Abort Trip Logic Verification
TeX source

Page contact and owner at end of this issue.

PEP-II Beam Abort System

October 7, 1997

Author: Tom Himel Subsystem: PEP-II User Impact: Large
Panel Changes: Many Documentation: Yes Help File: Yes

Basic Purpose of the Beam Abort System

The stored beam at PEP has a very large stored energy. If a stored beam current of more than 100mA were lost all at one point, it could melt a hole in the beam pipe. Note that the HER design current is 1000mA and the LER design current is 2100mA.

The beam abort system is intended to detect problems that would make the beam get lost and to cleanly extract it into a dump instead of letting it exit at an uncontrolled location where at worst it could damage things, and at best it would irradiate things and perhaps trip a BSOIC (Beam Shut Off Ion Chamber). In fact the latter two things have already happened during uncontrolled beam dumps.

The beam abort system also puts all the injected beam rate into the tune-up dump when it trips. This makes sure the operator has a chance to correct the problem that caused the trip before injection continues. It also serves to protect valves and stoppers from having beam injected through them.

There are two completely independent beam abort systems: one for the HER and one for the LER. The HER system is complete except for some inputs which aren't yet finished. The LER system is not yet installed.

The beam abort system consists of 4 basic parts:

  1. A set of inputs such as ``valve is out''or ``klystron is OK''
  2. A large distributed AND gate which combines these inputs together to make a single output. This is called the Beam Abort Trigger System (BATS).
  3. The beam abort kicker and its pulser which are triggered by the output from the BATS and which kick the beam into the beam abort dump.
  4. A connection from the BATS to the master pattern generator micro (MPG) which uses a modifier bit to force the injected beam into the HENIT tune-up dump.

The beam abort system was designed, implemented, and tested by many people. Randy Champion and Jeff Olsen did the BATS hardware. J. J. Lipari, Jeff de Lamare, and Artem Kulikov did the beam abort pulser control. Phyllis Grossberg, Ken Underwood, Tony Gromme, Sandra Bes, and Nancy Spencer did the software.

Overview of the Controls Implementation

The hardware for the BATS consists of two newly designed CAMAC modules: the BATC and the BATP. There are two BATC (Beam Abort Trigger Clock) modules: one for HER in IR10, and one for LER in IR08. Note that these are located near the abort kicker (which is near the injection kickers). From now on I'll just talk about the HER system. You can assume the LER will be very similar when it is installed. The BATC module generates a clock which is sent around the ring to a series of BATP (Beam Abort Trigger Processor) modules. Each BATP accepts eight failsafe inputs. There is typically one BATP in each IR hall (IR08 has two because it has both RF and a bunch of power supply inputs). When any input goes away, the BATP interrupts the clock from the BATC. The BATC detects the loss of the clock and fires the beam abort kicker. It also sends a signal to the MPG (Master Pattern Generator) to fire the kicker at the end of the injection line to inhibit further injection. The BATP and BATC latch the cause of the beam abort so the user can tell what caused it.

The beam abort system takes advantage of the large base of existing control system software. It is primarily implemented using the ``new" MPS software and digital status. To see the touch-panels associated with it, go from the


to the


panel to the


panel. This panel uses digital status to read bits from the BATC and BATPs to show the overall status of the system. The HER CLOCK STATUS will show either ON (the clock is going which means there has not been a recent fault) or OFF (There has been a fault which hasn't been reset. Injection will be inhibited.) Just to the right of that, the two MPG statuses show whether injection is being allowed (OK) or not (FAULT). These two statuses should always be the same as they are redundant copies of the same signal. The bottom rows of the panel show which BATP has a fault latched that was the cause of the beam abort. Then there are buttons to take you to each micro for details about its inputs.

You can get the status of the beam abort kicker and pulser by hitting the


button on the Beam Abort Trigger panel. This panel and the KICK#1 INTLK PANEL that you can get to from it use digital status to show the state of the manyinterlocks associated with the pulser. If any of these are red the pulser sends a signal to the BATC saying that it is bad, and the BATC will inhibit injection. This status is shown on the BATC panel (which you can get to with the button in the lower right had corner of the BATS panel).

Basic Operating Guide for the Beam Abort System

How to Know If and Why It Has Kicked Out the Beam or Is Rate Limiting You

Usually you'll first notice the beam suddenly disappear, or you will be trying to inject, and can see the beam on the tune-up dump even though you asked to inject it into the ring. There are two ways to see if the beam abort system is the cause: the over head MPS SDS (Machine Protection System System Display Summary), or the BATS panel. The first way is most useful if you're not sure what is going on, or to diagnose obscure problems. If you already suspect the BATS is the cause, then the second method is most expedient.

Using the MPS SDS to See If the BATS Is Tripped and Why

The MPS SDS (Machine Protection System System Display Summary) is an existing display and software that has been extended slightly to include the BATS. It is a display that is normally shown on one of the overhead monitors. It has four rows of colored boxes at the top and an area of scrolling messages at the bottom. The box in the column labeled PEP2 RING and the row labeled MPS (Machine Protection System) will be red if the BATS is faulted. In fact, since at the moment the BATS is the only machine protection system for the ring, if the box is red, then it is definitely caused by the BATS. In this way, at a glance, you can tell if the BATS is faulted. Note that there can be up to a 10 second delay before a new fault is displayed.

If the fault has happened recently, the messages on the bottom part of the display will show the exact cause. The most recent message is shown at the bottom. A typical message is: {center} 1653 PR12 HER Kly1 LATCHED TRIPPED {center} This tells you that at time 16:53 a klystron in micro PR12 (which is in PEP interaction region 12) tripped off. The LATCHED in the message refers to the fact that this is the latched output of the beam abort system, not the present value. More on that later.

If the cause of the fault has scrolled off the MPS SDS display, it can still be found using the MPS SDS touch-panel and display in the SCP. This is standard operating procedure and most operators know how to do it. However, since there are a lot of new PEP users, I'll describe it here. Experienced users can skip to the next section.

To get details about the cause of the trip from the SCP do the following. From the INDEX panel, select




buttons. To view the normally overhead summary display, select


To view the problems or devices behind a box on the screen, select the button that has the name of the row and the button that has the name of the column you are interested in. For the beam abort system select




This will show all the problems in the selected box. The


will produce a list of all the beam abort inputs.

Using the BATS Panel to Determine the Cause of a Trip

Go to the Beam Abort System panel (off the HER Index). If the HER CLOCK STATUS shows a red OFF bar, then the BATS is the reason for the beam loss and rate limiting. To find the more specific cause, look for a red YES bar near the bottom of the panel. This identifies the micro which had the fault. Hit the button in the bottom row under the red bar. This takes you to a panel which has details about all the inputs in that micro. When the system is complete and everything is running, this panel will have no red on it except for the one input which caused the beam abort. At present, some inputs have not been implemented and hence they show both a red FAULT bar and a red BYPASSED bar. So one has to look a little carefully to find the actual fault. Here's how. Each input has 3 squares on the touch panel associated with it. They are fairly clearly labeled. There is a real-time input, a bypassed indicator, and a latched value. These are arranged it two groups of three rows on the panel. The bottom row and the fourth from the bottom row show latched values. The one of these that shows red FAULTED is the cause of the beam abort.

Here is a bit more detail about the three indicators associated with each input. The real-timeindicator shows the present value (alright, it may be a few seconds old) of the input (OK/FAULTED). This is not affected by whether the channel is bypassed. The bypassed indicator shows whether the input is bypassed. A bypassed input will never cause a fault. A channel is bypassed via software which does a CAMAC operation to the BATP module. Control of bypassing is handled via the new MPS system and is password protected. More details are given in a later section. The latched indicator attempts to show the input which actually generated the abort. If two inputs occur within twenty microseconds of each other they may both be latched. As its name indicates, the latched indicator stays there until the BAT system is reset by the operator. This allows one to determine the cause of an abort even if it is a transient.

Other Reasons the Beam May Stay on the Tune-up Dump

If the beam abort system is OK and the BeamTo HENIT Dump button is set to AUTO but the beam still remains on the HENIT dump instead of going into the ring there are three more things to check: the MPG queue of bunches to inject, the injection timing feedback, and the timing setup of the HENIT dump.

To check the first two things, go from the PEP-II index to the BEAM Option Control panel to the PEP2 Inj Diag panel.



to look at the status of the MPG queues. There are two queues for the HER (and two for the LER). If both HER queues are empty(as opposed to active) then there are no requests for bunches to inject into PEP and hence the MPG directs the beam onto the dump. To fix this, you can either execute a diagnostic list from this same touch panel or use the BIC (Bunch Intensity Controller) EPICS screen to inject. These two methods correspond to the two queues shown on the queues status display.

Inhibiting of injection due to injection timing feedback is less likely to be a problem and the mechanism is a bit obscure. However, it is included here for completeness. Injection timing feedback is turned on and off from this same touch panel using the

P2 Inj

button. It should normally be on. This feedback compares the timing of the injector (linac etc.) with that of the ring timing system. The timing hardware is designed so that this loop should normally have to make no corrections. However, if there is a power dip, or we unlock the PEP master oscillator (say for a dispersion or chromaticity measurement) then this loop detects the timing difference and fixes it. At this time it inhibits injection because the error in the timing systems could make an injected pulse go into the wrong bucket. It does this for just a few seconds and it outputs a global error message like: {center} MP00 HER bucket 0 synch offset changing: old =27335, new =27339 {center} So, unless something about this loop is broken and you are getting a constant stream of these messages, it isn't the cause of the beam staying on the tune-up dump.

To check the last possibility, go to the PI11 TRIG panel. TRIG PI11 102 is the trigger for the HENIT tuneup dump. Make sure it is deactivated on all beams (there are displays to check this and a button to deactivate it if it was activated). There is no good reason for someone to activate this trigger, but maybe someone did.

Recovering from an Abort

After you have determined the direct cause of an abort, you should determine the root cause, reset the device which caused the abort and then reset the abort system itself. How you reset a device depends on which one it is. If a valve or stopper has gone in, you should check why it went in (vacuum pressure too high, or BSOIC trip) and then remove it. If the RF has tripped off, check what happened (cavity vacuum, or an arc, or reflected power), take any necessary corrective action and then turn it back on. Sometimes the RF trips off and then turns itself back on. In either case, it takes about a minute for the RF to come fully on and settle down. It will not remove its fault from the beam abort system until this has happened. If a bad orbit is detected using a couple of special BPMs, it doesn't need to be reset at all. Power supplies that trip off must be turned back on and so on.

When we are running at high currents, the sudden loss of beam often causes the RF to trip off. So be sure to check that, even if it wasn't the cause of the abort.

After you have corrected/reset all the bad inputs, reset the beam abort trigger system itself by hitting


on the main beam abort panel. If it doesn't reset, then look for more bad inputs as explained above.

Manually Stopping Injection into the Ring

As mentioned above, the BATS automatically will kick the beam into the HENIT tune-up dump when it has fired. One often wants to do this anyway, even if the BATS hasn't fired. We do this to stop filling the ring for example. The method of doing this has changed since the BATS was given the power to rate-limit the beam. This is done using the


button. Each time it is pressed it toggles between ALL and AUTO. ALL means it will always go to the HENIT tune-up dump. AUTO means the BATS system determines whether it goes to the dump or into the ring. This single button effectively controls the triggers to both the injection kicker and the HENIT dump kicker. The mechanism is described later. The BeamTo HENIT Dump button is available on the PEP-II TUNE PANEL which is available off the PEP-II Index. It is also available on the PEP-II INJ DIAG panel.

Changing the Timing of the Injection Kicker and HENIT Dump Kicker

The mechanism used to automatically stop injection into the ring when the BATS has fired necessitated a change in how the timing of the HENIT tune-up dump and HER injection kicker were controlled. In the past one changed the TDES of TRIG PI11 102 and TRIG PR10 110 respectively to change the timing of these kickers. Now one must change the the TiMing VAriable TMVA) associated with the kicker. These are named ``T_DUMP_BYP_H" and ``HER_INJKTIME" respectively.

TMVAs are an established part of the control system that most operators know how to use. For the new PEP-II people, a brief description is given here. From the INDEX panel hit


and then


If you have forgotten the name of the TMVA associated with the kicker you can get a list of the names by hitting


. To change a setting, hit


and type in the name of the TMVA you want to change (T_DUMP_BYP_H for the HENIT tune-up dump or HER_INJKTIME for the injection kicker). Next, hit


and enter the desired time. Timing variables (TMVAs) can also be stepped with correlation plots. For the step variable simply enter TMVA and then the name of the TMVA you want to vary.

Bypassing an Input

At times it is necessary to bypass an input to the BATS. This is typically done if an input is known to be broken (or it doesn't exist yet) and we are confident that some other protection system or an administrative procedure (such as keeping the stored beam current under a certain value) will prevent damage to the accelerator. Bypassing the input allows us to continue running while the problem is awaiting repair. Bypassing an input should not be done lightly. This is reflected in the fact that it is one of only two operations in the control system that requires a password. The EOICs (lead operators) have this password and should normally be the ones to do this bypassing.

To bypass a BATS input, one uses the new MPS system in a manner identical to that used to bypass all the other new MPS inputs. One should be careful that some inputs are put into the BATS twice for redundancy. For these cases, both inputs must be bypassed or unbypassed. Usually these inputs have the same name except that one has a suffix of R (for Redundant). To bypass an input do the following. From the BATS panel select


and then


Next select the primary, micro, and unit of the device you want to bypass. To do this first hit


Available primaries will be shown in the bottom two rows. Choose


Then a set of micros will be displayed in the bottom two rows. Choose the micro, e.g. PR04, that has the device you want to bypass. Now the bottom two rows will display the names of the inputs to the BATPs in that micro. If there are more than 14 of them, you can hit the


in the bottom right hand corner to see the rest of them. Select the input that you want to bypass. Now hit


You will be prompted for your name, an expiration date, an MPS privilege account, and a password for that account. Answer the questions properly, and the input will be bypassed.

The bypass will automatically expire (the input will become active again) at the expiration date you enter. Shortly before that, the MPS system will warn the operators that the bypass is about to expire to give them a chance to extend the bypass time. It is also possible to get a list of all bypassed devices. Having software bypasses like this with expiration dates and lists helps prevent people forgetting that a bypass is in place. This is preferable to a jumper wire placed somewhere out in a electronics rack.

To unbypass an input after a problem has been fixed, follow the same procedure as for bypassing an input, but hit the UNBYPASS DEVICE button instead of the BYPASS DEVICE button.

Details of the Beam Abort System

For people who are interested in how the system works rather than just how to use it, more details about the system are presented in this section. These details will also prove useful when unusual things happen with the BATS, or as an aid to checkout and trouble-shooting.

The following sections give information on the central part of the abort system (BATS), the inputs to the abort system, the kicker and dump, the method used to implement the rate-limiting of the beam, and how to test the system.

The Beam Abort Trigger System
A Modular System to Allow for Easy Expansion

The BATS for each ring consists of a single BATC (Beam Abort Trigger Clock) CAMAC module and multiple BATP (Beam Abort Trigger Processor) CAMAC modules. Each BATP handles up to eight inputs. Presently there is one at each IR and two at IR 8. The system is designed so that more BATPs can easily be added to handle new inputs. Full details of the modules are available in the Hardware Manual (actually they haven't been put in there yet). A few select details are given here.

The BATC puts out a 2.5\,MHz clock which is routed in two directions (clockwise and counter-clockwise) roughly halfway around the ring. Each clock then goes into a BATP module and is then daisy-chained through a series of cables and BATP modules back to a clock input of the BATC. If an input to a BATP goes bad, it interrupts the clock. If the BATC sees three consecutive missing clock pulses, it sends a signal to fire the beam abort kicker.

Since this is an important safety system, every attempt has been made to make it reliable and failsafe. A clock is used to connect the modules instead of a simple level so that if the signal gets disconnected or shorted to anything reasonable it will cause an abort. Three clock pulses are required to be missing to avoid noise causing an abort. Also a single missing clock pulse is used to test the system in a manner described in a later section. The inputs to the BATPs are 5 volts for OK. Again, a disconnected cable (the most common failure) will cause an abort. Inside the BATP and BATC most of the signal paths are redundant. The redundant signals go through separate programmable logic devices. The output from the BATC to the kicker pulser is redundant (two separate cables) and failsafe (5\,V for OK). If power is lost to a BATC or BATP an abort will be generated.

The BATC has a few direct inputs which can cause beam aborts. Response to these inputs will be faster than inputs to a BATP since one doesn't have to wait for the signal to propagate on cables up to halfway around the ring nor does one have to wait for 3 clock pulses. In fact, one of these inputs causes an immediate abort. It doesn't even wait for the ion-clearing gap to fire the kicker. This input is used for the beam loss monitor (BLM) system. Since beam losses won't occur until part of the beam is actually scraping the vacuum chamber, we felt that a very fast response was needed in order to extract the beam onto the dump before the rest scraped on the chamber.

The BATC also has a handshake with the abort kicker controller. If the abort kicker controller thinks the kicker pulser is failing (for example the high voltage is dropping) it sends a signal to the BATC which then tells the kicker to fire. In this way the beam is extracted before the kicker fails and makes this impossible. A second signal saying the whether the kicker pulser is OK or bad is sent to the BATC. If the kicker is bad, the BATC won't attempt to fire it as a partial amplitude kicker pulse could damage the vacuum chamber near the dump.

Synchronizing the Abort Kicker to Fire in the Ion Clear Gap

The abort system is designed to fire the kicker when the ion clearing gap is passing by. The idea is that during the ion clearing gap (when there are no populated bunches in the ring) the kicker rapidly ramps up to full strength. It then gradually ramps down (over 7 microseconds). The rapid ramp-up during the gap avoids letting beam hit the beam pipe and edge of the dump. The gradual ramp down scans the beam across the dump to distribute the heat load and avoid damaging the dump or the exit window of the vacuum chamber.

The timing for the kick comes from the PEP timing system. TRBR PR10 313 BATC10 (a base rate trigger) is used to generate a continuous pulse train every ring turn (7.3 microseconds). This signal goes to the BATC which fires the kicker on the first pulse in the train that occurs after a beam abort signal. Since the timing system is not fail-safe (it is easy to turn off the TRBR pulses from the SCP), the BATC has a backup mechanism for firing the kicker. Basically, if there is an abort signal and no pulse is seen from the TRBR within 7.3 microseconds, the BATC will fire the kicker anyway. This firing would then be unsynchronized with the ion clearing gap.

In fact, to gain speed, when the special beam loss monitor input to the BATC shows a fault, the kicker is immediately fired without waiting for the ion clearing gap.

To time in this TRBR and to check the operation of the abort kicker, there is a phosphorescent screen mounted in front of the dump. PEP video channel 2-34 can be used to view this screen for the HER.

Zero, One, and Two Kicker Mode

The beam abort system was designed to allow for the use of two abort kickers (for redundancy). The idea was that on each abort it would fire first one kicker and then 7.3 microseconds later, the second kicker. That way if either kicker malfunctioned the beam would still be cleanly extracted. At present we have only one kicker per ring.

The BATC has the necessary logic to handle zero, one, or two functioning kickers. The number it expects can be set by using the new MPS system. It is called kicker modeand can have values of zero, one, or two. We normally use kicker mode one. The present value of kicker mode can be viewed on the BATC panel which is available off the main BATS panel.

Here is a short description of how the BATC functions in each of these modes.

Inputs to the Beam Abort System

Here are some specifics of the inputs to the beam abort system. We first list those which actually exist now and then those which should be completed within the next few months. As this is a general system with extra inputs available, presumably other ideas will be implemented in the future.

All of the above inputs are presently in use. The following inputs are planned for implementation in the next few months. They presently show on the beam abort panels and are bypassed.

Implementation of Beam Rate Limiting

This section assumes a reasonably good knowledge of the SLC control system.

The BATC outputs a signal which indicates whether injection should be allowed. This goes on a dedicated cable (actually two as the signal is redundant) to an IDIM in the MPG's CAMAC crate. The MPG reads the bit on every 1/360 second interrupt.

The MPG uses this bit and THE other inputs that may effect rate limiting that were described in a previous section. It decides if the pulse should go to the ring or the HENIT tune-up dump.

Based on this decision, it outputs a modifier bit on PNET. This bit is named DUMP_BYP_HER. A value of one means the beam pulse should go to the dump.

The trigger for the HENIT tune-up dump (TRIG PI11 102) has a conditional expression that says if the DUMP_BYP_HER bit is on then fire the kicker with the timing variable (TMVA) T_DUMP_BYP_H.

The trigger for the HER injection kicker (TRIG PR10 110) has a conditional expression that says if the DUMP_BYP_HER bit is NOT on then fire the kicker with the TMVA HER_INJKTIME.

Testing the Beam Abort System

There is an automated program which continuously tests the central beam abort trigger system. It is described in the next article. While it thoroughly tests the central system, it doesn't test the actual inputs. For example, if the microswitch on a vacuum valve gets welded shut, or someone makes a wiring change that always puts 24 volts into a BATP input, the automated test won't find it. Hence it is necessary to do a manual test of each input.

At the beginning of each run we should manually test each beam abort input. To do this, first clear all abort inputs and enable the beam abort system. The ring will have to be locked up to do this since the valves and stoppers cannot be removed otherwise. Then trip each input one-at-a-time, re-enabling the BATS in between. For example, close a vacuum valve, check that the BATS fired, open the valve, reset the BATS, repeat for each vacuum valve. Then go on to the klystrons, pumps, and so on.

PEPII Beam Abort Trip Logic Verification

September 12, 1997

Author: Phyllis Grossberg Subsystem: PEPII User Impact: Large
Panel Changes: Few Documentation: Yes Help File: Yes

The Beam Abort Trigger System (BATS) monitors equipment in the PEPII rings, both dumping stored beam and inhibiting further injection when it detects a device failure. The MPS Beam Abort Trip Logic Verification (BATLV) monitors the BATS, sending error messages when it detects that the BATS is not responding correctly to device failures. BATLV does not invoke ring dumps and it only inhibits injection temporarily while the offline test is running.

There are two BATLV tests, online and offline, and there is an ON/OFF toggle button for each test on the MPS BATS Diagnostic panel. Only one of the two tests can run at a given time and software assures this requirement. The MPS BATS Diagnostic panel is reachable from MPS panels or from PEPII panels.

From the SLC INDEX:





From the PEP-II INDEX:






Each test systematically trips each device in each BATC and BATP module in each ring, then checks for an appropriate response. Each trip is performed in test mode, and normal operation of the BATS is not interrupted. If the response is not as expected for a particular device trip, that device trip is repeated. If the device fails the second trip as well, a message is sent to the SCP and the error log, indicating which device failed; and a general warning message is sent to the MPS Fault display. The test then resumes with a trip of the next device.

The tripping and checking of each device requires, among other things, that the BATS be armed, i.e., that the BATS clock be operating. Should the BATS become disarmed during a test, a message is sent to the error log when this condition is detected but the test does not stop.

The time between each trip, and therefore the total running time of each test, is database driven. When a full test completes successfully, the MPS Fault display is cleared of any warning message that was put there by a previous test. Each time a full test is completed, even if there were device failures logged, a completion time is written to the database. The last completion times for each test can be viewed on the MPS System DB display.

The major differences between the two tests consist of their philosophies of operation including who controls the test and how long it takes to run; the status of the BATS including pre-test preparations and post-test cleanup required for the offline test; and the quantity of messages that are sent to the error log during the test.

Online Test Details

It is intended that the online test run continuously under the control of MPS, being started for the first time when MPS is started, and being restarted automatically each time the test is completed. There is an MPSI HSTA bit in the database which is set to indicate that the default for this test is always ON. However, the BATLV ONLINE toggle button allows operator intervention of this continuously running test in the event that becomes necessary. When the operator toggles the online test to the OFF state, the test is stopped and the MPSI HSTA online test default bit is cleared to indicate that the default for the test is OFF. MPS will not run the test again until the operator re-toggles the BATLV ONLINE button to the ON state, causing the MPSI HSTA online test default bit to be reset which indicates to the MPS controller that it is once again in control.

The database secondary MPSI WONL defines the number of seconds between device trips and, for the online test, is set so that one full uninterrupted test of both rings takes approximately one hour. The online test restarts automatically after each completion.

The online test can be stopped with the SCP toggle button at any time before its normal completion. It can also be stopped by a request for an offline test, or by a software failure requiring that the MPS controller be restarted. In all cases, the test always restarts from the top, not from the point at which it was interrupted.

Messages with respect to the results of a device trip/check are only sent to the error log when a device fails two successive tests.

Offline Test Details

The offline test is designed to run, at operator request, primarily during those times when a ring is not armed and when there may be many unbypassed, faulted devices. The offline test may, however, be run under normal operating conditions in lieu of the online test when speedier results are desired. (The offline test takes two or three minutes as compared with the hour required for the online test.) If an online test is running when an offline test is requested, the online test will be stopped and then restarted, from the top, when the offline test has completed.

The following steps are taken before an offline test starts.

The following steps are taken when an offline test finishes.

The database secondary MPSI WOFL defines the number of seconds between device trips and, for the offline test, is set so that one full uninterrupted test of both rings takes two to three minutes.

The offline test can be stopped with the SCP toggle button at any time before its normal completion. It can also be stopped by a request for an online test. In either case, conditions set up specifically for the test will be undone as if the test had completed normally. In the event the offline test is interrupted as a result of a software failure requiring that the MPS controller be restarted, any devices bypassed specifically for the test will be unbypassed as soon as the MPS controller is again up and running.

During the course of an offline test, messages are sent to the error log and to the SCP initiating the test regarding the results of each device trip, whether that trip fails or succeeds.

Back to top of this issue

September 12, 1997 Index Panel indx105

Translated from original PlainTeX by index2html.pl.

*Links followed by an asterisk are limited to SLAC clients only.
  Last modified on Wednesday, July 26, 2006 Webmaster