Share one PLC RS232 port between a scanner and a label printer

Your controller has one free RS232 port and the station now needs two serial devices: a barcode scanner sending order numbers in, and a thermal label printer taking finished labels out. A second port module is not always an option — on compact controllers that slot is often already filled by the network adapter. The escape is built into the port itself: RS232 is full duplex, with a dedicated conductor for each direction, and a scanner only talks while a printer can be set to only listen. Below is the pin split, the single serial format both devices must share, the byte timing to check against your cycle, and the faults that appear when a printer answers back.

Can one RS232 PLC port serve a scanner and a printer at once?

Yes: wire the scanner TX to the PLC RX, the PLC TX to the printer RX, and signal ground to both, and the two devices never share a conductor because RS232 is full duplex.

A port carries three signals that matter here: TX, where the PLC transmits; RX, where the PLC receives; and signal ground. The rule that makes the split safe is one driver per line. The PLC drives TX and nothing else does, the scanner drives its own TX into the PLC RX, and the printer TX stays unconnected. The scanner owns the inbound line, the printer owns the outbound line, and the only thing they share is ground.

The single-device procedures still apply on each leg: wire a barcode scanner RS232 ASCII string into a PLC serial port for the receive side, and send ASCII label data from a PLC serial port to a barcode printer for the print side. You are giving each of those guides one conductor of the same physical connector, nothing more.

Which pins go to which device?

On a DB9 PLC port, TX is pin 3, RX is pin 2 and signal ground is pin 5: PLC pin 3 to the printer RX, scanner TX to PLC pin 2, and pin 5 to both devices.

If the port is an RJ-style jack the numbers move — pull the TX, RX and GND positions from the controller serial manual before crimping; wiring an RS232 scanner to a PLC RJ12 jack shows that lookup on one common jack style, and a scanner pinout wired to a PLC serial port shows the DB-style equivalent on a controller channel.

Read every signal name from the device that drives it: PLC TX meets printer RX, scanner TX meets PLC RX. You are building half of a null modem to each device, so add no crossover adapter anywhere — the cross lives in your junction. For the run itself use a multiconductor cable with a bare end at the junction side; the LS-CBL-0300 is an M8 8-pin power and I/O cable with an open 8-core end, 7 m long and rated for drag-chain use, so TX, RX and ground still leave spares.

Browse power and I/O cables or the accessories finder for other conductor counts and lengths.

What serial settings must both devices share?

Both devices must run exactly 9600 baud, 8 data bits, no parity, 1 stop bit — the classic scanner and printer default — and both must also keep flow control and status replies switched off.

One physical port has one baud generator and one framing setting, so the scanner and the printer must match it exactly. Configure the scanner first, through its configuration barcodes or utility: RS232 host interface, that same 8-N-1 line, suffix CR + LF, no host acknowledgment expected. Configure the printer from its panel or utility to the same line, hardware and software flow control off, automatic status replies off — that silence is what keeps its TX line dead.

A mismatch of even one parameter fills the PLC buffer with wrong characters instead of ASCII; garbage characters from a barcode scanner on a PLC serial link lists the combinations to walk down.

How do you wire and configure the shared port?

Power everything down, land three conductors — PLC TX to printer RX, scanner TX to PLC RX, ground to both — configure the port once to the shared format, then test each direction alone before running both together.

1. Set the scanner: RS232 host interface, the shared 8-N-1 line, suffix CR + LF, beeper local, no acknowledgment expected from the host.
2. Set the printer: the same line, hardware and software flow control off, status and error replies off.
3. With all power off, wire PLC TX to printer RX, scanner TX to PLC RX and signal ground to both; leave every handshake pin open at both devices.
4. Configure the PLC port once to the same settings, through its protocol or serial port functions: one receive rule that frames on CR/LF for scanner strings, one transmit block that streams the label text.
5. Test the scanner alone: scan a code and confirm the receive buffer holds a clean ASCII string ending in CR/LF.
6. Test the printer alone: send one label and confirm it prints exactly once, with no stray characters.
7. Run both: trigger a scan while a label is mid-transmission and confirm the received string is identical to the quiet test.

Pass criteria: scanner strings identical with and without printing in progress, and printed label count equal to trigger count. If the label is more than plain text, preview the layout in an online label renderer for your printer command language before committing it to PLC code — catching a layout error there costs minutes instead of labels.

How fast are a scan and a label on the shared port?

At 9600 baud and 8-N-1 a 14-character scan takes about 15 ms and a 300-character label about 313 ms, and because they ride opposite conductors the two transfers overlap instead of adding.

Say the operator scans a 12-character order number and the label repeats that number plus a measured length. With CR and LF the inbound string is 14 characters = 140 bits; 140 / 9600 = 0.0146 s, about 15 ms. The label with its command framing runs roughly 300 characters = 3000 bits; 3000 / 9600 = 0.3125 s, about 313 ms. Add one PLC scan for handling, say 10 ms, and the exchange closes under 340 ms — comfortable inside a 1 s station cycle.

Commit to that speed while the label stays under about 500 characters and the cycle allows half a second of print time, since 500 × 10 / 9600 = 0.52 s. Move both devices to 115200 when labels grow past that or the cycle tightens below 500 ms.

Why do you get garbage characters once both devices are connected?

Two drivers on one RX line, or one device at the wrong baud, produce the garbage — isolate it by lifting the printer TX conductor and rescanning, because a printer that cannot reach the RX line cannot corrupt a scanner string.

Work the causes in this order. First, a ready-made serial printer cable wires every pin: if you used one, its TX conductor is feeding the PLC RX alongside the scanner, so cut that conductor or land only the three signals you need. Second, a device that reset to factory defaults no longer matches the shared line; recheck both. Third, the receive framing itself: if the buffer shows several scans glued together or a label fragment, ASCII barcode data framing in the PLC receive buffer covers terminators and buffer handling, and a barcode reader sending no data to the PLC COM port covers the silent case.

When does the shared-port wiring fail?

It fails when the printer must answer back on a return line — handshaking, acknowledgments or busy status — or when a scanner locked to the low speed meets a 115200-only printer; the fix then is a second port or an RS485 converter, not wiring.

The specific dead ends:

• The printer refuses data until a handshake line is asserted, and it has no no-handshake mode.
• You need the printer acknowledgment after each label; sharing the RX conductor interleaves two streams in one buffer.
• The two devices support no common speed.
• The printer sits on a different machine with its own supply, so ground offset corrupts a single-ended link.

The fix in every case is a differential bus or more ports: wire an RS232 scanner through an RS485 converter for distance and noise immunity, or put multiple barcode printers on one RS485 multidrop when the device count grows.

What should you check before ordering the cable and scanner?

Before ordering, confirm five things: a scanner with a true RS232 output, a printer that can be silenced, one common serial format, enough conductors for three signals, and a total run inside the 15 m classical limit for RS232 at this speed.

• Scanner interface: an RS232 host mode with a programmable CR/LF suffix. A USB-only handheld types into a PC-class host as a keyboard and cannot sit on a COM port, so filter handheld code readers by interface before shortlisting.
• Printer behavior: flow control and automatic status replies both switchable off in the menu tree.
• Common format: the shared 8-N-1 line set on both devices and written on the cabinet card.
• Conductors: an 8-core cable with an open end carries TX, RX and ground with room to spare.
• Grounding: scanner, printer and PLC on one machine ground, total run under about 15 m.

If handheld scanning is the bottleneck rather than the port, change the station instead: the MV-ID6200PM-00C-NNG is a 20 MP logistics code reader with a Serial interface and a C-mount, mounted over the conveyor and feeding the same COM wiring.

When the station grows, the code-reading topic page collects the scanner, printer and PLC serial guides in one place, and the cabling step of the system configurator bundles these cables into a full vision build. For a pinout check on a specific controller jack, use the contact page and name the controller family and port.