HMI Recipe Management in TIA Portal: Records, Transfer and Batch Setup

• One recipe definition, many data records; adding a product should be a record, not a program change.
• Transfer with a handshake and validation, because an out-of-range parameter is worse than no parameter.
• Store records on the panel media and back them up; they are not inside the TIA Portal project.

Recipes, Elements and Data Records

Three terms, and mixing them up causes most of the confusion.

• Recipe: the definition. It says which parameters exist, for example mix time, temperature setpoint, fill volume, speed.
• Recipe element: one parameter inside that definition, linked to a PLC tag and carrying its own data type and limits.
• Data record: one set of values for those elements. Product A is a record, Product B is another.

Designed properly, a new product is a new data record entered by a production engineer. Designed badly, a new product is a PLC modification, a download and a shutdown.

Configuring a Recipe in TIA Portal

Open Recipes under the HMI device and work through the two tabs.

1. Elements: add one row per parameter with a name, the connected PLC tag, the data type and the display format. Set the upper and lower limits here so the panel refuses a bad entry at source.
2. Data records: add one row per product and fill in the values. Keep the record name meaningful, because this is what the operator selects.

Point every element at a tag inside a dedicated recipe data block in the PLC, not at scattered tags across the program. One structure keeps the transfer simple and the validation in one place.

Recipe settings

Be careful with Update tags. Combined with Synchronise, it can write values to a running machine while an operator is browsing recipes, which is exactly what a handshake exists to prevent.

Transfer, Handshake and Validation

The safe pattern separates the panel's copy of the values from the ones the machine is using.

1. The operator selects a data record and presses Load, writing the values into a request area in the PLC.
2. The panel sets a transfer request bit.
3. The PLC checks the machine is idle and not mid-cycle.
4. The PLC validates every parameter against its allowed range.
5. If everything passes, the PLC copies the request area into the active recipe area and sets an accepted bit.
6. If anything fails, it sets a rejected bit with a reason code and leaves the active values untouched.

The panel then shows the active values in read-only fields, so the operator can confirm what the machine is actually running rather than what was selected.

Why the PLC validates again

The panel already has limits on each element, but a SCADA station, a second panel or an engineering laptop can write the same data block. The PLC is the only place that sees every source, so it must repeat the check. The same principle applies to individual setpoints in HMI I/O fields and setpoint entry.

Operator Screens, Storage and Backup

Add a recipe view to a dedicated screen. Configure it as a simple view for panels with small displays, or the full view where the operator needs to see all elements at once.

• Show the selected record name and the active record name side by side.
• Protect Save, Delete and Load with a user authorisation so operators cannot edit recipes accidentally.
• Display the reject reason in plain text when a transfer is refused.
• Log every successful transfer with the record name, time and user, which gives you batch traceability for free.

Storage and backup

Data records live on the panel storage medium, not inside the TIA Portal project. Restoring the project onto a replacement panel therefore restores the recipe definition but none of the records.

Back up the records to a USB stick or network path, and test the restore. This is part of the panel handover described in HMI user administration and runtime settings. Sites with more than a few dozen products usually move recipe storage into SQL Server on a SCADA station instead, which also gives central editing and version history.