![]() |
![]() ![]()
Experimental Physics and
| ||||||||||||||
|
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? 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:LOLOYou 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
| ||||||||||||||
ANJ, 16 Sep 2010 |
![]() · Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |