User Tools

Site Tools


level2:creating_advanced_reports_in_level2

Process control reports in Level2

When you have any automated manufacturing process you want to control its parameters for many reasons. These are: accounting, quality control, resources consumption, preventive maintenance, etc.

To achieve this goal the very first task you need to do is data collection.

Collect data

WebHMI has special feature called events which allows you to recognize your process cycles and collect any related information. To detect correct timeframe of each production cycle event has start and stop conditions.

It is very easy to create these condition using visual blocks:

Events can be two different types:

  • Event is considering active whenever condition is true and it lasts for one scan only. In every scan when condition is true new event will be triggered. Every consequent scan will create new event while condition is true.
  • Event has some duration and it can last over multiple scans. In this case it can have separate end condition.

Please note that any change in project will force WebHMI to reset all current processes and read new configuration. This is needed to be in defined state on project start. This meant that if some event was in running state and you will apply change to project (add/edit register settings, etc) all running events become incomplete. Typically you might see such situation during creating project and this should not be a case in real production for final system because project will be reloaded in normal conditions.


On Actions tab you tell WebHMI what to do once event occurred. Three choices are available:

  1. Add message to Message Log
  2. Save data to Report.
  3. Show event on Timeline. This option is available only when you save data to Report.

Report basically is a dataset which describes what was happening during the event. Data is being collected from registers and you can pick any available register to get data from. In addition to raw register value you can use some preprocessed values based on register value:

  • First value of register within event's timeframe
  • Last value of register within event's timeframe
  • Minimum value of register within event's timeframe
  • Maximum value of register within event's timeframe
  • Average (sum of all values divided by their count) value of register within event's timeframe

Also there are available 3 special registers - “Start time”, “End time”, “Last update time”. As you can guess they provide unixtime timestamps of event's start, end and last update time in database.

During long events (from multiple second and much longer) WebHMI will save current “state” of event into report and mark it as unfinished. System will update these unfinished events in database every 5 seconds. “Last update time” field shows when event was saved last time.

Event's data (set of registers) can be saved into report once per event or multiple times on periodic basis. Interval timings are useful when you have dynamic metrics and you want to track their changes over time. Another option will be use graph data to see changes of some metrics over time (see blow).

Events can have child/parent events. This is very handy in situations when you have complex process with some subroutines and you want to track these subroutines individually. WebHMI checks conditions of these subroutines only when their parent event is running. I.e. child events can't run if parent event is not run too. End of parent event will force end of child events.

To see collected events data you can open its report under Reports menu item. It will look something like this one:

Here you can see basic fields for parent event (start time, end time, recipe name, etc) plus links to child events (Component 1, Component 2, etc).

Also here you will see that last event was not finished yet and is still running.

If you will click on child event link, you will see details of this event. For example:

Timeline is a way to visually see order and duration of your events. It is available under ReportsTimeline menu. It shows only events with enabled timeline option. You can drag and zoom it to see more details. Here is example:

So, now we know how to collect all needed data and check if it was collected correctly. Now it is time to build custom reports for them in Level 2 system.

Example

Lets take a look on real-life example how events can be used to track work of dosing system on mixed fodder plant.

In our example plant has 8 tanks with variable components. Operator can fill them using noria and remotely-controlled valves. Once tanks are full he selects product that needed to be produced. Basically this is a recipe with set of weights for each component and total weight of batch. After that operator starts weighting process by pressing “Weighting” button. When needed amount was put on weights product goes to crusher, then to mixer and then it can be passed to packaging or pellet machines.

In this example we will focus on weighting process. Script in PLC or even script in WebHMI itself will control motors to deliver needed amount of each component to the weights. Once needed amount of current component was delivered, script stops motor and switches to next component.

Obviously some errors can occur due to various delays in batching process and motion imperfections. System can deliver a bit more or less ingredients. Head of production department of plant wants to track how many kilograms was actually put on weights and be able to compare it with target weight.

To track weighting process master event “Weighting process” was created. It starts when Weighting start flag is set and ends once it clear. Here is how we setup this condition:


We call this event “Master” because it will be like a container for its child events. It will collect basic information about overall process. Child events will collect information about individual components.

In WebHMI each event can have parent event. If so, it will be child event. Event without parent event is parent event to another events or standalone event. Child events can start only while parent event is running and they can collect individual sets of data.

To help users see the parent-child relation between events we display them in tree view:


To build up informative report we will need to collect following fields for master event: Start time, End Time, Recipe Name, Dosing Duration, Target Weight, Error Flag. Error flag will let us know that this batch has error and we will highlight such event in report later.

Additionally we created child events for each components:

They have very simple conditions. We will collect data when correct motor is running. Here is example:

In action tab we instructed WebHMI to collect following data:

  • Start time
  • End time
  • Target weight
  • Actual weight
  • Dosing weight. This is actual weight minus target weight. Can be negative.
  • Component title. Tank can hold different components, we want to know what component is in it now.
  • Weight error flag. This flag will allow us to highlight component if there was dosing error.

Once events were setup we can check that they collect correct data under Reports page. Here is how master event looks.

And individual component subreport should look like:

If WebHMI was connected to Level2 correctly, all collected events data are being automatically sent to Level2 periodically.

Report Builder in Level2

Level2 has powerful report builder which allows users create rich custom reports using WYSIWYG-style editor. It is available at ReportsManage page.

Lets take a look on report that we will create.

Here we see list of all dosing batches in table view. We see very basic info of each dosing cycle: start and end time, duration, recipe name and error flag. If any error was occurred during dosing process row is being highlighted with red background and red Error icon appears.

User can click on any row and see details of that dosing batch.

Here is how detailed view looks like.

Here we have much more information on dosing process. Timing table show start time, end time and overall dosing duration. Recipe table shows overview on target weights of individual components. Components table gives us detailed info on dosing each component: time, target and actual weight, difference between them and error flag. Error flag is added here just for usability purposes. It helps operator quickly identify component that were dosed with problems.

At the very bottom of report we can see timeline that visually displays dosing of each component in respect to their timing and order.

Report Builder provides easy to use visual tools to build such reports. Lets take a look on how this report was set up.

On basic tab we entered report title, selected node (WebHMI device) “Mixed fodder plant” from which we want to show events data, and selected master event “Weighting process”.

List tab configures how overall list of all dosing events will look.

We can group events by day. This will visually group events that happened in one date within individual tables with date header.

Here we also can set width on this table list to 100%. But for tables with small amount of columns this will look bad.

And in columns section we specify title and content of each column of this table. Content of column can be value of register from event. Here we can specify how to display value of each register: raw value as is, date and time, time duration of alert flag.

For Date and time and time duration columns we can specify time format in moment.js format.

Flag should a bit value (0 or 1). If value is 1 then row will be automatically highlighted with red background.

Column value can get value not only from master event but from child events too. If there are multiple child events with specified id happened system will get value from last one.

Details tab contains WISIWYG editor that allows user to create report with rich formatting and with custom layout.

Layout builder allows you to create rows and columns within them. Row takes 100% width of page. Each row is being split into 12 vertical sections and must contain at least 1 column. Column can span from 1 up to 12 such sections taking from 1/12 to 12/12 width of page. This allows create flexible layout what fits all display sizes. You can make column smaller or bigger using corresponding buttons on toolbar.

To visualize structure of layout you can toggle Show layout blocks button in toolbar. This will highlight rows with blue color and columns with orange color.

Here is small video showing basic layout editing techniques:

Another option to restructuring data is to use tables. Report builder provide reach possibilities to create and edit tables. Here is small video showing basic table editing techniques:

Once you understand how to structure your data lets take a look on available options on displaying data.

Register value

The most simple way to display data from events is insert is as plain text. You can use “Register's value” tool for this. This tool allows you to select event, register from it and format of data to be displayed:

Once you will add such value into report template you will see yellow placeholder in format [E2.1]:

This means that system will show at this place value of register #1 from event #2. Where these numbers are coming from? You can see them in every event edit page nearby each register added to report:

Alert flag

Alert flags are simple red icons that supposed to attract user's eye to data with some problems. System will show red icon if there will be non-zero value in selected register. Here we show that there was and error with dosing of Fishmeal:

In report editor these flags will be displayed as red placeholder in format [E4.6]:

Timeline

Timeline allows you visually see events' start and end time, duration. Also it is easy to see order of running different events.

It is very easy to select what events to display on timeline. Simply clink on needed checkbox, pick a color and enter title (or register id in format [E1.2] instead of title to show value from this register) and all these events will be displayed on timeline automatically.

If you have many events or their duration is short, you can drag, pan and zoom on timeline to see more details.

Graph

If you have any long-term processes running during your event and you need to visualize their parameters Graphs control can be used. It allows you display any registers that has graph data and marked as “Send graph data to level2” on WebHMI.

Basic settings tab includes graph title, height of graph in pixels, Start and end of graphs's timeframe should be taken from event timings. You can get start time from one event and end time from another event if needed. But usually we get them from master event. Also here you can specify minimal and maximum value on Y axis.

On Regsiters tab you can pick registers that you want to display on current graph. Please note that here you will see not all registers on WebHMI, but only registers with storing graph data enabled and marked to send this data to Level2. You can override their title and color if needed.

On Events tab you can highlight some events on graphs with color background. Usually this is used to display some parts of technical process on graph.

Here is how graph can look in report editor. It shows sine waves and random event timings as sample data to see colors, etc.

And here is how real graph will look inside report: Here we can see 2 temperatures over 13 minutes during our sample report. From 4 till 7 minutes we see red color zone - heating process, and from 10 till 12 minutes we see blue zone - cooling process.

Such graphs can significantly help operators to enhance process performance, find sources of issues, etc.

Map location

For mobile laboratory applications it might be useful to see location in reports. For such situation Map Location control can be used. This control can get Latitude and Longitude from event registers and display them as marker on map.

Specifying time formats in Report builder

Please refer to the following link

level2/creating_advanced_reports_in_level2.txt · Last modified: 2022/01/14 16:06 by emozolyak

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki