Why the HMI Shows the New Recipe While the Machine Still Runs the Old One

Thirty minutes into a changeover, quality calls. The screen shows the new product recipe, but seal temperature is still yesterday's value. Open the tags and HMI_SelectedRecipeId has changed while PLC_ActiveRecipeId has not. Either the download never started, or it started and was refused. The screen did not distinguish between the two. The diagram below is the minimum sequence that makes that distinction possible — the HMI writes parameters to a staging area, writes recipe id, version, parameter count and checksum alongside them, increments a request number, and the PLC returns accepted or rejected with a reason code. The point is comparing the last arrow against the second one.

One tag cannot hold three states

Put everything in a single RecipeName tag and the plant will get confused, reliably. What the operator picked, what the PLC received and validated, and what the current cycle is actually running can all differ — and the moment things go wrong is exactly the moment those three diverge.

The split is not an invention. It is the same reason IEC 61512-1 (ISA-88) separates a master recipe from a control recipe: the recipe bound to one batch and executing is a different object from the one sitting in the library.

State	Example tag	Purpose
Selected recipe	HMI_SelectedRecipeId	What the operator picked on the screen.
Download request	RecipeDownload.RequestId	Command that starts the parameter transfer.
Downloaded recipe	PLC_DownloadedRecipeId	What the PLC has received and checked.
Active recipe	PLC_ActiveRecipeId	What the current cycle or batch is using.
Recipe version	RecipeVersion or checksum	Detects stale copies carrying the same name.
Download status	Idle, Busy, Accepted, Rejected, Timeout	Drives operator feedback and interlocks.

The screen wording has to follow the same split. "Selected", "staged", "downloaded" and "active" each get their own label. One ambiguous line saying "current recipe" gets read differently by every shift. A good share of changeover problems start with that line.

Use a request number, not a request bit

On a small machine a recipe is ten registers. On a large one it is several hundred tags. Do a blind block write there and report only success or failure, and commissioning will catch nothing.

The sequence from the diagram, written out:

1. HMI writes parameters to a staging area.
2. HMI writes recipe id, version, parameter count, and checksum.
3. HMI increments a request number.
4. PLC validates count, checksum, ranges, and current machine mode.
5. PLC copies the staging values into the download buffer.
6. PLC returns accepted or rejected with a reason code.
7. HMI displays the result and logs the request id.

Step 3 should be an incrementing number, not a toggled bit. If a bit is left set after a restart there is no way to tell a new request from last week's leftover. With a number, the PLC holds the last one it processed and ignores a repeat — retransmission becomes safe for free.

Step 5 is the one implementations skip. Run straight out of the staging area and a transfer cut halfway through leaves the machine running a half-written recipe.

The semiconductor equivalent has the same shape: in SEMI E5 Stream 7, S7F1 Process Program Load Inquire sends the PPID and the body length first so the equipment can grant or refuse, and only then does the body go down in S7F3. Negotiate first, transfer second.

What to reject before the PLC sees it

The PLC still has to defend itself. But catching what you can in the HMI or recipe service is better, because that is the layer that can give the operator a sentence they can act on.

• Minimum and maximum engineering limits per parameter.
• Step limits — ramp rate, or maximum change from the previous product.
• Unit consistency, especially for a recipe copied in from another line.
• Required fields: product code, material grade, tool number.
• Mutually dependent parameters, such as speed versus dwell time.
• Mode constraints, such as download allowed only in idle or setup.

Limits do not belong only in a PDF. Store them as system data alongside the recipe definition. When a value is approved in MES but rejected at the HMI, the two systems should at minimum name the same rule or show the same reject reason, or the conversation goes nowhere.

"Download failed" is not a message

Those two words let neither the operator nor maintenance decide what to do next. Which value blocked it, or which machine condition, has to be on the screen.

• Seal temperature high limit: 215 °C is above recipe limit 200 °C
• Machine must be idle before recipe download
• Recipe version 18 is not approved for Line 2
• PLC checksum mismatch after parameter transfer
• Parameter count expected 64, received 62

Keep a numeric code next to the text. The HMI language, the PLC comments and the support ticket will all word it differently; the code is what lets you tell whether it is the same problem.

Compare what came back

A download is not finished when the HMI finishes writing tags. If you take one thing from this article, take that. The PLC has to echo what it received and on what terms it accepted it, and the HMI has to compare that against what it sent.

• Accepted recipe id and version.
• Checksum or signature the PLC computed.
• Parameter count the PLC received.
• Completion timestamp from the controller or SCADA server.
• Reject code and the index of the first failed parameter.

For critical setpoints, put requested and accepted side by side on screen during commissioning. Scaling errors, integer rounding, shifted array indexes and stale values all surface right there. Remove the display once you are in production if it bothers you.

Rules for overwriting a running batch

They differ by process. A packaging line can stage the next product while the current one finishes. A batch reactor should refuse any process parameter change after charging starts. Either way the rule belongs in logic, not in a document.

• Download allowed only when the equipment is idle.
• Next recipe may be staged while the current active recipe stays untouched.
• During running, only non-critical labels are editable.
• Limit changes require the engineering role.
• MES approval required before production use.
• Manual override writes an audit event with a reason.

Make it fail on purpose during commissioning

Watching one clean download succeed proves very little. What production needs is the recovery path when it does not.

Test	Expected result
Valid recipe while idle	PLC accepts; echoed id/version/checksum match.
Out-of-range parameter	HMI or PLC rejects with a field-level reason.
Wrong machine mode	Download blocked before parameters become active.
Network cut during transfer	Status becomes timeout or rejected; old active recipe stays.
Duplicate request number	PLC ignores it or reports already processed.
Same recipe name, new version	Screen shows the version difference clearly.
PLC restart after staging	No half-downloaded recipe becomes active silently.

Keep the screenshots and log exports from these tests. When a quality issue arrives months later asking which recipe was actually running, that is the evidence.

Failure modes you will meet

Screen shows the new product, machine runs the old values. The selected recipe changed and nobody checked the accepted one. Without the comparison above this recurs, guaranteed.

One parameter shifted into the next field. An array index moved when someone inserted a new parameter. Count and checksum checks catch it before production.

Works from the engineering station, fails from the runtime HMI. Either the runtime service account lacks database or file share permission, or the production HMI points at a different recipe folder. It is one of those two.

Operators bypass a blocked download by editing PLC tags. That means the rejection reasons are unclear or the changeover procedure is too slow. Once it becomes habit, the recipe system is decoration.

MES and HMI disagree on approval status. Pick one source of approval truth, or synchronize approval state including timestamp and version.

One thing to check next time you open a recipe screen: whether PLC_ActiveRecipeId is displayed anywhere on it. If it is not, the rest of the validation does not mean much yet.

To watch the same handshake at byte level on the SECS/GEM side, the S7 flow runs in the SECS/GEM simulator.