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  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024  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  <20202021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Receiving duplicate monitor values using CA PV Gateway
From: Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Date: Thu, 27 Aug 2020 16:45:32 +0200
I wasn't even aware of that thread ... nice one! (And I did have other things to do during that week.)

That extra update is related to the function principles of Channel Access and the Gateway. (It also depends on other clients being connected to the same PV through the Gateway, actually.)

The usual order of things when a client establishes a monitor:
1. Monitor request - 2. Current value returned by the IOC immediately - 3.-n. Updates sent by the IOC.

The original Gateway mode was with active cache, so that an external client:
1. Monitor request - 2. Gateway returns cached value immediately - 3.-n. Updates sent by the IOC are forwarded.

The problem: when doing a plain get(), the external client would often see a different value through the Gateway (the value of the last monitor update sent by the IOC) compared to connecting to the IOC directly (the real current value which might differ - e.g. less than the deadband for an analog value).
The '-no_cache' option was added so that externat get() requests would *always* be repeated internally to the IOC. More traffic to the IOC traded in for more transparent behavior on the outside.

Now, in that -no_cache mode, when a monitor connection to the PV exists and an additional external client connects - what should the Gateway do?
It doesn't have the cached value, so it must do another get() on the inside to the IOC. When the answer to that get() arrives, it can't be distinguished from a monitor update. So with a list of clients for that PV, which ones should get the update, which shouldn't?
Also, there are four "event" (reason) bits that can be combined when subscribing. The CA value update from the IOC, however, does not contain information about the reason why this particular update has been sent. Tough for a Gateway that tries to combine multiple external client subscriptions into a single one to the IOC.
These things, especially in situations with multiple external clients connecting quasi simultaneously, make it pretty hard to come up with a simple logic that doesn't lose updates in non-standard situations.
I remember that after trying for quite a while, I eventually was talking myself into being happy with a situation that would send double updates in specific situations. It's relatively easy to filter-out a double update, and relatively hard to fabricate a missing one.

But - by all means: if you feel inclined to give it a try, please go ahead. The current behavior is far from perfect, no doubt. I am not actively maintaining the Gateway, but explaining things and reluctantly looking at pull requests for sure.

Cheers,
~Ralph


Replies:
Re: Receiving duplicate monitor values using CA PV Gateway Johnson, Andrew N. via Tech-talk
References:
Receiving duplicate monitor values using CA PV Gateway Juan F. Esteban Müller via Tech-talk

Navigate by Date:
Prev: Receiving duplicate monitor values using CA PV Gateway Juan F. Esteban Müller via Tech-talk
Next: Re: Receiving duplicate monitor values using CA PV Gateway Johnson, Andrew N. via Tech-talk
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  <20202021  2022  2023  2024 
Navigate by Thread:
Prev: Receiving duplicate monitor values using CA PV Gateway Juan F. Esteban Müller via Tech-talk
Next: Re: Receiving duplicate monitor values using CA PV Gateway Johnson, Andrew N. via Tech-talk
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  <20202021  2022  2023  2024 
ANJ, 27 Aug 2020 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·