Define the recipe parameters once as a PLC data type, keep a Request and an Active area in DB_Recipe, and let the HMI recipe write only to Request. The PLC validates idle state and every range before copying Request to Active, and the machine runs only on Active values.
- One recipe definition, many data records: a new product is a record, not a program change.
- The panel writes Request, the machine reads Active, the PLC decides – after validation.
- Data records live on the panel media, not in the TIA project; back them up.
Recipes, Elements and Data Records
A recipe is the definition of which parameters exist; a recipe element is one parameter linked to a PLC tag with its own type and limits; a data record is one set of values, normally one per product. Designed properly, a new product is a new record entered by a production engineer. Designed badly, it is a PLC change, a download and a shutdown.
| Element | PLC member | Type | Range |
|---|---|---|---|
| Mix time | Request.MixTime | Int, s | 30 – 600 |
| Temperature setpoint | Request.TempSP | Real, °C | 20.0 – 95.0 |
| Fill volume | Request.FillVolume | Real, l | 5.0 – 200.0 |
| Mixer speed | Request.MixerRPM | Int, rpm | 50 – 1500 |
Lab Flow: From Mixer Signals to a Tested Recipe Screen
Stage 1Field Wiring and PLC Tag Table
Mixer M5 is a VFD-driven agitator. The field gives a start push button, a running feedback from the drive relay and a lid switch; the PLC drives the run command and an analog speed reference.
| PLC tag | Address | Type | Device |
|---|---|---|---|
S30_StartMix | %I4.5 | Bool | Batch start push button, NO |
M5_Running | %I4.3 | Bool | VFD relay output, 1 = running |
B21_LidClosed | %I4.4 | Bool | Lid switch, NC, 1 = closed |
M5_Run | %Q1.5 | Bool | VFD run command |
M5_SpeedRef | %QW80 | Int | VFD speed reference 0 – 27648 = 0 – 1500 rpm |
Stage 2Input Mapping into DB_IO
// FC_InputMapping – mixer signals "DB_IO".S30_StartMix := "S30_StartMix"; "DB_IO".M5_Running := "M5_Running"; "DB_IO".B21_LidClosed := "B21_LidClosed";
Same rule as every lesson in this series: these are the only lines that touch %I for the mixer. The structure is explained in HMI alarm configuration: IO mapping and alarm mapping.
Stage 3Logic: Request/Active Areas and Validated Transfer
// PLC data type UDT_Mix MixTime : Int; // s, 30 … 600 TempSP : Real; // °C, 20.0 … 95.0 FillVolume : Real; // l, 5.0 … 200.0 MixerRPM : Int; // rpm, 50 … 1500 // DB_Recipe (DB40): Request : UDT_Mix; Active : UDT_Mix; // Cmd_Load, LoadOld, Accepted, Rejected : Bool; RejectCode : Int;
// FC_RecipeTransfer – validate the request, then copy it as one block
IF "DB_Recipe".Cmd_Load AND NOT "DB_Recipe".LoadOld THEN // rising edge
IF "DB_IO".M5_Running OR "DB_Mix".CycleActive THEN
"DB_Recipe".RejectCode := 1; // machine busy
ELSIF "DB_Recipe".Request.MixTime < 30 OR "DB_Recipe".Request.MixTime > 600 THEN
"DB_Recipe".RejectCode := 2;
ELSIF "DB_Recipe".Request.TempSP < 20.0 OR "DB_Recipe".Request.TempSP > 95.0 THEN
"DB_Recipe".RejectCode := 3;
ELSIF "DB_Recipe".Request.FillVolume < 5.0 OR "DB_Recipe".Request.FillVolume > 200.0 THEN
"DB_Recipe".RejectCode := 4;
ELSIF "DB_Recipe".Request.MixerRPM < 50 OR "DB_Recipe".Request.MixerRPM > 1500 THEN
"DB_Recipe".RejectCode := 5;
ELSIF NOT "DB_IO".B21_LidClosed THEN
"DB_Recipe".RejectCode := 6;
ELSE
"DB_Recipe".RejectCode := 0;
END_IF;
IF "DB_Recipe".RejectCode = 0 THEN
"DB_Recipe".Active := "DB_Recipe".Request; // same UDT: one assignment
END_IF;
"DB_Recipe".Accepted := "DB_Recipe".RejectCode = 0;
"DB_Recipe".Rejected := "DB_Recipe".RejectCode <> 0;
END_IF;
"DB_Recipe".LoadOld := "DB_Recipe".Cmd_Load;
// FB_MixCycle (instance DB "IDB_MixCycle") uses ONLY the Active values, e.g.
// #tMix(IN := #Mixing, PT := DINT_TO_TIME(INT_TO_DINT("DB_Recipe".Active.MixTime) * 1000));
// FC_OutputMapping – speed reference to the VFD analog input
"M5_SpeedRef" := REAL_TO_INT(SCALE_X(MIN := 0.0, MAX := 27648.0,
VALUE := NORM_X(MIN := 0, VALUE := "DB_Recipe".Active.MixerRPM, MAX := 1500)));
"M5_Run" := "DB_Mix".CycleActive;
The batch start itself should follow the permissive pattern from PLC interlocks and permissives (lid closed, no active fault, valid recipe), and the mixing steps fit the state machine shown in the sequence status screen lesson.
Stage 4HMI Tags and the Recipe RCP_Mix
- Drag
DB_Recipeinto the HMI tag table. TIA Portal creates tags such asDB_Recipe_Request_MixTimeandDB_Recipe_Active_MixTime. - Open Recipes, add recipe
RCP_Mix, and on the Elements tab add four elements linked to the four Request tags, with display names, units and the limits from the table above. - On the Data records tab add Product A, B and C with their values.
- In the recipe settings, set the data record path to the SD card and size the number of records for the product range plus growth. Leave automatic tag updating off so browsing records never writes to the PLC by itself.
| HMI tag | PLC member | Used by |
|---|---|---|
DB_Recipe_Request_* (4) | "DB_Recipe".Request.* | Recipe elements |
DB_Recipe_Active_* (4) | "DB_Recipe".Active.* | Active value fields ④ |
DB_Recipe_Cmd_Load | "DB_Recipe".Cmd_Load | Activate button ③ |
DB_Recipe_RejectCode | "DB_Recipe".RejectCode | Status field ⑤ via text list TL_Reject |
Stage 5Link the Recipe View and Status Graphics
| # | Object | Properties | Tag / event |
|---|---|---|---|
| ① | Recipe view RV_Mix | Recipe RCP_Mix; show record selection and element values with units | Elements → Request tags |
| ② | Recipe view toolbar | New, save, delete protected by authorisation Recipe edit; write to PLC copies the record into Request | Built-in buttons |
| ③ | Button ACTIVATE RECIPE | Authorisation Operator | Press: SetBit, Release: ResetBit DB_Recipe_Cmd_Load |
| ④ | Output fields Active values | Read-only, same units as the elements | DB_Recipe_Active_* |
| ⑤ | Symbolic output field status | Text list TL_Reject: 0 Accepted, 1 Mixer running, 2 – 5 value out of range, 6 Lid open | DB_Recipe_RejectCode |
| ⑥ | Traceability line | Product, user and time of the last accepted load, optionally logged | Data log or report |
User groups and the backup of data records are covered in HMI user administration and backup; individual setpoint fields in HMI I/O fields and setpoint entry.
Stage 6Perform and Test: Animated Recipe Screen and Mixer
Select a product record, write it to the PLC request area, then activate it. The PLC logic checks that the mixer is idle and every value is in range before copying Request to Active. Edit a value out of range or try to activate while the batch is mixing, and watch the rejection reason. Start a batch to see the mixer run with the active values only.
| Record | Mix time s | Temp °C | Fill l | RPM |
|---|
Troubleshooting Recipes
| Symptom | Likely cause | First check |
|---|---|---|
| Activate does nothing | Cmd_Load not linked or no rising edge | Watch DB_Recipe.Cmd_Load while pressing |
| Always rejected with code 1 | M5_Running or CycleActive stuck at 1 | DB_IO.M5_Running and the batch sequence |
| Machine changes speed while browsing records | Automatic tag update enabled and elements linked to Active | Link elements to Request only |
| Records missing on a new panel | Records were never backed up | Restore from the panel backup |
Hands-On Lab: Mixer Recipe with Validated Transfer
Hands-on- TIA Portal with WinCC Comfort and a panel or PLCSIM + HMI simulation
- Simulation only, no live batch
- Estimated time: 75 minutes
Wire the mixer signals and map PLC tags
Declare S30_StartMix, M5_Running and B21_LidClosed as inputs and M5_Run and M5_SpeedRef as outputs in the PLC tag table.
Map inputs into DB_IO
Copy the three inputs into DB_IO in FC_InputMapping.
Create UDT_Mix, DB_Recipe and FC_RecipeTransfer
Define UDT_Mix, add Request and Active areas plus the handshake bits, and write the validation and copy logic; drive the mixer only from Active values.
Create the HMI recipe and tags
Drag DB_Recipe into the HMI tag table, create recipe RCP_Mix with four elements linked to the Request tags and three data records.
Link the recipe view and status graphics
Add the recipe view, the Activate button, the active-value output fields and the reject reason text list, protected by user authorisations.
Perform and test
Activate valid and invalid records, try activating during a batch and confirm that only accepted values ever reach Active.
Recipes reach the machine only through a validated copy, the operator always sees the active values and the reason for a refusal, and records are protected by user rights.
Frequently asked questions
What is the difference between a recipe and a data record?
The recipe is the definition of which parameters exist and which PLC tags they map to. A data record is one set of values for those parameters, normally one per product.
Where are recipe data records stored?
On the panel storage medium such as the SD card or USB stick, not inside the TIA Portal project. They must be backed up separately – see the user administration and backup lesson.
Why should the PLC validate recipe values again?
Because the data block can also be written by SCADA, a second panel or an engineering laptop. Only the PLC sees every source, so only the PLC can guarantee the range check.
Can a recipe be downloaded while the machine is running?
It should not be. The PLC checks that no batch is active before accepting a transfer, otherwise parameters change mid-batch and the product is out of specification.
Why separate a Request area and an Active area?
The panel only ever writes Request. The machine only ever reads Active. The copy from Request to Active happens in the PLC after validation, so a half-written or wrong record never reaches a running process.
How should the recipe structure be defined in the PLC?
As a PLC data type (UDT) used twice in DB_Recipe, once for Request and once for Active, so the validated copy is a single assignment and both areas always have the same layout.