WCCILevent
Specific options of the Event Manager
| Option | Meaning |
|---|---|
| - noDMAlertConn | No automatic alert connect of the Data manager. |
Specific debug levelsof the event manager
| Number (Name) | Meaning |
|---|---|
| 13 (EV_STATFUNC) | Show detailed statistical function information |
| 16 (EV_WORK) | General information on the Event manager.
-dbg EV_WORK will also print a line in case of Delayed Alerts when an alert delay expires and the alert will be activated. |
| 17 (EV_TIME100) | Turn on the output for performance check (time per 100 messages). |
| 18 (EV_SOURCETIME) | Ignore the source time and use the current time instead (not in case of data point values). |
| 19 (EV_EVENTFILE) | Activates the event file. |
| 20 (EV_ALERTFILE) | Activates the alert file. |
| 21 (EVMAIN) | Iteration times of the Event main loop. |
| 23 (UI_RENT) | Query profiling. |
| 29 (CTRL_TRACE) | Activate CTRL trace alerts for every script that will be started. |
| 44 (copyDp) | Information on copyDp and copyDpType. |
| 45 (License) | Detailed information on licensing events. |
| 48 (alertFiltering) | Debug alert filter actions. |
| 49 (sumAlertCheck) | Extended recursion information and sum alert recursion checks at start-up. |
| 50 (CTRL_PERF) | Show CTRL performance statistic data. |
| 51 (CTRL_WORK) | Temporal output of the CTRL interpreter. |
| -report ALERTCOUNT | See detailed description below. |
| -dbg STAT_SIMPLE | See detailed description below. |
| -dbg STAT_HISTO | See detailed description below. |
-report ALERTCOUNT
To get the total number of alert instances in the system the report flag "-report ALERTCOUNT" for the Event Manager can be used.
If the report flag is set the following information is written to the log file for the Event Manager:
Existing alarm instance in the event manager: "<number of alerts>"If an alert is raised the count is increased.
-report ALERTCOUNT (or -report ALL) will show the number of delayed alerts and the minimum and maximum remaining time of the alert delay for Delayed Alerts.
When the alert is gone and acknowledged the count will still be the same.
Therefore the number does not reflect the number of pending alerts in the system.
The information written by the report flag can be used to detect if the number of alerts is increasing (constantly) while the project is running.
-dbg STAT_SIMPLE
With the debug flag -dbg STAT_SIMPLE for the Event Manager the number of value changes or changes on alert instances is reported in an interval of 30 seconds.
When the debug flag is activated the following information is written to the log file for the Event Manager:
WCCILevent (0), <TIMESTAMP>, STAT_SIMPLE, "DPEChanges: <number of value changes> "
WCCILevent (0), <TIMESTAMP>, STAT_SIMPLE, "AlarmChanges: <number of changes on alert instances> "-dbg STAT_HISTO
With the debug flag -dbg STAT_HIST more detailed information for the processed value changes and changes on alert instances is reported in an interval of 30 seconds.
The information is written to the log file for the Event Manager.
The interval can be defined with the config entry [general] MessageDiagSec. The default value is 30 seconds.
For every debug two lines of information is written, where the first line contains information for the value changes in the system and the second line contains information for the processed changes of alert instances.
The information is written in form of a histogram. Each slot of the histogram has a special meaning.
Value changes
The first column contains the total number of value changes for the last period.
In the following columns detailed information for the latency is reported. The latency is the difference between the value change timestamp and the processing in the Event Manager.
If the value is changed due to a dpSet/dpSetWait message, the difference is 0 in any case as the time stamp is given by the Event Manager.
If the value is changed in a PLC and the driver provides the timestamp, some latency might be detected. Due to time synchronization there might be negative latency intervals as well, which are counted in a separate slot.
The histogram contains information for following latency intervals:
// slots:
// total number [ 0]
// 0 .. 90 ms [ 1] .. [10]
// 100 .. 900 ms [11] .. [19]
// 1 .. 9 s [21] .. [29]
// 10 .. 90 s [31] .. [39]
// <0.0 [102]
// >= 100s [101]The example for the log message shows value changes triggered by a Ctrl script running on the same server as the Event Manager, therefore no latency is detected.
There are 34 changes in total, and all are detected with less than 10 ms latency.
WCCILevent (0), <TIMESTAMP>, STAT_HISTO, "DPEChanges - decades: 34, 34, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, >100s 0, <0 0"Changes of alert instances
The first column contains the total number of changes of alert instances for the last period.
In the following columns detailed information is listed according to the alert type (continuous alarms, multi instance alarms, suppressed alarms) and the alert state.
// ALERTEVENT_CAME (0)
// ALERTEVENT_CAME_IMPULSE (1)
// ALERTEVENT_GONE (2)
// ALERTEVENT_MULTIPLE_ACK (3)
// ALERTEVENT_SINGLE_ACK (4)
// ALERTEVENT_GONE_INACTIVE (5)
// ALERTEVENT_GONE_IMPULSE (6)
// ALERTEVENT_GONE_OBSOLETE (7)
// NOEVENT (8)The histogram contains the following slots:
// slots:
// total number [ 0]
// continuous alarms [ 1]..[10] sorted by AlertEvent constant
// multi instance alarms [11]..[20] sorted by AlertEvent constant
// suppressed alarms due to minPrio setting [32]
// _alert_hdl config was set active/inactive [33]The following sample shows changes of continuous alarms and multi instance alarms.
1036 alarm changes in total
29 continuous alarms (ALERTEVENT_CAME)
7 continuous alarms (ALERTEVENT_GONE)
1000 multi instance alarms (ALERTEVENT_CAME)WCCILevent (0), <TIMESTAMP>, STAT_HISTO, "AlarmChanges - decades: 1036, 29, 0, 7, 0, 0,
0, 0, 0, 0, 0, 1000, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, >100s 0, <0 0"
