• Not Answered

SX Controller – EDC block CAS_IN_D working difference Between Versions

Hello All,

We have observed a difference in SX Controller behavior between DeltaV versions 14.3.1.7332 and 14.3.1.7412 related to EDC / CAS_IN_D functionality.

When the CAS SP Track device option is disabled, EDC1 / CAS_IN_D is not modifiable in DeltaV 14.3.1.7412 during the LO Mode ( Interlock active ). However, in the previous version (14.3.1.7332), CAS_IN_D could be modified under the same conditions.

In our pump logic, the CAS SP Track option is not enabled, and the EM HOLD command is used to drive CAS_IN_D to the passive state during interlock activation. After upgrading to DeltaV 14.3.1.7412, we noticed that when the EDC block enters LO mode, the HOLD logic is unable to write to CAS_IN_D.

Has anyone experienced similar behavior or can share insights on this change?

Thank you,
Prasanth

• controller
• DeltaV #DCS
• 14.3.1

Prasanth Gopalakrishnan Nair

• 15 Dec 2025 9:42 AM
• Cancel

4 Replies

• Manuel Behrens

  

  • 15 Dec 2025 11:28 AM

  Hi Prasanth,
  
  we are facing a similar issue. Maybe it's connected to NK-2300-0376?
  
  All the best,
  Manuel

  • Cancel
• Matt Forbis

  

  • 15 Dec 2025 6:48 PM

  In reply to Manuel Behrens:

  It's described as Issue #3 in the KBA that Manuel has linked too. There have been a few different issues around trying to resolve how the EDC block handles CAS_IN_D and Setpoint Write errors. I know that Matt Stoner has been working alot with these and can probably provide a bit more insight, but I know he is out for the holidays right now.

  • Cancel
• Andre Dicaire

  

  • 17 Dec 2025 9:55 PM

  In reply to Matt Forbis:

  We worked through multiple iterations of the EDC block with respect to the SENTINEL parameter and the Write_Error_Act flag. It was painful, also because the documentation did not align with released functionality/behavior. The Write_Err_Act and SENTINEL parameters are new, if not explicitly used, their status and behavior don't matter. The big issue is categorizing continuous writes (Wired connection) as a problem and blocking the parameter change in the block. This caused working configurations to break.
  
  You could ask why the DO block allows the CAS_IN to be wired, but the EDC now says it should not be wired. I can't think of a reason why these have to be different, but the fact is they are different. The DO is an IO block and does not have an intermediate layer of interlock logic, or confirmation logic with PV. All we can do is understand how it works and configure with those constraints.
  
  I would suggest that the "recommended' approach is to write by exception and only when conditions are right for success. That is, the Mode.Actual should be correct and any other conditions for a successful result are confirmed. Adding a delay expression to the CAS_IN write Action would avoid the write error and preform a successful write once Mode.Actual becomes CAS. I'm sure there are other changes you would need to accommodate with respect to timing of changes.
  
  The one thing you can control is your configuration, both in functionality and timeline to implement a change. Changing the Sequence to verify mode before writing Cas_In will work with both versions of firmware and be more resilient.

  Andre Dicaire

  • Cancel
• Matt Stoner

  

  • 5 Jan 2026 2:58 PM

  In reply to Andre Dicaire:

  The reason the EDC/CAS_IN_D can't be wired is because of the Setpoint Tracking option couldn't work if something wired while the DO/CAS_IN_D does allow it to be wired because it doesn't have a SP Tracking option.
  
  There has been a couple hot fixes recently for the EDC block so make sure you have the latest controller hotfix installed. There still might be more coming in the future but I believe that issue with writing when LO was addressed.

  • Cancel