Connect to a vision camera over TCP: client vs server setup

The fix is a one-line assignment: set the camera's result output to TCP server on a fixed port — port 5000 in the worked example below — leave its peer address field blank, and dial 192.168.11.5:5000 from the test tool as the client on an address in the same subnet, 255.255.255.0 mask. When the ping passes but the connect still fails, the two ends have been handed conflicting roles, or the PC's firewall is silently dropping the inbound dial. This guide fixes both in one bench session. You will assign exactly one server and one client, check the subnet arithmetic by hand, open one TCP port in the firewall, and read the camera's first ASCII result string in a generic TCP terminal tool. It is written for anyone bench-testing a smart camera, vision sensor or code reader before its results move on to a PLC or a robot.

One server, one client: the rule behind most failures

A TCP connection is a socket pair. One end listens for incoming connections — the server — and the other dials out to an address and port — the client. The server never dials, so its peer or destination address field stays blank. The client carries the server's IP address and port. Set those two fields in conflict on either end and the connect fails no matter how good the addresses are.

The bench default is the first row: the camera listens on a fixed port and the tool dials in. That is also how most controller integrations run — barcode reader as TCP server, with the PLC as the client shows the same assignment on a line. Reverse the roles only when the camera's firmware can only dial out, or when one fixed collector must receive strings from several cameras.

What you need

• A camera with an Ethernet result output: smart cameras and fixed code readers both carry one.
• A laptop with a generic TCP terminal tool that offers both client and listen modes.
• A switch, or a direct cable; modern Ethernet ports negotiate the pairing themselves.
• The camera's configuration utility, open on its network and result-output pages.
• Two addresses on one subnet, fixed by hand.

Almost any current model supports this workflow. A 5 MP color vision sensor like the MV-SC3050XC-16M-ATN-H brings Fast Ethernet for exactly this job, and so does the compact MV-ID3013PM-12M-WBN code reader.

Step 1: put both addresses on one subnet

1. Give the camera a static address inside your bench range, in its network settings; a DHCP lease can change between sessions and move the target under your feet.
2. Set the laptop's adapter to a static address in the same range, or keep DHCP if a bench router hands out stable leases.
3. Use the same subnet mask at both ends — 255.255.255.0 on a small bench.
4. Leave the gateway field empty unless a router separates the two subnets.
5. Dial by IP address rather than host name: embedded cameras rarely carry a DNS entry, and the IP takes name resolution out of the problem.

The only arithmetic in this step is one AND operation per device, done in full in the worked example below.

Step 2: make the camera the server and fix the port

1. Open the result-output page of the camera's configuration utility; vendors name it differently, so look for TCP/IP output, result output or Ethernet output.
2. Choose the server or listen mode.
3. Set the port number. Keep the utility's default, or pick one that nothing else on the bench uses, and write it down — the worked example below uses 5000.
4. Leave the peer or destination address blank. The server waits; it does not dial.
5. Set the output format to ASCII with a CR, LF or CRLF terminator where the format is configurable.
6. Save and restart the camera so the listener comes up on the new port.

If the camera's firmware only dials out, reverse the assignment: the terminal tool switches to its listen mode, and the camera's client mode carries the laptop's IP and the port the tool binds.

Step 3: open the firewall only when the PC listens

Direction decides. When the laptop's tool dials out to a camera server, the connection opens from inside the PC and the firewall passes the reply traffic back, so an inbound rule is normally unnecessary. When the camera dials in to a listening tool, that inbound connection is precisely what a default Windows firewall drops, and the fix is one scoped rule:

1. Create an inbound rule allowing TCP on the chosen port — 5000 in the example — scoped to the bench subnet.
2. Bind the terminal tool's listen mode to that same port.
3. Point the camera's client mode at the laptop's IP and port.
4. Retest. If you switched the firewall off wholesale while testing, switch it back on and keep only the scoped rule.

Port discipline carries straight into production; vision controller to PLC: TCP ports and firewall rules covers the same checks for a controller that initiates connections.

Worked example: camera server on 192.168.11.5, laptop client on 192.168.11.50

The inputs, and where each comes from:

• Camera: a vision sensor set static to 192.168.11.5, mask 255.255.255.0 — the address is an example input, typed in its network settings.
• Laptop: 192.168.11.50 with the same mask — the bench laptop; the /24 mask is the common small-bench default, assumed here.
• Camera channel: TCP server on port 5000 — an example port; the camera's output page prints the real default.
• Result format: one ASCII line per read, ending CR/LF.

The rule, in words: two hosts talk directly only when their (IP AND mask) results match, and the connection needs exactly one listener, whom the client dials by IP and port.

The arithmetic:

Both sides land on network 192.168.11.0, so they talk with no gateway. The network address .0 and the broadcast address .255 stay reserved, which leaves usable hosts from 192.168.11.1 to 192.168.11.254; both devices fit with room for a PLC later. The failure case falls out of the same two lines: a laptop at 192.168.1.50 lands on network 192.168.1.0, which is a different network, and with no gateway in between the dial has no route. Sharing the first octets — "the same range" — proves nothing; the masked result is what counts.

The result is one socket pair: the laptop's tool dials 192.168.11.5:5000 from an arbitrary local port, the camera's listener accepts, and every triggered read appends one ASCII line to the session.

The decision, read off what the tool displays:

• "Connection refused", almost immediately: something answered and declined — the camera is not listening on 5000, or a firewall rejected the attempt actively. Check the camera's server mode and port first.
• Silence until the tool's timeout expires, often 10–30 s by default: packets are being dropped on the way — a mask mismatch, the wrong IP, or the missing inbound rule when the PC is the listener. Re-run the two AND lines, then check the rule.
• Connected, but nothing arrives: the link is fine and the output is not firing. Trigger a read, or check the camera's output condition.

Step 4: connect, trigger a read, read the string

1. In the tool, choose client mode and enter the camera's IP and port; connect.
2. Fire one read — a soft trigger from the utility, or an ASCII command on the same link, as in trigger a smart camera over TCP with ASCII commands.
3. Watch the result line arrive and note its terminator. Two reads glued into one line, or one line split in two, means the CR/LF settings disagree; smart camera OCR string output over TCP shows the camera side of that setting.
4. Log a hundred triggered reads before wiring in the PLC or robot: a bench session that loses one read in twenty will cost a day on the line.

Code readers behave identically. The LS-CRD-0028 pairs a 2560 x 2048 sensor reading 30 fps with a result channel rated 60 codes/s over Fast Ethernet, and its strings arrive through exactly the socket pair built above.

For larger fields of view, a GigE smart camera such as MV-SC5060XM-08M-WBN runs the same workflow over a wider pipe.

When it still will not connect

Work down the list; each test takes seconds.

1. Roles. Read each end's mode field aloud. Both listening, or both dialing, fails silently every time.
2. Port mismatch. The camera's output port and the tool's target port must be the same number; read both from the screens, not from memory.
3. Subnet math. Re-run the AND operation on both addresses. Sharing the first octets is not sharing a network.
4. Firewall. If the PC side listens, confirm the inbound rule exists and is enabled; if the PC side dials, look elsewhere first.
5. The channel is taken. Many cameras hold one client per result channel; close the vendor tool or the other terminal session and retry. The same one-client rule governs the streaming path — see connect a camera only when subscribed to free the GigE link.
6. A VPN or managed switch in the path. A route that passes the browser may still drop your port; access a smart camera over VPN: add a remote subnet route works the routing fix.

From test tool to the real system

The socket pair you just proved is the one the controller will use. Point the PLC or robot client at the camera's IP and port, keep the ASCII format and terminator identical at both ends, and send pass/fail strings rather than images. These guides pick up from that exact point: send string data from a vision system to a robot over TCP, vision camera to PLC over Ethernet with ASCII strings and read smart camera data from a VB.NET TCP client safely.

For the bench itself, the camera finder filters by interface and resolution, the systems topic page gathers the networking guides, and the contact page is the way to reach us about a link that still refuses.