Re: "Best Pratice" on Monitors

[Tim Mooney <mooney@aps.anl.gov>]

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 (mooney@aps.anl.gov) (630)252-5417
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab.