Re: [foxboro] PI I/A Interface and non-updating values

  • From: tom.vandewater@xxxxxxxxxxxxxx
  • To: foxboro@xxxxxxxxxxxxx
  • Date: Wed, 13 Apr 2005 13:26:58 -0400

Brad,
        It isn't clear in your note if you are running Ver. 4.3 Fox IA,
(AW), software or Ver.4.3 foxapi.  Your base IA software Version and the
FoxAPI software version is unlikely to be the same.  To find out what
version of foxapi you are running you can issue the following command if in
a VT or telnet session on the AW51 you use to pass data to PI.

what /opt/fox/ais/bin/foxapi |more
on our current system the output starts like this:

/opt/fox/ais/bin/foxapi:
        fabs.S 1.14 92/01/24 SMI
        FoxAPI.c Date 02/20/97
           Fox API Version 4.2.2 Copyright (c) Foxboro 1992-1998

        We are running Ver.6.2.1 base IA software but Ver.4.2.2 foxapi.
foxapi is Foxboro's IA Application Programmers Interface tool that can be
used by other vendor or user applications such as OSI PI, WonderWare, or
Aspentech to access data from the Fox IA system.
        In addition to foxapi there are other files used specifically by OSI
PI to interface with foxapi. piapi is the PI server software running on the
server that connects to your AW51 but there is a header file on the AW51
that should indicate what version piapi is being used on the server.  Using
"what" as in the example below lets me know that we are using Ver.1.35 piapi

what /opt/piapi/build/api/piapi.h  returns the following on our system:
piapi.h:
        piapi.h 1.35 06/17/96

        The client side application for OSI PI that runs on the AW51 is
called fxbais and the fxbais version can be found by running "more" on the
file called releasenotes.txt as shown below:

more /opt/piapi/interfaces/fxbais/releasenotes.txt
       Foxboro I/A (FoxAPI) Interface
       Sun Solaris 2.x and Windows NT Intel

          version 2.2.4   Release Notes

        Brad, I am curious to know if you are already running foxapi Ver.
4.3 and are experiencing the flat-line symptoms that Corey mentioned.
Corey, I know you are using Aspentech but what version of foxapi are you
currently running?  Thanks for any feedback.

Tom VandeWater
Control Systems Developer/Analyst
Dow Corning Corporation
Carrollton, KY   USA

1. Upgrade from 4.2.2 to the current version of the FoxAPI (4.2.8) 

2. Upgrade from 2.2.4 to the current version of the Foxboro I/A Interface
(fxbais) 2.2.7.35. This version has some fixes for handling bad inputs. 

3. Install the quick fix "QF1005118 - om_server initial scan update fix"
dated 11/05/03.

4. Modify our OSI PI lists to insure that no more than 250 values exist per
CP in any one PI list.

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of brad.s.wilson@xxxxxxxxxxxxxx
Sent: Tuesday, April 12, 2005 4:44 PM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] PI I/A Interface and non-updating values

Seeing all these messages about PI prompted me to write with my own PI
problem.
We have v4.3 with 17 CP40s (non-FT).  Occasionally I will have some points
"freeze" in PI ... there will be no error messages such as I/O timeout or
bad input ... but the value will stop updating, so I get a flat line.  The
last good value is timestamped with the time the freeze occured, but I can
find no apparent cause for it ... no I/A error messages (at least none that
make sense to me), the DCS is unaffected.  The values are always (I
believe) analog.  Often (but not always) they are all in the same
collection group, but not ALL the points in the group freeze.  I know of no
way to "kick-start" the group without stopping and restarting the PI
interface, which clears anything that might have been in the buffer and
causes breaks in all my data.  I don't know if these "frozen" points are
even being scanned or if the values are in the buffer but not being
uploaded to PI.  Without much knowledge of how collection groups actually
work, I have created 2 groups per CP ... one for analog values and one for
discrete.  The points are not evenly distributed between groups, because
some CPs are more heavily loaded than others.  We have 2 nodes, but only
only one PI portal, so the PI interface must go cross-node to reach 13 of
the CPs.  Any ideas?

Brad Wilson
ExxonMobil Chemical Co
Edison Synthetics Plant
732-321-6115
732-321-6177 fax
Brad.S.Wilson@xxxxxxxxxxxxxx

 
 
_______________________________________________________________________
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:             //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:             //www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
 

Other related posts: