On Jun 21, 2005, at 13:43, Dalesio, Leo `Bob` wrote:
Monitors have been a callback on a "change" in one of the three
events: alarm condition changes, value monitor changes, Does this
become:
Subscribe
Send Channel ID
filters
% (of range or of last notification)
absolute change
rate limit
events
bits in the 32 bit event mask - definable in each IOC.
event records and event system sets the events to true
event records should be able to get value from calcs
Return value on the specified event when the filter is met.
What do you get in the return value?
Assume you subscribe to
- PV "fred",
- properties "value", "units", various limits,
and the new property for "color" (of fred's shoes),
- request notification on 3% change of value,
any change in other properties,
limited to 1 value / sec,
but a minimum of 1 value per minute.
(Sub - issue: How do you pass the request?
An SQL-type string into the 'user friendly' API
that gets converted into a class subscrFilterSpec?)
(Sub - issue: How do you get notified?
CA V3 uses a C function pointer callback.
The current V4 proposal means I have to derive
from subscriptionUpdateNotify, which ends up being more source
code but is the same thing:
One and the same function gets invoked for the duration of the
subscription.
Java APIs use the idea of adding and removing 'listeners'.
A subscription could have 1 or more listeners,
very common in display tools.
It could also have 0 listeners, at least temporarily
while e.g. a display tool like EDM is closing & re-opening
screen definitions at runtime.
)
Whenever the high limit changes, do you
get all the properties?
Or only the new limit?
For efficiency, only changes should be sent.
Consider the case of the gateway which has
one client interested in fred.value every minute,
another in {value +- 3%, units, limits},
....
so it subscribes as shown above
and then needs to figure out which data to forward
to what client, so it needs to know which
condition was triggered.
On the other hand, a simple client application wants
an easy API to the full data set, kept up to date all the time
without having to handle each piece of data yourself.
Something like this might work:
class Channel:
allows you to subscribe,
and the notification includes a data-access handle to the changed
properties.
You need to use DA to figure out what properties
are in there and store the data yourself.
class Container:
- methods for adding & removing properties & values
- attach(Channel)
- interface data_access_listener:
you_have_new_data(data_access *what_changed_and_how, data_access
*all_the_data);
- add_listener(data_access_listener),
remove_listener(data_access_listener)
When attached to a Channel, the container will automatically
issue a 'get' for all its properties and then subscribe to changes.
When the high limit changes, the container updates its
high limit and sends a 'new data(high limit)' notification to
all listeners,
in which you can see that the limit changed but you can also still
access the current value, units, ...
I actually believe that the use of Containers will be very common:
Simple 'caget' tools, EDM, archiver, CA gateway
all could use the same container and wouldn't have to come up with
their own in-memory data storage.
For a CA server, it's probably more common that you already have
the data stored and only need a way to expose it to CA.
Thanks,
-Kay
- Replies:
- Re: Monitors Ralph Lange
- References:
- RE: Monitors Dalesio, Leo `Bob`
- Navigate by Date:
- Prev:
hello world examples Marty Kraimer
- Next:
Re: hello world examples Ralph Lange
- Index:
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: Monitors Dalesio, Leo `Bob`
- Next:
Re: Monitors Ralph Lange
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|