Re: [foxboro] Unreliable API calls.

  • From: steve.shimp@xxxxxxxxxxxxxx
  • To: foxboro@xxxxxxxxxxxxx
  • Date: Mon, 23 May 2005 07:10:09 -0400

This is probably due to loading since this bit of code works most of the
time.  Are you seeing OM overruns on the station hosting C1SETUP?

We use C programs to push information into control blocks and have found
that when the code references the same block repeatedly, without any sleep
statements, information will be lost or unresolvable.  When this happens,
the CP will report OM overruns.


Steve Shimp
Maintenance & Systems Engineer
ExxonMobil Paulsboro Lube Plant
phone: 856.224.5059      cell: 609.820.8501      fax: 856.224.5030
email:  steve.shimp@xxxxxxxxxxxxxx


                                                                                
                            
                      "Schouten, Frits JF"                                      
                            
                      <Frits.Schouten@bluescop          To:      
<foxboro@xxxxxxxxxxxxx>                    
                      esteel.com>                       cc:                     
                            
                      Sent by:                          Subject: Re: [foxboro] 
Unreliable API calls.        
                      foxboro-bounce@freelists                                  
                            
                      .org                                                      
                            
                                                                                
                            
                                                                                
                            
                                                                                
                            
                      05/19/05 06:42 PM                                         
                            
                      Please respond to                                         
                            
                      foxboro                                                   
                            
                                                                                
                            
                                                                                
                            



Whow, text got a bit messed up with '=3D' and '=3D20'
The logfile snipped should perhaps be read like this:

15/05/2005:12:52:30 - nextladle :
   CBP:C1SETUP:NEXT_LADLE.IO0002, ValType:6, Error:1

15/05/2005:12:52:30 - nextladle :
   CBP:C1SETUP:NEXT_LADLE.RI0001, ValType:3, Error:1

15/05/2005:12:52:30 - nextladle :
   CBP:C1SETUP:NEXT_LADLE.RI0002, ValType:3, Error:1

15/05/2005:12:52:35 - nextladle :
   CBP:C1SETUP:CAST_LADLE.SN0008. Error: 34

15/05/2005:12:52:39 - nextladle :
   CBP:C1SETUP:CAST_LADLE.SN0003. Error: 34

Frits.

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx
[mailto:foxboro-bounce@xxxxxxxxxxxxx]On Behalf Of Schouten, Frits JF
Sent: Friday, 20 May 2005 10:37
To: Foxboro DCS Mail List (E-mail)
Subject: [foxboro] Unreliable API calls.


Hello Gang,

I have a bit of an issue with API calls and in particular the one offs li=
=3D
ke uread and uwrite.
They are extensively used within our 'C' applications to get the odd few =
=3D
values to and from control blocks.
A logfile snippet:
-------
15/05/2005:12:52:30 - nextladle : CBP:C1SETUP:NEXT_LADLE.IO0002, ValType:=
=3D
6, Error:1=3D20
15/05/2005:12:52:30 - nextladle : CBP:C1SETUP:NEXT_LADLE.RI0001, ValType:=
=3D
3, Error:1=3D20
15/05/2005:12:52:30 - nextladle : CBP:C1SETUP:NEXT_LADLE.RI0002, ValType:=
=3D
3, Error:1
15/05/2005:12:52:35 - nextladle : CBP:C1SETUP:CAST_LADLE.SN0008. Error: 3=
=3D
4=3D20
15/05/2005:12:52:39 - nextladle : CBP:C1SETUP:CAST_LADLE.SN0003. Error: 3=
=3D
4=3D20
-------

Error 1, according to foxdoc B0193UD appendix D, means:
1 noaccs Unable to access object (object-level error).
Object not found; check "name" argument of FoxAPI call for
typographical=3D=
20
error; check I/A Series database for existence of object and create,
if necessary.

Error 34, according to foxdoc B0193UD appendix D, means:
34 nostg String not found.
Object(s) not found; check "name" argument of sread() for typographical
error; check I/A Series database for existence of object and create it,
if necessary.

But the objects do exist and the program only fails like 2-3 times a day =
=3D
while it runs well over 150 times a day.

And if the program then tries to write back to I/A about the issue it get=
=3D
s yet another error:
15/05/2005:12:52:43 - nextladle : CBP:C1SETUP:COMMON.II0001, ValType:6, E=
=3D
rror:-35=3D20
15/05/2005:12:52:43 - nextladle : CBP:C1SETUP:COMMON.II0002, ValType:6, E=
=3D
rror:-35=3D20
Error -35, according to foxdoc B0193UD appendix D, means:
ENOTACTIVE (-35) Caller not active with IPC.

My question really is, why are API calls so unreliable.=3D20
Some years ago all programs got changed from OM calls to API calls and ev=
=3D
er since I have this issue with reliablility.
The host is running V7.1 with Fox API Version 4.2.8.


Regards,
Frits Schouten=3D20
Process Computing Department=3D20
New Zealand Steel Ltd



EOM=3D0A=3D0ANOTICE - This message and any attached files may contain inf=
orma=3D
tion that is confidential and/or subject of legal privilege intended only=
=3D
 for use by the intended recipient. If you are not the intended recipient=
=3D
 or the person responsible for delivering the message to the intended rec=
=3D
ipient, be advised that you have received this message in error and that =
=3D
any dissemination, copying or use of this message or attachment is strict=
=3D
ly forbidden, as is the disclosure of the information therein. If you hav=
=3D
e received this message in error please notify the sender immediately and=
=3D
 delete the message.
=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:             //www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
=20


EOM=0A=0ANOTICE - This message and any attached files may contain informa=
tion that is confidential and/or subject of legal privilege intended only=
 for use by the intended recipient. If you are not the intended recipient=
 or the person responsible for delivering the message to the intended rec=
ipient, be advised that you have received this message in error and that =
any dissemination, copying or use of this message or attachment is strict=
ly forbidden, as is the disclosure of the information therein. If you hav=
e received this message in error please notify the sender immediately and=
 delete the message.


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