Camera to robot TCP communication setup in simulation

You can build and prove the whole camera-to-robot messaging layer before any hardware arrives: run the vision side and the robot simulator on one PC and let them talk over the loopback address 127.0.0.1. This guide shows where that address goes, which side should listen, which port to pick, and what the result string should carry. You will test the link with a plain TCP listener, convert pixel results into the millimetres a robot actually consumes, and know exactly what changes on the day real hardware replaces the simulator. The method covers two emulators, a smart camera on the bench, or a camera plus a vision controller — the protocol and the discipline stay the same.

Can a vision emulator and a robot simulator talk to each other?

Yes. Two programs on the same PC reach each other through the loopback address 127.0.0.1, which behaves like a private network inside that machine, so a vision emulator and a robot simulator exchange TCP messages exactly as two devices on one switch would.

Both programs are ordinary processes opening sockets, and the loopback interface routes packets between them without ever touching a physical network. Any protocol carried over Ethernet works: a raw TCP socket sending one ASCII line per result, Modbus TCP registers, or the messaging your robot's vision instructions already use. Image transport stays separate — a GigE Vision camera streams frames to its host on channels of its own, so robot results and image data never compete for the same port.

Keep the protocol deliberately dull in simulation: one connection, one request, one line of text. Every hour spent making the simulated link boring is an hour saved at commissioning.

What IP address goes in each side?

Enter 127.0.0.1 on both sides: the robot simulator's communication-device setting binds it to loopback, and the vision system's peer-address field points at the same address, because on one machine every program is reachable at 127.0.0.1.

On the vision side the field is usually called peer address, host or controller address — it names the machine to connect to. On the robot side, the communication-device or vision-device setting names the vision system, and it also takes 127.0.0.1 while both programs share the PC. The name localhost resolves to the same address.

The listening side matters as much as the calling side. A listener bound only to a LAN address refuses connections that arrive over loopback, so during simulation bind it to 127.0.0.1 or to all interfaces. No subnet, gateway or cable is involved — loopback exists even on a PC with no network at all, which is what makes it the right harness for protocol work.

Which side should be the TCP server?

Make the vision system the server and the robot the client. Robot vision instructions typically open one connection, ask for a part position and read a single reply, so a listening vision side matches the flow you will run in production.

Three patterns cover nearly every cell, and this table is the whole decision:

Take the request–reply row unless something forces otherwise: one persistent connection opened at job start, one request per part, one reply. Reconnecting for every part costs milliseconds and adds a second state machine to debug. When the robot consumes the numbers, send camera offsets to a robot over TCP socket messaging shows the message handling on the robot side, and vision controller Modbus communication: a PLC integration guide covers the register route.

What port number should I use?

Use any unused TCP port from 1024 to 49151 — 8500 is a trouble-free example — because ports below 1024 are reserved for system services and often need administrator rights, while the range above 49151 is handed to outgoing connections.

The ranges come from the IANA port registry: 0–1023 well-known, 1024–49151 registered, 49152–65535 ephemeral. The operating system picks ephemeral ports for every outgoing connection, so a listener there gets evicted sooner or later. Inside the registered range, pick a number the simulator does not already open, stay clear of UDP 3956 — the GigE Vision control channel — and of TCP 502 unless the link really speaks Modbus TCP.

One link, one port. If you split trigger and result into two channels, give them two ports and write both into the same configuration block, because the fastest commissioning failure is two sides configured with different numbers.

How do I verify the link before adding vision?

Start a plain TCP listener on 127.0.0.1:8500, connect the vision side to it, and send the exact result string you plan to use; when the listener shows every character intact, the network layer is proven and any later problem is elsewhere.

1. On the development PC, start a plain TCP listener bound to 127.0.0.1 on port 8500 — a socket test utility or a short script of your own, printing every byte it receives.
2. In the vision system's communication settings, set the peer address to 127.0.0.1 and the port to 8500, with the protocol on raw TCP.
3. Send the exact result string you designed, terminator included, and read it on the listener: every character, in order, exactly once.
4. Send it one hundred times in a loop and count arrivals. One hundred clean strings prove the framing, not just the connection.
5. Stop the listener, start the robot simulator listening on 127.0.0.1:8500, and repeat. The simulator's receive log must show the identical string.
6. Only then point the vision side at real images. The network layer is already proven, so every later symptom is optics or processing.

How do I convert pixel results into robot millimetres?

Divide the field of view by the pixels across the sensor, then multiply every pixel offset by that scale before it leaves the vision system. At 300 mm across 3072 px the scale is 0.098 mm per px, so the robot receives millimetres, never pixels.

Work a full example. Suppose a 6 MP-class sensor of 3072 × 2048 px, with the lens placed so the sensor width covers 300 mm. A part sits 180 px right of and 26 px below the taught position:

• ΔX = 180 px × 0.098 mm/px ≈ 17.6 mm
• ΔY = 26 px × 0.098 mm/px ≈ 2.5 mm

Two edge points 150 px apart along the part differ by 2.6 px across it, so the rotation is atan(2.6 / 150) × 180 / π = 1.0°. The line on the wire is 17.6,2.5,1.0 with a carriage-return and line-feed terminator: millimetres and degrees, one decimal, X right, Y down, rotation positive counter-clockwise. Fix that convention in a one-page protocol note before either side is coded.

Budget the cycle while you are here: a 500 µs exposure, 30 ms of camera transfer, 35 ms of processing and under 1 ms of loopback round trip total 66.5 ms — a ceiling of 1000 / 66.5 ≈ 15 results per second. A real LAN adds well under a millisecond, so processing is where to optimise, not the network.

Work the requirement the other way when the camera is still open: a 250 mm part that needs 0.1 mm per px demands at least 250 / 0.1 = 2500 px across the sensor. The camera resolution calculator turns that target into a pixel count, and the lens focal length calculator sizes the optics for the field of view you assumed.

What changes when real hardware replaces the simulator?

Three things change: the addresses, the firewall and the calibration. Loopback becomes a LAN address on both sides, the port needs an inbound firewall rule on the listening machine, and any hand-eye calibration done against the simulator must be redone on the real cell.

Addresses first. When the vision software keeps running on the same PC as the simulator, only the camera address changes: the camera takes its LAN address while the robot link stays on 127.0.0.1. When the vision application moves onto a controller on the bench, both ends go to LAN addresses on one subnet — camera static IP setup: reach a smart camera on the same subnet is the checklist for the camera half of that link.

A PC-based cell is assembled the same way in PC-based robot vision guidance with a GigE Vision camera. Before the swap, read up on the hardware corners: setting up a GigE Vision camera on a real robot controller covers the robot end. When the camera reports to a PC that is not the robot's, connecting a vision camera to a PC without the robot controller covers that layout.

For the standalone cell, a GigE smart camera such as the MV-SC5060XM-08M-WBN holds the inspection and the robot socket in one housing:

On the PC-based route, the camera streams to a host that also owns the robot link, for example the MV-VC3301H-128G66:

Both routes end in a cable, and the bench run is short: the LS-CBL-0199 is a 3 m high-flex GigE cable with screw locks, and the LS-CBL-0117 is a 15 m camera data cable with locking studs:

Calibration is the third change. A hand-eye calibration performed against a simulated robot proves the plumbing, not the geometry: redo it with the real camera, mounting and tool, then prove it with a known offset. When the camera offers no calibration wizard, smart camera hand-eye calibration when no wizard exists walks the manual route.

Before you swap the simulator for a real robot, confirm:

• the listener binds to the address real traffic will arrive on, not loopback only;
• an inbound firewall rule exists for the port on the listening machine;
• both devices sit on one subnet, or a route between subnets exists;
• the result string, terminator and sign convention are written down and dated;
• the pixel-to-millimetre scale has been re-measured on the real optics;
• the hand-eye calibration has been redone and checked with a known offset.

When does the loopback shortcut fail?

Loopback stops working the moment a second machine or a physical camera joins: 127.0.0.1 always means "this machine", never another device, so a real camera cannot sit there and a simulator bound only to loopback refuses connections from other PCs.

• A camera in metal cannot live at 127.0.0.1 — loopback names the local machine only, so the vision software must learn the camera's LAN address before anything else.
• A simulator bound only to loopback refuses remote connections. Bind the listener to all interfaces before a second machine joins, or expect timeouts.
• Discovery protocols that use UDP broadcast stay inside the host. GigE Vision finds cameras that way, so enumerating a real camera needs the physical interface — and a PC with several IPv4 addresses can pick the wrong one, as UDP broadcast discovery failing with multiple IPv4 addresses documents.
• Host firewalls mostly exempt loopback but always filter cross-machine traffic. The port that worked all week in simulation is the one that dies on Monday morning without an inbound rule.

With the link proven, size the rest of the station — camera, lens, light, controller and trigger — in the system configurator, filter smart cameras by interface and resolution, or start from the vision controllers and camera cables categories. If the protocol side needs a second opinion, use the contact page.