Multiple vision cameras on Modbus TCP: one PLC CPU, one poll loop

Three Ethernet vision systems, one PLC CPU, and a controls group that wants every inspection result as holding registers: that is a standard Modbus TCP cell, and it needs no protocol converter. The CPU is the client; each vision system is a server listening on TCP port 502. Two decisions decide whether commissioning takes an afternoon or a week: the addressing architecture (a connection per camera, one gateway with unit identifiers, or one vision controller as the single server) and the poll-cycle budget. This guide commits to both, gives the unit-identifier rules, works the polling arithmetic for Ethernet and for a 19200 baud serial line, and ends with a register map and bring-up steps you can run in order.

Can one PLC CPU poll several Modbus TCP vision systems?

Yes. One CPU acting as Modbus TCP client polls as many vision servers as it has client connections — two or three cameras is routine — provided each server answers at its own IP address on TCP port 502.

Three architectures cover every real cell:

• A connection per camera. Every vision system runs its own Modbus TCP server on the plant or camera network. The PLC opens one client connection to each. Choose this for up to about three Modbus-capable devices.
• One gateway, many unit identifiers. A serial-to-Ethernet Modbus gateway fronts devices that only speak Modbus RTU. The PLC holds one connection; the unit identifier in each frame picks the slave.
• One vision controller as the single server. The cameras stream over GigE to a controller that runs the inspections; the PLC polls that one server.

Commit like this: up to three cameras that already serve Modbus TCP — direct connections, one per camera. Four or more cameras, coordinated triggering, or cameras without their own Modbus server — one vision controller in front and a single server to poll. Serial-only devices — the gateway, with unit identifiers doing the routing.

Do I need a serial-to-Ethernet gateway when the cameras are on Ethernet?

No. A serial-to-Ethernet Modbus gateway exists to carry Modbus RTU from an RS-232 or RS-485 line onto Ethernet; a camera that already runs a Modbus TCP server needs only a switch port and an IP address, not a converter.

The gateway reflex comes from the years when every device sat on a shared serial pair and Ethernet ended at a converter. On a native Ethernet camera the converter adds a store-and-forward hop, a second configuration surface and another power supply, and gives you nothing the switch did not already provide. On-device inspection cameras — smart cameras — hold their results internally; the models in this guide pass them to a vision controller over GigE, and the controller carries the Modbus conversation.

What is the unit identifier, and when does it matter?

The unit identifier is the one-byte field in the Modbus TCP header that replaced the RTU slave address; it routes a request to one slave behind a gateway and does no routing on a direct connection.

Every Modbus TCP frame starts with a 7-byte header: 2 bytes of transaction identifier, 2 bytes of protocol identifier (always zero), 2 bytes of length, then the single unit-identifier byte. The transaction identifier increments with each request and comes back unchanged in the response, which is how you pair answers with questions.

On a direct connection, the IP address has already selected the device, so the unit identifier steers nothing — but most servers still check it. Use 1 everywhere; 255 is the other value commonly accepted as meaning the device itself. Behind a gateway it is the slave address, and it is the only thing telling the gateway which camera you meant.

How do I address each camera behind one gateway?

Give every camera its own slave address from 1 to 247 and leave the gateway at one IP address; the PLC sends all requests to that IP on port 502, and the unit identifier — equal to the slave address — picks the camera.

Two wiring flavors exist. A multi-port gateway maps each serial port to its own unit identifier, so two cameras on two ports never see each other's traffic. A single RS-485 multidrop line carries them all, and every frame passes every slave; that is the cheaper cable and the slower bus. Either way, the PLC side stays one TCP session.

That single session is the gateway's real gift: a second master that needs the same data — an HMI, a line analyzer — opens its own client connection to the same address and port, exactly the pattern worked through in running several Modbus TCP clients to one IP and port.

How fast can one CPU poll all the cameras?

On Ethernet, budget about 7 ms per camera for the poll itself, so four cameras close in roughly 30 ms; behind a 19200 baud RS-485 line the same read costs about 24 ms per camera, and the cycle grows in a straight line with every camera you add.

Worked example — four cameras, direct Ethernet, one read of 8 holding registers per camera per poll:

• Request: 7-byte header + 5-byte read command = 12 bytes. Response: 7 + 2 + 8 × 2 = 25 bytes.
• Wire time at 100 Mbit/s: (12 + 25) × 8 = 296 bits ≈ 3 µs. The cable is not your problem.
• For turnaround, use 5 ms per camera and 2 ms of PLC client processing as example values; one measurement at commissioning replaces both. Per camera: 5 + 2 = 7 ms.
• Four cameras in sequence: 4 × 7 = 28 ms per full poll.

Decision: a 100 ms PLC task polls all four with 72 ms of margin. A 10 ms task polls one camera per scan round-robin and refreshes the whole cell every 40 ms.

The same read over Modbus RTU at 19200 baud, 8E1 framing (11 bits per character), on one multidrop line:

• Characters per second: 19200 / 11 ≈ 1745. Request 8 bytes + response 21 bytes = 29 bytes.
• t_wire = 29 / 1745 ≈ 16.6 ms, plus a 3.5-character inter-frame gap (about 2 ms) and a 4 ms slave turnaround: roughly 23 ms per camera.
• Eight cameras: 8 × 23 ≈ 184 ms. If the task cycle is shorter, raise the line to 115200 baud (29 / 10473 ≈ 2.8 ms of wire time per read) or put the cameras on Ethernet.

The same scan-to-result arithmetic, applied to code readers, is worked through in cutting scan-to-flag latency on a PLC link.

How many Modbus sessions does each device have to accept?

Budget four TCP sessions per polled device: the PLC's client connection, the HMI, your commissioning laptop, and one spare; anything less, and the laptop that worked last week locks the PLC out on Monday.

A session is one TCP connection to port 502. That port number is fixed for Modbus in the open Modbus TCP specification, and PLC client functions default to it, so plan on 502 and nothing else. Unit identifiers never separate masters — separate connections do. When a device offers fewer sessions than your budget, stop polling it directly and put the concentrator or the gateway in front, where one server faces the PLC and the second master reads the same registers from that server.

Keep the cameras on their own switch or VLAN. Discovery broadcasts and camera utilities have no business on the plant network, and the segment boundary must pass port 502 in both directions — the rule set is in TCP ports and firewall rules for a vision-to-PLC link.

What register map should every camera use?

Use one identical ten-register map on every server — status, sequence counter, part ID, x, y, angle, cycle time — read in a single request, so one block instance per camera serves the whole cell.

The sequence counter is the handshake. The PLC stores the last value it read; an unchanged counter means the camera has not finished a new part, and the PLC holds the previous verdict instead of re-failing a part it already handled. A 32-bit value spanning two registers needs a word order — write "high word first" into the map comment, because both orderings exist in the field and a swap turns coordinates into nonsense.

When is polling from the PLC the wrong design?

When inspections must be synchronized to motion or to each other: the Modbus poll is asynchronous by nature, so trigger the cameras from a hardwired output or a controller line, let each camera latch its result, and poll the latched values.

Three cases break the direct-poll design:

• Synchronized inspection. The trigger must be deterministic. Start routines from a PLC output or from the camera's own inputs — controlling vision routines on a smart camera from GPIO or serial keeps the timing out of the network entirely.
• The CPU has no client connections left. Invert the roles: the PLC serves one port and the vision systems push. The block pattern is in one server block answering several Modbus TCP clients.
• Four or more cameras. Concentrate: cameras on GigE into one vision controller, which runs the inspections and is the only Modbus server the PLC ever sees. The PLC-facing side of that architecture is the subject of vision controller Modbus communication, a PLC integration guide.

For the concentrator role, a controller that keeps camera traffic on its own segment and hands the PLC a single server:

The MV-VC3301H-128G66 has 5+ LAN ports, 4 built-in channels for lights and 8 GB of memory, with the vision software license included. Lights belong to the trigger, not to the poll: strobe them from the controller's channels or from a dedicated light controller so every image is lit identically.

How do I bring the cell up step by step?

Bring it up one layer at a time — addresses first, one camera polled alone, then the rest — and measure the per-camera turnaround before you trust the cycle arithmetic.

1. Give every vision device a fixed IP address on the camera segment, DHCP off, and write each address and unit identifier into the panel schedule.
2. From a laptop Modbus test client, read 8 holding registers from each device at its IP on port 502. This proves the server, the port and the wiring before the PLC is involved.
3. On serial devices, set and record every slave address (1-247) before mounting; duplicates only surface when two slaves answer inside the same scan.
4. In the PLC, create one client connection per Ethernet device — or one to the gateway — with unit identifier 1 for direct connections and the slave address behind the gateway.
5. Load the ten-register map on every server, then poll one camera for a minute and watch the sequence counter step once per inspection.
6. Time one exchange end to end and put your measured turnaround into the budget above.
7. Add the remaining cameras one at a time, confirming each poll closes before adding the next.
8. Run the full line rate for an hour with timeout and CRC counters logging, then hand it to production.

For the inspection layer, on-device cameras with fixed lenses keep each station's wiring simple:

The MV-SC5060XM-08M-WBN is a 6 MP mono smart camera with an 8 mm focal length, M12 mount and GigE; the MV-SC6050C-08M-XBN is the 5 MP color counterpart with a global shutter and a multi-color light source. For the lights, strobe control that sits next to the trigger rather than inside the poll:

The LS-CTL-0070 is a digital control box with 4 channels, strobe output, 200 W and an RS232 port.

Once you know the camera count and the cycle time you must beat, start the cell in the configurator or send us the layout and we will size the poll loop with you.