HMI Recipes used in production processes are stores of data, specific to a particular product, which can be called up on demand and then implemented to produce the product. Each recipe includes a set of parameters important to the production process. For example, if a bakery is making ten different products, each will have its own recipe in terms of ingredients, mix times, bake temperatures and other variables. The same could be true for the packaging line in the bakery, as it will also have different settings depending on the specific product being packaged.
Einstein Chimes In
Albert Einstein once said that everything should be made as simple as possible, but not simpler. This certainly applies to recipes, and perhaps the most important simplification step is to include only the parameters changing from one recipe to the next. Steps and procedures remaining the same from one product to the next and anticipated to remain that way don’t belong in the recipe, but should instead be hard coded into the control system.
In our bakery example, bake temperatures might change from one product to the next and would thus be a recipe parameter, but mixing speed would remain constant if the mixer only has a single speed motor. Best practices are to err on the side of caution and add all parameters which might change in the future, as it’s much easier to include these parameters up front rather than adding them later.
Now that we know what recipes are, let’s see why we might use them.
Why are Recipes Used?
Recipes are only applicable when multiple products are being produced. When only one product is being made, then the parameters for its production are simply stored in the automation system, and repeated time after time.
But when multiple products are being made and the production parameters vary among them, recipes provide a means to quickly and accurately change from one product to the next.
The alternative is to have an operator change the required parameters for each product manually, often by entering data on an HMI screen from a recipe sheet, a time-consuming and error-prone process.
If you’ve read this far, your facility probably makes multiple products and you see the value of recipes. So, your next logical question is where recipes should be created, stored and modified.
Where are Recipes Stored?
The two main options for recipe creation and storage are the HMI and the controller.
Recipe storage at the controller is only practical when there is just a handful of simple recipes and just one controller. Creating, viewing and modifying recipes in this manner can be cumbersome as most controllers don’t contain any specific recipe functionality, forcing the programmer to perform custom ladder logic or script programming for each.
But most HMIs, on the other hand, come with recipe functionality built-in to allow easy creation, storage and selection of recipes. When recipes are stored in the HMI, they are selected at the HMI and then downloaded to the controller for execution.
Multiple Controllers and HMIs
For systems with multiple controllers, each with its own recipe parameters, HMI recipe storage is the only practical option. For example, a bakery might have a controller for the production process, and a second to control and monitor packaging. In this and other instances, the HMI is used for recipes, with appropriate parameters downloaded to each controller.
What about systems with multiple HMIs? In this case, the recipes will typically be stored at the main HMI as it fulfills a supervisory role over the entire production process.
Going back to our bakery example, a PC-based HMI like AutomationDirect’s Point of View® might be the supervisory HMI and thus contain the recipes. AutomationDirect’s C-more® embedded HMIs could be positioned at strategic locations along the production and packaging lines to provide local operator interface, but not recipe functions, even though they posses that functionality.
Although many embedded and PC-based HMIs come with recipe functionality, successful implementations require following specific steps.
How are HMI Recipes Created and Used?
The first step is to create the master recipe containing all of the variable parameters for each recipe. As previously mentioned, it’s important to omit constant parameters which don’t change from one product to the next in the recipe. The next step is to define and create the recipe destination tags in the controller program, as these tags will receive the recipe source data from the HMI.
The recipe function in an embedded HMI, such as the AutomationDirect C-more, provides a simple and effective method to create, save, edit and store recipes. It also permits easy downloading of recipes to controllers.
The C-more uses both a recipe database and recipe sheets. The recipe database enables the creation, viewing and editing of recipe sheets. Each recipe sheet can have up to 1000 recipes (rows) and the database can hold 99 sheets. Recipes are entered as single rows in the sheet, with each row having 256 columns. The first column is the text name of the recipe, and each of the remaining columns contains a recipe parameter.
With a PC-based HMI, even more recipe options are available as there are virtually no limits on the number of recipes and the number of parameters in each. AutomationDirect’s Point of View, and many other PC-based HMIs, require the purchase of an optional recipe module. Using this module, recipes can usually be created and stored either locally at the PC, or in an external database.
