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: "Dalesio, Leo `Bob`" <[email protected]>
To: "Tim Mooney" <[email protected]>, "Bill Nolan" <[email protected]>
Cc: "Tech-Talk" <[email protected]>
Date: Fri, 8 Sep 2006 10:53:15 -0700
To make something post all of the time - you can set the MDEL to a negative number. Then the post is controlled by whoever configures the record.
Bob 

-----Original Message-----
From: Tim Mooney [mailto:[email protected]] 
Sent: Friday, September 08, 2006 10:50 AM
To: Bill Nolan
Cc: Tech-Talk
Subject: Re: "Best Pratice" on Monitors



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.


References:
Re: "Best Pratice" on Monitors Tim Mooney

Navigate by Date:
Prev: Re: "Best Pratice" on Monitors Tim Mooney
Next: Re: EPICS source Documentation Paul Joireman
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: Re: "Best Pratice" on Monitors Tim Mooney
Next: EPICS: Visualization David Dudley
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 ·