Experimental Physics and
Industrial Control System

Dirk Zimoch <[email protected]> · Mon, 23 Jan 2012 10:58:39 +0100

Just a remark about gateways and properties:

A client might have the idea to subscribe for DBR_CTRL_... with

DBE_VALUE (or DBE_LOG) + DBE_ALARM.

This does not work at all. The gateway itself does a get on DBR_CTRL_...

on connection and then subscribes for DBR_STS_... only. These two pieces

of data are held in two different variables. As a result, it sends only

the STS data to the client and fills the other fields (e.g. limits,

units, etc) with 0, 0.0, or "".

Dirk

Kasemir, Kay wrote:

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