Save operator recipes from an HMI with no save button

The answer: store recipes in the PLC, not on the panel

The panel's recipe sheet stays what it is: a table of stored rows that the call recipe dialog writes onto your tags. The rows are edited through that dialog with Edit turned on, and nothing in it copies the current tag values back into a row. Check the current help and release notes for a save-to-sheet option before you build anything, then plan around what is printed there.

Sheet capacity is not the reason to leave the sheet. The recipe database of one common HMI line stores up to 99 sheets with 1000 recipes of 256 tags each per sheet, and its panels run out of physical memory far earlier than those figures. The reason to move storage into the PLC is the missing save press, and the PLC gives you three lines to build:

• Reserve one block of retentive memory per recipe slot, each block the same length as the running-parameter set.
• A save action copies the running values into the chosen block.
• A recall action copies a block back onto the running tags.

Two builds deliver those lines, and a third path holds things together until they exist:

• Store and recall pages: one recipe button per slot on each page, each button a data transfer between the running parameters and that slot's block.
• One indexed copy: a slot-number tag on the panel and one copy routine in the PLC that computes the block's offset from the slot number. No button count limit; the ceiling is retentive memory.
• The interim path: the call recipe dialog with Edit on, with the product name kept in a recipe field, until a build above is tested.

If your project runs a CODESYS visualization, the closest published variant is a second button set that saves HMI screen input to recipe storage; the builds below are for panels that give you nothing of the sort.

What you need

• The running-parameter list: the tags the process reads at changeover, in a fixed order. Count them; the count is your block length.
• One retentive block in the PLC per slot, each as long as the running block, plus the running block itself.
• A slot-number tag, 16-bit integer, for the indexed build.
• Two panel pages if you build transfer buttons: a store recipe page and a recall recipe page.
• The controller's printed retentive memory size, from its datasheet or selection tables.
• Access to the PLC data view for the acceptance test.

If the controller is not chosen yet, storage this size belongs in that decision: see choosing a PLC for recipe storage and one PID loop.

The interim path: the call recipe dialog with Edit on

1. Bind one recipe column to a string tag and use it as the product name. The default Name cell stays read-only in the dialog and its column cannot be hidden; on a 6-inch panel that column fills about half the dialog, so keep the Name values short and put descriptions in your own name field.
2. Place a call recipe object on the recipe page and turn Edit on.
3. Call the recipe to be changed, or a blank row for a new product.
4. Type each value into the dialog fields. The keypad shows the data type's full range, so a 16-bit signed field accepts anything from −32768 to 32767; put the working limits in the PLC logic, because the keypad will not refuse an out-of-range number.
5. Write the tuned values down before you leave the screen. The dialog is the only place they are entered, and calling the next recipe row overwrites the tags.

This path works the day you need it. It is also slow and depends on notes, which is why the builds below exist. On a CODESYS visualization, where recipes live as files, a refusal to save is a separate fault with its own repair: see fixing the CODESYS Recipe Manager when recipe files will not save.

Build store and recall pages

1. Fix the running-parameter list in one order and give the block a length in words. It never changes after slots exist.
2. Reserve one block per slot in retentive memory, in this project style V-memory, each the same length as the running block.
3. Build the store recipe page: one recipe button per slot, each configured as a data transfer from the running-parameter area into that slot's block.
4. Build the recall recipe page: one recipe button per slot, each a transfer from that slot's block back onto the running tags.
5. Store the product name inside each block and label the button with it, so the labels follow the product.

The result is a save button per slot and a recall button per slot, and the operator needs no training beyond finding the pages. The cost is drawing: every new SKU means new buttons on both pages and a download to the panel. That cost is acceptable while the SKU list is fixed and short, and it is why the indexed build exists. The same pattern, recipe blocks held in V-memory and recalled per batch, is documented for other panel families; storing recipes in V-memory for batch recall walks it step by step.

Scale past fixed slots with one slot-number tag and an indexed copy

1. Put a numeric entry on the panel bound to a slot-number tag, 16-bit integer.
2. In the PLC, compute the offset from the slot number: offset = (slot number − 1) × block length. Use the indexed or indirect addressing your controller's manual prints, and read the memory map from that manual.
3. Write one copy routine and run it both ways. Save copies block-length words from the running block to storage start + offset. Recall copies storage start + offset back onto the running block.
4. Range-check the slot number before any copy: with 20 slots, a slot number of 0 or 21 must start no copy.
5. Interlock the recall: let the machine logic accept the recalled set only after the copy reports done, so a changeover never starts on half-written values.

The operator types a slot number and presses Save or Recall. Button counts disappear, a new SKU needs only an unused slot, and the ceiling becomes the retentive reserve.

Example: sizing 20 slots for a 40-word recipe

A filling line runs 20 products and the customer adds a few each year. The running-parameter block is 40 words: 12 temperatures, 14 speeds and times, 6 counters, and 8 spare words for settings the customer will ask for later. These are the project's numbers; scale the arithmetic to yours.

Storage = slots × block length = 20 × 40 = 800 words. At 2 bytes per 16-bit word that is 1,600 bytes, about 1.6 KB. Add the running block and the retentive reserve is 840 words, 1,680 bytes. Check that total against the controller's printed retentive pool before the download; the PLC side of the sizing is the pool, and the panel side of the same job is its own calculation, covered in sizing an HMI project against panel and PLC memory limits.

The indexed copy uses the same numbers. Slot 17 gives offset = (17 − 1) × 40 = 640 words, so Save writes storage words 640 to 679 and Recall reads them back. Slot 1 maps to words 0 to 39 and slot 20 to words 760 to 799, and 800 words covers all 20 slots exactly. For headroom, size slots above today's count: 24 slots × 40 words = 960 words, 1,920 bytes, and the next new product then needs only an unused slot number.

Which build fits

Decision, case by case. A fixed list of 10 or fewer SKUs: store and recall pages, because two pages are faster to build than copy logic. A list that grows, or anything past roughly 20 SKUs: the indexed copy with spare slots in the reserve, since a button pair and a download per added SKU stops being affordable. The sheet with Edit: the interim path, and overflow storage for families you rarely run.

Check the save and recall cycle

1. Recall a known set, change two values and the name word at the panel, and save.
2. Recall a different set, then recall the first again. Both edited values and the name must return.
3. Open the PLC data view and compare the running words against the stored slot, field by field.
4. Cycle power on the PLC, recall the slot again, and confirm the values held. That step is what proves the blocks are retentive.
5. On slot pages, store two different sets to two slots, recall each, and confirm neither overwrote the other.
6. Run the first recall on the machine with drives stopped, and confirm each recalled value against the machine's allowed limits before release. Wire and prove the panel link the same way as operator panel PLC link setup: test writes before motion.

Recommendation: Put recipe storage in retentive PLC memory and give the operator a slot-number tag with one indexed copy routine for Save and Recall, sized as slots × block length against the controller's retentive pool. Choose store and recall pages only when the SKU list is fixed at 10 or fewer, because every added SKU then costs a button pair and a download. Keep the call recipe dialog with Edit on as the day-one interim path, and reserve spare slots at build time so the next new product is a slot number, not a project.

Questions