Experimental Physics and
Industrial Control System

Gasper,

a CA event does *not* contain the event mask - that is the CA design flaw
that causes all the additional effort and trouble in the Gateway.

A CA client that subscribes to a PV using VALUE and ALARM in the mask will
receive all events that match either one or both. For any event that it
receives, the client will *not* know if it was a VALUE or an ALARM change
(or both) that caused that event to be sent.

So I would argue that the Gateway's alarm handling feature added by cosylab
- if you describe it correctly - has a design flaw.
The only way the Gateway can act fully transparent is by creating separate
subscriptions, one for each combination of event flags used by its clients.
Only that ensures that even in the case updates are dropped between IOC and
Gateway, a client with a certain event mask will still receive the last
update the IOC sent for this event mask. (Which would be the same situation
as directly connecting to the IOC, aka transparent behaviour.)

Again: if CA would send the "reason" (event mask) for an event as part of
the event data, none of this extra effort would be necessary, as the Gateway
would easily know which clients to send an update to.

~Ralph

"Some time ago" is too long ago for the cosylab change still being under
warranty, I guess ;-)

-----Original Message-----
From: Gasper Jansa [mailto:[email protected]]
Sent: Wednesday, January 12, 2011 1:39 AM
To: Jeff Hill
Cc: Dirk Zimoch
Subject: gateway question

Dear Jeff

Some time ago we did a change in the gateway in a way that events were
posted with alarm mask
set only when alarm or status changed. This was done because before this
change alarm handler
was receiving all events and thus 'polluting' its log files since
gateway posted all events with value/log/alarm mask set.

It has been reported now, that it can happen that alarm handler
sometimes does not receive update (e.g. alarm handler
shows that there is an alarm on the record when in reality it is
cleared) when connected via gateway.

I don't know exactly the reason why this happens but probably the reason
is in the feature of channel
access when client can not consume all events a bunch of them can be
dropped but it is assured that
the client always receives the latest one. Is this true?

I can imagine the following scenario when gateway connects to one record:

1. Value in the record changes which also sets an alarm. Gateway
receives an monitor update from the record. It detects that
     alarm has changed so it posts new event to its clients (via
postEvent routine) with value + alarm mask set. All clients receive this
event.
2. Some time later the value in the record changes again which clears an
alarm. Gateway again receives an monitor update
     from the record.  It detects that alarm has been cleared so it posts
new event to its clients with value + alarm  mask set.
3. For some reason this event is dropped (e.g. (I don't really know how
this works) so clients never receive this event.
4. In the meantime value in the record changes again and gateway
receives update. Now the alarm/status of the record is the same
     as in last monitor update so it posts new event only with value mask
set.
5. This last event is sent to the client again but this time only with
value mask set and hence the alarm handler does not receive the update.
     Is this possible?

Best Regards
Gasper

References:

RE: gateway question Jeff Hill

Navigate by Date:

Prev: RE: gateway question Jeff Hill

Next: RE: large arrays native element count wrong with Channel Access in EPICS 3.14.12 Jeff Hill

Index: 1994  1995  1996  1997  1998  1999  2000  2001  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: gateway question Jeff Hill

Next: Access to records from subroutines during iocInit Rod Nussbaumer

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <2011>  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024