[foxboro] FW: PI I/A interface

Dirk Pauwels offers the following.
 

AJ

 

I can't post to the list for some reason, I already tried registering again,
didn't help. I still get the mails...

 

I got this from an OSI developer regarding the 250 tags stuff, it's a bit
long, but answers most of the questions regarding lists

 

 

Unbuffered tags do not use any lists within the FoxAPI, but unbuffered tags
(Location2=0) should be avoided if posible. They do not belong to a list, so
are not automatically updated when the I/A object changes. They add a much
higher load to the system because the FoxAPI must broadcast a message of the
control network to retrieve the current value, and then wait for the reply. 

 

*********Note from AJ

The broadcast is generally eliminated in later versions of FoxAPI. It is now
setup to use the IMPORT table automatically. However, the IMPORT table can
fill and the result is a fallback to broadcasts for tags whose top level
name is not in the table. There are tools to check its status
(/usr/local/show_params) and instructions to how to resize it to handle more
top level names.

 

However, the comment about delay is dead on. These calls are much slower and
put a lot of load on the station with the data.

**********

 

There is also a big problem if the controller hosting the object is offline,
because the FoxAPI does its broadcast and waits for the reply, but the reply
never comes, so the FoxAPI eventually times out (12 seconds or longer), but
it means that the interface has stopped scanning the other points during
this timeout period.

 

By default, the FoxAPI can open 100 lists and access 6000 objects. But these
limits can easier be changed. It is just a couple of parameters in the
foxapi.cfg file and restarting the FoxAPI. So, if the customer would like
more lists, it is easy to increase. There are no licensing issues for
increasing these parameters. I think the reason that Foxboro put the
parameters there is because the FoxAPI allocates memory for the lists on
startup, so keeping the maximum at 100 means that it will grab less memory.
On my test system I increased the values to 12000 objects and 200 lists
without any problems.

 

There are some I/A objects that you can not add to lists, so sometimes you
have no choice. String objects can not be added to a list. There are a few
other parameters that you can not use the buffered lists to read. I don't
have a list of them, but I know that the compound .ON parameter can not be
added to a buffered list. The customer should look at his 1500 unbuffered
tags to see if they really need to be unbuffered. For outputs, if you use a
buffered write (object in a write list), then it will "secure" that object.
Only the interface will be able to write to the object, as long as the
interface is running and has the list open. In most cases, this is what you
would want. An unbuffered write would allow as operator to manually
overwrite the value if they wanted, but then the interface would overwrite
it again when the PI source tag changed. And there are the performance
issues for unbuffered access, so it is better to use buffered writes if
possible. Note that there were problems with buffered writes in the previous
versions of the interface, but I believe that it is working pretty well in
the current release. The interface should be able to handle moving an object
from one list to another without having to restart, however there will be a
pause as the interface closes the old lists and opens a new one. It is also
tidier for the FoxAPI (less fragmenting) if the interface was stopped, the
tags edited and the interface restarted.

 

**********Note from AJ

Be careful with secured writes. You don't want to put parameters like LR or
MA on a secured write list because they will remain secured if the AW
crashes and will stay secured until it reboots. This could be a problem to
the operator.

***********

 

Also, from what I have seen, the FoxAPI can handle lists bigger than 250
objects. But, the lower levels of the Foxboro system (the object manager)
have the 250 object limit. If a FoxAPI list is >250 objects, the FoxAPI will
handle the splitting up of the objects into smaller lists. But if you keep
the size of the FoxAPI < 250 then the FoxAPI will just pass it directly to
the object manager, and you have better control of the object manager lists.

 

The reason you want the control of the contents of the lists is to minimize
the number of lists within the controllers, and reduce the network loads. If
you group the objects so that all the objects in one list all come from the
same controller, then it will need few network messages to get the data. If
you need more than 250 objects from a controller, then you can have multiple
lists to a single controller. But you should not have one list that accesses
objects from multiple controllers.

 

Note that the interface will work OK with bigger lists, or lists accessing
multiple controllers etc. The above are recommendations to minimise system
loads. You don't need to go to these lengths for most systems. Only if the
system loading is an issue. If the customer is not running the current
release (2.2.7.35), I would recommend upgrading if possible. I also
recommend using PI-API 1.3.9.5 and FoxAPI 4.2.8.

  

Dirk Pauwels - DCS coordinator 

Engineering dept.

Lawter International BVBA

An RSM Company

Ketenislaan 1c - Haven 1520

B-9130 Kallo, Belgium

T.  +32.(0)3.570.95.97/ Mob. +32.(0)497.428.300

F.  +32.(0)3.570.16.09

E mail: dirk.pauwels@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

Other related posts: