Vision controller to PLC: TCP ports and firewall rules

A vision controller hands finished results to a PLC over ordinary TCP, on the fixed port list its vision software publishes. When the link fails, the symptom is always the same: the address answers a ping, the handshake never arrives, and the line waits on a firewall rule nobody wrote. This guide is for the engineer bringing up that first link or rescuing one during commissioning. You will inventory the ports, decide who connects to whom, write rules scoped to the two devices, bring remote support in through a gateway instead of the site router, and prove every port with a connect test. A worked example plans a four-port link on a single cell subnet.

The link is TCP services, not a special bus

A vision controller is a computer with several Ethernet ports, and its PLC link is a set of TCP services. Each service listens on one port number, speaks one protocol, and moves one kind of data. The port numbers are fixed by the vision software, and the communication chapter of its manual lists them. One layout common to several industrial vision lines looks like this: TCP 8500 carries the command and result strings, TCP 8502 carries recipe and file uploads, and TCP 8503-8504 serve the remote monitor and emulator. Four ports, one service each.

The PLC side has documented numbers of its own. Modbus TCP listens on 502. EtherNet/IP uses TCP 44818 for explicit messaging and UDP 2222 for implicit I/O. A device web console on TCP 80 or 443 belongs to laptop setup; keep it off the control path. The whole network plan reduces to one sentence: permit the exact service ports between the exact two addresses, on every firewall in the path.

Why ping is not the test

Ping is ICMP, a different protocol from TCP. A successful ping proves the address responds at the IP layer; it says nothing about whether a TCP service accepts a connection. A firewall in the path drops the first packet of the TCP handshake silently, so the route looks alive while the port is dead. The same trap catches camera discovery, which rides on subnet broadcasts; we cover that case in why GenICam discovery uses subnet broadcast and in the GigE Vision firewall fault where ping works but discovery fails.

The reliable test is a TCP connect attempt to one exact port, made from the device that will run the link. Success answers within a few milliseconds on a switched cell network. A timeout means a rule or a route is missing. An active refusal means the port is reachable but nothing is listening on it.

Decide who connects to whom

Every TCP link has one listener and one initiator, chosen per connection. The firewall opens inbound traffic on the listener side only, and a stateful firewall already permits the replies of an established connection. One inbound rule per listening service is therefore the complete requirement.

Most lines make the PLC the client: it polls the vision controller for the result of the last part, every inbound rule sits on the controller side, and the PLC interface needs nothing. Flip the roles when the controller must push the moment a part clears the fixture; that is the same pattern as sending camera part coordinates to a robot controller over TCP. The roles apply identically to code readers, and the TCP client or listener walkthrough covers the detail of each side.

Set the link up in eight steps

1. List every conversation. Write one row per link: initiator, listener, data, and rate. A controller-to-PLC line typically carries polled results, recipe upload from a laptop, and remote monitoring for the integrator.
2. Fill in the port table from the manuals. For each row record the port or range, TCP or UDP, the listener address, and the permitted source. The numbers come from the vision software's communication chapter and the PLC manual. For a raw-socket link you define yourself, take a port from 49152-65535, the range reserved for private use, so you never collide with a registered service.
3. Fix the addresses. Static IPs on the controller and the PLC, one subnet per cell, recorded with mask and gateway. The worked example below uses 192.168.10.0/24.
4. Mark client and listener on each row. The inbound rule always lands on the listener side.
5. Write scoped rules. Allow the protocol, source = peer address, destination = listener address, ports = the exact list. Rows that share a source and destination merge into one rule with a port list.
6. Apply on every firewall in the path. The controller's own operating-system firewall, the inter-VLAN ACL on the router, and any host firewall on a PC in between all need the rule, active in the network profile the cell interface uses.
7. Bring remote access in through a gateway. A remote-access gateway on the cell network builds its own outbound tunnel; integrators sign into it and work as if local. The site router forwards nothing inward.

8. Test, then lock. Run a connect test on each port from the peer device, then the real command string. Delete every permissive rule added while debugging, and go live with the scoped set alone.

Worked example: one cell network, four ports

The cell holds one vision controller, one PLC, a remote-access gateway and an engineering laptop on a single switch, all with mask 255.255.255.0.

The subnet leaves 8 host bits, so it holds 2^8 = 256 addresses. Subtract the network address .0 and the broadcast address .255, and 254 usable hosts remain, covering .1 to .254.

The controller listens on four TCP ports: 8500 for commands and results, 8502 for recipe upload, 8503-8504 for monitor and emulator. Both peers reach the same listener address, so two rules cover the plan.

Traffic scale settles the second decision. Result strings are tiny: two parts per second at about 64 bytes each is 2 × 64 = 128 bytes per second. A GigE camera at full line rate moves 1,000 Mb/s ÷ 8 = 125 MB/s nominal, around 110-118 MB/s once protocol overhead is paid — roughly a million times the result traffic. That is why the camera ports keep their own switch or network interface and only the results ride the PLC path. The budgets in GigE camera network planning: switch ports and bandwidth and in two GigE cameras on one host: NIC ports and bandwidth budget size that network.

Any vision controller with enough Ethernet ports holds both networks at once.

Verify each port before the line runs

Stand at the peer device and run a TCP connect test to every port in the table.

Then run the go-live list:

• The connect test succeeds from the actual PLC, not only from a laptop.
• A real command string returns a real result string, end to end.
• Every rule names a source address; none leaves the source unrestricted.
• The gateway session reaches the controller while the site edge firewall holds zero inbound rules.
• Debug rules and temporary laptop addresses are gone.

Common mistakes that cost a shift

• Trusting ping. ICMP succeeds on a path whose TCP ports are all closed. Test the port, not the address.
• Switching the firewall off instead of adding a rule. The link works until the next audit or security scan re-enables the firewall; keep the scoped rule instead.
• Leaving the source unrestricted. The rule then admits every device on the plant network. Scope it to the peer address recorded in step 3.
• Forgetting the UDP half of a protocol. EtherNet/IP implicit I/O rides UDP 2222 even when explicit messaging on TCP 44818 already works.
• Forgetting the emulator or monitor port. Commissioning stalls on the integrator's laptop link, not on the PLC link.
• Binding two services to one port on one device. The second listener refuses to start because the port is already in use. Move it to another documented port or a second interface.
• Sending camera streams across the PLC link. At 125 MB/s of image traffic, control strings queue behind frames; keep the networks separate as in the worked example.

When to change the plan

Register-style exchange. When the PLC wants a few result registers on a cycle rather than strings, Modbus TCP on 502 is the simpler contract, and most PLC platforms read it natively. The vision controller Modbus communication guide walks that link step by step.

An existing raw-socket fleet. Keep it. Custom sockets on documented ports remain a clean design; apply the same scoping, exactly as the vision-to-PLC raw TCP socket connection shows with a code reader.

Code readers on the same line. A networked fixed code reader reporting decodes to the PLC follows this same plan; the code reader to PLC communication planner covers it from the reader side.

Heavy image traffic on the controller. When the unit also pulls the camera streams itself, it keeps that traffic off the plant link entirely.

The decision, case by case

• PLC polls the controller on one subnet: one inbound rule, TCP, exact ports, source = the PLC address, applied on the controller side.
• Controller pushes each result: the rule moves to the listener side, on the PLC interface or the device behind it.
• Cell and plant on different subnets: the same two rules land in the router's inter-VLAN ACL.
• Integrator support from outside: a remote-access gateway inside the cell with its own outbound tunnel, and zero inbound rules at the site edge.
• A raw-socket link you define yourself: take the port from 49152-65535.

Browse the vision controllers by LAN port count, or step through the whole chain in the configurator.

For an unusual host link, the contact page reaches the applications team directly.