The web server built into an HMI panel serves static JPEG screen captures named by screen number, with no tag interface. Image-mapped HTML pages over those captures, reloaded every 60 seconds behind a VPN, make a workable read-only remote view; live values need a separate path.
An HMI panel's built-in web server serves pictures, not values. Point a browser at a panel that has an Ethernet port and you can pull a JPEG capture of any project screen by its screen number. There is no address that returns a tag value, and nothing on the web side writes to the PLC. For a read-only look from a desk that is enough to work with: build one HTML page per screen you want published, lay image-map hotspots over the captures so the pages navigate like the panel, and reload every 60 seconds. This page explains what the web server can and cannot expose, where the 60 second figure comes from, and how to tell whether a 60 second picture is accurate enough for the value you want to watch.
What the web server serves
Every panel in this class that carries a built-in Ethernet port carries the web server with it; engineers have run it on 6, 10 and 15 inch panels. A panel with only serial ports has nothing to browse to.
The addressable content is one JPEG per project screen, named by screen number: 1.jpg, 2.jpg, 3.jpg, and so on. Request a capture and the panel returns the screen as it would render it, no matter what the local display is showing at that moment. A screen the operator has not opened in weeks still comes back with a current picture.
That is the whole interface. There is no tag list, no value query, no write path. Refreshing the browser gets you a newer picture, not live data.
Why no setting turns it into a tag server
Settle the question the pages cannot fix before building anything:
| Tried | Why it stops |
|---|---|
| Browse to a tag name or address on the panel | The server hands out screen captures only; there is no tag interface to address |
| Put a clickable write button on the page | A browser click cannot become a touch event on the panel; nothing sends data back toward the PLC |
| Ask the page which screen the operator is on | The web server has no knowledge of the local display and cannot change it |
| Shorten the refresh interval for near-live values | You get more copies of the same static capture, and the panel's web task runs at low priority |
If the written requirement says "read tags" or "enter setpoints", the panel web server is the wrong tool and no setting changes that. Route that requirement to a separate data path. The rest of this page covers the case the web server does serve, which is checking screens from a distance, read-only.
The page set that works
Build one HTML page per published screen. Each page loads the panel's capture for that screen number and overlays image-map rectangles on the buttons an operator would press, so a hotspot over the alarms button opens the alarms page. Clicks move the remote viewer between pages; they never reach the panel or the PLC.
Name pages to match captures so the links stay readable: 7.html shows 7.jpg, 38.html shows 38.jpg. A minimal page:
<html>
<head>
<meta http-equiv='refresh' content='60'>
</head>
<body>
<img src='7.jpg' usemap='#nav' border='0'>
<map name='nav'>
<area shape='rect' coords='340,180,520,240' href='38.html'>
<area shape='rect' coords='340,260,520,320' href='3.html'>
</map>
</body>
</html>
The content='60' line is standard HTML: the browser reloads the page every 60 seconds on its own. The coords rectangles are illustrative; take real pixel coordinates from the capture of your own screen, and take them fastest in a visual web editor that lets you drag rectangles over the image.
Three rules keep the job small. Build pages only for screens a remote reader will actually reach; on a project with hundreds of screens, 15 to 20 published screens is the practical ceiling, because every screen is another page mapped by hand. Keep the refresh at 60 seconds; a shorter interval only loads the panel further. On a large project, use a two-frame index with a collapsible menu of the 150-plus screen numbers on the left and the mapped capture on the right.
Load the finished pages onto the panel by FTP; the panel's own documentation prints the login details and the file location for your model. Then open the index from a PC on the far side of the link and click every hotspot once. A dead hotspot means a wrong page number or a missing upload.
Scenario: a dryer temperature checked from the office
Scenario: a plant manager wants to glance at a dryer from an office in another building. The project has 28 screens; the manager needs the overview (screen 1), the dryer screen (screen 7) and the alarm summary (screen 38). That is three mapped pages plus an index, four files to upload.
The dryer temperature on screen 7 drifts about 2 °C per minute. The page reloads every 60 seconds, and after each reload the panel renders and serves the capture. Assume the panel serves a capture within 30 seconds even when busy; the oldest number the manager can then see is 60 + 30 = 90 seconds, or 1.5 minutes, behind the panel.
The reading error is the rate of change times that staleness: 2 °C/min × 1.5 min = 3 °C at worst. For a check of "is the dryer holding band", 3 °C of age is acceptable. Contrast a hopper weight gaining 30 kg per minute: 30 kg/min × 1.5 min = 45 kg of error at worst. A number that wrong is worse than none, because it looks authoritative.
The decision rule falls out of the same multiplication: staleness = 60 s + serve time, reading error = rate of change × staleness. Multiply the rate of the value you care about by 1.5 minutes; if the product sits inside the tolerance of the check, publish the page. If it does not, that value needs a live path.
Commissioning check: change a value at the panel, wait one 60 second cycle, and confirm the remote picture updates. Then drop the VPN link once on purpose, so everyone learns what a frozen stale image looks like.
Slow serving and stale pictures
The web task runs at low priority in the panel's CPU, and that ordering is correct: the operator standing at the machine comes first. Under load, captures serve slowly, and a slow fetch looks like a fault in the browser, which falls back to the copy it already stored. A remote viewer can stare at a minutes-old picture with no error on screen.
| Symptom | What it points to | What to do |
|---|---|---|
| Picture never changes, no error | Browser kept its stored copy after a slow or failed fetch | Hard-refresh the browser; confirm the VPN link is up; keep the interval at 60 s |
| Pages crawl at busy times | Panel serving web at low priority while the local screen works | Wait it out, or publish fewer screens; keep the refresh at 60 s |
| Nothing loads at all | Link or routing down | Ping the panel address from the viewing PC; restore the link, then reload |
When the pages stop loading but an FTP session to the same panel still connects, the network is fine and the panel's web service is not. The walkthrough in when the web server stops responding but FTP still works sorts that split out.
What read-only buys, and where live values come from
The no-write limit is a safety property, so keep it. A browser nobody can push values through cannot start or stop anything. Publish the pages through a VPN and never port-forward the panel to the open internet; the same rules govern any embedded machine view, and how to embed a remote machine screen safely covers them.
When a check needs the actual number instead of a picture, build the data path on the controller side. A PC-based runtime reading the PLC directly is the standard route, and running the HMI on a PC when the panel has no web server starts that job. Some controller ecosystems also document a second, tag-driven web page served outside the panel's screen-capture server; your panel manual tells you whether yours has one. And when the office needs its own dedicated screen instead of a browser tab, one can sit at the end of a long run; connecting a remote HMI screen 1,500 feet from the PLC covers the cabling side.
Recommendation: Publish image-mapped capture pages at a 60 second refresh, behind a VPN, when the remote need is a read-only look at values whose rate of change times 1.5 minutes stays inside your check tolerance; keep the published set near 15 to 20 screens. When the reader needs a number accurate within seconds, or anyone needs to write from a desk, skip the panel web server and put a PC-based runtime or another controller-side path on the PLC network.
Before you build, confirm four things
- The panel has an Ethernet port; without it there is no web server to configure.
- You can reach the panel's IP address from the PC that will browse, over the VPN if the view is off-site.
- You know the screen numbers of the pages to publish, from the project itself.
- The panel's documentation gives you the FTP login and the upload directory for your model; use those as printed.
If all four hold, the page set above is buildable in an afternoon for a dozen screens, and the dryer arithmetic tells you which of those screens are worth the effort.
Questions
A panel without an Ethernet port has no built-in web server?
Right. The web server comes with the Ethernet port, so a panel that only offers serial ports has nothing for a browser to reach. Putting such a panel on the network means adding a separate device in front of it, and that device becomes the thing you secure, address and monitor. Check the port list for your model before planning any browser view.
Which screens are worth publishing to the office?
Publish the screens a manager actually checks: the overview, the alarm summary, and the two or three process screens whose values move slowly enough for a 60 second picture. Leave out setup, maintenance and calibration screens; out of context they mislead, and every extra screen is another page to map by hand. Around 15 to 20 published screens is a practical ceiling on large projects.
Do I need special software to view the pages?
No. The pages are plain HTML with JPEG images, and the 60 second reload is a standard HTML header, so any browser on a desktop, tablet or phone renders them. A full-size capture needs zooming on a phone. The one-time install is different: loading the pages onto the panel needs an FTP client and the credentials printed in the panel's documentation.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.