The KEKB Accelerator control system[1] is based on EPICS(Experimental Physics and Industrial Control System)[2] and uses many PLCs in the magnet protec-tion systems and the radiation safety system. In order to monitor the interlock status, Modbus Plus[3] is adopted as the protocol between an IOC(Input/Output Controller) and PLCs. For this purpose, a device support and a driver support for Modbus Plus have been developed. The device/driver support modules allow an IOC to communicate with PLC-s by asynchronous I/O transactions, in such a manner that the GPIB devices do. With the software modules, an IOC works always as a master device on the Modbus Plus net-work to read the status of controlled devices from PLC memory. While the main use of the software is to read the interlock status, it is also used to reset the interlock sys-tems. Details of the software structure are described. An ap-plication of this software in the KEKB accelerator control system is also presented. 

Katoh, T

Kudo, K

Kurokawa, S

Nakamura, T T

Odagiri, J I

Yamamoto, N

J. Odagiri

T. Katoh

K. Kudo

S. Kurokawa

T. T. Nakamura

N. Yamamoto

CiteSeerX

Interfacing modbus plus to EPICS for KEKB accelerator control system

CERN Document Server

INTERFACING MODBUS PLUS TO EPICS FOR KEKB ACCELERATORCONTROL SYSTEMJ. Odagiri, T. Katoh, K. Kudo, S. Kurokawa, T.T. Nakamura, and N. YamamotoKEK, High Energy Accelerator Research OrganizationOho 1 - 1, Tsukuba, Ibaraki, JAPAN 305AbstractThe KEKB Accelerator control system[1] is basedon EPICS(Experimental Physics and Industrial ControlSystem)[2] and uses many PLCs in the magnet protec-tion systems and the radiation safety system. In order tomonitor the interlock status, Modbus Plus[3] is adopted asthe protocol between an IOC(Input/Output Controller) andPLCs.For this purpose, a device support and a driver supportfor Modbus Plus have been developed. The device/driversupport modules allow an IOC to communicate with PLC-s by asynchronous I/O transactions, in such a manner thatthe GPIB devices do. With the software modules, an IOCworks always as a master device on the Modbus Plus net-work to read the status of controlled devices from PLCmemory. While the main use of the software is to readthe interlock status, it is also used to reset the interlock sys-tems.Details of the software structure are described. An ap-plication of this software in the KEKB accelerator controlsystem is also presented.1 INTRODUCTIONThe commissioning of the KEKB accelerator was launchedin December 1998 and is now under progress. The con-trol system of the KEKB accelerator has been constructedbased on the EPICS software tool kit. EPICS provides ap-plication developers with rich functionality at various lay-ers, especially at the IOC layer[5]. However, site-specifichardware requires new driver software to interface withEPICS.One of them in the KEKB control system is the PLC de-vice. Several kinds of PLC devices are used in the KEKBcontrol system. Among these, the PLCs which talk Mod-bus Plus protocol are used in the magnet protection sys-tems and the radiation safety system. While these systemsare managed by the PLCs locally and autonomously, theinterlock status should be monitored on the console in thecentral control room.A set of software has been developed in order to inter-face these PLCs to EPICS. It has the standard structure re-quired for the device access layers of EPICS. It consistsof a device support and a driver support. The device sup-port deals with the processing specific to the Modbus Plusprotocol. The device support is described in section 2 indetail. The driver support interfaces directly with the hard-ware and handles physical I/O requests. The driver sup-port is described in section 3. This layered structure al-lows the software to be ported easily onto another systemsuch as COACK-II(Component Oriented Accelerator Con-trol Kernel-II)[4] in the future. Section 4 describes the ap-plication of this software in the KEKB accelerator controlsystem. This paper focuses on the hardware access layerand does not refer to any user interfaces.2 DEVICE SUPPORT2.1 I/O transactions and record processingThe Modbus Plus protocol provides a set of standard dataaccess commands to read the PLC memory or to write intoit. An IOC sends these commands as a master device onthe Modbus Plus network.Since the communication with the PLC could cause a de-lay in the order of milli-seconds, the device support musthandle the I/O in an asynchronous manner. The device sup-port enters a request on its queue and notifies the driver thatthe new request must be processed. After the PLC com-pletes the processing of the request, the IOC gets a responsefrom the PLC and the transaction is completed. This is thecase not only for reader access but also for writer accessbecause PLCs return a response even to the Modbus com-mands for writer access. The device support inspects theresponse to confirm the validity of the transaction.In this case, user applications can put a new value in-to EPICS records through Channel Access[6] even if anI/O transaction is in process. This is because the record isnot in locked state while it is waiting for the asynchronouscompletion. However, that request can not be processed bythe device support because the record is in busy state(PACTfield of the record is being set to 1). This can cause inco-herencies between the EPICS records and the remote PLCmemory, if successive writer access requests are sent fasterthan the processing speed at the device access layer. Theapplications must be designed so that they can take care ofthis possible incoherency.2.2 Record types and Modbus commandsThe data accessible in PLC memory can be divided intotwo classes. One is a bit of data which is held on eithercoils or inputs. The other is a word of data(16 bits) whichis held on holding registers or input registers. Bi/bo, mb-biDirect/mbboDirect, and waveform records are used forthe former data class. Ai/ao and longin/longout records areused for the later data class[7]. The inputs are read-only forboth classes, while the others are read and write.International Conference on Accelerator and Large Experimental Physics Control Systems367International Conference  Accel rator and L rge Experim ntal Physics Control Systems, 1999, Trieste, ItalyIn the Modbus Plus protocol, the type of data is denot-ed by the highest digit of the address. From the addresstogether with the type of the record in question, the de-vice support can decide which Modbus command is con-cerned. An appropriate Modbus command is selected foreach record during the initialization of the device support.The users are requested to select an appropriate record typeand to input the address information summarized below: Modbus Plus node address on the network address of the data in the PLC number of bits to be accessed(only for mbbiDirec-t/mbboDirect, and waveform records) routing path(described in the next subsection)2.3 Routing supportModbus Plus supports up to five stages of message routingthrough bridge nodes. The device support reads routing in-formation together with the address information and passesthem down to the driver support as a request. The driversupport builds a data packet from the request and passesit down to the logical link control(LLC) layer which hasbeen implemented on the interface board(described in thefollowing section).3 DRIVER SUPPORT3.1 Interface BoardThe model SV85 supplied by Modicon was adopted as theVME Modbus Plus interface. A processor on the boardmanages the processing required below the LLC layer. Thedriver support loads the data packet, which includes a Mod-bus command and routing information, and issues an in-terface command to have the board send the data packet.After the transaction is completed, the driver unloads theresponse from the board by issuing other interface com-mands.Some of the features of the board are: functions as A24 or A16 VME slave no DMA capabilities transfer rate of approximately 500 ns/byte supports concurrent transactions on eight logical linksto be in process at the same time.That last feature had a significant impact on the design ofthe task assignment in the driver support.3.2 Task AssignmentThe driver support spawns the following tasks to supportconcurrent transactions on the logical links. tPutTask: has the board send the data packet whenthe task gets a request and an idle logical link, book-s which transaction is going on the logical link, andstarts a watchdog timer for the transaction. tGetTask: inspects on which logical link a transactionhas been completed when the task is awaken by aninterrupt, cancels the watchdog timer, and unloads theresponse from the board, then releases the logical link. tAbortTask: checks if a logical link with the expiredwatchdog timer still holds a transaction, and if this isthe case, it aborts the hanging transaction and releasesthe logical link.These three cooperative tasks work together to get ful-l transaction capability of the interface board.Another task, named tKeepAlive, supplements the activ-ities of the driver support. It just keeps issuing a interfacecommand to keep the board alive even if there is nothing tobe done.3.3 Interrupt handlingThe board generates two kinds of interrupts. One is theimmediate reply to an issued interface command and theother one notifies the completion of a transaction on thelogical links. An interrupt handler handles both of them.4 APPLICATION4.1 Applied systemsThere are three systems which utilize the device/driver sup-port to monitor the interlock status from the central controlroom. One is the radiation safety system and the others arethe magnet protection systems for the beam transportationline and the KEKB main rings.This subsection as well as following ones focus on themagnet protection system for the KEKB main rings, whichis the largest among these systems. The PLC system iscomposed of fifteen sets of I/O modules distributed aroundthe main rings. Only one of them has a CPU moduleand it collects all the data from the others through HDLClinks. An IOC communicates with this representative unitthrough a Modbus Plus connection.The KEKB main rings have about 1,600 water-cooledmagnets. The status of the cooling water flow and the mag-net temperature are monitored for each magnet. The statuschanges are latched on the associated holding coils provid-ed in the PLC memory. The IOC monitors the latched s-tatus rather than raw inputs. This is needed because theinput status is automatically recovered when the interlockcondition is spontaneously restored. This is more likely tohappen on the water flow status due to the fluctuation. Thelatched status is cleared by an operator through write chan-nels.In addition to the interlock status, the cumulative countsof communication errors, which occurred inside the PLCsystem, are also monitored by the IOC.4.2 Database designThe IOC polls the PLC periodically in order to monitor theinterlock status. This method is adopted because it does not368require any additional programming for the PLC to achievethe monitoring, except for the latch logic.To reduce the number of transactions required to scan thePLC memory, waveform records are used in this system.Unfortunately, the data to be transferred has to be dividedinto at least two groups, because the number of data pointsexceeds the maximum(two thousand bits) allowed for sin-gle Modbus Plus transaction. From a logical point of view,they are actually divided into eleven groups.On the other hand, it is convenient for the higher levelapplications that the IOC holds each status bit as an inde-pendent bi record. It is possible to decompose the data bitsin a waveform record into a set of bi records by using thedatabase link mechanism only. However, it is simpler tocreate a special device support routine which directly map-s the bi records onto a waveform record. This is purely asoftware device support in the sense that it does not causeany Modbus Plus transactions in itself. It just allows a birecord to read a bit of data from an appropriate position ofthe associated waveform record.Consequently, the database has a double layer structure.The lower layer maps the PLC memory onto the waveformrecords on the IOC by executing Modbus Plus transaction-s. The higher layer maps the bi records onto the associat-ed waveform record by using the software device supportspecific to this purpose. Applications running at the man-machine interface layer see only the bi records throughChannel Access. Table 1 summarizes the ingredients ofthe database designed for the system.Table 1: Records in the designed databaseRec. Type # of Rec. Use HW accessbi 3340 int. status nowaveform 11 int. status readlongin 14 com. error readbo 43 latch clear, etc. write4.3 Resource consumptionA database scan processes more than three thousandrecords, and causes twenty-five Modbus Plus transaction-s. A scan rate of around 1 Hz is supposed to be sufficientfor the accelerator operation. The measurement of the CPUload showed that the database scanning at the rate of 1 Hzcaused about fifteen percent of the CPU load on the ForcePowerCore-6750 CPU board(266MHz, 64MB RAM). Ta-ble 2 shows the CPU load arising from the relevant tasks.Most of the CPU load came from tGetTask, which hadto copy the Modbus response from the interface board tothe IOC memory. One of the EPICS general purpose task,named scan60, executed the processing of all records.As for the memory consumption, the database requiredrather large amount of memory at the cost of holding a bitof status data as a record. The total memory consumptionwas about 4M bytes at run-time. This is in the acceptablerange for the CPU board with 64M bytes RAM, which isnow being used in the KEKB accelerator control system.Table 2: CPU load(at 1Hz)task CPU load(%)scan60 2.0tPutTask 1.0tGetTask 11.3tAbortTask 0.0tKeepAlive 0.2interrupt 0.1Total 14.65 CONCLUSIONA device support and a driver support for Modbus Plus havebeen developed in order to interface PLC devices to EPICS.They are used to monitor the interlock status of the mag-nets and the radiation safety system, for the KEKB accel-erator operation. The software has run stably for more thanhalf a year on several IOCs since the commissioning of theKEKB accelerator was launched.The database designed for the magnet protection systemcould monitor more than three thousand bits of status dataat the scan rate of 1 Hz, consuming fifteen percent of CPUability and about 4M bytes of memory.6 REFERENCES[1] T.Katoh, et al. “Present Status of the KEKB Control System”,ICALEPCS’97, Beijin[2] L.R.Dalesio et al., “EPICS Architecture”, in Proceedings ofICALEPCS’91, KEK, Tsukuba, Japan, 1991, pp. 278-282.[3] “Modicon Modbus Plus Network Planning and InstallationGuide”, Modicon, Inc., Industrial Automation Systems[4] I.Abe, et al. “Project on Accelerator Control Kernel Develop-ment”, in these proceedings.[5] J.B.Anderson and M.R.Kraimer, “EPICS Input/Output Con-troller(IOC) Application Developer’s Guide”.[6] J.O.Hill, “EPICS R3.12 Channel Access Reference Manual”.[7] J.B.Anderson and M.R.Kraimer, “EPICS Input/Output Con-troller(IOC) Record Reference Manual”.369

Interfacing Modbus Plus to EPICS for KEKB Accelerator Control System

http://www.elettra.trieste.it/ICALEPCS99/proceedings/papers/tc1p25.pdf

Interfacing Modbus Plus to EPICS for KEKB Accelerator Control System

Abstract

Similar works

Full text

Available Versions

CiteSeerX

CERN Document Server