Close an HMI recipe screen from the PLC on the done bit

What the write bit has to show first

The write bit in the last column is the completion signal: the recipe system sets it when the transfer reaches the end of the value list. Before that bit moves a screen, watch it beside the last recipe value during one manual load. Open the panel's trend or data view with the bit and the final value in it, load a recipe by hand, and read the order of the two events.

Three outcomes:

• The bit comes on after the last value lands. Use it.
• The bit comes on before the last value lands. A screen change at that moment closes the window mid-transfer. Fix the completion logic first: gate the close request on the done bit and on the last value matching the selected recipe, so navigation waits for both.
• The bit comes on and stays on. Fine as a signal, wrong as a trigger. Trigger on the rising edge and clear the bit from the PLC, or the next load produces no new edge and the window stays open.

Take one more reading while you are there: how long the bit stays on, counted in scans. A bit held for a single 5 ms scan can fall between two panel updates and go unseen, which is what the latch below is for.

What you need

• A recipe screen whose last column writes a completion bit to the PLC.
• The screen tag the PLC writes to move the panel to a chosen screen.
• One spare internal bit for the latched close request and one timer for the hold.
• A trend or data view showing the done bit and the last recipe value together.
• The machine in a state where a screen change can start nothing, for the first test.

Do the first automatic close with the process stopped. A navigation test that lands the panel on the wrong screen mid-cycle is a fault worth avoiding from the start.

Close the recipe window from the PLC

1. Load one recipe by hand and watch the done bit beside the last value. The bit comes on after the value lands. Note how long it stays on, in scans, and read the panel's tag update time from the communication settings; this example uses 250 ms.
2. Put the machine in the safe test state.
3. Latch a close-request bit on the rising edge of the done bit. The edge handles a bit that stays on; the latch handles a bit that lasts one scan.
4. While the close request is on, write the destination screen number to the panel's screen tag. Pick the screen the operator should land on after a load: the run screen, or a confirmation screen.
5. Hold the request for four panel update cycles, then clear the request and the done bit in the same scan. At the update time above, four cycles is 4 x 250 ms = 1000 ms = 1 s.
6. Load a second recipe. The window must close exactly once, on every load.

Keep the Close button on the recipe screen. It costs nothing and gives the operator a way out while a transfer is still running.

Example: twelve values, one update cycle, a 5 ms scan

Scenario: a recipe with 12 values, a panel polling at the update time from step 1, a PLC program scanning in 5 ms, and a done bit the recipe system holds for one scan.

Transfer time, worst case. Plan for the panel writing one value per update cycle, the slowest legitimate pattern: 12 update cycles = 3.0 s. The done bit's rising edge arrives at or after 3.0 s.

The raw pulse, left as is. A 5 ms pulse into a poll fifty times longer is caught 5 / 250 = 0.02, about 2% of loads. Leave the bit unlatched and the window stays open 49 loads out of 50.

The latched version. The close request turns on the scan after the done bit, within 5 ms. The panel acts on its next update, up to one update cycle later. The window closes 3.0 s + 5 ms + 0.25 s = 3255 ms, about 3.3 s after the operator starts the load. One write to the screen tag, one close, every load.

The hold. Four update cycles: 4 x 0.25 s = 1000 ms = 1 s, then both bits clear and the sequence is ready for the next recipe.

Re-arm the bits for the next load

The second load is where a first version fails. The done bit is still on from load one, its rising edge never comes, and the window sits open over a recipe that actually transferred.

Clear the done bit and the close request together, in the scan the hold timer finishes. The recipe system writes the done bit again on the next load, so clearing it now costs nothing and buys the fresh edge that fires the next close.

If alarm navigation writes the same screen tag, the last write wins. Keep the close request short, the 1 s hold, so a later alarm navigation still lands the panel where it needs to be. On the catch side, an HMI recipe load caught with a handshake tag covers the pattern where the PLC needs to know a load started as well as finished. And since the operator can still close the window by hand, reset logic that runs on every path a pop-up closes by keeps your re-arm rung covered on that path too.

How to check it worked

Run two loads and read four things off each:

• Every value from the recipe lands in its PLC destination.
• The window closes once, and the destination screen appears.
• The done bit and the close request are both off within about a second of the close.
• The recipe screen can be opened again and a third load behaves the same way.

When a check fails, the failure names the fault:

• Values missing, window closed: the done bit fired early. Back to the first section, and gate the close on the last value.
• Values present, window open: the screen-tag write never landed or the request was too short. Check the latch and the 1 s hold.
• Window closes and the panel jumps again a moment later: a bit never cleared. Check the re-arm rung.

Recommendation: latch the done bit into a close request, drive the screen change from the latch, hold it 1 s at that update time, and clear both bits when the hold ends. Run the raw bit only if you have watched it stay on through two full loads; a one-scan pulse will strand the window sooner or later.

Questions