Recent Control & Safety Systems Discussions
Similar Posts
DeltaV CND Block Timmer Error
Analog values compared in CND Block.
AT block equivalent of ILK_SHUTD_ACTIVE parameter for EDC block?
Abort on Read Error option on CND block
usage of Diagnostic status inside CND block
Share

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?

ShawnHakim
  • Andre Dicaire
    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

  • ShawnHakim

    In reply to Andre Dicaire:

    Andre,
    I really appreciate the detailed response. I used to work for an Emerson LBP and I was familiar with the DC/CND blocks.
    I have a new DeltaV system that has been installed at our site. I started using the DC/CND blocks for the first phase of the DeltaV configuration (just because I am not familiar with the new blocks and the configuration had to be done quickly). We are now installing new equipment and the System is quikly expanding. My only other concern was confusion for the operator, but it looks like the front end dynamos and faceplates don't look to much different.
    So if it is better on controller loading, and I do agree they are a lot more simple to configure and understand I guess switching to the new blocks is the way to go.
    Again I appreciate the response.
    Regards,
    Shawn Hakim
  • Matt Stoner

    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.

  • ShawnHakim
    I decided to see what the Load Estimator would determine. (didn't realize one existed till today) I created module examples for 3 types of modules for the Load Estimator.
    1. "edc" : which is an edc block with 2 inputs and 1 output, and a DCC block with 4 interlocks
    2. "DC" : which is a DC block with 2 inputs and 1 output, and a DCC Block with 4 interlocks
    3. "dc_cnd4" : which is a DC block with 2 inputs and 1 output, 4 CND blocks, 1 BFI, 1 AND block, 1 OR block, and 1 NOT block.

    I put that there are 100 of each of the above type of module running in the controller at a .5 sec scanrate. This is what the estimator showed.

    Module count Memory CPU% usage
    edc 100 1757 10.8288571238518

    dc 100 1478 8.56828540563583

    dc_cnd4 100 1098 7.67400041222572

    it actually shows that the DCC uses more resources than the CND/BFI combination. I do still think the DCC is worth the extra resources even if the above is true. I wonder if the load estimator is incorrect though. I would of thought the multiple blocks would of used up more resources.
    Just an interesting view.
  • Matt Stoner

    In reply to ShawnHakim:

    The numbers should be "similar" with the differences being the other functionality that is supported or not supported. The loading savings comes from the ability of the DCC block to have 4 interlocks defined in a class but set to use 0 at the instance.

    Change the I_USED_CND to 0 on your EDC and DC test modules with DCC and see what the numbers show.
  • Andre Dicaire

    In reply to ShawnHakim:

    The improvement in CPU usage is as compared to PCSD equivalent Module class designs, which include various additional features included in the blocks.
    Bypass monitoring: checking the Disable status on CND blocks and some CALC logic to generate a LOGEvent
    Motor Runtime: Timers and logic to record runtime of motor.
    Number of Configured Interlocks: Classes have fixed block count while DCC can define number of interlocks used (Matt hit this one)
    Permissive and Forced SP logic: Built into DCC.

    product testing found significant CPU reduction, up to 50% on applicable module types. Also note that for the same logic, you get additional functionality, such as On and Off delay on interlock. Extensible parameters that help manage the HMI environment.

    Finding that the DCC and EDC create equivalent loading as compared to the basic CND/BFI approach found in the DeltaV default Module Template library is encouraging as most libraries include a lot of custom code to accomplish the features of these blocks. your test did not include any of this additional functionality, so you get that for "free".

    Appreciate you sharing your results.

    Andre Dicaire

  • Alex Lutz

    In reply to Matt Stoner:

    I'm a little confused by how to interpret the "passive" state for the EDC. I want to change the named sets to more meaningful names for both the DCC and the EDC (i.e. START/STOP instead of State 0/State 1) and I need some guidance in matching everything up.

    1.) it does not look like there is any way to change the named set associated with I_STATE on the DCC. Can someone confirm? This renders the function block faceplate associated with the DCC much less useable as it displays the i_state for each interlock condition, but can only show "State 0", "State 1",...

    2.) The SP_D and PV_D named sets are straight forward. I can easily understand how to copy this named set out and rename State 0 to STOP and State 1 to START. They also both include an "Undefined" named state at a value of 255.

    My problem is with interpreting the EDC1/INTERLOCK_STATE named set. I would have expected this to be read the same as the SP or PV named sets, but now the UNDEFINED state is changed to PASSIVE at value 255. This  matches the DCC block. So if I update the INTERLOCK_STATE named set, should I make sure to leave that PASSIVE at 255 in there? is that the only way I can use an I_LOCK state of PASSIVE?

    I see that I can update the PASSIVE_STATE parameter, but it only allows me to select State 0 or State 1 as the PASSIVE_STATE, not any other state.

    So what all should be changed on a DCC/EDC block to use a more meaningful named set?

  • TreyB

    In reply to Alex Lutz:

    did you create a new PASSIVE STATE named set as well? You should be able to select any state as passive. The way I have it set up is yes, keep the 255=Passive for INTERLOCK STATE.. then I decide what my PASSIVE state is through the named set, which includes all the same states as my SP and PV
  • Alex Lutz

    In reply to TreyB:

    yeah i tried creating a new named set to put into the EDC/PASSIVE parameter. No matter  if i create a new named set or use the default one, it will only allow me to pick the first two named sets as the PASSIVE state.

    i guess this isn't that big of a deal. I can just select the I_STATE to be something over than passive on the DCC. I can't think of the reasoning for this though?

    so if i want to create a new named set, it would be best to create a new named set for the following: SP_D, PV_D, PASSIVE, INTERLOCK

    I found out that you can change the named set for I_STATE_n, but only after you add the condition. you can't set a default named set for the whole DCC such that, that named set is used each time an additional condition is added.

  • Matt Stoner

    In reply to Alex Lutz:

    Yes they can be fully customized provided they have the correct number of entries within the named set. If it doesn't match the number of values it won't be a valid selection.

    For states you don't have, Give a unique name and uncheck Visible and User Selectable.

    Named Set formats - EDC Parameter(s) (Required Values)

    CAS_IN_D, FV_D, PV_D, SP_D (0-5, 255) Note: 255 is Undefined meaning inputs not met for any states in state mask
    FAILURE_STATE, PREV_FAIL_STATE (0-18)
    INTERLOCK_STATE (0-5,255) Note: 255 is Passive State which means whatever is configured for PASSIVE_STATE is where interlock will go
    PASSIVE_STATE (0-5)
    PV_STATE (0-11)

    Here is Example of the discussed Passive and I_State named sets for a Forward/Reverse Motor

       

    All of this is documented in Books Online: Configuration -> Function Blocks -> Logical blocks -> Enhanced Device Control (EDC) function block -> Enhanced Device Control function block execution

  • Alex Lutz

    In reply to Matt Stoner:

    thank you for the walk-through, that makes it much clearer. it's a lot of named sets to create, but it all makes sense. I figured it would be best to continue this EDC info message chain with one more question so that users can reference it all in one place in the future:

    Can you explain what is happening in the below screenshot? Books online indicates that OUT_D will show the worst case status of F_IN_Dn and F_OUT_Dn. In the screenshot below, F_IN_D1 is "BAD/Device Failure" yet OUT_D remains "Good/non-cascade".

    Note: IGNORE_PV is set to FALSE and SIMULATE is DISABLED.

  • Matt Stoner

    In reply to Alex Lutz:

    You don't have any output I/O defined so I'm wondering what you have in the State Mask for Outputs. I would suspect it is because there is no outputs defined?
  • Alex Lutz

    In reply to Matt Stoner:

    same results with and without i/o defined.

    i can call it into GSC if you think it is an actual problem so they can log it. I figured I'd enhance books online with this thread with this question if there was an easy answer.

  • Matt Stoner

    In reply to Alex Lutz:

    In this case I don't think that BOL is accurate, You can log a call with GSC to start that process to figure that out.

    Yes there are alot of NS to do but I think the results are better than what was had with DC, just changing a NC valve to NO and all the places it was potentially checked was a nightmare typically found at commissioning. Now just a single parameter change with EDC.
  • Michael Krispin

    In reply to Matt Stoner:

    Hi Matt, what benefit would you have to use a DC instead of the EDC with the DDC? The EDC take some time to understand wich named set need to change but it offer much more flexibility and can reduce your amount of typical in the library. i.e Valve NC/ NO as one and configure the passive state accordingly
    BR, Michael

This is the official online community site of the Emerson Global Users Exchange, a forum for the free exchange of non-proprietary information among the global user community of all Emerson Automation Solution's products and services. Our goal is to improve the efficiency and use of automation systems and solutions employed at members’ facilities by sharing our knowledge, experiences, and application information.

User Groups | World Areas | Community Guidelines | Legal Information | Privacy Policy | Contact Community Manager

Website translation provided by Website Translator

© 2015-2022 Emerson Global Users Exchange. All rights reserved.