contents
DESCRIPTION
Epics to TINE translator Matthias Clausen, DESY Hamburg Phil 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. Past - PowerPoint PPT PresentationTRANSCRIPT
9-12 Oct 2000 PCaPAC 2000, DESY Hamburg
Epics to TINE translator
Matthias Clausen, DESY HamburgPhil Duval, DESY Hamburg
Zoltan Kakucs, DESY Hamburg
9-12 Oct 2000 PCaPAC 2000, 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
9-12 Oct 2000 PCaPAC 2000, DESY Hamburg
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)
9-12 Oct 2000 PCaPAC 2000, DESY Hamburg
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
9-12 Oct 2000 PCaPAC 2000, DESY Hamburg
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.
9-12 Oct 2000 PCaPAC 2000, DESY Hamburg
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
9-12 Oct 2000 PCaPAC 2000, DESY Hamburg
“Old way”
ca-client
ACOP Application
ca-server
VME crateOS: vxWorksAppl: EPICS
UNIX orWindowsNT TINE
client CA function
9-12 Oct 2000 PCaPAC 2000, DESY Hamburg
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
9-12 Oct 2000 PCaPAC 2000, DESY Hamburg
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
9-12 Oct 2000 PCaPAC 2000, DESY Hamburg
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
9-12 Oct 2000 PCaPAC 2000, DESY Hamburg
ConfigurationPCWindows NTVBA ApplicTINE
I/O ControllersvxWorksEPICSCA ServerField I/O
Sun SolarisMEDMCA
Field I/O
I/O ControllersvxWorksEPICSCA ServerTINE Server
PCWindows NTX-SessionCA
9-12 Oct 2000 PCaPAC 2000, DESY Hamburg
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
9-12 Oct 2000 PCaPAC 2000, DESY Hamburg
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)
9-12 Oct 2000 PCaPAC 2000, DESY Hamburg
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 !!!!
9-12 Oct 2000 PCaPAC 2000, DESY Hamburg
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.
9-12 Oct 2000 PCaPAC 2000, DESY Hamburg
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
9-12 Oct 2000 PCaPAC 2000, DESY Hamburg
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
9-12 Oct 2000 PCaPAC 2000, DESY Hamburg
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
9-12 Oct 2000 PCaPAC 2000, DESY Hamburg
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
9-12 Oct 2000 PCaPAC 2000, DESY Hamburg
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.