IP camera widget shows no feed: put the RTSP URL in the binding field

You added an IP camera widget to the HMI screen, typed the camera's address into the URL field, downloaded the project, and the widget is still black. In most cases the network is innocent: the URL is bound in the wrong place. A camera address is a constant string, and this widget only reads it from the expression binding — a tag binding pointing at an empty variable gives the widget nothing to open. This guide takes the fix end to end: enable the stream on the camera, copy the address the camera itself prints, bind it correctly, then budget the bandwidth so several widgets do not swamp a 100 Mbps segment.

Why the widget stays black

The URL property on an IP camera widget accepts two kinds of input. A tag binding hands the widget whatever a variable currently holds; if that variable never carries a full, valid address, the widget has nothing to open and draws nothing. An expression binding takes the literal string. Because a fixed camera's address never changes at runtime, the string belongs in the Expression tab of the binding dialog — in both the initial-value field and the expression field, so the widget has it before the first frame request.

The second silent failure is the display format. The format selector must match the scheme: RTSP for an rtsp:// address, MJPEG for the camera's HTTP/MJPEG address. An RTSP URL in a widget set to MJPEG fails without an error message. The same rule governs embedding an IP camera stream in an HMI or SCADA window, so the habit carries across platforms.

What you need

• A laptop on the machine network, with the camera's IP address and a login that holds administrator or service rights.
• The camera's web management page, reached from a browser.
• The panel's engineering software and download access to the panel runtime.
• A player that accepts RTSP addresses, such as VLC, for the pre-test.
• Panel and camera in one subnet, or a router rule that joins them.

Enable the stream and copy the camera's own address

1. Log into the camera's web management page from the laptop. Smart cameras and IP cameras of this class serve their stream addresses from an on-camera web server.
2. Open the applications or streaming page. Most cameras print their ready-made RTSP and MJPEG addresses there. Copy them exactly: the camera has already assembled the correct path, port and profile, so there is nothing to reconstruct.
3. Check the RTSP switch. MJPEG is commonly on by default and RTSP off, and enabling it usually takes an administrator- or service-level login. Switch it on and save.
4. Paste the RTSP address into VLC's network-stream box on the laptop. If the picture appears, the camera side is finished; if not, fix the camera before touching the panel.
5. Note the MJPEG address as well. It is the low-bandwidth fallback for small diagnostic windows and the basis of a one-button live view from a snapshot URL.

Bind the address in the widget

6. Add the IP camera widget to the screen and open its properties.
7. Double-click the URL field to open the binding dialog. Choose the Expression tab, not Tag.
8. Paste the RTSP address into the initial-value field and the same string into the expression field. Leave the tag unbound.
9. Set the display format to RTSP so the selector matches the scheme.
10. Fill the Username and Password fields only if the camera asks for credentials; out of the box, most cameras stream without them.
11. Download the project to the panel and switch to run mode. The live picture should appear within a second or two. Once it does, set the widget scaling so the image fills its frame without distortion, the way the camera-image scaling guide describes.

Panel families hide these fields behind different menus. For one widely used panel family, the RTSP camera stream configuration walkthrough shows the equivalent screens step by step.

What one stream costs the network

Every widget pulls its stream for as long as the screen runs, so size the budget before you duplicate the widget.

Worked example, MJPEG: the camera serves a VGA diagnostic window at 15 fps with 60 KB frames — typical quality for that job. 15 × 60 KB = 900 KB/s. 900 × 8 = 7,200 kbit/s, about 7.2 Mbps. Five such widgets on one screen draw 5 × 7.2 = 36 Mbps: comfortable on a switched 100 Mbps segment by itself, tight once the same segment also carries I/O and acquisition traffic. The same scene over H.264 costs far less — roughly 1-2 Mbps at VGA and 4-8 Mbps at 1080p — so even ten RTSP widgets stay under 80 Mbps with margin on GigE. If the camera itself hangs on a 100 Mbps port, that port shares the budget, so keep heavy MJPEG feeds on cameras attached at GigE.

Snapshot windows are cheaper still. A 250 KB JPEG refreshed once per second costs 250 × 8 = 2,000 kbit/s, about 2 Mbps; every five seconds it drops to 0.4 Mbps. For a status window that updates a few times a minute, the snapshot route laid out in the RTSP, snapshot and player guide is effectively free.

Decision: RTSP for full-frame-rate views, MJPEG for at most five widgets per 100 Mbps segment, snapshots for slow status windows. Bandwidth is not the whole cost — each RTSP widget also decodes on the panel — so if CPU climbs with several 1080p windows, lower the camera's frame rate or move some windows to snapshots. An MJPEG window that hangs on a stale frame after a stream restart needs its client socket closed and its cache busted, as the MJPEG restart fix shows.

Two ports, subnets and the web widget

Panel and camera must sit in one routed network. Ping tells you the address answers, not that the stream port is open — and a ping that works while the camera's web page shows someone else's settings is an IP conflict, which the camera IP conflict fix walks through. Reserve the camera's address on the DHCP server or set it statically.

Expect trouble on a panel's second Ethernet port. Some panel runtimes bind their media services to the primary interface, so an IP camera widget or web widget fed through the second port stays black even though everything pings. Test the stream on the primary port first, then sort the networks deliberately: cameras on one, cell and office traffic on the other.

Where the runtime offers a web widget, point it at the camera's web management page and the configuration interface opens inside the HMI screen. Focus, exposure and stream settings become panel jobs, and combined with the panel's remote-access function the same screen serves off-site camera management. An HMI window only ever shows what the camera itself streams — the live-display mechanics are spelled out in what a smart camera image in a PLC HMI actually displays.

Common mistakes

• Address in the tag binding. The widget renders nothing. Move the string to the Expression tab, into both fields, and leave the tag empty.
• Format and scheme mismatched. An RTSP address in a widget set to MJPEG fails silently. Match the selector to the scheme every time.
• Judging the editor canvas. Streaming widgets often draw a placeholder until run mode. Download and judge in the runtime — the same teach-versus-runtime gap that trips vision locate tests.
• RTSP still switched off. The VLC test fails on the laptop too. Enable it under an administrator- or service-level login on the camera's pages.
• Panel and camera on separate VLANs. VLC works from the office laptop, the panel never connects. Add the route or move both onto one subnet.
• UDP-only transport through managed switches. Where the camera's pages offer the choice, set RTSP over TCP; panel widgets handle TCP-interleaved streams most reliably.
• Credentials pasted into the address. The password ends up in the project file in plain text. Use the widget's Username and Password fields.

If you are also choosing the hardware

The widget does not care who built the camera; it needs an RTSP or MJPEG address the panel can reach at the frame rate you want to show. If the feed source is still an open line item, smart cameras attach straight to the machine network, and the camera finder filters them by interface, resolution and shutter.

The MV-SC5060XM-08M-WBN is a 6 MP mono GigE smart camera with an 8 mm M12-mount lens, and the MV-SC3050XC-16M-ATN-H is a 5 MP color sensor with a global shutter on Fast Ethernet.

For fast motion in the widget window, favor the global shutter; for slow or static parts, the higher pixel count buys inspection detail. On the panel side, a vision controller hosts the machine-vision network inside the cell: camera acquisition on one port group, HMI traffic on another, with no extra switch to mount and wire.

The MV-VC2140-128G40-1T carries three to four LAN ports, 8 GB of memory, and a 128 GB SSD plus a 1 TB HDD.

Split the ports so the widget's stream never competes with image acquisition. The same address that feeds the widget also feeds your own code, as acquiring an RTSP stream in your vision program shows.

The sign-off check

Before the station ships, run the list:

• Camera: RTSP enabled, address copied from its own web page, VLC test passed on the machine network.
• Widget: address in the Expression tab, initial value and expression both filled, display format matched to the scheme, credentials in the widget fields.
• Network: one subnet or a route in place, stream on the primary port, bandwidth inside the budget from the worked example above.
• Panel: default camera password changed, project downloaded, picture judged in run mode.

That is the whole fix. The address was always valid; it was just bound where the widget never reads. If you are planning a cell with several streams and want cameras, box and network sized together, run the layout through the build-a-system configurator or reach the team on the contact page. More integration walks like this sit on the systems topic page.