This is an example of an inline quality inspection app that could be used to support a manual inspection process.
This app assumes that each item being inspected is associated with a unique work order or other unique ID in barcode form.
The app is designed to enable an operator to conduct an inspection of a single item and mark the item as either:
- Good unit produced
- Rework required
This app has the added benefit of being able to report this data real time to a production dashboard.
Step by Step Walkthrough
The app is pretty simple, it begins with a barcode of the work order (or any barcode uniquely identifying this unit).
After the barcode is scanned the app automatically progresses to the inspection step.
On the inspection step, the operator will compare the unit to an image of a known good part, and record the status of the part.
If the part is good, the app will complete.
If the unit requires rework or is deemed to be scrap the app will prompt the associate to report additional information to help identify root cause of the issue.
All of the information being collected in this application can feed real time production dashboards. These dashboards are useful to report progress made against a daily target.
Review of App Logic
Now, let’s take a look at the logic that’s driving this application. To do that, we’ll need to enter the App Builder. The "Inline QA and Production Visibility App" is already available in your account in the "Visibility" category.
Go to the first Step, "Scan Work Order".
You’ll notice that there is a trigger listed on the Step tab of the Context Pane along the right labeled, “Next on Barcode Scan.”
Clicking the pencil icon along the right opens up the Trigger Editor to reveal the underlying logic.
- When a barcode is scanned at this Station
- Then perform two actions
- First save the scan as a variable called “Work Order / Item UID”,
- Then go to the next step.
Based on the logic in this trigger, scanning the barcode will save the UID of the item being inspected and then automatically progress to the next step.
It looks like this:
The next screen in this app shows the operator an image of the item being inspected and asks the operator to record this item as:
by selecting the appropriate button along the bottom right of the screen.
Clicking any of these buttons from within the App Builder will reveal the Widget tab in the Context Pane along the right.
Let’s take a look at what happens when the associate presses the “Good” button.
Again, we can open the Trigger Editor by clicking the pencil at the right of the trigger for this button.
- When the button is pressed
- Then perform three actions:
- Increment the variable “quality_inspection_passed” by 1
- Increment the variable “production_count” by 1
- Complete this run of the application
Any dashboards reporting on this line will reference these variables.
After the app is “Completed” it will return the operator to the first screen and they will be ready to scan the next Work Order or the unique ID of the next item to be inspected.
Now, let’s take a look at what happens if the associate presses one of the other two buttons indicating that the item being inspected is either scrap or rework.
You’ll notice that the logic is similar. However, instead of incrementing the variable “quality_inspection_passed” we’re incrementing a different variable called “rework_count.”
You’ll also notice that instead of completing the app to inspect the next part, we are going to a different step to capture more information about the defect, below.
The final step of this app is a “Form Step.” This step is designed to let the operator enter additional information about the specific defect encountered.
As with all widgets in Tulip, each of these fields is completely customizable. The purpose of this step is to provide granular reporting around defects to identify the root cause effectively.
Feel free to explore our other step by step guides for more ideas for building apps in Tulip.