[TEG.SPEC]BPM_FUNC_SLC.TXT 23 Nov 1999 SLC Control System Beam-synchronized Data Acquisition Software 1. Overview. The first purpose of the SLC Control System's beam-synchronized data acquisition software is to provide the capability of obtaining beam position measurements made by more than one micro in such a way that all can measure the same particle bunch as that bunch travels through the machine. In the SLC, BPM data (meaning any kind of measurement data whose acquisition must be beam-synchronized) is generally acquired only on individual demand, primarily because of multiplexing of BPM processors. BPM data acquisition generally requires close cooperation among the requesting SCP, the micros acquiring the data, and the MPG (which supplies the needed synchronization via PNET). At the beginning of any BPM data acquisition, the requesting SCP sends "prep" messages to the micros involved in that acquisition, causing the BPM software in those micros to build data structures that will guide the acquisition through its steps, and to set up programming of timing channels owned by the measurement devices. After receiving status replies from these "prep" messages, the requesting SCP sends a "YY request" message to the MPG, causing the MPG to enqueue a request to eventually broadcast a "YY code" on PNET, which the micros recognize as an "enable" signal to begin the steps of the measurement. The individual steps in the acquisition are executed by a 360-Hz interrupt-driven coroutine in the micros, and 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. In each micro, as the final step of the measurement is reached, a task is awakened to perform needed data conversions, send the results to the requesting SCP, and dismantle the data structures that were built for the given data acquisition. 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 data acquisition request completes. The request sent to the MPG includes a list of micros performing the acquisition, and 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. After finding that the request has (mostly) completed, the MPG sends a reply to the requesting SCP. For acquisitions in which the data is too bulky to be extracted from measurement devices by the interrupt-driven code, the requesting SCP must explicitly notify the MPG of completion after having received the measurement data. For feeding fast feedback loops, it is possible to set up free-running beamcode-driven acquisitions (known as "sharable readout buffer rings") in any micro. Such acquisitions can also satisfy SCP demands, though if a SCP request includes units not being read out by a running beamcode-driven acquisition, then that SCP request preempts the beamcode-driven acquisition, possibly delaying fast feedback. Creation of BPM sharable readout buffer rings is generally done as part of the micro IPL procedure. The MPG knows nothing of free-running data acquisitions, and free-running data acquisitions are not synchronized among micros. For any free-running data acquisition, extraction of data from measurement devices must fit within the camac bandwidth limitation of one 360th of a second, or be aborted by an acquisition synchronized by the MPG that begins on the following 360th of a second. Non-demand-driven data acquisition does exist for TORO's, which cant be multiplexed, and which are not able to distinguish well between bunches in a multi-bunch pulse. For this kind of acquisition, the micro maintains a circular buffer, in which each entry includes pulse id, and whose contents can be retrieved by any SCP at any time. In the present version, the micro copies TORO data into this circular buffer only when demand-driven or beamcode-driven acquisitions occur. 2. Measurement Device Types. Details of the beam-synchronized data acquisition software are largely dictated by the design of the BPM processors and other measurement hardware devices. BPM multiplexers reduce hardware cost, but reading out a complete set of multiplexed BPM's once can require up to ten actual beam pulses. Such multiplexing is usually done by separate camac single-pole ten-throw switching modules. Some BPM's are time-multiplexed, such that different units (representing different sets of electrodes, possibly in different beam pipes) cabled to the same processor module are distinguished only by the timing of their PDU gate signals (and data conversion constants). Some BPM processors are capable of reading two (of three possible) bunches from the same set of input cables on the same machine pulse. The PEP2 RINQ BPMP contains a DSP, and can make measurements at ring turnaround rate using pulse-train output from PDU channels, and can retain up to 3000 measurements. Choice of bucket to be measured is made by the timing offset of the pulse-train. RINQ BPMP's are multiplexed two ways, each capable of reading a set of electrodes in one ring or a set of electrodes in the other ring for any aggregate of measurements. For both RINQ BPMP's and waveform digitizers, extraction by the micro of measurement data is interrupt-driven if the quantity of data is small, and otherwise occurs in a less time-controlled way; in both cases, the device is generally unavailable until after all data for a requested aggregate of measurements has been extracted. The software in the micros also supports readout of several kinds of gated ADC's and TDC's. Some timing output channels not owned by any beam measurement devices represented in the operational database are reserved for driving scanning devices, and can be set up (by a scan request) to fire on a subset of pulses during the requested scan; these timing channels are known as TRYY's. 3. Database Structures. In the SLC operational database, primary "BPMP" (processor) refers to physical camac module, and primary "BPMS" (station) refers to location of striplines or electrodes in beam pipe, connected by four wires (X+,X-,Y+,Y-) which may be combined in pairs down to just two wires (X-only or Y-only). In the Linac, Linac-type BPMP's and XY BPMS's are typically one-to-one, though any such Linac-type BPMP may also serve an X-only PRL (positron return line) BPMS and a Y-only PRL BPMS, distinguished only by gate timing. For Arc-type BPMP's, one XY BPMS is served by two physical modules, i.e., by a pair of BPMP's. Each EP-type physical module (capable of measuring two bunches on one pulse) is represented by a pair of BPMP units, and the station they serve is represented by a pair of BPMS units (to distinguish the bunch timings). Each of a set of BPMS's multiplexed to one BPMP is distinguished by multiplexer setting. 4. Calibration. Each different BPM device type requires its own calibration method. Some BPM calibration methods require actual beam; some require a programmable pulser to simulate actual beam; for the latter kind, gate timing is chosen to avoid any possible actual beam; such timing may be difficult to achieve in a damping ring. Data produced by calibration typically consists of channel pedestals and gain ratios between pairs of channels. The calibration operation excludes any concurrent beam measurements that would use the devices being calibrated. This exclusion is presently accomplished by the MPG + PNET mechanism that assures that within any one micro that has several measurements or calibrations prepp'ed concurrently, at most one of those measurements or calibrations is active at any one time. Since any calibratable device will typically have many calibrations available that support different beam strengths and BPM readout modes, and since any calibration made by a given SCP can be used only by that SCP until that SCP makes that calibration public, and since data produced by calibration can be somewhat bulky, this data is stored in separate files rather than in the database. After a micro has been rebooted, contents of these files must be downloaded before beam measurements using those calibrations can be made. 5. Timing Diagnostic. The SCP has a procedure which makes a series of separately prepp'ed BPM acquisitions, incrementing gate timing offset across these measurements, to "hunt" for the best timing to find beam; results are then used to adjust gate timings in the database. For TORO's, a similar procedure is used to find best timing (relative to beam crossing time) for sampling beam-induced toroid signal. 6. Device Grouping. In a "prep" request message, measurement devices to be read out or calibrated can be specified by unit number range (from a DGRP) or by explicit list of units. Though calibration results are tied to BPMP's (processors), for each multiplexed BPMP one BPMS (station) must be chosen if the calibration method requires actual beam. At "prep" time, the micro checks the database to identify devices marked offline. 7. Running Data Structures and Acquisition Step Sequence. Beam measurement for any one pulse occupies at least three consecutive iterations of the 360-Hz interrupt-driven coroutine in the micros. The first iteration (one 360th of a second before beam crossing time) sets attenuations, sets multiplexers, and selects preprogrammed gate timings. The second iteration is wasted since camac readouts would be uncontrollably before and after beam crossing. The third iteration (more if required by camac bandwidth limitation) reads out the raw measurements. Raw data is collected in one buffer for each complete multiplexer cycle, and these buffers are filled to satisfy the needs of any one averaging request or scan request. Data acquisition is always in the form of a triply nested loop: multiplexing within averaging within scan stepping. Each scan step can begin with commands to move wire carriage or move beam correctors. Data conversion for a given request is done after all raw data for that request has been acquired. 8. Fast Feedback. The fast feedback code in any micro can establish up to a dozen or so "connections" with any existing sharable BPM readout buffer ring. Such "connections" are one-to-one with fast feedback loops whose measurement tasks reside in the given micro; thus one loop may have "connections" in more than one micro. Whenever a running sharable BPM readout buffer ring (having at least one fast feedback connection) completes a multiplexer cycle, then (subject to loop inclusion/exclusion masks) a task is awakened to perform needed conversions on each data item needed by at least one loop, and send to each loop its expected data. This mechanism in effect governs the rate at which any fast feedback loop iterates. 9. Thoughts Toward NLC. Beam-synchronized data acquisition for NLC may differ greatly from the above description. Hopefully BPM multiplexing (the main obstacle to sharable data streaming) will be minimal, maybe even nonexistent, though BPM processors and their timing channels may be programmable to center any measurement on a specified bunch within bunch trains, and damping ring BPM processors may have data aggregation capabilities. It seems desirable to set up easily modifiable definitions of free-running BPM data acquisition modes for areas of the NLC machine, feeding both fast feedback and a data stream in which each measurement is tagged with pulse id and which can be sampled by any SCP-equivalent. "Sample" here may mean copy (possibly selectively according to pulse id) data already collected, or may mean post a request for data yet to be acquired. A request that is incompatible with a currently free-running acquisition in some area of the machine may be able to suspend (or interleave with) the free-running acquisition for the duration of the demand-driven acquisition. Besides being self-identified by database name and tagged with pulse id, data fed to a general data stream should also be tagged with timing parameters and with an indication of whether the measurements were part of a scan that could affect beam. Incidentally, putting beam measurement devices online or offline should not interrupt the data stream being produced from other beam measurement devices.