Barcode reader to a PLC ASCII serial port at 160 reads per minute

A fixed reader that must deliver 160 reads per minute to a PLC puts one decoded string on the wire every 375 ms. That is slow traffic for a controller, so the simplest link wins: an RS-232 ASCII line into the controller's serial port, drained by a receive instruction that runs every scan. This guide sizes that link, walks the wiring and the settings that must match at both ends, frames each string so nothing is dropped, and names the rate where Ethernet takes over. Worked numbers assume a 20-character payload at 9600 baud, and every factor that moves the answer is stated with its effect.

Is a PLC ASCII serial port fast enough for 160 reads per minute?

Yes, with wide margin: 160 reads per minute is one decoded string every 375 ms, a 22-character string at 9600 baud holds the line for 23 ms, and even a 100 ms controller scan leaves 202 ms spare between strings. Three formulas set the whole budget:

Run them for the worst case, not the average. Controller cycles of 1 to 100 ms are the normal range for mid-size programs, and the receive buffer — not your ladder logic — absorbs the time between scans. Stack the worst case: 23 ms on the wire, a 50 ms post-read delay at the reader, one 100 ms scan before the string is copied out. That path totals 173 ms against a 375 ms period, so 202 ms of slack remains. If your line ran ten times faster you would be comparing link types rather than timing one; that comparison, made at 2,000 reads per minute, is covered in choosing barcode scanner communications for 2000 reads per minute.

How much line time does one barcode string take?

A 20-character payload with CR and LF appended is 22 characters; at 8N1 that is 220 bits, so the string needs 22.9 ms at 9600 baud, 5.7 ms at 38400 baud and 1.9 ms at 115200 baud. The 8N1 frame carries 1 start bit, 8 data bits and 1 stop bit — 10 bits per character, parity off. That fixed per-character cost is why baud changes line time but barely moves the ceiling:

The ceiling column is 60 s divided by the full worst-case path, and it moves only 45 reads per minute across a twelve-fold baud range. The scan and the post-read delay own the budget; the wire does not. Decision: run 9600 baud at 160 per minute, and raise it only if the port carries other traffic — at 38400 baud you buy 17 ms of margin, not a new rate class.

How do you wire the RS-232 link from reader to PLC?

Cross the pairs: reader TX to controller RX, reader RX to controller TX, signal ground to signal ground, in a shielded cable of 15 m or less at 9600 baud — a pin-for-pin cable is the most common cause of a silent port. The controller end is usually a DB9; the reader end is often a round industrial connector or flying leads, so use the maker's integrated code reader cables rather than adapting pins blind. One integrated cable ends in open leads, RJ45 and a DB9 that mates with the controller's port:

At 5 m it covers a typical reader-to-cabinet run, and the open leads give you the crossover without a soldered adapter. The 15 m figure comes from the interface standard's capacitance limit, not from a metre count on a drawing. Beyond it, drop the baud, move to RS-422/485 levels, or buy the reader with Ethernet — do not stretch RS-232 and hope.

For the screw-terminal and pin-number side of the same job, see wiring a barcode scanner RS232 ASCII string to a PLC serial port.

What serial settings must match at both ends?

Set both ends to 9600 baud, 8 data bits, no parity, 1 stop bit, and aim the controller's receive terminator at the carriage return the reader appends — a mismatched baud rate is the usual source of garbage characters. Readers ship at 9600 8N1 more often than not, so the least-work path is to leave both ends there. When the port prints symbols instead of barcodes, walk the checklist in garbage characters from a barcode scanner: fix the PLC serial link before touching wiring.

Termination deserves one careful minute. Configure the reader to append CR (ASCII 13 decimal, hex 0D) and LF (ASCII 10 decimal, hex 0A); many reader tools take these values in hexadecimal while controller channels often want decimal, so you enter the same pair twice in two notations. An example of setting the termination character on a serial ASCII channel shows the controller-side half of that setting. Keep the reader's post-read delay — the pause it inserts after finishing a string — at 50 ms or less, and switch the prefix off unless you use it deliberately as a start delimiter; the pattern is laid out in prefix and suffix framing for barcode scanner input.

How do you keep every string out of the buffer and into a tag?

Run one receive instruction, enabled every scan, that ends on CR and copies each finished string out of the receive buffer before the next lands — at 160 per minute the line sits idle 352 ms between strings, so a dropped string is a framing error, not a speed problem. Size the buffer once: the longest payload plus CR and LF is 22 bytes, so a 64-byte buffer holds two full strings with room for jitter. Instructions that fire once per transition must be retriggered each scan — that trap and its fix are laid out in ARL and AWA ASCII instructions execute once: retrigger each scan.

Two failure modes account for most lost strings at this rate. Bytes that arrive without a terminator sit in the buffer until something else flushes them; the nulls and races that follow are dissected in ASCII barcode data framing in the PLC receive buffer. And a code the reader cannot decode sends nothing at all, so give the logic a timeout shorter than one part period and treat it as a reject, as in abort a serial barcode read when the scanner reads nothing.

Handshaking can stay off. RTS/CTS exists for receivers that cannot drain between strings; yours drains a 23 ms string in a fraction of a scan. If the reader refuses to send until its handshake inputs are asserted, jumper those pins at the reader connector and leave the controller side clean.

Which reader fits a 160-per-minute line?

Any fixed code reader rated above 10 codes per second carries this line with better than 3× headroom — 160 per minute is 2.7 reads per second — so pick on reading distance, code type and mounting rather than interface speed. For close mounting, the LS-CRD-0047 is a compact reader with USB 2.0 output and a 60-120 mm reading distance. The LS-CRD-0052 brings an Ethernet interface and a 12 mm focal length for longer stands. The MV-ID6200PM-00C-NNG is the native serial path: a 20 MP logistics reader with a C-mount lens. Three readers, three integration paths:

Values as printed in each product's data sheet; open a part for its drawing and full specifications.

A USB reader on a controller deserves a note of its own: controller USB ports expect specific device classes, and why serial still wins on PLC USB ports explains why the converter cable is often the shorter path. Browse the fixed code readers category or filter the code reader finder by interface, and check reader accessories for the light boards and protective covers that keep a fixed reader alive on a line.

When should you step up to Ethernet?

Step up when any limit appears: the rate passes 500 reads per minute, the run exceeds 15 m, the decode image must be archived with each read, or a second reader joins the controller — below those limits, serial ASCII is simpler to commission and to troubleshoot. The 500 cutoff is arithmetic, not taste: at 500 per minute the period is 120 ms, under the 173 ms worst-case serial path, so the paper margin is gone. With a 10 ms scan the same link clears 700 per minute, which is why the rule says 500 with a normal scan, not 300.

Two readers change the economics: one serial module per reader against one switch port each, and Ethernet wins the moment you also want the image. On that side the reader can listen as a TCP server with the PLC as client, as in barcode reader as TCP server: wire your PLC as the client, or push ASCII strings exactly as a serial device would, as in vision camera to PLC over Ethernet: ASCII strings, no serial port.

Out of serial ports on the controller? Add a serial module before you route the reader through the HMI's port; when the HMI must sit in the path, the framing rules in barcode scanner to an HMI serial port: framing data without headers and the approach in reading a barcode reader through the HMI when PLC serial ports are full keep the string whole. An example of ASCII reads on a compact controller's serial port shows that half of the link. More integration write-ups sit on the code reading topic page.

What should you check before ordering?

Close five numbers and the part choice makes itself: line rate today with headroom to 300 per minute, reading distance to the code, payload length, controller scan time, and the free port type on the controller. Work the list in this order:

• Rate headroom. Reader decode rate at least 3× the line rate; a 60 codes per second reader against 2.7 reads per second is 22× covered.
• Interface path. Serial, USB with a converter, or Ethernet — matched to the port you actually have free.
• Cable. Crossover pinout, 15 m or less at 9600 baud, and the maker's integrated cable when the reader end is not DB9.
• Settings sheet. 9600 8N1 written into both the reader configuration and the controller channel before power-up.
• Framing. CR and LF suffix on, prefix off or deliberately used as the start delimiter, post-read delay at 50 ms or less.
• Buffer and timeout. Receive buffer of 64 bytes or more, no-read timeout at 300 ms.
• Bench test. Ten minutes at full rate; the count of strings received equals the count of triggers sent.

If the controller's port or the reader's connector is unusual, bring both part numbers to our support team and we will pin the crossover out for you.