Alternative to timed functions

[Mgiacome]

In my project I have several queries that evaluate the number of active alerts on different datapoints, and I was looking for a way to refresh them every 10 seconds. After discarding timed functions, I thought about using a datapoint as a clock.

I created a DP using dp_fct based on the value of the system heartbeat (_Event.Heartbeat) and I check its value with p1%10==0, meaning it becomes TRUE every 10 seconds.

In the functions that evaluate the queries, I then used a dpConnect on the value of the newly created clock, and by checking for the rising edge (TRUE), I trigger the function that counts the alarms.

Among the advantages are the greater simplicity of the code and the fact that the clock changes in sync with the system, so all queries are updated at the same time.
In addition, it is possible to easily create clocks with different intervals (30s, 1 minute, etc.).

I hope this can be useful to someone.
Best regards.

[gschijndel]

I would not recommend this alternative as it has several disadvantages:
1. Datapoint functions are executed by the event manager resulting in an overall lower system performance. While the event manager is running datapoint functions it cannot process incoming messages.
2. Library updates cannot be done online in a non-redundant system as the event manager must restart to reload the library.
3. With a sumalert the alert count can be retrieved by reading the '_summed_alerts_count' attribute. No function is required for that.

In my opinion the best alternative to timed function is an endless (for/while) loop with a delay.

[leoknipp]

For cyclic tasks the timed function was implemented. A timed function can also be used for tasks which must be executed in short intervals, e.g. 10 or 30 seconds.
More interesting is the question why you must update the number of alerts in a short interval?
Where is the information for the number of alerts displayed or used then?

Doing identical queries all the time is not the best idea. While the Event Manager is processing the query no other task is executed in Event Manager.
The AESRow counts the alerts with a dpQueryConnectSingle() and some business logic. Maybe you can use a similar approach in your use case.

Best Regards
Leopold Knipp
Senior Support Specialist

[Mgiacome]

I have several synoptics (home pages) that contain links to different parts of the plant; for each plant section, specific datapoints are defined, and for these datapoints specific alert_hdl are configured.

On these home pages I display the number of active alarms (CAME) and the total number of alarms; this alarm count depends on the priority (warning or critical) and on which DPs are present in the plant section: the number of alarms is different for each plant section.

To get the number of alarms I use a SELECT ALERT query with filters on the DPs and on the _prior field.

I tried using dpQueryConnectSingle, but it doesn’t return the list of active alarms, only the changes; I tried using dpQueryConnectAll, but I don’t get results, and in the documentation I found:
"A query with the SQL statement SELECT ALERT ... must not be used because of performance reasons!" along with other limitations.

Currently I don't notice any performance issues

[gschijndel]

Sounds a bit like the panel topology or the group alert facility part of it.

[Mgiacome]

Last update: I'v used the dpQueryConnectSingle as a trigger to perform the count of active alerts filtered by prior and DPs