User Tools

Site Tools



About events

With events you can save some set of process related data in a separate log, an event log and then analize these sets or data. For events you define trigger conditions and actions, i.e. what data to save. Then you get records which can be used further in many ways:

Unlike building the necessary protocols by 'mining' information in the database (logs), event reports are generated 'on the fly' ie. at a pace with the monitoring process.

Customizing an event

Creating an Event

Setup / Events menu is for adding events into a project.

'Add event' button is located in the top-right page corner:

Event Basic settings

In the Basic tab, there are 3 items:

  • Title This title is for the list in the Setup menu
  • Description To give any comments for the events
  • Parent event This event recorded only if a high-level, or parent event is running now. I.e. this event nests in a parent event with all its data.

About parent and child events

If there is some process that could happen “inside” a parent event and is a part of the whole event you can declare it as “child” event. Child events have some features:

  • They are recorded only when the parent event is being recorded, i.e. parent's enable condition acts like a “AND” condition for the child
  • Parent event's report builder can access child's data for report data
  • Child event table are referenced as a links inside the parent event view table. You can disable child event link visibility for the parant event view - see more on this in Viewing events
  • Child event run/stop states can be used as timeline source data or Gant diagram inside the parent event report page
  • For child events no report entry will be created in the side menu.

Event Condition

After a 3.3 version, WebHMI has simpler condition setting - if some register's value equal or not equal to another value. There could be several conditions acting by logical 'AND' operation.

Of course, the event conditions sometimes may be very complex, but with Lua scripts you can describe any imaginable condition:

-- complex event start condition 
local tmr_state, count_down = Timer(var1 > 60, ON_DELAY, OFF_DELAY, "myTimer_1")
local eventEnableCondition = var2 and var3 or (var4 and count_down >= 30)

Lasting vs. one - shot events

The events may have or do not have duration in time. For lasting events (that is more common application) you set special checkbox. Lasting events are good solution when you have some regular batching process lasting several minutes. For long lasting processes (with durations of days, weeks or more) they not always can be appropriate (see note on events below).

For day, week etc. totals you can latch neccessary data in an one-shot event. For such an event condition must be true for ONLY one scan. Otherwise the records will be added in every scan while event condtion is true. See the note.

Event Actions

The 'Action' tab of the event settings determines what, how, and when have to be recorded in the event report data structure.

  • Title - The title field for the Setup menu. Possible to re-type here
  • Save to report checkbox - If selected, it will be possible to set the E-registers in the form of Ey.x. See explanation below
  • Report title - It is the Report title when it's viewed or accessed from API, etc.
  • Menu item name It is how the 'Report' menu entry will look in the side bar menu
  • Save data The registers values (except for Event Start/End/Last update time selection) can be written Once per Event or Every X seconds . If you don't want to log some register's value for graphs all the time, but only inside a specific event, you may choose option of 'Every X seconds' and then a series of values will be recorded just in the event log data. Then an external application (or Level2 report builder) can use this data to biuld its own graph.
Selecting data to record in event log

If you press +Add Register to report, the following dialog will appear:

It is possible to pick up 4 options:

  • Start time - event start time
  • End time - event end time
  • Last update time - the time of last record write time in the event ( this is a speical option for testing purposes)
  • Any register from Registers list - when you select a register from your project, then you can re-type the parameter title for the event and select which value to take for event log (min / max / first/ last / average):

The rows of selected register have Register E1.0, 1.1, … string left to it. These E-registers are indexed from 0 and further in ascending order (x is an index), y is the event identifier that is assigned to it when it is created and is displayed in the event list. Ey.x - it is address in the WebHMI internal register protocol (see also link), and also it is used to refer to them in Level2 report builder.

Show on timeline - If you select this checkbox, you can see evetn on timeline with set color. See below

Add log message - If you select this checkbox, a message with set priority and content will be generated upon event start.

Viewing events data

The side bar Reports menu is for accessing logged event (it's only available if there are event configured in the project). When viewing the event data you can use calendar, search box, sorting and save selected data to csv, html files:

Since the “Show on timeline” option was set when creating the event, it will also be shown on the timeline. The line with a point on the axis marks the event start time or the one-moment event. You can navigate the timeline holding main mouse button to move horizontaly and zooming with mouse wheel button.

Other event usage options

Besides above application, there are extra options for the recorded event data:

Export event data to csv/html - file

Get event data from external applicaion via API

More on this - here.

Send event data to Level2

There is a report builder in the Level2 system as well which uses data taken from WebHMI as a source. More on this here.

Creating a timeline based on time from the event

Customized report view on screens and dashboards

getting historical data from events in WebHMI customized report screen or dashboards (using API and Lua)

Notes on event usage

Editing events in the running project

Due to 'on the fly' method of recordig events, WebHMI project restart will cause an event being recorded to “split”. If you have some important report or critical data in your project and edit or comission the project remotely, apply changes when the event unlikely to happen or won't cause data distortion.

One - time events

With one-time event, i.e. those not having 'event has duration' checkbox set, remember that while the event condition is true the webhmi will generate excess records in the DB on every scan. Use lua script which provides one scan duration of the event enabling condition.

The script which gives a right condtion for an one-shot event (running every hour) could be like this:

function main (userId)
  -- vars 
  local prev_cur_hour = R("cur_hour") -- read current stored value 
  local cur_hour ="%H", os.time()) -- read RTC 
  -- logic 
  if (cur_hour ~= prev_cur_hour) then 
     W("one_time_event_condition", 1)      
     W("cur_hour", cur_hour)          
     W("one_time_event_condition", 0) -- prevents further calls      

Lasting events with different start and end condition

Be carefull with different start and end condition for lasting events. Becuase when they intersect, i.e. end conditino happens while start condition is true, you will get multiple events at once.