EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  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  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: "Best Pratice" on Monitors
From: Tim Mooney <[email protected]>
To: Bill Nolan <[email protected]>
Cc: Tech-Talk <[email protected]>
Date: Fri, 08 Sep 2006 12:49:47 -0500


Bill Nolan wrote:

Hi all,
    So I've just about finished a new device support and record set
involved in my current project, and I am sitting looking at the how to
handle when to raise monitors.
    The IOC dev guide says that record support should *NOT* call
db_post_event() for values that do not change. So I've started coding in
the check for each value held by the record, and I stooped, probably
because its Friday, and looked at why.....
    The record and its connected device have over 100 monitorable
fields, and if any one changes, there will be changes in almost 80 other
fields, so to the point...
    Will I break anything by posting a monitor for the 20 or so
remaining field that have not changed ?

No.


    I will of course incur the network load for 20 extra fields, but
what other costs are there. Or is posting on a no change just bad enough
practice that it should not be done for any reason ?

The other costs are the cpu loads on the server and any clients that are monitoring, displaying, archiving, etc. You don't know the full cost in advance, because you don't know what clients might be monitoring. Altogether, it's a lot less costly to check than to post.

There's one situation I can think of in which it's good to post a value that
hasn't changed.  This is when the post signals that some event has occurred.
In this case, the timing of the post is the "value", so you could still say
that you're posting because a value has changed.

--
Tim Mooney ([email protected]) (630)252-5417
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab.

Replies:
RE: "Best Pratice" on Monitors Dalesio, Leo `Bob`
References:
"Best Pratice" on Monitors Bill Nolan

Navigate by Date:
Prev: Re: VME Bus Error handling on MVME3100 and MVME6100 boards Kate Feng
Next: RE: "Best Pratice" on Monitors Dalesio, Leo `Bob`
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: "Best Pratice" on Monitors Bill Nolan
Next: RE: "Best Pratice" on Monitors Dalesio, Leo `Bob`
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·