Experimental Physics and
Industrial Control System

"Liyu, Andrei" <[email protected]> · Wed, 05 Nov 2003 11:35:22 -0500

Jeff,

	Thanks you very much for detailed answer. There are some moments
that I would like to explain, suggest or ask ...

1. 
**********
* A.L.>>> Also what I will have if I init CA library some times?
* J.H.>>> I am confused by this question but I am guessing that you are
just
* emphasizing that in your situation you would like to call
* ca_context_create() from a different thread than the one that called
* ca_context_create() and, to the best of my knowledge, that should work

* fine.
***********

Explanation. I wrote first version library between LabView and Epics CA
(Windows and Linux). Simple examples work. But there are two moments. At
first, all LabView's programs ".vi" work undo LabView's engine in one
process. So if programmer writes few vi's, start them he will use
ca_context_create() and ca_context_create() some times! At second,
LabView uses multithreading too. But the usage is not clear. Programmer
can use ca_context_create(), ca_open_channel(), ca_get() in different
threads!!!
Now I wrote a little complicated program and met these problems. I am
sitting and thinking what I can do ...
Question. If I use ca_attach_context() two or more times in the same
thread I suppose CA will be work fine. Am I right?

2. 
***********
* > 3. Some time ago I understood that I open channel to PV's field. 
*
* CA channels form a virtual circuit between a process variable (PV) and
a
* client side application program. It is possible to connect a wide
variety  * of data sources into EPICS using the CA server library. When
a CA channel
* communicates with an EPICS Input Output Controller (IOC) then a field
is a
* specialization of a PV, and an EPICS record is a plug compatible
function
* block that contains fields, and the meta data below frequently are
mapped
* onto specific fields within the EPICS records by the EPICS record
support
* (see the EPICS Application Developer Guide).
* 
* > PV's field has type, count, reading/writing access, host name 
* > (why not IOC name?).
*
* In the past there was only one IOC per host and so the host name and
the 
* IOC name were always the same. With R3.14 it's possible to have
multiple  * IOCs on the same host so this is more complicated. The short
answer is 
* that the CA client currently knows only the IP address and the port
number 
* of the server (IOC). The IP address can be converted to a host name. I

* suppose that, when configuring an IOC, the EPICS application developer

* might use a new facility which specifies the IOC name, and this could
be 
* passed up to the CA client library interface, but that has not been 
* considered as of yet. We are interested in your thoughts on this
matter 
* (why it is needed - how it would be used etc).
*
* > But what about timestamp? Is it only to VAL field?
* 
* You can ask for the time stamp, alarm status, limits, units, and other

* meta data associated with a field by requesting different DBR_XXX
types. 
* The range of data types supported is documented in the R3.14.4 CA 
* reference manual and also in db_access.h. Typically, in an EPICS IOC 
* context the time stamp is obtained from the timestamp field in the
record 
* which is updated when the record is processed. The time stamp is
usually 
* the time that the record was processed or the time that the value
field 
* was acquired by the hardware.
*
**************

My interpretation about record, PV and PV's field (maybe wrong).
	Record and PV are the same. But there is one difference.
Programmer says "record" when he develops Epics program and IOC loads
records. When IOC has processed record programmer begins to say "PV".
	PV (or record) has a lot of fields. Programmer can open channel
to any field of PV (maybe not if type is NOACCESS). (If field is absent
that it's VAL field and your manual has this information.) (There is
TIME field. Most likely TIME is timestamp. Record reference manual
hasn't link TIME and timestamp. I was confused and I did mistake about
timestamp.)
	PV field has set information (subfield) too. There are type,
counts, access (programmer can access!) and other subfields.
	This is structure.
	When programmer open channel he can 
- read about subfields (ca_read_access(), ca_write_access(),
ca_element_count(), ca_field_type()
- read/write value from/to PV's field (DBR_*type*)
- read from set of PV fields (DBR_XXX_*type*) (synchronization in IOC
and decrease network traffic)
- read NAME field by ca_name()
- read IP address and port of server ca_host_name() (I asked why host?
Background of my question was very simple. If you open
http://www.aps.anl.gov/epics/ you will see IOC and HOST softwares. IOC
is server software. HOST is basically client software. But
ca_HOST_name() gives server=IOC not client=HOST address. )
- read connection status ca_state() and channel_state().

Maybe one remark about your manual. From my opinion if it's manual that 
- idea should be on first place
- information should be enough in manual (no EPICS Application Developer
Guide. Moreover this Guide is really awful. If newcoming come from
Windows he will lose a lot of time to install Epics.)
- when I tried to understand CA I write my interpretation of this deal.
If you like I can send it to you. I hope you say it's oversimplification
again :)
But ... no doubt I appreciate you for your manual.

3. 
*************
* > 4. And last question. What do client and server do when 
* > connection lost?
* > 
* > I believe that they are waiting up to EPICS_CA_CONN_TWO time 
* > and server is sending beacons. 
* 
* This is an oversimplification, but almost correct. The details are in
the
* R3.14.4 CA reference manual.
* 
* > But what is later? Does server clean resource of
* > disconnection channel? 
* 
* Mostly no. 
* 
* Once you create a channel the client library will try to keep it
connected
* for you until you delete the channel. The client library will *not*
delete
* the channel for you. That is your responsibility and the timing of
this is
* your choice with ca_clear_channel().
* 
* The client library will also remember any monitor subscriptions
entered
* against the channel and make a subscription with the server whenever
the
* channel connects. The subscriptions are *not* destroyed when the
channel
* disconnects. The subscriptions *are* destroyed when you destroy the 
* channel.
*
* Any outstanding get callback, put callback, or sync group requests
*are*
* cleaned up (destroyed) when the channel disconnects.
*
* > Why client can connect again if server was rebooted?
*
* This is a necessary feature for client side applications in a
distributed
* process control system. Long lifespan programs like the sequencer, the
* database links, the operator interface, the archiver, and many others
need
* this capability. The CA client library knows when the server has
rebooted
* and therefore when it is possible to reattach to it. 
* 
* It is possible to receive a callback from the CA client library when
the
* circuit reconnects.
*****************

Suggestions.
Server doesn't clean resource if client died. But we have this
possibility. For examples, operation system is hanged, network break. I
believe you give more examples. And client isn't important as server!!!
Maybe cleaning resource in server after 10-20-30 minutes (as DCOM in
Windows) will be good decision?

Usually programmer tries to clear tails (close subscription, close
channel). But why doesn't CA library delete channels if programmer calls
ca_context_destroy()? I believe library has information about opening
channels.

Thank you very much,
Andrei.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System