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.
Setup / Events menu is for adding events into a project.
'Add event' button is located in the top-right page corner:
In the Basic tab, there are 3 items:
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:
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)
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.
If you press +Add Register to report, the following dialog will appear:
It is possible to pick up 4 options:
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.
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.
Besides above application, there are extra options for the recorded event data:
There is a report builder in the Level2 system as well which uses data taken from WebHMI as a source. More on this here.
getting historical data from events in WebHMI customized report screen or dashboards (using API and Lua)
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.
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 = os.date("%H", os.time()) -- read RTC -- logic if (cur_hour ~= prev_cur_hour) then W("one_time_event_condition", 1) W("cur_hour", cur_hour) else W("one_time_event_condition", 0) -- prevents further calls end end
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.