An HMI panel's web server only serves its own screens to a PC that connects in; the panel has no web client, so it cannot open an intranet page or render an IP camera stream. Put the page or camera on a display documented to render it, sized from the operator's viewing distance.
A panel that serves its screens to a web browser looks, at first glance, like a device that could also browse. It cannot. The web server on an HMI panel works in one direction only: a PC connects in and views the operator screens. The panel has no browser engine, so it cannot reach out to an intranet server, open a web page, or pull the stream from an IP camera onto its own display. This page explains the direction of the connection, what the documented remote-access feature actually delivers, and the display path that puts an intranet page or a camera picture in front of operators, sized to where they stand.
Can an HMI panel open a web page or show an IP camera on its own screen?
No: an HMI panel serves its own screens to a PC over its web server, and it has no browser engine to fetch and render someone else's page, so an intranet page or IP camera view will not appear on the panel's own screen.
The panel's runtime draws exactly the screens its project defines, and its web server publishes those screens outward to connected PCs. Nothing in that pair holds a URL bar, an HTML parser, or a decoder for someone else's video. Turning on the web server, updating the panel software, or enabling a remote-access option changes who can look at the panel; it adds nothing that lets the panel look at anything else. The same applies to a camera hanging off the same switch: a project can show camera content only where the panel documentation lists camera support for that exact model, and a general web page is a different function again. Plan it as two devices from the start: control and alarms stay on the panel, and the page or camera gets a display of its own.
What is the difference between a web server and a web client?
The difference is which end opens the connection: a web server waits for a PC to connect and serves the panel's screens, while a web client reaches out to another server, pulls a page or stream, and renders it, and the panel ships with only the first half.
A server answers; a client asks. Rendering is the client's job: parse the page, run its scripts, lay out the text, decode the video. An HMI runtime skips all of it because it draws project screens with its own graphics engine, so the machinery a web page needs is absent from the firmware, and no project setting installs it.
| Job | Who opens the connection | Who renders | Hardware that does it |
|---|---|---|---|
| View or control the panel from a PC | The PC | The PC | Documented client program or browser |
| Show an intranet page on the floor | The display device | The display device | Browser-capable x86 panel PC |
| Show camera video on the floor | The display device or decoder | The decoder | Stream decoder or camera monitor |
Software built for the web keeps that split too: the server publishes pages, and a browser on the client device does the parsing, layout and video work, which is how an industrial HMI suite renders its pages in browser sessions.
What does the panel's remote access feature do?
Remote access runs the direction you already have: a PC connects to the panel's web server to view, and where the feature allows it, to control the panel behind a password; one panel family documented it from software version 2.4 and later, set in the panel's network settings.
In that documented arrangement, each remote user downloads a small client program from the panel's own web page, and a switch in the touch panel's network settings turns the feature on; newer panel families more often serve the screens straight to a browser. One current panel family's remote-connection settings define two passwords for remote access, so give the operating password to the people who may touch the process and keep the second with engineering. Either way the PC is the client and the panel is the server, which is the opposite of what a camera page requires. Getting to that page from outside the plant is its own job: start with a VPN router set up for remote PLC and HMI access, and if the path stalls, test each port forwarding step in order.
How do you get an IP camera picture onto the shop floor?
You get the camera onto the floor by giving it its own rendering path: a decoder or monitor documented for the camera's stream format, a browser-capable panel PC for an intranet page, or a card-fed display that shows a refreshed still image on a schedule.
Start from the camera's documented output, because everything downstream follows it. Most network cameras expose a live stream and a still-image URL, and they are different jobs:
- Live stream: a decoder or a monitor whose documentation names the camera's stream format and profile. Stream support is per model, so get the match in writing before purchase.
- Intranet page: a browser-capable x86 panel PC or mini PC mounted where operators look, driving the screen over its video output.
- Still image on a schedule: a snapshot pulled to a file and shown on a display that plays image files from a card; the camera still refresh on an operator display covers the refresh loop, and remote camera snapshot checks cover the camera side.
Reachability is step one of three: the camera must answer the network, the receiving device must decode its format, and the picture must survive a power cycle at the final screen.
Which display should show the intranet page or camera view?
The display that shows the page or camera view follows three numbers: the viewing distance, the light that falls on the screen, and how many hours a day the screen is on, because those decide letter height, brightness tier, mount and power.
Distance sets letter height with the FHWA sign rule, 30 ft of viewing distance per inch of capital letter height, tightened to 20 ft per inch where operators read between tasks; the screen size and viewing distance guide works the full method for other rooms and distances. Light sets the brightness tier: screens away from windows carry typical indoor ratings of 300 to 400 nits, and a wall that faces windows or high-bay fixtures is the tier suppliers list at 800 to 1000 nits. Hours set the hardware: a screen that is on every shift needs a mount rated for the display's weight with margin, a power feed that survives the building's switching, and the supplier's rated panel life in hours as the figure to compare. If the job is a second screen beside the HMI for a camera still, a production count or a notice board, that is what our panel-mount Android displays are built for: image and video files played from a memory card or USB stick, no subscription, mounted in a panel cut-out.
Worked example: how large does on-screen text need to be at 12 ft?
At a 12 ft viewing distance the FHWA planning rule of 30 ft per inch of letter height asks for 0.4 in capitals, and the faster 20 ft per inch rule asks for 0.6 in capitals on a 1.02 in line pitch.
The arithmetic for a station whose screen sits 12 ft from the operator:
- Leisurely reading minimum: 12 ft ÷ 30 ft/in = 0.4 in of capital height.
- Fast reading between tasks: 12 ft ÷ 20 ft/in = 0.6 in of capital height.
- Line pitch at the fast figure: 1.7 × 0.6 in = 1.02 in per line.
Take a typical 21.5-inch 1920 × 1080 monitor for the page. A 16:9 panel of that diagonal has an active area of 21.5 × 16 ÷ √(16² + 9²) ≈ 18.74 in wide and 193.5 ÷ 18.36 ≈ 10.5 in tall, which is 1920 ÷ 18.74 ≈ 102 pixels per inch. The fast-reading capital height becomes 0.6 in × 102 ≈ 61 px; typical UI fonts set capitals near 70 % of the font size, so 61 ÷ 0.7 ≈ 87, and a 90 px font is the value to style the page with.
Capacity at that pitch: 10.5 in ÷ 1.02 in ≈ 10 lines. A camera picture with a timestamp, a station label and six status lines fits with two lines spare. If the page must carry 15 lines, it needs 15 × 1.02 ≈ 15.3 in of panel height: a 31.5-inch-class 1080p monitor at the same distance, or the same 21.5-inch screen moved to 8 ft, where the fast rule asks 8 ÷ 20 = 0.4 in capitals on a 1.7 × 0.4 = 0.68 in pitch, and 10.5 ÷ 0.68 ≈ 15 lines.
Recommendation: keep control and alarms on the HMI panel, and put any intranet page or camera view on a display documented to render it; size that display at 20 ft of viewing distance per inch of capital height wherever operators read between tasks, and use the 30 ft per inch minimum only for text read at leisure.
How do you check each function before operators depend on it?
Test the three functions separately, because each has its own client and its own success check: remote access from a PC, the page render on the browser display, and the live camera image on its final screen after a restart and a reconnect.
- Remote access: from the intended PC, open the panel's web page, start the documented client, and confirm the operator screen appears. If control is enabled, run one control action with the process in a safe state and the password gate active.
- Page render: load the intranet page on the display device that will run it, on the operator VLAN, and confirm the text size and the refresh behaviour hold with the page left open through a full shift.
- Camera: power-cycle the camera and the display path, and set the target at a picture back within 60 seconds of power returning, with no password typed; a path that waits for a login at each reboot gets switched off within a week.
- Handover: show operators which screen carries which function, because a viewer window on a PC and the floor display look alike from across the room.
When is the panel's own web server useful?
The panel's web server earns its keep as a diagnostics door: an engineer opens the panel's web page from a PC in the office or over a VPN, views the operator screen, and checks tag values or alarm states without walking to the line.
That is the feature doing what its documentation says, and it pairs well with the separate display path: the panel keeps control and diagnostics, the browser display carries the intranet page, and the camera feed lives on its decoder. When the next question is what the server exposes beyond pictures, reading PLC tag values from an HMI web server covers the data side.
Questions
Does the camera display path need its own login?
Usually yes. The decoder, camera viewer or panel PC that renders the video keeps its own account, separate from the HMI project and from anyone's personal login. Plan one service account for it, write the password into the handover sheet, and confirm the picture returns on its own after a power cut.
Can one screen show several cameras at once?
Yes, through a decoder or network video recorder with a multi-view output: typical units combine four or nine camera streams into one picture on a single display. The limit is the documented per-stream resolution budget, because nine 1080p streams squeezed into one 1080p output leave each tile at about a third of the screen width, and small tiles read poorly at distance. Check the stream count and the output resolution before buying.
How much network bandwidth does one camera stream use?
Plan about 4 Mbps for one 1080p H.264 camera stream, the usual surveillance planning figure; a scene with lots of motion pushes it higher, and ten cameras then load the link with roughly 40 Mbps before spikes. Put cameras and the display path on their own VLAN so a busy production network or a malfunctioning camera cannot slow the HMI traffic that operators depend on.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.