Smart camera to robot TCP data exchange that parses results

The inspection passes on the bench, the string looks right in the camera's emulator, and then the robot sits idle — because the two devices never agreed on who talks first, in what format, and for how long. This guide fixes that hand-off for a self-contained smart camera feeding a robot controller over one Ethernet cable, with no PC in the loop. You will pick the server and client roles, define a four-field result string, configure the camera's result output, and build the controller side: one connection at start-up, one line per inspection, a 5-second receive timeout, and a no-part branch that keeps the line moving. Every number is there to be re-derived — the byte counts and the timeout budget show their arithmetic, so you can swap in your own inspection time and takt.

Which side should be the server, the camera or the robot?

Make the camera the TCP server on one fixed port and the robot the client that connects once at start-up: one connection, one result line per inspection, and no re-connects while the line runs.

The camera owns the data and knows the instant a result exists, so it holds the listening socket. The controller side reboots, reloads programs and gets edited far more often than a camera changes state, and a client recovers from all of that with one small routine: check the socket, close it, reconnect. Everything below assumes a camera with onboard inspection tools — the smart cameras in the shop are exactly this class — and one Ethernet run from camera to controller port, direct or through a single small switch.

What goes into the result string?

Send one ASCII line per inspection with four comma-separated fields — pass flag, X in mm, Y in mm, angle in degrees — and end every line with CR LF; the example line below is 21 bytes on the wire.

Fix the field order and the decimals at design time: a parser that expects flag, X, Y, angle with two decimals never needs maintenance. Send one line per trigger, always — a reject still sends its line with flag 0, so silence on the socket can only mean a link or inspection fault, never a bad part. That single rule is what makes the timeout logic later in this guide simple.

How do you configure the camera as the TCP server?

In the camera's flow editor, add the result-output tool — usually named a TCP/IP write, socket send or send-results tool — set server mode on an unused port such as 5000, build the comma-delimited string, and place the tool after the inspection decision.

1. Give the camera a static IP on the same subnet as the controller port — example: camera 192.168.10.20, mask 255.255.255.0, controller port 192.168.10.2.
2. Add the result-output tool and set it to server mode; pick a port no other service uses — 5000 works, and any free port above 1024 does too.
3. Map the four fields into one string with comma delimiters and fixed two-decimal formatting.
4. Switch on the CR LF line terminator so the receiver can read to end-of-line.
5. Place the tool last in the flow, after the final verdict, so it fires exactly once per inspection.
6. Prove it before robot day: from a laptop on the same subnet, open a raw TCP terminal such as PuTTY in raw mode to the camera's IP and port, trigger the camera, and confirm exactly one line per trigger.

The camera side needs nothing more than those onboard tools and the Ethernet result-output feature; all three of these run the inspection and serve the string on their own:

How does the robot connect and read each line?

At program start the controller creates one client socket and connects to the camera's address — 192.168.10.20, port 5000 in these examples — then each cycle it triggers the camera and waits on a single receive call that returns after one line or after 5 seconds.

1. Declare the client socket once, at program start, not inside the pick loop.
2. Connect to the camera's IP and result port, and log the success so a wiring change shows up immediately.
3. Set the receive to read until CR LF — socket libraries offer read-to-terminator or fixed-length reads, and read-to-terminator matches the string above.
4. Set the receive timeout to your budget; the worked example below lands on 5 s.
5. In the loop: trigger, receive one line, parse, pick, repeat — and never close the socket between cycles.

In plain terms the client side reads:

client := new client socket
connect client to 192.168.10.20 : 5000     // example address
loop each cycle:
    trigger the camera                      // your existing trigger path
    line := receive client, until CR LF, wait up to 5.0 s
    if line is empty:
        no-part branch: retry once, then alarm
    else:
        flag, x_mm, y_mm, angle_deg := split(line, ",")
        if flag = 1 then pick at x_mm, y_mm, angle_deg

Budget the timeout from your own measurements, with two bounds:

Measure t_answer on the bench, trigger to complete line; a one-tool inspection typically answers in 0.2-0.5 s. Take t_answer = 0.4 s, a takt of 6 s, and a fault branch of 0.5 s:

• Lower bound: T ≥ 10 × 0.4 s = 4.0 s
• Upper bound: T ≤ 6 s − 0.5 s = 5.5 s
• Choose T = 5 s: 5 ÷ 0.4 = 12.5 answer periods of headroom, and the worst case of 5 s wait plus 0.5 s fault branch still fits the 6 s takt with 0.5 s to spare.

With a tighter 3 s takt the same bounds give 4.0 s ≤ T ≤ 2.5 s, which is impossible — the fix is a faster answer (0.2 s drops the lower bound to 2.0 s) or a receive that runs in parallel with the return move, not a longer timeout. The wait is one call per frame, the pattern behind when a frame never arrives within its timeout; if the robot moves while the next inspection runs, budget the whole loop with the image-based control latency breakdown.

How do you parse the string on the robot controller?

Split the line on the commas, check the pass flag first, then convert the three number fields; a well-formed line has exactly four fields, and anything else is a corrupt frame that gets the same treatment as a timeout.

1. Strip the CR LF terminator.
2. Split on the comma and count the items: four, or treat the line as corrupt.
3. Convert fields 2 to 4 to real numbers in mm and degrees — they are text until you convert them.
4. Branch on field 1 before touching the coordinates: 0 means reject or no-read, so no motion.

The parse costs well under a millisecond against a 0.4 s answer, so guard it rather than optimize it. When one frame later has to carry more results, the same split grows with the string — splitting one socket string into several vision results shows the multi-field version. The mm and degrees are camera-frame numbers; turning them into the robot's frames is the calibration job covered by converting a camera point between robot work objects.

What should the robot do when no result arrives?

Run the no-part branch, retry the trigger once, and if the second 5-second receive also returns empty, stop or reject with an alarm: two missed answers in a row is a broken link or a broken inspection, not a missing part.

This is why the camera answers on every trigger, rejects included. A single timeout then points at part presentation — shifted, absent, or late — and the retry usually clears it. Two misses point at infrastructure: cable, switch, camera power, or a flow that stopped sending. Each miss costs one 5-second wait, so the alarm fires 10 s after the first trigger; if 10 s of stall is too long for the line upstream of you, alarm on the first miss and let the operator reset instead. The no-part branch itself — signal, skip, log, resume — is laid out in handling the vision no-part error on the robot.

How do you keep the link healthy across thousands of cycles?

Check the socket at cycle start and reconnect there when the controller reports it closed — TCP holds a connection with no traffic limit, so the drops you will actually see follow a camera power cycle, a switch reboot or a controller program reload, all of which happen between cycles.

Opening and closing per cycle is the mistake to avoid: the handshake adds delay to every pick, and some stacks leave half-closed sockets behind after an abnormal exit. A healthy pattern is one connect at start-up, a state check each cycle, at most one reconnect attempt per cycle, and an alarm when the reconnect also fails. When a link that worked yesterday answers nothing today, work the failure in order — cable and link lights, camera IP, port, then the flow — as the robot socket no-response checklist walks through.

Does the same pattern work for code readers and OCR?

Yes — a fixed code reader serves the same TCP pattern and sends the decoded string per trigger, so the robot parses it with the same split-and-convert logic; only the field meanings change, from X and Y to lot code and part number.

For picks driven by a barcode, a reader with a 12 mm lens covers codes on small parts at close range and ships the decode over the same socket:

The reader is one of the fixed code readers that speak this one-line-per-trigger protocol, and wiring a barcode reader as a TCP server covers the server side in detail. OCR follows the identical path — the inspection sends the read string instead of coordinates, as sending OCR strings over TCP from a smart camera details — and splitting barcode strings into fields handles the parse when one decode carries several values. When the client is a PLC rather than a robot, the string and the parsing logic carry over unchanged; a TCP setup walkthrough for a PLC client shows the controller side of that variant.

When is a smart camera the right choice instead of a PC-based set-up?

One inspection, one robot decision, no image archive: the smart camera alone is the right choice, and the TCP string is your entire interface. Add a PC when several cameras feed one decision or when you must store images — the PC then sends the coordinates, over the same one-line-per-inspection pattern.

That PC-based variant is exactly what sending camera part coordinates to a robot controller over TCP documents, so the protocol you built above survives the upgrade. If the results belong in a historian rather than in the robot's hand, reading smart camera results over OPC UA is the cleaner transport and needs no parser on the controller at all.

To shortlist the camera, filter the camera finder by interface and resolution, or start the configurator at the camera step:

Send us your string format and your takt and we will check the timeout budget with you before you order. The rest of the integration set — trigger wiring, calibration, cycle planning — lives on the systems topic page.