Experimental Physics and Industrial Control System
|
On 25.03.2015 20:03, Andrew Johnson wrote:
>Is it reasonable to simply change the event subscription mask to include
>DBE_PROPERTY by default? Will doing so work (in the sense of "not
>fail"), even though only getting VALUE, LOG, and ALARM events) for older
>iocs and through gateways? If so, that's an easy change to make.
Unfortunately I believe the answer is no, and that wouldn't really make
sense anyway since your DBE_PROPERTY subscription would need to request
a DBR_CTRL data type, but your regular value subscription should for a
DBR_STS data type. The DBR_CTRL types do not include the timestamp, and
would use up extra bandwidth if you used it to get all the extra fields
every time when only the value changed.
A tech-talk search for DBE_PROPERTY will being up a couple of posts by
Kay Kasemir explaining what he found to be the best solution, although I
think a more recent post explained that the CSS code may have turned off
this subscription again for the time being.
In my opinion clients should work like this:
Every monitoring client should have a connection callback.
On connect it checks if the data type has changed (that may include
changes in array length, keep in mind that dynamic array length is a
relatively new thing and we cannot expect every server to support it).
If yes, remove existing event subscriptions on this channel and start
from scratch as if the channel was new. Most probably the client needs
to clean up some if its internal data structures here.
If no event subscription exists (new channel or changed data type), the
client should get the DBR_CTRL data once, subscribe for VALUE (or LOG)
plus ALARM changes on the DBR_STS data (as usual) and additionally
subscribe for DBE_PROPERTY changes on the DBR_CTRL data (a second,
independent monitor). It needs two different event callbacks because
different things need to be updated. The callback for DBR_STS is the
usual stuff, but the callback for DBR_CTRL needs to update enum strings,
precision and such.
Servers (IOCs) should support proper DBE_PROPERTY events, but if they
don't no harm will be done to the client. It will just work the
"traditional" way.
Gateways needs to keep subscriptions with different event masks or
different data types separate, even for the same client. The overhead is
not that big, because most clients will use the same two subscriptions
for the same channel only.
Just my two cents.
Dirk
- Replies:
- Re: pyepics not updating pv.enum_strs after connection Ralph Lange
- Re: pyepics not updating pv.enum_strs after connection Ralph Lange
- Re: pyepics not updating pv.enum_strs after connection Kasemir, Kay
- References:
- pyepics not updating pv.enum_strs after connection Jameson Graef Rollins
- Re: pyepics not updating pv.enum_strs after connection Jameson Graef Rollins
- Re: pyepics not updating pv.enum_strs after connection Matt Newville
- Re: pyepics not updating pv.enum_strs after connection Jameson Graef Rollins
- Re: pyepics not updating pv.enum_strs after connection Matt Newville
- Re: pyepics not updating pv.enum_strs after connection Jameson Graef Rollins
- Re: pyepics not updating pv.enum_strs after connection Matt Newville
- Re: pyepics not updating pv.enum_strs after connection Jameson Graef Rollins
- Re: pyepics not updating pv.enum_strs after connection Matt Newville
- Re: pyepics not updating pv.enum_strs after connection Dirk Zimoch
- Re: pyepics not updating pv.enum_strs after connection Andrew Johnson
- Re: pyepics not updating pv.enum_strs after connection Matt Newville
- Re: pyepics not updating pv.enum_strs after connection Andrew Johnson
- Navigate by Date:
- Prev:
Re: Registration Open for the Spring 2015 EPICS Collaboration Meeting Jack
- Next:
Re: pyepics not updating pv.enum_strs after connection 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:
Re: pyepics not updating pv.enum_strs after connection Andrew Johnson
- Next:
Re: pyepics not updating pv.enum_strs after connection 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
|
ANJ, 16 Dec 2015 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|