• Not Answered

Does enabling conditional alarming for function blocks affect controller loading?

We are having discussions at my plant of using module classes to help to standardize the control strategies here at the plant.  The topic of conditional alarming came up and how to implement this into a module class.  The simplest option would seem to be to expose the conditional alarm enable parameter but this does not seem to be possible.  The only I way I have found to be able to access it is by using the assign alarm option in the context when right clicking on a function block.  We discussed just enabling conditional alarming in the class and then exposing all of the additional alarming parameters.  My question around this is will this affect controller loading and if so by how much?  Even a small amount of additional loading will add up when the number of class instances gets larger.    

1 Reply

  • Instead of doing that I would suggest adding an Action Block to your classes, Change the default of IN_D of this block to be 1 with status of GoodNonCascade, then make the default expression to set the IN_D to 0 and allow this expression to be configurable at instances.

    Then when you need to do conditional alarming you just write the expression to update the appropriate conditional alarming parameter based on the condition required. If you need timing on the condition you can use the associated condition alarming XX_ENAB_DELAY parameter for this. Here is an Example of the Default Expression of an ACT block name MISC_LOGIC and then a version of this expression for conditional alarming use in an instance.

    Because this is an expression this also will allow you to do "other" special logic if needed at instances.

    This configuration won't have any extra loading when not needed because the Action expression only runs when IN_D is 1 but does have some added memory. We have found this to be very beneficial because of the flexibility it provides to make easy modifications at instances when required.