As I said, fastest_rsr sets the scan rate for all points opened by FoxAPI -
IP.21 uses FoxAPI.
The original AIS API allowed each data set to be opened with a different
scan rate. FoxAPI maintains the same call, but ignores the read scan rate
specification. The OM lists that implement the data set are all opened with
fastest_rsr.
The FoxAPI Information Bulletin (available from TAC) says:
fastest_rsr
The read-scan-rate that is used for all connections made by
FoxAPI. The read-scan-rate and delta values used with OM control the
frequency of updates from the CP. The proper setting of object deltas is
critical. The default is 1(1/2 second); the range is 1 to 20(1/2 to 10
seconds).
So, feel free to specify anything you want in the call, but you won't go
faster or slower than fastest_rsr.
Also, this was the source of interesting compatibility problem during the
transition from AIS to FoxAPI. In AIS, people would set the change delta to
0.0 and the scan rate to 10s, this resulted in an update on all points in
the list every 10s. This is not such a bad thing.
When they upgraded to FoxAPI though, they got an update on all points every
0.5s and this is a very bad thing - 20x load on the CP for example.
Regards,
Alex Johnson
Invensys
10707 Haddington
Houston, TX 77063
713.722.2859 (office)
713.722.2700 (switchboard)
713.932.0222 (fax)
ajohnson@xxxxxxxxxxx <mailto:ajohnson@xxxxxxxxxxx>
For the latest information on ArchestrA, go to
www.invensys.com/Archestra.html
<http://www.invensys.com/divisions/Archestra.html> .
-----Original Message-----
From: Corey R Clingo [SMTP:clingoc@xxxxxxxxxxxxx]
Sent: Wednesday, December 11, 2002 9:58 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] FOXAPI Configuration for Foxhistory
Ver 2.0
He he. You are talking to a bunch of engineers. What did you
expect? :)
Your comments about fastest_rsr are interesting. We were discussing
this
problem here a little while back, and I perused the FoxAPI docs to
try and
get a better understanding (I've never programmed FoxAPI, and don't
claim
to be an expert on it). They seemed to imply that applications
could set a
scan rate per list when opening lists, and maybe per tag when using
other
calls. They mentioned fastest_rsr, but did not make clear how it
interacted with the lists' scan rates. I assumed it was a lower
bound from
a scan period standpoint, but lists could scan more slowly (higher
periods)
if the applications that opened them passed the right info in the
function
calls.
Having said that, we run Aspen IP.21, and setting fastest_rsr from
nothing
(defaults to 0.5s) to 20 (10s) increased our CP idle time from 5-10%
on
anything below a CP60, and 1-3% on the CP60s. So either fastest_rsr
overrides everything as you said, or IP.21 doesn't specify slower
scan
rates on its lists (we scan everything at 10s or slower in IP.21),
or both.
Corey Clingo
BASF Corp
|---------+---------------------------->
| | "Johnson, Alex |
| | (Foxboro)" |
| | <ajohnson@Foxboro|
| | .com> |
| | Sent by: |
| | foxboro-bounce@fr|
| | eelists.org |
| | |
| | |
| | 12/11/2002 09:35 |
| | AM |
| | Please respond to|
| | foxboro |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------
----------------------------------------------------|
|
|
| To: foxboro
|
| cc:
|
| Subject: Re: [foxboro] FOXAPI Configuration for
Foxhistory Ver 2.0 |
>---------------------------------------------------------------------------
----------------------------------------------------|
Re: Actually sampling theory, ie. Nyquist, says that you should
sample at
least twice as fast as the fastest frequency that is present in the
data.
I knew when I wrote that I should have said that this is an
approximation
of
the theory. I actually wrote that, but decided that it was
distracting.
Sigh...
It is hard to know how much detail to provide sometimes.
Regards,
Alex Johnson
_______________________________________________________________________
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
_______________________________________________________________________
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