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
- References:
- DBE_PROPERTY support in R3.14.11, gateway, CSS, MBBI/MBBO Re: Rec Proc Monitor for mbbi ZRST Kasemir, Kay
- Navigate by Date:
- Prev:
DBE_PROPERTY support in R3.14.11, gateway, CSS, MBBI/MBBO Re: Rec Proc Monitor for mbbi ZRST Kasemir, Kay
- Next:
Motor record support for Galil DMC-2183 Phillip Sorensen
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
DBE_PROPERTY support in R3.14.11, gateway, CSS, MBBI/MBBO Re: Rec Proc Monitor for mbbi ZRST Kasemir, Kay
- Next:
problem with 64 bit build of EDM v1-12-68 John Dobbins
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|