Replacing analog cameras with IP cameras on an HMI

The fix is concrete: retire the analog camera and its capture card together, replace them with an IP camera serving an RTSP stream, and bind the HMI's viewer widget to that stream URL (TCP 554 by default) instead of reading frames off a card. Expect 0.5-2 s of glass-to-glass latency instead of one or two frames, plan a PoE port and roughly 15 W per camera, and keep any camera that does measurement on a machine-vision camera rather than an RTSP feed. This guide is for the controls engineer holding the HMI project: what changes in the signal path, the viewing-versus-measurement decision, the steps that wire each stream into the application, the bandwidth and decode arithmetic, and the hardware that carries the new path.

What changes in the signal path

The old path was short and synchronous: composite video over coax into a frame grabber, frames into the HMI's memory, one icon per camera. At 30 fps a single frame is 1 / 30 ≈ 33 ms, so glass-to-glass latency stayed around one or two frames, under roughly 70 ms.

The new path has no capture stage. The IP camera compresses each picture to H.264 or H.265, serves it as an RTSP stream (the RTSP default port is TCP 554) and sends it over ordinary Ethernet; the HMI pulls the stream in a web view or decoder widget and decodes it on the PC. The frame grabbers the old viewing path needed leave the bill of materials — they remain only for machine-vision cameras, which the next section sorts out.

What the simpler wiring costs is latency. The encoder finishes a group of pictures before a decoder can even start, the network and jitter buffer add their share, and tiles land around 0.5-2 s late on camera defaults. Decode itself is not the culprit: one 1080p frame decodes in tens of milliseconds on a current core. The seconds live in encoder buffering, which is why the tuning step targets the keyframe interval.

More HMI-and-stream integration guides sit on the systems topic page.

Decide first: viewing feed or measurement camera

Before touching software, sort the old cameras by their job.

If a camera only gave operators a live look — a hopper level, a guard window, a packaging line — an IP camera and an RTSP tile are the right replacement, and the delay is cosmetic.

If the camera fed an inspection — a gauge, a code read, a presence call that stops the line — an RTSP camera is the wrong tool. Compression smooths the very edges a gauge measures, rolling shutter smears anything moving, and frame arrival time varies, which breaks any timing tied to the image. Keep that job on a machine-vision camera speaking GigE Vision or USB3 Vision: uncompressed frames at a fixed rate into your acquisition code, global shutter when the part moves. That migration is its own project — replacing an obsolete analog NTSC frame grabber with USB3 Vision walks it, and the area scan cameras page is the parts source. If operators still want a wall tile of that station, run the machine-vision camera for the decision and add an IP view alongside it.

Size the measurement replacement from its smallest feature. A 40 mm field of view resolving 0.1 mm features needs 40 / 0.1 = 400 pixels across the part; a 5 MP sensor with about 2,600 pixels across carries a 6.5× margin. The calculator runs your own numbers:

A global-shutter GigE camera suits the smaller replacement jobs:

What you need before the cut-over

• Each camera's RTSP URL, username and password, and the names of its main and sub streams. The URL is shaped like rtsp://camera-address:554/stream-path; the path after the port is set by the camera family, so take it from the camera's integration guide rather than guessing it.
• A desktop media player on the HMI PC, to prove every URL before the HMI touches it.
• The viewer widget the HMI package provides: a web view control or a media/decoder control. If the package offers neither, embedding a machine-vision camera stream in a web HMI shows the pattern a custom control follows.
• Network gear: a PoE switch, or PoE NICs in the HMI PC, plus a VLAN if security wants the cameras off the office network.
• Decode headroom: hardware H.264/H.265 decode in the PC's graphics silicon, or CPU cores you are willing to spend.
• A written map — old camera, new camera, stream URL, HMI tile — that becomes the commissioning checklist.

Point the HMI at the RTSP stream

1. Collect the stream URLs. Take each camera's RTSP address and credentials from its integration guide, and note the sub-stream name: most cameras serve a small secondary stream around 640 × 360 to 960 × 540 alongside the full-resolution main stream.
2. Prove each URL outside the HMI. Open it in a desktop player on the HMI PC. A picture there means the network path is sound and any remaining problem is in the widget; no picture means a camera or network fault. Display an RTSP camera stream in an HMI: snapshot URL or VLC covers the URL forms cameras actually serve, including still-image URLs for widgets that cannot play video.
3. Add the widget and bind the stream. Place a web view or media control on the display and paste the URL into its stream-source binding — not into a script that opens a browser tab. A tile that shows a login page or stays black is usually bound to the camera's web page; putting the RTSP URL in the widget's binding field is the whole fix there.
4. Run wall tiles on the sub-stream. Eight main streams multiply decode load by eight; eight sub-streams cost almost nothing. Promote a tile to the main stream only when an operator maximizes it.
5. Shorten the keyframe interval where the camera exposes it. A decoder cannot join a stream mid-GOP; it waits for an I-frame. At 25 fps, a 25-frame GOP holds up to 1 s of finished frames, a 13-frame GOP about 0.5 s. Reducing RTSP frame latency ranks the settings by their effect.
6. Repeat, save, restart. Name each tile after its camera and area, save the application, and confirm every tile returns after an HMI runtime restart — live camera image in an HMI runtime: snapshots vs streams explains what survives a restart and what rebinds.

Size the network and the decode load

Two budgets decide whether the PC survives the cut-over: bandwidth and decode.

Bandwidth is the per-stream configured bit rate times the stream count. 1080p H.264 is commonly configured between 2 and 8 Mbps; H.265 reaches a similar picture at roughly half that; MJPEG costs an order of magnitude more and is a poor choice on a tiled wall. Compare the aggregate with the link: one Gigabit uplink carries 1,000 Mbps, and the plan should sit under 40% of it — 400 Mbps — so bursts, added cameras and an NVR pulling its own copy cannot stall the tiles.

Decode binds first. Software decode of 1080p30 H.264 costs roughly a third to half of a modern core per stream, so a quad-core PC spends about 2-4 of its cores on eight streams. The working rule: past about six software-decoded 1080p streams per PC, turn on hardware decode — current integrated graphics decode dozens of 1080p H.264 streams in silicon and leave the CPU to the HMI runtime.

The same arithmetic scales to any network video; streaming depth data over a network: bandwidth math and compression works a heavier version of it.

Where the HMI PC must also power the cameras, one card does both jobs:

Values as printed in each product's data sheet; open a part for its drawing and full specifications.

These cards sit in the accessories finder alongside the frame-grabber range.

Worked example: eight 1080p streams on one line-side PC

A plant retires a wall of eight analog cameras and lands all eight feeds as tiles on one line-side PC. Inputs, with their sources:

• 8 streams — the camera count being replaced.
• 1080p at 25 fps, H.264 at 4 Mbps per stream — a typical configured rate for 1080p H.264; the camera's stream settings page carries the actual value.
• One Gigabit uplink, 1,000 Mbps — the camera switch to the HMI PC.
• A quad-core PC with hardware H.264 decode available.

The rules are the three-line formula above plus the latency budget: GOP delay + jitter buffer + display delay.

• Bandwidth: 8 × 4 Mbps = 32 Mbps aggregate. Utilization: 32 / 1,000 = 3.2% of the uplink, a twelfth of the 400 Mbps planning ceiling. Even 48 cameras at the same rate would draw 48 × 4 = 192 Mbps = 19.2% — the network is not the constraint here, and would not be even after doubling the wall.
• Decode: 8 × 25 fps = 200 fps of 1080p. In silicon that is trivial. In software, at a third to half a core per stream, it is 8 × 0.33 to 8 × 0.5 ≈ 3-4 cores — most of a quad-core PC, which starves the HMI runtime.
• Latency: a 25-frame GOP at 25 fps contributes 25 / 25 = 1.0 s; the decoder's jitter buffer adds about 2-3 frames ≈ 0.1 s; display adds 1-2 frames ≈ 0.05 s. Total ≈ 1.15 s per tile on defaults, inside the expected 0.5-2 s band.

The decisions, with their thresholds:

• Network: 32 Mbps sits far under the 400 Mbps ceiling, so the existing 1 GbE uplink stands; no switch upgrade is justified by bandwidth at this scale.
• Decode: 8 software streams exceeds the 6-stream rule, so hardware decode is required, not optional.
• Latency: expect about 1.2 s as configured. Cutting the GOP to 13 frames and putting the tiles on the sub-stream brings the budget to about 0.5 + 0.1 + 0.05 = 0.65 s.

Choose the line-side hardware

The decode PC is the one part of the old rack that gets replaced rather than deleted. Three shapes cover it:

• A vision controller at the line. An industrial computer sized for mounting near the cell, with the LAN port counts a multi-camera wall wants — across the range, most models expose five or more LAN ports:

• A panel PC as the operator surface. Where the tiles render on the terminal at the line, size its decode with the same budget; industrial panel PCs cover the wall- and arm-mounted versions of that job.
• The existing HMI server. If it already has the cores and the graphics silicon, add nothing but the PoE card above and the VLAN.

Vision controllers earn their slot when the box also runs inspection: the same chassis then carries the machine-vision cameras on GigE Vision while the RTSP tiles render beside them. Where a station outgrows Gigabit — dozens of high-resolution streams, or one link shared with heavy inspection traffic — a quad-port copper 10GbE NIC separates the camera network from the plant network; the MV-GT2104 is that card.

Keep one legacy row in the plan: any analog camera that outlives the first phase keeps its capture card until its own swap, and integrating an analog frame grabber with vision software runs fine beside the new tiles.

Verify the picture, then the latency

Functional checks, per tile: the stream updates live; an unplugged camera produces the widget's explicit lost-signal state rather than a frozen last frame; the tile returns after a runtime restart; settings survive a camera power cycle.

Then measure latency once, so nobody argues about it later. Put a running stopwatch or the plant clock inside the camera's view and read the same time off the HMI tile; the difference is glass-to-glass latency. On defaults expect roughly 0.5-2 s. After the GOP cut and the sub-stream switch, a tile should land near the 0.65 s the worked example budgets, and a well-tuned direct stream under about 0.5 s. Re-measure after every settings change, and once more after a week of running — encoder firmware updates and drifted stream settings show up here first.

Finish with one full shift watched at peak: sustained dropped-frame counts, tile reconnects, and CPU headroom on the decode PC. A cut-over that looks clean at 10 a.m. and stutters at shift change was not watched long enough.

Common mistakes on an analog-to-IP cut-over

• Binding the tile to the camera's web page. The widget renders a login screen or a black square; the fix is the stream URL in the binding field, and an MJPEG viewer that shows no video is the same lesson in a different codec.
• Building on an NVR integration without a version check. NVR-to-HMI integrations are locked to specific HMI releases; an older runtime fails silently or simply omits the feature, which is an architecture discovered too late.

• Main streams on every tile. Decode load scales with stream count; eight 1080p main streams spend 3-4 CPU cores the tiles do not need. Sub-streams on tiles, main stream only full-screen.
• Multicast enabled but not routed. Some clients show video while others stay black. Set cameras to unicast to each client unless the switch network is deliberately built for multicast.
• Retiring an inspecting camera as if it were a viewing camera. The gauge loses resolution and timing together; inspection stays on machine-vision frames per the decision at the top.

Cut-over checklist

Per camera

• URL proven in a desktop player on the HMI PC.
• Sub-stream set for the tile; main stream reserved for full-screen.
• Keyframe interval shortened toward 0.5 s where the camera exposes it.
• Login moved from the factory password to the plant standard.

Network

• PoE budget checked: nameplate watts per camera times camera count, plus about a 20% reserve, against the switch total.
• Cameras on their own VLAN or switch, with TCP 554 and the management port reachable from the HMI PC only.
• Planned aggregate under 40% of the uplink.

Decode PC

• Hardware H.264/H.265 decode enabled and confirmed in the player's statistics overlay.
• CPU headroom at peak, all tiles running, for the HMI runtime.
• The six-soft-stream rule respected, or decode moved to silicon.

Acceptance

• Every binding saved and proven across a runtime restart.
• Glass-to-glass latency measured and recorded per tile.
• Lost-camera behavior confirmed on each tile.

When the map is filled in, the camera finder filters the inspection-side replacements by interface, resolution and shutter, and build a system starts the full chain from camera to controller. The applications team can sanity-check a stream-and-inspection split before anything is ordered — contact us.