Using the duration of on-change captured statuses in OEE visualizations and calculations

I have a work order run status read into Ignition via an API and added into an UDT on change.
image

What I would like to do is track the amount of time the equipment was in a given run status - both for OEE calculations and also to present this information visually over given time intervals. EG hourly, by shift, daily, user-defined range.
For the visual, I'd like to make something like this:

I have to rely on a separate (manual) MES system for run status because we primarily use Ignition for data collection and monitoring rather than as a control system. I can't track run status at the machine level yet (for these machines).

So far, I have figured out how to grab the status and its timestamp on change, and load it into a table like this:
image

I'm not sure how to use these timestamp-difference time frames in a way I can visualize/analyze and say for example "it was in run from 2-4 then it was in problem from 4-5, so from 2-5 we had 67% machine availability." (And also only measure machine performance from "Run" status periods)

Any help is appreciated!
Thanks.

For our internal Ignition Module, as well as Sepasoft an integer is used as the state so for instance:
1 = running, 2 = stopped, 0 = idle
You would then track them with a start time, and you can track end time if you want, or you can use the begin time of the next state for that machine. this gives you a timeseries effectively of what the machine was doing. It is just a list of start and end datetimes that give you what you are looking for.

For visualization, you can use a bar chart to achieve this, however you can run into issues with the number of events you have and how the chart can handle the rendering of those states.

Generally, you need to have a custom database schema, or use a third-party module to get into actual complex OEE (as if you really mean OEE you will need more than just is my machine running). It gets exceptionally complicated when you have to consider what types of rollups you want. For instance we can implement a Site > Line > Area > Machine model which may have some key cell detection where My line is tied to Area 1 for downtime because that is my identified bottleneck, but I may not have a bottleneck and I just do initial cell to say whatever downtime is at my children is my downtime and then it's a queue to get back to running potentially.

Thanks for the reply!

Can you please explain how to do this:

You would then track them with a start time, and you can track end time if you want, or you can use the begin time of the next state for that machine. this gives you a timeseries effectively of what the machine was doing. It is just a list of start and end datetimes that give you what you are looking for.

I'm most interested in how to capture these timestamp differences and visualize/use them for calculations (I have used datediff to get a "current status duration" measure for the most recent status change, but I'm not sure how to apply this or another method to collecting the differences between the timestamps.
image

From what you're saying, I could transform each status string value into an integer, which I get, but I'm not sure how to configure the time component of the data for use.

Thanks for your help

In doing something similar, I stumbled upon this visualization in the Ignition Exchange. I've had good success with it and would recommend it to you as it looks like it could accomplish your goal. Once you provide the input parameters and enumerations for your machine state, it should populate the ribbon chart. The components do a nice job of outlining what needs to be provided.

Ignition Exchange | Inductive Automation

I have also used this in the path.

Keep in mind that graphs in Ignition Perspective cannot handle thousands of datapoints and also animations etc. This just means if you have a piece of equipment that changes state a lot, say 1000 times a day you may want to aggregate the states, or, and more likely than not, you need to reassess what you consider a downtime.

An example of what I mean is if you have a machine that produces a sand mold onto a conveyor to be filled at a pouring station, that machine may idle while the conveyor moves forward and for the next mold to be placed. You may want to track this idle time, but you need to consider what is really idle time. What are your thresholds for when a true non-running condition is. This will help reduce noise in the data and allow for your visuals to also benefit.

This is true for Perspective, out of the box.

While this topic is tagged for Perspective, that blanket statement is simply false for Vision.

Correct! I suppose I didn't think to mention that due to the tag. Thank you for pointing that out though.

Edit made :white_check_mark:

Definitely not a volume issue - this status changes maybe 10-20 times during a day. Thanks for the insight all, going to try to make the ribbon chart work.