Read a serial barcode scanner over TCP to PC software

Your RS232 barcode scanner already reads, your IEC 61131-3 controller holds the digital I/O for triggers and pass lamps, and the decoded strings must reach PC software over the network. Keep all three. Put a serial-to-TCP passthrough function block on the controller: it forwards every character between the scanner's COM port and a TCP port you choose, so the controller keeps the wiring while your PC opens the socket. This guide gives you the serial line budget with the arithmetic shown, the block set-up step by step, and both ways for the PC to read the scan: raw socket or virtual COM port. It ends with the bench tests and the point at which an Ethernet code reader is the simpler machine.

How the serial-to-TCP tunnel works

The controller owns the COM port and the passthrough block owns the exchange. Every program cycle, the block moves characters from the serial receive buffer into a TCP connection, and characters arriving on that connection go back out of the COM port. Your PC connects to the controller's IP address on the assigned TCP port — port 1000 is the usual example — and reads the decode strings as a byte stream. The scanner, its cable and the controller's I/O wiring do not change.

Vendors name the block differently, so open your runtime's library and find the data-stream exchange block documented for COM-to-TCP forwarding. Its inputs set the COM port, the TCP port number and the buffer length; its outputs report connection state and character counts. Call it unconditionally every scan so a partially received message waits in the buffer instead of vanishing between calls.

The digital I/O stays yours. A photoelectric sensor into a digital input still triggers the scanner, and an output still drives the pass lamp. If the plant wants trigger and result status as well, expose it over Modbus TCP on its standard port 502 or through your own message protocol; the tunnel occupies only the serial line and the one TCP port you assigned. And if the arrangement should run the other way — the PLC consuming the scans as a TCP client — that design is set out in barcode reader to PLC over raw TCP sockets.

What you need

• An RS232 barcode scanner whose suffix and trigger you can configure; the standard configuration code sets baud, suffix and trigger mode in one scan.
• An IEC 61131-3 controller with a free RS232 COM port, an Ethernet port, and the vendor's serial exchange block in its library.
• A switched Ethernet segment where the PC and controller can talk on your chosen TCP port.
• PC software that reads bytes from a socket, or a virtual serial port driver that maps the tunneled port to a local COM name.
• A DB9 female-to-open serial cable for the scanner side. Such a lead gives you bare conductors for TX, RX and signal ground, and the 7 m cable below reaches a panel-mounted controller from a bracket-mounted scanner.

Wire transmit to receive in both directions and join the grounds. A swapped pair is the classic first fault, and it behaves exactly like the garbage characters from a barcode scanner described for PLC serial links.

Plan the serial line budget

The serial line, not the network, sets how fast the tunnel can deliver scans. With 8N1 framing, each character travels as 10 bits — one start, eight data, one stop. A 20-character decode string plus a CR and an LF is therefore 22 characters, or 220 bits, per scan.

Worked example — a Code 39 label decoding to 20 characters, suffix CR plus LF, scanner and controller at 9600 baud 8N1:

• Bits per scan: 22 × 10 = 220 bits.
• Line time per scan: 220 ÷ 9600 = 22.9 ms.
• Maximum scan rate: 9600 ÷ 220 = 43.6 scans per second.
• At 30 scans per second: 30 × 220 ÷ 9600 = 68.8% line use. Workable, with little headroom.
• At 45 scans per second: 45 × 220 = 9900 bit/s against a 9600 bit/s line. The line overruns and message tails are lost. Set both ends to 19200 baud: 9900 ÷ 19200 = 51.6% use. At 115200 baud the same traffic is 5.7%.

The network side is not the constraint: on a switched 100 Mbit/s LAN a frame forwards in microseconds, so the tunnel adds well under a millisecond against 22.9 ms of serial line time. Where the scan must become a PLC flag inside a fixed time, the wider budget is worked through in cutting serial scan-to-flag latency.

Build the tunnel on the controller

1. In the runtime's function-block library, locate the serial data-exchange block documented for COM-to-TCP forwarding. Note its input names for the COM port, the TCP port and the buffer length, and its status outputs.
2. Assign the free RS232 port and set the line settings from the budget: for the example, 9600 baud, 8 data bits, no parity, 1 stop bit, handshake off. Set the scanner to match with its configuration code.
3. Assign a TCP port the runtime does not already use — 1000 is a common choice. Leave service ports such as 502 for Modbus TCP to the services that own them.
4. Size the character buffer above the longest possible message. 128 characters is generous for a 22-character scan and leaves room for a long Code 128 string plus suffix; treat that figure as illustrative and pick from your longest real decode.
5. Call the block unconditionally every program scan. A conditional call silently drops the serial bytes that arrive while the block is skipped.
6. Leave the trigger and output logic untouched, give the controller a static IP address, and download the program.

Read the scan in PC software

Raw TCP socket. Open a client connection to the controller's IP address on the assigned port, read bytes, and split messages on the suffix. The example below is illustrative, uses only the standard socket library, and shows HOST and PORT as your values:

# Illustrative: standard-library sockets only, Python 3.
import socket

HOST = "192.168.1.50"   # controller IP address (your value)
PORT = 1000             # TCP port assigned to the passthrough block
READ = 256              # bytes per read call, integer

sock = socket.create_connection((HOST, PORT), timeout=2.0)
pending = ""            # string buffer for partial messages
while True:
    data = sock.recv(READ).decode("ascii", errors="replace")
    if not data:
        break                       # connection closed by the controller
    pending += data
    while "\r\n" in pending:        # scanner suffix: match your configuration
        line, pending = pending.split("\r\n", 1)
        print(line)                 # one decoded barcode per scan

The test that proves the path: scan a test label encoding AB-1234-56 and the console prints AB-1234-56 once per scan, with nothing printed between scans.

Virtual COM port. A virtual serial port driver on the PC maps the controller's IP address and TCP port to a local COM name, so existing serial-reading software opens it unchanged. The line settings already live at the controller's COM port; the virtual port only moves bytes, so the baud value in the PC application is ignored. Suffix handling stays exactly where it was in your software.

Where the software runs. If the decode application belongs on the machine rather than in an office PC, host it on a vision controller next to the line. The MV-VC2140-128G40-1T, for example, carries an Intel N-series processor, 8 GB of memory and several LAN ports, so the tunnel and the plant link can sit on different ports.

Verify before you go live

1. Ping the controller from the PC, then confirm the firewall on each machine allows your chosen TCP port in both directions — the same pairing described for a vision controller to PLC TCP link.
2. From a terminal utility on the PC, open a raw connection to the controller's IP address and TCP port, then scan a test label. The characters and suffix appear immediately.
3. Type a few characters in the terminal and confirm they leave the COM port; a second scanner or a serial monitor on the bench shows them. Both directions are now proven before any application code is involved.
4. Run the real software or the virtual COM mapping at your fastest production cadence. At 30 scans per second on 9600 baud you sit at 68.8% line use, so truncated messages mean the budget is spent — raise the baud at both ends.
5. Soak test a full shift with reconnect logic armed: the PC application must detect a dropped socket and reconnect without operator action.

Common mistakes, in the order they usually appear:

• Two applications connected at once: the tunnel carries one character stream, so two clients split the messages between them. Assign one client.
• Handshake enabled with no control lines wired: the port waits forever. Turn handshake off unless the scanner's manual requires it.
• Buffer below the longest message: tails are cut. Size it once, generously.
• No suffix configured: back-to-back scans concatenate into one long line in the PC buffer.
• Baud mismatch: the TCP side looks healthy while every serial character is garbled.

When to skip the tunnel

If you are specifying hardware for a new station rather than reusing a serial scanner, an Ethernet code reader removes the whole chain: one standard Ethernet cable run from the reader to the switch, the PC or PLC as a network client, trigger and result I/O in the reader or on the network, and no serial line budget at all. The MV-ID3013PM-12M-WBN, for example, is a compact 1.3 MP code reader with a Fast Ethernet interface and a 12 mm focal length.

The decision, case by case:

• Serial scanner you already own and trust, controller I/O needed in the same program: build the tunnel. It costs one library block and an afternoon of bench tests.
• New station: specify an Ethernet reader from the fixed code readers range — the code reader finder filters by interface and resolution — and the serial problem never exists.
• Decode software that must run on the machine: host it on a vision controller and keep whichever scanner path fits.

Whichever branch you take, the checks are identical: one client on the port, matched line settings, a buffer above the longest message, and a full-shift soak test. The cables category covers the serial and Ethernet leads and the accessories finder lists them by length, while the system configurator steps through a camera-to-controller build. More integration patterns for scanners, controllers and networks sit in the systems guides, and if your controller's runtime has no COM-to-TCP block, contact the applications team with what you are running.