Experimental Physics and
Industrial Control System

Richard Pastrick <[email protected]> · Tue, 21 Oct 2008 16:29:43 -0700

Thanks for the help. After a quick test, the issue was that I was not properly using ca_attach_context.

This solved my problems.

-Richard

> -----Original Message-----
> From: Jeff Hill [mailto:[email protected]]
> Sent: Tuesday, October 21, 2008 4:21 PM
> To: Richard Pastrick; [email protected]
> Subject: RE: EPICS Threading Issues
> 
> 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:tech-talk-
> [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