If you are interested in building a manufacturing app that uses data from both humans and machines, Tulip could be a great fit for your production floor.
For example, if you want your operator’s app to use dynamic logic based on whether a machine is running or not, Tulip can help.
Or, if you just want to collect machine data alongside human data for later analysis, Tulip can also help.
In order to determine which machine data can be integrated into Tulip, you will need to know the following information:
- What protocol does the device use to share data? Common examples include OPC UA, MTConnect and Modbus.
- How will the machine connect to your network? Common examples include Ethernet cables or the GPIO interface in the Tulip Gateway.
- If you are currently capturing data from the machine, where is it located? And what is the format?
Tulip uses Connectors to work with external software and hardware. In addition to the standard HTTP and SQL Connectors, Tulip's Machine Monitoring module adds the capability to connect to machine protocols through the OPC UA Connector.
As soon as you integrate your machine data into Tulip, you can immediately combine it with human input in Tulip’s App Builder.
Here’s a quick introduction to how it works.
An Overview Of Tulip
This article contains an overview of how the entire Tulip system works.
If you want to connect Tulip to a device on the shop floor, you first need to think about how you will connect the device to your company’s servers, either on-premises or in the cloud. There are three common scenarios:
- An older machine connected to a Tulip Gateway- this is a device that may not already be connected to your servers, but can be connected to the Tulip Gateway via serial port, USB or GPIO.
- A “smart machine” that shares data via OPC UA- this can be connected to Tulip via a Connector
- A “smart machine” with a gateway- If you want to combine human input from an IoT device in Tulip’s Factory Kit with machine data, you will need an IoT Gateway.
The types of data that can be accessed in Tulip depend on the machine’s method for sharing data. Tulip will at least know simple facts like whether the machine is on or off. It may be able to access more advanced metrics, like the speed of a spindle or the pressure of an operation.
There are also potential workarounds when Tulip cannot natively work with the machine.
For example, you could attach a cheap vibration sensor to a Tulip Gateway and place the vibration sensor on top of a machine to measure whether it is running or not.
Or, when a machine turns "off", you can ask the operator whether it was intentional or not.
An Overview of Data Flow
There are three major steps in the data flow from machine to Tulip’s apps.
- The original machine that shares data via a predefined protocol
- Your company’s servers that store the data
- The Tulip Connector Host, which then shares data with the rest of the Tulip platform
The machines usually push data into your company’s servers. And then your company’s servers push data into Tulip’s Connector Host when certain events occur.
Here’s a diagram of that flow.
A Tulip engineer will help you send data from your server into Tulip. After that, it is up to you to decide how to use the new data.
For example, if you wanted to notify a maintenance team member when a machine is down for more than 10 minutes, you could create a Trigger that sends a text to the maintenance technician when the machine has not sent any data in the past 10 minutes.