[TEG.LCLSDOC]BPM.STUFF 17 Mar 2004 rev. 21 Apr 2004 BPM-related questions, and question-like statements, and statement-like questions: 1. Will IOC-based BPM's be such that they can be read in only one way, allowing data to be continually acquired from them without regard for who might be interested in that data? Probably not. 2. Presumably no iRMXmicro will try to communicate directly with any IOC for other than fast feedback purposes? 3. Following will more or less assume that LCLS "SLC-aware" IOC's will be capable of receiving 360-Hz PNET message (somehow), and reacting variously to those messages at that rate. 4. IOC will learn how to respond to BPM "prep" request message from SCP much as iRMXmicro responds to such message. IOC will have 360-Hz PNET-interrupt-driven routine capable of decoding parts of PNET message. 5. IOC will do its best to send BPM data to requesting SCP in messages structured as iRMXmicros presently do. Within that message structure, new structure types will doubtless have to be defined & supported for individual readouts acquired from new IOC-based BPM device types. 6. Existing SCP code will need device-specific additions for displaying data from IOC-based BPM's, since present existing SCP code that displays BPM data has to make quite different line-by-line displays for different kinds of existing SLAC BPM's (of which there are many). 7. Presumably all or most already existing capabilities of IOC will remain supportable from Unix-based Epics operator-interface machines; will new IOC-based devices accessible or supportable from SCP also be accessible or supportable from Unix-based Epics machines? 8. Since in general the peculiarities of each device type within a classification such as BPM require special attention at widely different application code levels, any assumption that special attention for new device type should occur in only one place is probably a bad assumption. 9. Hopefully LCLS IOC-based BPM's wont use multiplexer modules, and will always have database secondary BPMS:MUXS = 0. Rest is descriptive information about existing SLC BPM data acquisition method: Note incidentally that in existing iRMXmicro code most support of timing device channels used for gating BPM devices (i.e., PDU/PPDU channels in YY mode as opposed to PP or other modes) is in BPM subjob as opposed to TIME subjob. Let's assume the answer to each of questions 1 & 2 above is "No, they wont." Any acquisition of BPM data has to be "orchestrated" by SCP through unique iRMXmicro known as "MPG" (only micro having PNET broadcast device) and other iRMXmicros containing the BPM's to be read out. SCP has collection of pre-canned "BPMD's" (BPM measurement definitions; BPMD and DGRP are relevant primaries in SLC operational database). Any one of these BPMD's gives a list of micros with device unit number range for each micro, and various other parameters. Using SCP touchpanel, human requestor selects a BPMD, and optionally modifies some parameters (which modification is remembered by that SCP for that SCP's use of that BPMD). One such possible modification is selection of (contiguous) subset of that BPMD's micros. Human requestor pushes one of various BPM touchpanel buttons saying "acquire data" or something like that. SCP sends BPM "prep" message to each non-MPG micro, and waits for reply from each saying "Request looks valid and I've prepared structures according to which data acquisition can proceed" (or saying "I cant and I havent"). If at least one micro replies ok then SCP sends YY request message to MPG and waits for data reply messages from successfully prepp'ed micros and YY completion reply from MPG. In the meantime that SCP cant do anything. Any micro can have numerous BPM prep's outstanding. MPG (whose only actual output is 360-Hz PNET broadcast) satisfies enqueued YY requests as PNET output allows. BPM prep message (and YY request message) specifies small set of beamcodes on which data is to be acquired for that prep; acquisition times can be further conditioned down by exclusion masks and inclusion masks specifying other bits in PNET message. Beamcode itself is 5-bit dedicated field in PNET message. Beware that term "YY" has variety of meanings, but in MPG context, YY means 8-bit code which MPG puts for micros to see in 8-bit dedicated field in PNET message. This YY code is unique across all running SCP's and across all BPMD buttons belonging to any SCP. YY value is specified in any BPM prep message to non-MPG micro and of course in YY request message to MPG. This YY code uniquely identifies any outstanding prep that any micro has constructed. Micro receiving PNET regards YY code seen on PNET as "enable" signal selecting one BPM prep that can now run to its completion as dictated by other information in that and subsequent PNET messages. Entire acquisition can include beam-synchronized stepping of beam-control devices or of wire carriage movement control devices, as optionally specified in prep message. YY request message to MPG includes bitmask specifying which micros will participate in that acquisition. During acquisition, MPG guesses how long acquisition will take for slowest micro, and for the duration of that YY request the MPG starts no other YY request affecting any of the same micros. In some cases the requesting SCP must notify the MPG when the entire transaction seems complete. At each beam-crossing time on which BPM readout will occur, micro's 360-Hz PNET-interrupt-driven routine must issue commands as follows: on the 360th of a second before which the fiducial will trigger timing channels for that beam crossing, BPM devices must be programmed with (at least) attenuator settings for expected beam pulse intensity, and BPM multiplexers if any must be programmed. Next 360th of a second (beam-crossing time) is largely wasted because there is no way to control when readout commands would occur relative to time when BPM devices capture & digitize measurements; hence actual readout via camac starts on following 360th of a second, and lasts one or two 360ths of a second, depending on how many BPM's the worst micro has (everyone has to agree with the worst micro, and the SCP knows it ahead of time). PEP2 is a major exception, in which readout via camac for a single beam-crossing can last considerably longer (again, the requesting SCP knows it ahead of time). In any case, maximum beampulse rate for which BPM data can possibly be acquired is 120 Hz. For any fast feedback loop, iteration rate for that loop is governed (driven directly) by acquisition of BPM data which that fast feedback loop wants. When a SCP's BPM data acquisition request disagrees significantly with more or less constantly running acquisitions driving fast feedback, then that SCP's acquisition can shut out fast feedback for the former's duration. In the micro, any measurement setup (sometimes known as "measdef") consists of a number of structures which the micro allocates in memory according to parameters found in the "prep" message sent by the requesting SCP. Essential structures are: a (single) "buffer ring descriptor" in which is rooted a ring of buffers (known as "M2" buffers) to receive raw camac data. Each "M2" buffer represents one complete multiplexer cycle (hence at most ten beam pulses), and contains raw camac data as well as camac readout command packets. Here the term "multiplexer" refers to a camac module which is in effect a single-pole-ten-throw switch, through four of which the signals from up to ten BPM electrode quadruplets (one per beam pulse) can be routed to just one BPM signal digitizer. In the database, each possible quadruplet ("station") of electrodes in the beampipe is represented by a unit of primary BPMS, and each BPM signal digitizer camac module ("processor") is represented by a unit of primary BPMP. Most of the more static information describing BPMS's (e.g., multiplexer setting) and their BPMP's (e.g., camac address) comes from the database. There are two kinds of "BPM hw readout buffer ring", private and public. Public buffer ring supports (in fact drives) up to nine or so fast feedback loops, and runs continuously as governed by PNET (but without any request-specific YY code from the MPG) until explicitly deleted by a SCP. Private buffer ring stops automatically when satisfied, causing its data to be converted & packaged up & sent to requesting SCP. In general, a BPM data acquisition request from a SCP can parasite off an already-running public buffer ring if sufficiently agreeable, and otherwise creates its own private buffer ring, which takes precedence in competing with any public buffer ring for beam pulses. In any case, on any one 120th of a second the code (as it is now) will service at most one buffer ring (as determined by PNET information), mainly because of the difficulty of policing camac bandwidth, which has always been an overriding and software-consuming consideration. (The camac commands that will be issued on the next 360th of a second to send the F19 must always get executed in time, otherwise beam may hit the wall.) Note in case you have occasion to look at the iRMXmicro code: For replacing a block of information that will be seen by interrupt-driven code, task-level code makes the installation or replacement by using a single uninterruptible instruction. Since there is no single instruction for storing a far pointer (48-bit pointer consisting of offset and selector), the thing stored must be either a selector or a near pointer as opposed to a far pointer. For sharing a counter or a word containing flag bits between interrupt-driven code and task-driven code, each instance of such code depends on usage of a single uninterruptible instruction to update (read & write) memory. Though the "SLC message service" is primarily structured to support simple "speak only when spoken to" transactions, more specialized procedures are provided in the Alpha specific to BPM data acquisition: For any one such acquisition, the SCP sends a "prep" message to the primary task of the BPM subjob in each of the micros that will perform the acquisition, and the SCP collects the immediate setup success/failure responses from those micros, and (if at least one micro reported success in its setup) the SCP sends a YY enqueueing request message to the MPG micro (MP00 (prod) or MP01(dev)), and waits for completion reply from MPG and replies containing data from those micros that reported successful setup. Each micro, after completing the entire acquisition cycle as governed by PNET messages, converts the raw camac data to floating-point with the help of per-BPM calibration information held in the micro, and sends the results to the (unique) requesting SCP (possibly in a series of messages to overcome message service limitations, since the data may be quite voluminous; in such cases the receiving SCP must explicitly request each additional piece). Since "prep" request messages themselves may exceed message service size limitations, any "prep" request message may be sent in pieces, and the micro acts on the "prep" request message only when complete (among several large incoming request messages received in pieces from several SCP's, the micro acts first on the one completely received first, though the micro must acknowledge each piece). BPM-specific request/reply message service function codes are defined in includefile REF_C_INC:BPMFUNC.HC, and structures of request/reply messages are defined in REF_C_INC:BPM_REQREPLY_STRUC.HC, BPMSTRUC.HC, and BPMCALSTRUC.HC (the latter two contain definitions of inner structures of data coming back from the micros). Structure of YY enqueueing request message to MPG is in includefile REF_C_INC:MPG_REQREPLY_STRUC.HC. Though BPM includefile naming is a little inconsistent between C code and older Fortran code (Fortran includefiles are in REF_SLCTXT:*.TXT), names of structures themselves are fairly consistent between the two languages. For LCLS, it seems to me that if answer to question 1 at top above is at least a little more than halfway "yes", then the public buffer ring concept can be extended a little to allow the micro to accumulate circular buffers of BPM data to whatever depth, including pulse id and PNET information (as mentioned today), and these buffers could be sampled by many data acquirers concurrently. Furthermore, if micros are accumulating BPM data for anybody to sample after the fact, and there are various device parameters governing modes of BPM data collection, then each set of acquired BPM data should include current values of those parameters. I also suggest making data be self-identifying as opposed to merely positionally located within binary records, allowing expandability of kinds of devices & data & parameters included.