Let the PLC catch an HMI recipe load with a handshake tag

How does the PLC know a recipe was loaded from the HMI panel?

Two PLC-visible tags carry the news: the recipe control's handshake tag, which the panel sets when a recipe transfer completes, and a recipe ID field written with the recipe, given a distinct value in every recipe so the PLC knows which one arrived.

The handshake is the panel's built-in event signal for a recipe control. When the transfer finishes, the control sets the PLC tag its configuration names, and the PLC answers by writing the acknowledgment that same configuration calls for. Miss the acknowledgment and the panel reports a timeout error, so a timeout after every Load is the signature of a handshake nobody answered. The handshake alone says nothing about which recipe moved; that is the ID field's job, covered below. Check the recipe object's documentation for a raw button-state bit. Where the project exposes none, the handshake is the supported signal, and the better one for production logic, because it marks a transfer that actually completed.

What do you need before you touch the recipe project?

You need three things: a spare integer tag in the PLC for the recipe ID with an initial value of 0, a spare bit for the handshake signal and its acknowledgment, and a backup of both the panel project and the PLC program taken before you change anything.

Beyond those:

• The recipe control already configured in the panel project, with every recipe entered and its setpoints mapped.
• One spare 16-bit signed integer in the PLC for the ID. Positive values 1 to 32,767 are available in that width, ample for any realistic recipe list.
• One spare bit each for the handshake signal and the acknowledgment the control expects back.
• Online monitoring on the PLC, so the test watches real tag values and real scan behavior.
• The documentation entry for the recipe control, which names the handshake, notification and timeout settings your software version exposes.

Where the recipes live in PLC memory instead of inside the panel, storing HMI recipe tables in PLC memory covers the storage side; this article adds only the event tags around them.

Which handshake tag should the recipe control use?

Give the recipe control its own handshake tag, and its own notification tag where the project software offers one per control, so a load from the recipe screen cannot be mistaken for any other panel transaction.

Where the software offers a handshake tag and a notification tag per control, a dedicated pair keeps the recipe screen separate from every other transaction the panel can raise, and it costs two spare tags. Where your version offers one shared handshake for everything, do not assume the recipe control is isolated: list every control that consumes the shared tag and decide how the PLC tells their transactions apart, usually by checking which data moved. The handshake also beats a raw button bit for production logic, because it marks a completed transfer; a press cancelled mid-transfer should never start a batch.

How do you show the PLC which recipe loaded?

Add one field to every recipe that carries a different value in each one, and map it to a spare PLC integer, so the values 101, 102 and 103 land in the PLC alongside the setpoints and name the recipe that just arrived.

Because the ID travels inside the recipe write, the number arrives at the same moment as the setpoints, and a single handshake edge covers both. Pick numbers the PLC can check and operators can read, and keep 0 out of the numbering, because 0 is the cleared state that means nothing new has arrived. Write the recipe-to-number map into both projects so the next engineer can match them. Give the field one job: it names the recipe, while the handshake edge dates the arrival. A value left sitting in the register since the last shift is exactly why the PLC clears it to 0 the moment it stores a copy.

How do you wire the capture and acknowledgment into the PLC?

Capture the ID on the handshake edge, store it, clear it back to 0, and pulse the acknowledgment for one program scan; four rungs of ladder logic do the whole job, and every value they touch is one you can watch online.

The tag names below are illustrative, so rename them to your project's style. HMI_RECIPE_ID: integer, initial 0, the panel writes it. PLC_RECIPE_STORED: integer, initial 0, the PLC's own copy. HMI_HANDSHAKE: boolean, set by the recipe control. PLC_ACK: boolean, set by controller logic.

1. Back up the panel project and the PLC program.
2. In the panel project, open the recipe control and assign its handshake, and its notification tag where the software offers one, to dedicated PLC tags. Note the control's timeout setting while you are there; a setting of 5000 ms is common, and any value above a few hundred ms leaves ample room for a next-scan acknowledgment.
3. Add the ID field to every recipe, one distinct value each, mapped to HMI_RECIPE_ID.
4. Detect the rising edge of HMI_HANDSHAKE and, on that edge, move HMI_RECIPE_ID into PLC_RECIPE_STORED.
5. On the same edge, write 0 into HMI_RECIPE_ID.
6. Set PLC_ACK on the edge and clear it on the next scan, so the pulse lasts exactly one scan.
7. Download both projects through your normal controlled commissioning process, then put the PLC online and watch all four tags while someone presses Load.

The acknowledgment goes to the tag the control's configuration names, and the panel project defines which direction each of those tags moves, so match the PLC write to that setting. Skip it and every Load ends in the panel's timeout error even though the recipe data itself landed fine.

What does a three-recipe example look like from press to acknowledge?

A packaging line runs three bottle sizes with recipes numbered 101, 102 and 103; when the operator presses Load on recipe 102, the panel writes the setpoints plus ID 102, the PLC stores 102, and the panel gets its acknowledgment one scan later.

All four tags start at 0. Recipe 102 carries the 500 mL setpoints and ID 102.

Scan N: the panel finishes the write and sets HMI_HANDSHAKE; HMI_RECIPE_ID reads 102. The edge fires. PLC_RECIPE_STORED moves from 0 to 102. HMI_RECIPE_ID returns to 0. PLC_ACK sets.

Scan N+1: the edge is gone, so PLC_ACK clears after lasting exactly one scan. The panel sees the acknowledgment and raises no timeout error. The batch logic keyed to 102 starts the 500 mL sequence.

Now the arithmetic. A 16-bit signed ID tag offers positive values from 1 to 32,767. Recipes 101 to 103 take three of them, leaving 32,767 - 103 = 32,664 recipe numbers free, so the numbering outlives any list this line will grow. At a 10 ms scan time the acknowledgment pulse lasts 10 ms; the exact limit is the timeout configured on the recipe control, so read that figure from the project.

Against a 5000 ms timeout, that 10 ms pulse is 1/500 of the available window. Even a slow 50 ms scan leaves a 50 ms pulse inside the same window with a factor of 100 to spare. Delete the clear rung and the example breaks in a useful way: an hour later HMI_RECIPE_ID still reads 102, and any logic that treats a non-zero ID as news sees a recipe nobody loaded. The clear is what turns the ID from a label into an event.

How do you check the handshake before the line runs?

Test the whole path with the machine in a safe state: watch the actual PLC tags online, press Load once, and confirm the sequence of ID in, ID stored, ID cleared, acknowledgment seen happens exactly once per press, then repeat it with a second recipe. Give the two-press test about 5 minutes with online monitoring; that is enough to see both edges and both clears.

Commission with any motion the recipe change could trigger inhibited; the test exercises a signal path, and the safe state keeps a wrong signal from moving anything.

1. Watch the PLC tags, not the operator screen. A panel can display the new recipe while the PLC's stored register still holds the old one, and only the tags tell you which happened.
2. Press Load on recipe 102 and record four facts: HMI_RECIPE_ID reads 102 at the edge, PLC_RECIPE_STORED becomes 102, HMI_RECIPE_ID returns to 0, and PLC_ACK pulses with no timeout error on the panel.
3. Load recipe 103 and confirm PLC_RECIPE_STORED follows to 103.
4. Cycle power if retained values could matter, wait the 60 seconds the controller takes to come back online, then confirm the reaction logic stays idle until a real handshake edge, with PLC_RECIPE_STORED holding its last value and the ID at 0.
5. If the panel can cancel a load mid-transfer, cancel one on purpose and record what the tags do. Write the final PLC logic around the sequence you observed, at the scan times you measured, and around no assumed pulse width.

Recommendation: configure a dedicated handshake tag for the recipe control and add an ID field with a distinct value in every recipe, then let the PLC store the value, clear it to 0 and pulse the acknowledgment for one scan. Use the handshake alone only when the PLC needs to know that a transfer happened and nothing more; the moment the batch logic needs the recipe's identity, and most recipe jobs do, the ID field earns its tag.

What goes wrong when the handshake is shared or never acknowledged?

Three failures cover nearly every troubled recipe handshake: the panel times out because no acknowledgment came back, a shared tag fires logic for the wrong control, and a stale ID from the previous load makes the PLC react to a recipe nobody just loaded.

• Timeout error on the panel after every Load. The acknowledgment is missing or aimed at the wrong tag. Confirm the PLC writes it to the tag the control's configuration designates, on the scan after the edge.
• Reaction logic fires with no Load pressed. Another control shares the handshake tag. Assign a dedicated handshake and notification pair to the recipe control where the software allows it; where it does not, list every consumer of the shared tag and let the ID value tell the transactions apart.
• Logic fires at power-up, or twice per press. The reaction keys on a level instead of the edge, or the clear rung is missing, so a stale value re-triggers. Key the batch logic on the handshake edge alone and treat the ID as payload.
• Setpoints moved but the ID still reads 0. The ID field is missing from the recipe's tag list or mapped to the wrong PLC address. Re-check the field assignment in the recipe control, then repeat the two-recipe test.

The set-and-acknowledge pattern is the same one alarm handling uses, and signaling an HMI alarm acknowledgment back to the PLC applies it to alarms; once the recipe handshake works, the alarm version takes minutes to wire.

Questions