Trigger an HMI recipe write from a PLC bit

Can a PLC bit trigger an HMI recipe write?

Yes: enable the Recipe object's Use Write Event Tag option, point it at a dedicated PLC bit, pulse that bit, and the panel runs the object's write event, transferring the selected recipe record into the PLC addresses the object targets. The option belongs to the Recipe object itself, so the same object decides what is written. It carries the record selection and the target address block, and the event tag only decides when the write runs. The option also comes with its own note: the object has to be on the screen the panel is showing at the moment the bit fires. The rest of this article sets up both halves, the bit and the screen, and ends with the test.

What do you need before you start?

You need four things: a saved copy of the HMI project, a Recipe object already configured with its recipe records and target addresses, one spare PLC bit reserved for this trigger, and the list of screens from which the PLC can request a write.

• The project copy comes first, because this job changes event configuration and object placement, and the previous download is your way back.
• The Recipe object with its records and addresses already set. The trigger never picks a record or invents target data; it only fires what is configured. If the records still need real values from the operator, saving HMI screen input to recipe storage is the companion setup.
• One bit that nothing else touches. A bit shared with an operator button or a sequence step fires recipe writes at the wrong moments.
• The screen list. It decides between copying the object onto each screen and sharing one object through a background screen.

How do you assign the PLC bit as the recipe write trigger?

Open the Recipe object's settings, enable the option named Use Write Event Tag, and set its tag to your dedicated PLC bit; that one option is what turns the bit into the write trigger.

1. Save a copy of the project, then open the Recipe object and read its own settings: which record it writes and which PLC addresses receive the data. If either is wrong, correct it here; the trigger will faithfully transfer the wrong recipe otherwise.
2. Enable Use Write Event Tag and set the event tag to the dedicated bit. Check that the tag points at the right PLC address and is typed as a bit or boolean.
3. Confirm the panel sees the bit change before you trust the link. Force the bit from the PLC and watch it in the panel's online tag view; most panel software includes one. If the tag was imported and shows stale values, repairing an imported HMI tag that ignores PLC register writes comes before any trigger work.
4. Download the project and keep the previous file with the machine's records.

Should the trigger bit pulse or stay on?

Pulse it: set a one-shot pulse of 500 ms as the default, sized to outlast a tag update period of up to 250 ms with margin for one missed poll, and stretch it to 1 s on slow serial links. The rule behind the default is pulse length = at least two update periods, so the panel still sees the request after missing one poll. Build the pulse with an on-delay timer in the PLC.

A coil driven for one scan of a small PLC is a pulse of roughly 10 ms. Against a 250 ms update period the panel misses most of those; the worked example below puts the fraction on it. A maintained bit is the version to avoid: it leaves the request asserted, and whether the panel writes once or repeats is decided by the event handling your panel software's documentation describes, which is a bad thing to learn on a running machine.

Does the recipe object have to be on the current screen?

Yes, and this is the trap: the write event only runs while the screen holding the object is the one loaded on the panel, so a correctly wired bit does nothing if the object's screen is not showing at that moment. The option's note says so plainly, and it is the most common reason a bit that tests fine on one screen looks dead on another. Two arrangements cover it:

• Copy the object onto every screen in your trigger list and park it off the bottom edge, below the visible area; the panel still loads it there and it stays out of the operator's way.
• Build one screen that holds the object and attach it through the background screen option, so every screen using that background carries the object, one edit to maintain instead of one per screen.

Either way, confirm each screen in the list actually carries the object, and recheck the list whenever a screen is added. A PLC bit can also act on the panel in the other direction: an event-triggered screen change on an HMI when a PLC alarm bit turns on.

How does the PLC bit choose which recipe downloads?

It doesn't: the write event tag only fires the transfer, and the record that goes out is whatever the object has selected, so the selection must be set before the pulse is issued. Sequence every request the same way:

1. Select the record, by the operator or by a selection tag the PLC or the project writes.
2. Let the selection settle for one update period, 250 ms in the example below, so the panel acts on the new record.
3. Pulse the trigger bit.

Where the selection travels down to the PLC as a number or a name, passing a recipe name from an HMI to a PLC variable covers that direction, and the PLC can verify it before pulsing. Treat the pulse as a request, not a receipt: the bit rising means the panel was asked to write, and the transfer being finished is a separate condition. If the project software offers a completion event, wire it to a handshake bit the PLC waits on. If it offers none, the PLC compares the target register block against the expected record before it acts on the new values. Design the PLC side so it never waits forever on a panel that is off; keeping PLC schedules running when the HMI panel is offline is the companion question.

One safety note: a recipe write changes live setpoints, so run the first triggered write with the machine in a state where new values cannot move anything.

Worked example: what happens when the PLC pulses the trigger bit?

A depositor with 6 operator screens and 20-register recipes needs one object on a shared background screen and a 500 ms pulse, and the panel picks up each request within 250 ms of the bit setting. The panel runs 6 operator screens, each 800 x 480, all using one background screen that carries the Recipe object parked below the visible area. Recipes are 20 registers each. The PLC scans in about 10 ms, and the project sets its tag update period to 250 ms. The trigger is an on-delay pulse of 500 ms.

• Coverage: 1 object on the background screen serves all 6 screens; per-screen copies would mean 6 objects to keep in step.
• Pulse sizing: a bare one-scan pulse of 10 ms lands inside a poll window in 10 / 250 = 4% of requests, so 96% are missed outright. The 500 ms pulse spans 500 / 250 = 2 update periods, so the panel sees every request even with one poll missed.
• Timing: the worst case from bit set to sighting is one full period, 250 ms; the 20-register write follows the sighting, and the PLC releases the request once its register block matches the record.
• Result: one pulse, one write, from any of the 6 screens, with no operator action.

How do you check the recipe write worked?

Run one controlled cycle: load the screen that holds the object, select a test record, pulse the bit once, and confirm the target registers change to the test values and the request bit returns to off with no second write.

1. Watch the trigger tag from the PLC and in the panel's online tag view, pulse once, and confirm the panel sees the change before anything is written.
2. Compare the target register block, all 20 registers in the example, against the test record.
3. Let the bit return to off, wait 2 s, and confirm nothing writes again. A spontaneous second write means the request handling repeats the transfer, and the pulse design has to change before this goes on a machine.
4. Walk the trigger list: load each screen, pulse from each, and confirm the write on each. A silent screen is missing the object or its background.
5. Restore the normal trigger logic and run one full cycle with the values you intended.

Recommendation: Use one dedicated PLC bit, pulsed 500 ms with an on-delay timer, assigned through the Recipe object's Use Write Event Tag option, with the object on a background screen shared by every screen that may request a write. Raise the pulse to 1 s on a serial link, keep the selection-before-pulse sequence in the PLC, and add every new screen to that background before it reaches the floor.

Questions