Design and development of PLC based DAC for 45.6 ...

Technical Report

Design and development of PLC based DAC for 45.6 MHz, 100kW ICRH system using EPICS and MODBUS/TCP Ramesh Joshi1, H M Jadav, YSS Srinivas, Sunil kumar and S.V. Kulkarni 1

Email: [email protected]

INSTITUTE FOR PLASMA RESEARCH, NEAR BHAT VILLAGE, GANDHINAGAR- 382428. INDIA

Index: Sr. No.

Title

1 2 3 4

Abstract………….………………………………………………………….. Introduction…………………………………………………………………. ICRH DAC Architecture…..………………………………………………. PLC interface with computer over MODBUS……………………………. (a) MODBUS MESSAGING PROTOCOL.…………………………. (b) MEMORY MAPPING IN MODBUS ……….………………….... (c) MODBUS/ TCP WITH PYMODBUS………..…………………... (d) PYMODBUS DEMO APPLICATION………..………………….. DAC PLC communication with Integrated power supply PLC………… DAC communication with Central Control................................................ EPICS interface with CSS and logic implementation using python.……. CSS user interface design………………………………………..………… Data acquisition…………………………………………………..………… Data analysis….…………………………………………………..………… TEST SETUP……….………………………………………………………. RESULTS AND DISCUSSION……………………….………………….... Conclusion........................................................................................................ References........................................................................................................ Appendix..........................................................................................................

5 6 7 8 9 10 11 12 13 14 15

Page. No 1 2 2 4 5 5 7 8 10 11 11 12 13 14 14 15 16 16 17

Design and development of PLC based DAC for 45.6 MHz, 100kW ICRH system using EPICS and MODBUS/TCP Ramesh Joshi1, H M Jadav, YSS Srinivas, Sunil kumar and S.V. Kulkarni Institute for Plasma Research Bhat village, Gandhinagar – 382428 Email: [email protected] Abstract The Data Acquisition Control system (DAC) for Ion Cyclotron Resonance Heating (ICRH) system is commissioned for remote operation of heating experiment on tokamak. This system will be used for ion Bernstein wave heating experiments on tokamak. As per the requirement of DAC, it needs 32 analog inputs, 32 digital inputs, 16 digital outputs and 16 analog outputs channels for monitoring and control of the 100 kW, 45.6 MHz RF system. For the same reason Delta automation PLC (AH500 series) has been procured for remote experiments. It provides interface with MODBUS which is an open standard protocol and communicates over TCP/IP. MODBUS provides memory maps for read and write coils for digital I/O interaction and 16 bit registers to read and write analog registers as required by DAC. National Instruments (NI) fast data acquisition card has been interfaced for high speed data acquisition during experiment which uses trigger communication via PLC. MODBUS/TCP protocol is widely used in the industrial control field because of its excellent reliability, flexibility, real-time performance etc. MODBUS/TCP follows a master and slave architecture where a master (PC) transmits a request to a slave (PLC) and waits for the response. Pymodbus library allows reading of data from PLCs and writing of data to PLCs over Ethernet using specified MODBUS addresses in two way communication. Pymodbus uses asynchronous communication over TCP/IP connections that reduces the amount of code, and has good debugging and connection management. This report describes the integration scheme and control structure of EPICS based DAC using PLC over MODBUS/TCP. It is decided to use EPICS as control system which uses python for logic implementation. Python would be the better choice as it provides both pymodbus and pyepics libraries for single platform interface. Fast data acquisition has been handled by USB based data acquisition module (NI USB6242) which works on event trigger provided by PLC.

1

1. INTRODUCTION High power ICRH system is one of the prominent auxiliary heating systems utilized for tokamak heating experiment. PLC based DAC has been envisaged and development process has been going on for control and monitoring of the High power ICRH-RF heating experiment in tokamak[1]. There are two different requirement of this system on for second harmonic heating at 45.6 MHz system and another is for IBW heating at 40 MHz for Aditya. As a part of this development phase the communication with user interface computer and PLC should be established and it should run in failsafe manner [2, 3]. There are three different requirement of DAC. (1) Periodic monitoring data at every 100ms interval, (2) Interlock and control of different power supplies connected with each RF amplifier stage and (3) Acquisition with the rate of (>=1kHz) for RF power generation in pulsed mode. This report describes first two DAC requirements which need MODBUS/TCP communication over Ethernet because of stringent time requirement for control and interlock. The third requirement needs fast sampling with data acquisition module in synchronization with PLC. There are several MODBUS libraries available to communicate with open source MODBUS protocol with PLCs. Python is a script language available with different operating systems which will be the core part of software development. Pymodbus library is open source site package for python which is the better option among several MODBUS library implementations [4]. In next subsequent sections we present the ICRH system and MODBUS implementation for application. DAC would remotely operate the different stages of RF Generator like 2 kW, 20 kW and 100 kW. 2 kW and 20 kW stages require two different plate power supplies. 100 kW systems would have four different power supplies each which are named as plate, control grid, screen grid and filament power supply. These all power supplies have different voltage and current setting with raise/lower functionalities. These all functionalities would be remotely controlled and monitored by DAC system with required interlocks. Figure-1 shows schematic of ICRH for SST-1 tokamak which use for second harmonic heating at 45.6 MHz. RF source is connected with hybrid coupler which divides power equally in both arm of transmission line. Transmission line has two different matching networks to deliver maximum power. Finally power transmitted using vacuum interface section to antenna end. Figure-2 shows schematic of ICRH for Aditya tokamak which use in IBW heating at 40 MHz. RF source connected with transmission line along with matching network which connects using interface section to the antenna end. All the signals coming from different stages have been connected through front end electronics and signal conditioning which ends at PLC terminal end. The application allows control of a variety of hardware, ranging from straightforward, continuous data streaming of a few channels to multirack based data acquisition instruments. 2

2. HIGH POWER ICRH SYSTEM

Figure-1. ICRH Schematic for SST-1

Figure-2. ICRH Schematic for Aditya

Function Generator (5mW)

Low Power Amplifier Stage (50W)

Pre Driver Stage (2kW)

Driver Stage (20kW)

High Power Stage (100kW)

Load

PLC based Integrated PS

Front End Electronics and Signal conditioning – Filed IO Interface

MODBUS TCP

PLC (DELTA AH500)

DAC Computer System for user control and operation

Figure-3. Block diagram of ICRH Generator DAC 3

3. ICRH DAC ARCHITECTURE As shown in Figure-3, signals coming from function generator are amplified through low power amplifier, pre-driver stages of 2 kW and 20 kW followed to high power 100 kW stage. The list of all signals is given in Appendix-I at the end of report. These signals are fed to signal conditioning circuits so that the signals meet the requirements for further processing. To operate the amplifier stages independently, PLC is used for monitoring and control for each RF amplifier stages and connected power supplies. Integrated power supply (IPS) has been used for 100 kW RF amplifier stage. It includes all four power supplies required for the operation with PLC support. Our PLC communicates with hardware signals with IPS power supply PLC for control and monitoring. Voltage signals (0-10 V) generates by our PLC using software program to set the voltage level as per power supply calibration. For monitoring and accessing the signals of PLC on a user interface, MODBUS/TCP protocol over Ethernet is used as communication medium. The field test results with the wireless monitoring system using Zigbee gives good and robust performance in terms of transmission the data over MODBUS which proves applicability and performance of MODBUS based communication [5]. A cryptographic scheme can be applied to enhance the MODBUS protocol with authenticity, in which it is infeasible for an attacker to maliciously forge as the master[6]. This User interface consists of python based pymodbus library which is the implementation of MODBUS stack in python. The aim of this design is to make it open source to enhance the design flexibility and reliability using pymodbus library over python. Using EPICS optimization has also been achieved for the similar kind of a system [7]. At Advance Photon Source (APS) set of binary and analog values are passed using EPICS which use the same concept [8].

Figure-4. MODBUS master-slave architecture Here in this report ICRH DAC software can be broadly categorized in following subsystems. • • • • •

PLC interface with computer over MODBUS DAC PLC communication with Integrated power supply PLC DAC communication with Central Control System EPICS interface with CSS and logic implementation using python CSS user interface design 4

4. PLC interface with computer over MODBUS a.

MODBUS MESSAGING PROTOCOL

The MODBUS protocol is an open communication protocol which was developed in 1979 by Modicon, for industrial automation systems. Originally this protocol is implemented as an application-level protocol which is intended to transfer data over a serial layer, now has expanded to include implementations over serial, TCP/IP, and the user datagram protocol (UDP). It is application layer implementation of TCP/IP stack on port 502 [9]. MODBUS protocol is the most available means of connecting industrial electronic devices. This protocol follows a master and slave architecture as shown in Figure 4, where a master transmits a request which is indicated to a slave and then waits for a response from the slave. Communication protocol data unit and application data unit (ADU) has been described using figure 5. Protocol data unit (PDU) comprises with function code and data for the register. Additional addresses and error checking would be added in PDU to build ADU. Figure 6 shows the transaction between master and slave for read and write operations. If response contains error, slave will respond with error code. Here PC acts as master and PLC acts as slave. Master can communicate with one or multiple slave devices (PLC’s). Most vendors provide the MODBUS memory map for respective devices like PLCs. Those addresses have been accessed by master computer with seamless communication either on Ethernet or Serial. TABLE-I MEMORY MAPPING MODBUS address Type

TABLE-II PLC ADDRESS RANGE Address types

Read or Write Coils Read Only

Discrete Inputs

0x0000 to 0xFFFF Read Only

Input Registers

Read or Write Holding Registers

b.

MODBUS Address Range Register Function address types Codes 0x0001 to 0x8192

M0-M8191

0x0001 to 0x0064

D0-D63 (Analog Input)

0x0065 to 0x0096

D64-D95 (Analog Output)

Coils

01

Holding 04 register

MEMORY MAPPING IN MODBUS

Each MODBUS device has memory, where process variable data is stored. The MODBUS specification states the way for the data to get recover and what type of data can be recovered, still it does not place a restriction on the way of mapping the data in its memory map by the device manufacturer. A common example of how a MODBUS device manufacture might logically map different types of process variable data is shown in table-I. In table-I first column shows the MODBUS address ranges, second column shows type of registers and third column 5

shows the address types like coils (8 bits register) and registers (16 bits register). Discrete inputs and coils are one-bit values and each has a specific address. Analog inputs (also called “Input Registers”) are stored in 16-bit registers. Holding Registers are also 16-bit internal registers that can support floating point. Data in the memory map is defined in the MODBUS specification, so if the MODBUS device manufacturer follows the MODBUS specification (not all follows), then all data can easily be accessed by the MODBUS master. Memory addresses for the master device to communicate with the slave device (PLC) is shown in table-II. In table-II second column shows MODBUS address ranges for master device corresponding to slave address ranges. Third column shows register type and function code shows in fourth column.

Figure-5 ADU and PDU for MODBUS data frame

In our case we have procured Delta AH500 model PLC which has MODBUS memory map with internal bit register from 0 to 65535 in decimal [10]. These memory bit registers are used for read/write operation for digital status and control of power supplies and interlock operation. Analog devices use 16 bit registers but for this specific model it supports 32 bit floating value for value read/write control.

Figure-6 Transaction between MODBUS devices 6

c.

MODBUS/ TCP WITH PYMODBUS

Figure-7 State diagram of read/write operation using pymodbus MODBUS/TCP has been used over industrial standard Ethernet for our application. Ethernet provides the physical medium for communication and TCP/IP gets the data packets to the destination node. In MODBUS/TCP, IP addresses are used in place of device addresses to communicate with master/slave devices [11]. With MODBUS/TCP, the MODBUS data is 7

simply encapsulated inside a TCP/IP packet. MODBUS/TCP will allow multiple masters to poll the same slave device at the same time. This is possible due to the fact that multiple messages can be sent, buffered and delivered without the need of token passing over Ethernet using TCP/IP. For MODBUS master implementation in python pymodbus library is used. pymodbus is a full MODBUS protocol implementation in python and it should work properly under any python version greater than 2.3. Here we have used python version 2.6. Pymodbus needs the IP address of MODBUS/TCP client for establishing communication between MODBUS master and PLC.MODBUS/TCP master builds the application data unit which initiates a MODBUS transaction for read/write operation. Figure 7 shows the state diagram for read and write operation between MODBUS devices using pymodbus. Initially the communication between master and slave devices has been established for both units. Server receives PDU which has been explained by figure 4. Master sends request to slave for read or write operation. Request has been processed if initial address and quantities are properly assigned for read/write operation. If there is any error for assignment then it gives exception code by slave device at any time. If everything goes well slave responds with desired function code and data response. The function code field of a MODBUS data item is coded in one byte. The data request field of messages sent from MODBUS master to server devices contains additional information that the slave uses to take the action defined by the function code. Function codes for coil and register is given below in table-II at last column. This includes discrete output coils and register addresses, the quantity of data items to be handled, and number of actual data bytes in the field. d.

PYMODBUS DEMO APPLICATION

Test program uses struct, pymodbus client and payload as import package [12]. Program uses synchronous communication in between master and slave. Payload has been used with struct package to make 32-bit floating point register which is one of the requirements of slave PLC device for analog read/write operation. For making 32-bit floating point register struck package includes packing of two 16-bit registers and then unpack it to a 32-bit tuple. There are four main operations performed which are related to digital and analog status and control. Read coils and write coils are the function implementation available with pymodbus client hierarchy. Read coils uses two arguments first is for starting MODBUS address for memory bit and second is count of number of addresses to be read. First three memory bits have been read, among them first memory bit has been in ‘True’ position. Same way floating value of first holding register has been read by program using read_holding_register function. Both case has been discussed in Test setup in detail.

8

Figure-8 Demo application to validate communication using pymodbus There is a facility of setting the value of analog register and second memory bit for demonstration. Payload has been used for setting floating value of analog register at address of 00064. As per PLC requirement the big endian has been supplied as argument of BinarypayloadBuilder function for building floating register value. To validate communication between ISPSoft (PLC ladder program) using pymodbus, Graphical user Interface (GUI) is made using wxpython. It is shown in figure-8. It is a cross-platform toolkit built in python. Cross-platform signifies that the same program will run on multiple platforms without modification. Wxpython provides facility to build dynamic user interface with help of operating system widgets in object oriented manner [13]. Sample program has been developed with help of wxpthon which is able to show the values of different MODBUS addresses and execute memory write functions based on button click event in a GUI provided by wxpython. 5. DAC PLC communication with Integrated power supply PLC

9

Integrated power supply has inbuilt control in order to interlock and control of all four power supplies using PLC. This PLC takes care of power supply control with different switching mechanism along with start and stop sequence. For failsafe operation of power supply it has been implemented different logic program in ladder programming language. DAC PLC has to communicate with IPS PLC using different hardwired control. Several input as well as output signals have been controlled using two ways communication of both PLCs. Interlock from DAC side has been applied with hardware trigger to IPS PLC. Same way status of each power supply has been applied from IPS PLC to DAC PLC as per sequence of operation and control.

Figure-9 EPICS synchronization between CSS and PLC using python 6. DAC communication with Central Control system Integrated testing with tokamak it needs to communicate with central control system (CCS) which works as master for all connected systems. There are two different ways for such communication. 10

I.

External hardwired control to trigger DAC system which works in pulse mode and end of pulse information back to CCS II. Software communication for handshaking of different system includes shot number communication broadcasted from CCS and send data after shot to store in central storage server This requirement is taken in consideration while development of the system. DAC generates start and stop trigger pulse with external triggering facility for hardwired control by CCS. Same way EPICS provides software control for handshaking between both the systems. 7. EPICS interface with CSS and logic implementation using python Control system studio provides different widgets in drag and drop fashion. It also provides features like monitoring graph, data browser, logbook, spreadsheet table, different layout etc. It also provides RDBMS connectivity with data browser for interactive data storage. Figure-9 shows the user interface development for DAC software 2 kW and 20 kW stage.

Figure-10 Event handling by CSS using python script 11

It is also shown the terminal screen for broadcast of the process variables using EPICS module. EPICS provides command softIOC that is used for broadcasting. The data communication layer is a separate layer, which allows BOY connecting to various data sources seamlessly. Users can provide their own data source by extending an Eclipse extension point. As shown in Figure-10 event handling can be done using python script. There is several provisions given in CSS like “Add execute Javascript”, “Add execute Python script”, “Add execute command” etc. One can configure the event action as per embedded python script or external python script. There is other option available like on load widget for Rules and Scipt. Figure-11 shows the RF shot control panel. It shows different power supplies status, forward and reflected power monitoring graph and different power supplies voltages. According the status and values of different power supplies one can decide the parameter for RF shot. “On Time”, Öff Time”, “Delay Time” and “No. of Pulse” have to be set to apply RF shot according to experimental requirement. One has to feed the required parameter and give shot in synchronous with other network-connected subsystems.

Figure-11 RF shot panel

12

8. CSS user interface design CSS BOY is an Operator Interface (OPI) development and runtime environment. An OPI is a general GUI but with extra facilities to connect to your live data directly. CSS BOY allows building your GUI with drag and drop and connecting to your data instantly. It also allows using JavaScript or Jython to manipulate the GUI in a very similar way as using JavaScript in HTML. In BOY, the OPI Editor is a What You See Is What You Get (WYSIWYG) editor which allows you to create your GUI in a similar way of creating PPT. The OPI Runtime works in a similar way as modern web browsers. One can display the OPIs either in tabs, windows or views and navigate OPIs forward or backward. An OPI is a regular XML file that can be edited in OPI editor or text editor and run in OPI Runtime. No compilation is needed.

Figure-12 100 kW CSS development screen As shown in Figure-12 100 kW screen with connected power supplies. There are different control frames which have been developed like plate power supplies, filament power supplies, screengrid and controlgrid power supplies. User interface provides graph monitoring of voltage and current for respective power supply for trend. Actual values have been displayed in text boxes below graph monitoring. Different PV values have been displayed in the bottom panel of the screen. As per the alarm setting for each process 13

variable the color will be displayed like for saturation limit it shows red color, same way for acceptable range of variable it shows in green color with “OK” label. Log messages have been displayed on the same panel.

9. Data Acquisition USB based data acquisition module has been used to store data in faster scale (