Smart camera data logging to the network: three paths and the math

The inspection runs, the camera sorts good parts from bad, and quality asks where the data lives. The awkward answer is: on the camera. A log destination set to the device's local drive means the camera's own storage, not your PC and not a mapped network drive. This guide is for anyone wiring smart cameras or vision sensors into plant data systems. It gives the working paths off the device, the storage fill-time and transfer-time arithmetic that picks between them, and a worked example at one part per second you can rescale to your own takt.

Where the files actually land

When an inspection targets a camera and logs to its local drive, files accumulate in that device's flash storage. The development PC you configure from keeps nothing; it only hosts the editor, and every save location the camera offers is on the camera. The desktop-style interface makes this easy to forget: the interface is remote, and the target device does the logging.

Camera storage is shared real estate. The same space holds the deployed inspection program and its settings, so image logs and result files compete with the program for room. See how smart camera program storage and offline editing fit together before planning a large on-device archive. Logs that only grow are a failure mode of their own, so diagnosing and bounding camera log storage belongs in the design, not the punch list.

No mapped network drive appears among the destinations. Standalone vision devices speak a short list of protocols, file transfer and raw TCP above all, and the architecture has to be built from that list. Everything below is a way to combine them.

Three paths off the camera, and when each wins

Three paths, four configurations: the file path simply runs in two directions. If the host needs only pass/fail, measurements and coordinates, stop at path 1 and log nothing on the camera. If the host also needs pixels, the pull-versus-push choice is set by how fast files must reach the host and how fast the camera fills. When rates or retention outgrow path 2, a vision controller in the cell owns the disk instead.

Paths 2 and 3 ride the camera's Ethernet link, so the interface is the first spec to check. A 100 Mb/s Fast Ethernet link is 12.5 MB/s of line rate, and sustained file transfer lands near 10 MB/s once protocol overhead is paid; a 1 Gb/s link is 125 MB/s of line rate and lands near 100 MB/s. The three vision sensors below cover both speeds:

Values as printed in each product's data sheet; open a part for its drawing and full specifications.

The numbers: fill time, transfer time, and the one-third rule

Two formulas size the whole problem:

S_free is free space on the camera in MB, s_part is the logged size per part in MB, R is the part rate in parts per second, S_logged is what has piled up since the last pull in MB, and T_link is sustained link throughput in MB/s. Fill time says how long local logging survives; move time says how long each transfer takes.

Turn fill time into a schedule with the one-third rule: pull at most every third of the fill time. A 37-hour fill tolerates a per-shift pull with room to spare; a 7.4-hour fill demands a pull every 2.5 hours or less. When no practical interval clears the rule, the camera cannot be the archive, so push the files or delegate the storage instead.

Path 1: push results as they are generated

A result message is small. A line like OK,12.4315,0.0203 followed by carriage return and line feed is 20 bytes; even a verbose 100-byte message at five parts per second is 500 bytes per second, or 4 kb/s, a rounding error next to a 100 Mb/s link. Bandwidth is never why results fail to arrive; connection handling is.

Decide who opens the connection. A camera acting as a TCP client reconnects to your host after a network blip; a camera acting as a listener waits for connections and is simpler to firewall. The TCP client or listener decision works the same for a vision sensor as for any network device. Give every message the part counter, and know what the device does with unsent results when the host is down: retry loops that end in a device hang after days are a known pattern, and network failure recovery shows both the failure and the fix.

Serial and discrete I/O still earn their place: a pass/fail lamp or a PLC input needs no network at all. The moment you want measurements, timestamps or traceability, move to TCP. For robot guidance the same path carries coordinates, as in sending camera part coordinates to a robot controller over TCP; if results must pair with images, asynchronous result and frame matching with timestamps keeps that join honest.

Any Ethernet vision sensor holds this connection. The MV-SCB007EC-12S-WBN is a 1.6 MP color sensor with a 12 mm manual-focus lens; point its TCP client at your collector and leave the device storage empty.

Path 2: move image files, pulled or pushed

Both directions ride the same Ethernet link and the same fill-time math. What differs is who initiates the transfer and how fresh the host copy is.

Pulled: FTP into the camera on a schedule

The camera runs a file-transfer service of its own. From a host you connect, list the logged folder, download what you need, and delete what you have taken to free space. The camera keeps logging at full takt while the pull runs on your side, which makes this the standard answer for batch review, customer claims and building training sets. Schedule pulls by the one-third rule, and learn what a full device does on your model: some stop logging, some overwrite the oldest file, and both look like missing evidence weeks later.

If the actual goal is only showing the current image at the station, skip file logging entirely. What a smart camera image actually displays in a PLC HMI covers that live path.

An integrated-lens camera leaves only the storage budget to design. The LS-SMC-0063 pairs a 16 mm lens with a GigE interface, so log on the device, pull each shift, and the architecture is done.

Pushed: the camera uploads to your FTP server

Run an FTP server on the machine that owns the archive, give the camera its own account and folder, and point the inspection's upload step at it. Files land on the host within seconds of each cycle and camera storage stays near-empty. At the worked example's 0.03 MB per part, five parts per second is 1.2 Mb/s of sustained upload, comfortable on a dedicated 100 Mb/s cell link and tight only if that line also carries backups or office traffic. If the cell shares its link, measure first: diagnosing machine-vision network congestion lists the symptoms and the tests. Keep camera traffic on the production VLAN and script a retention job on the server, because an upload folder that only grows is a scheduled outage.

A GigE camera leaves the most headroom here. The MV-SC5060XM-08M-WBN pairs a 6 MP mono sensor with an 8 mm lens on a GigE interface, so full-resolution frames upload well inside the cycle gap.

Path 3: let a vision controller own the storage

When images are the product, meaning every part logged, months of retention, or several cameras in one cell, stop squeezing archives into sensors. A vision controller is a compact computer with camera ports, built-in light channels and PC-class storage; cameras stream to it and it writes to its own disk. Results keep flowing exactly as in path 1, and the controller simply becomes the host that also keeps the pixels.

Storage sizing stops being the constraint. At 864 MB per shift, a 1 TB drive holds about 1,150 shifts, over four years of single-shift production. The MV-VC2140-128G40-1T splits the job that way: a 1 TB HDD for archives beside a 128 GB SSD for results and runtime, plus 4 built-in light channels, so the cell's illumination wiring lands in the same enclosure.

Pick the controller tier by camera count and analysis load, not by disk size. The standalone machine vision controller selection guide walks LAN-port counts, light-channel counts and processor tiers for exactly this choice.

Cuts that shrink the data 10-100×

• Log defects, not everything. At a 1 % defect rate, defects-only logging cuts 864 MB per shift to 8.6 MB, a 100× reduction. Adding one good part in 100 as a control roughly doubles it, still near 50× less.
• Compress. The 640 × 480 mono frame is 0.31 MB raw and about 0.03 MB as JPEG at 10:1. When every image must be kept, this is the biggest single lever.
• Crop. A 320 × 240 ROI holds a quarter of the pixels, so the JPEG shrinks to roughly 7.5 kB, four times more history in the same space.
• Set retention per stream. Results are bytes; keep them for years. Images answer claims and feed retraining, so 30 to 90 days covers both, and a rolling delete keeps the disk honest.

Checks before you commit

1. Measure one real logged file on the bench and read its size in bytes; every schedule here scales from that number.
2. Read the device's communications list, covering FTP server, FTP client, TCP client and serial, because it decides which paths exist on your camera before you design around one.
3. Compute fill time from your takt and the measured file size, then set pulls at a third of it.
4. Fix the naming scheme now: part counter and timestamp in both the file name and the result message, so the host joins them with one query.
5. Set retention per stream and script the deletes; an archive without a delete job is a fill-time countdown.
6. Run one pull and one upload during live production, at production rates; bench numbers flatter every link.
7. Put camera traffic on its own VLAN, or the day someone copies a job folder across the cell link becomes a latency mystery.

When the usual answer is wrong

• Logging everything locally and cleaning up later fails above about one shift of fill time: the archive dies mid-shift, silently.
• Uploading every image for traceability fails on tight takt over a shared link; retries inside the cycle cost more than any disk.
• Buying a controller for results alone fails the cost test, because results are bytes and path 1 moves them for free.
• Expecting a mapped network drive fails on any standalone device; plan file transfer and TCP from the first drawing, because the drive icon on your PC is not a protocol the camera speaks.

The decision, case by case: results only, push them over TCP and log nothing; images at about one part per second, log locally and pull every shift; images at five parts per second, flip to FTP push or a controller; several cameras or months of retention, a vision controller owns the disk. Filter the camera finder by interface, then assemble camera, controller, trigger and lights in the system configurator. More integration reading sits on the systems topic page, and the applications team answers architecture questions through the contact page.