IP camera snapshot URL on an HMI: refresh rates and setup

An IP camera that serves a single JPEG over HTTP is the quickest way to put a live view of a cell, a tank level or a door on an HMI page. There is no stream to license and no extra software to install: a URL, a timer and an image gadget. The trade-off is refresh rate, because a polled snapshot is not a video feed and never behaves like one. You will find the deciding numbers here — update interval, image age, bandwidth per camera — and the point at which a snapshot view stops being enough and a vision sensor has to take the job over.

How fast can an HMI update an IP camera snapshot?

Plan on about two updates per second: most HMI image gadgets poll the snapshot URL on a timer with a 0.5 s minimum interval, so 2 frames per second is the practical ceiling, and platforms that refresh on a scan cycle can sit several seconds behind.

The gadget reserves a frame on the page and re-requests the JPEG at the configured interval; between requests you are looking at a still. At the floor setting every frame is between 0 and half a second old, with an average age of about 250 ms. Some integration platforms go slower by design, because they treat the camera as a scanned image source with a default interval around 10 s — check that setting before blaming the camera.

Two consequences follow. An image gadget will not play a stream: for motion, the choices are a separate video widget or a link out to the camera's own page, as set out in displaying an RTSP camera stream in an HMI. The monitor may redraw 60 times a second while the content changes twice, so the smoothness you see belongs to the screen, not to new frames; monitor refresh rates and frametime, 60 Hz to 360 Hz explains that difference.

If your platform drives the image from a tag that holds the URL, the tag's own scan rate stacks on top of the gadget interval; refreshing camera images in an HMI from a tag-based URL walks through that pattern. For the broader choice between a polled still and a true live view, snapshots versus streams in an HMI runtime sets out when each is the right call.

What makes a snapshot URL work on an HMI gadget?

The camera needs one property, a plain HTTP GET that returns a single JPEG: open the URL in any browser on the plant network, and if one still picture appears, the HMI gadget will pull that same file on its timer and nothing more is required.

Each camera family documents its own snapshot path and its own query parameters for resolution or channel, so take the path from the camera's manual and prove it in the browser first; grabbing images from an IP camera over an HTTP snapshot URL shows how to find and test it. Many cameras accept the username and password inside the URL string. If yours does, create a read-only account for the gadget and keep that account reachable only from the plant network.

Setup is then short:

1. Confirm the URL returns one still JPEG in a browser.
2. Place the URL in the gadget's image source.
3. Set the refresh interval to the gadget's floor, or slower where the view does not need it.
4. If the HMI page is published to remote users, enable the proxy option so the camera is fetched server-side.

How much network bandwidth does snapshot polling cost?

Budget about 0.8 Mbit/s per camera at the floor interval of 500 ms: a 640×480 JPEG is typically 30–60 KB, and at two polls per second even a 60 KB file stays under 1 Mbit/s — small per camera, but it multiplies quickly across cameras and shifts.

Worked example, arithmetic shown. Take a mid-size 50 KB JPEG at the floor interval:

• Bandwidth: 50 KB × 2 polls/s = 100 KB/s, then × 8 bits = 800 kbit/s.
• Data per 8-hour shift: 100 KB/s × 3,600 s × 8 h = 2,880,000 KB ≈ 2.9 GB per camera per shift.

Resolution is the lever. A 1920×1080 JPEG runs four to six times the VGA size, roughly 200–300 KB, which at 2 polls per second lands at 3.2–4.8 Mbit/s. That is still modest on a switched gigabit network, but it buys nothing when the gadget tile shows a quarter of the screen anyway.

Will a 2 fps snapshot keep up with my process?

Compare travel per refresh with the positioning you care about: multiply line speed by the refresh interval, and if the product moves further than the feature you are checking between frames, the snapshot view cannot time, sequence or verify anything on that line.

At a 300 mm/s conveyor, one refresh covers 300 mm/s × 0.5 s = 150 mm of travel. A 40 mm part moves nearly four of its own widths between consecutive frames, and the frame on screen is up to one interval old — at that line speed, up to 150 mm of position error. So use the snapshot for questions whose answer changes slower than about a second: is the hopper full, is the lamp on, is the door closed, how long is the queue. Hand anything the controller must react to within the interval to a triggered camera.

When is an HMI snapshot camera the wrong tool?

Any result that drives an action — a reject pusher, a dimension, a robot pick — needs a machine-vision camera, because a snapshot gives you no trigger, no known capture instant and no controlled exposure, only a JPEG that happened to be ready when the HMI asked.

Each missing piece fails in a specific way. No external trigger means the exposure lands anywhere in the product's travel, so motion smear is uncontrolled. Auto exposure and auto white balance drift between frames, which a measurement cannot tolerate. JPEG compression softens the edges a gauging tool needs. The 0–500 ms age uncertainty makes the image useless for sequencing a reject. Plan the check before buying hardware: planning vision inspection error rates for the worst case puts numbers on the risk, and single camera inspection routing to a robot and reject pusher shows the hardware that carries the result.

What should I pick instead when the line also needs pass/fail?

Fit a vision sensor or smart camera and let the HMI display the result instead of the image: these devices run the inspection on board and hand the PLC a pass/fail over digital I/O or Ethernet in milliseconds, while the operator watches a result bit rather than a picture.

The split works because raw image flow is heavy. A 1.6 MP mono frame is about 1.6 MB before compression, so 60 frames per second is roughly 96 MB/s, close to 770 Mbit/s — most of a gigabit link. Processing on the device and returning one bit per part is what makes inspection practical at line rate. What actually displays when a smart camera image lands in a PLC HMI covers the direct camera-to-HMI case.

The LS-SMC-0063 is a 1.6 MP smart camera rated at 60 fps, with a 16 mm lens and white light. Sixty frames per second is thirty times the snapshot ceiling, and the inspection runs on the device. Three devices that cover the common range:

All 3 share: Max. frame rate 60 fps; Ingress protection IP65. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

For a single check — present or absent, full or empty — a compact vision sensor does the job:

Where several cameras feed one decision, a vision controller runs the inspections and passes one result set to the PLC:

The MV-VC2140-128G40-1T lists 3-4 LAN ports, 2 USB 3 ports, 4 built-in light channels and 8 GB of memory, so camera ports, light control and PLC communication sit in one box. Pick 0.3–1.6 MP sensors for presence, level and label checks, and step up to 5–6 MP only when a small feature must fill more of the frame.

How do I show the camera without exposing it to the internet?

Keep the camera on the plant LAN and let the HMI fetch it: with the proxy option on, the HMI server polls the camera locally and re-serves each JPEG over the same HTTPS connection (TCP 443) as the rest of the pages, so the camera needs no port forwarding.

That leaves one published endpoint, the HMI, and keeps the snapshot URL — credentials included — off the internet entirely. Leave the camera's administration page unpublished too, because a proven URL needs nothing from it. When someone needs direct access for setup or service, a VPN into the plant network is the cleaner path; adding a remote subnet route for smart camera access over VPN covers the routing.

What else limits the refresh rate besides the gadget setting?

The camera itself is usually the second limit: many surveillance-style cameras build a new JPEG no faster than a few hundred milliseconds and throttle simultaneous snapshot connections, so five screens polling one URL can stall to a frozen frame even with the gadget set at the floor interval.

Diagnose in order. Pull the URL in two browser tabs and refresh both; if the image updates slower than the gadget setting, the camera's snapshot engine is the limit. Stagger screens one or two seconds apart so their requests never land together. Put the camera on a wired drop, because Wi-Fi shows up as jitter and missed polls rather than a slow steady rate. If a display freezes instead of lagging, you are in connection-limit territory; IP camera snapshot stops loading: refresh and connection limits walks that failure to a fix.

Which one should I use for my line?

Watch, don't inspect: if the operator only needs to see state, an IP camera snapshot at the floor interval costs under 1 Mbit/s and works well; the moment a result must drive a reject, a measurement or a robot move, put a vision sensor or a vision controller on the job.

• Operator awareness — level, lamp, door, queue: snapshot URL, interval at the gadget floor or slower, JPEG sized to the tile, proxy on when the page is published. About 0.8–1 Mbit/s per camera.
• Pass/fail on a moving line — a vision sensor or smart camera from the camera finder, triggered, returning a result bit to the PLC.
• Several cameras, measurement or robot guidance — GigE cameras into one of the vision controllers, returning one consolidated result set.

If the call is inspection, the system configurator walks camera, lens and controller in a few steps, or bring the part and the line speed to the contact page and we will size it with you. The rest of the networking and display set-up guides sit on the systems topic page.