EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022 
<== Date ==> <== Thread ==>

Subject: Subscription / first update
From: Ralph Lange <[email protected]>
To: EPICS V4 Developers <[email protected]>
Cc: EPICS Core-Talk <[email protected]>
Date: Thu, 14 Jan 2016 13:23:08 +0100
The issue with subscriptions and first updates
========================================

This issue applies to monitor subscriptions to ANALOG values that use a DEADBAND technique to limit the update rate, e.g. CA monitors to EPICS database records of analog type that use MDEL.
The specification (or documentation) says a client gets the current
value on connection, then updates whenever the value leaves a configured
deadband around the value last sent.
The EPICS database uses the cache of the "value last sent" once per
record instance. The first client will correctly get the current value,
then updates when the values leaves the deadband. Additional clients
will get the current value, then updates when the values leaves the
deadband of the first client's last update. This effectively changes the
deadband for the second update of additional clients to be anywhere
between zero and twice the configured deadband.
In most cases, the effects are not prominent. For any values that change
frequently, there's a short oddity right after connecting, then
everything is in sync across all clients.
For slowly changing channels, however, that first update interval of
additional clients can last minutes or longer. During that time (i.e.
until the first client gets a new update), any additional newly
connecting client will show a different value.
I have seen situations (special synchrotron operation mode with
extremely good lifetime) where a handful of panels on screens in the
main control room where all showing different values for the same
prominent PV (beam current).
Conceptually, there are two ways out of this:

Either, the deadband algorithm (including the last value cache) is done per client - this is what happens when you use the 3.15 server-side plugin that does deadband limitation. This guarantees correct deadband behavior for each client, but makes the across-client situation worse: different panels showing the same PV will *always* show different values.
Or - and that would be my suggestion - the first update that clients
receive is redefined as being the cached last value that the first
client of the same subscription received. That way, all additional
panels that you open will always show the same value as the first
client, even across Gateways. Also, the effective deadband for second
updates to additional clients will be between zero and the configured
value, and never larger than configured as in the current situation.
Would that be something to change in 3.16, and follow in V4?

Cheers,
~Ralph

Replies:
Re: Subscription / first update Andrew Johnson

Navigate by Date:
Next: Re: Subscription / first update Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022 
Navigate by Thread:
Next: Re: Subscription / first update Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022 
ANJ, 22 Jan 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·