Inspection Functional Example

Inspection Functional Example (app-based)

Follow this how-to guide to build and track your inspection processes in Tulip.

Purpose

This Functional Example app walks the user through building an inspection solution for a product or an inspection procedure. It covers inspection set up, performing inspection, and analyzing inspection results. This is a learning resource and not a solution that can be deployed to your shop floor.

While most of the app introduces you to how the data is logged and shows you how to build steps for inspection checks, there are Steps that you can copy and paste to your own inspection app in the Step Group Templates.

Setup

There is no set up needed. This app only uses Variables data (i.e., Completion records). Variables are already configured.

How it works

Run the app in the Player and learn how to build your inspection for your products. Each step is a combination of how-to guidance (in the Introduction steps and in the green banners) and hands-on tests.

Introduction steps

The introduction steps will help you to understand Completion records in Tulip and how they are best set up when building an Inspection use case.

1. All the data from your inspections is collected in Completion records. They are immutable histories of any data entry action performed while running the app in the Player and saving the app data.

2. Triggers that will save all your app data are Save All App Data (an action) and any of the Complete/ Cancel transitions.

3. There are some best practices to make sure that completion records are clean and readable. For example, set the app name to be the name/ number of the product/ part to inspect, and create a label variable for your completions. Every time the app logs a completion record, the latter allows you to differentiate between completion records type (e.g., "Inspection Outcome" vs. "Follow-up Action Logged"). Your label values should be consistent within the app.

Functions steps

Product
An inspection procedure usually relates to a product/ part. Because there is a 1:1 relationship between inspection procedure and product/ part, this is encoded in the app. The operator can start the inspection procedure straightaway.

Serial Number
If each product/ part inspection has a distinctive serial number or identifier, it is worth recording it in the records in order to be able to analyze all the data relevant for that product/ part at a later stage.

Pass/ Fail
Some inspections require the operator to inspect the product/ part and enter whether it passes or fails the inspection based on their judgment. In the app, this is done with the buttons Pass and Fail. Each button will save, respectively, True or False into the variable Boolean Check.

Number Input
If the operator is required to enter a numeric value as the inspection output, this is done by using a numeric input field. The Submit button in the step simply moves the operator to the next stage, as the value entered is automatically stored in the value Number Input Check.

Ranking
If there is a set of standard values for the operator to enter, e.g., a value from a ranking 1-4, this can be set up by using a button for each value in the standard set. When the operator clicks on one of the buttons, the value associate (1, 2, 3, or 4) is stored in the variable Ranking Check.

Text Attribute Input
Sometimes the output of the inspection is not a simple pass/ fail nor is measurable with a number. If this is the case, a text input field will be the best option. As in the number input case, the Submit button simply navigates to the next step, as the variable connected to the text input field is automatically updated as the operator types.

Read Inspection Results
Ideally, the read inspection results step should be its own standalone app. This will ensure that only quality managers or supervisors from have access to a detailed view of the data collected from inspections.

Because of the amount of data generated as completions during an inspection procedure, it is best to set some filters to enable the quality manager or supervisor to display only the data they are interested in.

If you are not using this step as template for a separate app, you can still ensure that only quality managers or supervisors have full access to the data by using the Electronic Signature widget. The widget also allows you to select the data points that the reviewer will be signing.

Action
In the step folder Common, you will find a single step to which you are redirected whenever the operator marks a check as failed or if the numeric value is outside limits (in this app, limits are encoded in the app). Once the operator presses Log Action, the app completes.

Template steps

Opening the app in the App Editor, there is a folder with some template steps for each of the operational steps in the app. The logic of triggers and variables are replicas of the core app steps. To implement your own solution, you should customize these however you like by:

• Modifying the UI (colors, frames, etc.);
• Adding your own specifications to the app logic and overall look (part/product, specification limits, etc.);
• Combining steps and techniques from this functional example with other functional examples'.

Further Reading

• How to Complete an App
• How To Create And Use Variables
• How to use the e-Signature Widget