EE - Forum Styles
fo

Recurring Alarm in DeltaV v13 for a Discrete Valve Module

Hello,

I'm looking for feedback:

We essentially try and maintain sticking to class based modules when we can. I have a scenario where I'm trying to have a timer for a specific interval to realarm as we have a valve open and are utilizing a chemical. In our library there are two classes: AI_RECUR which you'll see below and a SOFT DI. The valve and its class base is vlv_no.

I believe with this instance I won't have an issue justifying creating an instance that is classless utilizing that vlv_no and then modifying the linked composite and making that instance an embedded composite as to not affect my library or class based modules. I feel like I may be nuking this and just want to ensure that I won't be creating a custom module if there is one that lives out there in a library or the way I was going to set it up won't be causing some type of underlining issue. In that condition block, I have an expression that is looking for the valve to be a 1. 

 

2 Replies

  • Module classes are both a blessing and a curse. You want to strike a balance between the number of classes and controller performance. Adding all functionality to a class so it serves every purpose means a lot of code that does nothing. Having a class for every variance means a lot of Class modules and you end up not knowing which does what. So a nice balance is to create a new class when there is a meaningful design requirement and using some amount of standard features that align with your control design philosophy. You may not use them in every module, but you will in most.

    Then comes the one off situation. Do you make a new class? Do you modify the class and add the feature to all, or do you make an instance.

    First step is make an instance and move forward to prove the design and get the project done.

    Next, once the design is proven and working, you can take some time to determine how best to get this integrated.

    Another option:

    Manage your alarm reset from a separate module designed for this. Should not be a class as this is a custom supervisory module and you could manage all such alarms from one module.

    Use an External reference parameter, called "ALARMXYZ" and point this to the module/alarm in question. Then using a CND block and an ACT block, monitor the alarm state and reset the Unacknowledge state based on the CND timer.

    In the CND block, i monitor the .CUALM field of the targeted alarm, via the external reference path.  I also check to see if OUT_D is equal to 0 to reset the expression automatically.  When the CND OUT_D is true, the ACT block fires one time to set the NALM field of the alarm true, setting it unacknowledged, assuming the alarm does not autoacknowledge. 

    I could make this into a composite, and when you drop this in the module, you set the path and the time out desired.  A module supports 255 blocks so this would work for 127 modules, give or take.  You might create a few of these based on plan areas, or alarm types or what have you.  Run that at 5 or 10 second.  as time is not that critical.

    Cheers.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Andre, thank you for the insight, I appreciate it.