In this article, you will learn...
How to decide whether to use one app completion or multiple completions to track a batch.
How to store details about a batch in a Table
Tulip uses "app completions" to track real-time shop floor data.
In other words, every time an operator presses the "Complete" button in an app, valuable data is recorded and can be analyzed using the Analytics Builder.
However, the "app completion" model is intended to fit one-piece flow. If your organization uses batches for discrete parts, there are still multiple ways that you can track accurate shop floor data.
This guide will help you figure out which app logic pattern is best suited for your process. For batches of discrete parts, you can either:
Complete the app after every part
Complete the app after the batch is complete
If you are interested in tracking a batch of chemicals or pharmaceuticals, check out this separate guide to traceability of continuous processes in Tulip.
Here's how to set up each pattern shown above for batches of complete parts.
App Completions After Every Part
If each part in the batch requires a lengthy operation, it may make sense to track each part in a separate app completion so you can gather better cycle time data on each part.
In the first step of the app, you might ask the operator to input the batch number before allowing them to continue to the work instructions.
You can do this with a Form Step:
This text widget stores its value in a variable called "batch_num"
Then, you will want to make this variable "persistent" so that it is not reset when the app is completed. If the batch number is persistent, you will not need to re-enter it until you start a new batch. You can do this by checking the "Persistent" checkbox in the Context Pane:
Then, you can ensure that the operator skips the first step on every subsequent part by using the "App" "Complete Then Change To Step" trigger at the end of the app to go back to the first step of instructions every time.
Here's what that trigger might look like on a "Complete" button:
Finally, you will need to create a "Start New Batch" button that will just go back to the first step so that you can change the persistent "batch_id" variable:
Completing the App At The End of Every Batch
Many of the concepts featured in the section above can also be used when there is only one app completion for a whole batch.
We generally see manufacturers complete an app at the end of every batch when each operation is very quick, and the operator needs minimal work instructions to do their job.
Here's what the flow might look like for app completions at the end of every batch of discrete parts:
Operator enters a batch number, as shown above
Work instructions begin
When work instructions finish, operator presses a button called "Part Finished"
IF there are more parts in the batch, the operator is sent back to the first instruction step.
ELSE if all parts in the batch have been finished, an "app completion" is triggered and the batch is finished.
So, the app would start with a Form Step like the one shown below:
The "Number of Parts" value would be tracked in a variable called "total_parts", shown below:
There is no need for persistent variables in this example.
Instead, you can use a series of work instruction steps, and the final step would have a "Part Finished" button. It might look like this:
When an operator presses "Part Finished", you will want to increase a counter that tracks the number of parts completed in the batch.
The first trigger on the button looks like this:
The trigger increments a variable called "part_counter" every time a part is finished.
Next, we need to check whether all parts in the batch have been completed. If so, the app can be completed. If not, we need to return to step 1 of the work instructions.
"Variable" "part_counter" "=" "Variable" "total_parts"
"App" "Complete App"
"Go To Step" "Instruction 1"
Tracking Batch Progress in a Table
The Tables feature allows you to track data about each batch and share that data between multiple apps.
So, if you want to access data about a batch from multiple workstations, you will need to store that data in a table.
Here's how to set up and update a simple table around batches of discrete parts.
Create a new table, and add two new columns:
Total Parts in Batch (number)
Total Parts Completed, Station 1 (number)
To connect the table to our app, we need to create a record placeholder in the App Editor. Let's call it "Active Batch".
Now, we will update that table with the Form Step from the previous example:
We need to add a "custom action" that fires when the "Submit" button is pressed. Then, we can create (or load) a table record and update the first number field.
"Table Records" "Create or Load Record" by ID: "Variable" "batch_num" into "Active Batch"
"Data Manipulation" "Store" data: "Variable" "total_parts" location: "Table Record" "Active Batch" "Total Parts in Batch"
Finally, we can update this table record each time that a part is completed. We need to add another statement to the first trigger on the "Part Finished" button, as shown above.
Here's the updated trigger at the end of the app:
"Data Manipulation" "Increment Value" value: "Variable" "part_counter" by: "Static Value" "integer" "1"
"Data Manipulation" "Store" data: "Variable" "part_counter" location: "Table Record" "Active Batch" "Total Parts Completed, Station 1"
Did you find what you were looking for?
You can also head to community.tulip.co to post your question or see if others have faced a similar question!