8th International Conference on Accelerator & Large Experimental Physics Control Systems, 2001, San Jose, California TUAP067 physics/0111153 INFORMATION-CONTROL SOFTWARE FOR HANDLING SERIAL ∗ DEVICES IN AN EPICS ENVIRONMENT P. Chevtsov, S. Schaffner, Jefferson Lab, Newport News, VA 23606, USA Abstract they are ready to receive data. RS-232 also defines a communication method to send information on a Each accelerator control system has a variety of physical channel. The information is broken up in data measurement devices. One of the most common types words. The length of the data word is variable, usually of instrument interfaces used for their control is a serial 7 or 8 bits. Data bits are sent with a predefined (RS-232) bus. It is inexpensive and adequate for frequency, the baud rate that is roughly equivalent to relatively simple measurement and control devices such the number of bits transmitted per second. To as switchers, amplifiers, voltmeters, and stepper understand each other, a transmitter and a receiver must motors. Since the RS-232 specification is very broad use the same number of bits in a data word and the and does not require uniformity above the basic same baud rate. communication protocol level, one of the major The RS-232 standard says nothing about the content problems associated with the use of RS-232 is that the of the message sent between the two devices, the command protocol for each device is unique. This amount of time to wait between messages and how to makes it difficult to design generic drivers for RS-232 handle multi-word messages. These issues are left up to and also hampers efforts to develop generic the designer of the device. The result is that each troubleshooting methods. This paper presents software device is unique in the way messages are interpreted at developed independently at three other labs and both the DTE and DCE ends and this makes it difficult integrated into a single system at Jefferson Lab to to develop a generic method of programming that will handle serial devices in a generic manner. The software support the range of possible RS-232 devices. is based on the EPICS toolkit [1] and uses a 3-tier architecture including a common serial driver at the 2 DEVELOPMENT, DIAGNOSTIC AND bottom, a top-level protocol to specify individual INFORMATION TOOL FOR RS-232 device commands in a generic manner, and mid-level software to "glue" the two together. 2.1 Background 1 INTRODUCTION The accelerator control system at Jefferson Lab is based on the EPICS toolkit. With its very powerful set RS-232 is one of the oldest computer communication of tools, EPICS allows easy system extensions at all standards. It was introduced in the early 1960s as the control levels. Several devices within the control recommended standard (RS) number 232 for the system utilize serial communications. Most of these "Interface between Data Terminal Equipment and Data systems connect to the serial ports on the Input-Output Communications Equipment Employing Serial Binary Controller (IOC) transition module. Since it is Data Interchange" [2]. There are two types of serial relatively easy to access these serial ports using the devices: the Data Terminal Equipment (DTE) and standard terminal I/O driver supplied with VxWorks, Data Communication Equipment (DCE). The computer such systems treat the serial ports as file I/O and write is considered a DTE, while peripheral devices, such as custom EPICS subroutine records or State Notation modems, are DCEs. The two are linked together Language (SNL) sequencers to control devices through through a serial port and the connection is relatively simple read/write commands. This is not an optimal slow since data travels across a wire one bit at a time. way to handle device control for several reasons. First, Serial ports consist of two signal types: data signals and there are only a very limited number of available ports control signals. The physical connection in a serial line on the transition modules (usually, 2-4). Second, this can be as simple as three wires for "data in", "data out" method bypasses the standard EPICS model that and signal ground. Additional wires may be used for divides device control into three distinct layers: a layer "handshaking" when two ends of the communication which interfaces directly with the device (driver line tell each other that ∗ Supported by DOE Contract #DE-AC05-84ER40150 200 8th International Conference on Accelerator & Large Experimental Physics Control Systems, 2001, San Jose, California support) and is essentially independent of EPICS, a The serial device/driver support library uses a three layer which handles communications with Channel tier software architecture: a common serial driver at the Access, the EPICS network protocol, and has no real bottom, a top-level protocol to specify individual knowledge of the underlying device (record support), device commands in a generic manner, and a mid-level and a layer in between that handles the interface software to "glue" the two together. between the two (device support). The method that has been in use at Jefferson Lab moves all of the processing 2.2 Common Serial Driver into the top layer. This makes it difficult to properly This tier deals with the serial ports used for the identify serial applications since hardware communication with control devices. It is multi- identification in EPICS is handled through the device component software. Each type of supported RS-232 layer. It also makes such tasks as upgrading the version communication hardware is handled by the of EPICS or changing the processor type difficult since corresponding software component. Currently, the each of these serial applications shares no common VME serial transition modules, "on board" IOC serial device or driver support and each must be upgraded, ports, IP-Octal modules, and 16-channel intelligent tested and verified separately. asynchronous serial controllers VMIVME-6016 are The serial device control at Jefferson Lab followed supported. It should be fairly easy to integrate other this non-standard pathway because EPICS is based on serial drivers into the system. an inherently register-based control algorithm. Each Each serial port is served by a separate control task record assumes that it is connected to a single control that exchanges messages with the EPICS database channel providing the same type of information with records referencing this port. The serial port control every access. Serial devices can serve a variety of data task reads and writes data into and out of the serial port. types and command sequences through a single It also handles the hardware operation timeouts. channel. This makes it difficult to fit into the EPICS The driver layer is activated with the use of two model. A detailed analysis of many serial control basic calls. The first call initializes the serial applications that have been created in the EPICS communication hardware. The second call sets the community reveals that all the elements for a generic basic communication parameters for each serial port EPICS-based serial control model exist. All that is provided by the underlying hardware: the baud rate, needed is to put them together to form a single system. data word size, number of stop bits, parity, etc. All RS-232 was one of the first subnets supported by activation calls for each IOC are combined into one EPICS. An EPICS terminal driver and low level drivers serial configuration file. This file is downloaded into for several common serial interface devices were the IOC at start up time and activates the driver. The developed [3]. Many attempts were made to fashion control system is then ready to communicate with serial traditional EPICS device support on top of this layer devices connected to the initialized serial ports. but these attempts were not successful for the reasons mentioned above. Two recent additions to the EPICS 2.3 Serial Protocol Software code base have provided the missing pieces. The first is the Message Passing Facility (MPF) [4] developed by Each type of serial control device has its own set of Marty Kraimer at Argonne National Laboratory. The commands and data formats. Every action of the device second is the Stream Device Support software [5] consists of a sequence of input and output operations developed by Dirk Zimoch at the University of and a set of additional parameters that affect data Dortmund. The MPF system was developed as a device transfer, such as separators, terminators, or timeouts. support layer mechanism to pass messages to and from This is called the serial protocol. Each serial protocol processes. It does not directly connect to EPICS has a name that is usually associated with a particular records. The Stream Device Support software connects device action. All serial protocols for each device type directly to EPICS records but does not have an are combined in one serial protocol file. All serial interface to the serial driver software. The tool protocol files reside in one directory. The file name, developed at Jefferson Lab combines these two device the protocol name, and the information about the type support layers along with several serial drivers to of RS-232 hardware and serial port on this hardware provide configurable, generic serial support software. are referenced by INP or OUT links of EPICS database The tool consists of the serial device/driver support records. At IOC initialisation time, the serial protocol library, an information system about the use of this software parses the protocol file and defines the device library for various control applications, and the details control actions for all such records. This information of the RS-232 standard. becomes part of these EPICS records. 201 8th International Conference on Accelerator & Large Experimental Physics Control Systems, 2001, San Jose, California c) create the EPICS database that will handle the serial 2.4 Middle-Layer Software device command protocol; This software layer is used to "glue" the two tiers d) connect the device to the serial communication port described above and to provide a user with RS-232 with a proper cable; diagnostics.