Chad,

An omread error indicates that the ICC was unable to connect to the source
of the data, i.e., the block of interest.

This could happen for a lot of reasons (this list is not complete):

1)      The CP is too busy to respond to the request for data
2)      The CP lacks the resources to respond (there are all kinds of
resources)
3)      There is too much broadcast traffic on your network and the open
request is getting dropped.
4)      etc.

What type of CP is failing?

There are three types of uploads:

1)      Block only
2)      All blocks in a compound
3)      All blocks in a station

Which upload type is failing?

Are you on FoxWatch? If so, have them test for Nodebus loading and
broadcasts in general. If you are not on FoxWatch, call your FS rep and
explain the situation and ask for an on-site analysis.

This is where I would start.


Regards,

Alex Johnson
The Foxboro Company
10707 Haddington
Houston, TX 77043
713.722.2859 (v)
713.722.2700 (sb)
713.932.0222 (f)
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 


        -----Original Message-----
        From:   Airhart, Chad M. [SMTP:[EMAIL PROTECTED]]
        Sent:   Friday, May 05, 2000 5:20 PM
        To:     'Foxboro DCS Mail List'
        Subject:        RE: save_all.sh update information

        We have been having a problem uploading for the past year.  We have not
        successfully done an upload by hand through the ICC in that time. We have
        a CAR out but as of yet have no help from Foxboro.  The upload's fail at
        random points in the process.  The errors in the log file are an omread()
        timeout, errors on various parameters and then the upload aborts. At first
        we were told we could not do uploads with API running but stopping API and
        trying did not resolve the problem.  This is very frustrating because
        everytime we change a PID the tuning parameters go back to initial unless we
        change them by hand in the block.  We would like to do automatic uploads and
        savealls but cannot proceed until we can at least do them manually. Any
        help would be greatly appreciated.

        Chad M. Airhart
        Instrument and Control Engineer
        Equistar Chemicals, LP
        Off. (361)572-2568
        Pgr. (361)270-2214 Alpha paging at  [EMAIL PROTECTED] or
        www.mobilecomm.net.   
        Fx. (361)572-2541

        > -----Original Message-----
        > From: Stan Brown [SMTP:[EMAIL PROTECTED]]
        > Sent: Tuesday, May 02, 2000 12:08 PM
        > To:   [EMAIL PROTECTED]
        > Subject:      save_all.sh update information
        > 
        >       For those of you using the save_all.sh script, and for anyone else
        > who
        >       is lucky :-( enough to have Spectrm Interface Processors, we
        > aparently
        >       have discoverd a bug which prevents uploading these units.
        > 
        >       I appears that an upload, wither from the Integrated Control
        >       Configuratior, or from a script will fail if you attempt to uplaod
        > the
        >       entire configuration for the SIP's. The problem appears to be an
        >       inabulty up sucesfull upload soem of the paramters in the ECB.
        >       Uploading any compunds other than the ECB seems to work fine, but
        > even
        >       doing the ECB by itself fails.
        > 
        >       Since the ECB is uploaded by the default implied "all" of the UPLOAD
        >       command used in the save_all.sh script, this will cause it to fail
        > to
        >       corectly upload the entire SIP. 
        > 
        >       There also appear to be some problems in the sciprts detection of
        >       whether an upload suceded or not. I need to look and see if the
        > Foxboro
        >       utiliy being used returns a useful return code, or not. If it does
        > we
        >       can use this to determine success/failure of the
        >       upload/shrink/checkpoint/saveall sequence.
        > 
        >       Just a heads up.
        > 
        > -- 
        > Stan Brown     [EMAIL PROTECTED]
        > 843-745-3154
        > Charleston SC.
        > -- 
        > Windows 98: n.
        >       useless extension to a minor patch release for 32-bit extensions and
        >       a graphical shell for a 16-bit patch to an 8-bit operating system
        >       originally coded for a 4-bit microprocessor, written by a 2-bit 
        >       company that can't stand for 1 bit of competition.
        > -
        > (c) 2000 Stan Brown.  Redistribution via the Microsoft Network is
        > prohibited.
        > 
        >


-----------------------------------------------------------------------
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

Reply via email to