Re: [foxboro] PI I/A Interface and FoxAPI "Bad Input" Fix + CP60 reboot

I'm not a PI expert and I can't speak to how their software is configured,
but I understand that one can "group" points and open groups separately.

Under the covers, these groups map into one or more OM lists. Opening OM
lists is an "expensive" operation for Control Stations and opening a large
number of such lists quickly can cause points to fail on the list.

The change to foxapi.cfg that I mention slows the opening of the lists.
Similar things can be done on the PI side as well (though I don't know how
to do them).

Does this help?

Regards,
 
Alex Johnson
Invensys Process Systems
Invensys Systems, Inc.
10707 Haddington
Houston, TX 77043
713.722.2859 (voice)
713.722.2700 (switchboard)
713.932.0222 (fax)
ajohnson@xxxxxxxxxxx

-----Original Message-----
From: Jaime Claramunt R. (Inforsa) [mailto:jclaramunt@xxxxxxxxxxxxxxx] 
Sent: Tuesday, April 19, 2005 8:45 AM
To: foxboro@xxxxxxxxxxxxx
Cc: ajohnson@xxxxxxxxxxx
Subject: RV: [foxboro] PI I/A Interface and FoxAPI "Bad Input" Fix + CP60
reboot

are you getting this mail  ???

I got "undeliverable" after quite a lot of time i've sent it...


-----Mensaje original-----
De: Jaime Claramunt R. (Inforsa) 
Enviado el: Jueves, 14 de Abril de 2005 08:20
Para: foxboro@xxxxxxxxxxxxx
Asunto: RE: [foxboro] PI I/A Interface and FoxAPI "Bad Input" Fix + CP60
reboot


BTW... What do you mean with "250 tags in PI list" ??
what is a list ?

thx

Jaime Claramunt
Inforsa Paper Mill
Chile


-----Mensaje original-----
De: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]En
nombre de Johnson, Alex (Foxboro)
Enviado el: Miercoles, 13 de Abril de 2005 17:11
Para: foxboro@xxxxxxxxxxxxx
Asunto: Re: [foxboro] PI I/A Interface and FoxAPI "Bad Input" Fix + CP60
reboot


Re: 4.3

It is available for Windows and Solaris.


Re: 250 points

The issue here is that the tags map to tags on an OM list. A large OM list
can put a lot of load on the CPs when it is opened. This loading impact in
reflected in "missing" points when a list is opened. They aren't really
missing, but the device didn't reply fast enough.

In the "old days", this happened frequently on PI systems. When PI started
up, many points showed disconnected status. This was especially true in
systems with CP10s or CmP15s.

The solution is to adjust the foxapi.cfg file to allow more delay between
opens. This is controlled by the ctdlay parameter. I set it to two seconds
(200).

Regards,
 
Alex Johnson
Invensys Process Systems
Invensys Systems, Inc.
10707 Haddington
Houston, TX 77043
713.722.2859 (voice)
713.722.2700 (switchboard)
713.932.0222 (fax)


-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Pulas, Philip (GE Contractor)
Sent: Wednesday, April 13, 2005 3:58 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] PI I/A Interface and FoxAPI "Bad Input" Fix + CP60
reboot

Thanks for the info Tom and Chad!  I will have to change my program that
creates PI tags to limit the tag count to 250 per list when we perform
the upgrade.

As for instituting the changes in my initial email, we have not done any
of this yet.  We have confirmed that we do need to perform all of the
items (upgrade FoxAPI, upgrade fxbais, and install the Quick Fix) on
almost all of our I/A systems, but probably won't have time to do so for
a couple of weeks. =20

From what we have heard, FoxAPI v4.3 is only for Windows I/A systems,
which we are trying to get because we have a new I/A system on XP that
we'd like to get into PI.  I believe we are also waiting to get this
version.

Thanks,
Philip P.=20

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of tom.vandewater@xxxxxxxxxxxxxx
Sent: Wednesday, April 13, 2005 1:31 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] PI I/A Interface and FoxAPI "Bad Input" Fix +
CP60 reboot

Philip,
        Glad you asked about #4  I wrote it just to see if anyone was
really
reading this stuff. On Page 34 of a document from OSI titled:

"Foxboro I/A 51 and 70 Series Interface to the PI System Version
2.2.7.35"

It says:

"Some customers have experienced performance problems when there are
many
(~250) tags in a PI List.  So, you may want to keep the size of a PI
List
within this number."

I will send you the document off list.

        I'm curious to know if you have already instituted the other
changes
you referred to in your initial email?  If so, has it solved your
problems?
Duc has been installing the fixes one by one and rebooting on a sandbox
AW51. He installed foxapi 4.2.8 this morning, (sorry Alex but 4.3 isn't
downloadable and we haven't gotten a response from CSC yet).  We are
seeing
some strange results but I won't elaborate until we have installed all
of
the recommendations to see if our problems are solved.  Later in the day
he
installed QF1005118 - om_server initial scan update fix" dated 11/05/03.
Tomorrow morning he will install fxbais ver. 2.2.7.35 which will
complete
the process.  More about this after that is done.

Tom V.

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On
Behalf Of Pulas, Philip (GE Contractor)
Sent: Wednesday, April 13, 2005 3:58 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] PI I/A Interface and FoxAPI "Bad Input" Fix +
CP60
reboot

Tom,

I'm curious about your comment "4. Modify our OSI PI lists to insure
that no more than 250 values exist per CP in any one PI list."

Did you find this limitation or recommended value in any documentation?
I have been looking to see if there was a recommended number to limit
each OSI PI list to, but have only found that there is a parameter for
total number of PI lists and total number of PI points allowed per
fxbais interface.  Right now, whether or not we have a few PI points or
several thousand PI points from a single CP or GW, I put all of the
points from that single CP or GW in the same list (two lists, actually,
one that scans more often than the second).  Please direct me to where
you found the 250 PI point limit per PI list.  I have been curious to
know if having several thousand PI points in one list can be
contributing to any missed PI scans.  Thanks in advance for your help.

Thanks,
Philip Pulas
Tesoro Corporation
Golden Eagle Refinery
Martinez, CA

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of tom.vandewater@xxxxxxxxxxxxxx
Sent: Tuesday, April 12, 2005 10:39 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] PI I/A Interface and FoxAPI "Bad Input" Fix +
CP60 reboot

Hi List,
        Thanks to Philip Pulas for his contribution about the Fox IA/OSI
PI
interface issues.  It was very timely, as we have seen some of the same
issues.  As a result, we are going to:

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

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.=3D20

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.

        The following scenario occurred on Friday, Apr. 8th, and I am
currently writing up a CAR to dig deeper into the instance, but am
interested in seeing if any other users have experienced anything like
this.
It is either an extreme coincidence or a potential bug/loophole in the
interface!
        At 4:30pm on Friday afternoon, (as is always the case with
serious
system problems), the PI administrator called me and said that PI was
receiving "Bad Input" from the Fox IA system on several critical points
used
for mass balance calculations. The points went bad at 11:05am the same
day.
Upon further investigation I discovered that all of the data points were
coming from one CP.  I looked through our System Monitor logs to see if
there had been any issues with the CP in question, (a FT CP-60).  There
had
been no system alarms.  I looked at the station loading compound and the
CP
wasn't heavily loaded or experiencing any overruns.  Finally I looked at
the
data points PI was having trouble with and the values were still
changing
and the IA historian was collecting data for them.
        Together, we decided to turn the PI points "Off Scan" and then
back
on again to correct the comm error, (this has worked in the past).  When
the
PI Administrator turned the points "Off Scan" I noticed the IA screen I
was
looking at, turned CYAN and the Sys top menu bar key began to flash red.
By
the time I opened SysMgmt the CP-60 was red and then turned yellow
showing
that both FT CP's had failed and then one began rebooting.  I watched as
all
of the ECB's/FBM's were brought back online and finally the control
returned
and I could again call up C:B:P values on the DM. The other CP60 did a
memory dump to its boot host, (dump is found at the following location):
/usr/fox/sysmgm/softmgr/dump/21CP03.1 through 21CP03.8
 and the shadow finally rebooted, which took about 36 minutes to
complete as
can be seen below in the list of System alarms received.
        The CP's most recent event captured in our System Monitor logs
that
was related to this CP was a checkpoint that occurred just over 24 hours
before the unplanned CP reboot:

04-07-05 14:01:23      0  SYSMON =3D3D SYS21A  21CP03  Software Manager

  SYSMON -00021 Checkpoint Successful

        As a result, the CP booted with all of the setpoints and block
valve
positions that were current when the checkpoint occurred a day before
the
reboot.  As one can imagine, things had changed and the processes
controlled
by this CP were bumped when the reboot occurred.  Lucky for us the
processes
controlled by this CP weren't some of the more hazardous ones in our
plant.
We haven't had a simultaneous failure of both FT CP's in several years
and
this is a very disturbing occurrence that we can't ignore.  As I said, I
am
writing a CAR and will send the dump files to Foxboro for analysis, but
am
interested to see if any other users have experienced anything like this
in
conjunction with turning PI points off scan?

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

04-08-05 16:46:16      0  SYSMON =3D3D SYS21A  21CP03  Error Protocol

  FTXSS  000080 Memory violation occured 00006C0FAF69

04-08-05 16:46:16      0  SYSMON =3D3D SYS21A  21CP03  Error Protocol

  FTXSS  000080 Memory violation occured 00006C0FA3EF

04-08-05 16:47:53      0  SYSMON =3D3D SYS21A  21CP03  Software Manager

  SYSMON -00003 Powerup reboot OK. ROM Addr =3D3D 00006C0FA3EF

04-08-05 16:48:01      0  SYSMON =3D3D SYS21A  21CP03  Station

  SYSMON -00041 Equipment on-line

04-08-05 16:48:12      0  SYSMON =3D3D SYS21A  21CP03  Software Manager

  SYSMON -00019 Database Load Successful

04-08-05 16:48:12      0  SYSMON =3D3D SYS21A  21CP03  Process =3D3D =
downld

  CIO_DB 000001 DATABASE DOWNLOAD: RESOLVE LINKAGES SUCCESSFUL=3D20

04-08-05 16:48:43      0  SYSMON =3D3D SYS21A  21CP03  Process =3D3D =
downld

  CIO_DB 000003 DATABASE DOWNLOAD COMPLETE =3D20

04-08-05 16:48:55      0  SYSMON =3D3D SYS21A  21CP03  Equip =3D3D =
21CP03

  SYSMON -00051 Equipment has been added on-line

04-08-05 16:48:55      0  SYSMON =3D3D SYS21A  21CP03  Equip =3D3D =
21A100

  SYSMON -00051 Equipment has been added on-line

04-08-05 16:48:55      0  SYSMON =3D3D SYS21A  21CP03  Equip =3D3D =
21A101

  SYSMON -00051 Equipment has been added on-line

..... and all of the rest of the FCM's and FBM's successfully came on
line!

04-08-05 17:10:36      0  SYSMON =3D3D SYS21A  21CP03  Software Manager

  SYSMON -00023 Memory Dump Successful. File name =3D3D 21CP03.*

04-08-05 17:12:05      0  SYSMON =3D3D SYS21A  21CP03  Software Manager

  SYSMON -00003 Powerup reboot OK. ROM Addr =3D3D 00006C0FAF69

04-08-05 17:12:13      0  SYSMON =3D3D SYS21A  21CP03  Fault Tolerant =
Exec

  SM_MSG -00046 Fault Tolerant Modules Now Married

04-08-05 17:12:15      0  SYSMON =3D3D SYS21A  21CP03  Equip =3D3D =
21CP03

  SYSMON -00056 Currently using PIO bus A


-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On
Behalf Of Pulas, Philip (GE Contractor)
Sent: Wednesday, April 06, 2005 11:13 AM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] PI I/A Interface and FoxAPI "Bad Input" Fix

All,
=3D20

Since I have noticed a lot of PI users out there, I just thought I'd
pass along this fix (at the bottom of this message) in case anyone
hasn't seen it yet.  This is from OSIsoft's tech support website.  We
have been experiencing this same issue for some time with one I/A system
and the fixes so far haven't really solved it, but this sounds like it
will.

=3D20

Thanks,

Philip Pulas

Tesoro Corporation

Golden Eagle Refinery

Martinez, CA

=3D20

Foxboro I/A Interface (fxbais) and FoxAPI "Bad Input" issue
04-Apr-2005

There is a known problem with the PI Foxboro I/A interface (fxbais) and
the FoxAPI that only affects I/A series control systems running version
6.5.1.


The Issue:=3D20
The issue is that for some of the lists, the FoxAPI does not receive an
initial value for the objects and returns a status of zero, which is
sent to the PI server as a "Bad Input." When the object changes, the
update goes to the FoxAPI and the interface sends the correct value to
PI. But, for values that don't change often (i.e. setpoints), the PI tag
can show "Bad Input" for a long time.

The issue appears to have been resolved with a Quick fix from Foxboro
(QF1005118). The description of the bug from Foxboro is:

"FM#27455/CAR1005118
The Foxapi uses OM open list functions add/activate to open data sets.
If Foxapi does an activate which involves more than 23 points, the
initial scan update for points after the 23rd may be missed.

The fix is not to the FoxAPI itself, but to the om_server process
(Object Manager) that sits under the FoxAPI."


Determining if you need the Quick Fix:

If you are getting a lot of "Bad Input" values from the Foxboro
interface, make sure:

1. You are running the current version of the FoxAPI (4.2.8)=3D20

2. You are running the current version of the Foxboro I/A Interface
(fxbais) 2.2.7.35. This version has some fixes for handling bad
inputs.=3D20

3. If both are current and you are still getting the Bad Inputs, then
you should contact Foxboro Customer Support and ask for the quick fix
"QF1005118 - om_server initial scan update fix" dated 11/05/03.

=3D20
=3D20
_______________________________________________________________________
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
=3D20
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         =3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Djoin
to unsubscribe:      =3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Dleave
=3D20
=20
=20
_______________________________________________________________________
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
=20
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
to unsubscribe:      =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
=20
=20
=20
_______________________________________________________________________
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
=20
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
to unsubscribe:      =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
=20
 
 
_______________________________________________________________________
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
 

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