Poll one screen at a time: send a screenshot request, wait for the image to finish, and log how long each capture takes. With four screens on a 1-second send interval, every screen refreshes every 4 seconds only while each capture completes inside its slot. When the worst completion time crosses the slot, widen the send interval to twice that capture time and re-test.
A web server on an HMI panel can hand out screenshots of its screens. A PC can poll those images onto large monitors at different spots around a site. On paper the schedule is simple: four screens, one request per second, so each screen is refreshed every 4 seconds. On the panel, that schedule holds only while every capture finishes inside the gap between sends. So send one request at a time. Log how long each capture takes. Keep the schedule only while the slowest capture stays under its slot. When a capture runs longer, widen the send interval until requests stop queuing.
What a 1-second send schedule promises
Four screens with one request every 1 second works out to a request for each screen every 4 seconds: 4 screens × 1 s = 4 s. That figure is a promise the PC makes on its send timer. The delivered refresh matches it only when each capture completes inside its slot. A capture that runs past the slot pushes the next request back or stacks requests up. The per-screen intervals then stretch past 4 s, and a backlog builds that later requests do not clear on schedule.
The number that decides the schedule is the capture completion time on your project. It is not a datasheet figure. It is measured on the running project, because it moves with the screens in the design, their object counts (the design here runs 50 to 100 numeric and text display objects per screen), and everything else the panel is doing at the same time.
A polling tool often carries two settings that get confused: the send interval and the timeout. They do different jobs, and HMI timeout time vs poll time: what each setting does walks through the pair.
What you need
- The panel's web server running, with the screenshot request for each screen documented in the panel's manual. Get the manual from the panel manufacturer or its distributor.
- A PC on the same network as the panel.
- A small script or polling tool that sends one request and timestamps two moments: when the request goes out and when the image is fully saved. Most scripting environments do this in a few lines.
- A log with three values per capture: send time, completion time, screen requested. A spreadsheet handles the analysis.
- The project running as it will run in production, with its normal screens on the panel and the monitors in place at the four locations.
Set it up: one request at a time
- Open the screenshot request by hand. Ask the web server for a capture of one screen, save the image, and open it. It should be the screen you asked for, with the values on it matching the panel at that moment.
- Request captures of the other screens one by one while someone watches the panel. If asking for a capture of screen 2 flips the operator's live display or stalls touch response, stop there and resolve it against the panel's documentation before automating anything.
- Time one screen. Send the same request 20 to 30 times, one at a time. Log the send time and the completion time (the moment the image is fully saved) for every request. Note the worst completion time.
- Start the rotation. Send one request every 1 second, cycling through screens 1, 2, 3 and 4. Keep logging send time, completion time and screen name for every capture.
- Watch the panel's normal work while the rotation runs: touch response, alarm pop-ups, values updating as before. Watch the log too, for retries and timeouts.
- Compare the log against the slot. Every completion time under a second means the schedule holds and each screen is refreshed every 4 seconds. Any capture over the slot means requests are lining up. Set the send interval to twice the worst completion time in the log and run the rotation again.
- Re-measure after every project change. Edited screens, added objects and firmware updates all change the load. The interval belongs to the project as it stands on the day you measured.
If the capture is fired by an event or a script on the panel instead of a plain request, the same rule applies on the panel side: one capture finishes before the next starts. Check the panel's event documentation for how capture completion is signalled, and log that signal the same way.
Worked example: four screens on a 1-second send schedule
The inputs: four screens at four locations on a 15-inch panel (the job); one request sent every 1 second, cycling 1-2-3-4 (the proposed schedule); 50 to 100 numeric and text objects per screen (the screen design, which is part of what each capture costs).
The rule in words: the refresh each screen actually sees equals the screen count times the send interval. That figure holds only while every capture completes inside the send interval.
The arithmetic: 4 screens × 1 s = 4 s between requests for the same screen, and each capture has that same 1 s to finish in. Say the log from the steps above shows a worst completion time of 1.4 s. That is over the slot, so requests queue and the promised 4 s refresh is not being delivered. Set the new send interval at twice the worst completion time: 2 × 1.4 s = 2.8 s, rounded up to 3 s to keep whole-second timers and keep the margin. Each screen then refreshes at 4 × 3 s = 12 s.
The result and the decision:
| Worst completion time in the log | Send interval to set | Refresh per screen |
|---|---|---|
| Under the 1 s slot | Keep 1 s | 4 s |
| Over the slot (example: 1.4 s) | 2 × worst, rounded up: 3 s | 12 s |
Hold the 1-second schedule while the worst completion time stays inside the slot and the panel's normal operation is unchanged. The first capture over the line sends you to the second row. A single fast capture is not proof, so judge from the log over the full rotation.
What overload looks like
While the rotation runs, these signs say the captures are costing the panel time:
- Completion times creeping upward, run over run.
- Touch response on the panel lagging.
- Alarms or value updates arriving later on the panel than usual.
- Timeouts or retries appearing in the log.
Each sign points the same way: the capture work is competing with the panel's normal jobs. Slow the schedule first. If the signs persist even at a slow serialized interval, stop polling and look at what the panel is carrying. A stalled web server also leaves its own signature in the log: timeouts on every screenshot request while other network services on the panel still answer. That pattern tells a stalled server from a busy network, and it calls for a panel restart per the manufacturer's documentation, not a longer interval.
There is a lighter path when the monitors only need the values. Ask whether the web server can serve the tag data directly, and render the picture on the PC. Read PLC tag values from an HMI panel web server covers that way of working.
How to check it worked
- From the completion timestamps, work out the delivered refresh for each screen: the time between consecutive completed captures of that same screen. On a holding schedule all four sit at 4 s, with no gaps and no drift.
- The log for the run shows zero timeouts and zero retries.
- The panel's own work is unchanged: touch response, alarms and value updates as they were before polling started.
- Leave the schedule running through a full production shift, with the line doing its normal work, before you call the schedule permanent. Re-run the measurement after any change to the screens.
Recommendation: poll one capture at a time and set the send interval from the log. Keep the 1-second schedule across four screens while the worst completion time stays under that slot, which delivers a 4-second refresh per screen. On the first capture over the line, set the interval to twice the worst logged time, confirm the resulting per-screen refresh still meets what the monitors need, and re-measure after every change to the project.
Questions
What send interval do I set for six screens instead of four?
The same rule with the new screen count: the nominal refresh per screen equals the screen count times the send interval, so 6 screens at a 1-second schedule works out to 6 s per screen. The slot rule stays the same too: the schedule holds only while the worst completion time in the log stays under the slot. Past that, set the send interval to twice the worst logged completion time, and each screen then refreshes at 6 times that interval.
Why not request all four screenshots at once?
Requests sent together overlap at the panel, and each completion time then includes waiting for the others, so the log no longer tells you what one capture costs. With one request in flight, the completion time measures a single capture, the load arrives at the panel one item at a time, and a backlog becomes visible in the log the moment a capture outgrows its slot.
The monitors only need fresh images every 10 seconds. What interval does that allow?
Work backwards from the requirement: 10 s spread over 4 screens allows a send interval of up to 2.5 s and still meets it. Set the interval from the measurement anyway: twice the worst logged completion time, as long as that stays at or under 2.5 s. That meets what the monitors need while asking the panel for the least capture work.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.