Re: [foxboro] More FoxAPI/OM optimization questions

The pck_read parameter needs to be interpreted with respect to the station
on which the API is running.
The option to pack the list refers to the lists on the AW/AP not the list in
the CP, so by saying No to packing you are telling it not to pack the lists
at the AW/AP but to open a separate list for each device.
The API will then create a separate OM list for each CP etc and adds/deletes
tags from the lists irrespective of the order that they are given to the
API. 
This results in a minimum number of lists at the CP which are filled based
on the value of "maxien" in foxapi.cfg (default of 255 if not set
otherwise).

If you use the foxconf utility then enter 'N' at the prompt for the pck_read
option or if you edit foxapi.cfg manually then add the line "pck_read = 0".
This is for read only connections.

The same can be done for read/write connections by setting pck_write ie
"pck_write = 0"

 Example foxapi.cfg to minimise cp lists

fastest_rsr    =   8
maxobj         =   10000
maxqo          =   1
maxch          =   10
maxds          =   100
maxien         =   255
pck_read       =   0
pck_write      =   0
maxlog         =   1000
ctdlay         =   50
ddctly         =   0
logtrm         =   0
docmsg         =   0
wfilt          =   0
trcast         =   0
trccts         =   0
trcef          =   0
trcfil         =   0
trclok         =   0
trcx25         =   0
trcbrw         =   0
open_wait      =   1
status_wait    =   10
use_omopen     =   1
nocsaonread    =   0

I segregate IP.21 get records based on the node that I am collecting from so
that there is not data collection across CBLan, the data collection for each
node then is built without having to worry about which CP it comes from on
that node, as the API takes care of this. This has allowed me to simplify
the adding/deleting of tags to IP.21 wether I am adding individual tags by
hand or bulk additions by script.


Ian


-----Original Message-----
From: Corey R Clingo [mailto:clingoc@xxxxxxxxxxxxx]
Sent: Friday, December 20, 2002 1:41 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] More FoxAPI/OM optimization questions




OK, I guess I need a little clarification.  Did you set this value to "y"
or "n"?

This documentation also seems to contradict my notion that for a given
number of points read out of a particular CP, the fewer lists that are
used, the lower the CP loading.

We didn't really have problems with grouping the tags by CP, as we
initially built the system with scripts that grouped the points by CP, and
the groups have the CP letterbug in them, so they are easy to find.  The
only hassle is having to find out the CP letterbug for new tags to be
added, particularly the onesy-twosy ones that we do by hand.

Corey



|---------+---------------------------->
|         |           "Sweetman, Ian F"|
|         |           <SweetmIF@xxxxxxx|
|         |           com>             |
|         |           Sent by:         |
|         |           foxboro-bounce@fr|
|         |           eelists.org      |
|         |                            |
|         |                            |
|         |           12/18/2002 10:53 |
|         |           PM               |
|         |           Please respond to|
|         |           foxboro          |
|         |                            |
|---------+---------------------------->
 
>---------------------------------------------------------------------------
----------------------------------------------------|
  |
|
  |               To:  "'foxboro@xxxxxxxxxxxxx'"
|
  |        cc:
|
  |        Subject: 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







 
 
_______________________________________________________________________
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: