Resolving Blue Triangles

I have inherited a system with over 30 modules that have blue triangles. I am wary about downloading the modules to fix the issue without knowing what the difference between what is in the controller and database. Is there a way to see why the system thinks the module needs a download (the system does not currently have Version Control)? If not, what checks should I perform before I download the modules in order to reduce the possibility of a process upset?   Thank you in advance for input.

7 Replies

  • Upload before downloading, check every changes one by one during the upload.

  • Usually what I do is:

    1) See what the control modules will directly change as far as I/O (i.e. valves, outputs, etc).  Valves and such usually go to default position.  PID type modules usually will ride through the download pretty well.

    2) Check references on the control module to what links to it or what's dependent on it.  Other modules might go interlocked or do something based on the PV, etc.

    3) In the controller under assigned modules, do an upload (you don't have to accept them, just need to know) and see if you need to upload those online changes to the database.

    Hope that helps.

  • Blue triangles indicate a change was made to the database not yet committed on line (not the other way around). Uploading would erase those (parameter only changes) that may have been made with intent and wouldn't necessarily catch everything. I think the upload parameter log should be used as a guide and not wholesale, either way. Additionally, architectural change discrepancies cannot be uploaded. 

    If you take regular exports, an export of the modules prior to their changed date compared to a current export will be more informative.

     

    Youssef El-Bahtimy | Systems Integration Technologist
    PROCONEX | 103 Enterprise Drive | Royersford, PA 19468 USA
    Proconex Office: 610 495 2970 | Cell: 267 275 7513
    Youssef.El-Bahtimy@ProconexDirect.com

    ------
    Original message ------
    From: Badraa Lkhagvaa
    Date: 2013/08/23 18:51
    To: DeltaV@community.emerson.com;
    Subject:RE: [EE365 DeltaV Track] Resolving Blue Triangles

    Upload before downloading, check every changes one by one during the upload.

     
  • In reply to Youssef.El-Bahtimy:

    Mr.Youssef you're right. tklatt, use version control.

  • It won't tell you everything, but view Control Studio ONLINE. Items removed since the last download won't be obvious, but items created since download will have no values.
    Use the upload function (but don't actually upload any values unless you're sure) to check for differences, then decide (or consult someone) which values are correct.
  • In reply to andrewduffy:

    Some thing you can do is determine when the last download of the module was performed.  DeltaV Explorer will tell you when the module was last modified, and by who.  You can search the Event CHronicle to determine when the module was downloaded.  From that date, you can try to find an Export that might be holding the exact configuration downloaded.  The module may have been changed multiple times without download, so you need to have a sense of whether the FHX file you have represents what was downloaded.

    Note that when you upload in DeltaV, you are uploaded online changes made to the module from DeltaV Operate, Control Studio, Watchit.  The DeltaV Communciation layer records these parameters into a special file on the Pro Plus to facilitate their upload into the database.  There typical hundreds of parameters in the control module, so rather than read all these and compare with the database, the upload utility captures those user changes for later upload.  When uploading, only select those parameters that should be preserved in the database, and discard normal operator changes.  When you do upload, the system discards all the parameters not selected so they don't continually appear on subsequent uploads.

    One thing to remember, the blue triangle can be set by workstation related data changes. If you change the module description or assigned displays, the controller logic is not changed, but a download of the module is required to clear the flag.  

    VCAT provides detailed history of all changes.  If you don't have that, keeping good exports provides a means of manually comparing configuration changes, not with some challenge.

    Finally, if you cannot easily identify what is chagned (Online view shows everthing, no red X's), you should still be good to download.  IO blocks preserve their mode and status values for bumpless downloads.  However, each configuration can be different, and the parameter download behavior setting may initialize variables on download.  If you don't know how your modules behave on download, proceed cautiously and check the parameter download behavior.  The default is Preserve Critical Block values.  This should allow the module to pickup from its last execution, especially since an online view does not show Red X on any parameters.

    Good luck

    Andre Dicaire

  • In reply to Andre Dicaire:

    Is there any way to check the database against the files/scripts in the POWERUP directory?  Has anyone cracked that nut yet?