Send string data from a vision system to a robot over TCP

An inspection result is only useful once something acts on it, and in most cells that something is a robot. The last metre of the link is deliberately boring: a plain TCP socket carrying one ASCII string per cycle. The vision side listens on a fixed IP address and port; the robot connects as the client and reads. Set that half up well and the same pattern sends barcodes, pose offsets or pass/fail flags to any socket-capable robot controller. This guide covers the vision-side set-up: who listens, what the string looks like, when it is sent, and the bench test that proves the link before the robot is involved. The robot-side half — turning received values into a pose — is a separate walk-through in send camera part coordinates to a robot controller over TCP.

Two roles, one socket

One connection, two roles, decided once. The vision system is the TCP server: it boots first, holds a static address, and listens on a port you choose — 5000 is the customary pick, and any free port above 1024 works. The robot is the client: its program calls a socket_open command with the camera's address and port, then reads in its loop. This split matches how robot programming is built — socket_open, socket_send and socket_read commands exist for exactly this — and how these integrations are documented: the robot acts as the client.

The payload is separate from the transport: the bytes are plain ASCII with no formatting layer, so the string you define in the vision tool's output node arrives byte for byte at the robot's parser. One server port can accept several clients, but keep one client per inspection cell so result ownership stays unambiguous.

What you need

• A vision device with an Ethernet result output — a smart camera or a vision controller; inspection software exposes the TCP/IP output as a communication node in its tool palette.
• Robot programming access, so you can add the socket_open and receive calls to the job.
• One Ethernet switch, or a single cable for a two-device cell; both devices on the same subnet.
• A laptop with a raw TCP terminal for the bench test.
• Two free IP addresses on that subnet and one free port above 1024.

Fix the string contract on paper first

The string is a contract between two programs; write it down before touching software. The rules that keep parsers honest on both sides:

• ASCII only — no binary bytes, no locale digits.
• Fixed field order, comma separators, no spaces inside a field.
• One line per result, terminated by a line feed (LF, hex 0A).
• Numbers carry no units inside the string; units live in the contract.

Two contracts cover most cells. Guidance: X,Y,angle\n with X and Y in millimetres and the angle in degrees — declare the units in writing, because the robot cannot infer them. Barcode: code,grade\n. Values beyond a handful get a count field first, which is the shape some robot readers expect anyway: a socket_read_ascii_float(6)-style command asks for six values and returns [6,0.4,0,0.5,0,-3.14159,0], count first. If your robot reads that way, send numbers only. Packing several results into one line has its own pitfalls, covered in parsing four vision results from one socket string; barcode fields specifically are walked in splitting a barcode string into fields.

Set up the vision side

1. Give the camera a static IP on the cell subnet — for example 192.168.1.10 with mask 255.255.255.0, and 192.168.1.20 for the robot. Sockets dial addresses; DHCP-moved addresses break them.
2. In the inspection software, add the TCP/IP communication node and set it to server mode on your chosen port — 5000 in this example. The node needs three settings: listen address, port, payload template.
3. Build the payload template from the contract: map each tool result to its field, add the comma separators, and end with the line feed. Most output nodes assemble this from tool variables.
4. Set the send event to result-ready — one string per completed inspection, never a timer. A timer sends stale or duplicated data whenever the inspection time varies.
5. If the device offers client filtering or a firewall, allow the robot's address now; a blocked client looks exactly like a cable fault later.

A worked text case — an OCR string served over TCP from a smart camera — is in smart camera OCR string output over TCP.

Set up the robot side

1. Open the socket once, at job start: socket_open(camera_address, 5000). Check the return; a failed open means wrong address, wrong port, or no server running.
2. Trigger the inspection each cycle — a digital output pulse, or a command character sent over the same socket. Both are common; pick one and keep it.
3. Read with a timeout, until the line-feed terminator. Start at 2 s: a 100 ms inspection should never need more, and a too-short timeout shows up as randomly missing results.
4. Parse the line: split on commas (string_split-style), convert each field, and hand the values to your pose or accept logic. The full conversion is worked in reading X, Y, angle and score from a camera over a robot socket.
5. Fail safe: on timeout or a short line, close the socket, reopen once, and request again; if it still fails, fault the cycle. The send-loop failure cases are walked in robot socket communication: no response, fix the send loop.

Worked example: a 12-character barcode string over Fast Ethernet

Inputs, with their sources:

• Payload: a 12-character code, a one-letter grade, one comma and one line feed — the code,grade\n contract; count your own code length and substitute it.
• Link: a Fast Ethernet port, 100,000,000 bit/s — the port class on the majority of vision sensors; GigE runs at 1,000,000,000 bit/s.
• Header budget, fixed by the protocols: 20 bytes TCP plus 20 bytes IPv4 plus 18 bytes Ethernet header and checksum.

The rule in words: wire time equals frame bits divided by link rate, where the frame is the payload plus the protocol headers.

Arithmetic:

payload = 12 + 1 + 1 + 1 = 15 bytes frame = 15 + 20 + 20 + 18 = 73 bytes = 584 bits Fast Ethernet: 584 / 100,000,000 = 5.84 µs on the wire; preamble and inter-frame gap add 20 bytes = 160 bits = 1.6 µs, so call it under 10 µs GigE: 584 / 1,000,000,000 = 0.58 µs, about 0.6 µs

Decision: the network costs single-digit microseconds while the inspection runs tens to hundreds of milliseconds. Shaving bytes buys nothing, so keep code,grade\n readable and send it as built. Spend the tuning effort where the milliseconds are: send on result-ready, and size the robot's receive timeout with margin — 2 s covers even a slow 500 ms inspection four times over.

Verify before the robot connects

1. Laptop first: open a raw TCP client to the camera's address and port, trigger, and read the line. Check the final byte is 0A in a hex view — a missing terminator is the most common string failure.
2. Measure trigger-to-arrival over 20 cycles. The spread should track the inspection time, not the network; jitter in the microseconds means the link is fine.
3. Drill the failures: pull the cable mid-cycle — the robot must fault, not coast on the last string; then send a malformed line — the parser must reject it, not floor the value to zero.

Common mistakes, in the order they occur

• Both ends configured as clients — nothing listens and socket_open fails every cycle. Set the camera as the server.
• Terminator mismatch — one side sends LF, the other waits for CRLF; reads time out while bytes sit in the buffer.
• Send before re-arm — the camera pushes at result-ready while the robot is still busy; the line lands in a buffer nobody reads and the next cycle gets a stale one. Use one request per result if cycles overlap.
• Locale decimals — a comma decimal separator turns 12,5 into two fields. Force dot decimals in the payload template.
• Units inside fields — 12.5 mm breaks a float conversion. Numbers only; units live in the written contract.

When a plain socket is not the right link

Sometimes the string should not go straight to the robot. If a PLC owns the cell logic, send the values to the PLC through a register handshake and let the robot read them from there, or use a fixed-position RS232 telegram when the controller has only serial. When the trigger comes from a PLC handshake, vision format selection timing covers the race conditions. The server pattern is not camera-specific either: a dedicated barcode reader serves a PLC over raw TCP the same way, shown in barcode reader as TCP server.

Choose the vision-side hardware

Match the hardware to the job: one inspection feeding one string runs entirely on a smart camera, with the inspection and its result output on the device and no PC in the link. Two current options:

The LS-SMC-0063 pairs a 1.6 MP sensor with a 16 mm lens and reads at 60 fps, which suits a single code read at close range. The MV-SC5060XM-08M-WBN moves up to a 6 MP mono sensor on GigE with an 8 mm M12 lens, for smaller codes or faster lines.

When several cameras merge, or light channels and I/O need coordinating, a vision controller runs the inspections and serves one socket to the robot.

The MV-VC2140-128G40-1T carries three to four LAN ports and four built-in light channels, so camera traffic and the robot link can sit on separate ports. The MV-SVC2506-16G60-128G separates them by design: four camera GigE ports, one configuration GigE port and one communication GigE port, with 16 GB of memory.

Size the camera to the inspection first; the link follows. Browse the smart cameras and vision controllers pages, or filter by interface and resolution in the camera finder. More integration walk-throughs sit in the applications topic.