Personnel Safety System Status Reporting via EPICS at theAdvanced Photon Source*
S. J. Stein
Experimental Facilities Division, Argonne National Laboratory
9700 S. Cass Ave. Argonne, IL, 60439 USAABSTRACT
The Personnel Safety System (PSS) for an experimental beamline at the Advanced Photon Source(APS) uses a dual-chain, PLC-based architecture for controlling shutters and experimental stations.
Reporting the status of these two chains is important from both an operational and diagnostic standpoint.
This paper discusses the methods used for passing information from both chains of the PSS to the EPICSbased control system at the APS.

I. INTRODUCTION
The design of the Personnel Safety System for the experimental beamlines at the Advanced Photon
Source (APS) specifies the use of Programmable Logic Controllers (PLCs) for both interlock and control
functions. To meet certain DOE requirements, the PSS was designed using two chains in an effort to avoid
common-mode failures [1]. The first chain (denoted “Chain A”) uses the Allen-Bradley PLC-5 series
processor with both local and distributed I/O. The second chain (“Chain B”) uses the GE/Fanuc 90-70
processor, also with both local and distributed I/O. Each beamline has its own autonomous PSS with noknowledge of, or communication with, any other beamline [2].
The (physical) size of the APS makes it necessary to be able to monitor the status of any given
beamline from a remote location (such as the control room). To accomplish this without compromising theindividuality of each PSS, special hardware and software has been added to both chains. These additions
allow each chain to report a variety of information (including I/O points, status information, faults, etc.) tovarious EPICS database records. Once it is available as a collection of EPICS database records, any
authorized X-Terminal or workstation has the ability to display the status of each beamline PSS. This
information can be used for a variety of things including validation, debugging, fault tracing, and usertraining.

II. CONCEPTUAL DESIGNThe overall design requirements specified that the individual chain is responsible for sending theappropriate data to the EPICS database. It is also a requirement that the EPICS interface is not an integral
function of the PSS operation (i.e., if the IOC goes down, the PSS must still function). Finally, it is also
necessary that the communication be a read–only operation (the database must not have the ability to write
into the PLC data space). Each chain has special hardware and software to meet these criteria.

III. CHAIN A - ALLEN-BRADLEY PLC-5
Allen-Bradley produces a VME “scanner” card that can be used to communicate with an AllenBradley back plane. This scanner typically connects via shielded twisted pair wire to an Allen-Bradley“Remote I/O Adapter,” which sits in an Allen-Bradley crate. It is then possible to perform most of thefunctions of an Allen-Bradley PLC-5 processor – including reads and writes. Note that the “intelligence” ofthis system comes solely from the VME scanner – the Remote I/O Adapter is a non-intelligent device. At
this point, it would seem that the simplest method of transferring data to EPICS from the PLCs would beto use this VME Scanner to Remote I/O Adapter communication. Two overriding concerns prevent this:firstly, the interlock system must be stand-alone and not dependent on the VME scanner, and secondly, anytype of write operation (from the VME to the PLC) must not be allowed as it may compromise theintegrity of the interlock program. A data transfer method that only reads from the Interlock System is*

Supported by the U.S. Department of Energy, BES-Materials Sciences, under contract W-31-109-ENG-38

required: a one-way communication that “filters” the data the VME side can access. To facilitate such acommunication requires the use of an Allen-Bradley “Direct Communications Module” (DCM). This
module was designed to allow a remote PLC processor to access the local processors data space (both readand write) through shielded, twisted pair cable (“blue hose”). The DCM occupies a slot in the same chassis
as the local processor. Communication between the local processor and the DCM is done directly throughthe backplane. The local processor decides what data it wants the DCM to read and/or write. It is this ability
that allows us to achieve the desired communication protocol [3].
It was decided to pass all of the input and output bits into EPICS, along with certain PLC status
information, and a fault stack containing a time-ordered list of faults. To accomplish this, a small amountof code was added to the PSS logic that collects all of this data into two groups and sends them to the DCM
via the Block Transfer construct. The DCM is configured to buffer the blocks (a block can be up to 64words - 16 bits each) coming in over the (Allen-Bradley) backplane and send them over the blue hose when
the VME scanner requests them. A new EPICS record type, denoted the “abDcm,” is used to specify suchparameters as the scanner address (in “Link, Rack, Slot” notation), number of word groups to read, and scanfrequency. For each binary value (mostly input and output bits) a “bi” record is created for use in EPICS
applications such as MEDM and the Alarm Handler. In an attempt to reduce network traffic, all binary input
records are interrupt scanned [4].
Sect o r 1 -BM PSS Rack

AB

Chain AGE

Chain B
Sect o r 2 Vacu u m Rack

To 1-IDFib erMo d em

Fib er

To 2-BM
Serial-12

Rep eat in g u p
t o 3 -ID.

Blu e Ho se
Mu lt i-co n d u ct o r rib b o n

To 1-ID
To 2-BM
V ME

Rep eat in g u p
t o 3 -ID.

FIGURE 1 - SCHEMATIC LAYOUT OF IOC AT SECTOR 2
Each IOC supports six beamlines (see figure 1). In order to maintain isolation between beamlines,
six VME scanners are used (each with a different link number). The scan time for each DCM is fixed at one
second, making the best-case resolution for updates about once per second (chain A).

IV. CHAIN B - GE/FANUC
General Electric makes a line of 90-70 coprocessors that sit on the GE backplane and are capable ofrunning programs independently of the main processor. All main processor memory is available forinspection by the coprocessor, including I/O and status. We choose a coprocessor with configurable serial
ports that can be programmed in a extended BASIC language, which GE named “MegaBasic”. MegaBasic
was chosen due to its large flexibility in controlling character output format to the serial ports, along withthe relative ease of programming.

A small MegaBasic program was written that continuously scans the input, output, and status bitsof the main processor, forms them into a string of hexadecimal characters, and prints them out of the serialport. A single frame consists of a start flag (the ASCII character “s”), the byte representation of the mainprocessor memory, an end flag (letter “t”), and a checksum. Frames are sent continuously with no regard toacknowledgments. The serial port of the coprocessor is connected to a fiber-optic modem to allow longcable runs without (electical) noise problems. The other end of the fiber pair is connected to another fiber
modem (one of many concentrated in a “serial 12” chassis - see figure 1), which in turn is connected to theVME module (described below).
On the VME side, a MVME162 module running the Hideos operating system is configured with
two quad serial IP (Industry Pack) modules. Each of the IP modules is capable of communicating with fourserial (RS-232) devices. The serial port of the GE co-processor is connected to one of the eight available
serial ports on the MVME162 via fiber. A Hideos task was written to read the status frames arriving fromthe coprocessor and check for successful transmission (via the framing bits and the checksum). If a validtransmission is not received in five seconds of the last received frame, the connection is assumed dead andthe record support specifies an invalid alarm.
Assuming a successful transmission, the Hideos task then looks at groups of two bytes (a “bitgroup”) and checks to see if any bit has changed within a group. If so, the associated records within the bitgroup are signaled to the process and the values are updated appropriately [5]. As in the Allen-Bradleyimplementation, a separate binary input record is created to map each individual I/O point of the Chain BPSS.
Monitoring chain B takes only one MVME162 card since the IP modules allow us to connect tosix individual GE coprocessors. The communication between the GE coprocessor and the MVME162 takes
place at 19.2 Kbps. Assuming a low noise connection (which is valid since we are using fiber as thetransmission medium), we will experience very few corrupted frames and can easily match the one second
resolution of Chain A.

V. OPERATOR INTERFACEMEDM was used to build a variety of screens (see figure 2). In general it was desired to be able tomonitor all input and output points for both chains simultaneously. A special database was created tocompare related outputs between chains and is used to flag abnormal conditions (for example, if an input
does not appear on both chains when it is normally supposed to). Other screens include a fault stack(showing the last 10 faults), a PLC status page (showing a variety of PLC–specific information) andnavigation (via menus).
Other screens show a schematic overview of the beamline and experimental stations. These screensare more useful to the experimenters to indicate status of shutters, doors, etc. (figure 3).

Figure 2 - MEDM Screen Depicting input points

Figure 3 - MEDM Screen depicting a schematic view of an experimental station
VI. CONCLUSIONS AND POSSIBLE IMPROVEMENTS
Currently the system is implemented for one beamline (3-ID) and is working very well. All of thediagnostic screens have been used for beamline hardware checkout and as an aid to software verification. The
ability to monitor the entire I/O map of both chains simultaneously has been a tremendous benefit todiagnosing wiring problems and limit–switch misalignments.
A number of improvements and/or additions can be added to the system however. The interrupt
driven nature of both chains is worthwhile in theory, but may not do so well in practice. There are a few
signals that are periodically changing on the I/O maps which need not generate interrupts (particularly the“watchdog” signal – a pulse train traded between both chains to indicate “I’m alive” status [2]). Making
special consideration for these periodically changing signals may cut down on network traffic and processorload.
At this point in time, Chain B does not pass any status information (i.e., scan times, battery
condition, etc.). Although it was deemed not necessary due to the simple interlocking function of that chain[2], it will be added later to assist in debug and fault tracing.
Finally, the Alarm Handler and the Archiver have not been implemented up to this point. It would
be worthwhile to log certain I/O and status points in order to reconstruct any run time faults that may occur
during beamline operation.

VII. ACKNOWLEDGMENTS
I would like to thank Jim Kowalkowski for the tremendous work done on Hideos in general andthe Fanuc support in particular. I would also like to thank Chris Seaver for assistance in all questions
regarding the Allen-Bradley PLC systems.

VIII. REFERENCES.
1. DOE Order 5480.25, “Safety of Accelerator Systems,” (DOE 1992b).
2. Hawkins, J., et al., “Personnel Safety System for the Beamlines at the Advanced Photon Source,” SRI
Conference proceedings, 1995.
3. Stein, J. “One-Way Data Transfer for PLC to VME Status Reporting at the Advanced Photon Source,”
Nuclear Instruments & Methods in Physics Research - A 253 (1994) 210-212.
4. Stein, J., Nawrocki, G. and Kramer, M. “Data Exchange from Allen-Bradley PLC Based Systems toEPICS,” ICALEPCS Proceedings, 1995.
5. Kowalkowski, J. “A Cost Effective Way to Operate Instrumentation Using the Motorola MVME162
Industry Pack Bus and HiDEOS,” ICALEPCS Proceedings, 1995.