Port 80 stops answering while FTP and the programming port still respond on the same IP, the HTTP task inside the panel has hung and the network is healthy. Set the clock source to internal as a stopgap, cap the web clients, and update the runtime firmware, which is the change that ends the hang.
An HMI panel that serves web pages on port 80, runs clean for a day or two, then refuses connections while FTP on the same IP address keeps answering has a hung HTTP task, and the network is healthy. The programming port keeps working too, and a power-cycle brings the web server back until the hang returns. That combination rules out the cable, the switch, the addressing and the browser. Two field changes matter: the panel's clock source, which stretches the interval between hangs from days to weeks when it is set to internal, and the runtime firmware, which is the update that has ended the hang on the panels that showed this fault. Work through the checks below before you reboot, because the reboot erases the evidence you need for the service ticket.
Why does the web page stop while FTP still answers?
Because the panel runs its web server, its FTP server and its programming port as separate tasks, a defect that hangs only the HTTP task on port 80 leaves FTP on port 21 and the programming port on 11102 answering on the same cable and the same address.
Each listener sits on its own TCP port: 80 for the web pages, 21 for FTP, and a third for the programming connection, whose number the panel's manual or the editor's connection settings print. A fault that kills one listener while the other two answer points straight at the task behind the dead one.
Match what you see against this list:
- Port 80 refuses or times out while FTP and the programming port still connect: the HTTP task is hung, and this is the fault this article fixes.
- Port 80 comes back after a power-cycle and dies again within one to two days: the same fault, and that interval becomes the baseline for the validation run.
- All three services go quiet together: power, Ethernet link, IP conflict or panel lockup. Different diagnosis, covered at the end of this article.
- Pages load but the values on them are stale or wrong: the HTTP task is alive and the fault sits in the data path.
- FTP also refuses connections: the fault is wider than the web server, so check the link and the network settings before you touch firmware.
Which checks do I run before I power-cycle the panel?
Capture the evidence first, because the reboot destroys it: from a PC on the same subnet, test TCP port 80, open an FTP session, connect the programming software, and write down the runtime version plus the number of clients that had pages open.
Work down this list, then reboot:
- Test the web port from PowerShell on the PC:
Test-NetConnection -ComputerName <panel-ip> -Port 80, with the panel's address in place of<panel-ip>. Record whether the TCP connection succeeds, times out or is refused, and the time. - Open an FTP session to the same IP from the same PC and list a directory. FTP working while port 80 times out pins the fault on the HTTP listener.
- Connect the panel's programming software over the programming port, 11102 in the setup described here, and record the result.
- Write down the date, the time, and how many browsers or clients had the panel's pages open in the hours before the hang.
- Read the four firmware versions from the panel's information screen. The panel in the reported cases read: hardware 1400, boot loader 1003, runtime 1.21.6.18, boot screen 1.21.6.18.
- Power-cycle the panel and run the port test again. When port 80 answers, you have the fault described here and the record that shows where it sat.
What do I change first when the firmware update is weeks away?
Two stopgaps buy time: set the panel's clock source from external to internal, which stretched the interval between hangs from days to weeks in the reported cases, and cap the number of simultaneous web clients, because the hang shows up earliest under multiple requests.
Clock source. Open the project in the panel's programming software, find the clock or time synchronization source setting, change it from external to internal, download the change to the panel, and set the panel clock by hand against a known reference. The screen location varies by software version, and the software's help page shows the path for yours. In the reported cases this single change moved the hang interval from days to weeks. An internal clock drifts, so when operators or records read timestamps from the panel, put a manual correction on the schedule; the FAQ below carries the drift arithmetic.
Web load. The server also renders page images for screens nobody is viewing, and every open client adds that work, so the hang arrives sooner as clients stack up. Close the tabs sitting on screens nobody watches, keep remote viewers on a short list, and switch off any script that polls the pages on a fast timer.
Timed power cut. A power cut on a timer restores the web server on a schedule, the hang returns on its own, and the operator screens blank for the length of the restart. If the panel is fed from a rail-mount 24 V DC supply in the cabinet, the timer can switch that low-voltage feed, which is simpler than switching a mains circuit. None of these three changes repairs the defect in the old runtime code, so the firmware update stays on the schedule.
How do I update the runtime firmware so the hang stops?
The firmware update is the repair: panels moved off runtime 1.21.6.18, one to 1.30.7.21 and others to 1.31.7.27 from the EA01310727.eas package, and the hang stopped, so record your versions, back up the project, and flash the newest release your hardware revision accepts.
- Record the four versions from the information screen, so the ticket shows the before and after.
- Back the project up from the panel to your PC.
- Download the current runtime from the panel maker's official support page, matched to your hardware revision. The versions in this article come from an older release cycle; take the newest one the release notes list for your hardware.
- Read the release notes before you flash: they state hardware compatibility and whether a boot-loader step comes first.
- Apply the update through the programming software's firmware update function with the machine in a safe state, and leave power on for the whole transfer. One safety note: removing power mid-transfer can leave the panel without a working runtime, and the operator loses the panel view for the length of the update, so pick a window when the line can spare it.
- Confirm the new runtime number on the information screen, then re-download the project if the update cleared it.
- When the panel stops communicating after the flash, work through the communication checks after a firmware update in order, and when the transfer stops over a missing file, the missing firmware file fix covers that case.
Worked example: how long must one panel run clean before I trust the fix?
Run one panel for twice the longest interval you ever saw between hangs: a panel that hung every two days on runtime 1.21.6.18 and stretched to 15 days on the internal clock needs a clean 30-day run with several browsers open before the fleet gets the update.
The scenario: a packaging line panel hung every one to two days, worst case two days, while three shop browsers and one tablet held its pages open. The port test showed port 80 timing out while port 21 and port 11102 connected, so the HTTP task was hung, and the information screen read hardware 1400, boot loader 1003, runtime 1.21.6.18, boot screen 1.21.6.18.
The clock source moved from external to internal that afternoon, and the next hang arrived after 15 days: 15 ÷ 2 = 7.5, so the interval grew 7.5 times. Two weeks later the runtime went to 1.31.7.27 from the EA01310727.eas package. The validation target was twice the worst interval seen on the internal clock: 2 × 15 = 30 days, which is 30 ÷ 2 = 15 times the original two-day failure interval. At day 32, with four clients open, the panel was still serving pages, FTP and the programming port still answered, and the same firmware went out to the remaining panels on the line.
| Check | Pass condition |
|---|---|
| Runtime version on the panel | Shows the new number, never 1.21.6.18 again |
| Port 80 test from a PC | TCP connects and the page loads |
| FTP and programming port | Answer during and after the whole run |
| Concurrent clients | Pages keep serving with several browsers open |
| Elapsed clean run | Longer than twice the previous worst interval |
Change one variable at a time where a spare panel exists, so the panel that runs clean tells you which change mattered.
Recommendation: Set the clock source to internal the day you confirm the fault, cap the web clients at the same time, and schedule the runtime update for the next maintenance window; flash one panel first, run it clean for longer than its previous worst interval between hangs, and roll the same firmware across the rest of the fleet only after that run passes.
When is it a different fault?
Treat it as a different fault the moment all three services go quiet together: dead power, a failed Ethernet link, an IP address conflict or a panel lockup, each of which takes FTP and the programming port down along with the web server.
Work cheapest first: link LEDs at both ends of the cable, then the switch port, then a ping to the panel's address, then the panel's power feed. A panel that answers pings but delivers no data has a different problem again, and the protocol driver check separates a data fault from a network fault. When the Ethernet link itself drops and returns on a schedule, the returning Ethernet adapter fault is the closer match.
Questions
Does remote access through a router change the diagnosis?
Test from the same subnet as the panel before you judge anything. If port 80 answers from a PC on the local network but fails from outside, the forwarding rules or the firewall carry the fault and the panel firmware is not involved. Repair the local hang with the firmware update first, then add remote viewers back one at a time, because each connection loads the service that was hanging.
Where do I get the current runtime firmware for my panel?
The maker's official support downloads are the only source, matched to your hardware revision and read together with its release notes. The versions printed in this article, 1.21.6.18 and 1.31.7.27, belong to an older release cycle; they stand as evidence that moving off 1.21.6.18 ended the hang. Read the notes for boot-loader requirements before you flash, and keep the project backup you made at the start.
How fast does the internal clock drift once synchronization is off?
A panel clock on a plain crystal drifts by seconds per day. At a typical 50 ppm crystal tolerance, a day holds 86,400 s and 86,400 x 0.00005 gives about 4.3 seconds of drift daily. Put a weekly correction against the plant reference on the schedule when records or operators read timestamps from the panel, and re-check the clock after every daylight saving change.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.