In this guide, you will learn:
- How to organize OPC UA tags on the Machine Monitoring page
- How to create app logic around OPC UA events and statuses
If you have a functioning OPC UA server with tags that you would like to connect to Tulip, then you are ready to use the Connectors page and create your first machine monitoring app.
This guide will show you how to create a simple app that reacts when a machine goes offline. It will present a series of choices to the operator or supervisor to indicate why the machine went offline.
If the machine is functioning normally, you will also learn how to automatically store data about uptime.
By the end of this article, you will understand how to capture data points that can later be used to calculate OEE.
Please note: this article will cover machine monitoring for standard Tulip accounts hosted in the cloud. If you deploy Tulip on premises, you will need to speak to a Tulip representative to use machine monitoring.
There are four steps needed to accomplish this:
- Set up an OPC UA connector on the Machines page
- Map your events on the Machines page.
- Build a Trigger that reacts to an event from your machine
- Design your app so that it stores the correct data and presents the correct steps to operators
Setting Up An OPC UA Connector
First, click into the Machines option under the Shop Floor tab on the Menu Bar.
Then, click “Add Connector” on the Connectors tab.
Name your connector and hit "Save"
Then click "Add Connection Details."
After that, you will have 4 fields to fill in:
- Running On
- Agent URL
For the “Running On” field, choose “Cloud Connector Host” unless you have a special setup that you have discussed with a Tulip representative.
For the “Agent URL” field, you should have a local TCP server with an IP address and port. If you are using a service like Kepware, this will be exposed in the UI. For example:
Then, you will need to add a redirect so that cloud services can access this IP address. Here’s an example of a redirect that is accessible in the cloud:
Add this string to the “Agent URL” field. Hit “Test” to see if you can successfully connect to the server.
If the test is successful, then you are ready to setup a machine. Click the "Machine Library" tab to set up a machine.
Mapping Your Events on the Machine Page
You will need to create your machine in Tulip, and select from a list of tags in a node tree that are shared by the OPC server.
First, click "Create Machine".
Then, name the machine and select the OPC connector that you just created. Add the Station where the machine is running.
Then, choose "Select Machine Node" to choose the node from the server that contains all the relevant tags. Hit "Select" on the appropriate node.
Alternatively, if your tags are organized under different nodes, you can just hit "Next" and add them individually.
A “tag” gives a unique identifier to an I/O point. You have probably configured these yourself, or they may be provided by the machine by default.
Tulip automatically treats all tags as discrete events, for example, an emergency stop button, completion of job, or a scanned barcode.
After you have selected or a node, a list of fields will automatically populate the next screen.
You can manually add new fields, or select existing machine attributes if you have already created them. This is not required, however.
You will use these tags in the Trigger Editor. Click the "Save" button to create the machine.
There are two types of machine monitoring apps you can build:
- Apps that take human input- these are apps where operators must complete the app
- Headless apps- these apps do not require human input, and can be completed upon a certain event in a machine.
This guide will cover common patterns that are used in each type.
Using the Trigger Editor
Let’s imagine that you want to create an app that opens a specific step when the machine goes offline. The step might look something like this:
This would give an operator or maintenance technician an instant overview of the machine’s performance from that day.
You would need to create a trigger that would open this specific step upon an event in the machine. Let’s say that there was an event called “Alarm” that fires when the machine goes offline.
Your “When” Statement in the Trigger Editor should watch for this alarm:
- “Specific Machine”
- Outputs “Alarm”
Then, you could add 2 then statements. One would go to the “Downtime” step, shown above. The other would alert a maintenance tech about the issue.
Then Statement 1
- “Go to Step”
Then Statement 2
- “Send Email”
- To maintenance tech
- Message: “Spindle is down”
If you wanted to create a headless app, you would not need to take operator input in the App Builder. Instead, you would create trigger logic that would complete the app when a certain event fires from the machine. Then, it would automatically restart to wait for the next event.
Designing an App With Machine Monitoring Triggers
Let’s imagine that you wanted to design an app with the following functionality.
- When app starts, operator must press button to indicate machine has started. This starts a timer for how long the machine has been running.
- If the machine completes its runtime without stopping, the operator must register the number of defective parts at the end, and the types of defects. Then, they complete the app.
- If the machine does not successfully complete the batch and goes offline (or the operator hits the emergency stop button), an email is automatically sent to a supervisor. The app enters an offline step and begins tracking offline time.
- When the machine starts again, the operator must enter a reason that the machine went offline. This completes and restarts the app.
Here’s the first step that would allow the operator to indicate the job has started.
When they press “Start Production”, they would be sent to a step called “Running” which would show live statistics about the machine.
This would have a trigger that would fire upon step closing, and save the amount of time elapsed on the step in a variable called “timeRunning”.
This is the “Then” statement:
- “Data Manipulation”
- “App Info”
- “Time Elapsed on Current Step”
- “timeRunning” variable
Then, let’s say the operator hits “Reject Part” at the bottom of the step shown above. This would take them to a “Select Defect” step where they would choose from a list of defects.
Each button has a trigger that will store the type of defect in a variable called “Defect Cause”, then complete the app.
Let’s imagine the machine did not successfully complete the part, and instead went offline. We would need a trigger on the “Running” step to watch for the offline event, and send the operator to the “Offline” step.
Just like the “Running” step above, the “Offline” step would track the amount of time elapsed on step until the operator hits “Go Online”.
When the operator presses “Go Online”, they will be prompted to enter the reason for downtime with the “Select Downtime” step.
Just like above, each button would update a variable with the reason for downtime and complete the app.