Re: [foxboro] More FoxAPI/OM optimization questions

The Foxapi configuration parameter that you need to check is pck_read

The following is from HH900 -

pck_read
n  =  For read-only connections use a separate Object Manager list for each
CP.  This reduces the load on the CP.  If nocsaonread = 1, packing will be
done just as when pck_read = y.

y  =  For read-only connections do not use a separate Object Manager list
for each CP; instead pack each Object Manager list to its capacity  This
increases the load on the CP

The default is y.

I have Cimio (IP.21) and AIMapi (Aim Historian) both collecting via Foxapi
(v4.2.5) on AW51E's.
I used to build the IP.21 collection sets so that all points from a single
CP were listed sequentially. 
However this becomes rather difficult to mainatin as time goes on with
points being added and deleted from data collection.
I have configured Foxapi with the above setting and the API now does all the
hard work for me. 
A check of lists in the CP's etc using RSOM shows the lists to be packed to
the max value of 255 points before a new list is opened and the PID of the
list is Foxapi. This is done irrespective of the order that your tags appear
in the IP.21 lists or AIM* configuration.
Prior to using this parameter each CP had lots of lists open with varying
amounts of tags in the list.
Before and after comparisons of CP loading show a definite improvement in
available CP resources largely due to the reduction of OM scanner loading.

I would suggest that you read HH90 and then use the FoxAPI configuration
tool "foxconf" found in /opt/fox/ais/bin as it prompts for most of the
standard parameters that need to be set and builds a new foxapi.cfg file for
you. A foxapi restart is required for the changes to take effect.

Also the Aspen documentation is incorrect with regard to the use of
fastest_rsr in the cimio cofiguration as foxapi ignores it and you need to
set fastest rsr in the foxapi configuration if you don't want the default
scan rate of 0.5 secs.

Ian Sweetman

Applications Engineer
BP Oil Refinery ( Bulwer Island ) Pty Ltd

Phone  :- +61 7 3243 7537
Fax    :- +61 7 3260 2082
E-mail :- sweetmif@xxxxxxxxxx



-----Original Message-----
From: Corey R Clingo [mailto:clingoc@xxxxxxxxxxxxx]
Sent: Thursday, December 19, 2002 10:45 AM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] More FoxAPI/OM optimization questions




The discussion on whether FoxAPI optimized multiple C:B:P requests from
different FoxAPI client applications to a single OM connection (it does,
spake Dr. Alex :) got me to thinking:  what about other optimization?

Let's say I have an application that opens one FoxAPI list for the
following data:

C1:B1:P1
C1:B2:P1
C1:B3:P1
.
.
.
C1:B10:P1

and a second FoxAPI list with the following data:

C1:B11:P1
C1:B12:P1
C1:B13:P1
.
.
.
C1:B20:P1

Will FoxAPI merge those lists into a single OM list (since all the
requested C:B:Ps reside in the same CP)?

This came to mind because we use Aspen IP.21, and we were told by Aspen to
try to configure collection groups so that they did not span CPs; I believe
their rationale was that FoxAPI did *not* perform the optimization in the
above example and you could incur unnecessary CP overhead processing a
bunch of short lists.

Any thoughts?

Corey Clingo
BASF Corp.


 
 
_______________________________________________________________________
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

Other related posts: