Experimental Physics and
Industrial Control System

Dirk Zimoch <[email protected]> · Thu, 26 Mar 2015 09:47:42 +0100

On 25.03.2015 20:03, Andrew Johnson wrote:

>Is it reasonable to simply change the event subscription mask to include
>DBE_PROPERTY by default?  Will doing so work (in the sense of "not
>fail"), even though only getting VALUE, LOG, and ALARM events) for older
>iocs and through gateways?  If so, that's an easy change to make.

Unfortunately I believe the answer is no, and that wouldn't really make
sense anyway since your DBE_PROPERTY subscription would need to request
a DBR_CTRL data type, but your regular value subscription should for a
DBR_STS data type. The DBR_CTRL types do not include the timestamp, and
would use up extra bandwidth if you used it to get all the extra fields
every time when only the value changed.

A tech-talk search for DBE_PROPERTY will being up a couple of posts by
Kay Kasemir explaining what he found to be the best solution, although I
think a more recent post explained that the CSS code may have turned off
this subscription again for the time being.

In my opinion clients should work like this:

Every monitoring client should have a connection callback.

On connect it checks if the data type has changed (that may include

changes in array length, keep in mind that dynamic array length is a

relatively new thing and we cannot expect every server to support it).

If yes, remove existing event subscriptions on this channel and start

from scratch as if the channel was new. Most probably the client needs

to clean up some if its internal data structures here.

If no event subscription exists (new channel or changed data type), the

client should get the DBR_CTRL data once, subscribe for VALUE (or LOG)

plus ALARM changes on the DBR_STS data (as usual) and additionally

subscribe for DBE_PROPERTY changes on the DBR_CTRL data (a second,

independent monitor). It needs two different event callbacks because

different things need to be updated. The callback for DBR_STS is the

usual stuff, but the callback for DBR_CTRL needs to update enum strings,

precision and such.

Servers (IOCs) should support proper DBE_PROPERTY events, but if they

don't no harm will be done to the client. It will just work the

"traditional" way.

Gateways needs to keep subscriptions with different event masks or

different data types separate, even for the same client. The overhead is

not that big, because most clients will use the same two subscriptions

for the same channel only.

Just my two cents.
Dirk

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System