Keywords

1 EPICS Introduction

The EPICS software [1] was originally designed to be tool based approach to process control and this continues to be its primary application. An infrastructure that encourages proper design of distributed software systems is also important. For example, in multi-threaded distributed systems, toolkit needs communication software interfaces designed to avoid application programmer introduced mutual exclusion deadlocks. Interfaces must also be properly structured to encourage robust response to loss of communication or other hardware resources. Portability among workstations and embedded systems is an important requirement for certain advanced applications. These capabilities are required by process control components.

The EPICS based software tools includes application software that offers a satisfying solution for measuring, processing tasks and secondary development software which is a powerful technology that allows software integrators and application uses to customize and automate the application software. Several extensions provided with EPICS could also be used for alarm handler, interlocking and alarming mechanism implementation. User interface design with MEDM which provides motif based user interface. Channel Archiver (CA) for the storage of data during shot and analysis with Strip tool or data browser. We could also able to use the CSS Best Opi Yet (BOY) for the user interface development which provides the XML based markup language integration with bundled widget options and integration based on Eclipse platform. Certain aspects of the existing EPICS communication software interfaces appear to be important facilitators for advanced toolkits. Close integration with process control systems requires efficient publish-and-subscribe communication strategies. Message-batching capabilities also improve communication efficiency. Software interfacing with systems capable of independent actions needs interfaces that can generate an asynchronous response synchronized with external events.

2 ICRH System

ICRH is a promising heating method for a fusion device due to its localized power deposition profile, a direct ion heating at high density, and established technology for high power handling at low cost. For the same reason 1.5-MW ICRH system is developed for Steady State Superconducting Tokamak (SST-1). SST-1 is a large aspect ratio Tokamak with wide range of elongation (1.7–1.9) and triangularity (0.4–0.7). The maximum plasma current is expected to be 220 kA. The maximum toroidal magnetic field at the center is 3.0 T. The major and minor radii are 1.1 and 0.2 m. 1.5 MW of RF power is to be delivered to the plasma for pulse lengths of up to 1,000 s [2]. The block diagram of the integrated ICRH system has shown in Fig. 1. The first block named RF Source will generate RF Power as per the requirement with different frequencies for the experiment. This operation remotely controlled by Master DAC system and the other part means generated power transmission with matching network and antenna diagnostics would be controlled and monitored by slave DAC system. Both DAC systems have been described in next sub sections.

Fig. 1
figure 1

ICRH block diagram

Full size image

2.1 ICRH Master DAC System

ICRH has two separate DAC systems, which have been used for two different requirements. The first DAC system been installed at RF Lab to control and monitor the RF generator system, which are provides RF power at 22–25, 45.6 and 91.2 MHz frequencies. Master DAC would remotely operate the different stages of RF Generator like 2, 20, 200 kW and 1.5 MW. 2 and 20 kW stages require two different plate power supplies. 200 kW and 1.5 MW 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 Master DAC system with required interlocks. The block diagram has been shown in Fig. 2 with different stages. All the signals coming from different stages have been connected through front end electronics and signal conditioning which ends at VME terminal end. The application allows control of a variety of hardware, ranging from straightforward, continuous data streaming of a few channels to multi-rack based data acquisition instruments.

Fig. 2
figure 2

Block diagram of ICRH generator DAC

Full size image

2.2 ICRH Slave DAC System

Slave DAC system is responsible to control and monitor RF transmission and diagnostics using two transmission lines with offline and online matching system followed by Interface sections and antenna diagnostics. The systematic block diagram of the all connected systems has been shown in Fig. 3 for single transmission line. The red oval indicates the master DAC system which have been used as RF generator system as explained via Fig. 2. The DAC server would only get triggered with the trigger pulse provided by the Master DAC either by external hardware or software. The transmission line consists of (a) a pressurized 9 in. 50 Ω coaxial line, (b) matching systems at two different time scales and (c) vacuum transmission line called interface, linking the transmission line to the fast wave antennae. One single line transmits the power from the RF generator to the two antenna boxes placed at diametrically opposite radial ports. Each transmission line arm has 24 voltage probes, motorized automatic matching network (in ms) and course tuner (in s). Automatic matching network consists of two stubs coupled with stepper motor and two numbers of vacuum variable capacitors coupled with high-speed servomotor. Interface section has vacuum system which has been monitored and acquired with the desired time scale with Linux terminal using serial port. The systems would have connected with some diagnostics which requires faster scale acquisition of the signals like density calculations and some probe signals coming from Antennae interface connected with SST1 machine.

Fig. 3
figure 3

Block diagram of ICRH transmission line with matching network

Full size image

Two another probe signals among the 24 probe signals have been used for local voltage 1 and local voltage 2 for the Automatic matching network error signal calculation along with forward and reflected power. Coarse matching network have been used for the offline matching before the experiment starts and the automatic matching network have been used during shot as it works as fast matching network to match the input impedance with the plasma impedance. This algorithm is based on feedback control loop at every 5 ms which uses the four signals from the transmission lines, calculate the reflection coefficient and that will be used for the error signal calculation. There error signals are being used for the deciding parameter for the cylindrical capacitor direction either clockwise or anticlockwise. The faster 1 kHz sampling rare has been used for all 32 × 2 signals and around 24 diagnostic signals. There is hardware as well as software interlock have been implemented and tested before experiment and maintained periodically [3, 4].

2.3 Integrated DAC Approach

Integrated DAC system block diagram has been shown in Fig. 4. Both DAC systems have been connected with Ethernet communication and hardware link for fast controller trigger line. The acquisition of the data during experiment would be done at very fast scale like 1 kHz. This process will follow the cycle like the VME processor board will get data from the analog or digital board register memory buffer. At the time of shot the data would be available at the digitizer cards. After shot the data would be demanded by the Linux user interface the socket communication is been established and the packet structure wise data have been available on Ethernet. The processor board will store the data in buffer memory from the digitizer board using messages queue implemented by program. Linux terminal will take the data from that buffer using Ethernet network. The data will be acquired (stored) on user interface computer by the GNU socket library program.

Fig. 4
figure 4

Block diagram of integrated DAC systems

Full size image

3 EPICS Implementation

There are about 32 analog input channels, 12 analog output channels and 64 digital I/O channels consist at master DAC same way 96 analog input channels, 12 analog output and 128 digital I/O channels are connected with slave DAC system. The requirement of different channel IOs have been catered with the EPICS base module installation at Linux terminal. To make user interface the state notation language (XML) has been used with CSS IDE and assign required field widgets with respective process variables. The signal naming has been specified at the ICRH: <signal_name>. Using soft IOC module we have broadcasted the process variables (PVs). XY graph has been chosen for monitoring the voltage and current signals. Python script has been used for the periodic assignment of the channels process variables using caput command for apply periodic new value to the respective process variable. Separate python script is running periodically using execute command function provided on action button click event. In this script we have used pyepics [5] package and import epics as python module and will able to process caget and caput command as per requirements.

We have also used cython package for the load shared object module as dynamic library which was made using C program for socket communication with fast controller [6]. Using this module we can run python script on action button event for socket communication and reading and writing data as per need. In separate thread we can run this module which will not affect the main monitoring and control process.

The fast fiber optic trigger network will give trigger pulse to fast controller at Master DAC. This fast controller get triggered that will trigger the fast controller at RF transmission DAC fast controller. As fast controller triggered the digitizer card buffer memory will get filled with the given on-time reference time. This data will be acquired by the Linux terminal user interface program with acquire button by socket command using Ethernet. The integrated architecture of both DAC systems has been shown in Fig. 5. Master DAC will be communicated by Central Control System (CCS) communication with details of shot number and experimental parameters by Ethernet based communication program and time synchronization by Network Time Protocol (NTP) from Master GPS timer. Master DAC will communicate with slave DAC system with EPICS process variables. Data acquired at master DAC have been sent to the slave DAC and that will acquire data accordingly.

Fig. 5
figure 5

Integrated architecture of both DAC systems

Full size image

3.1 Advantages Over Existing System

  1. 1.

    Synchronize in required timescale for both DAC in terms of data monitoring, interlock and acquisition.

  2. 2.

    Smooth operation of real time feedback control loop with interlocking using lightweight process variables.

  3. 3.

    Data monitoring and acquire of vacuum data using serial communication on Linux terminal using micro ion gauge with synchronization of acquire trigger pulse.

  4. 4.

    Automatic acquisition of data at slave DAC for transmission lines and diagnostics in synchronous with master digital pulse from master DAC.

  5. 5.

    Interlocking the master DAC system from slave DAC parameters with real time action like reflection coefficient and vacuum degradation which was the limitation of existing system.

  6. 6.

    Process variables available in real time requires by other sub system for synchronous operation which was another limitation of existing system.

  7. 7.

    Experimental Parameters exchange in real time with Central Control System.

  8. 8.

    Accelerate development of next-generation, broad-reach applications.

  9. 9.

    Using web technology revolution one can get the platform independency.

  10. 10.

    Save time with the ultimate developer cockpit.

4 Database

MDSplus (Modal data system) [7] is a data management system used in several Nuclear Fusion experiments to handle experimental and configuration data [8, 9]. Many application programming interface (API) for local and remote data access are available with most languages, namely C, C++, Fortran, Java, Python, MATLAB and IDL, and a set of visualization and analysis tools are available for data browsing and display. In this way, it is possible to take advantage of the availability of the local and remote data access layers of MDSplus, widely used in the fusion community to handle large sets of data. The MDSplus system has been successfully adopted in many fusion experiments for data acquisition, storage and access [9]. MDSplus provide the hints to achieve continuous data acquisition during the experiments required to use acquired data in the active control of the experiment. We could use Channel Archiver tool for binary data storage of process variable to MDSPlus database. The Channel Archiver [10] is a generic periodic sampling toolset for EPICS. Using the EPICS Channel Access (CA) network protocol [11], it can collect real-time data from any CA server on the network. The Channel Archiver acts as a Channel Access Client and stores recorded data, acquired via periodic scan or monitored, into indexed binary files [12].

The acquire data at the slave DAC will be done with the shot number at slave DAC embedded master DAC shot number for synchronization. Shot detail form master DAC would be sent in separate child process because it should not affect the main running process of monitoring and control and master DAC. Same way another thread is waiting at slave DAC will watch for the coming information from master DAC and acquires data accordingly.

5 Conclusion

We can handle experimental requirement with broadcasting mechanism using channel access protocol with EPICS. Channels as process variables have been broadcasted every required time period so when the shot is applied to master DAC, the information has been automatically available to slave DAC on same network. There is no need to run separate thread for this purpose and lightweight process of broadcasting process variable will be accomplished easily. By using this proposed system we could also able to synchronize the ICRH DAC system with Central control system. We haven’t considered this section in this paper. The final implementation with experimental results will be published after deployment of conceptual implementation in sub sequent paper.