A barcode scanner wired to a PLC serial port that returns dots instead of digits, with a receive counter that changes by a different amount every scan, has a fault on the RS-232 link itself, not in your string-handling code. This page is for anyone commissioning that first scanner-to-PLC serial connection. You will read the symptom fingerprint, run five tests in order (transmit-lead identification, frame settings, queue clearing, signal ground, adapter level), and finish with clean, correctly framed ASCII on every scan. On a first install, expect the cause to sit in the first two tests: a swapped transmit pair is the most common finding of all.
Read the fingerprint before you touch a wire
Dots in a received string are bytes that are not printable ASCII. The corruption happens at the byte level on the wire, so the parsing logic is innocent and the link is guilty. The failure pattern then narrows the cause to a single test:
| Symptom | Most likely cause | First test |
|---|---|---|
| Counts change randomly, string shows dots | Swapped RXD/TXD, or missing signal ground | Idle-voltage check, then swap the leads |
| Same length every scan, every character wrong | Baud, parity or stop-bit mismatch | Set 9600 8N1 on both ends |
| Length grows by whole messages | Receive queue never cleared | Clear the queue before each read |
| Correct once, then doubled or trailing bytes | Clear runs at the wrong moment | Clear, read, then re-arm in one sequence |
| Nothing received at all | No trigger, or a logic-level adapter | Idle-voltage check, then trigger check |
Two shapes of count change tell different stories. Counts that move in whole-message steps (12, 24, 36 for the same label) mean bytes are accumulating in the receive queue. Counts that move randomly (17, 9, 23) mean electrical corruption: wiring, ground or noise.
The same sequence of changing counts, a dot-filled buffer and a swapped-wire fix is laid out step by step in a serial wiring and data troubleshooting walkthrough for a barcode scanner feeding a PLC.
The five causes, in order of probability
- RXD and TXD swapped. Both ends are transmitters, so the receiver listens on a line nobody drives. The classic first-install fault.
- Baud, parity or stop-bit mismatch. Scanner and PLC sample the same bits at different instants.
- Receive queue never cleared. Old bytes mix into the next read, and lengths grow message by message.
- Signal ground missing or noisy. Receivers switch at ±3 V, so a minimum ±5 V driver leaves only 2 V of margin.
- A logic-level output in the path. A 0-5 V 'serial' signal never crosses RS-232 thresholds at all.
Work them in this order. Each test takes minutes and either clears a cause or finds it.
Test 1: identify the transmit lead, then swap with power off
On a standard 9-pin DTE serial port, pin 2 is RXD, pin 3 is TXD and pin 5 is signal ground. Some scanners wire the connector as DCE or with a custom pinout, so read the interface page of the scanner's manual once and label the cable. Nobody should have to guess twice.
You can find the transmit lead without any pinout at all. With the scanner powered and idle, meter from signal ground to each signal lead at the PLC terminals. An RS-232 transmit output idles negative, typically -5 to -12 V and within the standard's -5 to -15 V mark range, while a receive input sits near 0 V. The negative lead is the scanner's TX, and it belongs on the PLC's RXD terminal. A crossed pair also leaves two line drivers facing each other output-to-output, which stresses both ports.
Fix: power off both ends, swap the two signal leads at one end only, power up, and scan the known label. The same label returning the same clean string on every scan closes the fault. The full pin and ground arrangement for this kind of hook-up is in the RS-232 connection guide for embedded hosts.
Test 2: match the frame on both ends
Start at 9600 baud, 8 data bits, no parity, 1 stop bit on both ends, which is the default on most handheld readers, and change settings on both sides together, never one alone. If either end offers flow control, set it to none while you commission.
Worked example at 9600 baud, 8N1:
- Bit time: 1 / 9600 s = 104.2 µs
- Character time: 10 × 104.2 µs = 1.042 ms
- A 10-digit label plus CR and LF is 12 characters, so one scan occupies the line for 12 × 1.042 ms = 12.5 ms
The mismatch fingerprint falls out of the same arithmetic. A scanner transmitting at 19200 baud sends 52.1 µs bits; a port set for 9600 samples every 104.2 µs, once per two transmitted bits, and assembles deterministic wrong bytes. The string keeps the correct length while every character is garbage, which is exactly the 'same count, all dots' symptom. Parity and data-bit mismatches corrupt characters the same way.
If the frames match and the port still never receives anything, the scanner may not be sending at all. Check trigger wiring and host commands with the silent serial trigger guide.
Test 3: clear the receive queue before every read
Most PLC serial tool sets expose an input-queue counter, the number of bytes waiting. A counter that moves differently on identical scans is not a mystery; it is arithmetic you can check. Worked example, same 12-byte label every scan:
- Scan 1: queue cleared, 12 bytes arrive, the read drains 12, counter back to zero, string clean
- Scan 2: clear skipped, so 12 old + 12 new = 24 bytes waiting
- Scan 3: 24 old + 12 new = 36 bytes waiting
Readings of 12, 24 and 36 mean one full message accumulates per scan because nothing drains the queue. Move the clear to the start of arming each read, then stream exactly the expected count or read to a terminator. Counts that differ by a fixed small offset point instead at the reader's output format: many models append a code-quality field, and a shorter no-read string next to a full label changes the count on identical scans.
Framing makes stale bytes detectable instead of silent. Have the reader send a suffix terminator and match it in the PLC: the prefix and suffix framing guide shows the pattern, the variable-length input fix covers labels of different lengths, and the full clear-arm-read sequence for a serial module is in reading a scanner into a PLC CPU module over serial.
Test 4: prove the signal ground, then protect the noise margin
RS-232 has no separate reference pair; both devices must share signal common. Meter between the PLC signal ground and the scanner ground lead: the reading should be under 0.1 V. Volts of difference means the signal voltages reference through whatever metal path exists, and the receiver reads that difference as data.
The margin arithmetic shows why noise matters. A receiver switches at ±3 V, so a minimum ±5 V driver leaves 5 - 3 = 2 V of margin, and a ±12 V driver leaves 9 V. A serial cable run beside a variable-frequency drive output can inject volts of switching noise, which flips random bits, and random bit flips are random counts and dots.
Fix in this order: one continuous shielded cable with the shield grounded at the PLC end only; 300 mm of separation from power and motor wiring as shop practice, crossing at right angles where a crossing is unavoidable; and if the run must get longer, drop the baud rate before adding cable. The design point from the standard is 15 m at the full 20 kbit/s rate, set by its 2500 pF load limit; at 9600 baud, shielded runs of 20-30 m are normally solid. Shielded serial-grade cable and connectors are in the cables category.
Test 5: confirm a true RS-232 level, not logic level
The idle-voltage measurement from Test 1 doubles as a level check. An idle transmit lead reading 0 V or +5 V instead of a negative voltage means the port is logic level: its 0-5 V swings never cross the ±3 V RS-232 receiver thresholds, so you receive nothing at all or noise read as framing errors. Put the converter the scanner's documentation specifies between logic level and RS-232, or change the interface. A true RS-232 idle is negative; there is no third possibility.
Prevention: wire it once, then keep it clean
- Label the corrected pinout on the cable at both ends. Wiring is the part nobody remembers a year later.
- Record the agreed frame (for example 9600 8N1) next to the pinout, so a replaced scanner or PLC module gets set the same way.
- Put clear, arm, read, re-arm in one subroutine, so no scan path skips the queue clear.
- Enable a suffix terminator on the reader and match it in the PLC, so partial or stale frames fail loudly instead of parsing as garbage.
- Ground the shield at one end only, and keep the 300 mm separation from power runs.
- Keep the known test label with the panel drawings.
- Sign off with 50 consecutive scans of the same label: 50 identical strings, zero length changes, zero framing errors.
Two cross-checks round this out. Other controller families show the same fingerprints, and same garbage-data fix traced end to end on a different controller platform is worth reading if your symptoms match but your hardware differs. And if the PLC now holds clean strings while garbage still lands in an HMI input field, the fault is in the hand-off to the display rather than the scanner; a walkthrough for garbage characters arriving in an HMI field after a barcode scan covers that side. More fixes in this family are collected on the code-reading topic page.
When RS-232 keeps fighting you, change the interface
After a corrected pinout, matched frames, a cleared queue, a proven ground and a true-level port, a link that still garbles at under 15 m has a hardware fault in one of the two endpoints. Stop debugging the cable and change the interface.
USB removes the TX/RX pair entirely: the host enumerates the reader and the link either works or it does not. Both of these wired readers connect over USB:
- Resolution
- Up to 3 MP
- Shutter
- Global
- Interface
- USB
- Connection
- Wired
The LS-HCR-0001 is a 1.0 MP wired handheld reader with a USB 2.0 interface, and the second card is the general-purpose wired USB model from the IDH5000P series. Where the characters go from there, HID keyboard input to an HMI or a virtual serial port, is worked through in USB barcode scanner input on a PLC HMI and the three input methods to a PLC.
For longer runs, change to Ethernet. Fast Ethernet gives 100 m per hop with standard network diagnostics, a different league from the RS-232 design point of 15 m.
- Interface
- Fast Ethernet
- Connection
- Wired
This wired industrial code reader from the IDH3000 series carries a Fast Ethernet interface, and the host-side choice of client or listener role is set out in the TCP client or listener guide. The handheld code readers category and the code reader finder filter by interface and connection, and integrated readers take dedicated cables and covers from the reader accessories category.
If you would rather have a second pair of eyes before ordering, send the scanner model, the PLC port type and a photo of the wiring through the contact page, and we will point at the most likely of the five causes. To specify reader, cable and mounts as one system, start the system configurator at the extras step.
Questions
Why does my receive counter move when nobody is scanning?
In presentation mode some readers re-transmit a label on a timer, so a resend interval of about 8 seconds adds a fresh 12 bytes between reads and the counter moves with the label just sitting there. Turn continuous reading off while you commission, or arm each read individually so the timer's bytes are cleared before they matter.
Why does a straight-through serial cable fail where a crossed cable works?
A PLC serial port is usually wired as DTE, with pin 2 as its receive input, while many scanners wire the connector as DCE, which mirrors the pins. The scanner's transmit then arrives on your transmit pin. A crossed, or null-modem, lead puts each transmitter into the other end's receiver, which is why it works.
What serial settings should a scanner-to-PLC link start on?
9600 baud, 8 data bits, no parity, 1 stop bit on both ends. The mismatch fingerprint is distinctive: correct length, every character wrong. If either end offers an inter-character timeout, leave it generous, because a tight timeout drops the tail of a string and shows up as lengths that change between reads.
How long can the serial cable run be?
Design to 15 m: the standard's 2500 pF load limit works out to about 15 m of typical cable at the full 20 kbit/s rate. At 9600 baud, shielded runs of 20-30 m are normally solid. Beyond that, change technology: RS-485 converters carry the same bytes roughly 1,200 m at low baud rates, and Fast Ethernet gives 100 m per hop.
The PLC holds clean data but the HMI field still shows garbage. Where is the fault?
Past the serial link. The bytes arrive correct, so check the hand-off: the field's data type against the string, the commit event that writes it, and the field's defined length, which truncates or wraps overlong strings. Frame messages with a suffix first, because a display cannot tell a stale frame from a fresh one.