Wrist camera full resolution image access from an external PC

You want the wrist camera's full sensor frame — all 5 megapixels — on the PC that runs your vision library, the way a standard camera hands frames to a GigE Vision or USB3 Vision application. The wrist camera was built to inspect inside its own processor and hand the robot a verdict, so its Ethernet services behave differently from a camera you drive directly. This guide gives you the two routes that exist today with their real timing numbers, the arithmetic that decides when each is good enough, and the standard-camera swap — with lens, pixel-scale and exposure numbers worked through — for when the file route cannot keep up with the cycle.

Can you pull a full-resolution image from a wrist camera over Ethernet?

No — not as a live stream. The camera hands external applications a reduced preview over the controller's Ethernet services; the full 5 MP frame leaves the robot only as a saved file that your PC collects over FTP, typically 0.4 to 1 s after the capture.

The camera is an inspection device: it grabs, locates and judges on board, then passes the controller a result. The network services are built around that job — a live preview for setup and monitoring, plus result data for the robot program. The sensor frame itself never leaves the camera live. Two routes do get full-resolution pixels onto your PC, and both move files rather than streams:

• The robot program saves the frame to controller storage, and an FTP client on your PC collects it.
• You replace the wrist camera with a standard area scan camera that streams to your vision PC over GigE or USB3.

The payload is not the obstacle. A 5 MP frame at 4:3 is 2592 × 1944 pixels, so one 8-bit mono copy is 2592 × 1944 × 1 B ≈ 5 MB — small by machine-vision standards. The obstacle is that no interface the camera exposes lets an external application pull those pixels on demand.

How does the save-and-FTP route work in practice?

Three nodes do it: the camera's barcode reading node forces a full-resolution grab, the image saving node writes that latest frame to the robot controller's storage, and an FTP client on your PC downloads the file — your vision library then treats it like any image on disk.

The barcode reading node matters because it makes the camera run its capture pipeline — the same one it uses to read a code — so the frame it holds is full sensor resolution, not the preview. The sequence:

1. Add the barcode reading node to the vision program, even when you need no code read.
2. Follow it with the image saving node, which stores the latest image taken.
3. Run that sequence once per image you need — from the program flow or the pendant.
4. Connect an FTP client from your PC to the controller and download the saved file.
5. Open it in your vision library and process it like any image on disk.

One failure mode to design around: the save node stores the latest image, so a capture that fires while you are still fetching the previous one overwrites it. Pace captures to fetches, or accept the loss.

What does the FTP route cost you in latency and throughput?

Budget about 0.5 to 1.5 s from trigger to processed image: the saved 5 MP frame is roughly 5 MB as 8-bit mono (2592 × 1944 × 1 B), so an FTP fetch takes 0.4 s on a 100 Mbit/s link and 0.04 s on 1 Gbit/s, plus save overhead.

The two transfer numbers, worked through:

• 100 Mbit/s link: 5.0 MB ÷ 12.5 MB/s = 0.4 s per frame.
• 1 Gbit/s link: 5.0 MB ÷ 125 MB/s = 0.04 s per frame.

Add the camera's grab-and-save time and your poll interval on top, and 0.5-1.5 s trigger-to-processed is the honest budget. Two structural costs sit under it. The save node keeps only the latest frame, so captures that land mid-transfer are lost. And FTP is pull-based: the loop never closes faster than poll interval plus transfer. If the image is meant to steer the current pick, the budget fails before the first byte moves — the latency budget for a full vision-guided feedback loop shows where those milliseconds would have to go. The same arithmetic, run for live streams instead of files, is the data-sizing walkthrough for slow full-resolution capture.

Do not expect the controller's real-time data channel to carry pixels instead — that link moves process data, not image payloads. One write-up of an image-over-RTDE attempt ends up back at the file route, which tells you where the boundary sits.

Why is the live network stream only a low-resolution preview?

The camera's vision runs on board, and the Ethernet interfaces it documents expose a reduced live preview — one community-documented socket on port 4242 serves it — plus inspection results, but no API returns the raw 5 MP frame to an external application.

The preview is sized for the pendant screen: alignment, checking what the camera sees, confirming detection. That is why it looks fine in a demo and fails in processing — your library needs sensor-resolution pixels, and the preview does not carry them. The port 4242 live-image socket returns exactly that preview frame.

Interfaces do move between firmware generations, so read the release notes for the camera and vision-program versions in your cell before designing around any of this. As those interfaces stand today, every route into the camera ends in a preview or a saved file — which turns this from a settings problem into an architecture decision.

When is save-and-FTP good enough and when does it break?

Save-and-FTP wins when you need at most one full-resolution image every few seconds — golden samples, audit records, training data, offline tuning — and loses the moment the image must steer the current pick, because 0.5 s of transfer and latest-image-only semantics cannot feed a loop that closes in milliseconds.

The deciding numbers: capture, save and fetch together sustain roughly one image every 1-2 s, so 30 to 60 full-resolution frames per minute is the practical ceiling.

• Cycle of 10 s or longer, one record image per part: fits with margin; the delay is invisible.
• Cycle of 2 s: the fetch competes with the robot and frames start overwriting each other.
• Any cycle where the result must move the robot in the same cycle: does not fit at any cycle time — the loop needs a stream.

Training-data collection is the quiet winner: fifty frames of a new part at one every two seconds is a two-minute job, each at full sensor resolution.

Which hardware delivers full-resolution frames at line rate?

For full-resolution frames at line rate, put a standard GigE or USB3 area scan camera on the wrist and wire it straight into your vision PC or vision controller: the same 12 MP, 4000 × 3000 sensor runs at 9 fps over GigE and 30 fps over USB3.

The arithmetic behind those two rates. An 8-bit frame is 4000 × 3000 × 1 B = 12 MB. GigE moves about 110 MB/s of payload, so one frame takes 12 MB ÷ 110 MB/s ≈ 0.11 s — just under 9 fps. USB3 moves about 360 MB/s at that frame size, which is 30 fps. The catalog prints both rates on one IMX226 sensor:

GigE buys cable reach; USB3 buys frame rate. Both read the sensor line by line — a rolling shutter — exactly right when the robot has stopped at capture and wrong when it has not.

The PC side can be the machine that runs your library today, or a vision controller mounted beside the cell. The compact VC2100 model carries four built-in light channels and three to four LAN ports, so the wrist light, the camera and the PLC network land on one fanless box — and the separate light-ring controller you were about to bolt on disappears into it. The VC2100 model below is that box at its smallest: N97 processor, 8 GB memory, 128 GB SSD plus 1 TB HDD.

If you would rather drop the external PC from the loop entirely, running pick-and-place vision on the controller without an external PC is the other end of the same decision. For the camera end, browse the area scan camera category or filter the camera finder by interface and resolution. The network plumbing specific to a wrist mount — IP setup, image retrieval from your code — is covered in GigE camera on a robot wrist: network setup and image retrieval.

How do you size the lens and exposure for a wrist-mounted replacement?

At a 200 mm working distance, a 12 mm lens on a 1/1.7-type 4000 × 3000 sensor covers about 116 mm, giving 0.03 mm per pixel — a 0.3 ms exposure then keeps blur under one pixel at 100 mm/s wrist speed.

Worked example — 120 mm wide field of view at 200 mm working distance, on the 1/1.7-type format above (nominal 7.4 mm sensor width):

• Magnification: m = 7.4 mm ÷ 120 mm = 0.0617.
• Focal length: f = 200 mm × 0.0617 ÷ (1 + 0.0617) = 11.6 mm — specify a 12 mm lens.
• Field of view at 12 mm: m = 12 mm ÷ (200 mm − 12 mm) = 0.0638, so FOV = 7.4 mm ÷ 0.0638 ≈ 116 mm.
• Pixel scale: 116 mm ÷ 4000 px ≈ 0.03 mm/px, so a 0.2 mm defect spans 6.7 ≈ 7 pixels.
• Exposure: blur = speed × exposure, so 100 mm/s × 0.3 ms = 0.03 mm — one pixel. Hold the exposure at 0.3 ms or shorter.

At 0.3 ms no continuous light holds a usable image, so strobe: a short pulse freezes the wrist and keeps heat off the part. On hardware trigger the pulse period, not the camera, sets your frame rate — the hardware-trigger frame-rate walkthrough runs that timing.

A grab while the wrist still moves needs a global shutter: the MV-CH120-11UC pairs 12 MP with a global shutter on USB3 (IMX304, 1.1-inch format). With the robot stopped at capture, the rolling shutter models above cost nothing in image quality.

Which route and parts do you commit to for your cell?

Commit case by case: keep save-and-FTP for one record image per cycle of 10 s or more; take a GigE wrist camera at 9 fps when the PC needs every frame live; take USB3 at 30 fps, global shutter if you grab on the move, when rate decides.

Checks before you order:

• Measure wrist-to-PC cable reach first. 1000BASE-T runs to 100 m; passive USB3 tops out near 3 m. Beyond that, GigE on the camera or a vision controller beside the cell.
• Decide grab timing before sensor choice: stopped-at-capture takes rolling shutter at the better price; on-the-fly takes global.
• Plan the trigger wire from robot I/O to the camera before the light; the strobe follows it.
• Count light channels: one wrist light takes one channel, and four built-in channels leave room for two side lights.

If the file route covers your cycle, stay put — it costs a node and an FTP script. If the cell needs every frame at line rate, configure the station end to end or ask through the contact page; odd cycles are exactly what that form is for, and the rest of the systems guides cover the plumbing around the camera. When the table above lands you between two routes, run both for one shift — the file route in parallel with a borrowed streaming camera — and let the timestamps tell you which one your cycle actually waits for.