Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Thu, 04 Aug 2005 17:42:49 +0200

Hi Dirk,
first of all: thanks for all the time and effort you are putting into
this. This is very valuable and highly appreciated.
Looking at the code it seems that you definitely some more bugs in gdd
as well as in the Gateway. Wow, what a good job! (I've been poking
around in that code myself a lot, and I mean it!)
Let me add just two comments about the alh connections over the Gateway
at this time, as this might be of wider interest:
Is this conversion to a string really necessary? It does not happen if
no alarm handler is connected. An other side effect of the conversion
is that DOUBLE values are rounded to only 6 significant digits if an
alh is watching them. I think, data should be stored in its native
type wherever possible.

If you look at db_access.h, you will find that DBR_STSACK_STRING is the
_only_ DBR type that contains the data that the alh is interested in.
The alh subscribes to the Gateway asking for DBR_STSACK_STRING, and the
only thing the Gateway is able to do is to use the same type for its
subscription to the IOC.

The Gateway does store data in its native type wherever possible - alas
it is not possible for these alh connections.
Let me think ... back then - when I was adding alh connectivity to the
V1 Gateway - I think I had organized it in a way that the Gateway would
open two subscriptions to the IOC and keep two separate copies of the
data (one native, one DBR_STSACK_STRING) in cases where alh and regular
clients are connected to the same channel. Maybe this mechanism didn't
work correctly or was broken somewhere during the changes for V2. I will
check this as soon as I find time. Do you see different behavior
depending on which client (alh or regular) is connecting first to the
Gateway?
So far my advice: Don't connect alh to the same gateway as your
"normal" clients.

This is true and a reasonable advice for another reason:

Regular clients will usually subscribe for DBE_VALUE events, while the
alh subscribes for DBE_ALARM events, and an archiver will subscribe for
DBE_LOG events.

Even if the Gateway ORed these bits together in its subscription to the
IOC, Channel Access will not tell with an incoming update which event
triggered this update, so the Gateway wouldn't know which clients to
send the data to.

This is a known deficiency in the Channel Access network protocol which
will be fixed in the next major protocol update (for EPICS V4).
As a workaround, I made the Gateway subscribe to the IOCs with a fixed
event mask, which can be set through a command line argument. So the
smartest way to handle this would be starting multiple Gateways with
different event masks, and have the clients connect to the appropriate
Gateway.

This is an ugly workaround, I know, but as long as CA doesn't send me
the event that caused an update, it's all I can do.
So much for now - this mail is too long already....
Again: Thanks a lot for all your help!!
Ralph

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System