Hella all,
We got a message from Emerson with the following issue:
DC/EDC block outputs get written on a “one shot” basis on a change of state when those outputs are configured internally to the block and all outputs have good status. If an output has bad status, it’s possible for a change of state to not occur, preventing new output values from being re-written. This may also prevent the operator from manually changing the state of the function block, requiring manual operator intervention at the physical device.
The following conditions must all be true to be susceptible to this issue:• Configurations utilizing DC or EDC blocks with outputs tied directly to I/O channels. (Wired outputs to Discrete Output function Blocks are not susceptible.)• More than one output is configured and assigned directly within the DC/EDC block.
Using CHARM I/O• The status of an associated Discrete Output CHARM goes bad for any reason as reported by DeltaV.Using Conventional I/O• DC/EDC Block Outputs are tied to the same Conventional DO Card and one of the channels has a field wiring fault where LINE_FAULT_DETECTION is enabled for the affected and associated channel.OR• DC/EDC Block Outputs are tied to Conventional DO channels spanning multiple cards with one of the cards having a bad status affecting the channels as reported by DeltaV.
However, we don't know if it is relevant for us.
I don't understand the statement:
Configurations utilizing DC or EDC blocks with outputs tied directly to I/O channels.
In our software we are using classes, which contains DC functional blocks in which the IOs are defined (see picture).When we are configuring our DC modules as shown below, do we need to modify our modules?
Hopefully somebody can reply on this.
Thank you in advance.
Best regards,
Elwin
It would appear you are referring to KBA NK-2400-0421 and the associated safety Notice SNDV2024003.
You should fully read and understand the Safety Notice and KBA and seek assistance from a subject matter expert (Emerson support or other) if you have any concerns.
Having said this I shall offer some advice.
I am not providing any recommendation as to whether you should or should not deploy the workaround proposed in the KBA. I'm simply answering your direct question and to that question the answer isn't a simple answer YES or NO, but I shall offer guidance on how you should go further to confirm if you are or are not affected and whether you might require the workaround in the interim period before a DeltaV product software solution is available from Emerson (which was being prioritised by Emerson for v14 and v15 .FP and .LTS as of 06-Nov-2024).
You appear to be using Conventional I/O and Card 17 channels 13 and 14 in that particular control module, As both channels are on the same card you will have to go further to determine if your application is affected by checking if Line Fault Detection is enabled on those two particular channels. If LINE FAULT DETECTION isn't enabled on those two channels the KBA would lead you to believe you are okay and don't require the workaround. if LINE FAULT DETECTION is enabled on either of those channels then your application of the DC function block in this module is susceptible to the issue.
Note you should also check all occurrences of DC and EDC usage within all of your DeltaV systems Modules and determine if there are any DC/EDC blocks in those modules with more than 1 output configured within the DC / EDC IO_OUT_X parameters (as per the subject module you've shown). After making that determination you then also need to assess the output signal channel type and configuration for each module to determine if the usage matches any of the cases identified in the "How do you know if you are affected?" section of the KBA.
Note you can use the tool referenced in the KBA to perform the first part of that task, but determining whether each module identified with 2 or more output channels in the output of the tool matches any of the scenarios in the section "How do you know if you are affected?" that's a manual activity.
Note you should you decide to deploy the workaround to your module(s) you should also consider the additional minor loading impact the addition of the DO function blocks proposed as the workaround will have on your DeltaV controller(s). It's unlikely to be insignificant for a single module change but for many module is a single controller it may just push your controller over a threshold from an acceptable loading state to a less acceptable loading state.