USB barcode scanner on a Linux controller: serial port in Node-RED

A USB barcode scanner looks like a keyboard to most Linux systems, and that is exactly wrong when the consumer is a controller: the keystrokes go nowhere and the PLC never sees the code. Put the scanner into USB serial mode and the same device appears as a port file, /dev/ttyACM0 or /dev/ttyUSB0, that Node-RED or a PLC program can open and read one scan at a time. This guide takes you through both read paths on a Linux controller: programming the scanner, finding the port, wiring the serial in node or the PLC serial library, and proving the link with a byte-level test you can repeat after every change.

What you need

• A scanner that can be programmed to USB serial mode (also labelled COM port emulation or CDC-ACM). Most handheld scanners ship in USB keyboard (HID) mode; the mode codes sit in the interface chapter of the scanner's user guide.
• A Linux controller with a USB host port and either Node-RED or an IEC 61131-3 runtime: an edge box, an industrial PC, or a vision controller.
• A test barcode: print Hello World as a Code 128 or QR symbol.
• Ten minutes.

If you are also choosing the scanner itself, these two read USB out of the box:

The LS-CRD-0047 is a fixed reader with a 60-120 mm reading distance and a 1.2 MP sensor; the LS-HCR-0001 is a 1.0 MP handheld, and both speak USB 2.0.

Step 1: programme the scanner to USB serial mode

1. In the scanner's user guide, find the interface chapter and scan the configuration code for USB serial mode.
2. Scan the suffix code that adds CR and LF if the guide offers one. The terminator is what lets a receiver tell one scan from the next; the framing choices are covered in the prefix and suffix framing guide.
3. Unplug and replug the scanner so Linux re-enumerates it. A port a program already holds keeps the old identity until you do.

Step 2: find the port and clear permissions

Plug the scanner into the controller's USB host port and read the kernel log:

dmesg | tail

A scanner that speaks CDC-ACM registers as /dev/ttyACM0. A scanner or adapter that bridges through a USB-to-serial chip registers as /dev/ttyUSB0. If both names exist, unplug the scanner, run the command again, and the name that disappears is yours. On a single-board controller the port may need host or OTG mode first; the USB host OTG guide covers that case.

Then check permissions and prove the stream:

ls -l /dev/ttyACM0
cat /dev/ttyACM0

Substitute your port name. Scan the test barcode: the raw text should print, followed by an invisible carriage return and line feed. Ctrl+C stops the read. If cat answers Permission denied, the port belongs to the dialout group; add yourself to it with sudo usermod -aG dialout $USER, log out, and log in again.

Step 3: read the port in Node-RED

1. From the palette manager, add the serialport palette so the serial in node exists, then drop a serial in node and a debug node onto the sheet and wire them together.
2. Double-click the serial in node, name it Scanner, set the serial port to /dev/ttyACM0, and leave the line settings at 9600 8N1: the field needs a value, but a CDC-ACM port moves data at USB speed and ignores the baud number.
3. Set splitting to the character \n so each scan arrives as one message ending at the line feed.
4. Press Deploy. The node's status turns to connected, and from then on one scan produces one debug message carrying Hello World.

A few scanner families stream a binary TLV protocol instead of plain ASCII. Search the palette manager for a scanner-specific community node: the Node-RED library lists nodes that handle that framing for you, and the node's own documentation tells you which scanner families it covers.

Step 4: read the port in the PLC

Linux-based PLC runtimes reach a serial port through a COM library; where SysCom is that library, add SysCom and the settings library CmpSettings in the library manager, then:

1. Write a three-state program. State 0 opens and configures the port with the same 9600 8N1 line settings as in Step 3. State 1 reads bytes into a BYTE buffer every cycle and watches for the terminator, byte 13 or 10. A third state copies the bytes into a STRING and clears the buffer.
2. Download and start the program, then write the run flag online: SysCom example programs drive the loop with a flag such as iState, set from 0 to 1 with the online-write command (Ctrl+F7 in the IDEs that use it).
3. Restart the controller once after any change to the port settings; the new settings apply only on the restart.
4. Scan the test barcode. The STRING variable shows Hello World and the byte buffer holds the decimal values decoded in the worked example below.

Decimal-to-character is a fixed mapping, and the PLC-side byte, word and string handling is covered in the guide to storing ASCII barcode strings in PLC memory.

Worked example: Hello World arriving as 13 bytes

The inputs:

• Payload Hello World: 11 characters, 10 letters and 1 space — the test barcode.
• Terminator CR then LF, ASCII 13 and ASCII 10 — the scanner suffix scanned in Step 1.
• Character codes H = 72, e = 101, l = 108, o = 111, space = 32, W = 87, r = 114, d = 100 — the ASCII table.

The rule: one scan on the wire is payload bytes plus terminator bytes, and it reaches your program as one message only when the splitter fires on the last terminator character.

The bytes on the wire:

72 101 108 108 111 32 87 111 114 108 100 13 10

The result: Node-RED delivers one message whose payload is the 11-character string Hello World, with the 13-byte buffer behind it; the PLC byte buffer holds the same decimals, and 72 101 108 108 111 spells Hello.

The decision: 13 bytes in one message means the framing is correct. Thirteen messages of one byte each mean the splitter is off, so set it to \n. Nothing at all points to permissions or the wrong port name (Step 2). Text landing in some other window means the scanner is still in HID keyboard mode, and the HID or serial decision guide covers when each mode is the right one.

Four failures and their fixes

The serial-link half of that last row is covered in the garbage characters guide.

When USB serial is the wrong path

• Operators type into an HMI field and expect keystrokes: keep HID mode. The keyboard wedge guide covers that path.
• The controller offers RS232 only: pick a scanner with a native serial interface rather than adapting USB; the RS232 or USB guide compares the two, and the overview of scanner input methods to a PLC maps all three.
• The read point sits far from the controller or on a moving line: use an Ethernet reader and let it push each decode over TCP, as set out in the high speed conveyor guide. Ethernet code readers are in the fixed code readers category.

For a line-side install, an Ethernet reader removes the serial step entirely:

Before you hand it to production

• Mode: the scanner answers on USB serial, the CR plus LF suffix is scanned, and keystrokes are gone.
• Port: the name recorded from dmesg is pinned in the node or program, not guessed.
• Permissions: the account running Node-RED or the PLC runtime is in dialout.
• Framing: the splitter is on \n, and one scan of the test code produces one 13-byte message.
• PLC: the state machine opens the port before the read loop starts, and the controller was restarted after the last settings change.
• One consumer: Node-RED or the PLC holds the port, never both.

Where to go next

Pick hardware in the code reader finder or build the whole station in the configurator; the reader accessories category covers protective covers, mounts and light boards for the install. More controller-side integration notes sit on the systems topic page, and if the scanner-to-controller choice is still open, contact us with the controller model and the symbology you need to read.