Two cameras, one HMI screen, and the browser shows one picture: the address you open points at one camera's web server, so it can only ever render that camera. The fix is structural, not a hidden setting. Give each camera its own viewer element on the screen and bind each element to its own address. This guide walks the six steps: prove each stream URL in a browser, place one widget per camera, bind separate string tags, match refresh mode to stream type, lay out the grid, and budget bandwidth and decode before deployment. Controls and vision engineers building a multi-camera page on a panel or vision controller will leave with a screen that holds up on the line, not just on a laptop.
The rule: one address serves one viewer
A web viewer or IP-camera widget is a browser in a box: it fetches the resource named by its source address and draws whatever comes back. It knows nothing about your other cameras. An address like http://192.168.200.1:8080/jpg names one endpoint on one camera's web server — one scheme, one host, one port, one path — so it returns one camera's frames for as long as the line runs.
The consequence is one widget per camera. Camera A at 192.168.200.1 and camera B at 192.168.200.2 are two different servers; camera B's picture lives at camera B's own address, on the same port and path its built-in web page uses. Two widgets, two addresses, one screen. When two tiles show the same picture, the cause is almost always two widgets reading one shared string, not a limit of the screen.
Read a camera stream URL
Split the example address into its parts. The scheme (http) is the transport. The host (192.168.200.1) is the camera — change it and you change cameras. The port (8080) and path (/jpg) are whatever that camera's web server exposes, and the camera's own configuration page is the authority for both. The query string (?q=10 in the floor example) carries per-request settings such as compression quality, or a timestamp that keeps a proxy from serving one cached frame forever. Keep the parameters your camera actually uses; test any change in a browser tab before it reaches a tag.
Two stream types behave differently in a widget:
- An MJPEG URL holds the connection open and pushes frames; the widget updates itself.
- A snapshot JPEG URL returns one image per request; the widget needs a refresh trigger — a timer or a tag change — to look live.
One case looks like an exception: two camera heads in one housing share a single IP. The second head then answers at a different path or query value on that same address, and the device's own web page lists both. The rule survives: one server, one address, one path per channel — you address the channels, not two boxes.
Build the screen in six steps
You need four things before you open the editor: the IP, port and path of every camera (from each camera's web interface or the switch's DHCP lease table); network reachability from the HMI to every camera; a runtime with a web viewer or IP-camera widget; and a timer element if any camera serves snapshots. Then build:
- Prove each address in a browser. On a PC on the camera network, open every URL in its own tab. The browser is ground truth: what it renders, the widget renders; what fails there fails in the HMI too.
-
Place one viewer widget per camera. Two cameras means two widgets on one screen. Name them after stations —
StationA_View,StationB_View— so a swapped binding is visible in the widget list at a glance. -
Bind each widget's source property to its own string tag. Set the tag type to string and give it the full URL as its initial value:
CameraA_URL = 'http://192.168.200.1:8080/jpg',CameraB_URL = 'http://192.168.200.2:8080/jpg'. The tag names are illustrative; every HMI toolkit keeps a string tag table. Binding beats typing the URL into the widget: a runtime write re-points a tile without a screen edit. - Match refresh mode to stream type. Leave an MJPEG widget to stream on its own. Give a snapshot widget a timer set to the camera's frame period or slower: a 10 fps camera refreshed every 100 ms shows all ten frames; refreshed every 500 ms it shows two.
- Lay out the grid from the panel's pixel budget. On a 1920×1080 display, a 2×2 grid gives four tiles of 960×540 — a clean home for 1280×720 streams. A 3×2 grid (three across, two down) gives six tiles of 640×540 — a natural fit for 640×480. Label every tile with its station, and if the page archives images too, the grid layout with per-camera output folders guide covers the storage side.
- Test on the panel, not the engineering laptop. Run production motion and read tile update rate and runtime CPU on the target hardware. Twenty decodes per second that a laptop shrugs off can stall a low-power panel; the multi-camera system design guide plans the capture side that feeds these tiles.
Budget bandwidth and decode before you add tiles
Every tile bills the network for its stream and the panel for its decode, and both bills are arithmetic:
Worked example — two 640×480 MJPEG cameras at 10 fps:
- A mid-quality 640×480 JPEG runs about 40 kB per frame (307,200 pixels; a busy scene pushes 60 kB, an empty one drops to 25 kB).
- Per camera: 40 × 10 × 8 / 1000 = 3.2 Mbit/s.
- Two cameras: 6.4 Mbit/s — 6.4% of a 100 Mbit/s link.
- Decode: 20 frames/s × 0.31 MP ≈ 6.2 Mpx/s on the panel.
Scale it up and the decision appears. Four 1920×1080 cameras at 15 fps, near 200 kB a frame, draw 200 × 15 × 8 / 1000 = 24 Mbit/s each — 96 Mbit/s together, which saturates a 100 Mbit/s link. Keep the tile total under half the link's rated speed for burst headroom, and put four or more 1080p-class tiles on gigabit. Where the cameras share a host with the vision runtime, the two GigE cameras on one host: NIC ports and bandwidth budget guide runs the same math for capture traffic.
Choose the runtime that hosts the screen
The host needs a network port group per camera VLAN plus one for the plant network, and CPU headroom for the decode total you just computed. On a vision line the natural choice is the same vision controllers range that already talks to the inspection cameras: one box, one power feed, and the light channels you already use.
Both controllers below carry 8 GB of memory and 4 built-in light channels; the MV-VC2140-128G40-1T offers 3-4 LAN ports for a compact cell, and the MV-VC3301H-128G66 offers 5+ LAN ports and PCIe expansion for a line with several camera networks.
- LAN ports
- 3-4 LAN ports
- USB 3 ports
- 2 USB 3 ports
- LAN ports
- 5+ LAN ports
- USB 3 ports
- 3-4 USB 3 ports
If the panel also runs the inspections and strobes 8 built-in light channels, this class fits: an Intel Core i5, 32 GB of memory, 5+ LAN ports with PoE camera ports, and PCIe expansion for a capture card later.
- LAN ports
- 5+ LAN ports
- USB 3 ports
- 3-4 USB 3 ports
- PoE
- PoE camera ports
- Light outputs
- 8 built-in channels
A PoE camera port earns its keep on a viewing host: a display-only camera that powers from the port needs no injector at the cell. To size cameras, optics and runtime in one pass, the system configurator walks the chain step by step.
When a viewer widget is the wrong tool
A viewer widget speaks HTTP, and the area scan cameras in the inspection cell speak GigE Vision, USB3 Vision or CoaXPress. Point a widget at a GigE Vision camera's IP and nothing renders: no web server, no /jpg path behind it. The machine vision connectivity standards guide maps which interface does what, and the camera finder filters the range by interface if you are specifying replacements.
Those frames reach a screen through the acquisition runtime that owns the camera. The live display on a second monitor without a frame grabber guide covers rendering from your own capture code, and the smart camera image in a PLC HMI guide covers screens where the camera's runtime renders first. If a second program tries to open a camera the vision software already holds, you get the device already in use error: one camera, one owner.
Two boundaries finish the picture. A frozen tile is a stalled request, not a dead screen — give each widget an activity tag the runtime bumps on every received frame and alarm on it, so an operator sees a stuck station before a quality escape. And close the door you opened: change every camera's default password at commissioning and keep the camera VLAN off the office network.
Check the screen before it goes live
- Swap test. Exchange the two tag values at runtime; both pictures must move to the other tile and move back. That proves each widget reads its own tag.
- Drop test. Unplug camera B at the switch: only B's tile freezes while A holds its rate. Reconnect, and B recovers within one refresh period.
- Rate check at full line speed. Every tile holds its commissioned rate (10 fps in the example above) with runtime CPU in headroom; if decode pushes past about three-quarters load, lower tile frame rates before you remove tiles.
- Link counters. Camera and HMI ports on the switch sit well under the half-link budget from the bandwidth section.
- Panel-native rendering. The page is drawn at the panel's resolution, not the laptop's — check fonts, tile borders and any text overlay on the smaller screen.
Common mistakes and their fixes
- One tag feeding two widgets. Both tiles mirror camera A. Fix: one string tag per camera, each with its initial value set at commissioning.
- URL typed into the widget. Swapping a camera becomes a screen edit and redeploy at shift change. Fix: bind to tags, as in step 3.
- Timer faster than the camera. Snapshot polling above the camera's frame rate returns duplicate frames and doubles load. Fix: timer period at least the camera's frame period.
- Credentials pasted into the URL. The password rides in the tag table. Fix: widget credential fields and a limited account.
- Laptop-only sign-off. The panel tells the truth about decode. Fix: step 6, on the target.
Once the tiles hold rate on the target panel, the screen is done. For a second opinion on the layout, the bandwidth math or the host, contact the applications team, or browse the other systems guides for the capture-side pieces this page links.
Questions
Why does my second camera tile show the first camera's image?
Both widgets are reading the same source — usually one shared string tag, or a copied URL that was never changed. Give each widget its own string tag and set it to that camera's own IP, port and path. To prove which tag a tile reads, swap the two tag values at runtime: the picture that moves between tiles is the tag doing the work. If the tiles still match after the swap, the widget binding, not the tag, is wrong.
How many camera widgets can one HMI screen show?
There is no widget-count limit to hit — the budget is decode and bandwidth. Using the worked numbers above, each 640×480 tile at 10 fps costs about 3.2 Mbit/s and 10 decodes per second, so six tiles total roughly 19 Mbit/s and about 18 Mpx/s of decode — easy on gigabit, measurable on a low-power panel. Start at four tiles, read CPU and tile rate on the target under production load, then add one at a time.
My camera serves single JPEG snapshots, not a stream — does a viewer widget still work?
Yes. Point the widget at the snapshot URL and re-request it from a timer or a tag change. The rate you see is the lower of the timer rate and the camera's own capture rate, so set the timer no faster than the camera produces; a 10 fps camera polled at 20 Hz doubles the network load for ten new pictures. Add the timestamp query value the camera supports so caching never serves an old frame.
The browser shows the image but the HMI widget shows nothing — what differs?
Usually credentials, caching or resolution. The browser carries a logged-in session and its cache; the widget starts clean, so a camera that demands a login serves it an error page instead of a frame. Configure credentials in the widget or connection settings, then open the exact widget URL — query values included — in a private browser window, which behaves closer to a widget than your daily session does.
Can I swap which camera each tile shows while the line is running?
That is the point of binding the URL to a string tag instead of typing it into the widget: write the new address to the tag and the widget re-points at its next refresh, with no screen edit or redeploy. Keep a commissioning table of camera IP, station and line position so a camera swap or spare replacement is a two-minute change, and rerun the swap test from the checks above to confirm.