Parse tab-delimited results from a smart camera into pass or fail

A smart camera that inspects on its own processor still has to tell the line what it saw, and the most dependable way is a line of plain text: fields separated by tab characters, a verdict spelled out in ASCII, sent down the TCP connection you already use to trigger it. Opening that socket is its own task, covered in triggering a smart camera over TCP with ASCII commands; this guide starts when the first string arrives. You will fix a field layout, split the line on the tab, compare one field exactly, and hand a pass bit, a fail bit and a valid strobe to the PLC.

What does the camera actually send down the TCP connection?

One line of printable ASCII per inspection: the fields you configured, left to right, separated by a single tab (ASCII 0x09, decimal 9) and terminated with CR LF (0x0D 0x0A), which is why the parser must strip two bytes before comparing anything. You choose the contents and the order on the sensor's export page; on sensors that follow the common layout that is the Data Export tab under System Settings > Communications, and every result you tick there becomes one field, left to right, in the order shown.

Fix the layout before writing any parser code. The one parsed end to end here:

• field 0 — part ID, free text, unique per part
• field 1 — overall verdict, the token PASS or FAIL
• field 2 — the tightest measurement
• field 3 — inspection time, milliseconds

Verdict second is deliberate: field 0 carries a unique ID for the stale-data check later, and the verdict stays clear of the terminator bytes that ride on the last field. One inspection arrives as:

LOT-4471<TAB>PASS<TAB>0.84<TAB>23.7<CR><LF>

Count the bytes: 8 for the lot number, 4 for the verdict, 4 for the measurement, 4 for the time, 3 separators, 2 terminator bytes — 8 + 4 + 4 + 4 + 3 + 2 = 25 bytes:

4C 4F 54 2D 34 34 37 31 09 50 41 53 53 09 30 2E 38 34 09 32 33 2E 37 0D 0A
 L  O  T  -  4  4  7  1 TAB  P  A  S  S TAB  0  .  8  4 TAB  2  3  .  7 CR LF

When the payload is read text rather than a verdict, the sensor side is the same page; smart camera OCR string output over TCP walks that configuration.

How do I split the line into fields?

Split the stripped line on the single byte 0x09 and index left to right from zero: the example line yields four fields, and the verdict lives in field 1 no matter what the other fields contain. Split on that one byte, never on "any whitespace": a part ID containing a space shifts every later index by one, and the parser then reads the measurement as the verdict. Strip before splitting — one trailing 0x0D, one 0x0A, then any trailing spaces the export adds.

Then count. Three separators mean four fields, and the count is a structural check: a line with the wrong count is a communication fault with its own alarm, never a judgement about the part.

Buffer discipline matters more than the split itself. If the host reads late, one read can hold two lines; split the receive buffer on 0x0A first and keep the last complete line. The framing traps are the same in ladder logic — nulls, partial frames, races — and ASCII data framing in the PLC receive buffer works through them. A robot host receiving several results in one socket string runs this split twice, lines then tabs, exactly as parsing four vision results from one socket string on a UR10e shows.

How do I turn a field into a pass/fail boolean?

Compare field 1 as text to the exact token PASS: equal means pass, and everything else — empty, short, misspelt or a line that never arrived — means fail, with a communication alarm attached. The whole decision in one place:

The procedure, once per trigger:

1. Read the socket until 0x0A arrives, with a 500 ms timeout. A small inspection answers trigger-to-string in roughly 10-50 ms, so 500 ms is ten times the worst case; a timeout fails the part with a comm alarm.
2. Strip one trailing 0x0D and 0x0A, then trailing spaces.
3. Split on 0x09 into fields indexed from 0.
4. Require exactly four fields; anything else raises the comm fault and stops the parse.
5. Set pass on the case-sensitive compare of field 1 against the token PASS.
6. Optional plausibility gate: parse field 2 as a decimal and compare numerically — 0.84 mm against a 0.90 mm limit passes with 0.06 mm of margin. Parse first: as text, "9" would sort above "10".
7. Combine: final = pass AND gate. Fail is NOT final, written as its own signal.
8. Write pass, fail and the valid strobe to the controller in one update.

The worked example

final = true AND true, so the pass bit sets, the fail bit clears and the strobe fires.

Gate on the camera's verdict, not on a host-side re-decision from the numbers. The camera owns the tolerances; a host that re-decides duplicates them, and two copies drift apart within a season.

How do I parse it in a LabVIEW host?

With two string operations and one comparison: split into an array on the tab, take index 1, and the output of the string-equality comparison is already the boolean — no separate conversion step exists or is needed. Concretely: the comparison output wires straight to the pass indicator and to the case structure that writes the controller bits. When the export sends the words True and False instead of tokens, compare against the constant True — the equality comparison is the string-to-boolean conversion.

Pace re-reads with a small wait carried on the error chain rather than a sequence structure, so the timing lives in one wire and the diagram stays flat. The wider pattern — connect, trigger, read, use results as data — is laid out in smart camera LabVIEW integration: use inspection results as data; the same parse in a text language appears in reading smart camera data from a VB.NET TCP client safely.

How do I write the booleans to a PLC?

Write three signals, never one: a pass bit, a fail bit and a valid strobe of about 100 ms, because a PLC that scans every 1-10 ms needs the result held for at least ten scans to catch it reliably. Three signals, one update:

• PASS — true only for the part the strobe marks.
• FAIL — its own bit, true for a rejected part or a comm fault.
• VALID — a 100 ms strobe; the PLC latches on its rising edge.

Give the comm fault a separate bit as well, so the line can tell a rejected part from a deaf camera.

The socket exchange end to end is in smart camera to PLC over TCP: trigger and pass/fail, and vision system to PLC: send pass-fail results, not images explains why the images stay on the camera. A result line that lives for one scan vanishes before the logic sees it — the barcode string that disappears after one PLC scan is that failure, latched on the pulse. Counters built from these bits should reset with the batch, as resetting pass/fail counters per batch in a vision inspection script shows.

Why does every compare fail on a fresh set-up?

Almost always it is the carriage return: CR LF termination leaves the last field carrying an invisible 0x0D, and any text compare against a clean token fails on every single part until you strip it. The causes, in the order you meet them:

• Invisible CR on the last field. Print the line in hex and look for 0D before the 0A; the fix is step 2 of the procedure.
• Whitespace split. Send a part ID containing a space; if the verdict index moves, the split is wrong. Split on byte 0x09 only.
• Re-configured export. Someone ticked one more result on the export page. The field-count check catches it; put a layout version in field 3 so the host can name the change.
• Two lines, one read. Trigger twice without reading in between. Split on 0x0A and keep the last complete line.
• Case drift. The export sends Pass while the host compares PASS. Fix it on the sensor page — token uppercase — not with a case-insensitive compare, which hides the drift.
• Stale result. The host parsed the previous part's line. Make field 0 a unique part ID and check what came back against what was sent.

Which camera and host should run this?

Any smart camera whose export page lets you order the fields and spell the verdict token will do; choose the sensor for the inspection, then confirm the host has a LAN port for the camera and one for the PLC. The link speed is irrelevant — a line on this layout is 25 bytes, so even a busy part rate leaves the network idle. Filter the smart cameras range on sensor format, resolution and mount in the camera finder.

Two examples from the shelf:

Three side by side — what differs is on the sensor and the lens, not on the link:

All 3 share: Humidity 20% RH to 95% RH (no condensation); Certification CE, KC. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

When the host is not a line PC, a vision controller runs the parse, the lighting and the PLC handshake in one box; where that work belongs is its own question, answered in smart camera results to an RT controller: how to split the work. One host built for exactly that split:

The vision controllers range carries the same job in several sizes.

What should I check before the first production shift?

Run five known parts — three good, two deliberately bad — and demand five logged lines, the booleans flipping on exactly the wrong two, and a communication alarm the moment you pull the cable mid-cycle. The full list:

• The line ends 0x0D 0x0A, and the parser strips both before any compare.
• Three separators give four fields; a mismatch raises the comm fault, and three consecutive comm faults stop the line.
• The verdict token is uppercase PASS on the sensor page and in the host constant, compared case-sensitively.
• Field 0 carries a unique part ID, and the host checks returned against sent.
• The strobe is 100 ms and the PLC latches on its rising edge, not its level.
• The socket timeout is 500 ms; a timeout fails the part and counts toward the stop threshold.
• After a camera power cycle, the first parsed line is live — its part ID matches the part in front of the lens.

From here, start the system configurator at the camera step and let it carry lens, light and controller from there. More on moving results into control systems sits on the systems topic page, and for a cell bigger than one parser — several cameras, one controller — send the part list through the contact page.