Fix a partial HMI screenshot in an emailed report

Why the screenshot comes out partial

A screen with a lot of data, bitmaps or animation takes longer to render than a plain screen. The panel waits for the render to finish before it captures, but a busy screen can outrun that wait. The capture then takes what has been drawn so far: the top of the frame, or most of it. The crop moves from one send to the next because render time moves with what the screen is doing at that moment.

A second cause sits in the data. A panel can display a screen before every value on it is current. Right after a screen change, a screen that reads several PLCs may still be waiting for its devices, so the capture preserves an empty or half-filled state with correct image boundaries. On one installation, that empty window lasted about 15 seconds after the screen loaded.

The third cause is the event itself. If an Email action starts while the capture operation is still writing the file, the send attaches whatever exists at that instant. That is why action order is the first thing to check.

What each symptom points to

• The crop moves from send to send, and some images are blank. The capture starts before the render finishes. Check the action order, then the timing.
• Failures cluster on heavy screens. Bitmaps, animation and dense data stretch the render past the panel's capture wait. Build a plainer screen for the report.
• An almost-empty screen still fails. One installation saw 3 of 4 sends come out partial or blank from a nearly empty screen, so render load is ruled out as the whole cause. The order or the timing is at fault.
• The screen reports Device Timeout right after it loads. PLC values are still arriving, and the capture freezes that empty state. Extend the settle time.
• The USB copy is whole but the attachment is missing or damaged. The fault is in the delivery path, most often an unstable connection.

Checks, in order

1. Compare several failed images against the screen that was displayed at capture time. For each send, write down whether the image is blank, cut off near the top, or nearly whole, and whether the screen was busy, changing, or settled. A crop that moves points at timing. A crop that always stops in the same place points at that one screen.
2. Open the event and read the actions in execution order. The Screen Capture Action has to come before the Email Action. Fix the order if it is reversed, then test several sends.
3. Watch the target screen right after it loads. Changing values, blank fields or Device Timeout messages mean data is still arriving. Time how long the screen takes to go steady, because that number sets your settle time. If Device Timeout persists past a generous settle, the fault is communications, and the sequence in tracing a 10 to 15 second delay between an HMI panel and its devices takes over.
4. Save the capture to a USB drive as well as emailing it. A whole file on the drive with a bad attachment moves the fault to the email path. A partial file on the drive keeps it in capture timing.
5. Run the same event several times before changing anything else. A fault that hits about 30 percent of sends hides easily in one or two test runs.

The fix: order, staging, and two events

1. Order the single event so the Screen Capture Action runs first and the Email Action second. Test it across several sends.
2. Stage a busy screen: add a step that changes to the reported screen ahead of the capture, so the screen is already displayed and populated when the capture fires. Allow 15 to 60 seconds between the screen change and the capture, and use the top of that range when Device Timeout still shows 15 seconds after the screen loads. The screen change can be its own timed event, the same pattern used when an HMI changes screens on a PLC alarm bit.
3. Leave about a minute between the capture and the send. In the staged schedule below, that minute covers the image write to the USB drive; with no USB copy, it still keeps the send from starting inside the capture.
4. If a single event still sends partial images, split it: one event carries the Screen Capture Action, a second carries the Email Action, and both are triggered by the same tag. If that still fails, use two different trigger tags with a short delay between them. The split makes the send a separate step that cannot start while the capture step is still running.
5. Simplify the reported screen if failures keep clustering on it: fewer bitmaps, no animation, and only the values the report needs. A plainer screen renders faster and needs less settle.

Recommendation: Order every report event as Screen Capture Action first and Email Action second, and stage a screen change 15 to 60 seconds ahead of the capture whenever the reported screen carries bitmaps, animation or more than a handful of tags. Use the full 60 seconds when Device Timeout still shows 15 seconds after the screen loads, and 15 to 30 seconds for a screen that populates quickly. Leave about a minute between capture and send, and split the two actions into separate events on one trigger tag if a single event still sends partial images.

Example: staging a 12-inch, 100-tag overview screen for a 6:00 email

The inputs, and where each comes from:

• Panel: a 12-inch HMI panel. The same fault showed on 15-inch panels.
• Screen: a status overview gathering more than 100 data tags from several PLCs (tag count from the screen's configuration).
• Observed behaviour: Device Timeout on several PLCs for the first 15 seconds after the screen loads, values complete after that.
• Report schedule: email twice per day, the morning send at 6:00.
• Event steps as configured: screen change at 5:58, screenshot to the USB drive at 5:59, email at 6:00.

The rule: the settle time between the screen change and the capture must be longer than the window in which devices still report missing, and each step gets its own minute so no step starts inside the previous one.

The arithmetic:

• Settle time: 5:59 minus 5:58 is 60 seconds. The schedule gives the screen 60 / 15 = 4 times the observed timeout window, so the last PLC value has 60 - 15 = 45 seconds to arrive and settle before the capture fires.
• Capture to email: 6:00 minus 5:59 is 60 seconds, reserved for the image write to the USB drive.
• Whole pipeline: 6:00 minus 5:58 is 120 seconds, two minutes of panel time each morning.

Result: complete screenshots at every send. The only remaining failure on this installation is an unstable internet connection at the send step, which shows up as a missing or damaged attachment with the file still whole on the USB drive.

Decision: if your screen still reports Device Timeout 15 seconds after it loads, set the settle to 60 seconds. If it populates in under 15 seconds, 15 to 30 seconds is enough. If the screen carries well under 100 tags from one or two devices, skip the screen change and run capture and email a minute apart.

Keep the tag values with the picture

When the report also carries tag values, the staged schedule splits it in time. Values gathered at 6:00 describe the screen a full minute after the 5:59 capture, so the numbers and the picture come from different moments.

Decide which timestamp matters. If the picture is the point, keep the staged schedule and treat the image as the record. If the values must describe the same moment as the picture, send the values in their own email at 5:59, when the screenshot is taken, and send the image at 6:00. Label each email with its send time so nobody reads the 6:00 picture as being from the same second as the 5:59 values. Test the pair with values that change quickly, so any mismatch shows up in your own inbox before the report goes into service.

Prove it before restoring the schedule

Run the staged sequence across 7 days of normal operation: two sends a day is 14 sends. For each send, open the USB copy and the emailed attachment and compare them, and confirm Device Timeout is gone before the capture fires on every run. The odds that the fault has survived unnoticed are small: at the observed 30 percent failure rate, each send passes by chance 0.7 of the time, and 0.7 to the 14th power is under 0.01, so 14 clean sends in a row happen by luck less than 1 percent of the time. Keep the simplified screen or the split events if those are what produce whole images; a single consolidated event comes back only after it passes the same 14 sends. If attachments fail while the USB copies are whole, the fault is delivery: check the connection first, then the mail settings, starting with the DNS checks in an HMI panel email send error traced to DNS first.

Questions