Re: [foxboro] ICCAPI error
- From: "Doucet, Terrence" <tdoucet@xxxxxxxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Tue, 29 Aug 2006 07:59:36 -0400
Duc,
Sounds like a resource limit has been reached on a station, likely the =
host of the Control Processor, but it could also be the CP itself. Have =
the tech run the "show_params" command on the host to see if one of the =
limits has been reached.
If the tech knows about the Foxboro tool spic, there may be some help =
using that tool. If the station they were using to run the configurator =
is different from the host of the CP, then run show_params on that =
station, too.
Check the partition sizes free space. If /var/tmp gets full, then some =
configurators do not work well. Check memory and largest segment on the =
CP's STATION display to see that you do not hit limits.
Terry
-----Message d'origine-----
De=A0: foxboro-bounce@xxxxxxxxxxxxx =
[mailto:foxboro-bounce@xxxxxxxxxxxxx] De la part de Kevin FitzGerrell
Envoy=E9=A0: August 28, 2006 11:12 PM
=C0=A0: foxboro@xxxxxxxxxxxxx
Objet=A0: Re: [foxboro] ICCAPI error
Quoting Duc M Do <duc@xxxxxxxxxx>:
> At 09:32 AM 8/29/06 +1200, Kevin FitzGerrell wrote:
>=20
> >
> >Duc,
> >
> >ICCAPI says this is a "class=3D 1" error which means IPC error.
> >
> >IPC error=3D -29 is "abortion of connect request" (see E_ABORT_CON =
in
> the IPC
> >manual). The messages says c_chkio error, but I would guess that the
> error
> >originated with a c_send or c_receive call.
>=20
> Kevin,
>=20
> Thanks for the elucidation (though you lost me after the first
> sentence).
>
> I don't understand the error message (okay, hold the laughter!) since=20
> we can load this compound into an off-line CP without any problem, yet =
> cannot load it into an FSim simulator. I've sent it to my technical=20
> contact at SimSci-Esscor and we'll wait to see what she has to say.
>=20
> My original question still remains, and that is where I can find a =
list
>=20
> of error messages for ICCAPI (other than the terse listing in =
iccapi.h,
>=20
> thanks, David!) that also has some explanation for the errors. They =
are
>=20
> not in the ICCAPI document, obviously.
>=20
> Regards,
>=20
> Duc
Duc,
Sorry about that.
As far as I know there is no good coverage of possible error messages in =
the I/A
system in Foxboro's documentation. The ICC manual does a fairly good =
job of
trying to identify errors you are likely to see in the ICC though.
I can tell you how I think the message breaks down though (anyone who =
knows
better please feel free to step in with corrections - this is based on =
my
limited experience digging into other error messages):
FAIL 5 load 23FS01!C0704: Mon Aug 28 08:37:32 2006
iccdrvr.tsk log entry showing command and FAIL status of that command =
and the
time it occured.
-15=20
I'm having a little trouble with this "-15" - probably just means ICC =
error, see
/opt/fox/ciocfg/api/examples/iccdt.h
ICCload error:
iccdrvr.tsk says it the error return code was from an ICCload call. =20
class=3D 1
OK, this tells us that the error was an IPC error (different error =
classes are
listed in /usr/include/fox/iccapi.h). So, at this point we know the =
ICCload
failed, and the failure has to do with the IPC system. The=20
error=3D -29
This is the specific IPC error, E_ABORT_CON -29 "abortion of connect =
request".=20
The IPC manual covers what return values you should expect from =
different types
of calls.
text=3D icipcmsg: c_chkio error
icipcmsg is an undocumented internal function in iccdrvr (but based on =
the name
I'd guess it's used for passing ipc messages back to icc), and c_chkio =
is a
documented iccapi call. I would have expected an E_ABORT_CON response =
to a
c_send or c_receive rather than a c_chkio though.
After all that, it's still hard to tell what caused the problem. When =
you use
icc (or iccdrvr) to interact with a CP, an IPC connection is opened =
between your
workstation and the CP. It appears that this connection is failing.
Regards,
Kevin
=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
_______________________________________________________________________
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:
