contents
DESCRIPTION
Epics to TINE translator Matthias Clausen, DESY Hamburg Phil 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. Past - PowerPoint PPT PresentationTRANSCRIPT
16 - Nov. 2000 EPICS Workshop Oak Ridge 1
Epics to TINE translator
Matthias Clausen, DESY HamburgPhil Duval, DESY Hamburg
Zoltan Kakucs, DESY Hamburg
16 - Nov. 2000 EPICS Workshop Oak Ridge 2
Contents
• Accelerator Controls at DESY
• History of creating EPICS to TINE translator
• Naming convention
• Mode of operation
• Conclusions, summary and future
16 - Nov. 2000 EPICS Workshop Oak Ridge 3
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)
16 - Nov. 2000 EPICS Workshop Oak Ridge 4
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
16 - Nov. 2000 EPICS Workshop Oak Ridge 5
“Old way”
ca-client
ACOP Application
ca-server
VME crateOS: vxWorksAppl: EPICS
UNIX orWindowsNT TINE
client CA function
16 - Nov. 2000 EPICS Workshop Oak Ridge 6
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
16 - Nov. 2000 EPICS Workshop Oak Ridge 7
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
16 - Nov. 2000 EPICS Workshop Oak Ridge 8
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, …)
16 - Nov. 2000 EPICS Workshop Oak Ridge 9
ConfigurationPCWindows NTVBA ApplicTINE
I/O ControllervxWorksEPICSCA ServerField I/O
Sun SolarisMEDMCA
Field I/O
I/O ControllervxWorksEPICSCA ServerTINE Server
PCWindows NTX-SessionCA
16 - Nov. 2000 EPICS Workshop Oak Ridge 10
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
16 - Nov. 2000 EPICS Workshop Oak Ridge 11
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
16 - Nov. 2000 EPICS Workshop Oak Ridge 12
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 !!!!
16 - Nov. 2000 EPICS Workshop Oak Ridge 13
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
16 - Nov. 2000 EPICS Workshop Oak Ridge 14
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
16 - Nov. 2000 EPICS Workshop Oak Ridge 15
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
16 - Nov. 2000 EPICS Workshop Oak Ridge 16
16 - Nov. 2000 EPICS Workshop Oak Ridge 17
16 - Nov. 2000 EPICS Workshop Oak Ridge 18
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