Vision system image logging over FTP to debug picking faults remotely

A double pick you cannot see is a fault you cannot fix, and when the camera and feeder sit 800 miles away, every question costs a phone call and a day of someone's time. Vision system image logging over FTP closes that gap: the camera pushes each result image into PASS and FAIL folders on a server you can open from your desk, with result codes, timestamps and pick counters baked into the file names. This guide walks through the server set-up, the job-side settings, the naming scheme and the storage math. At one 200 KB JPEG per pick on a 2 s cycle, 20,000 picks a day is about 4 GB — small enough that a 1 TB drive holds roughly 250 days of history.

What you need

You need five things, none of them exotic:

• A vision device with an FTP-write step. Nearly every smart camera and PC-based vision platform carries one in its tool list; look for image transfer by FTP. The smart camera to PLC trigger and pass/fail pattern shows the same device class doing its day job.
• An FTP server on a machine you control. An open-source server such as FileZilla Server on a Windows PC at your office works, and so does the same software on a small box in the plant.
• A network path the camera can reach. The clean route is a site-to-site VPN between plant and office. Do not forward raw FTP ports through the plant firewall to the internet; keep the protocol inside the tunnel.
• A dedicated login. One account, its own password, and a home directory that contains nothing but image folders.
• Storage sized for the retention you want. The worked example below gives the numbers.

One variant matters when the plant allows no outbound traffic at all: host the archive in the cabinet. A vision controller with a hard drive runs the server itself, and your desk PC becomes the client that pulls folders over the plant's remote-access link. The pushing NG images to an HMI over FTP variant of the same pipeline targets a screen; this guide targets the debugging archive instead.

On the camera side, pick a sensor fast enough to freeze the bowl at trigger time — global shutter when parts are still moving. A 5 MP sensor resolves individual pockets on a flexible feeder; a 1.6 MP sensor covers larger parts where the whole bowl must sit in one frame.

Set up the FTP server

1. Install the server and create one user for the vision devices. Give it a home directory such as vision-images on a data drive, and disable anonymous login.
2. Build the folder tree: one folder per camera, with PASS, FAIL and TEST subfolders. TEST takes commissioning images while you are still at the bench.
3. Enable the server transfer log. It is your proof of arrival — when a fault review needs an image, the log shows the upload time, the account and the file name.
4. Set passive mode with a defined port range, 50000 to 50100 for instance, and open exactly that range on the host firewall for the camera subnet. Nothing else needs to be reachable.
5. Give the server a stable address on the VPN and sync its clock to the same time source as the PLC. If camera timestamps and robot logs disagree by seconds, correlation work becomes guesswork.

The same folder discipline pays off on PC-based systems — organizing inference output folders per run applies the idea to offline result sets.

Point the vision job at the server

1. Add the FTP image-write step after the inspection has decided, so the file name can carry the result.
2. Enter the server address, port 21, the account and password, and select passive mode.
3. Route by result: PASS images to the PASS folder, FAIL images to the FAIL folder. Most platforms take the remote path as a string you build at run time — that is what the next section uses.
4. Set the transfer to queue and run without blocking. The pick cycle must never wait on the network.
5. Fire a few forced results into TEST and confirm arrivals before you point the job at PASS and FAIL.

Trigger a fresh image every cycle. A result carried over from the previous photograph is a classic double-pick cause — trigger a fresh measurement per pick explains why, and the vision-guided pick-and-place cycle shows where the image sits relative to the grip.

Name files so faults sort themselves

Build each file name from four fields: result, camera ID, timestamp, pick counter. FAIL_CAM1_20260115_084212307_001847.jpg sorts chronologically, survives two cameras writing to one server, and greps cleanly for a shift or a counter range. PASS_CAM1_20260115_084214812_001848.jpg, two seconds later, is the matched good image.

If the PLC or cell controller builds the name instead of the camera, the same scheme works — this guide to dynamic FTP file names from the controller side shows the wiring. Keep the scheme short and stick to letters, digits and underscores; some platforms cap file-name length.

Sizing storage and link speed for a 5 MP camera at 20,000 picks a day

The inputs, with their sources:

• Image size: 200 KB per JPEG. A planning estimate for a 5 MP frame at default compression; textured scenes run 150-300 KB, so 200 KB sits mid-range.
• Pick rate: one image per pick at a 2 s cycle. 20,000 picks equals 40,000 s of running — an 11-hour producing day, the pace of a busy feeder cell.
• Drive: a 128 GB SSD or a 1 TB HDD, the storage classes a cabinet-mounted vision controller carries.
• Link: 100 Mbit/s Fast Ethernet, the interface class of the sensor shown above.

Volume: 20,000 picks × 200 KB = 4,000,000 KB = 4 GB per day. Retention: 128 / 4 = 32 days on the SSD; 1,000 / 4 = 250 days on the 1 TB drive. Link: 200 KB × 8 = 1,600 kbit per image, and 1,600 kbit / 2 s = 800 kbit/s = 0.8 Mbit/s — under 1 percent of a 100 Mbit/s wire, so uploads never touch cycle time. If you later log from many cameras at once, there are ways to speed up FTP image transfer from a vision system; at one camera and 0.8 Mbit/s you do not need them yet.

One format check: stay with JPEG. The same frame as an uncompressed BMP is 2,448 × 2,048 pixels × 3 bytes ≈ 15 MB per image, which turns 4 GB a day into roughly 300 GB and ruins both numbers above.

The decision: log everything for the first week — 7 × 4 GB = 28 GB, which fits the 128 GB SSD beside the operating system — then switch to every FAIL plus every 50th PASS. Sampling PASS at 1 in 50 turns 20,000 images into 400, so 400 × 200 KB = 80,000 KB = 80 MB per day before FAILs. Apply full logging only while the daily volume stays under about a tenth of the drive per month; above that, sample.

Where the archive lives in the cabinet, those drive sizes are literal catalog figures: the MV-VC2140-128G40-1T carries 8 GB of memory, a 128 GB SSD and a 1 TB HDD. On the numbers above, that HDD is the 250-day archive.

Logging from several cameras multiplies the daily volume by the camera count — three cameras at this pace are 12 GB a day — so size drive and sampling per camera, not per cell. A controller with PoE camera ports simplifies the cabinet when the cameras share it: the MV-VC5525-256G70-NN combines an Intel Core i5 processor, PoE camera ports and 8 built-in light channels with 5+ LAN ports and a 256 GB SSD.

Reading the FAIL folder: what a double pick looks like

Open the FAIL folder from the worst shift and sort by time. Four patterns cover most double picks:

• Two parts in one pocket. Parts migrate while the bowl vibrates, and the next image shows a neighbour sitting in the gripped pocket. That is feeder discipline, not vision, and it is why plate picks need Z handled outside the image — the height information that decides whether two parts overlap never appears in a top-down photograph.
• A tilted part. The gripper closes on the part edge and drags its neighbour along. The FAIL image shows the part angled in the pocket, often with a second part half-visible beside it.
• A stale position. The part moved between image and grip. Compare the robot log grip timestamp with the image timestamp; a gap of more than a cycle or two means the pick was aimed at an old photograph.
• A reflection double. One shiny part imaged as two, with both outlines sharing an edge. Polarized or diffuse lighting kills it — the machine vision lighting guides cover the set-ups.

Read PASS as actively as FAIL. The spread of good pick positions tells you how much tolerance the gripper really has, and FAILs at the edge of that spread are the early warning. Keep the per-shift counts honest with resetting pass-fail counters per batch.

Verify the pipeline before you rely on it

1. Force one PASS and one FAIL at the bench; each file should land in its folder within a second.
2. Open the server transfer log and confirm the camera account and the full file name appear — not a partial upload.
3. Check clocks: camera, server and PLC against one time source, drift under a second.
4. Pull the VPN at the bench and run 50 cycles. Uploads should queue while the link is down and flush when it returns, with the robot never pausing.
5. Watch one full shift of disk growth against the estimate — picks × 200 KB. A day landing within 20 percent of 4 GB means the compression guess was right.

Common mistakes

• Forwarding FTP ports to the internet instead of running the VPN. An open server gets found by scanners quickly; the tunnel is the safer default.
• Blocking uploads inside the cycle. A timeout on a dead link becomes a robot pause — queue instead, and cap the queue.
• FAIL-only logging from day one. Without the PASS baseline you cannot tell a marginal pick from a broken one.
• Two cameras, one naming scheme, no camera ID: midnight collisions and overwritten images.
• No server-side transfer log, so no proof an image ever arrived.
• Letting the drive fill. The server refuses, the camera queue grows, and the platform eventually stalls — apply the same bounding discipline as with bounding camera log storage.

Which set-up fits your plant

• Office link allowed, one camera: the camera pushes over the VPN to a server at your desk; no cabinet storage needed beyond the job itself.
• No outbound traffic allowed: a controller hosts the archive in the cabinet — the SSD for weeks, the 1 TB HDD for the 250-day log — and your desk pulls folders on demand.
• Several cameras on one server: a PoE controller in the cabinet, one folder per camera, sampling sized per camera.
• Fault understood: every FAIL plus every 50th PASS, pruned by date.

Browse the smart cameras and vision controllers, or start from the camera finder. More trigger and result-handling guides sit on the systems topic page. If a FAIL folder does not match any pattern above, send a handful of images through the contact page and we will read them with you.