Vision camera to PLC over Ethernet: ASCII strings, no serial port

The customer's spec reads simply: a camera verifies the serial number printed on the part, and the expected string arrives at your PLC from another PLC over Ethernet. The reflex is to add a serial cable, because ASCII instructions look like serial-port tools. They are not the only way. A vision camera can push its read or verify result as an ASCII line over a raw TCP socket, and the PLC buffers those bytes into a string file exactly as it would a serial message. This guide covers both ends: the camera output format, the PLC receive buffer, the character compare, the timing arithmetic, and the handshake details that decide whether commissioning takes a morning or a week.

The short answer: a raw TCP socket replaces the serial port

If the camera offers a raw TCP or UDP output mode and the PLC has a free socket channel, the serial port stays out of the design. The camera formats its result as one ASCII line and sends it to an IP address and port you choose; the PLC's socket or mailbox service receives the bytes, moves them into a string file, and the compare logic runs unchanged. Only the transport differs from the serial case.

This is the standard pattern for vision-to-PLC results on processors without a fieldbus option. For the barcode case on the same principle, barcode reader to PLC over raw TCP sockets is the companion guide; this article stays with the vision case, where the payload is a verify verdict or an OCR string rather than a decode.

An SLC 5/05-class Ethernet processor on one end and a vision camera on the other is the classic pairing for this question. If that is your hardware, a step-by-step Ethernet ASCII setup walkthrough for that pairing covers both ends; the rest of this guide keeps the technique generic. The systems topic page collects the PLC-side companions.

What to set up on the camera

Four settings, all in the camera's communication or output configuration:

1. Output mode. Raw TCP with the camera as client: it connects to the PLC's IP and port and writes each result line. Client mode survives a PLC power cycle, because the camera re-dials the next time it has a result to send.
2. Output format. One line per read: the string, any grade or no-read flag, a delimiter, then a terminator such as CR or LF. Decide the terminator now and parse for it on the PLC; a mismatched terminator is the top cause of doubled or missing messages.
3. No-read behavior. Emit a fixed line such as 'NG' when the mark fails, so the PLC receives exactly one message per part in every case.
4. Trigger echo. If the PLC triggers the read, have the camera acknowledge on the same socket before it starts, so the PLC can time out against a silent camera.

The reverse direction — the PLC as master — is triggering a smart camera over TCP with ASCII commands. Which fields go into the line comes from the scene's output variables, and reading smart camera scene result variables shows how they map.

Readers that fit the pattern:

The LS-CRD-0028 decodes the code and streams the result as a line over Fast Ethernet, with an 8 mm lens on a 5 MP global-shutter sensor. The MV-SC3050XC-16M-ATN-H is the verify case: a 5 MP color vision sensor, global shutter, 1/1.45-inch sensor in an M12 barrel. Where reading volume grows, the MV-IDS006M-12C-C moves up to a GigE port with a 6 MP sensor.

What the PLC side looks like

The PLC needs three things: a listening socket, a string file, and a handler with discipline.

1. A socket or mailbox channel on a free port above 1024 — 2222 works; write it into both programs.
2. A string file to land the bytes. In SLC 500 documentation, files 9 to 255 can be typed as String; other platforms call the same thing a STRING data block.
3. A handler with four steps: clear the receive buffer before each expected message (the ASCII clear-buffer instruction, ACL in the SLC 500 instruction set), arm a receive timeout, move the bytes into the string file on completion, then set a done bit for the rest of the ladder.

Receive instructions fire once per arm, not once per scan. That execute-once behavior is what trips serial ASCII programs — ARL and AWA retriggering explains it — and the same discipline keeps a socket handler from swallowing the second message. The buffer keeps whatever the camera leaves behind, terminator included: ASCII data framing in the PLC receive buffer covers the nulls, leftovers and races that fabricate reads, and storing ASCII barcode strings in PLC memory shows the clear-and-fill pattern. Strip the terminator before any compare.

Worked example: a 21-byte serial-number line over Fast Ethernet

Inputs. The job is a serial number of letters and digits; take 20 characters as the plate format and substitute your own length. The camera appends one CR, so the payload is 21 bytes. The link is Fast Ethernet at 100 Mbit/s; the LS-CRD-0028 and the readers above carry that interface class. TCP adds a 20-byte IP header and a 20-byte TCP header.

Rule. On-wire time is frame bits divided by link rate. One frame carries the preamble and start delimiter (8 bytes), MAC header (14), IP header (20), TCP header (20), the payload (21), the FCS (4) and the interframe gap (12).

Result. The line occupies the wire for 7.92 µs. Everything else is slower: image processing in the camera, then one or two PLC scans while the socket handler serves the string. Call it tens of milliseconds end to end on a small ladder.

Decision. This station may hold the part for seconds, so speed is not the constraint — but set the threshold anyway. If the per-result budget were 50 ms, the serial alternative at 9,600 baud spends 21.9 ms of it on line time alone (21 bytes × 10 bits ÷ 9,600 bits/s = 21.9 ms), which is 44 percent of the budget before any scan delay. Ethernet spends 7.92 µs, about 0.02 percent. Choose Ethernet; the serial port stays free for a printer or a panel device.

TCP, UDP or the serial fallback

UDP saves nothing at this message size and gives up delivery guarantees, so it is the wrong carrier for a verdict. Serial remains the honest fallback: wiring a barcode scanner RS-232 string to a PLC serial port is the same pipeline with a different cable, and on a processor with no Ethernet port at all, SLC 5/03 serial port ASCII configuration covers the port setup.

Comparing the read string with the expected serial number

First decide where the compare runs. A camera job holds one fixed expected string, so on unique serial numbers the camera cannot do the verification — teach part one and part two fails. The camera returns the characters it read; the PLC compares. Only when the print is identical on every part does camera-side verification make sense, with the PLC receiving just a pass flag; OCR verify mode against an expected string covers that setup.

On the PLC the compare is two steps:

1. Length check. A wrong-length read fails immediately, which catches truncated frames before a character compare wastes a scan.
2. Character compare. With the terminator stripped, compare each position or use the platform's string-equal instruction.

The expected string needs a source: a peer-to-peer message between the Ethernet processors (the MSG instruction in SLC 500 terms), an HMI entry, or a lookup table indexed by part type. Verifying scanned barcodes against a PLC lookup table shows the table pattern, and ladder logic that compares barcode strings and counts reads works the compare out rung by rung.

OCR reads what is printed, so normalize once: force both strings to the same case at storage, and treat leading zeros as data rather than noise.

Handshake rules that keep the station running

• One line per part, always — the no-read line guarantees it.
• Clear the receive buffer on the trigger edge, never after the read, so a late message from the previous part cannot pose as this one.
• Arm a receive timeout and define the fail state. On a station that allows seconds per part, one second of silence means reject and move on.
• Let the camera own the TCP connection as client. After a power cycle the socket is gone, and a client camera re-dials on its next result. If the camera must be the server, put reconnect logic on the PLC side and add a heartbeat, so a dead link shows up in seconds rather than at the next shift.

Choosing the hardware

Three device classes cover the job. The smart cameras, fixed code readers and vision controllers category pages sort them, and the camera finder filters by interface, resolution and mount.

• Fixed code reader when the serial number is already a DataMatrix or barcode and the task is decode-and-send: the shortest path to a string.
• Vision sensor or smart camera when the mark is human-readable print to verify — the OCV case — or the check needs templates and tolerances.
• Vision controller when several cameras feed one PLC message, or when lighting channels and multi-camera logic belong in one box:

The MV-VC3301H-128G66 carries 5+ LAN ports and 4 built-in light channels on an Intel Core i3 with 8 GB of memory, and includes the VM6200Pro runtime license, so camera links, lighting control and the PLC message share one box.

Checks before you commit

• The camera firmware offers raw TCP or UDP output, not only a proprietary protocol.
• The PLC has a free socket channel, and its port number is written into both programs.
• The string file or STRING data block is sized for the longest possible line plus margin.
• The terminator is agreed, parsed and stripped; the parser tolerates CR, LF or both.
• The no-read output is defined, and the PLC counts exactly one message per part.
• The expected-string source is decided: peer message, HMI entry or lookup table.
• A receive timeout is armed with a defined fail state.
• Trial runs use the worst print on the line, not a fresh sample — that exercises the no-read path on day one.

When this approach is the wrong one

• Per-part handshake faster than a few parts per second: raw sockets add scan-latency jitter. Use discrete trigger and result lines for the handshake and keep the string on Ethernet, or pick a reader with a fieldbus option.
• More than two or three cameras, or checks that need heavier processing: a vision controller owns the cameras and sends the PLC one consolidated message.
• No free socket channel and none can be freed: the serial fallback from the table above, at 21.9 ms of line time per 21-byte line at 9,600 baud.
• A plant standard that demands tag-based protocols such as EtherNet/IP: then the camera needs that protocol option and the raw socket gives way. On processors without the option, raw TCP is exactly what makes the integration possible.

Shortlist the device class first, then let the configurator narrow mount, resolution and lighting in one pass. If the string format, the compare logic or the handshake needs a second opinion, the contact page reaches the applications team.