Receiving vision data in RAPID over TCP sockets: how it works

Two instruction families show up in robot programs that talk to cameras, and the difference decides how you commission the cell. The Cam-prefixed instructions belong to a controller maker's integrated-vision option and only address that maker's own camera line. SocketCreate, SocketSend, SocketReceive and SocketClose are general socket messaging: they talk to any vision system that runs a TCP server, whatever the badge on the front. This page walks the socket path end to end — the request line and its CR LF terminator, parsing the reply into X, Y and angle with the arithmetic shown, the timeout that matches the vision cycle, and the failure modes that appear after a week of production. You finish able to read an inherited vision routine, say which interface it uses, and connect a new cell to either one.

How does a RAPID program receive data over a TCP socket?

It creates a client socket, connects it to the vision system's IP address and port, sends an ASCII command line that ends with the bytes \0d\0a, and reads the reply into a string variable with SocketReceive — four instructions on one connection.

Socket messaging splits the work between a server and a client. The vision system listens; its communication settings hold the IP address and the port, just like any network service. The robot is the client: SocketCreate makes the socket, the connect step points it at the camera's address and port, SocketSend \Str:= transmits a command string, SocketReceive \Str:=stReceived \Time:=2 waits up to 2 seconds for the reply, and SocketClose ends the session. ComChannel and stReceived are the programmer's own names for a socket variable and a string variable, and stReceived is cleared before every cycle so a previous result can never be read twice.

One request, one reply, one string — that is the whole interface. Socket messaging is a controller option in its own right, ordered with the robot rather than added later; the vision-side requirement is simply a TCP server with a command set written in its manual.

Why do some programs use CamGetResult instead of SocketReceive?

The Cam-prefixed instructions — CamReqImage, CamGetResult, CamLoadJob — come with an integrated-vision option that binds the controller to one camera family, while SocketCreate, SocketSend, SocketReceive and SocketClose are general socket messaging that talks to any TCP server.

Integrated vision is a package: robot-side software, calibration handling and job templates, tied to the camera line the controller maker sells for it. The Cam-prefixed calls hide the transport — CamReqImage takes the picture, CamGetResult hands back the result, CamLoadJob switches the job — and the image travels over a link the option manages.

Socket messaging sits one layer lower and is brand-blind. If the vision system runs a TCP server and a command set written in its manual, the controller can drive it — which is why an inherited program that mixes a job-load line, a cell read and a raw results string is driving a third-party camera over a plain socket.

The decision follows directly. Camera and controller from one house, and you want calibration handled for you: take the integrated option. Any other camera, or a mixed fleet: take sockets, and the integrated-versus-third-party-camera options page maps the middle ground. The same request-and-reply pattern works with a PLC as the master; receiving camera data over raw TCP sockets from a PLC walks that side of it.

What should the vision system send back to the robot?

One ASCII line per request is enough: a pass flag, then X and Y offsets in millimetres and a rotation in degrees, separated by commas and terminated with the CR LF bytes — for example 1,12.54,-3.20,0.47 followed by \0d\0a.

The string is whatever the vision job's output stage writes, so the two sides agree a contract and freeze it: field order, units, decimal point, terminator. Write the units into the job name or the contract sheet, because a units mix-up is not a small error: 0.47 read as radians instead of degrees is 0.47 × 57.30 ≈ 27° of gripper rotation. Numbers arrive as text because a TCP socket carries bytes and nothing else — the string is the whole contract.

The example program reads a single value from a single result cell; its read line is the six characters gvB072 plus \0d\0a. A results line that carries every field in one message keeps the exchange to one send and one receive, which is far easier to trace in a log — sending an OCR result string over TCP shows the same contract from the camera's side. Changing recipes is a command too, and the example keeps a commented-out job-load line in the routine; sending the job-load once at startup beats sending it every cycle, which is the pattern in setting a vision sensor to auto-load its job on startup.

How do you parse the reply string into X, Y and angle offsets?

Clear the string, receive the line, check its length with StrLen, split it at the commas, and convert each field to a num with StrToVal — the line 1,12.54,-3.20,0.47 is 18 characters and becomes three offsets in three conversions.

Everything arriving on the socket is bytes, so the numbers travel as text and the length check is the cheapest integrity test you own. Worked example on the line 1,12.54,-3.20,0.47, contracted as pass flag, X in mm, Y in mm, angle in degrees:

• Length: 1 + 1 + 5 + 1 + 5 + 1 + 4 = 18 characters, so StrLen(stReceived) = 18 proves the whole line landed. Anything else is a truncated line or last cycle's leftovers.
• Cuts: the flag sits at character 1, X at characters 3-7, Y at 9-13, the angle at 15-18, with commas at 2, 8 and 14 as separators.
• Conversion: each field goes through StrToVal, which returns TRUE and fills its num when the text is a valid number. The proof: nX = 12.54, nY = -3.20 and nAng = 0.47 after the three calls; a corrupted field returns FALSE and leaves its num at 0, which is exactly the no-vision signal the cell logic needs.

The variables are the programmer's own — ComChannel is a socket variable, stReceived a string, nX, nY and nAng the three num results:

stReceived := "";
nX := 0;
nY := 0;
nAng := 0;
SocketSend ComChannel \Str:="gvB072\0d\0a";
SocketReceive ComChannel \Str:=stReceived \Time:=2;
IF StrLen(stReceived) = 18 THEN
  ! cut the fields at characters 3-7, 9-13 and 15-18
  ! StrToVal fills nX, nY and nAng, returning TRUE for each valid number
ENDIF

On the motion side, the camera-to-robot calibration was done in the vision software, so the routine applies the numbers straight to the taught pick position: add nX and nY in millimetres, and rotate the grip about the tool z-axis by the angle. With nX = 12.54 and nY = -3.20 the gripper lands 12.54 mm along X and 3.20 mm back along Y from the taught point — these are offsets, not absolute coordinates, which is why the stored pick position never changes.

How long should SocketReceive wait for the vision result?

Give the receive a timeout at least twice the vision system's worst-case cycle and start from the example's 2 seconds (\Time:=2) — against a 360 ms vision cycle that setting leaves about 5.6× the expected wait.

The arithmetic: capture 300 ms plus processing 50 ms plus network 10 ms is about 360 ms, and 2000 ÷ 360 ≈ 5.6, so the timeout only bites when something has genuinely failed. The capture, processing and network numbers here are example values — timestamp twenty real cycles and take the worst one.

The 100 ms WaitTime ahead of the read command in the example is a settle delay, separate from the timeout. An empty wait raises a timeout error into the routine's error path, and that path should recreate the socket, retry once, then hand a no-vision flag to the cell logic — never carry last cycle's offsets into a new pick.

If the vision job itself is the slow step, that is a camera-side problem: when acquisition runs faster than processing is the frame-rate gap to close there.

Which vision hardware serves results over TCP?

Two shapes work: a smart camera that runs the job on the device and serves the results string over its Ethernet port, or a vision controller that runs several cameras behind one results connection — the robot never sees the difference.

On the device side, the MV-SC5060XM-08M-WBN is a 6 MP mono smart camera with a GigE interface and an M12 lens mount, and it runs inspection on the device, so the robot's request meets a finished result rather than an image.

A cell with two or more cameras — or one that wants a single address in the robot program — puts a vision controller between the cameras and the robot. The MV-VC3301H-128G66 offers 5+ LAN ports, 4 built-in light channels, 8 GB memory and includes the VM6200Pro license.

The other two sizes in the range cover a compact cell and a PoE-powered multi-camera one:

Choose by port count and power: a smart camera when one fixed view does the job, a 3-4 LAN port controller for a compact two-camera cell, and the PoE model with 5+ LAN ports when the cameras run power over Ethernet and the robot still needs its own port. Filter resolution and interface in the camera finder, and browse the smart cameras and vision controllers categories before committing a port plan.

How does the vision exchange fit into one robot pick cycle?

The routine runs between the move to the camera pose and the move to pick: trigger, wait, receive, parse, apply — with the example numbers it adds about 411 ms to the cycle, and the vision job is three quarters of that.

In milliseconds: trigger send 1, settle delay 100, capture and process 300, reply on the wire 10, parse under 1 — 1 + 100 + 300 + 10 ≈ 411 ms. Those are example values; the real number comes from timestamping the trigger send and the receive in the commissioning log. Even at twice that figure, a 2 s timeout is untouched.

Two trigger patterns exist. Pull — the robot sends the trigger string and waits for the reply, as the example does — is the simplest to debug because the cycle owns the timing. Push — the vision system self-triggers from a photo eye and serves results to whoever asks — suits conveyor work and frees the robot between parts. Sending camera part coordinates to a robot controller over TCP shows the pushed-results pattern, the vision-guided pick cycle end to end places this exchange inside the full grip sequence, and parsing four vision results from one socket string extends the same split-and-convert routine to multi-part frames.

What breaks a vision link that worked at commissioning?

Four faults cause most field failures: a missing CR LF terminator, a timeout shorter than a slow vision cycle, a stale socket after a restart, and a firewall that learned about the camera too late — each has a one-line test.

1. Missing terminator. Many TCP servers read by line and stay silent until the newline arrives. Test: print the sent string on the pendant and confirm it ends \0d\0a. Fix: make the terminator part of every command string.
2. Timeout shorter than the vision cycle. Test: timestamp trigger and reply over 20 cycles and take the worst case. Fix: raise the receive timeout to at least twice that number.
3. Stale socket after a restart. A controller cold start or a camera power cycle kills the connection while the program keeps writing into it. Test: does the first cycle after power-up always fail and later ones pass? Fix: recreate the socket in the error path instead of assuming the line lives forever — the no-response send-loop fix walks that recovery.
4. Firewall between controller and camera. The port that worked on the bench is closed on the plant network. Test: connect from a laptop on the robot's VLAN to the camera's port. Fix: open that exact port; the checks are the same as a vision controller talking to a PLC through TCP ports and firewall rules.

What do you check before go-live?

You are ready when eight agreements hold, each checkable in minutes: one server and one client, matching IP and port, terminator on every request, a frozen format with units, a timeout at twice the worst cycle, cleared strings, an error path that recreates the socket, and a no-vision outcome.

• One server, one client — fixed in the cell documentation. Two masters on one port is the fault that looks like everything else.
• IP and port match on both sides. Read them from the vision software's communication settings, not from memory.
• Every request ends \0d\0a. The terminator is part of the command, not a nicety.
• The format contract is written down. Field order, mm and degrees, decimal point — with one example line both sides can test against.
• Timeout at least 2× the worst vision cycle. The example's 2 s covers most jobs; measure and adjust.
• Strings cleared and length-checked before use. StrLen against the contract length catches truncated lines.
• The error path recreates the socket and retries once, then reports no-vision instead of picking with stale numbers.
• A no-vision path exists in the cell logic. Skip, re-seat or call an operator — never move to the pick position on last cycle's offsets.

When you are sizing the vision side of a new cell, send the drawing through the quote form and we will return a port plan, a string contract and timeout numbers to check against. More integration patterns sit on the systems topic page.