9-12 Oct 2000PCaPAC 2000, DESY Hamburg Epics to TINE translator Matthias Clausen, DESY Hamburg Phil Duval, DESY Hamburg Zoltan Kakucs, DESY Hamburg

9-12 Oct 2000 PCaPAC 2000, DESY Hamburg

Epics to TINE translator

Matthias Clausen, DESY HamburgPhil Duval, DESY Hamburg

Zoltan Kakucs, DESY Hamburg


Contents

• Accelerator Controls at DESY

• EPICS and its CA

• History of creating EPICS to TINE translator

• Naming convention

• Mode of operation

• Conclusions, summary and future


Accelerator Controls at DESY

• Past – hampered by the

“many-control-systems” syndrome

– different subsystems controlled by completely different means

– no possibility of intercommunication (HERA)

• Today– practically all

subsystems of HERA in fact controlled by TINE

– important exceptions include:

• Proton Vacuum• cryogenics control• the super conducting

electron RF cavities• the power

subsystems (EPICS)• The cooling

subsystems (EPICS)


What is EPICS? (Experimental Physics and Industrial Control System)

• Process control and data acquisition software toolkit• Application Developers can create a control system with it• Running under the real-time operating system VxWorks• Physically a flat architecture of front-end controllers and

operator workstations that communicate via TCP/IP and UDP• Software architecture is client/server based

Basic components:

•Operator Interface

•Channel Access

•Local area network

•I/O Controller


What is Channel Access (CA)

• Network protocol

• A callable interface (library of subroutines)

• Integrates software modules into the control system

• CA server >>> connection, get, put,and monitor services

• CA client >>> access to process DB-s in other IOC-s

• Communication between databases is accomplished

using the CA client library

• Standardized communication path to a field(s) within a

record (process variable) in any IOC database(s).

• All access to the database is via the database access

routines.


EPICS data to TINE in the past

• EPICS tools connected via the CA C/S libraries

• CA libraries linked to any third party program (TINE based application)

• Visual Basic Application using the ACOP (Accelerator Component Object Programming) library; last one has built-in the CA functions

• Unrealized Client-Side Tool Utility

– EPICS client-side tools are generic

– EPICS client-side tools used only with EPICS


“Old way”

ca-client

ACOP Application

ca-server

VME crateOS: vxWorksAppl: EPICS

UNIX orWindowsNT TINE

client CA function


Disadvantages of using “old way“

• Unfriendly update of distributed CA libraries and DLL-s

• Special VBA using CA functions

• No naming service available

• Low priority clients consume resources in critical machines


First Ideas

• Integrate the EPICS IOC-s into the HERA mainstream

• Build new server, runs directly on the EPICS IOC

• The server module resides in each one of the system

controllers along with that controller’s portion of the

distributed EPICS context

• TINE view of the hardware control to the rest of the CS

• Control via channel access remain as before

• Use well implemented local calls like dbpf, dbgf

• Each server module has its own “mapped” record list


Requirements

• Excellent performance without disturbing the real-time

control loops in and between subsystems

• A maximum level of functional flexibility

• Less additional programming

• Fit seamlessly into TINE systematics (Alarm, Archive,

Naming, Permit, …)

• Bypass local Channel Access Protocol


ConfigurationPCWindows NTVBA ApplicTINE

I/O ControllersvxWorksEPICSCA ServerField I/O

Sun SolarisMEDMCA

Field I/O

I/O ControllersvxWorksEPICSCA ServerTINE Server

PCWindows NTX-SessionCA


IOC

DATABASE

database access library

device drivers

Channel Accessclient C program

SNL sequence

record support

device support

database library

Channel Accessserver

TINE server

Channel AccessClient

user program

WORKSTATION

Channel AccessRepeater

TINE Client

user program

WINDOWS NT


Naming convention

• Database is the heart of an IOC (records)

• Unique record names across all IOC-s attached to the same TCP/IP subnet.

• Form: <record name>[.<field name>]

• Each record type has a fixed set of fields:

common / specific

• Access to the database is via the channel or database access routines (exception recSup, devSup)


Naming convention 2

• Each server module has a mapped record list

– the real PV names are mapped to TINE registered names

– EPICS record names 28 chars, field 4 chars field

– TINE device names 16 chars, properties 32 chars

• TINE names registered as devices

• Register devices with their truncated TINE names:

– List of PV’s and the correspondent TINE names

– Dynamically

Need to truncate !!!!


Mode of operation

• TINE client requires data

– Search for TINE device in the local list or reconstruct PV

name

– Search and get data (database access routines)

– Local conversion corresponding TINE client requested

data type format

– Respond to the request and send the data to the client

• No need to know the location or other attributes of the data.


Mode of operation 2

• The server is able to send any value to any client TINE

application

• The multiple instances of the server in a control system

respond to a request for data by searching for the

registered device

• Name servicing possibility

• Local access data functionality

• Directly access to the database access layer


Extended support for different data types

• Data type conversions are performed in the server

• Using EPICS CA standard data types defined in

db_access.h like DBR_STRING, _DOUBLE, _FLOAT,

_LONG, _CHAR

• Converting of different data types was possible without

major changes in EPICS or TINE code

• Care should be taken to ensure there is sufficient sized

reserved space for all supported data format


Composites

• New requirements were identified

• Extended set of interfaces, additionally set of PV’s

• Set of arranged TINE devices

• Identified through collective names

• Configuration files, contains the composite names and

the members of each composite device

• User can set up his own sets

• Easily scaleable


Conclusions, Summary and Future

• First tests >>> monitor 250 channels by one IOC (stably run)

• Weather station data transparent to TINE (archive)

• Possibility to communicate to the EPICS IOC’s through:CA protocol / “TINE-Way”

• Integrate existing EPICS systems without rebooting

• Port the EPICS database into TINE control system

• Keep alive TINE user friendly environment (no special VBA)

• Restarting of the TINE-Server without booting the system




Why use?

• Intercommunication between two different control systems

• Flexible and friendly updateable

– TINE server library in the unbundled tree of the EPICS system (similar base tree)

– Automatically update together with new EPICS releases

• No more distributing new channel access libraries

• No need special TINE graphical interfaces

• No use of CA subnet-dependent connections

• Following the trend of using Windows in control systems

• TINE has the naming service built-in.

Documents

9-12 Oct 2000PCaPAC 2000, DESY Hamburg Epics to TINE translator Matthias Clausen, DESY Hamburg Phil Duval, DESY Hamburg Zoltan Kakucs, DESY Hamburg