Experimental Physics and
Industrial Control System

[email protected] (William Lupton) · Tue, 9 Aug 94 11:49:31 HST

Dear all,

This is triggered by the mail from Kay Rehlich about a common API for
different underlying communication protocols. I don't know the
background to these discussions or how far they have gone but I
thought that people might be interested in our approach to this problem,
which is to define an API which is is completely independent of the
underlying communication protocol and then to implement "drivers" which
are in fact run-time-activated shareable libraries.

The API is called KTL (Keck Task Library) and a compressed five page
PostScript document can be obtained from (or mail me and I will send
it):

ftp://ftp.keck.hawaii.edu/pub/doc/ktl_paper.ps.Z

(the same directory also contains some related documents including a
detailed programming manual including, dare I mention it, automatically
extracted routine descriptions!)

The driver is identified by two character strings, a "service" (which
identifies which sub-system to connect to) and a "style" (which
defines the way in which high-level code interacts with the underlying
system). We have defined two styles so far:

keyword - where the applications work in terms of named keywords and
          their values

message - where the applications work in terms of message types and
          message structures

The driver implements seven routines: open, close, ioctl, read, write,
event and respond, which are responsible for all the interactions with
the underlying communication system.

The high-level (service and style-independent) KTL library handles
callbacks, maintains context, handles callbacks, and so on.

We currently have message style implementations that run on top of a
home-grown message system and on raw sockets. We also have keyword style
implementations that use the same home-grown system, and that are
layered directly on top of RPCs.

The way that one would handle CA would be to define a CA service and
style which works in terms of process variable names and values. One
would define various CA-specific KTL ioctls (or use CA-specific flags on
ktl_read() / ktl_write() calls) to handle things like group puts and
gets. We will be doing this at some stage since we will want KTL clients
to be able to talk to EPICS systems.

William Lupton

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System