Emerson Exchange 365

Hello!

I can suggest to use DVSYS.@MOD@/ALARMS[1].F_PRI. It returns value from 3 to 15 or 255 and alarms must be created in a Control Module

I hope I was usefull to you!

In reply to May:

May, the information on the ALARMS parameter is in BOL.  Search for "the ALARMS Parameter".

Note that this parameter is derived from alarm data at the console. It is not available at the Control Module Level.  The Workstation Alarm system uses alarm data from modules and creates this parameter for use in displays. 

In BOL in the section above, there are tables that break down all the attributes.  ALARMS[  ] is am array of the applicable alarms for the User, Area and Module, up to 250 alarms in the array. 

Andre Dicaire

In reply to May:

There are two parts to creating an alarm. First, the logic that determines when the alarm condition is present, or not, and secondly creating the Alarm type that will define the details of the alarm, such as the alarm word, alarm message. These come together when you create the alarm in the control module itself.

Before we get into those, why is an Out of Range alarm needed. What action is the Operator required to take and what is the time to respond? Is there a critical consequence to inaction by the Operator? I mean, if there are already Hi and Lo alarms on the signal, does an additional alarm on an Out of Range condition matter? Will this contribute to alarm flooding? Is this for the Operator or is this more to indicate a need for Maintenance to be called? Should this be an alarm or an indication?

Next, I would want to know what is the expected root cause of this out of range condition. Is it normal due to the chosen calibration of the instrumentation? Or is it indicative of a failed instrument or a blocked sensing line?

Assuming an alarm is warranted, is it specifically for an upper or lower limit or both? The expected response of an operator would likely be different for the process exceeding the upper limit versus the lower limit. You may want to only consider one or the other.

The DeltaV Signal is accompanied with a Status, which includes the Limit status. There are keywords you can use to compare the limit status using an Expression in a Condition Block.
'^/AI1/PV.ST' = LIMITED_LOW or
'^/AI1/PV.ST' = LIMITED_HIGH
Note that when the AI block is set to MAN mode, the OUT.ST is set to LIMITED_CONSTANT. The PV.ST would still reflect the channel.

In the AI Channel, you have the Upper and Lower Limits that are set to 103 and -3 %. These are tunable. If the process deviates past the capacity of 4-20 mA, i.e. the transmitter output becomes saturated, the signal will become limited. This also sets the HART Error PV Saturated.

In the Control module, you can add a COND block and write the expression that will set the Output TRUE when the limit condition is met. In standard DeltaV Modules the AI Block_Err is used to set the Bad_Active on a condition of Input Failure/Bad PV. This is broader than specific Out of Range, but it does not require you to add a Condition block as the alarm trigger is the BAD_ACT parameter. You would also need to set Block options to BAD if Limited. This sets the PV BAD on a limited status.

You should familiarize yourself with the "Status options" and "Function Block Status information" sections in BOL. If these features of DeltaV signals do not provide you with the right Alarm condition you want, use the Condition Block and write the expression you need.

The second part is to create an Alarm Type that gives you the presentation you want. The section in BOL called "Alarm types" details the available alarm types and also explains the key fields such as Alarm Word, Alarm Category and Alarm message.

With the Alarm Type, and the Boolean trigger, you can create a new custom alarm. Set the path for the Enable/Disable path, and set the Alarm Type. Note that on a custom alarm you cannot use the limit field in the alarm. Define the appropriate fields in the alarm creation dialog, including the alarm priority. Use the lowest priority that meets the requirements of this alarm.

Note that the alarm has a name. You can reference a specific alarm using the Module/ALARM_NAME explicitly from the graphics. However, since the Faceplate display is generic per module type, adding explicit references in the Faceplate or Detail displays requires that all modules that use these displays have the same alarm structure.

If you use Module classes, you will need to either add this alarm to the class, creating it in all modules based from that Class, or you can create a new class, or convert the module to an instance.

I guess that the process of adding an Alarm is quite easy. However, deciding on what should be an alarm, designing the trigger logic upon which to base the alarm, and then evaluating the impact this might have on Faceplate and Detail faceplates is not a trivial thing.

Ultimately, I think that before adding an alarm to the system, it should be fully reviewed by Operators in accordance with the site alarm philosophy. After all, the alarm system belongs to the Operators, not the engineers or maintenance people.

Andre Dicaire