Smart camera LabVIEW integration: use inspection results as data

A smart camera that runs its own inspection does not need LabVIEW to grab frames. It needs LabVIEW to receive verdicts: the pass or fail decision, the measured values and a sequence number leave the camera as data, over TCP or a few digital wires, while the pixels stay on the camera. Get that split right and your LabVIEW program becomes a small, testable receiver instead of an image-processing project.

This how-to is for controls and test engineers wiring a self-running smart camera into a LabVIEW station. It covers the transport decision, the camera-side settings, the TCP calls, a timing example at 60 fps, the digital handshake alternative and the checks that catch dropped or stale results before the station ships.

The decision: results as data, or frames through an SDK

Two roads lead from the camera to LabVIEW, and where the inspection runs picks the road.

If the camera's own configuration environment already inspects your parts correctly, treat the camera as a sensor. It runs the inspection and publishes one result per trigger; LabVIEW connects to that result channel and records or acts on it. Expect each line a few milliseconds after the ready handshake: the camera's processing sets that pace, and the network adds microseconds, as the worked example below shows.

If the algorithm cannot be built on the camera, the roles flip: LabVIEW acquires frames through the vendor SDK and processes them itself. That is the SDK route — calling the camera SDK DLL from LabVIEW — and it brings buffer management and callbacks with it. Choose it only when the camera's environment genuinely cannot express the inspection, because it trades a configuration problem for a software project.

The rest of this guide takes the sensor route.

What you need

• A smart camera or vision sensor whose inspection already passes on known-good parts, configured in its own software; if the station is not built yet, start from the smart cameras range.
• A LabVIEW development PC or runtime target with a free Ethernet port.
• A small switch for the cell network, plus the camera's power and I/O cable with the trigger and output lines broken out to terminals.
• For the digital handshake: a PLC, a DAQ device or a relay board that reads the camera's logic level.
• Written down before you start: the camera's IP address and subnet, the result port you will set, and the exact result line format.

Any networked model works — the transport is identical. A Fast Ethernet vision sensor such as the MV-SCB007EC-12S-WBN covers verdict-plus-value checks on small parts, and a 6 MP GigE smart camera such as the MV-SC5060XM-08M-WBN keeps more pixels on the part when the field grows.

Choose the transport: TCP, serial or digital I/O

Pick the channel by what LabVIEW must do with the result, not by habit.

Default to TCP — it carries everything and costs nothing extra. Add the digital handshake when a machine must react without waiting for your program, and keep serial for cells without a network drop. For switching recipes over serial, the RS232 recipe-selection pattern keeps one command code per recipe, and the same parsing discipline applies.

Configure the camera side

Vendors bury these settings under different menu names, but the five settings themselves are the same, and every one of them lives in the camera's inspection software — none of them happens in LabVIEW.

1. Give the camera a static IP on the station subnet — say 192.168.10.20 for the camera and 192.168.10.5 for the LabVIEW PC — and connect both through the cell switch.
2. Enable the result output over TCP and pick the direction. The usual arrangement is the camera listening on a port you set (5000 serves as the example) with LabVIEW connecting as the client; some cameras can instead connect out to a listener on the PC.
3. Define the result line: one line per inspection, fixed field order, terminated with a newline, and carrying a sequence number that increments on every inspection. That number is your only later proof of a dropped line.
4. Assign the handshake lines if you use them: a result-valid output and a pass output at minimum. Hold them until an acknowledge input releases them, or pulse them well beyond the slowest PLC scan you serve — 50 to 100 ms is a typical pulse for a PLC scanning every 10 ms.
5. Run the inspection in the camera's software over ten known-good and ten known-bad parts and read the raw result text it reports, so you know the exact line LabVIEW must parse.

Read one result per trigger in LabVIEW

The LabVIEW side is four primitives and a loop. The names below are the primitives on LabVIEW's TCP palette (TCP Open Connection, TCP Read, TCP Close Connection and their listener counterparts in the same palette), and the variables in this example take the values set in the camera section: address string 192.168.10.20, port 5000, read timeout 100 ms. The same call sequence works from any language that speaks raw TCP, so the camera-side contract survives a switch of host software.

1. Open the channel. Call TCP Open Connection with the camera's address and the result port, wire an open timeout of 2,000 ms, and keep the returned connection ID in a shift register.
2. Read one line. Inside a While Loop, call TCP Read with that connection ID, set its mode to CRLF so each read returns exactly one newline-terminated line, and wire the 100 ms timeout — the worked example below derives it.
3. Parse the line. Find the verdict token with Match Pattern and pull the measurement out with Scan From String using a format that matches your line — %f for the 812.53 in the example line 1,PASS,812.53.
4. Handle errors. A timeout error means no result arrived this cycle: clear it, increment a consecutive-timeout counter and loop. Any other error means the connection is gone: close, wait one second and reopen. Raise an alarm after ten timeouts in a row.
5. Close cleanly. Stop the loop, call TCP Close Connection, and let the next start reopen.

If the camera connects out to the PC instead, swap step 1: TCP Create Listener and TCP Wait On Listener accept the camera's connection, and the read loop stays unchanged.

Prove the parse before trusting it: run ten good then ten bad parts. The verdict must flip exactly at the part change, and the sequence number must step by one per read with no repeats and no gaps.

Worked example: timing a 100 ms read timeout at 60 fps on Fast Ethernet

The case: a station inspecting one part per trigger at the camera's full rate — the LS-SMC-0063 over GigE runs 60 fps, so the result stream can deliver one line per inspection.

Inputs, and where each comes from:

• Inspection rate: 60 fps — the camera's frame rate above.
• Link rate: 100 Mbit/s — the line rate of a Fast Ethernet port, which most smart cameras and vision sensors carry.
• Result line: 1,PASS,812.53 plus a newline = 13 + 1 = 14 bytes, in the format configured earlier.
• Message overhead: about 78 bytes per line — Ethernet header, preamble and inter-frame gap, plus IP and TCP headers.
• Margin rule: set the read timeout to five times the longest expected gap between lines.

Arithmetic:

• Worst-case gap between lines: 1 / 60 s = 16.7 ms.
• Bytes on the wire per line: 14 + 78 = 92, so 92 × 8 = 736 bits.
• Wire time per line: 736 bits / 100,000,000 bit/s = 7.4 µs.
• Link load: 7.4 µs inside a 16.7 ms cycle = 0.044 % of the cycle.
• Timeout: 5 × 16.7 ms = 83.5 ms, so set 100 ms — a six-fold margin.

Result: the network moves each line in about 7 µs and idles for the rest of the cycle. The line lands a few milliseconds after the ready handshake, with the camera's inspection time and scheduling setting the pace, not the wire.

Decision, with thresholds:

• Set the TCP Read timeout to 100 ms for this case.
• Use a blocking CRLF read, not fixed-rate polling. A poll must run faster than half the gap — 16.7 / 2 = 8.3 ms — or it can miss lines, and a UI-updated LabVIEW loop does not hold that pace.
• The link is not the constraint: even 1,000 lines per second of 92 bytes loads a 100 Mbit/s port under 1 %. Recompute only if messages grow to kilobytes or rates approach tens of thousands per second.
• If LabVIEW must react in under a millisecond, act on the digital pass bit and keep TCP for the record.

Wire the digital handshake

TCP records; I/O acts. When the verdict must stop a cylinder, fire a rejector or start a diverter without waiting for your program, put the camera's outputs on the machine's inputs.

1. Trigger: wire the part-present sensor or the PLC trigger output to the camera's trigger input, following the camera's I/O specification for sink or source wiring and the pulse width it accepts.
2. Result lines: at minimum a result-valid output and a pass output. Hold them until the machine's acknowledge input releases them, and the handshake becomes immune to scan-time jitter.
3. Timing check: pulse the trigger 100 times and count result-valid pulses with a counter. Fewer than 100 counts means a dropped handshake, not a dropped part. Expect the valid edge a few milliseconds after the ready edge for simple checks, longer for heavy ones — measure your own case.

For wiring and timing conventions when a vision device feeds machine motion, this smart camera to motor integration reference shows the same handshake on real hardware. When the destination is a PLC data table rather than discrete lines, one pattern reads smart camera results into a PLC through its message instruction — the sequencing discipline transfers directly to LabVIEW.

On power-up, let the camera finish loading before the machine starts triggering. If results stay missing right after load, the ready-gate fix is the usual cause.

Prove it works before the station ships

• Verdict flip: ten good parts then ten bad; the parsed verdict flips with the part, never one late.
• Sequence audit: log the sequence field for 500 inspections. Repeats mean duplicated or stale lines; jumps mean the camera produced a line nobody read.
• Cable pull: unplug the Ethernet cable mid-run. You must see timeout errors, never a frozen PASS. Design the recovery once, properly — the network-failure recovery pattern shows what long-running stations need.
• Latency band: timestamp the trigger and the read. The gap should sit in a steady few-millisecond band; a drift toward seconds means retries stacking up.
• Part matching: on a moving line, bind each line to a part with the sequence number and arrival timestamp — the timestamp-matching method handles results that land after the part has moved on.

Common mistakes

• Polling on a timer instead of a blocking read: at 60 results/s the race window is half of 16.7 ms, tighter than most loops keep.
• Termination mismatch: the read mode must expect the terminator the camera actually sends, or reads stall with no error at all.
• A short timeout with no watchdog: at a line stop every read times out and the alarm floods. Alarm on consecutive timeouts, not the first.
• Idle connections dropped by a switch or the camera's stack after quiet periods. Reconnect on any read error — the idle-disconnect pattern applies to any long-lived connection.
• Treating a timeout as a failed part: a timeout says no result arrived, not that the part is bad, and conflating them quietly rejects good production.
• Office network in the loop: routed or firewalled hops between camera and PC block or delay the result port. Keep the link inside the cell subnet.

When the camera-only architecture stops fitting

Stay with results-as-data while the camera's environment can express the inspection and one camera covers the field. Move on when you need synchronized multi-camera inspection, model-heavy classification or archived images: then a PC-class vision controller runs the processing while LabVIEW keeps the same contract — one result line per part over TCP — or takes frames directly through the SDK. Scaling changes who computes the verdict; it does not change the wire format your program reads.

When you are ready to spec the station, start from the smart camera finder, check the result-output features on each model page, and bring the parsing questions to us through the contact page.