Re: [foxboro] FOXAPI Configuration for Foxhistory Ver 2.0
- From: stan <stanb@xxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Wed, 11 Dec 2002 10:17:06 -0500
On Wed, Dec 11, 2002 at 09:47:45AM -0500, Johnson, Alex (Foxboro) wrote:
>
> The fastest_rsr value controls the period that is used by the OM in the
> remote station. The period controls how often the OM checks a list for
> changes. So, a 10s fastest_rsr will cause the CP to report changes on the
> list once every 10 seconds.
>
How fortuitous that this should come up for discussion at this time. One of
my co-workers ran into this value, in a discussion with TAC this morning,
and I would like some clarification here.
Here is the situation. We have a management edict to get large volumes of
data into the mill-wide PI system. Now we of course are trying to minimize
the impact of this on the control systems. Areas of concern include of
course CPU loading on the PI host A[PW}'s, and nodebus loading.
What we had done relative to nodebus loading was to break the data into
groups, and attempt to "phase" the collection of this data. For example we
have some datasets that we have told PI to check every 2 seconds, and some
datasets we have told it to check every 5 seconds.
Now, I'm wondering if this was a waste of time? It appears that the
fastest_rsr parameter will override anything we do. Is this correct?
Is any effort to control nodebus traffic impact of PI in any way other than
controlling the number of tags/datasets futile?
--
"They that would give up essential liberty for temporary safety deserve
neither liberty nor safety."
-- Benjamin Franklin
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: http://www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
- References:
- Re: [foxboro] FOXAPI Configuration for Foxhistory Ver 2.0
- From: Johnson, Alex (Foxboro)
Other related posts:
- » Re: [foxboro] FOXAPI Configuration for Foxhistory Ver 2.0
- » Re: [foxboro] FOXAPI Configuration for Foxhistory Ver 2.0
- » Re: [foxboro] FOXAPI Configuration for Foxhistory Ver 2.0
- » Re: [foxboro] FOXAPI Configuration for Foxhistory Ver 2.0
- » Re: [foxboro] FOXAPI Configuration for Foxhistory Ver 2.0
- » Re: [foxboro] FOXAPI Configuration for Foxhistory Ver 2.0
- » Re: [foxboro] FOXAPI Configuration for Foxhistory Ver 2.0
- » Re: [foxboro] FOXAPI Configuration for Foxhistory Ver 2.0
- » Re: [foxboro] FOXAPI Configuration for Foxhistory Ver 2.0
- » Re: [foxboro] FOXAPI Configuration for Foxhistory Ver 2.0
- » Re: [foxboro] FOXAPI Configuration for Foxhistory Ver 2.0
- » Re: [foxboro] FOXAPI Configuration for Foxhistory Ver 2.0
- » Re: [foxboro] FOXAPI Configuration for Foxhistory Ver 2.0
- » Re: [foxboro] FOXAPI Configuration for Foxhistory Ver 2.0
- » Re: [foxboro] FOXAPI Configuration for Foxhistory Ver 2.0
- » Re: [foxboro] FOXAPI Configuration for Foxhistory Ver 2.0
- Re: [foxboro] FOXAPI Configuration for Foxhistory Ver 2.0
- From: Johnson, Alex (Foxboro)