|
| |
[Next] [Previous] [Top] [Contents] [Index]
Channel Access Client Tutorial
1. Overview
What is Channel Access?
Channel Access is one of the core components of an EPICS system. It is the software component that that allows a Channel Access client application to access control-system data which may be located on different hosts throughout a network. Since it is based on a client-server model, the client makes requests and sends them to the server. For instance, a client can request to change the value of a certain variable. Often, there will be several servers running on different IOCs, and the client application will be running on a workstation. The client sends the request to the appropriate server, and the server tries to fulfill the request. The client may, for example, request the value of a variable in an IOC. When a server receives such a request, it will read the variable's value and send it back to the client.
A client application is any application that uses one or more function calls from the client library, which consists of functions and macros written in C. Using these calls, a client can request a "virtual circuit" between itself and a process variable or PV, which is any piece of data related to the system, such as a field in an EPICS record. Such a "virtual circuit" is what is referred to as a channel. The server that is located on the same host as the PV returns a channel identifier or chid to the client program. Using the chid, the client program can make further requests which the server will try to fulfill, such as returning a PV's value to the client program, changing the PV, and monitoring a PV for changes so that the client program can "keep track" of it.
Before EPICS 3.13, the only data a client application could access were fields in EPICS records, because the Channel Access server was used only in conjunction with the EPICS database software. For example, if a client application requested a PV's value, when the server got the request, it called one of the EPICS database access routines such as dbGetField(), which would retrieve the value, return it to the server which would send the value back to the client. As of Release 3.13, this is no longer true: a new application programming interface (API) has been developed for the server called the Portable Channel Access Server. Now, server applications can be created which deal with other data besides the EPICS database. For instance, a Portable Server could be created that would deal with another type of database. Therefore, it's possible that a client application can access PVs that are not EPICS-related.
The examples in this tutorial have the EPICS database in mind as most developers will be creating applications for use with the EPICS database. Nonetheless, the reader should be aware that the data he will deal with may not be related to the EPICS database.
What Does Channel Access Provide?
Channel Access provides the following benefits to client applications.
 | Network transparency
|
In order to establish a channel, the client program only has to provide a PV's name. As long as the channel is located in an IOC on the same local or wide area network (LAN or WAN), Channel Access will be able to establish a connection between the client program and the PV. Thus, the application programmer is relieved of the burden of having to know the IOC's address on the network or any such information: the application programmer doesn't need to know about network communication protocols.
| Isolation from system software changes
|
The Channel Access libraries are designed so that internal changes to the control-system software will have a minimal impact on client applications. Most changes to the EPICS database software, for example, will not affect client applications.
| Architecture independence
|
Channel Access performs silent data conversions when the client and server are running on machines with different architectures. Thus, the application programmer need not be concerned about these problems.
| Efficiency
|
The routines of the client library were designed to use resources efficiently. One key feature of Channel Access that makes it efficient is that client programs can combine requests. Combined operations are more efficient when passing through system software layers and when sharing common resources such as a bus. Combined operations also use the network more efficiently.
The Purpose of this Document
This document introduces the client library and illustrates it and its features through examples and explanation. As with most tutorials, the examples are somewhat trivial, but they should demonstrate how to use the Channel Access calls. The examples should at least give the programmer a good idea of how to get started with his or her own program.
There are other aspects of Channel Access which this document does not address and which some readers may be interested in, such as how to reconfigure Channel Access to set up a system that uses multiple IP subnets, or to change the time stamps to a time zone other than US Mountain time, etc. The Channel Access Reference Manual addresses these aspects.
- What is Channel Access?
-
- What Does Channel Access Provide?
-
- The Purpose of this Document
-
Channel Access Client Tutorial - 4 NOV 1997
[Next] [Previous] [Top] [Contents] [Index]
|