The delay is normal: the box that reads writing 1/3 is the panel reporting a write that touches its own storage and, where mapped, PLC addresses, while sharing the panel's communication time with the rest of the screen. Time it on the panel, then cut it two ways: consecutive PLC addresses for the recipe's fields, and a quieter screen.
Yes, the delay is normal, and you can measure it and shrink it. The grey and yellow box that reads "writing 1/3" is the panel reporting progress through a write that does real work: the selected record's values go to the destinations you mapped, the selection lands in the panel's own recipe storage, and any fields bound to PLC addresses cross the link to the controller. None of that work happens in simulation, which is why the project feels fast on the PC and slow on the machine. Two changes cut the wait: consecutive PLC addresses for the recipe's fields, and a screen with little other communication holding the recipe control.
What the writing message means
The box is a progress report, not a fault code. Your panel shows three parts: "writing 1/3", "writing 2/3", "writing 3/3". That count is the panel's own step count for the recipe operation you configured. It is one step per part of the operation, and it is one step per PLC address only if you happen to have mapped it that way. Note the highest count on the working project. After any edit, the same count should still appear; a different count means the operation changed shape and the destinations deserve a re-check before the machine runs.
The work behind the box is storage plus communication. The panel writes the selected record's values to their destinations and updates its recipe memory. Some panels also stage recipe data and commit it to internal storage on a timer; one vendor documents an automatic save every minute to limit flash wear. That is why the panel spends whole seconds where the PC spends none.
Symptoms and what each points to
- Fast in simulation, seconds on the panel. The write's storage and link work is the cost. Treat simulation as a logic check and time the real panel.
- The count climbs, the box clears, and the PLC values match the selected recipe. The write completes. The wait is the write's own cost plus contention; work through the fix below.
- The box stops on one count, or the destination values never change. That is a communications fault, not slowness. Check the link, the node addressing and the cable first; speed tuning can wait.
- The wait appears only on the busy screen. Contention: every object polling a device takes a share of the panel's communication time. Move the recipe control or trim the screen.
- The wait follows the recipe onto every screen. The write itself dominates. Look at the record's size, its storage and its address layout.
- Every control on the panel is sluggish, recipe or not. Start wider, with fixing a slow HMI panel's touch entry and screen updates; the recipe is then just one more write on a slow panel.
Check what the recipe actually writes
Before you change anything, write down the map. Four rows answer the question:
| What to record | What it tells you |
|---|---|
| Fields in the selected record | How many values one selection writes |
| Destination of each field | Internal tag, PLC address, or panel storage |
| Other objects on the recipe screen | What shares the panel's communication time |
| Where recipe data is stored | Panel memory or removable storage |
A recipe on internal tags skips the PLC transfer for its own values. It still writes to the panel's storage, and it still queues behind the screen's other traffic, so internal tags shorten the write without making it instant. If your project also saves operator input into recipe storage, the two-button pattern in saving HMI screen input to recipe storage keeps those writes deliberate while you sort out the delay.
Measure the delay on the panel
A recipe selection changes the machine's setpoints. Time your tests when the process can accept new values, or with the machine in a state that ignores them.
- Download the project and let the panel reach its normal running screens.
- Time the same selection five times, from touch to the moment the box clears. A phone video with a visible clock beats a thumb on a stopwatch. Write down all five numbers and the highest count shown.
- Open a temporary test screen holding the recipe selection control and only the objects the operator needs. Same recipe, same destinations, nothing else polling.
- Time the same selection five times there.
- Average both sets. The stripped-screen average is the write's own floor on this panel, and the difference is what the busy screen costs you.
Five runs absorb the spread you get when the panel's timed saves and its other screens land inside a measurement.
Example: timing one recipe on a busy 8-inch screen
An 8-inch panel, one of three recipe boxes, on a production screen with a dozen objects polling devices. On the loaded screen the selection takes 3.0, 3.2, 2.9, 3.1 and 3.3 seconds: 3.0 + 3.2 + 2.9 + 3.1 + 3.3 = 15.5, and 15.5 / 5 = 3.1 seconds on average. On the stripped screen the same selection takes 1.2, 1.3, 1.2, 1.4 and 1.3 seconds: the sum is 6.4, and 6.4 / 5 = 1.3 seconds on average. The busy screen adds 3.1 − 1.3 = 1.8 seconds, about 58 percent of the wait.
The decision from those numbers: 1.8 s is contention, so fix the screen first. The 1.3 s is the write's floor, so trimming the screen cannot take the selection below that. Had the two averages landed within 0.2 s of each other, the screen would be innocent, and the record itself, its storage and its address layout would be the target.
Treat these two thresholds as example figures from this method, not ratings: under about 2 s on a stripped screen is a small record doing its work, and more than 1 s added by the loaded screen is contention worth removing. Your own two averages replace them.
The fix: consecutive addresses and a quiet screen
- Save a copy of the project and of the current field-to-address map. A re-map done from memory writes values to the wrong destinations, and the machine will run whatever lands there.
- Where the PLC program allows, move the recipe's PLC fields into one run of consecutive addresses, keeping data types and field order. The panel can then move the whole run in one pass instead of a separate write per value. This is the layout rule behind grouping HMI screen addresses into dense ranges for faster updates.
- Give the recipe control a screen with little other communication. Move high-traffic trends, counters and status reads off it, or give the recipe its own screen. The panel hands each polling object a share of its communication time, which is the same queue that leaves an HMI screen slow to update over serial with no errors.
- Move addresses on both sides together. Change where the values live only with the PLC code that reads them; an address move on the panel alone breaks the mapping silently.
- If the recipe writes only internal tags, step 2 has nothing to consolidate, because no transfer crosses to the PLC. Do step 3, then look at the record's size and where its data is stored.
- Make one change, download, and re-time five selections. One change at a time tells you which edit bought which tenth of a second.
Prove the repair
- The box still counts to the same highest number and clears.
- Every destination value equals the selected record's field, read in the PLC's own monitor, not only on the panel's screen.
- The loaded-screen average sits close to the stripped-screen average; for the example above, that means about 1.3 s on the production screen.
- The selection behaves the same at shift start, with every screen the operators use open at once.
If the wait survives both fixes, the bottleneck is wider than the recipe, and diagnosing a factory screen update delay walks the rest of that path.
Recommendation: time five selections on the loaded screen and five on a stripped screen before you edit anything. If the loaded screen adds a second or more, move the recipe onto a quiet screen first, then re-time. Then, and only where the recipe writes to the PLC, lay its fields into one run of consecutive addresses. Leave every field the machine reads in place, and leave the write itself alone: the values landing in the controller are the whole point of the button.
Questions
How long should a recipe write take on an HMI panel?
Set your own floor instead of hunting a catalog number: five timed selections on a stripped screen, averaged, is the write's own cost on that panel. Record size moves it more than anything else you control, so drop fields nothing reads. A record of 6 fields finishes ahead of the same record carrying 18.
Why is the recipe fast in simulation but slow on the real panel?
Simulation runs on the PC's processor and memory, with no flash write to commit and no serial or network link to wait for, so it cannot show the write's true duration. Use it to check logic, layout and tag values. After every download, re-time five selections on the panel itself; the panel is the only clock that counts.
Do consecutive PLC addresses help when the recipe uses internal tags?
No. Consecutive addresses consolidate the transfer to the PLC, and internal tag destinations send nothing there. Your levers are a quieter screen and the record's own storage. If you add PLC destinations later, lay them out consecutively on day one: fitting them in afterwards means re-mapping both the recipe and the PLC code that reads the values.
Can a faster link shorten the recipe write?
Part of it. The values cross whatever link joins panel and controller, so the link's speed sets part of the wait; moving the panel from a serial line to Ethernet is the usual upgrade, and the recipe write shares the benefit with every other object on the screen. Measure five selections before and after, the same as any other change.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.