Abort on Read Error option on CND block

Hi All,

I have a need to enable "Abort on Read Error" option in ALGO_OPTS for CND block throughout the whole database.

Can I do this directly in the Function Block Template and download all the related instances or should do it at class level modules ?

Is there any constraint on updating the Functinal block templates ?

Kindly let me know your comments and suggestions..

Thanks for your time....

Have a great day

Senthilkrishnan 

5 Replies

  • Unless you have already done this, you need to properly evaluate the use of the CND block throughout your site before deciding to take this on. To answer your original question first, I do not believe you can set the default function block value, but you can certainly set the default configuration for all module classes where you use the value, and failing use of classes, perform some clever bulk importing to semi-automate the process.

    Please take a look at this article that describes some of the interplay of the abort on read error, error opt, and inter-controller communications.

    emersonexchange365.com/.../inter-node-communication--cnd-act-calc-block-settings-what-exactly-is-the-difference-between-algo_opts--abort-on-read-errors-and-error_opts-uselast-option-are-these-two-alternatives-for-retaining-last-value-upon-lost-internod

    In my experience, simply enabling this option will be detrimental if your CND blocks provide interlock functionality. If the CND block output becomes False to indicate an interlock condition, then an Abort on Read error will freeze the output of the CND block in a "not interlocked" value (True), unless you have the ERROR_OPT set up to fail on the appropriate state, in this case False. If the CND block output becomes True to indicate an interlock condition, then the opposite must be true.

    However, ALGO_OPT and ERROR_OPT take effect immediately, and do not delay based on the TIME_DURATION threshold (which is used to prevent spurious trips). In other words, if there is a communication or calculation error that lasts for 1 scan, it will cause the CND block to immediately revert to the ERROR_OPT value which will cause an interlock. If ERROR_OPT is not setup to the Interlock value then it will weather the spurious trip, but it will also freeze on the last value if the error condition is permanent.

    Unless this is accounted for by either

    1. Having another time delay function block after the CND block but before the interlocking device function block
    2. Having a separate CND block for interlocking that watches for the error condition of the other interlock evaluating CND blocks (that uses a time delay),

    you will either have freezing outputs or potential spurious trips.

    Back to the original statement, a case-by-case evaluation of the use of the CND blocks should be undertaken if not already done, with the above topics considered, before deciding to universally apply the ALGO_OPT Abort on Read Error option.
  • Aside from the why’s or shoulds, see if you can write to enable from the graphics. If you can then create a simple FOR loop that reads from a text file that contains the parameters and value you want to write to. Run it with a wait between reads so it only runs once every second or so, then since the write came from the graphics you will be able to upload the changes. This is how I do almost all mass changes. Automate the automation.
  • In reply to Youssef.El-Bahtimy:

    Hi Youssef,

    Thanks for the reply..

    I also went through the link (Andre reply) …

    In our project as we have upgraded DeltaV to V14.3 and we have moved the interlocks from CND block to DCC, so we are planning to do the same activity for DCC block (Enabling Abort on Error & keeping the I_ERROR_OPT, P_ERROR_OPT & F_ERROR_OPT to Last value)

    On controller switchover test we found the following issue..
    In a loop where the Pump unit is in a one controller while the XV was in another controller a switchover of XV controller triggered XV interlock on PU which tripped the whole loop.

    Since this is new to me, can you please let me know your suggestion on this....

    I believe in above scenario, we have to enable this option to avoid trip of the plant...but can you please let me know an example of where we shouldn't enable or provide a time delay.... Is there a possibility of error condition (switchover) being permanent or present for a long time ??


    BOL also states below
    "
    Preventing an output disruption due to a controller switchover
    The following lists configuration options to prevent output disruption during a controller switchover:
    Select the Abort on Read Errors option in ALGO_OPTS in Condition function blocks. A read error occurs when a parameter in another controller cannot be read due to a communication error. When the Abort on Read Errors option is used and there is a read error, PRE_OUT_D of the Condition block retains its last value. The status of PRE_OUT_D and OUT_D remains GoodNonCascade during read errors when the expression aborts.

    Alternatively, leave the Abort on Read Errors option deselected and change ERROR_OPT to Use Last. When ERROR_OPT is Use Last, OUT_D retains its last value when there is a read error, but the status of OUT_D changes to BadNoCommNUV.

    When the interlock or tracking inputs are sourced in other controllers, avoid the use of the Passive if Bad and Track if Bad options in the Device Control and PID function blocks.
    "
  • In reply to Benji_Kidmose:

    Hi Benji...

    Thanks for your reply...
    I will check this option once we decide the modules that needs update...
  • In reply to Senthilkrishnan M:

    And to confirm Benji's suggestion, You can write to Algo_Opts of a CALC block on line and from Watchit. This means you can script a write from Operate and obtain the ability to upload this into the database.

    Andre Dicaire