In this article, you will learn…
- How Tulip apps track machine data
- How to add machine data to your analytics for real-time visibility of your shop floor
- How to build apps that “complete themselves”
Many Tulip apps require operator input in order to progress through steps and get “completed”. (Quick reminder- Tulip apps must be “completed” each time they are run in order to track data.)
These apps are typically used in human-centric manufacturing processes.
Instead, you can create triggers that automatically complete the app based on events coming from the machine or device. This is known as a “headless” app because operators do not need to interact with the Tulip Player in order to track data.
This guide will show you how to create a headless app and organize data in the Analytics Builder. In order to understand this tutorial, you will need to be familiar with the following concepts:
- Form Steps
- How to track machine events with an IoT gateway OR
- How to create an OPC connector
What is a headless app?
There are two types of headless apps:
- Apps where the operator uses an external trigger to complete the app
- Apps where an event in a machine will automatically complete the app
Let’s look at an example of each.
App with External Trigger
Let’s imagine that you use a button to start a machine. The button has an external power supply and signal wires so that it can connect to the GPIO ports of an IoT Gateway. Then, when an operator presses the button, the app completes and logs data. Here’s what that looks like:
In this case, the operator stores data in the Tulip database without using a Tulip app on a computer or table. The operator doesn't need to interact with the app.
Machine Event Trigger
You can also trigger an app completion when an event comes from a machine connected to an IoT Gateway or OPC server. In this case, the app will automatically complete every time the event fires from the machine.
Here’s what that looks like:
In each case, you must build Triggers to complete the app after a certain event fires. But, before we cover that, let’s review some possible step designs that the operators can use to quickly understand a machine’s history.
Building Headless Apps in the App Builder
Yes, headless apps do not allow an operator to “complete” the app manually. But, they can still give an overview of the machine’s status in a step.
The example below is a one step app that is running on a machine. When an operator presses a button to start the machine, the app updates with the latest cycle time data.
Note: The button has its own power supply and is wired to an IoT Gateway via GPIO pins.
In this example, “prox_status” is variable text that shows the live value of a variable to indicate if the sensor has been triggered or not.
“Current Cycle Time” looks at the current time elapsed on the step using a pre-built variable.
Goal is a “Process Timer” that is set by the app developer.
“Average Cycle Time” is an embedded number analysis.
The app above can track whether the amount of machine uptime or downtime in a day, but it will not tell you why. This is why some Tulip customers combine a normal machine maintenance app with a headless app.
So, when a machine goes down, a lead operator or maintenance technician will inspect the machine, troubleshoot the issues and get it up and running back again. Then, they will use a Form Step in a normal app that is running on a tablet to report the reason and amount of downtime.
“Downtime reason” is a dropdown with all options shown as buttons.
“Downtime Minutes” is a number field.
After creating this app, you can create Analytics that total up the number of downtime minutes and group them by the value of the variable in “Downtime Reason” to find the most common reasons for downtime. Check out this guide to learn more about setting up that analysis. You can correlate the results collected in this app with the results collected in the headless app shown above. But let's see how the triggers work first.
Trigger Logic for Headless Apps
In order to successfully complete apps based on machine events, you need to know the average cycle time of the machine that the PLC or the program of the machine is set to. Then, you will need to align that with app completion times to track if a machine has been in use or has been experiencing downtime.
Here’s what that means. Let’s imagine that you have a machine with cycle time between 15 and 30 seconds. You need to create a trigger that will determine whether the machine has been in use or experienced downtime when it completes.
The machine starts when an operator presses a button that is hooked up to an IoT Gateway. The trigger below will successfully track uptime:
Here’s how it works:
- The “When” condition looks for any “pin up” event on a specific IoT Gateway.
- There are two “if” conditions. If the “pin up” event happens on the pin that is connected to the Gateway, then the first condition is satisfied. This pin number refers to the specific sensor connected to the gateway that fires on a specific machine action.
- This is a one-step app. If it has been open for less than 30 seconds, and the event fires, that means the machine just completed a cycle with an acceptable time frame.
- We can now proceed to the “then” statements. In the first statement, we store the “success” message in a variable called “prox_status.”
- The amount of time on the step is equivalent to cycle time in this case, so we store it as a number in a variable called “uptime”.
- We complete the app.
There is also an “Else If” statement that fires when the machine has been experiencing downtime.
Here’s how it works:
- It looks for a “Pin Up” event on the same pin as the first step.
- If the step has been open between 30 and 14,400 seconds, that means that it has been open for an unusual amount of time. There are 14,400 seconds in 4 hours, so in this case, 4 hours is the maximum amount of conceivable time where a machine could be down when it should be in use.
- If both of those statements are true, when the button event fires, the time that the app has been open will be stored as downtime, since it was longer than 30 seconds, which is the maximum amount of time for a cycle of the machine.
- The app is completed in order to store the data.
There is one more “Else If” statement that needs to handle the overnight period, where the machine is not expected to run (this factory has two shifts).
- If the correct pin fires, and it has been over 14,400 seconds since the last app completion, or over 4 hours, we will safely assume that this is not downtime. The facility would not count downtime for a machine that is down for that length of time.
- Then, we will cancel the app, and not count the time as uptime or downtime.
These statements will help you collect uptime/downtime data. Then, you will need to aggregate this data in the Analytics Builder.
Analytics for Headless Apps
Now, we need to set up analytics that constantly track uptime and downtime on daily, weekly or monthly increments. We will need to use the uptime and downtime variables from above to do that.
Enter the Analytics Builder, and create a Single Number analysis. Add the headless app, and then choose these two options:
Date Range: After 7 days ago (to see a rolling window of past 7 days)
Then, add this expression:
Here’s what it says:
ROUND((100 * (SUM(uptime) / 60)) / ((SUM(uptime)/ 60) + (SUM(downtime) / 60)), 2) + ‘%’
In other words,
uptime / (uptime + downtime)
First, we must use the SUM function to add the uptime and downtime values across all app completions from the past 7 days
Then, since all measurements are in seconds, we divide by 60 to turn into minutes.
Finally, we use the ROUND function to round it to 2 decimal places, then add a percentage sign at the end to make it readable.
Here’s an example of what that might look like: