_add_value

[JOSEPHINE]

I 'd like to add columns in the AEScreen . In my project I would like to display the name of the building where i have an alert, and many other information for each alarm .
I know i must use _alert_hld .._ add_value. could someone help me with this?

[leoknipp]

adding a column in the AEScreen is possible at the panel System Management --> Settings --> A&E - Row/Screen.
An _add_value needs to be added to every instance of an alert. If the information is "static" using the _add_value is not the preferred solution. E.g. this information can be saved as dp description for the dp element where the alert is configured.

[JOSEPHINE]

i already try what you said (saved the information as dp description), but i have to display four informations for each alert.
it is possible for you to help me with an example of script where an add_value is used?

[leoknipp]

is the information static or can it change with every alert instance?

If the information is static you can write it to the dp description with a defined separator. In the AEScreen the information is then displayed in one column.

[fmulder]

There are many solutions to this problem. The difficulty differs quite a lot and you'll have to figure out what is best for you:
1) Make your own alarm banner
- Lot of code
- You'll need a lot of scripting knowledge to be able to do this !

2) You can add some lines of script code to the existing AES scripting code
+ This is easiest to do
- But you'll have to do it again every time you install a patch or new version of OA

3) You can implement a C++ DLL that adds information to the alarm tabel
+/- you'll require some C++ knowledge (it is not too hard)
- You'll have to recompile when there is a new version
+ Probably the best performance

In all options you'll need something to store the 4 extra columns. You could use:
- The description of the datapoint (a comma separated string)
- 4 dp elements. Make sure that you do not dpGet() per alarm. Do a dpConnect() and store the information in a global mapping so that you can read the values fast

I have done all of the above options in the past. I've never used the _add_value sofar. IN our current project we are using option (1) because we do a lot with alarms and the standard banner wouldn't do the trick for us

[JOSEPHINE]

to return to the problem of alarm panel , yes the indormations are statics

[marcel@realsolutions.nu]

In several projects I'm also using add. values, works perfect, the workflow is like this:
- in the alertclass we call a script (alarm action), and on the arguments tab we define the info to supply
(thus if a new alert comes, this script is called so we're able to add the information /add.values)
- the script checks if the add.values are already added or not, or should be used from the partner alarm
- we determine the info that we want to add (e.g. by doing a dpGet)
- with alertSet we write the determined add.values to the alert

As already mentioned in this topic: add.values can be easily added to the alarmtable....

I can make some screenshots and send to you by email if you're interested...

[JOSEPHINE]

I really would be happy to have these screenshots. it would help me a lot for my project
this is my email : josephine.lamien@actemium.com

[leoknipp]

as you have described the information is static, therefore adding this information for every alert is too complex. Espescially when having a lot of alerts in a short period of time (data avalanche) additional tasks (e.g. alert action script executed by the event manager) will cause additional load for the system.
In case of static information the preferred solution is to use the dp decription or dp alias.

Using the dp description or dp alias has also a positive effect on the performance when reading alert information.
If the information is stored at an _add_value it needs to be read from the database (for historical alerts) or from the current process image (stored in the event manager).
The information for the dp description and dp alias is stored in the dp identification. The dp identification is loaded during startup of the UI manager and then stored in memory. Accessing this information during runtime is much faster then requesting this information by sending WinCC OA messages to the data/event manager.

[alaralum]

In case I would like to use this static information that I have saved as "alias" for every alarm, would it be possible to use this information to filter the actual displayed messages in the AES??