EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
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  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 
<== Date ==> <== Thread ==>
Subject: Re: Testing the new DBE property in EPICS R3-14-11
From: Ralph Lange <[email protected]>
To: [email protected]
Date: Thu, 16 Sep 2010 09:57:37 -0400
Hello Chengcheng, hello Ben,

On 12.09.2010 10:23, Ben Franksen wrote:
On Sonntag, 12. September 2010, Xu, Chengcheng wrote:
I am trying to test out the EPICS record's new DBE property.
You mean the new CA event type called DBE_PROPERTY?

To summarize: this nice new feature is not yet fully implemented for all
record types; also, camonitor misses an option to specify the request
type to make this useful. I tried to add it but it doesn't work.

Are you sure?

> ./bin/linux-x86/camonitor -h

Usage: camonitor [options] <PV name> ...

-h: Help: Print this message
Channel Access options:
-w <sec>: Wait time, specifies CA timeout, default is 1.000000 second(s)
-m <mask>: Specify CA event mask to use, with <mask> being any combination of
'v' (value), 'a' (alarm), 'l' (log/archive), 'p' (property). Default: va
-p <prio>: CA priority (0-99, default 0=lowest)
[...]

Please verify your impression that the option is missing, and file a bug report if the problem persists.
Note that DBE_PROPERTY was introduced in 3.14.11, so make sure the camonitor you use is from the same release.

We are
assuming when the release note states "support subscriptions that get
events whenever a property of the PV changes."

Note that event types concern properties of PVs as CA sees them. CA has
no notion of records or fields.

Correct.

E.g.: A client subscribes to the ioc:example with a DBR_GR_ type, that includes display limits.
Using the event mask DBE_VALUE, the client would get updates whenever the value changes.
When adding DBE_PROPERTY to the event mask, a record that implements it will also send updates when any other fields of the DBR_GR structure (e.g. display limits) change.

Even though only very few record implement the functionality yet, clients should start using this flag. It will not change the client behavior for the time being, but whenever a record supports the new flag, the client will get updates. Yay!

Does it mean if the meta data i.e value of ioc:example:LOLO 
You mean ioc:example.LOLO?
                     ^

changes
and we were using probe or camonitor to monitor the ioc:example pv,
it will change the value of LOLO since LOLO is a property of the pv.

If you subscribe to ioc:example using a DBR_CTRL_ type with DBE_PROPERTY in the event flag, the lower alarm limit will be part of the data structure. A record implementing this new feature will send an update when this limit changes.
(For ai and ao records, the lower alarm limit of the DBR_CTRL_ structure will be read from the record's LOLO field, but that depends on the record type.)

Looking at 'camonitor -h' I see no option for specifying the DBR type,
so it seems that --apart from timestamp and status/severity--
properties are not supported yet.

Correct.

The camonitor tool is aimed at looking at the timestamped values of many PVs over time. To keep the output readable, it follows the rule "one line per update".
To caget that rule does not apply, so it does support all available data types, producing a multi-line output for any of the complex types.

I would think that camonitor for the complex structures would yield a hard to read, if not unusable output.
Of course: If you have a valid use case, please file a bug report explaining your case and including ideas how the camonitor output should look like for the complex types. I will seriously consider it, that's for sure.

Cheers,
Ralph

Replies:
Re: Testing the new DBE property in EPICS R3-14-11 Andrew Johnson
Re: Testing the new DBE property in EPICS R3-14-11 Ben Franksen
References:
Testing the new DBE property in EPICS R3-14-11 Xu, Chengcheng
Re: Testing the new DBE property in EPICS R3-14-11 Ben Franksen
Navigate by Date:
Prev: Re: asynchronous record behavior Dirk Zimoch
Next: Re: controlling cross compiled build products Andrew Johnson
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: Re: Testing the new DBE property in EPICS R3-14-11 Ben Franksen
Next: Re: Testing the new DBE property in EPICS R3-14-11 Andrew Johnson
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 
ANJ, 16 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·