Introduction
Overview
When to send Instance or Duration Events? What should I tag with it? What should I call it? How does it affect my reports?
Let our guide below help you make the right decisions
Events
Client Driven
Events are created with an Event Type defined by a unique name. Event Types are client driven, meaning that if an Event with a new Event Type is sent, the type will be created along with the Event.
Check your spelling!
Types intended to be the same but with slightly different spelling will be treated as a new Event Type!
However, Event Type names are case insensitive.
Shared event types
Event Types can be shared across different station types, for example "login" or "stoppage" might be common event types used by different Stations Types. This is fine.
Naming
Naming your Event Types is very important as it makes it easier to understand what you are reporting on.
Be Specific
Be as specific in your event name as you can be without mentioning the Station it came from.
| Description | Bad names | Better names |
|---|---|---|
| An error occurs while reading a barcode on a machine. | "Error" (Too generic), "Barcode Error" (Still too generic) | "Barcode Reading Error" |
| Starting a "No work" downtime duration | "Downtime" (Too generic), "No work" (When looking at "No Work" out of context, others might not know it's a Downtime) | "No work downtime" |
| Processing part of an order on a machine that applies labels | "Order processing" (lots of things process orders), "Label processing" (What part of label processing), "Label Application" (multiple widgets could require different labels) | "Widget X Label Application" (Differentiate between what type of label) |
Instance Events
Instance Events are those events that happen at a point in time and do not have a duration.
Examples: "Barcode Read Error", "Small Vial dropped", "Order arrived".
In some cases an Instance event is better treated as a Duration Event if it takes time to resolve. "Barcode read error" might make sense as an Instance however if you want to report on how long it takes to resolve "Barcode read errors", and you can determine that, then it's better to make them Durations.
Usages
Instances are useful for reporting on counts, throughput, quantity over time; where the amount of time relating to an Instance is not of any value. You can use the following reports for Instances:
- Bar Charts
- Line Graph / Trends (Plots them over time by counting how many happened every X minutes/hours)
- Pie Charts
- Gauges
Grouping by a Station or Tag for the above is available to help break down your results.
Duration Events
Duration Events are events that have a start and end time that are different - spanning a duration.
Examples: "Downtime", "Stoppage", "Meters rolled", etc.
If the time taken to resolve an event is not of concern or can not be obtained easily, and you simply need to know that an event occurred, then it's better to make them Instances.
Usages
You can use the following reports for Instances:
- Bar Charts (Either counting number of durations, summing, averaging or using the median time of the durations)
- Line Graph / Trends (Cumulative or grouping by a period of time along with the options mentioned in Bar Charts)
- Pie Charts
- Gauges
Tagging
It can be hard to know what to tag but if it's something you would like to report on or need for audit/searching purposes later on then it's worth adding it.
Tags are also client driven so be sure that your spelling is consistent otherwise you could end up with a tag for "order reference" and another for "order number" when they might be the same thing.
Recording an "operator" / "user" has a special field in our events that you can populate. It is better to use those than to tag an event with the current operator. Using the special username field in an event will allow you to make use of the User Summary table.
Stations
Stations come in all shapes and sizes but some are more limited than others. Below are the types of Stations and how we can help get them connected to Insight.
Online Stations
Typically, a modern Station is capable of sending a web request. If your Station can send a web request then you can follow the instructions in Integration > Sending Events.
Offline Stations
Offline Stations are those that cannot make web requests directly to Insight.
Capable, but no internet connection
If your Stations can make web requests, just not to the internet then this is where the Mediator could be very useful.
Sending events to some local server which in turn has internet access is what the Mediator can help with.
At least we have logs...
Many older machines cannot make web requests but do have some form of machine logging happening. Write a parser to process those machine logs and send events on its behalf.
If you don't have anyone to write a parser, contact us - we'll be happy to help.
We don't even have logs!
In this case, we can set up an IoT box to directly read the machine's IO and send events as needed.
We'll be happy to discuss your requirements and see how we can help.