Multiple barcode scanners on Modbus RTU and TCP to one PC

A PC that must talk Modbus RTU and Modbus TCP to fifty barcode scanners and the fifty scales they sit on is not fifty point-to-point projects. It is one addressing plan and one poll budget. The devices line up as Modbus slaves on RS-485 lines, or as Ethernet nodes behind their own IP addresses, and the PC collects each in turn — in parallel on the Ethernet side. This guide gives you the two numbers that decide the layout: how long one poll of one device takes on a serial line, and how that multiplies across your device count. With them you can assign slave addresses, unit IDs, COM ports and network cards before any cable is pulled, and know in advance whether every scan reaches the server inside your time budget.

The decision first

One PC acts as the single Modbus master and gives every device an identity instead of a dedicated cable. On the serial side that identity is the slave address, 1 to 247, unique per RS-485 line, and the master polls in strict turn, so the budget is devices × poll time. On the Ethernet side the identity is an IP address, or a unit ID behind a gateway IP; polls run in parallel and wire time stops mattering.

The budget decides the layout. Fifty devices on one serial line at the default rate refresh about every 2.5 s, which fits a data-collection station and fails a fast one. Split the line, raise the baud rate, or put the scanners on Ethernet — the worked example below shows where each option lands. Scales stay as RTU slaves; readers with Ethernet ports poll as plain TCP nodes; serial readers join through a gateway.

Every rule in this guide follows the published Modbus serial-line and TCP specifications, so the address ranges, framing and silence gaps below are the standard's, not one vendor's habit.

Addresses that matter on the RTU side

Modbus RTU gives every device on a line one number: the slave address, from 1 to 247. Address 0 is broadcast and never belongs to a device. The master sends each request with that address inside it and only the addressed slave answers, so addresses must be unique per line. When two devices share a number, both transmit into the same wire pair, the frames collide, and the master logs timeouts on both.

You set the address in each device's configuration menu or its address switches; vendors label it 'slave ID', 'station number' or 'node address' — the function is the same. Keep a written map of address to station before the first power-up.

The line itself is strictly one request at a time: ask, listen, next device. No second request goes out until the reply arrives or its timeout expires. Some slaves also need a beat to empty their buffer before they accept the next frame — if a device misses requests under load, add a few milliseconds of idle between polls and the misses stop.

RTU framing defaults to 8E1, and to 8N2 when parity is off, which puts 11 bits on the wire per character. That number drives every timing figure below.

What one poll costs on a serial line

Three terms set the time of one poll: the request frame, the reply frame, and the silent gaps the protocol requires around each frame. RTU demands at least 3.5 character times of silence before and after every frame — 7 character times per poll in total.

A register read is always 8 bytes out. The reply is 5 bytes of address, function, byte count and CRC plus 2 bytes per register — for N registers, 5 + 2N bytes. The data block is the only term you control, so read exactly the registers the application consumes and nothing more.

At the RTU default rate a character takes 1.146 ms, so the mandatory silence alone costs 8.02 ms per poll. At 38400 baud the same silence costs 2.01 ms. Everything else is multiplication, which the worked example now does for a real fifty-device line.

Worked example: 50 scanner-and-scale pairs on one RS-485 line

Inputs, and where each comes from:

• 50 scanner-and-scale pairs — the project this guide answers; each pair is one Modbus RTU slave, all 50 on one RS-485 line.
• 9600 baud, 8E1 — the RTU default framing, so 11 bits per character.
• One read per device of 12 holding registers: scale weight (2 registers), reader status (1), new-data sequence counter (1), and the last code as 16 bytes of payload (8 registers).
• Request frame: 8 bytes = 88 bits. Reply frame: 5 + 2 × 12 = 29 bytes = 319 bits. Silence: 7 character times.

Rule: a poll costs its frame bits over the baud rate plus the 7 character times of mandatory silence; the full line cycle is one poll time multiplied by the device count.

Arithmetic:

• Character time: 11 bits / 9600 baud = 1.146 ms
• Silence: 7 × 1.146 ms = 8.02 ms
• Request: 88 bits / 9600 = 9.17 ms
• Reply: 319 bits / 9600 = 33.23 ms
• One poll: 9.17 + 33.23 + 8.02 = 50.42 ms
• Full cycle: 50 × 50.42 ms = 2521 ms ≈ 2.5 s

Result and decision. Every device is collected once every 2.5 seconds. The scanners keep decoding at their own rate and hold each code; the poll sets how old the news is when it reaches the server, not whether a code gets read. If the process tolerates 2-3 s of staleness, one line at the base rate is the entire design. If the server must react inside 1 s, the single line misses by 2.5×, and two serial fixes exist: four COM ports with 13 slaves each cycle in 13 × 50.42 = 655 ms, or the same one line at 38400 baud runs 12.60 ms polls and cycles in 50 × 12.60 = 630 ms. Past a one-second requirement, or past about 20 devices per default-rate line, the Ethernet side wins — that is the threshold.

Modbus TCP: parallel polls, not a longer line

Modbus TCP wraps the same register read in an MBAP header and replaces the serial address with a unit ID. The wire arithmetic collapses: a read request is 12 bytes, the 12-register reply is 33 bytes, so one poll moves about 45 bytes = 360 bits = 3.6 µs on 100 Mbps. The budget moves to connection count and device latency. Allowing a generous 10 ms of stack and firmware latency per poll, 50 devices at a one-second refresh need 50 polls per second — about 0.5 s of round-robin work per cycle on one thread.

Two layouts cover everything:

1. Unique IP per device. The PC keeps one TCP connection open per reader and polls them all; unlike RTU's strict turn-taking, a Modbus TCP client can keep several requests in flight at once. Never reuse one socket for different IP addresses by reconnecting in sequence — open one connection per device and leave it open.
2. One gateway IP, unit IDs 1-247. A serial-to-Ethernet gateway holds one IP and routes each request's unit ID to a serial slave behind it; that is how RS-232 and RS-485 scales join a Modbus TCP host. The gateway still drives its serial side one request at a time, so the RTU arithmetic follows it through the bridge: a gateway fronting a 13-slave line answers at that line's 655 ms rhythm, not at Ethernet speed.

The serial-to-Ethernet converter guide wires the gateway layout end to end, and the one-poll-loop pattern for several Modbus TCP cameras shows the same master scheduling from a PLC.

Decision: Ethernet devices with unique IPs reach sub-second refresh for 50 nodes easily; serial devices behind gateways keep their serial rhythm, so give each gateway's line its own budget.

What your scanners and scales actually speak

Scales and load cells are the natural Modbus RTU citizens — weight registers over RS-485 is their standard outfit. Industrial code readers mostly are not: today's fixed readers expose Fast Ethernet or GigE, USB, and on some logistics models a serial port. Their payloads travel as ASCII or structured frames over a socket rather than Modbus registers, which is why the PC side reads them with plain TCP sockets, raw socket links without EtherNet/IP, and strict ASCII framing rules so a half-received code never reaches your database.

To fold a socket-speaking reader into a strictly Modbus world, put a gateway between: it maps the reader's port into holding registers and hands you one unit ID or register block per reader. The device wiring follows the single code reader on Modbus RTU recipe; scaling to fifty repeats addresses, not links.

The readers that fit the TCP layout as-is are the fixed Ethernet models — the PC opens one socket each and polls them like any other node. The LS-CRD-0028 reads up to 60 codes/s over Fast Ethernet with its 2560 x 2048 sensor and 8 mm lens, so the reader, not the poll, is the fast step of that chain.

A serial-interface reader joins the same plan through the gateway route, exactly as the scales do. The MV-ID6200PM-00C-NNG is a 20 MP logistics code reader with a serial interface and a C-mount.

Handheld code readers usually stay on USB at a bench station: one operator, one device, no poll budget needed.

The host side is ordinary PC engineering — one COM port or USB-to-RS-485 adapter per serial line, one network interface for the socket pool, one polling thread per line. Fanless vision controllers built for multi-camera cells carry port counts in that class already.

The MV-VC5525-256G70-NN provides 5+ LAN ports and 32 GB of memory, and a fifty-socket pool plus image buffers fits inside that with room to spare.

How to choose the layout for your case

Per case, the recommendation:

• New line, readers not yet fixed: choose Ethernet-interface models, unique IPs, parallel polls. The whole job is an afternoon of configuration.
• Scales already on RS-485: leave them as RTU slaves; 13 per COM port at the default rate buys a 0.66 s cycle, or pull that line to 38400 baud for 0.63 s on one port.
• Mixed line: scales on their RTU lines, readers on Ethernet, one scheduler with two thread pools. Never hide a reader behind a scale line's gateway unless staleness is acceptable.
• Strictly Modbus-only host software: gateways with unit IDs for every serial device, and each line's serial rhythm counts behind its bridge.

Browse the fixed code readers category or the code-reader finder to shortlist Ethernet-interface models, and size the poll budget with the formula before ordering cable.

Checks before you commission

• Audit every slave address switch or menu setting against your written map, and power-cycle after changes.
• Poll the full cycle at the designed rate for an hour and log timeouts and CRC errors; a healthy 13-slave line shows near zero of both.
• Read one register from every unit ID behind each gateway before production, confirming the ID-to-device map.
• Check the Ethernet side for duplicate IPs before it fails intermittently — each socket must resolve to exactly one device.
• Log the round-robin duration per line and alarm when it exceeds the design value by 20%; that alarm catches a failing slave before it stalls the line.
• Keep the payload parser strict about framing, so a code split across two reads never lands as two records or one wrong one.

When the obvious answers are wrong

One serial or USB port per scanner scales worst of all: fifty readers mean fifty COM-enumerated links, each its own cable run and failure point, where shared-line addressing needs one wire per thirteen devices. The input-method comparison shows where point-to-point still makes sense — a handful of devices, not fifty.

A single RS-485 segment carrying everything 'because the wire allows it' confuses electrical capacity with poll budget: the wire holds the nodes and still takes 2.5 s per cycle at the default rate.

One TCP connection reused across several IP addresses in sequence turns parallel polls back into a serial queue; keep one socket per device.

Treating the poll as the read is the last confusion to drop. The reader decodes continuously and latches the result, the poll collects it, and a sequence counter read alongside the payload tells the two apart.

Size the budget first, then buy. If you send the device count, register list and required refresh through the contact page, we will check the arithmetic against your device list, and the code-reading topic page collects the rest of the scaling patterns.