Access camera images from a PC: APIs instead of the robot filesystem

You mounted the camera on the robot and told it to capture at every waypoint, and now the frames sit in storage your PC application cannot reach through any documented API. The fix is to stop treating the robot controller as an image server. Industrial cameras already serve their frames over their own interfaces: GigE Vision and GenICam on the network, the vendor SDK on a smart camera, RTSP when you only need to watch. This guide shows how to pull those images straight into your PC code, how to size the transfer with real arithmetic, and how to verify the loop before the robot runs a production cycle.

Why is the robot controller's filesystem the wrong image source?

Because it is a copy of a copy: the camera stores the frame, the controller keeps its own snapshot, and your PC then scrapes files with no documented format, no trigger tie-in and no way to know the image matches the waypoint the robot was passing.

A file copy also carries none of the metadata your code needs: no trigger timestamp from the camera, no waypoint index, no link to an inspection verdict. When the camera's own tool updates, its storage location and file format can move without notice, and a scraper breaks silently.

The camera's documented job is to capture, process and hand results across the network to a master computer. Use that path and the interface contract lives with the camera, not with wherever a tool happens to drop files this week. The network route is documented step by step in Connect a GenICam camera to an industrial controller over Ethernet.

Which interface brings camera images into your PC?

GigE Vision with GenICam for area scan and smart cameras on a network, the vendor SDK's result interface for on-device inspection, RTSP for monitoring. One 1 MP monochrome 8-bit frame is 8 Mbit, about 9 ms of wire time on a Gigabit link at an effective 940 Mbit/s.

Take the uncompressed stream whenever your code measures anything; an area scan camera on GigE Vision gives your software every pixel, plus exposure, ROI and trigger control. The GigE Vision capture-and-save walkthrough shows that path end to end, and the interface reliability comparison covers when USB3 Vision or CoaXPress beat GigE on a fixed bench. RTSP keeps a role for remote viewing; see acquiring an RTSP stream from an IP camera.

How do you pull frames over GigE Vision and GenICam?

Five steps: put the camera and a PC network port on their own subnet, enumerate the device, set the pixel format to Mono8, acquire into reused buffers, then process each frame as it lands. The loop then runs at the camera's frame rate, not the filesystem's.

1. Give the camera its own link. A dedicated network port on the PC, or a dedicated VLAN, with camera and port on one private subnet such as 192.168.10.x keeps frame traffic off the factory network.
2. Fix the camera's address with a static IP in that subnet so enumeration is deterministic after every power cycle.
3. Enumerate the device through your GenICam library's discovery call. The camera answers with model, MAC and IP; if nothing answers, check subnet and link speed first.
4. Configure before the first grab: pixel format Mono8 on a mono sensor, a fixed exposure instead of auto, and a packet size the whole path carries. Exposure changes go through the GenICam API as in setting camera exposure time through a GenICam API in Python; if a write fails, another client probably holds the camera, which is the case in GenICam node not writable.
5. Acquire into a ring of reused buffers rather than a new image per frame, the pattern in reuse image buffers instead of per-frame allocation, so the loop holds frame rate.
6. Write each frame with its waypoint index and timestamp in one record, so any image traces to the position that triggered it.

When does the smart camera's own SDK beat a raw stream?

When the inspection runs on the camera anyway. A smart camera processes on the device and returns results plus images to the master computer, so your PC receives a few kilobytes of verdict data instead of megabyte frames at every waypoint.

A vision sensor integrates lens, light and processing, runs inspection on the device, and reports verdicts over Ethernet. Both wire time and the code you maintain shrink, because the PC consumes decisions instead of pixels. Browse the smart camera category to see how far that integration goes.

The MV-SC5060XM-08M-WBN is a 6 MP mono smart camera with an M12 lens mount and a GigE interface.

A full 6 MP Mono8 frame is 6 MB, about 51 ms of wire time at 940 Mbit/s; a pass/fail record with coordinates is typically under a kilobyte. When the decision can run at the camera, running it there is cheaper on every cycle.

How much bandwidth does a per-waypoint transfer really need?

Far less than a Gigabit link gives you. At an effective 940 Mbit/s, wire time runs about 8.5 ms per 1 MP Mono8 frame, 102 ms per 12 MP frame and 170 ms per 20 MP frame, so any of them fits inside a 1-2 s waypoint cycle.

Assume uncompressed 8-bit mono frames on a clean point-to-point Gigabit link, which carries an effective 940 Mbit/s once GigE Vision protocol overhead is paid. Wire time is frame bits divided by that rate:

Wire time excludes exposure and sensor readout; a 100 ms exposure plus a 30 ms readout puts about 130 ms on the clock before the first byte moves. Budget each waypoint as exposure + readout + wire time + processing. With a 2 s cycle and 1.6 s of robot motion, a 12 MP grab at about 232 ms total fits the 0.4 s window; three cameras firing on one link share that window, and their wire times add.

Color changes the arithmetic only through bytes per pixel: an 8-bit Bayer frame moves like mono, a 24-bit RGB frame triples it. Pixels are the other lever, and an ROI or binning shrinks the frame, as the binning and readout comparison shows.

The MV-CS200-10GC outputs 20 MP color frames over GigE with a C-mount lens mount.

When pixels cannot be shrunk, link speed is the lever. The MV-CH250-25TC-F-NF moves 25 MP frames over 10GigE with a global shutter and an F-mount.

On a 10GigE link the same arithmetic divides wire time by roughly ten, so the 20 MP Mono8 frame lands in about 17 ms instead of 170 ms.

What breaks when the camera shares the network with everything else?

Mostly bandwidth contention and packet-size mismatches. A GigE Vision camera pushing 100 Mbit/s of frames across a switch that also carries robot traffic can stall both; and if the link negotiates down from 1 Gbit/s, oversized packets get dropped and acquisition errors follow.

Three fixes cover most sites. Give the camera a dedicated port or VLAN so other traffic never queues ahead of frames. Match the packet size to the link end to end. Confirm the negotiated speed is 1 Gbit/s full duplex before blaming software. When a link does drop below gigabit, a camera configured for large packets can throw acquisition errors instead of quietly slowing down, which is the failure in GigE camera packet size error.

How do you trigger a frame at each waypoint?

Trigger the camera from the robot's digital output, not from the PC. The robot fires an output as it settles at the waypoint, the camera starts exposure on that edge, and the PC collects the finished frame over the network when it is ready.

Hardware triggering removes tens of milliseconds of variable latency that a PC round trip injects into a moving cell. Wiring levels and pull-ups are covered in wire a GPIO output to a camera trigger input. Software triggering stays fine at a bench. And when a pick consumes a stored result from the previous part, you get the failure in vision result stale every cycle: trigger a fresh capture per waypoint and consume that frame, not the oldest one in the buffer.

How do you verify the loop before the robot runs?

With the robot parked. Enumerate, set exposure and pixel format, grab frames from a fixed target, and check four things: every grab succeeds, timestamps advance, measured wire time matches the arithmetic, and the saved image matches what the lens actually sees.

• Confirm the network port and camera both report 1 Gbit/s, full duplex.
• Grab 100 frames from a static target: zero timeouts, strictly increasing timestamps.
• Measure trigger edge to image on disk and compare with exposure + readout + wire time; expect agreement within a few tens of milliseconds.
• Inspect the image itself: focus, exposure histogram and the full field of view the application needs. A perfectly timed frame can still be useless.
• Repeat the count over a full shift, because a loop that survives 100 grabs can still drift when temperature moves focus or a switch renegotiates.

Which hardware should sit on the PC side?

A fanless vision controller with multiple Ethernet ports: one port per camera subnet, a separate port for the factory network, and the headroom to buffer frames between waypoints. Four or more built-in light channels also let it drive the illumination without an external controller.

Anything your code runs on can receive frames; the question is whether it keeps up at cycle rate. The MV-VC2140-128G40-1T pairs 3-4 LAN ports and 2 USB 3 ports with four built-in light channels and an Intel N-series processor.

Pick cameras first by pixels and interface, then let the camera finder and the vision controller category narrow the field, or start at the system configurator. If measuring at the PC versus inspecting at the camera is still open, AI vs rule-based smart camera inspection settles it by task. More integration patterns sit on the systems topic page.