Wiring a barcode scanner to an HMI serial port: handshake checks

A barcode scanner reads cleanly into a PC terminal, then goes dead the moment it faces the HMI's serial port, and no baud rate you try changes the result. That combination almost always convicts the cable: an HMI serial port is wired as DTE, exactly like the PC port beside it, so a lead built for a PC has to cross over before it feeds an HMI. This guide gives you the null-modem pinout that crosses the data lines, the handshake loops that satisfy a port which insists on DSR, DCD and CTS, the 9600 8-N-1 baseline with STX/ETX framing, and a three-test ladder that puts the fault on the scanner, the cable or the HMI in a few minutes.

Why does a scanner that works on a PC show nothing on the HMI?

In almost every case the scanner is sending and the HMI is listening, but the cable between them is wired straight through: an HMI serial port is DTE just like a PC port, so the scanner's transmit pin lands on the HMI's transmit pin instead of its receive pin.

On a DB9 wired as DTE, pin 3 is the transmitter output and pin 2 is the receiver input. Scanners are DTE too, because their cables are built to plug into a PC. Connect two DTE ends through a straight-through cable and each side drives its signal into the other side's transmitter: the scanner talks on pin 3, the HMI listens on pin 2, and not one character arrives. No setting fixes that, because the bytes never reach a receiver.

The plug genders are what make the fault stick. A male DB9 on the machine and a female plug on the scanner lead mate perfectly, the port configures cleanly, and everything works everywhere except the one link that matters. Keep the gender changer for fitting the plugs; the crossing has to happen in the wiring.

If the HMI also accepts USB HID input, a USB scanner in keyboard mode skips the serial wiring entirely. The serial port stays the better choice when the decode must land in one specific object, on demand, every cycle.

Which pins does a null-modem cable cross?

The full-handshake null-modem lead crosses pins 2 and 3, crosses 7 and 8, carries each end's pin 4 over to pins 6 and 1 at the other end, and runs pin 5 straight through, which satisfies every input a DTE checks before it accepts characters.

That pin set is the full-handshaking null modem, the standard variant for joining two DTEs; Wikipedia's null modem page draws the same figure. Build it when you do not yet know which handshake inputs the HMI's serial driver checks. For the scanner end, follow the reader manual's own PC-connection diagram; when both manuals say their device connects to a PC port, you have two DTEs and this lead is the answer.

Two build details matter more than they look: make pin 5 the first joint and take every measurement against it, and use shielded cable. Any multi-core shielded cable from the cables category carries RS-232 levels at scanner speeds; the pinout decides the result, not the cable's product name.

For a lead you terminate yourself, a DB9 female-to-open cable keeps both ends landable while you work:

What do the handshake lines do, and when can you loop them back?

DSR, DCD and CTS are inputs the HMI reads to confirm the far end is present and willing to receive; if the scanner ignores them, loop each end's outputs to its own inputs (4 to 6 and 1, 7 to 8) so the port sees a ready partner.

DTR and RTS are the HMI's outputs: DTR announces the port is open and powered, RTS announces receive-buffer room. DSR, DCD and CTS are its inputs. Some serial drivers will not open a port, or will ignore characters, until DSR or DCD reads asserted, and drivers set to hardware flow control hold off until CTS asserts. The full null modem carries each end's outputs across to the other end's inputs, which is why the table above wires pin 4 over to pins 6 and 1 and crosses 7 with 8.

Plenty of readers run as three-wire devices: TX, RX and ground, with the handshake outputs idle. For those, build the loopback version instead: at each end of the lead, jumper pins 1, 4 and 6 together, and jumper 7 to 8. The port sees its own asserted outputs echoed back, decides a partner is present, and opens at once. Looping flow control is harmless for a scanner, because a scan delivers one short string rather than a stream; the arithmetic in the next section shows the margin.

To read handshake state without a scope, measure from pin 5 to the pin in question with a multimeter: an asserted control line sits a few volts positive, a released one sits negative. The FAQ below gives the standard's voltage bands.

Which serial settings and framing must match before you touch the cable?

Match the port numbers first: 9600 baud, 8 data bits, no parity and 1 stop bit on both ends, plus the reader's preamble STX and postamble ETX, because a settings mismatch produces garbage characters while a framing mismatch produces a clean terminal stream that the input object never commits.

Set both ends to 9600 baud, 8 data bits, no parity, 1 stop bit first; most scanners and most HMI auxiliary ports leave the factory that way, and you change a number only when the reader manual says so. The failure signature then splits the causes for you: a baud, parity or stop-bit mismatch pours repeated garbage characters into whatever will listen, while a correct link with wrong framing leaves a clean string in a terminal and an empty input object. The garbage version is the PLC serial link repair fault, and its fix is the same: identical numbers at both ends.

Framing comes next. Set the reader's preamble to STX (hex 02) and its postamble to ETX (hex 03), and set the same terminator where the HMI's input object commits. Some objects commit on CR or LF instead; either is fine as long as the pair matches. The HMI serial framing guide walks the commit path end to end, prefix and suffix framing covers the reader side, and CR and LF handling matters when the destination is a plain text field.

One more screen while you are in the project: the input object must take characters from the serial device rather than the on-screen keypad, and it must hold focus when the scan fires. On most HMIs that means tapping the field once or enabling a focus-at-load setting on the object.

How do you isolate the fault to the scanner, the cable or the HMI?

Test the three corners in pairs: the scanner into a PC terminal, the PC into the HMI, then the scanner into the HMI, because when the first two pairs pass and the third fails, the only untested part is the cable and its pinout is the fault.

A 14-character scan is on the wire for about 15 ms at 9600 baud, so a working link prints the string in a terminal the instant the reader beeps; silence at a correct baud rate is wiring or handshake, never timing. Looped flow control cannot lose data here either: a reader holding a 1 kB buffer against a closed CTS would need 1024 / 960 ≈ 1.1 s of continuous scanning to overflow it, and a scan sends 14 characters. When the string also has to reach a controller on a production schedule, the scan-to-flag latency guide budgets the rest of the path.

Run the ladder in this order; the first two items account for most dead HMI ports:

1. TX and RX not crossed. The scanner prints into a PC terminal, the PC commits into the HMI's object, and the scanner into the HMI shows nothing. The cable is the only untested part left, so land the pinout from the table above.
2. Handshake inputs unsatisfied. The port refuses to open, or ignores characters that a terminal receives. Confirm with the multimeter method above, or fit the loopback jumpers.
3. Baud, parity or stop bits mismatched. You get garbage, not silence. Capture in a terminal at each candidate rate until the string reads clean, then set the HMI to the same numbers, starting from 9600 8-N-1.
4. Framing or focus missing. The terminal sees the string and the object stays empty. Check that preamble and terminator match on both ends, and that the object holds focus at scan time.
5. Port already assigned. An HMI locks a serial port to one function, so a port booked for a printer or a tool protocol never serves the scanner. Read the assignment in the project; if the controller's own ports are the constraint, the read-through-the-HMI guide shows the detour.
6. The reader never fires. No beep and no read light point at power or trigger wiring, not serial. Aim at a code, watch the indicator, then work through the trigger mode guide and the silent serial trigger diagnosis.

When the string's destination is a PLC serial port instead of an HMI, the same ladder applies, and a CompactLogix serial-port ASCII read guide covers the controller side of that link.

How long can an RS-232 scanner cable run?

Keep the serial lead at or under 15 m, the length the RS-232 standard specifies alongside its 20 kbit/s ceiling, which a 9600 baud scan string uses only in small part; longer runs fail through line capacitance rather than distance, so treat 15 m as the design limit.

The 15 m figure is not folklore: the RS-232 standard pairs it with a 20 kbit/s ceiling and bounds the line's load capacitance at 2500 pF. A 9600 baud scan string uses under half that rate, so the limit is comfortable. Long runs fail through capacitance before they fail through distance, which is why a thin 25 m lead drops characters that a well-made 15 m lead would carry without effort. Design to 15 m and the question closes.

Build the run for the panel, not the bench: shielded cable with the drain grounded at one end, hood screws tight at both ends, and the lead routed away from drive and motor cables. Interference at these speeds corrupts characters rather than removing them, so a noise problem presents as the garbage-character fault above, not as silence.

What belongs in the panel for the next commissioning?

Stock a null-modem adapter, a loopback adapter jumpered 1-4-6 and 7-8, a gender changer and a spare DB9 flying-lead cable, and tape the tested pinout and port settings inside the panel door, because this fault returns whenever someone builds a fresh cable on shift.

Four adapters and one sheet of paper prevent the repeat: a null-modem adapter, a loopback adapter jumpered 1-4-6 and 7-8, a DB9 gender changer, a spare flying-lead cable, and the tested pinout plus port settings taped inside the panel door. Label the lead at both ends as scanner-to-HMI, crossed, so the next person does not helpfully straighten it out.

If you are specifying the station rather than repairing it, choose hardware that talks the way the machine does. A fixed reader with a serial interface lands on exactly this lead; the MV-ID6200PM-00C-NNG is a 20 MP logistics code reader with a serial interface, and the fixed code readers page filters by interface, so serial models shortlist in one pass. Where the reader feeds a controller instead of an HMI, the input methods comparison weighs serial against USB and Ethernet.

For a new station, the system configurator walks camera, reader, cables and accessories in order. Free expert support with every order means you can send the scanner model and the HMI port type through the contact page and have the pinout checked against the reader manual before the lead is soldered.