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
<2011>
2012
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
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|