EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: RE: gateway question
From: "Jeff Hill" <[email protected]>
To: "'Gasper Jansa'" <[email protected]>
Cc: [email protected]
Date: Wed, 12 Jan 2011 10:09:35 -0700
Hi Gasper,

Best wishes for your new year.

> 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?

In EPICS, of course the database is the producer of subscription updates and
the ca client is the consumer. In fundamental CS queuing theory we know that
if sustained production rates exceed consumption rates then an infinite
amount of buffering will be consumed if we don?t discard some updates, and
of course the IOC is a limited resource environment so we don't have an
infinite amount of buffering space.

Therefore, to avoid runaway resource consumption problems, when all of the
finite buffering space is consumed, then some of the intermediate updates
are discarded, but always the most recent update is sent. So, yes, it's true
that intermediate updates can be discarded in this way.

> It has been reported now, that it can happen that alarm handler
> sometimes does not receive update

> 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

So it seems that this might be a correct conclusion if the gateway
implementation is deficient, and so perhaps the solution will be to maintain
a state variable with the PV in the gateway which is the current state of
the alarm status and severity, and if this changes then perhaps a
subscription update with proper alarm bit set in the event mask will need to
be synthesized. But perhaps the gateway is already doing this?

Best regards,

Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925


> -----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



Replies:
Re: gateway question Ralph Lange

Navigate by Date:
Prev: RE: Problem using large arrays with Channel Access in EPICS 3.14.12 Jeff Hill
Next: Re: gateway question Ralph Lange
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: EPICS support for Harvard PHD Ultra syringe pump tom.cobb
Next: Re: gateway question Ralph Lange
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·