Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Fri, 19 Aug 2011 09:44:05 -0500

That behavior of ca_put_callback to the motor record is the expected behavior.  The sscan record and many other clients depend on this behavior.  It is the most reliable method of doing a scan.  You don't poll any PV to see when the motor is done, which would require additional knowledge and be subject to race conditions unless carefully implemented.  The scaler record, mca record and the busy record all have this same behavior.  You just do a ca_put_callback, and the callback tells you when the device is "done".

Mark

-----Original Message-----
From: [email protected] on behalf of Jay Steele
Sent: Fri 8/19/2011 9:38 AM
To: [email protected]
Subject: RE: question about ca_get, ca_pend_io timeout in EPICS client withWindows XP multi-threading

Hi all,
     I tested the ca_get_callback function with Visual C++ 2008 and it worked quite nicely in my multi-threaded environment. I defined a static member function to be the callback function, and created a set of variables for multiple threads to store the data retrieved from EPICS and the flags indicating data received.

     I also tested the ca_put_callback function to set the VAL field for asyn motors, and only received the callback after the motor finished moving to its command position. Is this expected behavior? I was hoping for the callback to be received once the VAL field was set. Is there a way to configure the channel access software to make this happen?

Cheers,
Jay Steele
________________________________
From: Jay Steele
Sent: Tuesday, August 16, 2011 2:10 PM
To: [email protected]
Subject: RE: question about ca_get, ca_pend_io timeout in EPICS client with Windows XP multi-threading

Hi Jeff,
     Thanks a lot for the quick response. I see that there are some nice tutorials on EPICS channel access on the Los Alamos web site.

Cheers,
Jay Steele
Xradia Corporation

From: Jeff Hill [mailto:[email protected]]
Sent: Monday, August 15, 2011 5:23 PM
To: Jay Steele; [email protected]
Subject: RE: question about ca_get, ca_pend_io timeout in EPICS client with Windows XP multi-threading

Hi Jay,

>  However, when I launch another thread at priority THREAD_PRIORITY_ABOVE_NORMAL,

>  and this thread keeps the CPU busy, then for some reason the

>  ca_pend_io function returns with timeout

The ca client library spawns background threads at fixed offsets from the priority of the thread that created the ca context. Some of them run at lower priority and some at higher priority. If another higher priority uses all of the CPU then this definitely will cause the behavior that you are observing.

Generally it's a suboptimal design to let one thread spin and use all of the CPU. That design prevents your code from coexisting with other programs and libraries. A better design is to have your consumer thread wait on a work queue. When adding to  the work queue post the work-is-pending semaphore, and the consumer thread of course waits on this same semaphore. You will of course also need a mutex lock to protect the work queue.

Would the ca_get_callback function work better for this situation?

The ca_pend_io mechanism works well for simple single threaded programs with short lifetimes. For multi-threaded applications, or for programs with longer life spans (that need to deal with connect/disconnect cycles) ca_get_callback works better.

Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]<mailto:[email protected]>
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925

From: [email protected] [mailto:[email protected]] On Behalf Of Jay Steele
Sent: Monday, August 15, 2011 4:23 PM
To: [email protected]
Subject: question about ca_get, ca_pend_io timeout in EPICS client with Windows XP multi-threading

Hi EPICS folks,
        I have some questions regarding an EPICS client and multi-threading on WINDOWS. 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 XP 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 XP. 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.

       For initialization, I call these functions from the main task.

int nRet = ca_context_create(ca_enable_preemptive_callback);
m_pEPICSContext = ca_current_context();

       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. This thread is priority THREAD_PRIORITY_ABOVE_NORMAL, is attached
to the main task's context using ca_attach_context(m_pEPICSContext),
and periodically calls ca_get, then ca_pend_io to retrieve the motor data. I use
a 5 second timeout value for ca_pend_io. This normally works to successfully retrieve the motor data.

               However, when I launch another thread at priority THREAD_PRIORITY_ABOVE_NORMAL, and this thread keeps the CPU busy,
then for some reason the ca_pend_io function returns with timeout
(User specified timeout on IO operation expired). The WINDOWS O/S appears to swap CPU time between the two ABOVE_NORMAL priority threads,
But the ca_pend_io function still time outs. Is this expected behavior? Does the low level functionality in ca_pend_io run at a
low priority, so that it will timeout? Would the ca_get_callback function work better for this situation?

Thanks,
Jay Steele
Xradia Corporation

________________________________
The information in this email, including any attachments, is confidential and intended only for the recipient(s) listed. Any use of this email for any other purpose is prohibited. If you have received this email in error, please notify me immediately by reply email, delete this email, and do not disclose its contents to anyone.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System