HVS 4/21/97
10/24/00
Draft (Please excuse any spelling and grammar problems, as well as
----- any factualy incorrect ideas. For the most part, this a
good document.)
This document is intended as a guide to those wishing to change
MPSL algorithm files used by the Accelerator.
BACKGROUND:
The MPS system's function is to protect the accelerator beamline
components from being damaged by the accelerator's beam. This is achieved
by monitoring via CAMAC various relavent beamline signals, and slaving the
ability to generate a beam (via the Timing System's Pattern Generator) to
the condition of those signals.
The MPSL files which are used to determine what to do with these
beamline signals are collectively called "MPS algorithms". Historically,
MPS Algorithms for "Production Use" have been generated by the Accelerator
Operations Group (specifically the Author of this note). At the beginning of
each Accelerator running cycle, a set of algorithms is generated for each
MPS processor. Sometimes these are merely the same as previous algorithms,
with a review of the monitored devices. These files should contain provision
for MPS to function as desired for all Operating Modes anticipated for that
run cycle. There is text in each file which describes this.
These MPSL files must work together with the MPG's BGRP files in
order to implement the MPS system. MPSL algorithms are written based
on certain assumptions about what the MPG's BGRP shall do with beam rate
request labels. Similarly, the BGRP author needs to use assumptions about
what MPSL files are in place. A working familiarity with the BGRP to be
used with an MPSL file is therefore essential to the MPS Algorithm author.
ABOUT THE HARDWARE:
Begin with the front end hardware. There are (currently) three
types of MPS CAMAC modules. Each of these modules has the 1553 (see below)
interface (seperate from and in addition to the standard CAMAC interface)
used to communicate with it's MPS processor.
LDIM (Latching Digital Input Monitor)
LDIM is a 32 channel digital monitor. Each channel is (voltage)
monitored and determined by the module to be in either the OK (voltage above
threshold) or BAD (voltage below threshold) state. A typical signal shipped
to an LDIM might be the status of a beamline vacuum valve "out" microswitch.
A 24VDC circuit starts upstairs, runs down to the valve's microswitch (or some
upstairs relay...possibilties are endless) and then returned back to the LDIM
module. If the valve is out, it's out microswitch is closed, and the 24V
circuit returns 24V to the module. It the valve's microswitch opens, the
24V circuit to the module is broken, and the LDIM detects the input as
being "BAD". A huge variety of MPS information is handled via LDIM modules.
PICP (Protection Ion Chamber Processor)
PICP is a five channel multi-level comparitor. Each channel monitors
the current generated by an external electrical network collectively called
an ion chamber. The ion chamber has an externally applied voltage, typically
~300 volts. The network consists of two parallel current paths. First is
a high resistance (~ hundreds of Mohms) bleeding resistor. This bleeding
resistor draws a fraction of a microamp of current. The other current path
is a volume of gas (typically argon) which if left alone will draw essentially
no current. As the gas is dosed with radiation, gamma rays knock some of
the gas's valence electrons. Electrons knocked hard enough to escape the
valence band become free, and are accelerated by the externally applied
network voltage. Electrons which make it to the chamber's electrode generate
an additional network current. This "argon current" is used as a measure of
the radiation dose rate the argon receives.
This network current is returned to the PICP module. The current
level is shipped to four comparitors, each with different (programmable)
levels. Here is how the levels are used, and what they are called:
CABLE Rather small current level. If the measured current is less than
this level, it is clear that the external network is broken (or
HV is off). Chamber therefore is not operational, and and MPS fault
should be generated.
FULLRATE This is a rather high current level. It corresponds to the maximum
allowable radiation dose rate. If this level of current is exceeded,
the dose rate is too high and an MPS fault should be generated.
LIMIT_HI This is an intermediate current level, typically 1/12th of the
FULLRATE value. Idea is that if dose rate is below this level, it
should be OK to increase beam rate from 10->120Hz. MPS won't try
to go for higher rate than 10 Hz if this level is exceeded.
LIMIT_LO Same as LIMIT_HI, except 1/10th of FULLRATE. Used to decide whether
1->10Hz transition is OK.
See the references listed at the bottom of this document for
further (important) considerations about how these LIMIT_LO and LIMIT_HI
levels get set.
RTDP (Resistive Temperature Detector Processor)
RTDP is a 16 channel A/D converter with comparitor for each channel.
Each channel also provides a current source. Idea is that each channel's
current source is sunk into a platinum strip resistor; emersed into a beamline
location whose temperature is of interest. The current is then returned
to the module. A second set of wires then looks at the voltage drop across
the platinum strip resistor. The known thermal resistivity coefficient of
platinum is then used to translate this voltage to a temperature. If
temperature exceeds threshold, an MPS trip is initiated.
I'll spare the reader the nausea of going through how to figure
out how the trip setting is determined. It has to do with RTD resistivity,
current source level, comparator DAC full scale, etc. Bottom line is that
you type a number into the SCP "change module component" button, which
will ask you for a number called "thrshold". The number is going to be
in comparitor DAC counts, and the formula for the RTDs we use is:
( 2.30e-3 ) Where TEMP is the desired
THRSHOLD = 286 * ( 1 + ------- * TEMP ) trip detting in degF.
( degF )
(Example 150 degF gets THRSHOLD = 385)
VME PROCESSORS
The MPS system incorporates a series of VME processors. A typical
processor lives in some remote accelerator support building location, and
supports MPS for some set of nearby devices. The VME processor allocation
has no direct connection to the standard SLC multibus micro (i.e. DR11)
allocations. Each of these processors has a name (i.e. AP30 means Algorithm
Processor in sector 30).
Each AP is the master of a daisy chain serial link which loops around
each of the CAMAC modules supporting MPS signals for that AP. This is a
"MIL-Spec 1553" serial link. It's medium of propogation is the distinctive
looking blue coaxial cable with unusual fancy cable connectors. Go find one,
look at it, and you'll know what I mean.
On a clocked (360 Hz) interrupt basis, the AP initiates a communication
sequence with each of it's modules. As Mark Crane has expained to me, it passes
a "token" to the first module. That module then augments the token in a manner
which imparts onto the token all information about the module's inputs, and
then passes the token to the next module. Eventually the token, fully augmented
by each of the modules, returns to the AP. The AP then has all the information
about all the devices it supports. This process happens at 360 Hz.
The AP then has the task of translating all this CAMAC information
into something useful...something in the form of a "rate request". The
translation is done by the MPS algorithm for that AP. Net result of that
translation is a "rate request".
Enter the Supervisor. The MPS Supervisor is called SP00 (pronounced
_ _ _ _ _ __
"es pe zero zero " not " spoo " ). The supervisor is also a VME
processor like the APs. It is the master of a 1553 serial link. The
supervisor's serial link daisy chains around to each of the APs, just as the
AP's serial links daisy chain around to CAMAC. The supervisor's token is
augmented by each AP, based upon each AP's algorithm translation. Once back
at the supervisor, the supervisor's token has all the information needed to
determine what beam rate should be allowed. Translation of this token into
a "rate request" is done by the supervisor's algorithm. This process happens
at 360 Hz. The result of the supervisor's rate request (i.e. the result of
the entire MPS system) is then delivered to the SLC multibus micro MP00
(MP00 drives the Accelerator Timing System, and therefore determines the
rate at which beams can happen) via a shared memory card. This shared memory
card is the connection between MPS and the timing system. The MPG "obeys" the
MPS supervisor's requests for allowable rate in a manner determined by the
MPG's BGRP (the MPG's BGRP can be thought of as the timing system's algorithm).
THIS IS THE END OF THE HARDWARE DISCUSSION.
ALGORITHM FILES:
Each MPS Processor micro needs an algorithm file. Algorithms
are written with a text editor in a language called MPSL. Greg White of the
Software Engineering Group has constructed a compiler for these MPSL files.
See reference at bottom. Convention has developed that each AP has an .MPSL
file and an .MPSLINC file. The former (.MPSL) file contains MPSL code but no
specific MPS devices referenced. Rather, it has lists of devices referenced.
The lists are then defined (in terms of specific MPS devices) in the later
(.MPSLINC) file. See examples below.
These files are managed by DEC's "Code Management System" (CMS)
utility. Their home is in a directory pointed to by the logical name
ref_mps_alg_mpsl.
So for example, if one looks at all files in that directory associated
with the AP called AP51 one sees:
*** SLCHVS>set def ref_mps_alg_mpsl ***
*** SLCHVS>dir *AP51* ***
*** ***
*** Directory REF_:[MPS_ALG_MPSL] ***
*** ***
*** AP51_1997.MPSL;2 AP51_1997.MPSLINC;2 ***
*** ***
*** Total of 2 files. ***
COMPARISON OF .MPSL AND .MPSLINC FILES:
If one looks at the .MPSL file for AP51, one sees a bunch of MPSL
code which looks like this:
*** BEAM = "A_LINE" ***
*** RATE = "ZERORATE" ***
*** STOPCNF = BSY_B1_B2_OFF ***
*** NEWRATE = "ZERORATE" ***
*** BSY_50LINE_LDIM_OK & ***
*** BSY_COMMON_LDIM_OK & ***
*** BSY_COMMON_AP51_RTDS_OK ***
*** ; ***
*** NEWRATE = "LIMIT_LO" ***
Assertions are made about the integrety of lists of MPS signals.
These lists are defined in the .MPSLINC "include" files whose contents
if viewed look like this:
*** #define BSY_COMMON_LDIM_OK \ ***
*** MPS.AB01.2."IV3_OPEN" == "OPEN" {"BSY IV3 IN "}&\ ***
*** MPS.AB01.2."FSG3_OK " == "OK" {"BSY VACUUM FSG3 FAULTED "}&\ ***
*** MPS.AB01.1."PC119_FS" == "OK" {"BSY PC119 FS TRIPPED "}&\ ***
*** MPS.AB01.1."PC145_FS" == "OK" {"BSY PC145 FS TRIPPED "}&\ ***
*** MPS.AB01.1."PC155_FS" == "OK" {"BSY PC155 FS TRIPPED "}&\ ***
*** MPS.AB01.1."PC165_FS" == "OK" {"BSY PC165 FS TRIPPED "}&\ ***
*** MPS.AB01.1."PC175_FS" == "OK" {"BSY PC175 FS TRIPPED "}&\ ***
*** MPS.AB01.1."PC185_FS" == "OK" {"BSY PC185 FS TRIPPED "}&\ ***
*** MPS.AB01.1."PC195_FS" == "OK" {"BSY PC195 FS TRIPPED "}&\ ***
*** MPS.AB01.2."FSG10_OK" == "OK" {"BSY VACUUM FSG10 FAULTED "}&\ ***
*** MPS.AB01.1."PC320_FS" == "OK" {"BSY PC320 FS TRIPPED "}&\ ***
*** MPS.AB01.2."IV4_OPEN" == "OPEN" {"BSY (FFTB) IV4 IN "}&\ ***
*** MPS.AB01.1."PC90_FS " == "OK" {"BSY (FFTB) PC90 FS TRIP "}&\ ***
*** MPS.AB01.7."FFTB_MPS" == "OK" {"FFTB MPS SUMM (B406) FAULTED "}&\ ***
*** MPS.AB01.2."FSG12_OK" == "OK" {"FFTB VACUUM FSG12 FAULTED "} \ ***
*** /**** end of BSY_COMMON_LDIM_OK **/ ***
These .MPSLINC files are also made using a text editor. Devices are
"lumped" into these lists since usually there will be a large number of
devices which (due to their proximity to MPS Stoppers and beam line
demarkators) MPS treats exactly the same. Rational behind the device
grouping should be explained in the commenting of these files.
A WORD ABOUT MPSTs
MPST is an acronym for "MPS stopper". The idea is that if some
stopper is inserted upstream of some part of the Accelerator, then there
is no reason to make an MPS fault for tripped devices beyond it.
Examples of MPSTs include physical stoppers (ST6049 just upstream of HENIT
has the primary function of providing PPS protection for PEP, but also is
used as an MPST masking MPS faults in the NIT if inserted), magnet power
supply off status (50B1 off bit is used as an MPST to have MPS ignore devices
in the 52/51 lines). Creatively choosing and using MPSTs offers a tremedous
level of flexability towards being able to safely run upstream beams when
downstream areas have MPS faults.
SO YOU WANT TO CHANGE AN EXISTING MPS ALGORITHM
Usually when one wants to make changes to an MPS algorithm, one
really only wants to change these device lists which live in the .MPSLINC
file. One can easily change the .MPSLINC, recompile the .MPSL file which
uses the .MPSLINC file, and then download the .PORT file generated by the
compiler to the AP.
EDITMPS:
To facilitate changes to MPS algorithm files, Karey Krauter of the
Software Engineering Group has written a command file called EDITMPS.
EDITMPS is somewhat similar to the popular EDITPNL and EDITDBS command
files. It is very useful for handling the CMS reservation, compilation,
CMS replacement, etc. of MPS changes. It also prompts for questions
regarding the automatic generation of Summary List files used for
Fault Accounting and Status Displays. For more information about EDITMPS,
type EDITMPS without providing any file name arguement, and a brief listing
shall come up about EDITMPS.
If using EDITMPS to change one of these device list (say to
add a new device into the algorithm) one would first use EDITMPS to reserve
edit and then replace the desired .MPSLINC file. This action alone would
not allow the new device to be picked up. One would also need to use
EDITMPS to recompile the .MPSL file which uses the changed .MSPLINC file.
This is an easy problem to trip over, and EDITMPS does issue a reminder to
recompile the .MPSL file associated with a .MPSLINC file when replacing a
.MPSLINC file.
USING THE COMPILER AT THE COMMAND LINE:
With new devices, the author prefers to confirm that the .MPSL
compiler would be happy with the proposed changes before using EDITMPS to
change any CMS files. Since MPS devices are somewhat database intensive, and
since the .MPSL compiler requires that the database for MPS devices be
in many ways correct, it is often useful to use the .MPSL compiler from the
command line to confirm that proposed changes would work. One way to do this
is to make some temporary file for testing the proposed changes:
**** MCC>COPY REF_MPS_ALG_MPSL:AP51_1997.MPSL TEMP.MPSL ****
**** MCC>COPY REF_MPS_ALG_MPSL:AP51_1997.MPSLINC TEMP.MPSLINC ****
One can then change the local TEMP.MPSLINC file to reflect the
proposed changes. There is a line in the .MPSL file which tells the
compiler pre-processor where to find the macro definitions of device lists.
In the local TEMP.MPSL file, this line would need to be changed to direct
the compiler to look at your local .MPSLINC file. Specifically, change the
line in the TEMP.MPSL file which looks like this:
**** #include ref_mps_alg_mpsl:ap51_1997.mpslinc ****
to look like this:
**** #include your local directory:TEMP.MPSLINC ****
With the local TEMP.MPSLINC file containing the proposed changes and the
local TEMP.MPSL file directing the compiler to look at the local
TEMP.MPSLINC file, the compiler can be invoked at the command line:
**** MCC>MPSL TEMP.MPSL ****
If there are no errors, then the proposed changes should work and the CMS
files could be edited and recompiled using EDITMPS. If there are errors,
likely problems involve MPSL syntax and database setup for the referenced
devices.
DOWNLOADING THE CHANGES:
Once EDITMPS has been used to get the changes into the CMS files
and compile the new algorithm, the new algorithm must be downloaded to the
AP. This is done with the SCP:
MPS/PPS/ACCESS PANEL -> NEW MPS SYSTEM PANEL -> AP CONTROL PANEL -> ALG PANEL
First select using the dynamic buttons the AP which you are working with.
Then push the button "Downld NewAlg to AP". You will be prompted for the
filename to download, a level of priviledge, and a password. The default
for the algorithm file should be the same as was previously downloaded.
SO YOU WANT TO BUILD AN ALGORITHM FROM SCRATCH:
Before sitting down to contruct an algorithm file, you need to arm
yourself with a significant list of things:
LIST OF MPS DEVICES SUPPORTED BY THE AP WHOSE ALG YOU ARE TO BUILD
This may seem obvious, but you need to have everything that AP is
to do in mind. Several different beamlines are typically involved. You
need to understand what each MPS device does for you, where it is, and how
it works.
LIST OF MPSTs AVAILABLE TO YOU IN THIS AP
MPSTs are your friends. Sometimes you will need to make them.
This really depends on the application, but in general you will want to
make MPSTs to deal with inevidable issues like vacuum valves which go in
during access, PICP HV which goes off during access, etc. etc. You are in
a position to demand MPS status of devices which may not be already
available: "I need a meter relay signal on this magnet string which shall
trip whenever an LCLS BSOIC trips" or "I need LDIM monitoring of this
PPS stopper which goes in when there is access".
A GOOD KNOWLEDGE OF WHAT THE ACCELERATOR IS GOING TO DO WITH YOUR
ALGORITHM.
In constructing the algorithm, you need to be aware of what is planned
with the Accelerator. Is the North Damping Ring to be used? Will there be
a scavenger beam in EP01 when the "FFTB Rate Limiting Area" has rate?
You need to have your algorithm cover all the bases of Accelerator Operation
which will happen during your algorithm's usage. This involves getting into
the head of the BGRP author, since the BGRP author determines where beams
go under what label (by label I mean RL_AREA) and at what rate.
Once armed with everything you need, the first step is to start
sorting. Here is where you build the .MPSLINC file. See the example above.
Sort through the devices to make "groups" of devices which will always be
handled identically. Each group should be assembled into a "macro definition"
an example of which might be:
#define LI09_TIU_INPUTS_OK \
MPS.LI09.2."SBST_OK " == "OK" {"SECT 9 SUBBOOSTER NOT READY "}&\
VACV.LI09.1."VALVE " == "OUT"{"SECT 9 SLOW VALVE NOT OUT "}&\
MPS.LI09.2."SCRAPER " == "OK" {"SECT 9 BEAM SCRAPER FS TRIP "} \
/**** end of LI09_TIU_INPUTS_OK **/
The syntax is important. The stuff on the left of the == evaluator describes
the database PRIM,MICRO,UNIT,COMPONENT being evaluated, and the thing on the
right is the COMPONENT state corresponding to the not broken condition.
The stuff in between the curly brakets {} is called a translation string. You
get to make this up, and it is what the Operator looking at the MPS CUD
will see when there is an MPS fault. Put a lot of thought into your
translation strings. Often the PRIM,MICRO,UNIT,COMPONENT information is
not particularly descriptive of the device being referenced. The \ character
means that the string being defined is continued on the next line. The
charater sets /* and */ demark comments and are used to tell the compiler to
ignore characters in between them. The boolean operators == and & are as
one would expect. If all of these devices are OK, then the "anded" list will
be evaluate to "TRUE". If any one is faulted, the list will evaluate to
"FALSE".
Once all of your devices are sorted into such macro lists in the
.MPSLINC file, you are ready to build your .MPSL file.
I have made a template for building .MPSL files. It lives in the
file called USER_DISK_SLC:[HVS.MPS]TEMPLATE.MPSL and I believe is the
place to start, especially since the business of allowing rate to increase
based upon PIC thresholds is a little tricky. Trust me, just use the
structure in the template.
Things about .MPSL which you need to understand:
Branching:
Evaluations are interrupt driven. On each interrupt, the
processor is provided (from the Supervisor) the following information:
GLOBMMODE This has never been used. All globalmodes should be handled
identically by MPS since MPG does nothing different based
upon globalmode.
BEAM This is the "Rate Limiting Area" which the MPG associates
with this beam pulse. Examples might include "A_LINE" or
"HER_INJ".
RATE This is what the MPG claims is the current "rate" of this
rate limiting area.
STOPCNF This is the status of MPSTs.
So based upon this information the AP decides which part of it's algorithm
is used to perform this pulse's evaluation. This is an important point, in that
this branching mechanism makes it such that only a small portion of the
algorithm is used on each interrupt.
What the AP Returns:
The algorithm shall return a "NEWRATE" request to the supervisor on each
interrupt. The notion "if true go up" is used. For each branch, the NEWRATE
recommendation starts as ZERORATE. Then some evaluations are done, and if all
are true (i.e. MPS devices OK), then NEWRATE gets assigned a higher value
(say LIMIT_LO). If ever an evaluation fails (i.e. an MPS device being evaluated
is tripped), the AP returns it's current value of NEWRATE to the Supervisor
as it's rate request. Stare at the template with this in mind, and all this
will make sense.
It is worth mentioning that this scheme only allows one level of rate increase
per interrupt. One interrupt gets you from ZERORATE to LIMIT_LO, but a
second interrupt is needed to get from LIMIT_LO to LIMIT_HI, and so forth.
OTHER USEFUL THINGS WHICH ARE WRITTEN DOWN:
There is information about the EDITMPS utility, particularly about the
generation of fault accounting and .DINC and .SINC files in
DOC$[NEWSLETTER.OLD]MPSL_DBS_SWITCH.NEW (Index panel article).
The topic of PIC Processor trip settings is discussed at nausium in a
file:
ictrips.html
There is an owners manual for the MPSL compiler which is very useful. A
copy can be found in
DOC$USER:MPSL_USERMAN
SCP Online help is also excellent.