DC/CND vs DCC/EDC blocks

Now that DCC/EDC blocks exist. Should I use the DC/CND block combination for Discrete Control?

Do I need to take Controller Loading into consideration?

Does the new DCC/EDC blocks reduce controller loading or increase controller loading compared to the DC/CND blocks?

Does anyone have any comments or experiences they would like to share?

  • The EDC and DCC blocks deliver significant controller loading improvements over the traditional approach with CND, BFI and supporting logic. They also deliver more functionality as well.

    But of a system with existing standards, one has to weigh the benefits of changing those standards, at least creating some new designs for new projects, and leave your commissioned, tested/proven configuration alone. After all, if it works, by change it.

    On a new system, I would use the DCC block and AT block for the interlock functions rather than the CDN, BFI combination. You can use the DCC with a DC or an EDC. The EDC has additional inputs to support the Forced Setpoint logic in the DCC block. The EDC also has built in run timers. It would be my first choice for Motors.

    Controller loading is always a concern. More efficient code either means more modules or faster execution. CPU is a resource of the system and conserving it means fewer controllers. One challenge with CPU on new systems is the need to reserve CPU capacity for future use of the Spare IO capacity. Designing a controller and IO cabinet for 40% spare and have only 10% CPU left in the controller means you will not be able to use that IO. Most RFP's call for 30 to 50% free CPU upon delivery. If the control philosophy were to estimate full CPU usage at 800 IO, then a specification calling for 50% cpu would mean a limit of 400 IO in the design. Now we need two controllers for 800 IO. This is typical and a challenge. You might choose to use 300 as your limit to ensure you don't exceed the 50% cpu free time.

    These new blocks redefine the IO capacity of DeltaV controllers, so if you go forward with them, you will see CPU loading benefits for sure.

    With the built in tracking of bypasses and first in, and reporting to the Event Journal all built into the blocks, these will also simplify the code required to achieve what used to require CALC blocks and other configuration. So I would definitely recommend their use, going forward.

    Andre Dicaire

  • In reply to ShawnHakim:

    Just keep in mind that using the DCC with a DC block will have some limited functionality as only Interlocks and Permissives will be possible in a "standard" method.

    The DC block can only interlock to the Passive state (defined by named set 0 value) while the DCC supports Interlocking to any state.

    • This means the DCC/I_STATE# parameters will NOT be used regardless of how configuration is set on the DCC block.
    • I would suggest creating new display to remove the I_STATE# indication when using with a DC block as it would be misleading if this is configured to something other than what the passive state is.

    All the DCC Permissive functionality (Permit or Prevent) can be used with DC.

    The DCC Force Setpoint functionality can NOT be used with DC unless some special logic is created in addition to the DC and DCC blocks.