Supported platforms: CODESYS 2.3, CODESYS 3.5
Reading the Latest Events from Event Log
The purpose of the Event Log library is to send system event information, such as alarms, warnings and notifications, from Epec units to event consumer unit. The event consumer is able to log event information and show it to the user. The Event Log library uses PDO protocol to transfer information from event producer to event consumer.
Use Epec MultiTool Creator to define events for the event producer. The event system uses two PDO messages: one to send event data to the event consumer and another to receive the acknowledge message from the event consumer. Epec MultiTool Creator generates an enumeration EventCodes of events to Epec Code Template. To send an activated event to the event consumer, the producer only needs to call EL_Update function.
To store system events to log and/or to show them to the user, the system needs an event consumer. The event consumer can be an Epec unit that can log information to a file or NVRAM, such as 6107 display unit and 5050 control unit. Use Epec MultiTool Creator to define event consumer. The event consumer receives the PDOs from event producers, stores them in log file and in case of a display, can show event information to the user.
Epec MultiTool Creator generates a CODESYS project with code template that includes all configurations made.
- For event producer, the code template includes, for example, event enumeration and global variables for data connection to event consumer.
- For event consumer, the code template includes, for example, event enumeration for own events, data connections to producers and an array of EL_Event for each device (including consumer own event array) that configures events and includes event status information.
The following picture describes more detailed information about Epec Code Template and event system.
To update event status, use function EL_Update. Both event producer and consumer can use this function, the only difference is that the event consumer does not send the event information to CAN bus but adds it to log or show pop-ups.
Code: |
|
(* Compare if value is smaller than given limit *) IF a <= PAR_MaxValue THEN a := a+1; (* Increase value *) ValueExceedsLimit:=FALSE; (* No need for warning *) ELSE a := 0; ValueExceedsLimit:=TRUE; (* Trigger warning to TRUE *) END_IF
EL_Update( i_State:= ValueExceedsLimit, (* Event status, i_State change triggers sending event PDO (after on/off delay) *) i_EventID:= E_WarningValueExceedsLimit, (* Enumeration variable for limit warning generated from Epec MultiTool Creator*) i_OnDelay:= 200, (* Default value 0 ms*) i_OffDelay:= 200, (* Default value 50 ms*) i_ToIntEventLog:= FALSE); (* This producer does not have internal event log *)
|
To view the latest events from event log, use function block EL_ReadLog. The function block returns an array of type EL_GUI_ViewOfLog. The array size is defined in global variable G_EL_MAXVISIBLELOGLINES (default value = 20).
The following example shows how to read the latest events from the event log without filtering or sorting.
Definitions: |
|
ReadLatest: EL_ReadLog; LatestEvents:ARRAY [1..G_EL_MAXVISIBLELOGLINES] OF EL_GUI_ViewOfLog; LogLineCount:WORD;
|
Code: |
|
(*Read the latest events from the event log without filtering or sorting*) ReadLatest( i_StartPosition:=0, i_AscendingOrder:=FALSE, i_pFilter:=0, i_FilterCount:=0, i_SortingOrder_1st:=0, i_SortingOrder_2nd:=0, i_UpdateSortedList:=FALSE, o_ViewOfLog=> LatestEvents, o_EventCount=> LogLineCount);
|
The event log can be filtered by event status, source, type, user level and ID. The filters can also be combined, for example, the event log can be filtered by event status and type. To define the filters, define an array of type EL_Filter. Each row in the array defines one filter.
When the event is filtered by
1. status, the event state flag variable (EL_Event.EventFlags) is masked with variable Arg2. The result is then compared to Arg1. Arg1 and Arg2 are bit masks for EL_Event struct variable EventFlags. The following table describes filter argument possibilities. It is also possible to combine several bits into one value.
Name of the Constant |
Data Type |
Bit (x) |
Value |
Description |
EL_EventState |
INT |
0 (2#0000 000x) |
1 |
Follows event status after filter delay |
EL_StateNotAcknowledged |
INT |
1 (2#0000 00x0) |
2 |
Set on rising edge, if config bit is set EL_Config_Acknowledge |
EL_PopupNotAcknowledged |
INT |
2 (2#0000 0x00) |
4 |
Set on rising edge, if config bit is set EL_Config_Popup |
EL_EventToLog |
INT |
3 (2#0000 x000) |
8 |
Add event to log |
EL_EventActive |
INT |
4 (2#000x 0000) |
16 |
Event currently active |
EL_OptionExtSystem |
INT |
5 (2#00x0 0000) |
32 |
Log line after this, has optional information for the event |
EL_ExtSystemFrame |
INT |
6 (2#0x00 0000) |
64 |
This log line is optional information for the event |
EL_TimeStamp_Bit17 |
INT |
7 (2#x000 0000) |
128 |
Extra bit for timestamp calculation of delays (EL_Update) |
2. any other criteria (source, type, user level and ID), the argument variables Arg1 and Arg2 are handled as minimum and maximum values.
The variable Operator defines the relationship to previous filter, when several filters are combined. The first filter does not need an Operator. In the following example the Operator on the second filter is AND. Therefore, both filter conditions need to be met before the event is shown. Possible Operator values are listed in enumeration EL_FilterOperators.
The following example filters events according to event status and type, only active events from type 0 to 3 (alarms, warnings, notifications) are passed into output array o_ViewOfLog.
Definitions: |
|
ReadActiveAndType02: EL_ReadLog; ActiveAndType02View:ARRAY [1..G_EL_MAXVISIBLELOGLINES] OF EL_GUI_ViewOfLog; ActiveAndType02Count:WORD;
EventFilters:ARRAY [1..2] OF EL_Filter:=[ (*Filter active events *) (FilterType:=EL_FTP_STATUS, Operator:=EL_FOP_AND, Negation:=FALSE, Arg1:=EL_EventStatusFlags.EL_EVENT_ACTIVE, Arg2:=EL_EventStatusFlags.EL_EVENT_ACTIVE),
(*Range 0-2 = alarms, warnings, notifications*) (FilterType:=EL_FTP_TYPE, Operator:=EL_FOP_AND, Negation:=FALSE, Arg1:=0, Arg2:=2) ];
|
Code: |
|
ReadActiveAndType02( i_StartPosition:=0, i_AscendingOrder:=FALSE, i_pFilter:=ADR(EventFilters), (* Pointer to EL_Filter array *) i_FilterCount:=2, (* The amount of used filters from EL_Filter array *) i_SortingOrder_1st:=0, i_SortingOrder_2nd:=0, i_UpdateSortedList:=FALSE, o_ViewOfLog=> ActiveAndType02View, o_EventCount=> ActiveAndType02Count);
|
Negation is done after all other filtering operations for one filter. For example, filtering inactive events can be done using a filter for active events and set Negation variable to TRUE. Then the filter passes all events that are not active.
Definitions: |
|
(* Filtering inactive events with Negation *) InactiveEvents:EL_Filter:=(FilterType:=EL_FTP_STATUS, Operator:=EL_FOP_AND, Negation:=TRUE, Arg1:=EL_EventStatusFlags.EL_EVENT_ACTIVE, Arg2:=EL_EventStatusFlags.EL_EVENT_ACTIVE); |
To sort the event log, use EL_ReadLog inputs i_SortingOrder_1st and i_SortingOrder_2nd. These inputs are given as a bit mask, where each bit have different definitions.
Basically, sorting can be divided into two ways, sorting by
1. Type. Sorting by type has two options:
a. Using order (r) and mask (m) bits, when the log is
- first ordered, for example, by status
- then masked by popup, acknowledge or status in selected order (1st, 2nd, 3rd mask)
b. Using type definition (t), when the log is sorted by type or source of the event.
2. Direction: ascending or descending order
The following image shows how to define an input for sorting events from the log.
The following example shows how to sort active events from event log
- according to event type (2#00000001)
- to descending order (2#00001000)
Definitions: |
|
Events: EL_ReadLog; (* Filter according to event status *) CheckActiveEvents: EL_Filter := (FilterType:=EL_FTP_STATUS, Operator:=EL_FOP_AND, Negation:=FALSE, Arg1:=EL_EventStatusFlags.EL_EVENT_ACTIVE, Arg2:=EL_EventStatusFlags.EL_EVENT_ACTIVE);
(* Sort according event type to descending order.*) (* 2#0000x000: x=1 descending order, x=0 ascending order*) (* 2#0000000x x=1 sort according event type*)
sorted_1order:BYTE:=2#00001001;
|
Code: Events(i_StartPosition:=0, i_AscendingOrder:=FALSE, i_pFilter:=ADR(CheckActiveEvents), i_FilterCount:=1, i_SortingOrder_1st:=sorted_1order, i_SortingOrder_2nd:=0, i_UpdateSortedList:=FALSE, ); |
|
|
For more information about sorting possibilities, see section EL_EventHashCode
To clear the event log, use function EL_Clear.
Code: |
|
EL_Clear(i_Enable:=ClearLog);
|
To handle popups, use EL_Popup program.
Code: |
|
EL_Popup(i_AcknowledgePopup:=AcknowledgePopUp,(* Acknowledgement button *) i_Interval:=1000, (* Interval for changing the showing popup *) o_PopupActive=>PopUpActive, (* Indicates if there are any active popups *) o_Event=>, (* Current event that requires popup actions *) o_EventID=> );
IF PopUpActive THEN PopupEventID:=EL_Popup.o_EventID; (* Popup event ID *) ELSE PopupEventID:=0; END_IF
|
See also
Epec MultiTool Creator Manual, chapter MultiTool Creator Code Template
Source file Topic100311.htm
Last updated 19-Dec-2024