Re: [foxboro] More FoxAPI/OM optimization questions

I can offer the following clarifications if it may help.

In order to achieve peer-to-peer communication between two I/A station,
which is what FoxAPI is doing with its datasets,
Yous need to have one or more omlist opened on both the source and the
target
(or sink) stations.
If the AW is getting data (let's say 10 variables)from one CP 
then the situation is straight-forward.
You need to open one omlist of 10 variables on both the AW and the CP.

If the AW is getting data from multiple CPs (let's say 10 variables from 2
CPs)
then things get more complicated.

You can open one omlist on the AW.
If the variables in the list are sorted so that all the variables
from the first CP come first and are followed by all the variables 
from the second CP, then it will be necessary to open only one omlist
on each CP to source the peer-to-peer connection.
If the variables in the AW's omlist are not sorted then it will be necessary
to open one omlist on each cp to source each group of consecutive variables
in the AWs list that come from that CP.

The worst case would be if the AW's omlist variables were ordered so that
each odd position contained a variable from one CP and each even position
contained a variable from the other CP.
This would required 10 omlists on each CP to source the peer-to-peer
connection.

You can minmize the number of omlists required on the CP by making sure
"somehow"
that the variables in the AW omlist are ordered properly.

An other way to minimize the number of omlists required on the CPs is to 
use more than one list on the AW.
For the above example, if you open 2 omlists on the AW, ie one for each CP,
then you are sure that you will need only one omlist on each CP 
to source the connection. 
This holds true as long as the number of variables is sufficiently small 
to fit in one omlist. If the number of variables does not fit in a
single om list, then things get even more complicated but the principle
remains the same.

The pck_read option gives you the choice to decide if you want to
take the first or the second approach.

If you pack all the read variables into one AW list (pck_read=1), 
then it is likelly (if the variables are not ordered properly) 
that you will need more than one list per CP.
If you don't pack all the read variables into one AW list (pck_read=0)
then FoxAPI will not mix variables from different CPs into the same
AW list. This guarantees that the number of lists required on the CPs
to source the connection is minimal.

The second approach is a trade-off, you minimize the use of a scarce
resource
on one station (the CP) by using more of the same resource on an other
station (the AW) where it is not so scarce.

I hope this makes enough sense to be helpfull.

Alain G.

-----Original Message-----
From: Corey R Clingo [mailto:clingoc@xxxxxxxxxxxxx]
Sent: Thursday, December 19, 2002 10: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: