Embed an IP camera stream in an HMI or SCADA window

An operator screen needs the same view the vision cell has: a live window inside the HMI, not a second monitor bolted next to the panel. The camera itself decides which of the three routes you can take. If it serves an HTTP MJPEG page, a URL or web-browser control shows it live with no extra software. If it only speaks RTSP, you add a decode path or a server that re-serves MJPEG. If neither exists, the JPEG snapshot URL polled every 1-2 s covers the fallback. The sections below give the three routes, the wire cost of each and the checks that keep the window honest.

Three routes to a camera picture in an HMI window

Every working install uses one of three mechanisms, and the camera's firmware decides which ones you have.

• MJPEG over HTTP. The camera's web server sends a continuous sequence of JPEG frames. Any HMI control that renders a web address draws it. Live motion, no extra runtime, no license.
• RTSP with a decoder. The camera streams H.264 or H.265. The HMI needs a native camera-viewer object or an embedded decode window; a plain URL control cannot open it.
• JPEG snapshot polled on a timer. The camera's web server returns one still image per request, and the HMI re-requests it every 1-2 s.

The routes share one requirement: the camera must be a network citizen with an HTTP or RTSP service. A device that only talks to its SDK has no page to point at, whatever the HMI can render.

Route 1: point the URL control at the camera's MJPEG page

Try this first because it adds nothing to the runtime. A network camera with a web interface almost always serves its live view as MJPEG over HTTP, and HMI and SCADA packages ship a control whose property is a web address: paste the stream URL in and the picture appears. In a typical SCADA camera object the address sits in a URL field among the object's general properties. The configuration steps and the usual failure points are collected in this SCADA MJPEG stream configuration guide.

Match the control to the stream. A control that renders full HTML handles MJPEG natively; a plain image control draws one JPEG and stops, which is the snapshot route in disguise. Size the control near the stream resolution or switch on fit-to-box, because some camera objects crop the picture to the control instead of scaling it, and the operator loses the edges of the scene without noticing.

If the picture the operator needs belongs to the vision sensor itself, the same logic applies once the sensor is on an Ethernet network. The MV-SC3050XC-16M-ATN-H is a 5 MP color vision sensor with a Fast Ethernet interface, a global shutter and an M12 lens mount:

Open the sensor's web page in a browser first. If it shows a live view, that address is the one the HMI control takes. If the camera only talks GigE Vision to its SDK, there is no page to embed, and the section below on cameras without a web server covers the workaround. For what a browser view on a vision sensor can and cannot show, see this vision sensor browser display guide.

Route 2: RTSP needs a decoder on the screen side

RTSP carries the camera's H.264 or H.265 stream, which a browser or URL control cannot render on its own. Three ways in, in the order to try them:

1. The HMI's native camera-viewer object. Modern platforms take the full RTSP address in the object's URL field and decode it internally. Check what the viewer accepts first, because some ship without RTSP support and only draw MJPEG; the RTSP support limits of a SCADA camera viewer spell out one common case.
2. A recording or VMS server. Feed the RTSP stream to the recorder and let it re-serve the feed as MJPEG over HTTP. The HMI drops back to Route 1, and recorded footage comes as a by-product.
3. Your own decode window. A small viewer application launched from the HMI project shows the stream, at the cost of a window outside the SCADA screen's graphics. If that window is your own code, the stream handling in decoding barcodes from a live RTSP or MJPEG stream applies unchanged.

RTSP viewers buffer by default, so expect 1-3 s between scene and screen until you shorten the buffer. The upside is wire load: 2-6 Mbit/s typical at this resolution, set by a bitrate field rather than by image content, which is why crowded networks prefer RTSP wherever a decoder exists.

Route 3: the snapshot URL polled every 1-2 s

Almost every network camera with a web server also exposes a URL that returns a single JPEG. An HMI timer requests it on an interval and updates an ordinary image control. Set the interval to 1-2 s: fast enough to follow a manual load or a jam, slow enough that the load is trivial — one 2 MP frame per second is about 2 Mbit/s, an order of magnitude below the live MJPEG stream.

Staleness is the cost, and it is bounded: one interval plus about 16 ms to move a 200 KB frame across a 100 Mbit/s link. The operator sees a picture at most about a second old. That serves presence, jams, levels and door states, and it fails for anything where a second of old picture causes a wrong action. When the snapshot feeds more than a status glance, budget the delay explicitly; the image-based control latency budget walks the full camera-to-action loop.

The URL format and the polling code for the do-it-yourself version live in grabbing images from an IP camera over an HTTP snapshot URL. Brightness problems are camera settings, not HMI settings: exposure and gain belong to the camera, and runtime exposure and white-balance control shows how to adjust them while the line runs.

Compact terminals narrow the choice. A Windows CE operator target usually has no RTSP decoder at all, which makes the polled snapshot the standard camera picture there; IP camera video on Windows CE operator terminals shows that pattern end to end.

Worked example: a 2 MP camera at 15 fps on a 100 Mbit/s HMI network

The case: one monitoring camera hanging off the switch port that feeds the HMI runtime, next to PLC traffic. Inputs: a 1920×1080 frame, the 2 MP class where the largest group of shop vision sensors sits; 200 KB per JPEG frame at typical web quality, from the usual 150-300 KB range for that resolution; 15 fps, a common live-monitoring rate between full video and the 1-2 s snapshot fallback; a 100 Mbit/s Fast Ethernet port; and 20% protocol overhead for HTTP and TCP framing.

In words: MJPEG sends one complete JPEG per frame, so the line rate is bytes per frame, times frames per second, times 8 bits per byte, times the overhead factor.

The arithmetic: 200 KB × 15 fps = 3,000 KB/s. Times 8 bits = 24,000 kbit/s, or 24 Mbit/s. Times 1.2 for overhead = about 29 Mbit/s, which is 29% of the port. Two cameras reach about 58%; three reach 87%, which is saturation on a shared switched segment.

Decision: keep total MJPEG below half the line rate on a segment that also carries control traffic. One 2 MP camera at 15 fps is comfortable, a second is acceptable only if the segment is otherwise quiet, and a third means GigE or a camera-only VLAN. The same frame polled once per second costs 200 KB × 8 = 1.6 Mbit/s, about 2 Mbit/s with overhead, so the snapshot route keeps even a crowded Fast Ethernet segment comfortable.

Which route fits which screen

• The operator follows motion as it happens: Route 1, and Route 2 only if the camera refuses MJPEG.
• The camera is RTSP-only and a recorder already stands on site: Route 2 through the recorder, re-served as MJPEG so the HMI stays simple.
• The screen need is presence, jam or level status on a shared network: Route 3 at a 1-2 s poll.
• The camera is the vision sensor and results already appear on the HMI: draw the result overlay from the vision software's own HMI connection instead of the raw stream; what a smart camera image displays in a PLC HMI covers what each path actually renders.
• The operator must steer the camera: a browser control pointed at the camera's own page brings the pan, tilt and zoom buttons along; an image control cannot send PTZ commands.

Checks before you build the screen

1. Open the stream URL in a plain browser on the HMI runtime machine — same subnet, same VLAN, same credentials as production.
2. Name the control type before committing: URL or web control, native camera object, or image control plus timer. Each supports a different subset of the routes.
3. Match the control size to the stream resolution or switch on fit-to-box, so the operator sees the full frame rather than a center crop.
4. Count the port: the 29 Mbit/s figure assumes an idle Fast Ethernet link, and a switch port counter settles the real headroom in a minute.
5. Give the image control an update timeout, so a camera that stops answering greys the window out instead of leaving the last frame frozen.
6. Set the poll interval from the staleness the operator can act on, not from a default.

When the usual answer is wrong

A GigE Vision-only industrial camera has no web server and no RTSP stream, so none of the three routes applies. Publish the image from your own grab loop instead; embedding a machine vision camera stream in a web HMI covers that path, and a second monitor fed without a frame grabber is the quick stand-in. Mind exclusive access while you do it: a GigE camera that refuses to open in a second tool is usually the vision software holding the device.

The boxes that carry the streams

Whichever route wins, the screen runs on a machine with enough network ports to keep camera traffic off the plant network. The MV-VC2140-128G40-1T carries 3-4 LAN ports, 2 USB 3 ports and 4 built-in light channels; the MV-VC5525-256G70-NN steps up to 5+ LAN ports, PoE camera ports, 8 light channels and 32 GB of memory:

Splitting the camera network from the SCADA network at the box is what makes the bandwidth arithmetic hold in production, and PoE camera ports remove a shelf of injectors when the cameras take power over the wire.

To choose the camera that goes on the screen, start at the smart cameras and vision sensors category or the camera finder; the runtime boxes sit under vision controllers. The systems topic page collects the display and integration guides, and the configurator steps through a full set-up. If the route is still unclear, send the camera model and the HMI platform through the contact page and we will pick the path with you.