HMI project upload blacks the screen: plan it as an outage

Does uploading a project interrupt the operator?

Yes: the screen goes black with a No Program message for the whole transfer, and when the write finishes the panel's runtime reinitializes as if the unit had just powered up, so the operator loses the interface until the restart completes.

The behavior is part of the transfer design, not a fault. Replacing the running project leaves the panel with nothing to display while the new file writes, and the download documentation for at least one major HMI runtime says it plainly: the download disables the runtime and starts it again, and the documentation warns this can stop the plant. Even a one-button color change rides in a full project file, so a cosmetic edit causes an outage the same size as a control change. The runtime then starts the new project from its startup state, which is why the checks after the restart matter as much as the transfer itself.

Can the line keep running while the panel is dark?

It can when three things hold: the machine's stop path is hardwired and independent of the screen, an abnormal condition either latches safely in the controller or stops the machine on that path, and an operator stays within reach of the stop for the whole window.

During the window the operator loses whatever runs through the panel: alarm banners and acknowledgments, setpoint entries, mode selections, manual commands. The operator keeps the hardwired emergency stop. IEC 60204-1 requires a machine's emergency stop to act through its own hardwired circuit, with no dependence on software, and NFPA 79 carries the same requirement for machinery built to the US standard, so a compliant machine can still be stopped while its screen is dead. A fault that would normally raise a banner on the panel has to latch in the controller or stop the machine on that hardwired path while the screen is dark.

If this panel is the only place an operator can command a stop or acknowledge a hazard, bring the process to its stopped, safe state and upload during the stop. If the three conditions hold, a stable line can ride through the window with a named person at the panel. If you are still deciding which functions a panel has to carry at all, the planning checklist for a touchscreen operator interface covers that earlier question.

How long should the transfer window be?

Budget it from the restart and your verification checklist, not from the file size: a 4 MB project needs only 0.32 seconds of wire time on a 100 Mbit/s link, and the restart plus checks are what set the real duration.

The panel's restart time is not published anywhere you can quote, so measure it once: run a transfer on a spare panel or at a planned stop, and time the dark period. Everything else in the window is arithmetic you can do in advance.

Example: what do the numbers look like for a 4 MB project?

• Project file: 4 MB. Wire time at 100 Mbit/s: 4 MB x 8 = 32 Mbit, and 32 Mbit / 100 Mbit/s = 0.32 s. The wire is not the constraint at this file size; on the example trial panel, the same file took 40 s from transfer start to the last write.
• Restart: the trial panel stayed dark 50 s after the last write before the new project's first screen appeared. Dark period total: 40 + 50 = 90 s.
• Verification: the post-restart checklist below takes about 5 minutes, or 300 s, for one panel.
• Window: 90 + 300 = 390 s, or 6.5 minutes. Publish a 10-minute window so one complete retry still fits.

Use your own measured dark time in place of the 90 s; the method holds either way.

What do you check before you press transfer?

Have a copy of the running project read off the panel, the transfer address confirmed against the panel's transfer settings, and an agreed safe state with a person standing at the panel before the first byte moves.

• Read the running project off the panel before you edit it, so your copy matches what the machine has been operating with: the steps are in reading an HMI project from the panel before editing.
• Keep that known-good file as your master copy somewhere outside the panel; the HMI project upload protection routine is the habit to copy.
• Confirm the panel is in transfer mode and that the address in its transfer settings is the one your software targets. A panel parked in a service or maintenance mode can ignore upload attempts entirely, which looks exactly like a network fault from your desk.
• Tell operations when the screen goes dark and for how long; the window number comes from the section above.
• Agree the safe state before the write starts: process stopped, or running under the three conditions with a named person at the panel.

Is a black screen the upload or a fault?

A dark panel with the No Program message while a transfer is running is the upload working; the same darkness with no transfer in progress is a power or boot fault, and the stalled-transfer case has its own recovery path.

• Dark screen with a No Program message while a transfer runs: expected. Let it finish; adding a power event mid-write only widens the outage.
• Dark screen, no transfer running: power or boot trouble. Work through the checks for an HMI screen that goes blank and freezes before touching the project.
• Transfer stalls or aborts partway: the write did not complete. Retry the transfer once; if the panel refuses it, restore the master copy. Keep hands off the power switch, because a panel can lose its project after a power cycle, and a half-written file is the worst time to find out.
• Panel ignores upload attempts: check transfer mode and address first; from a desk it looks identical to a dead route.
• Panel returns without the expected project: the restore did not take, or the wrong target received the file. Work the steps for an HMI project restore that fails after reboot, and keep the panel out of production until the expected screen is live.

What do you verify after the panel comes back?

Check four things before you hand the panel back: the startup screen appears, one alarm message shows and clears, every setpoint still reads its intended value, and one real write from the panel reaches the controller.

The restart belongs to the panel; the machine held its own state through it. Confirm machine status from the controller indications first, then judge the screen.

• Startup screen: a reinitialized runtime opens the project's startup screen. If that is not the screen your operators expect, follow setting the startup screen on an HMI panel.
• Selections held in the runtime: a language choice can flip back when the runtime restarts; the runtime language selector that resets after startup shows where that lives.
• Values: a freshly restarted runtime can replay a stale numeric entry from a panel switch, so read every setpoint back, and run the low-below-high check on each one before it reaches the controller.
• Writes: make one real write from the panel to a harmless variable before production; the method in operator panel PLC link setup with writes tested before motion is the pattern.
• Alarm banner: force or wait for one event and confirm the message shows and acknowledges.

Hand the panel back to production only after all four checks pass.

Does a remote upload over a VPN change any of this?

No: the panel goes dark for the same transfer and restarts the same way, and the only difference is that recovery now depends on a person who can physically reach the panel within the window.

The outage is identical; the recovery is not. Before you connect from a desk, do the three things that make remote recovery possible:

• Put a person at the panel with the safe-state card and the window length, someone who can tell you to stop if the floor changes.
• Confirm the target address belongs to the panel you meant; a transfer lands wherever you point it.
• Keep the master copy on the machine you are pushing from, ready to restore.

The three conditions for running through the window apply remotely too, with one addition: the person at the panel is the one who acts on the hardwired stop, so they need to know the safe state before you start the write. When the post-transfer report from the floor is only 'the screen is acting odd', narrow it with a written plan for vague outage reports before you re-upload anything; a second upload over an unknown fault just doubles the variables.

Recommendation: Treat every project upload as a planned outage of the operator interface. Upload at a planned stop unless the machine's stop path is hardwired, its faults latch or stop safely in the controller, and a named person stays at the panel for the whole window; keep the master copy in hand and size the window from a measured restart plus a 5-minute verification checklist.

Questions