Choosing barcode scanner communications for 2000 reads per minute

Two thousand barcodes per minute sounds like a networking problem. It is not. The rate is 33 codes per second, and a framed read adds up to a few hundred bytes per second of traffic — the constraints that actually bite are the controller's scan time, the port you dedicate to the scanner, and, because this rate implies a fast belt, whether the reader can still decode a moving 20 mil code. This guide sizes the link, compares RS-232, RS-422, Ethernet and DeviceNet at that rate, and lists the numbers to lock down before ordering. For the wider serial-versus-USB-versus-Ethernet question on a PLC, start with barcode scanner input methods to a PLC: serial, USB and Ethernet.

Which communication method should you use at 2000 reads per minute?

Use RS-232 (or RS-422 on a long run) ASCII at 115.2 kbaud into a dedicated serial port; the full stream is 333 bytes per second. Choose Ethernet only when no port is free, and then only on an isolated segment with static IPs; keep this rate off DeviceNet.

The economics follow the arithmetic. A point-to-point serial link carries no other traffic, needs no switch and no address plan, and a 15 m cable is ordinary stock. A compact controller with two serial ports plus an Ethernet port covers both of your scanners — the fast one and the taping-station one — while Ethernet stays free for programming and the HMI. If layout or distance forces Ethernet, the isolation rules in the Ethernet section below keep it dependable. Either way, treat the link as a designed part of the cell: barcode reader PLC communication: plan a reliable link walks the framing and handshake choices that decide whether a read reaches your logic intact.

How much bandwidth is 2000 barcode reads per minute?

About 333 bytes per second: a 10-byte read frame delivered 33.3 times per second, which is 3% of a 115.2 kbaud link and 35% of a 9,600 baud link.

Count the frame the way the scanner sends it: one STX start character, the payload, one ETX terminator. Most configuration utilities expose exactly this preamble-and-terminator scheme; a guide to configuring barcode scanner serial communications shows the settings on a representative reader.

The eight-digit code is the short case. A 20-character GS1 string with separators frames to 22 bytes; at 33.3 reads per second that is 733 bytes per second, still 6% of 115.2 kbaud. One limit to catch early: some serial device modes carry only about 24 data bytes per read, so a long payload needs the scanner's full ASCII mode.

Set both ends to 8 data bits, no parity, 1 stop bit — 10 bits per character, which is what every number above assumes. Wrong parity or baud does not fail loudly; it arrives in the controller as garbage characters, the failure mode dissected in fixing garbage characters on a barcode scanner's PLC serial link.

What baud rate should the scanner run at?

115.2 kbaud, which moves a 10-byte frame in 0.87 ms; 38.4 kbaud is the practical floor on a noisy line, and 9,600 baud still closes but spends a third of every 30 ms window on the wire.

Wire time should be a rounding error against the window, so a re-read, a long payload or two frames arriving back to back never stack into a miss. At 115.2 kbaud the frame leaves the wire before the controller logic notices it arrived. At 9,600 baud that same frame owns the line for a third of your window, leaving nothing for a second attempt.

Distance sets the real limit, not speed. RS-232 is single-ended: plan 15 m or less, and stay on the short side of that at full baud. RS-422 or RS-485, differential and noise-tolerant, runs about 1,200 m and is the serial answer for a scanner at the far end of the conveyor. Past that, buy an Ethernet reader.

How fast must the PLC scan be to not lose codes?

Under 15 ms — half of the 30 ms window — so the receive buffer is emptied at least twice before the next frame lands; the port interrupt on the terminator does most of the work.

A new frame arrives every 30 ms at this rate. A 15 ms scan gives you two passes at each one; a 10 ms scan gives three and real margin. The interrupt path matters more than the scan average: the frame-complete event should move the string into your tracking table immediately, and the rest of the path — port service, ladder hand-off, flag to output — is its own latency budget, sized in cutting scan-to-flag latency on a barcode scanner link. On the trigger side a photoeye pulses every 30 ms; sensor, serial or free-run triggering changes where that budget goes, as fixed barcode reader trigger modes: sensor, serial or free-run lays out.

When is Ethernet the better choice?

When the controller has no free serial port, when the run exceeds what RS-422 covers, or when you want both scanners on one network: raw TCP or CIP I/O on an isolated, statically addressed segment.

Bandwidth never decides this — the byte rate is trivial on 100 Mbit/s — topology does. The dependable pattern is a dual-port Ethernet module: scanners on one port, the plant on the other, so office traffic never shares the scanner segment. Assign static addresses on a subnet IT does not use — if the plant is 192.168.x.x, put scanners on 10.x.x.x. Turn DHCP off; a lease renewal can re-address a scanner mid-shift, and the station goes quiet with nothing visibly broken.

For CIP-based I/O, set the connection update to 10 ms or less, and remember that I/O frames ride UDP with no retransmit: one lost frame is one lost code. Raw TCP is the safer pattern here because the reader buffers its own codes and the controller collects them by socket — barcode reads to a PLC over raw TCP sockets without EtherNet/IP and wiring the reader as TCP server with the PLC as client cover both layouts.

These compact readers put the same frame on Fast Ethernet, plain Ethernet or GigE:

Why does DeviceNet fall behind at this rate?

Because every node shares the poll cycle: at 2,000 reads per minute a 10-20 ms poll interval leaves no margin, and one missed poll is one lost code with no retry.

A DeviceNet trunk tops out at 500 kbit/s, and the scanner's delivery time is scheduled around every node on the cable, so worst-case timing depends on devices you do not own. Below about 500 codes per minute the window is 120 ms or wider and a shared poll is comfortable. At a 30 ms window it is not. Decision: DeviceNet stays on slow trunks; at this rate use point-to-point serial or isolated Ethernet.

Does 2000 reads per minute change the reader itself?

Yes: it sets the belt speed, and the belt speed sets the exposure — 2,000 parts per minute at a 6 in pitch is 1,000 ft/min, where freezing a 20 mil module takes 100 µs or less.

At 5.08 m/s a 25 mm code crosses the scan line in 5 ms, and a 150 mm field of view holds it for 29 ms — one frame at 30 fps, a single chance. So the reader must re-trigger inside the window: rate it at least twice the line rate, 60 codes/s or better here. Halve the pitch and you halve the belt speed, doubling every one of these windows; the formulas scale with your numbers.

A 100 µs exposure also sets the lighting: a strobed integrated light or a bright external one, not a dim continuous bar. Light boards and polarized covers for fixed readers sit in code reader accessories, and polarization is what saves you on shrink-wrapped or laminated labels.

For a line like this we would start with the LS-CRD-0028.

Its data sheet rates it at 60 codes/s with a 2560 x 2048 sensor — twice the read rate this line runs. Spread that sensor over a 150 mm field of view and each pixel covers 0.059 mm, so a 0.508 mm module spans about 8.7 pixels, nearly triple the 3 pixels per module a decoder wants. The same width covers fields of view up to about 430 mm before modules thin to 3 pixels; go wider and you buy pixels, not light.

Run the same arithmetic for your field of view and module size in the camera resolution calculator:

What should you check before ordering?

Five numbers: the reader's rated codes per second (at least twice your line rate), the controller scan time (under 15 ms), the frame length, the cable run, and the code module width (20 mil or larger at this belt speed).

• Reader rate. The rating must fund a re-trigger inside the 29 ms visibility window, not just meet the average.
• Scan time — 15 ms or less. If the program cannot get there, buffer codes in the reader and collect by exception instead of polling.
• Frame — count your longest code. A 20-character payload frames to 22 bytes; confirm the mode carries it end to end.
• Cable — match the run to the standard. RS-232 under 15 m, RS-422 / RS-485 to about 1,200 m, Ethernet beyond.
• Code quality — send samples out. Give the reader maker sample codes, belt speed and pitch for a decode confirmation before hardware is cut; damaged or low-contrast symbols miss far more often than the link does, and improving barcode decode rate on damaged, low-contrast codes shows the levers.
• Mismatch alarm — plan the memory, not just the horn. Comparing the entry read against the taping-station read is a first-in, first-out table in the controller; storing ASCII barcode strings in PLC memory covers the layout, and bottle label barcode verification with a fixed reader and PLC serial link is the same two-station pattern end to end.

The fixed code readers range then narrows to a model, and the system configurator bundles it with the light and controller.

When is the usual answer wrong?

When codes must be matched piece by piece, when the program cannot scan under 15 ms, or above roughly 20,000 reads per minute — the point where 115.2 kbaud runs out of margin.

That ceiling is arithmetic, not opinion: 11,520 bytes per second at 115.2 kbaud, held to 30% for bursts and re-reads, is about 3,456 bytes per second — 345 ten-byte frames per second, about 20,700 reads per minute. Below that, serial carries anything a belt can present to it.

Piece matching is the failure that looks like a comms problem. Two stations comparing codes needs an encoder-paced shift register sized to the pieces between them; no link upgrade fixes a tracking table that is one slot short. Budget the engineering hours there, not in baud rate.

Two more reversals. If the only network available is shared with IT and cannot be segmented, serial is the right answer even at extra cable cost. And do not size the taping-station scanner like the fast one — it reads one box at a time, and a basic serial port is exactly right for it.

The decision in one line: dedicated RS-232 or RS-422 at 115.2 kbaud with a sub-15 ms scan as the default; isolated, static-IP Ethernet when ports or distance demand it; nothing shared at 30 ms per code.