Experimental Physics and
Industrial Control System

Hello Pierre,

Ø  I don’t know which type of implementation (Portable CA Server or IOC) is the most

Ø  efficient. In this case, I started implementing an IOC. is it a good choice ?

It’s hard to make specific recommendations without more knowledge of your application. Nevertheless, a strong benefit of using an IOC to control motors will be that you can use all of the EPICS device drivers already written for motors now  and in the future if you upgrade. The portable server works well when you have a preexisting data store which needs to be interfaced to EPICS, or when you do not want to configure a subsystem using EPICS records.

Ø  And to be notified of change events, I’ve created a thread to launch :

Ø  ca_pend_event (0.0);

In a preemptive callback application you will receive callbacks from the ca client library’s auxiliary threads at any time, and accordingly user callback execution isn’t restricted to occur only when executing in the ca client library (as is the case with non-preemptive callback mode). So therefore, a call to ca_pend_event in the thread that you have launched isn’t strictly necessary.

Ø  The problem occurs when I want to change a PV value. All seems ok but the pv is 

Ø  only really modified 30 seconds to 1 min after the call to ca_array_put (I have

Ø  tested this in localhost) . To change a value, I proceed in the following manner

Ø  for a double :

Ø  ca_array_put(DBR_DOUBLE, 1, channel, &val);

Ø  status=ca_pend_io(put_timeout);

A better approach is as follows. First issue the put request, and second force the output queue to be flushed to the network.

ca_array_put(DBR_DOUBLE, 1, channel, &val);

ca_flush_io();

The ca_pend_io is a synchronize-by-blocking function which waits for ca get and ca channel connect requests to complete (but such requests will only participate if they are not synchronized by callbacks). Thus, ca_pend_io isn’t typically used with a ca put request. Also, ca_pend_io is used typically only in single threaded ca client applications, and not in a multithreaded (preemptive callback) ca client applications (which are typically synchronized by callbacks).

Ø  Is this a normal behaviour? If not, how can this issue be solved?

No, as soon as the request is flushed out of the output queue it will be delivered immediately to the IOC. While the ca_pend_io function call isn’t appropriate in a put request context, it does nevertheless issue internally a flush request so I _am_ surprised that you see this delay.

Are you certain that the delay is in the ca subsystem? The motor record is actually more complex in its implementation than other EPICS records.

Perhaps you can use the dbpr command from the IOC’s shell to verify that the field which is the target of the put request is in fact being modified after a delay?