Re: [foxboro] More FoxAPI/OM optimization questions

The answer to your first question:
"How would one control the order that FoxAPI orders lists in?" 
is not easilly, 
especially is you are adding and removing points from your list.

That's why the second approach is supported by the pck_read option.
Basically, Foxapi will build its omlist with variables 
in the order in which they are submitted when opening datsets
or when adding variables to the CDX. 
You can see the order if you look at dataset 1 
for the read-only variables
and dataset 2 for the read-write variables.
You can see the omlists that are opened by FoxAPI
if you use the CDT command in som.
The Lbug will that of the AW and the pid will be 
that of the foxapi process.
Having the list id you can use som's opvr command to see the 
names of the variables in the list.

So in theory, you could minimize cp lists if close all you datasets, 
re-organize them and re-open them every time you are 
adding or deleting a point.
Not very practical!

To your second question: 
Most I/A stations support omlists of 255 variables.
Exceptions are early stations like the CP10, AP20, GW20, etc... 
who support smaller lists of 40 or 50 variables.
This is documented in the object manager edoc.


-----Original Message-----
From: stan [mailto:stanb@xxxxxxxx]
Sent: Thursday, December 19, 2002 1:25 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] More FoxAPI/OM optimization questions



On Thu, Dec 19, 2002 at 11:46:53AM -0500, Grumelart, Alain wrote:
> 
> I can offer the following clarifications if it may help.

This is turning inot an interesting discussion.

I've got a couple of followup questiosn, please.

> 
> 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.

How would one control the order that FoxAPI orders lists in?

> 
> 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.

Ok, what are the size limits of om lists?

Thanks for the education here.

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