Re: [foxboro] iccdrvrtsk upload error

  • From: steve.shimp@xxxxxxxxxxxxxx
  • To: foxboro@xxxxxxxxxxxxx
  • Date: Tue, 7 Mar 2006 13:05:01 -0500

Thanks for the suggestions.  The problem is very odd since I can
successfully upload some stations but not others, and it seems
inconsistent.  I am running iccdrvr.tsk on an AW that does not host any
stations, and again, some work fine and others fail.



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

foxboro-bounce@xxxxxxxxxxxxx wrote on 03/07/2006 11:36:22 AM:

> Steve,
> I would try to perform the upload first from the command line on the =
> host of your CP. Then you can be certain that you are not impeded by =
> network communications. =20
>
> After you get it working on the command line, then build a script and =
> make it work.  ( Batch file if host is Microsoft) =20
>
> The following was recently tested on an AW70 with controls
>
> cd /opt/fox/ciocfg/api
>
> iccdrvr.tsk  -o my_log.txt  =20
>
> (my_log.txt will contain success or error statements)
>
> open PWLBUG UPLOAD fox
>
> (insert your letterbug for PWLBUG)
>
> upload
>
> close
>
> exit
>
> Depending on the block load of your CP, this could take a long time.
> Check the work file (PWLBUG.wf) date to see if it is refreshing to
> the current time / date, then you know it is working.
> On MS host there are some batch file restrictions that will cause you
> to build two files, call them UL.bat and  UL.dat
>
> UL.bat
> -------
>
> cd \opt\fox\ciocfg\api
> call iccdrvr.tsk -o my_log.txt -i ul.dat
>
>
>
> ul.dat
> -------
>
> open PWLBUG UPLOAD fox
> upload
> close
> exit
>
>
>
> I have not written code for a Unix host, but the same concept should =
> apply.
>
> Regards,
>
> Terry
>
>
> -----Message d'origine-----
> De=A0: foxboro-bounce@xxxxxxxxxxxxx =
> [mailto:foxboro-bounce@xxxxxxxxxxxxx] De la part de =
> steve.shimp@xxxxxxxxxxxxxx
> Envoy=E9=A0: March 7, 2006 11:03 AM
> =C0=A0: foxboro@xxxxxxxxxxxxx
> Objet=A0: Re: [foxboro] iccdrvrtsk upload error
>
> I am simply feeding "upload" to the iccdrvr.tsk, not "upload all".
>
> Could the upload be failing because there is a change occurring - say =
> t=3D
> o a
> string variable - during the upload?
>
>
> 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
>
> foxboro-bounce@xxxxxxxxxxxxx wrote on 03/07/2006 10:20:32 AM:
>
> > Sascha Wildner wrote:
> > > steve.shimp@xxxxxxxxxxxxxx wrote:
> > >
> > >>I am getting the following error when trying to automate a CP =
> uploa=3D
> d
> with
> > >>the iccdrvrtsk:
> > >>"ICCupload error class =3D3D 20 error =3D3D 112 text =3D3D =
> ICCupload: err=3D
> or -30 on
> > >>upload all"
> > >
> > >
> > > And damn right it is :) because you probably don't have a compound
> > > called 'all'. Error -30 is EQEMPTY ("Change queue is empty", see
> > > /usr/include/fox/om_ecode.h).
> > >
> > > iccdrvr.tsk documentation (B0193NE) will tell you that the UPLOAD
> > > command will only work on a block or a compound but not on a CP.
> > >
> > > Known bug, I don't think it will ever be fixed. No, wait! It's
> > > documented, hence it's a feature. :)
> > >
> >
> > Oops, sorry for the noise. :)
> >
> > In fact, the documentation says just typing "upload" should be =
> enough=3D
>  to
> > upload all compounds in the station. Did you type "upload all" or
> "upload"?
> >
> > --
> > Sascha Wildner
> > erpicon Software Development GmbH
> > Neusser Str. 724-726
> > 50737 K=3DF6ln
> > Germany
> >
> > Phone: +49 221 9746069
> > Fax:   +49 221 9746099
> > eMail: swildner@xxxxxxxxxx
> >
> >
> > =
> _____________________________________________________________________=3D
> __
> > This mailing list is neither sponsored nor endorsed by Invensys =
> Proce=3D
> ss
> > Systems (formerly The Foxboro Company). Use the info you obtain here =
> =3D
> at
> > your own risks. Read =
> http://www.thecassandraproject.org/disclaimer.ht=3D
> ml
> >
> > foxboro mailing list:             =
> //www.freelists.org/list/foxbo=3D
> ro
> > to subscribe:         =
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D=3D
> join
> > to unsubscribe:      =
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Dl=3D
> eave
> >=3D
>
>
> =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
>

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