Experimental Physics and
Industrial Control System

Kay-Uwe Kasemir <[email protected]> · Tue, 21 Jun 2005 15:48:27 -0400

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System