A finished Ethernet download can leave an HMI's web server hung while the network link stays healthy, and only a power cycle at the panel brings the page back. Treat the restart as recovery, run four pings and two browser tests to place the fault, and change no network setting until those checks agree.
The pattern is easy to recognize. An Ethernet program download to the HMI finishes, the runtime loads, and then the panel's web page refuses to open. Reopening the programming software on the PC changes nothing, and removing and restoring power at the panel brings the page straight back. This article gives you the check order that separates a hung web service from a real network fault, the subnet arithmetic that settles the router question, and a restart procedure that restores access without burying the cause. Everything here assumes the download itself completed; a transfer that fails partway is a different fault with its own checks.
Why does the HMI web server stop responding after a program download?
The download and the web page run as separate services in the panel, and a finished download can leave the web service hung while the network link stays alive, which is why a power cycle brings the page back every time.
That recovery split is the whole diagnosis. The web server is software running in the panel, and a power cycle restarts every piece of software in the panel at once, so power fixing it places the fault inside the panel. Installations that show this pattern show no fixed trigger either: the page dies after one download in some stretches and after many in others, with panel and programming PC on the same switch and the panel's address static the whole time. Treat every Ethernet download as one that can leave the web service hung, and treat the power cycle as a recovery that restores the service while the cause stays open.
Which symptom points to which cause?
Match the symptom to the layer before you touch anything: the table separates a dead web service, a dead network path and a stale router entry, and each row names the next check.
| What you see | What it points to | Next check |
|---|---|---|
| Download finishes, page will not load, reopening the console changes nothing | Web service hung in the panel | Four pings, then the page, from the same PC |
| Four pings time out right after a clean download | Network path or switch port | Link and switch port before the panel |
| Pings reply, page fails from two different PCs | Panel-side web service | Safe-state restart, then retest from both PCs |
| Pings fail from the programming PC, a second PC reaches the page | Router path between different subnets | Subnet arithmetic, then the router's address table |
| Restart brings the page back every time | Recovery confirmed, cause still open | Record versions and download counts |
| Page dies again after the next download | Repeatable service fault | Send the record to technical support |
A related case confirms the service-level view: when FTP on the same panel still answers while the page is dead, the fault is again in one service, and it is worked through in HMI panel web server stops responding but FTP still works.
How do I test the link and the web server separately?
Ping the panel's configured address from the programming PC with four pings, the count a Windows PC sends by default, then load the web page from the same PC; one pass plus one fail puts the fault in the panel, and two fails put it in the network path.
Run all three tests before changing anything. A passing ping tests the panel's IP stack; the page needs the web service answering on top of it, which is why a pass and a fail together is the cleanest panel-side verdict you can get from outside the cabinet. The second client matters because it separates a sick PC from a sick panel: if the second PC loads the page, look at the first PC's network settings and its path to the panel before touching the panel. When tests at different layers disagree, that disagreement is a pattern of its own, and red offline link indicator when the TCP port test passes works through another case of it.
Four timeouts straight after a clean download send you down a different road: check the link and the switch port first, because HMI panels invisible after power up: test the managed switch covers that isolation path.
Should I blame the subnet or the router?
Only when the programming PC and the panel sit on different subnets: a reprogrammed panel can sit with a stale entry in the router's address table, and a common enterprise-router default holds each entry for 4 hours before it ages out.
Compute it instead of guessing. Read the panel's address and mask from its configuration screen or project record, read the PC's the same way, and AND each address with its own mask, the bitwise step a subnet calculator performs: equal results mean same subnet and no router in the path, different results mean every reply from the panel must route. The different-subnet case is where the stale entry lives: after a reprogram, the router can hold an old hardware-address mapping for the panel, replies to the new state go nowhere, and the entry clears when it ages out. Waiting works, a manual clear works faster, and you touch the router only if you run that network or have the network team's approval. The same-subnet case in this pattern failed with both devices on one switch and a static panel address, so a static address on a shared switch rules the router out; take the checks above and go to the panel-side verdict.
How do I record the failure so support can act on it?
Record the software version, the firmware version, the panel address and the download count before the next planned transfer, then test the web page immediately before and immediately after, because the count that kills the page changes from one transfer to the next.
Change one thing per test. Keep the address, the browser, the PC and the project identical, and make the download the only variable: page test, transfer, page test, with the time written next to each result. After a second reproduction, that record turns a vague complaint into a case a support engineer can act on, which is exactly what this fault needs, because nothing on the outside of the panel shows it. The same record-first discipline applies when a firmware update leaves the panel with no communication; the trigger differs and the habit is the same.
What is the safe way to power-cycle and retest?
Treat the restart as recovery only: put the machine in a safe state under your site procedure, break and restore panel power, wait 30 seconds after the panel finishes starting, then run the same ping and browser tests from the same client.
Break power only at the panel's power feed, never by pulling the network cable; the cable plays no part here, and a dead link looks exactly like the fault you are chasing. The one safety rule: the restart interrupts the HMI while the line runs, so agree the moment with the operator and reach a safe state first.
- Write down the failed tests: the page address, the four ping results, the time.
- Coordinate with operations and reach a safe state.
- Remove panel power, restore it, and let the panel finish starting.
- Wait 30 seconds after startup finishes, so an early test cannot read as a second failure.
- Send the same four pings from the same PC.
- Load the page from the same PC, then from the second client.
- Record whether the page returned, and leave the record open until the next download confirms or clears the pattern.
Access is restored when the page loads from the client that actually needs it; anything less is a partial result.
Worked example: why can I ping the panel but not open its web page?
The scenario ends with a hung web service on a healthy network, and the subnet arithmetic plus four replies under 1 ms are what separate it from the router case.
Panel at 192.168.1.50, mask 255.255.255.0. Programming PC at 192.168.1.10, same mask. Subnet arithmetic: 192.168.1.10 AND 255.255.255.0 gives 192.168.1.0, and 192.168.1.50 AND 255.255.255.0 gives 192.168.1.0. Equal, so no router sits between the two machines and the stale-entry explanation is out. Four pings to 192.168.1.50 return four replies, each under 1 ms on the shared switch, so the panel's IP stack is answering. The browser on the programming PC cannot display the page, and a second PC at 192.168.1.20 fails the same way. Verdict: healthy network, hung web service. Run the safe-state restart, wait the 30 seconds, and the page returns from both clients.
Now move the programming PC to 192.168.2.10 with the same 255.255.255.0 mask. The arithmetic changes: 192.168.2.10 AND 255.255.255.0 gives 192.168.2.0, which is not the panel's 192.168.1.0, so every reply must route. The identical symptom now has a different first suspect, the router's entry for the panel, with the 4 hour default as the long version of the wait. Same dead page, opposite verdict, and the subnet arithmetic is what tells the two cases apart.
What do I do after the panel fails a third time?
Recommendation: run the three checks (four pings, page from the same PC, page from a second client) after the first unexpected failure, restart once through the safe-state procedure, and send the version-and-count record to support after the second reproduction; change no network setting until the checks point at the network.
Two more decisions close the job. If downloads keep killing the page while the case sits with support, move the next transfer off the network and deliver the project on a flash card; Send an HMI program update to a customer on a flash card walks through that delivery. And if the line also needs a separate notice or status screen running alongside the HMI, our shop-floor signage is built for that job; the HMI keeps its own role either way.
Questions
Does reopening the programming console bring the web page back?
No. In installations with this pattern, closing the programming software and starting it again left the page dead; the only action that restored it was removing and restoring power at the panel. Skip that step and go straight to the three checks, because a console restart costs time and touches nothing on the panel's side of the connection.
Is a static address safer than an automatic one for the panel?
For this fault, no address setting prevents it: the same pattern showed up with a static panel address. What a static address does buy is a number that never moves, so the pings, the subnet arithmetic and the restart retest all aim at the same target without re-reading the configuration first.
Does this fault damage anything in the panel?
Nothing in the pattern points to damage: the panel kept accepting downloads, and a power cycle restored the page every time it was tried. Treat it as a software state you recover from. The cost is the restart itself, which is why the safe-state procedure in this article matters.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.