Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Wed, 22 Jun 2005 09:37:21 +0200

Kay-Uwe Kasemir wrote:

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.

Whenever the high limit changes, do you
get all the properties?
Or only the new limit?

We were discussing this issue at the last meeting and - as far as I

remember - we even had an agreement.

On the wire CA will only transport properties that have changed.

The CA client tool will have to present a property catalog for the

subscription at subscription time. (So that the CA client library is

able to find out what's being requested.)

The first update event will hold the complete property catalog that the

client asked for (as well on the net as for the client tool). With every

subsequent incoming event, this catalog gets updated inside the user's

callback function (derived from subscriptionUpdateNotify) with the

properties that were coming in from the wire. (I.e. those that were

changed.)

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.

As the original IOC has to solve exactly the same problem, my guess is

that this is solved as part of the CA server library.

The only original thing that the Gateway has to do is changing channel

subscriptions (on the Gateway's CA client side) when outer clients

subscribe or unsubscribe that change the deadbands or dynamic properties

in a way that the existing subscription wouldn't get all or not enough

updates.

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.

class Container:
- methods for adding & removing properties & values
- attach(Channel)

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.

To achieve this, the CA client library itself could hold a copy of the

complete property catalog (aka Container) internally and provide the

client tool with a reference to that property catalog. In that case the

callback function (derived from subscriptionUpdateNotify) would only

signal that something has changed and the property catalog would always

get the whole thingy. The data store would be inside the CA client

library and the client tool wouldn't even have to care about a

representation (be it type-fixed or not) for storing the data.

The easiest and most general way for such a Data Store would be the

completely separated Data Store implementation that I was mapping out in

one of my last mails.

Ralph

--
Ralph Lange               [email protected]     Tel: +49 30 6392-2117
BESSY Controls Group      www.bessy.de             Fax:      ...   -4859

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System