Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Tue, 21 Oct 2008 17:20:40 -0600

Hello Richard,

First, it is essential to be aware of the following synchronization
fundamentals when using the CA client library. Additional details are in the
manual (http://www.aps.anl.gov/epics/base/R3-14/8-docs/CAref.html).

1) One must either wait for successful connection callback, or for
ca_pend_io to return success before using one or more channels that has been
recently created. Persistent (long life span) applications really have no
choice other than to wait for successful connection callback before using a
channel considering that the channel connections are transient (ca channels
can change in-between connected and disconnected states at any time).

2) After issuing one or more ca get request, one must call ca_pend_io to
block for synchronization with the values being returned to your data
buffers. For robustly implemented applications a better choice is to issue a
ca get callback request. 

3) The ca client library operates, depending on the developer's
configuration, in one of two modes - preemptive and non-preemptive callback
modes. Multithreaded applications typically use preemptive callback mode,
but developers of multithreaded applications needs to know how to use a
mutex to synchronize multiple asynchronous accesses to their data structures
(originating from multiple threads). 

4) Additional auxiliary threads that the developer spawns must take action
to join with the CA context created in the primary thread (see
ca_attach_context() in the manual).

Second, due to the way the database is implemented, when the CA server
executes a ca get request it does not cause the motor record to process. So
what you will receive in the get response will only be a snapshot of the
record's field at the instant in time when the ca get request is executed by
the server. It's probably safe to say that the motor record is a bit more
complex in the continuous asynchronous maintenance of its fields, occurring
as the motor moves and otherwise changes state, compared to the typical
EPICS record. It might be simpler and more robust to install a CA
subscription (a ca monitor) if there is a need to continuously update the
GUI that you are developing based on the state of a motor record's field.

HTH,

Jeff

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Richard Pastrick
> Sent: Tuesday, October 21, 2008 4:26 PM
> To: [email protected]
> Subject: EPICS Threading Issues
> 
> I have some questions regarding EPICS and threading. Let me start by
laying
> out the development environment.
> 
> I am developing an interface to an EPICS motor record using the CA API. I
> am using base 3.14.8.2. I am compiling under windows using Visual Studio
> 2008. I have successfully compiled all necessary components this way. I
> know that there are no issues with the compiling because all of the
> utilities and executables generated by the base are functional.
> 
> My interface is being generated in a GUI application for windows. When I
> start the program, the main process thread instantiates a class which
> contains all of my EPICS related code. This class will connect to the
> various PVs I require and store their chid objects for future access.
> 
> I then go on to do other necessary steps for my program and eventually I
> complete startup. Once startup has completed, there is a spawned thread
> which will go to my EPICS class at a specified interval and retrieve new
> data from the EPICS motors. These ca_get commands will fail to return any
> accurate data. The return code they return indicates a success but the
> data, as confirmed by both the caget utility and an MEDM window, is
> incorrect. For example, if I have moved the motor to a position of 2.5,
> both the MEDM window and caget will confirm that the RBV for that motor is
> 2.5. My program will say that it is at 0.
> 
> If I issue a ca_get right after I create the channels in the same thread
> that created the channels, I will receive the proper value of 2.5. I can
> also use ca_put with no problem. So if I issue a command to move to 4.2
> from my program, the motor actually will move to this new location but the
> ca_get to retrieve the RBV will return 0 for the read value.
> 
> So my question boils down to this, should EPICS be able use a channel that
> was created in a different thread?
> 
> Thank you,
> 
> 
> Richard Pastrick
> Associate Software Engineer
> Xradia Inc
> 5052 Commercial Cir
> Concord CA 94520
> 925-288-1228 Ext 1151
> 925-348-0384 (cell)

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System