16 - nov. 2000epics workshop oak ridge1 epics to tine translator matthias clausen, desy hamburg phil...

16 - Nov. 2000 EPICS Workshop Oak Ridge 1

Epics to TINE translator

Matthias Clausen, DESY HamburgPhil Duval, DESY Hamburg

Zoltan Kakucs, DESY Hamburg


Contents

• Accelerator Controls at DESY

• 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 are controlled by TINE or at least talking TINE

– important exceptions include:

• Proton Vacuum• cryogenics control

( D/3 and EPICS)

• the super conducting electron RF cavities

• the utility subsystems (EPICS)


EPICS data to TINE in the past

• Most of the TINE applications are written in Visual basic

• One generic component of the TINE environment is ACOP, an Active-X controlACOP (Accelerator Component Object Programming) library;

• ACOP has the CA –DLL bulit in

• Not all programmers use ACOP to develop their applications


“Old way”

ca-client

ACOP Application

ca-server

VME crateOS: vxWorksAppl: EPICS

UNIX orWindowsNT TINE

client CA function


Disadvantages of using “old way“

• Update of distributed CA libraries and DLL-s

• No naming service available

• No easy way to integrate EPICS IOC‘s into TINE applications

– Alarms, trends ...

• Low priority clients consume (CA) resources in critical machines


First Ideas

• Integrate the EPICS IOC-s into the HERA mainstream

• Build new server which runs directly on the EPICS IOC

• The server module resides in each of the IOC‘s along with the

local EPICS namespace

• Autoconfiguration of the TINE server during system startup

(after IOC_init)

• Control via channel access remains as before

• Use well implemented local calls like dbpf, dbgf

• Additional “mapped” record list EPICS<->TINE can be

configured


Requirements

• Excellent performance without disturbing the

real-time control loops in the IOC

• A maximum level of flexibility

• Less additional programming

• Fit seamlessly into TINE applications (Alarm,

Archive, Naming, Permit, …)


ConfigurationPCWindows NTVBA ApplicTINE

I/O ControllervxWorksEPICSCA ServerField I/O

Sun SolarisMEDMCA

Field I/O

I/O ControllervxWorksEPICSCA 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 (EPICS-CA)

• 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


Naming convention (Gateway)

• 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

• Record names are registered as TINE devices

• Register devices with their truncated TINE names:

– List of PV’s can be associated with TINE names

– Dynamically

Need to truncate !!!!


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


More ...

• New requirements were identified

• Additional set of PV’s ( all temperatures of the dipoles...)

• 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


Summary and Future

• First tests >>> monitor 250 channels in one IOC

• Weather station data transparent to several TINE clients

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

• Integrate existing EPICS systems without rebooting

– TINE server can be loaded and started at any time– Restarting of the TINE-Server without booting the system

• Integrate the EPICS IOC‘s into TINE control system


Conclusions

• The ‚dual face‘ IOC can be reliably implemented

• The integration of EPICS IOC‘s into other control systems can be implemented on the IOC itself

• Auto configuration – or configuration files – helps to unbundle the IOC database from ‚the other‘ server

• Existing data conversion routines can be used

• Using EPICS specific memory allocation routines in the code of the ‚the other‘ server helps to achieve stable operation

• Channel access ‚limitations‘ like name server and broadcast barriers can be avoided this way

16 - nov. 2000epics workshop oak ridge1 epics to tine translator matthias clausen, desy hamburg phil...

Documents

epics iocs

epics unix

epics workshop oak ridge7

epics iocs

utility subsystems epics

tine environment

tine applications alarms

desy hamburg slide