Tony Gromme 03 May 1995 Regional Beamcodes (RGBM) Purpose: The purpose of the regional beamcode software is to allow pulse-to-pulse variability of behavior of timing devices on a given beamcode, depending on some regular pattern (e.g., damping ring usage) or on varying conditions (ratelimiting). On different occurrences of a given beamcode, a given timing output can be selectively suppressed, or present with its usual timing, or present with a variable offset. Background: Outputs of timing devices are indirectly driven by codes sent in a 360-Hz broadcast message received identically by all micros. The sender is the master pattern generator micro (MP00 downstairs; MP01 upstairs). This 360-Hz broadcast is the machine's "heartbeat". Communication hardware: Up to about March 1992 the 360-Hz broadcast message was only 16 bits, known as PPYY, and sent on hardware known as CAT/CAR. This 16-bit code was directly relayed by the micros via camac to timing devices. The main hardware improvement allowing regional beamcodes was the CAT/CAR's replacement, the PNET hardware, capable of sending a longer message. The message length is now 128 bits, and is expandable. The PNET message includes the previous PP and YY codes; the additional information consists mostly of individual bits which locally modify the effect of the beamcode they are broadcast with. Timing hardware: The PDU module contains 16 independent channels. Each PDU channel can, at 360 Hz, produce an output pulse whose leading edge occurs at a programmable time relative to the 360-Hz fiducial which is transmitted everywhere on the main drive line (MDL). The timing of a PDU channel's output is pulse-to-pulse selectable from any one of 256 preprogrammed values, including a possible deactivation value (no output at all). Thus the key information provided to the PDU at 360 Hz is an eight-bit index. Since some PDU channels are used for timing BPM measurements and other actions that typically occur on a subset of the full beam rate, each PDU channel recognizes one or the other of two versions of this eight-bit index, known as PP and YY. The PAU module produces one analog output, pulse-to-pulse switchable to any one of 32 preprogrammed values between -10 volts and +10 volts. The PAU has a programmable memory that translates an eight-bit index (PP) down to a five-bit index which in turn selects output voltage value. Micro action at 360 Hz: Complete receipt of a broadcast message into a PNET receiver module causes an interrupt in the micro. The code servicing this interrupt decodes the PNET message and outputs a possibly recoded version of the received PP and YY codes via camac function F19 to all camac modules that require it. F19 pipelining: Because some devices need more than one 360th of a second to settle, the PDU sees three repetitions of the 16-bit PPYY codes. When the PNET message arrives, the micro outputs a recoded PPYY immediately on F19A10, again one 360th of a second later on F19A9, and finally one 360th of a second yet later on F19A8. Thus on each 360th of a second, each PDU channel actually uses one of six possible eight-bit indices; choice is determined by channel mode. Since the PDU needs to have the PP or YY index before the fiducial on which the selected time delay starts counting, the PNET broadcast message should always arrive as soon as possible after each fiducial. The beam crossing targeted by a given code occurs about one millisecond after the fiducial after that code is written by F19A8. Beamcode translation: Since the micro's 360-Hz interrupt-servicing code must consume much less than one 360th of a second (2777 microseconds), the PP recoding must be fast. For each base beamcode for which some DUPCD in the given micro has conditional expressions, a table has been built by which just the beamcode modifiers used with that base beamcode in that micro can be extracted from the received PNET message and shifted down to an integer of at most eleven bits, in turn used to look up the eight-bit substitute PP. Thus the recoding, if any, consists of two table lookups with a brief loop between. This translation is done once by each micro upon receipt of the 360-Hz PNET broadcast message. Base beamcodes for which no DUPCD conditional expressions exist in a given micro are left untranslated by that micro. YY recoding is done by BPM code, and is unrelated to regional beamcodes. DUPCD expressions: Timing hardware devices are generally known as PCD's, pulse-coded devices. PCD's in the database are: PDU, PSU, and PAU. DUPCD's are primaries in the database that point to PCD's. DUPCD's are: TRIG, KLYS, SBST, SBBP, KICK, PMAG, PAU, and PSU. Each unit of TRIG, KLYS, SBST, SBBP, KICK, or PMAG identifies and occupies one PDU channel. To specify how the behavior of a given DUPCD unit should vary on instances of a given base beamcode according to beamcode modifier bits broadcast with that beamcode, conditional expressions can be given to that DUPCD. For a given DUPCD and base beamcode, up to six expression pairs can be given. In each expression pair, the first expression consists of beamcode modifier names connected by logical operators, with parentheses as needed. In order of highest to lowest precedence, the logical operators are: ~ (not), & (and), | (or), and ^ (exclusive or). The second expression in each pair gives the timing value sum to be used if the condition is satisfied, and consists of TMVA names or asterisk connected by plus signs, or the single keyword DEACT. The asterisk here stands for that DUPCD/PP combination's timing value from the TMATRIX. If any value contributing to a timing value sum is a deactivation value, then the sum is automatically the deactivation value. Example of DUPCD having two expression pairs: Micro FF11 Beam 10 TRIG 104 1. Condition SBDARCN|SBDARCS|SCREEN30 Timing value DEACT 2. Condition TS4 Timing value *+TMVAR1 In the above example, the specified TRIG will not fire on those instances of beamcode 10 on which either arc single-beam dumper or the sector 30 screen kicker fires. Otherwise, the TRIG will fire on beamcode 10 with its usual timing value given in the TMATRIX, except that on timeslot 4 that timing value will be offset by the supplemental timing variable (TMVA) named TMVAR1. DUPCD expression updates: Whenever an operator edits any DUPCD conditional expressions and stores the result, the SCP recomputes a new set, always minimal, of substitute PP's sufficient to differentiate all distinct timing value sum expression combinations now existing in that micro. Substitute PP's are assigned for a micro as a whole, rather than separately for each crate, since the latter method would require the 360-Hz interrupt code to repeat the translation algorithm for each crate. The "DUPCD expression" touchpanel has buttons for displaying, searching, editing, and backtranslating DUPCD expressions. Editing a DUPCD expression causes the SCP to locally retain a copy of that micro's DUPCD expressions with the edits being made. A given SCP can edit DUPCD expressions for only one micro at a time. While editing is in progress the micro and other SCP's remain unaffected. When editing is complete, pushing the "update micro" button will cause the new version of that micro's DUPCD expression set to be stored publicly and to be downloaded to the micro, causing temporary suspension of timing outputs from that micro. Public storage for DUPCD expressions is in an extension of the TMATRIX shared global section. Timing value updates: Whenever a micro receives an updated TMVA value or an updated TMATRIX value as a result of a knob turn or an "ENTER TDES" or "DEACT" or "REACT", the micro must update all affected locations in PDU memories, possibly many camac writes when the related conditional expressions translate into many substitute PP's. Such updates do not cause any loss of timing device outputs, though the updates may be split by several 360-Hz interrupts. Beamcode modifiers: Beamcode modifiers are individual bits contained as part of the PNET broadcast message. Beamcode modifiers are identified by name. With each beamcode modifier name is associated a bit offset relative to the beginning of the PNET message. Some beamcode modifiers are explicitly scheduled by BGRP's; some are produced internally by the MPG code. A beamcode modifier bit's meaning depends on DUPCD conditional expressions involving that modifier, and is meaningful only on beamcodes for which such DUPCD conditional expressions exist. Examples: TS1,TS2,...,TS6 Indicate modulo-6 timeslot. Exactly one of these is always automatically present regardless of beamcode. SCREEN30 Kicks beam into sector 30 "Decker/Seeman" off-axis screens, assuming TRIG FB30 106 has condition ~SCREEN30, value DEACT on beam 10. NO_GUN_PERM No output from gun on this pulse, assuming TRIG's for TGAS's are DEACT on condition NO_GUN_PERM on beam 10. TMVA's: When a timing device's output on a given base beamcode is to be selectively shifted by a given offset, that offset is represented by a TMVA. Note that TMVA's can take on negative values. Each TMVA is system-wide, and updating a TMVA's value causes a message to be sent to each micro containing DUPCD's having coditional expressions involving that TMVA for any beamcode. Any TMVA can be included in a multi-knob file. KFTC's: KFTC stands for "Klystron Fast Time plot Condition". KFTC's represent no real device, but are merely "carriers" for conditional expressions that select the machine pulses on which data is collected by PIOP's for KLYS fast time plots. The KFTC primary merely connects KFTC name with KFTC unit #. Conditional expressions belonging to KFTC's are stored with conditional expressions belonging to DUPCD's. Conditional expressions belonging to KFTC's have no associated timing value sum expressions. For some Klystron fast time plots, non-default KFTC can be chosen by using the SELECT KFTC OVERRIDE button on the KLYSTRON DIAGNOSTIC SQUARED panel. Default KFTC can be set using the KFTC secondary of primary KLYS. BGRP's: All the information needed to specify beamcode scheduling and beamcode modifier scheduling for a given mode of beam production is organized into a "beamcode scheduling group" (BGRP). Each BGRP is identified by unique name. Any BGRP consists of one to four beamcodes, each with a scheduling pattern, and up to eight ratelimiting sections, each containing beamcode modifier scheduling patterns. A scheduling pattern is simply a string of up to twelve integers, and effectively represents a never-ending bit stream, one bit for each 360th of a second, where the associated beamcode or beamcode modifier is broadcast when the corresponding bit is "1" and not broadcast when the corresponding bit is "0". The integers in the string of integers alternate, counting first "0" bits, then "1" bits, and so on. Each string of integers is considered to repeat indefinitely, independently of any other pattern. The period (in 360ths of a second) of a pattern is simply the sum of the integers defining that pattern. Example: "1H2L" represents a 120 Hz pattern on timeslots 1 and 4. The scheduling pattern for any beamcode (as opposed to beamcode modifier) is limited to a period that divides evenly into 36. When a given beamcode scheduling group is activated in the MPG, all patterns in the group begin at the same instant, which in fact will be an exact even second boundary with respect to the pulse id. The patterns of all beamcodes in all concurrently active BGRP's must be disjoint. No two concurrently active BGRP's can share a beamcode. If a BGRP has more than one beamcode, then each modifier specification must also specify which beamcode that modifier belongs to. A modifier can only be broadcast when its beamcode is broadcast; that is to say, any modifier's pattern is implicitly and'ed with the pattern of its beamcode. All patterns in all ratelimiting sections are counted continuously as long as the BGRP remains active. When no ratelimiting is in effect, only patterns in the FULLRATE section can produce output. The MPG senses ratelimiting requests from various sources through IDIM modules and from MPS through a shared memory interface; the MPG reads both at 360 Hz. To limit beam rate in response to any request, the MPG switches to allowing the appropriate ratelimiting section of each active BGRP to produce output. BGRP updates: The "beam group control" panel has buttons for displaying and editing BGRP's. Individual beamcode patterns or modifier patterns can be created, deleted, replaced, or shifted. The SCP can edit only one BGRP at a time. While editing is in progress the MPG micro and other SCP's remain unaffected. When editing is complete, pushing the "store sched group" button will cause the new version of that BGRP to be stored publicly. BGRP's are stored publicly in database primaries BGRP and BPAT. To get the new BGRP running in the MPG, the operator must use the "halt BGRP" button if the previous version of the BGRP is running in the MPG, and then the "activate BGRP" button to start the new version. Exclusion/inclusion masks: As a simpler substitute for conditional expressions, exclusion and inclusion masks serve to select beam pulses on which BPM data is to be acquired for SCP's as well as for fast feedback. An exclusion mask is a 64-bit mask of modifiers, the occurrence of any of which on the given beamcode suffices to cause the BPM code to skip any attempt to collect data on that pulse. An inclusion mask similarly specifies modifiers, all of which are required on the given beamcode for the BPM code to attempt to collect data on that pulse. Saving and restoring: Sets of DUPCD conditional expressions, along with BGRP's, are included with timing configurations. The utilities RGSAVE and RGRSTR selectively save and reload DUPCD conditional expressions, TMVA values, and BGRP's to and from formatted text files. RGSAVE and RGRSTR provide an alternative means for editing this information. Downloading supported by TIMEX: TIMEX is a continuously-running Vax process whose sole purpose is to download timing information to micros. At micro IPL time, the micro sends a request to TIMEX for a complete download of that micro's timing information. Whenever an operator updates any DUPCD conditional expressions for a given micro, the updating SCP will request TIMEX to completely re-download the affected micro's timing information. TIMEX is receptive at all times to requests from micros as well as from SCP's. All requests to download timing data to micros are serialized through TIMEX. TIMEX does not handle timing device activations or deactivations or timing knob turns. The SLCnet communication path between TIMEX and any micro is separate from the path by which the micro's timing job receives updates or other requests. The timing code in the micro contains a separate task dedicated to receiving downloaded timing information from TIMEX. When a micro receives new timing information from TIMEX, the micro suspends all timing outputs while completely reprogramming all its timing devices. No communication with the Vax is needed for timing data when a crate comes online in an already-IPL'ed micro. Examples of DUPCD conditional expressions: Micro FF11 Beam 10 TRIG 104 1. Condition SBDARCN|SBDARCS|SCREEN30 Timing value DEACT 2. Condition TS4 Timing value *+TMVAR1 In the above example, the specified TRIG will not fire on those instances of beamcode 10 on which either arc single-beam dumper or the sector 30 screen kicker fires. Otherwise, the TRIG will fire on beamcode 10 with its usual timing value given in the TMATRIX, except that on timeslot 4 that timing value will be offset by the supplemental timing variable named TMVAR1. In this example, if the TRIG is deactivated for beamcode 10 in the TMATRIX, then it will not fire at all on beamcode 10. Micro FF11 Beam 10 TRIG 105 1. Condition ~(SBDARCN|SBDARCS|SCREEN30) Timing value DEACT In the above example, assuming the specified TRIG has been activated (in the TMATRIX) for beamcode 10, the TRIG will fire on beamcode 10 only when at least one of the arc single-beam dumpers or the sector 30 screen kicker fires; the timing value will be the usual one from the TMATRIX. Micro FF11 Beam 10 TRIG 105 1. Condition SBDARCN|SBDARCS|SCREEN30 Timing value TMVAR2 In the above example, assuming the specified TRIG has been deactivated in the TMATRIX for beamcode 10, the TRIG will fire only when at least one of the arc single-beam dumpers or the sector 30 screen kicker fires. Since no asterisk is present in the timing value sum expression, the timing value will be FF11's TNOMINAL for beamcode 10 plus FF11 TRIG 105's PDU's TREF plus TRIG 105's PDUT plus TMVAR2. Note that non-deactivated timing values in the TMATRIX already have TNOMINAL + TREF + PDUT added in. Micro FB69 Beam 10 PAU 1 1. Condition SBDARCN|SBDARCS|SCREEN30 Output channel 0 In the above example, the PAU will select its output channel 0, instead of the channel for which it is activated for beamcode 10, if at least one of the arc single-beam dumpers or the sector 30 screen kicker fires. A DUPCD/PP pair's last or only conditional expression may consist of a single asterisk (*) alone, meaning "all other conditions". This is needed in case one wants to assign a timing value that varies with a supplemental timing variable without involving any further beamcode modifier conditions.