Your vision program captures from the camera, the video window on the server PC updates smoothly, and then you enable web access — and the client PC shows every button and readout except the video. The window simply never appears. This guide is for anyone serving a live camera view to operators, supervisors or a second engineer over the network. You will confirm why the window cannot travel, move the live image onto the front panel so it replicates to every client, size the network load with real arithmetic, and pick a server that carries the camera and the clients without strain.
Why does video show on the server PC but not on the remote client?
The video never reaches the client because the capture library draws it into its own operating-system window, outside the application's front panel, and only front-panel controls are replicated, so the client receives an empty panel no matter how well the server PC displays the live image.
The display call does not paint into a control you own. It asks the operating system for a new top-level window and writes each frame straight into it. That window belongs to the desktop session, not to your program's user interface.
A remote client never receives a picture of your screen. It receives the state of the controls that make up the front panel: buttons, sliders, readouts, image displays. Because the video lives in a window the panel does not contain, the replicated panel has no image control to draw. Zero bytes of camera data reach the client, so the empty area is not a rendering fault — there is genuinely nothing to draw.
This is documented behavior, not a defect. The separate window call is a development convenience: it skips the copy into a panel control and saves work at the bench. One trap hides in it: if you developed inside a development environment, the window can belong to that environment's process rather than your built executable, so clients had no path to it under any settings.
What else stops a remote client from showing video?
Ranked by how often each one turns up: the separate video window (the cause above), a server application that is not actually running when the client connects, a wrong address or blocked port, an indicator that was drawn once and never updated, and an empty image buffer.
Work the list top down; each test takes seconds.
- The video sits in its own window — the cause above. Test: does the front panel itself contain an image control? If not, nothing further matters yet.
- The server is not serving. A client connects to a running application whose panel is in memory; if the executable was rebuilt or moved, or its loop stopped, the client shows a stale or empty panel. Test: does any control on the client change? For what shifts when a second client joins a session that already serves one, see remote front panel troubleshooting with two clients.
- Wrong address or a blocked port. The client never reached the server, so it shows nothing at all — not even the buttons. Test: open the panel from a second PC on the same subnet; if the static controls appear, the link is fine.
- The indicator was drawn once and never again. The draw call sits outside the acquisition loop, or the loop errored after frame one. Test: does the image change on the server's own panel?
- The image buffer is empty. The panel is correct but no frame ever arrived: acquisition stopped, a trigger never fired, or the buffer was never initialized. The blank image window troubleshooting guide walks this case, and isolating capture from rendering shows how to prove which half of the pipeline fails.
How do you confirm the missing-window diagnosis in five minutes?
Two checks settle it in about five minutes: close the video window on the server while the application keeps running, and watch whether the client's buttons and indicators still update while its image area stays empty.
Run them in order.
- On the server, close or minimize the pop-up video window while the program keeps running. If the frame counter keeps advancing with the window gone, the window is decoration and the panel never carried the image.
- Have a colleague move a slider on the server while you watch the client. If the slider follows but the image area stays absent, the panel link is healthy and only the drawing is missing.
A third check removes all doubt: drop an empty image indicator onto the panel and restart. The client now shows an empty image box where it showed nothing before. That box is the slot your drawing code has to fill — the transport works, the pixels were simply never put into it.
How do you draw each camera frame into a front-panel indicator?
Draw the frame into an image indicator placed on the front panel itself, inside the same loop that acquires, after resizing it to a fixed display size such as 640 × 480 pixels, and the panel now carries the video to every client.
- Remove the separate window call. Place an image indicator on the front panel, sized to the area clients should see.
- Resize every frame to a fixed display size — 640 × 480 pixels answers pass/fail and location questions — so each update costs the same bytes regardless of what the sensor resolves. The display ROI design guide covers sizing for responsiveness.
- Convert the resized frame into the indicator's format once per update, inside the same loop that acquires, and write it to the indicator.
- Draw after processing, not before, so clients judge the same image the inspection did, with pass or fail graphics already in place; text overlay on a live camera image shows the pattern for drawing results without touching the captured frame.
- Throttle the update if the panel refresh lags: drawing every second or third frame from a 30 fps camera (15 or 10 updates per second) cuts client traffic by a half or two thirds.
- Rebuild and test the deployed executable, not only the development project — front-panel image resources are a known casualty of a build tested solely in development, as covered in why a built application can lose its front panel images.
How much network traffic does a live indicator cost per client?
A 640 × 480 mono indicator updated 15 times per second costs about 4.6 MB/s, or 37 Mbit/s, per client — under 4 percent of a 1,000 Mbit/s port — while the camera's own 4000 × 3000 stream at 30 fps would need 2,880 Mbit/s and never fits one link.
Everything the client receives is the indicator, so a fixed indicator size makes the traffic independent of camera resolution. Three factors set the load: width, height, bytes per pixel, times the update rate.
Worked example, mono 8-bit indicator at 640 × 480, updated 15 times per second:
- bytes per update: 640 × 480 × 1 = 307,200 B ≈ 0.31 MB
- bytes per second: 307,200 × 15 = 4,608,000 B/s ≈ 4.6 MB/s
- link load: 4.6 MB/s × 8 ≈ 37 Mbit/s per client
Color at 3 bytes per pixel triples that to about 111 Mbit/s; drawing every second frame halves it to about 18 Mbit/s; four mono clients together load the port to roughly 148 Mbit/s. All of it sits inside one 1,000 Mbit/s interface with margin.
Now compare the stream you are choosing not to send. The LS-CMR-0166 delivers 4000 × 3000 frames at 30 fps. Sent raw, that is 4,000 × 3,000 = 12,000,000 pixels ≈ 12 MB per frame, so 30 fps makes 360 MB/s ≈ 2,880 Mbit/s — 2.9 times a 1,000 Mbit/s port, before any client's share of the panel. Resizing once on the server, down to the indicator's size, is what keeps every client inside the link.
Where the inspection does not need a large sensor, a smaller camera relieves the server too: the MV-CU020-90GC captures 2.5 MP color frames over GigE. A frame of 2,500,000 pixels is about 2.5 MB at 8 bits, light enough to copy twice — once for processing, once for display — without pinching the server. The memory-side cost of those copies is its own sum: see color camera memory bandwidth on an embedded vision controller.
Both are area scan cameras from the shop's range:
- Sensor format
- 1/1.7"
- Interface
- USB3
- Sensor format
- 1/1.7"
- Lens mount
- C-mount
Which vision controller suits the server side?
Any controller that runs your acquisition and processing will also serve the panel; choose by port count and power: two or more LAN ports so cameras and clients sit on separate interfaces, and PoE camera ports only if the cameras draw power over the cable.
Size the server by its three duties: acquiring, processing, serving the panel. Acquisition wants a network interface of its own; clients deserve another.
The MV-VC2140-128G40-1T covers a single-camera station: an Intel N-series processor, 8 GB of memory, a 128 GB SSD plus a 1 TB HDD, 3-4 LAN ports and 4 built-in light channels.
- LAN ports
- 3-4 LAN ports
- USB 3 ports
- 2 USB 3 ports
- Light outputs
- 4 built-in channels
- Memory
- 8 GB
When clients multiply, interface count matters more: the MV-VC3301H-128G66 runs an Intel Core i3 with 8 GB of memory on 5+ LAN ports, so camera and client networks get separate interfaces, and a vision software license is included. It has no PoE, so power cameras separately if they need it.
- LAN ports
- 5+ LAN ports
- USB 3 ports
- 3-4 USB 3 ports
- Light outputs
- 4 built-in channels
- Memory
- 8 GB
Multi-camera lines belong on the MV-VC5525-256G70-NN, which pairs PoE camera ports and 8 built-in light channels with an Intel Core i5, 32 GB of memory and 5+ LAN ports.
- LAN ports
- 5+ LAN ports
- USB 3 ports
- 3-4 USB 3 ports
- PoE
- PoE camera ports
- Light outputs
- 8 built-in channels
Browse the wider range of vision controllers to compare port counts, memory options and PoE availability side by side, then pick the one that matches your camera and client count.
When is a mirrored panel the wrong answer?
A mirrored panel suits a handful of clients watching a downsized image; full-resolution review, many simultaneous viewers, or mobile operators need a real streaming or replay path, because the panel sends the whole control surface, not a tuned video service.
The mirror carries every open control at the panel's own update pace — exactly right when one to a few people need to see what the station sees, wasteful once the job grows. Change tools when the job changes:
- Full-resolution review or training: keep frames on disk and replay them instead of squeezing them through a panel; recorded video replay for machine vision pipelines shows the pattern.
- A wall display or shop-floor kiosk: a page served by the vision device itself can be lighter than a mirrored panel; compare the vision sensor browser display for local operator viewing.
- Many small views from one sensor: capture cropped regions instead of one big frame; multi ROI camera capture: the frame rate arithmetic shows what each extra view costs.
Decision: up to about four clients watching a 640 × 480 indicator, the mirror wins on simplicity — 148 Mbit/s or less on one port. Beyond that, or whenever full frames must leave the server, move to replay or a streamed page. More display-side fixes sit on the systems topic page.
What should you check before clients go live?
Work through the short list below on the server before the first client connects; each item exists because skipping it has cost someone an afternoon of rework.
Server
- The acquisition loop runs unattended through a full shift with the draw call in place — one stalled draw freezes every client at once.
- A frame counter or timestamp sits on the panel, so the question 'is it live?' has a glanceable answer.
Indicator
- An image indicator on the panel is the only live image; no separate window call remains anywhere in the code.
- The display size is fixed, 640 × 480 as a workable default, keeping bytes per update constant.
- The draw happens after processing, so clients judge what the inspection judged.
Network
- Camera traffic and client traffic run on separate LAN ports.
- Per-client load is budgeted — about 37 Mbit/s mono, 111 Mbit/s color at the worked sizes — against the port's 1,000 Mbit/s.
- Expected client count times per-client load is checked against the port before go-live, not after.
Client
- The deployed executable is tested on the server, not only the development build; front-panel image resources must survive the build.
- One client is connected and checked through a full production cycle before a second joins.
When the list comes back green, connect the first real client and watch one complete cycle. If the server needs sizing or the panel behavior still puzzles you, the team reads every question sent through the contact page.
Questions
Does a remote client slow down the camera's frame rate?
No. The capture loop keeps its own pace, and 30 fps stays 30 fps on the server; the client only mirrors whatever the indicator drew last, at the panel's own update interval. Check the frame counter on the server panel: if it advances at full rate while the client refreshes slowly, the camera link is healthy and the panel update rate is the bottleneck — throttle or resize the indicator, not the acquisition.
Can several clients watch the same front panel at once?
Yes, but each connected client receives its own copy of the panel updates, so outbound traffic grows with the client count. At the worked sizes — 640 × 480 mono at 15 fps — one client costs about 37 Mbit/s, so four clients load the server's client-facing port to roughly 148 Mbit/s. That fits a 1,000 Mbit/s interface with room to spare; past about a dozen clients the load approaches half the port, so plan a dedicated client interface or a streaming server.
How large should the image indicator be?
Size it to the judgment an operator makes, not to the sensor. A 640 × 480 indicator answers pass/fail and location questions; 800 × 600 helps with fine defects, at about 1.6× the mono traffic of the smaller size. Beyond that, keep the full-resolution image on the server and give the client zoomed views or a replay of recorded frames instead of a bigger live indicator.
The client shows a frozen image instead of no image — what differs?
A frozen image means the panel path works and the drawing stopped: the indicator was written once, then the loop exited, stalled, or the draw call sits outside the acquisition loop. Nothing at all means the image was never on the panel. Restart the application on the server and watch the indicator locally; if it updates locally but freezes on the client, lower the update rate and check the server's CPU load.
Does the fix differ between GigE and USB3 cameras?
No — the display layer never sees the interface; it receives finished frames either way. The interface matters to the server plumbing: give the GigE camera a dedicated LAN port with the client traffic on another port, and plug a USB3 camera into a controller with USB3 hosts to spare. The MV-VC3301H-128G66, with 5+ LAN ports and 3-4 USB 3 ports, covers both without an add-in card.