Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Thu, 7 Sep 2017 10:20:50 -0500

Hi,

On 09/07/2017 04:56 AM, Giacomo S. wrote:
>>> 1. every time I receive an event, evargs contain not only the value /
>>> timestamp but also configuration parameters, right (HI, LO thresholds
>>> and so on...)
>> Not sure what the question is there. Your event_handler_cb() routine is
>> given a struct event_handler_args whose void *dbr pointer points to the
>> dbr_* type that you subscribed to. There are many different dbr_* data
>> types defined in db_access.h containing different subsets of the
>> available data, but none of them provides everything, so you may need to
>> subscribe to the same channel multiple times with different types and
>> different event masks. Channel metadata (enum strings, alarm levels etc)
>> usually change much less frequently than the data itself, and the event
>> mask DBE_PROPERTY is designed to tell you when metadata has changed.
> 
> You mean calling MULTIPLE TIMES
> 
> ca_create_subscription()
> 
> with different event masks, different user data and parameters or is it
> possible to subscribe ONCE
> setting the event mask ORing the needed DBE_xxx together?

Yes, I think Ralph and Michael explained yesterday that general-purpose
clients often create one subscription for DBE_PROPERTY updates with the
full set of metadata for the channel, plus another subscription to the
same channel for DBE_VALUE and DBE_ALARM updates for the value, alarm
and timestamp data.

As you said you OR together the DBE_* values to combine them, but in
practice combining DBE_PROPERTY with the other DBE_ values is less
common or useful. This is also related to how much data has to be sent
with each update; since metadata changes are much less common and the
relevant data types are larger than value and/or alarm changes, it is
better *not* to request all the metadata every time the data values
change (the larger DBR_* types are designed with this in mind too, the
timestamp is only available with the smaller types).

> In this last case, the requested type should be "bigger" (DBR_CTRL*) so
> as to contain data and metadata...
> Moreover, inside the event callback I should be able to detect whether
> the event is a metadata change or a
> normal value update...
> is this correct? How to do so?

Yes, unfortunately the CA library does not tell your event callback
routine what kind of event this update is for. By using different data
types for the channel subscriptions the event type value tells you which
subscription this event is for.

HTH,

- Andrew

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System