Tony Gromme 20 May 1998 rev. 18 Nov 1999 SLC Control System: Master Pattern Generator The SLC MPG's functions very briefly are fourfold: to schedule beam production pulse-by-pulse, to schedule PEP2 bunch injection pulse-by-pulse, to schedule beam-synchronized data acquisition pulse-by-pulse, and to assist in machine protection. Beam production is largely controlled by devices that output timing signals, i.e., by PDU's. Such devices are programmed to respond to the fiducial's label, i.e., to the camac F19 broadcast. On each 360th of a second, each micro derives the F19 data from the fiducial's extended label, which is the 128-bit message broadcast on PNET from the MPG to all micros. The MPG's only output (aside from error message logging) is this PNET broadcast. This PNET broadcast is received directly only by the SLC (Intel) micros; for any device to be affected by this PNET broadcast the mediation of an SLC micro is required. The MPG produces PNET output according to a script coded in a BGRP, which the MPG interprets at 120 Hz. Any BGRP thus runs in just one 120-Hz "phase" of 360 Hz. Any SCP can activate or deactivate BGRP's in the MPG (subject to restrictions imposed by the MPG), and can display and alter values of named variables in a running BGRP, thus possibly altering that BGRP's behavior. Any BGRP hopefully resembles a state machine, in which state changes are caused by changing needs for beam production and by changing conditions requiring ratelimiting. Any SCP can display the most recent BGRP state transitions with the reasons for them. Given a list of known "ratelimiting areas", the MPG maintains a current "ratelimiting state" for each ratelimiting area. Ratelimiting area here means beam path from bunch creation to eventual target or dump. Ratelimiting area names and ratelimiting state names are listed at the end of this document. In the coding of MPS "algorithms", ratelimiting area names identify the largest divisions of the code. Each beamcode that the MPG broadcasts is tagged (according to BGRP coding) with a ratelimiting area index, and this tag is sent to MPS processor SP00 across a reflective memory, thus identifying the portion of its algorithm that that processor should execute on the upcoming 360th of a second. The result of that algorithm execution is also tagged with the ratelimiting area index and sent back a few 360ths of a second later to the MPG across the reflective memory. Thus, though MPS and the MPG are quite separate hardware-wise and software-wise, they are closely linked pulse-by-pulse. The MPG senses machine-protection-related inputs from MPS and from other sources at 360 Hz, and receives machine-protection-related state-change requests from any SCP at human response rate, and at 360 Hz the MPG sets each ratelimiting area to the most severe ratelimiting state requested for that ratelimiting area. The MPG also senses single-bit inputs, including some fault detection and some hardware switches in the control room. The MPG (depending on BGRP coding) can also respond to a single-bit signal (known as "SLD window") from SLD indicating that the next eight or so 120ths of a second are usable for PEP2. The MPG can respond to faults indicated on the veto system bus. The MPG can respond to faults indicated by the PLIC system and by the beam containment system. Single-bit inputs include PEP2 beam abort signals (separate for HER and LER), which the MPG forwards on PNET to all micros, enabling micros to capture diagnostic information. The BGRP "language" includes a means of testing current state of any named ratelimiting area and a means of testing the abovementioned "SLD window" bit. Diagnosis of detected fault conditions generally requires altered (rate-limited) beam production modes. Rate-limiting is accomplished by limiting bunch production rate and by dumping selected bunches at some point; this is one of the main purposes of any BGRP. The MPG maintains a queue of BPM data acquisition synchronization requests. Each request includes a list of micros performing the acquisition. Each request is uniquely identified by an 8-bit code, called "YY". The MPG broadcasts the YY code (in its field in the PNET broadcast message) just once for any enqueued request; this broadcast causes the micros "prepp'ed" for the given BPM data acquisition to be all simultaneously "enabled" to begin the individual steps in the acquisition. "BPM data" here is meant to include various kinds of data whose acquisition has to be beam-synchronized. The individual steps in the acquisition are selected by beamcode, by a mask specifying PNET beamcode modifier bits sufficient to exclude a given pulse, and by a mask specifying PNET beamcode modifier bits required to include a given pulse. During the execution of a given BPM data acquisition request, the MPG mimics what the given set of micros are doing, in order to know when the given YY request completes. This mimicking includes mimicking the BPM data acquisition's triply nested loop: multiplexing within averaging within scan stepping. The MPG can optionally fire dumpers as part of a scan operation. The MPG ensures that no two requests whose sets of micros overlap are allowed to execute concurrently, because each micro can have at most one acquisition "enabled" at any one time. The MPG honors requests in this queue in such a way that no younger request will be started which might delay any not-yet-started older request. The MPG maintains six queues of PEP2 bucket injection requests: from BIC (PEP2 bunch intensity controller), diagnostic list from SCP, and "recovery" list for maintaining injection timing synchronization, each separate for HER and LER. The BGRP "language" includes separate verbs for HER and LER indicating pulses on which the MPG should test these queues and act on bucket injection request found if any. These queues are tested in the following order: BIC, diaglist, recovlist. Any bunch requested by the recovlist is always unconditionally dumped. The BGRP "language" also includes separate verbs for controlling intensity of bunches destined for PEP2 injection, at electron gun time and at positron production time. There are two variables (defined by default if not explicitly defined in the coding of a BGRP) giving the damping times (periods in 120ths of a second) for the north and south damping rings. Internally, the MPG maintains a number of "pipelines", representing each as an array of entries which is shifted by one entry on each pulse. This simple technique costs some CPU time for the shifting, but saves more CPU time since any entry N pulses "ago" (assuming N is a constant known at compile time) is directly addressable without any subscript arithmetic needed at run time. Such "pipelines" are accessed only by 360-Hz interrupt-driven code, never by task-driven code. For PEP2 bunch injection there are three such pipelines, representing: 1) E- bunch creation for HER; 2) E- bunch creation for E+ creation for LER; and 3) bunch extraction from north damping ring for injection into HER or from south damping ring for injection into LER. Of these three, the second keeps track of retention of an E+ bunch in the south damping ring for possible "extra" 120ths of a second for machine protection purposes before extraction. Ideally the SCP + MPG should provide a means by which operations personnel can relatively easily define or alter ratelimiting modes: depending on specified conditions, beam should be produced at specified rates and dumped by specified dumpers, etc. The present BGRP software makes a small step toward that goal. It should be noted that BGRP coding excludes knowledge of individual timing channels. Individually identified timing channels in individual micros are separately programmable (by any SCP) in terms of 5-bit beamcode, and (optionally) further in terms of logical combinations of other bits in the 128-bit PNET broadcast message. In particular, some dumpers are programmed to respond to PNET bits, in order that the MPG can contribute to the control of those dumpers. Some devices are programmed to respond to the beam containment fault bit, which the MPG senses from an IDIM and forwards on PNET. The MPG is also responsible for labeling phase of 360 Hz within 60 Hz to consistently identify "timeslot 1" of 6. A 4-bit field is reserved in the PNET broadcast message for synchronizing the pulse id (which has a wraparound period of about 6 minutes) in all micros. A single bit is reserved to mark the beginning of each even second, and is used by the micros to resynchronize the 360-Hz modulo-36 count register in each PDU. For diagnostic purposes, the SCP can retrieve one full recent second's worth of PNET broadcast messages from all micros including the MPG for the same second. The MPG synchronizes this retrieval using a dedicated YY value. In the micros, functions controlled or affected pulse-to-pulse by PNET include: Device timing. Beam production and routing. Beam intensity control. Selective beam dumping. Fast feedback iteration rates. Pulse subset selection for beam-synchronized data collection. Synchronizing BPM data collection across entire machine. Serializing use of sets of micros for BPM data collection for different requestors. PEP2 injection: request queue management; timing feedback watchdog; status reporting. Forwarding of fault signal (PEP2 beam abort) to cause individual PEP2 devices to capture diagnostic information. SCP displays based on information retrieved from the MPG (and possibly other micros) include: Source code (full or abbreviated) of selected BGRP (currently running or available to be run). List of all known beamcode modifier bit names. Recent history of BGRP state transitions (known as MGRP transitions), with reasons for those state transitions. Recent history of ratelimiting area state transitions, with reasons for those state transitions. Beamcode broadcast rates during a recent second. Most recent PEP2 injection cycles, either all cycles performed or only cycles not dumped by the MPG. Recent history of PEP2 injection timing resynchronizations. Current content of PEP2 injection request queues. Plot of recent second's worth of measurements from PEP2 injection timing hardware (PTG in LI00 = PEP2 trigger generator). Result of diagnostic comparison of one full second's worth of PNET broadcast messages retrieved from all micros for the same second. Decoding (into beamcode modifier bit names) of a recent second's worth of PNET broadcast messages (i.e., 360 messages) as received by any micro. IDIM input values for a recent second (i.e., 360 lines). List of currently enqueued YY requests (waiting or being executed). Recent history of YY requests executed. Ratelimiting area names are currently defined as follows: "NULL " Zero beamcode, or no beam. "SLC " Beam production (E- and E+) to SLC collision and dump. "HER_INJ " Beam source (E-) to injection into HER. "LER_INJ " Beam production (E+) to injection into LER. "FFTB " Beam source to FFTB and dump. "A_LINE " Beam source to A_LINE and ESA (no DR). "NLCTA " NLCTA beam only. "CRYO " Gun test lab only. All ratelimiting areas have generally the same set of possible ratelimiting states, though some ratelimiting states have no meaning for some ratelimiting areas. Ratelimiting state names are currently defined as follows: "FULLRATE" Full rate everywhere. "LIMHI_FS" E+ beam in arc or bypass limited to 10 Hz using s.b.d. "LIMHI_FN" E- beam in arc or bypass limited to 10 Hz using s.b.d. "LIMHI_FF" Both beams in arcs/bypass limited to 10 Hz using s.b.d.'s. "LIMIT_HI" Beam downstream of dumper 2-9 limited to 10 Hz. "INJLIMHI" Beam upstream of dumper 2-9 limited to 10 Hz and beam downstream of dumper 2-9 limited to 1 Hz. "LIMIT_LO" All beam limited to 1 Hz. "ZERORATE" No beam at all.