Experimental Physics and
Industrial Control System

"Kasemir, Kay" <[email protected]> · Thu, 19 Jan 2012 17:09:52 -0500

Fellow Techtalkians:

This thread was started by Charles from SNS asking about monitoring changes
to MBBI strings, and Andrew explained the new DBE_PROPERTY monitor event
added in 3.14.11.

After several more emails, here's what we found:

EPICS R3.14.11 defines a DBE_PROPERTY monitor event
that channel access clients can use to monitor changes
in "properties".

With R3.14.11 IOCs, the only property that will send
this event are the ZRST, ONST, *ST enumeration strings
of MBBI and MBBO records.
In principle, changes to the EGU, PREC, HOPR, ... fields
of analog records should also send DBE_PROPERTY events,
but they currently don't.

As of today, there are also very few channel access client tools
that actually use the DBE_PROPERTY event. Many do this:

- Connect to channel
- Get meta data via DBR_CTRL_... data once(!)
- Subscribe to DBR_TIME_... with DBE_VALUE or DBE_LOG or DBE_ALARM
  to get value updates

That's why operator screens won't update the range of sliders,
meters etc. when those are changed on the IOC.

Andrew suggested doing this:

- Connect to channel
- Subscribe to DBR_CTRL_... with DBE_PROPERTY for meta data updates
- Subscribe to DBR_TIME_... with DBE_VALUE or DBE_LOG or DBE_ALARM
  to get value updates

Yes, that's 2 subscriptions per channel, but the meta data
subscription will typically only send one initial value,
i.e. same network traffic as in the old case.

New IOCs (3.14.11+) will also send updates when the meta data
changes, while old IOCs only send one initial value.

Problem: The current version of the gateway will never send anything
for DBE_PROPERTY subscriptions, so we get no meta data at all.

A hack that seems to work:

- Connect to channel
- Get meta data via DBR_CTRL_... data once
- Subscribe to DBR_CTRL_... with DBE_PROPERTY for meta data updates
- Subscribe to DBR_TIME_... with DBE_VALUE or DBE_LOG or DBE_ALARM
  to get value updates

The DBE_PROPERTY subscription will get meta data (and maybe updates) from
the IOCs,

and the separate one-time get is compatible with the gateway.

The latest CSS "utility.pv" library has been updated to do this,
so upcoming versions of CSS will start to support the DBE_PROPERTY.
Meaning: A BOY display of MBBI/MBBO enumeration strings will now update
when the strings are changed, even though the numeric value stays
the same. Or MBBI records can be used as alarm triggers, and the
current value (including updates to the enum strings) can be used
for displays or annunciations.

Thanks,
Kay

On 1/13/12 19:03 , "Andrew Johnson" <[email protected]> wrote:
>On 2012-01-13 Peters, Charles C. wrote:
>> I want the mbbi st to be monitored for a change.  I can modify the
>>.ZRST at
>> runtime, but it is not monitored so I am unable to really change it.
>> 
>> Is it possible to modify my mbbi to monitor the ST fields?
>
>How are you changing the ZRST field?  If it's from a device support's
>read_mbbi() routine then after changing the field string it should also
>call
>    db_post_events(prec, &prec->zrst, DBE_VALUE | DBE_LOG);
>to post value and archive monitors on the ZRST field and
>    db_post_events(prec, &prec->val, DBE_PROPERTY);
>to post a property monitor event on the VAL field.  However for many CA
>clients this will not result in them updating their list of choice
>strings for 
>the VAL field because the DBE_PROPERTY monitor event was new in 3.14.11
>and 
>most CA client programs don't use it yet.
>
>Note that you should never try to do this from an interrupt service
>routine, 
>db_post_events() should only be called from task level with the record
>locked.
>
>If you're using CA to change the ZRST field then the IOC should already
>be 
>posting value and archive monitors on ZRST when you put the new value,
>but if 
>your CA clients don't have a DBE_PROPERTY monitor on the VAL field they
>won't 
>know anything about the string name for that state changing.
>
>You have just pointed me to a bug though; the record should be posting
>value 
>and archive monitors on the VAL field at the same time as the
>DBE_PROPERTY 
>event if the VAL field's contents currently match the xxST field that was
>changed.  I'll fix that in the next release, and if you add my code above
>you 
>should probably do the same thing, like this instead of my second line:
>    int event = DBE_PROPERTY;
>    if (prec->val == 0) event |= (DBE_VALUE | DBE_LOG);
>    db_post_events(prec, &prec->val, event);
>
>HTH,
>
>- Andrew
>-- 
>Optimization is the process of taking something that works and
>replacing it with something that almost works, but costs less.
>-- Roger Needham

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System