In the CP, regardless of type, the process that goes along with the upload command in the CP's host is very low priority. Rightly so; we want the CP controlling the process first then sending non time critical data thereafter. If the CP is very busy, it will not send data every BPC and could be unavailable to respond with data for many seconds. The host that requested the upload has a watchdog timer that will eventually time out and abort. Remember that the CP's real time operating system is priority based. My first step would be the same as Jack's that is try it manually from ICC or whatever tool you normally use to build blocks. If it still fails then I would look at the loading on the STATION display and check for overruns block processing and Object Manager. If you get zero of these during the upload request then you know that it is not a CP loading issue however, if you get any values here, I would suspect loading. You also need to remember that sequence blocks present a non-periodic load on your CP, so they could affect your results. If not CP loading, then you have to check communication loading and the host loading. It is normal to take many minutes to perform an upload, possibly more than an hour. The issue has been discussed many times on this website but the resolution of the problem is complex and very low priority. It would seem to me that a checkpoint file, that is sent to the host very quickly in the CP270, contains all the required information and could be queried on the host processor to extract the same data that the upload function provides and it is likely that the fast hosts that we have today could perform this same function in seconds as opposed to an hour or so (for the existing upload command). The CP would not have to provide any data other than the checkpoint file. All the data processing would be done on the host. I'm not saying that this would be an easy task, rather just that it is possible. Terry > From: Jack.Easley@xxxxxxxxxxxx > To: foxboro@xxxxxxxxxxxxx > Date: Tue, 4 Oct 2011 15:19:26 -0500 > Subject: Re: [foxboro] ICCAPI Upload Error > > Does the regular upload work from the ICC GUI for these CPs? I still will be > clueless, but it might give a "wiser one" more info to know. > > Jack Easley > Sr. I&C Technician > Luminant Power, Martin Lake Plant > Phone 903.836.6290 > jack.easley@xxxxxxxxxxxx > > -----Original Message----- > From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On > Behalf Of duc.do@xxxxxxxxxxxxxx > Sent: Tuesday, October 04, 2011 3:12 PM > To: foxboro@xxxxxxxxxxxxx > Subject: Re: [foxboro] ICCAPI Upload Error > > Jack, > > While that's true for the upload for 10CP02, its sibling ZCP270, 09CP02, took > only a few minutes to upload but, alas, with the same upload error: > > Tue Oct 4 01:04:00 MST 2011 --- upload, shrink and checkpoint 09CP02 > DONE 1 OPEN 09CP02!: Tue Oct 4 01:04:03 2011 > FAIL 2 UPLOAD 09CP02!: Tue Oct 4 01:09:47 2011 -15 ICCupload error: > class= 20 error= 112 text= ICCupload: error 35584 on upload all > DONE 3 SHRINK 09CP02!: Tue Oct 4 01:09:50 2011 > DONE 4 CHECKPOINT 09CP02!: Tue Oct 4 01:09:56 2011 > DONE 5 CLOSE 09CP02!: Tue Oct 4 01:09:57 2011 > DONE 6 EXIT 09CP02!: Tue Oct 4 01:09:57 2011 > > Hmmmm.... > > Duc > _______________________________________________________________________ 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