Every serial port on the PLC is spoken for, the cabinet is built, and the barcode reader still has to deliver its string into the control system. You have two routes that need no new rack hardware: capture the read at the HMI through a string input that always holds focus, then hand the string from HMI memory to a PLC register, or free one PLC port by moving an existing device onto a network or expansion card and receive the string in ladder. This guide gives you the decision rule between the two routes, the set-up steps for each, the serial framing numbers that make the link reliable, and the test that proves no scan is being missed.
Pick the route before you touch a wire
A keyboard-wedge reader behaves like a keyboard: its characters land in whatever input field holds focus on the HMI, and a field only exists while its screen is displayed. That single fact decides the route. If an operator stands at the HMI and each scan is part of a person's task—part-number entry at changeover, kit verification, rework logging—HMI capture is enough and costs no PLC changes. If the PLC must act on every scan with nobody watching—reject gating, diverting, batch counting—the capture has to live in the ladder, so free a port or move the string onto the network.
The routes also fail differently. A scan that arrives while the wrong screen is up, or while a popup owns the focus, is not queued anywhere: the HMI route fails silently. A serial receive in the PLC lands in a buffer your ladder drains scan by scan, so a lost handshake becomes an alarm you can see. Operator-paced entry takes the HMI route; autonomous decisions take the PLC route. If the reader purchase is still open, a third option—an Ethernet-output reader—removes the serial-port problem entirely.
Route A: capture the read through the HMI
What you need:
- A barcode reader with an RS-232 output, or a USB keyboard-wedge reader if the HMI has a spare USB host port
- A second serial port on the HMI, the one not used for the PLC link
- A string input widget bound to a 50-100 character tag
- A sheet object that can be applied to every screen
Wire and size the link
-
Connect the reader to the HMI's second serial port and set that port to the reader's defaults—most readers ship at 9,600 baud, 8 data bits, no parity, 1 stop bit. If the two disagree, change the reader, not the HMI. A port that receives nothing usually has TX and RX uncrossed: check the cable drawing before blaming the settings. Set the reader's suffix to CR so every scan ends the same way, as the prefix and suffix framing article shows, and match whatever header the string input expects; the HMI serial port framing guide covers that side. The barcode reader serial setup for an HMI walkthrough covers this exact port configuration step by step.
-
Size the string tag to the longest string the reader can deliver plus the terminator. A 13-digit EAN-13 with CR is 14 characters; Code 128 shipping labels usually land between 20 and 30 characters; a dense 2D code can exceed 100. A 50-character tag covers line-side linear labels, 100 if 2D codes are in play. Larger tags only consume string memory, so size for the longest label you actually print.
-
Decide where the string lands. If the HMI's string input can address a PLC register directly, point it there: no copy step, and the PLC sees each scan exactly once. If it only writes HMI-local string memory, copy to the PLC on the input's completion event and raise a new-data bit the ladder acknowledges and clears. The register handshake pattern from sending vision coordinates to a PLC works unchanged for a string and a bit.
Keep the field alive on every screen
-
Place the string input on a sheet and apply that sheet to every screen, then hide it with the control flag so operators never see it. The field must still exist and hold focus on whatever screen is displayed. Enable the HMI's auto-focus option for the first input on a displayed screen where it exists; where the macro set exposes a focus instruction, call it after every screen change with the field's number—SETFOCUS(n) on panels that name it that way. The keyboard wedge focus behaviour article explains why focus decides whether a scan is captured, and the serial barcode reader configuration walkthrough for a panel HMI covers the same wiring and field set-up on one screen.
-
Remove the Enter key from the workflow. Configure the reader to end every transmission with its suffix, then look for the string input's auto-commit option—many panels accept the terminator as confirmation. Where the option does not exist, a macro on the port's receive event commits the string instead; leaving Enter in place caps the station at operator typing speed. The CR and LF characters in an HMI text field article shows what those trailing characters do inside an input field.
If the HMI has a spare USB host port, a keyboard-wedge reader does the same job with no serial settings: it types into the focused field exactly like a serial wedge. The choice between HID keyboard mode and a serial port on a panel HMI is compared in USB barcode scanner on a PLC HMI, the wedge set-up lives in USB barcode scanner as a keyboard wedge, and the classic fault where only the first character arrives is fixed in USB barcode scanner sends only one character. For a station reader in this mode, the LS-CRD-0047 captures 1.2 MP images over USB 2.0 at a 60-120 mm reading distance.
- Resolution
- Up to 3 MP
- Shutter
- Global
- Interface
- USB
Prove the capture survives a shift
- Test the set-up the way a shift would run it:
- Scan on every screen the operators use, including maintenance and manual-mode screens.
- Raise an alarm or popup and scan while it is up; the string must still arrive.
- Power-cycle the HMI and scan without touching anything: focus must land on the field by itself on the boot screen.
- Scan the longest label you print and check the PLC-side string for truncation.
- Unplug and replug the reader, then scan: the port must recover without a reboot.
Then count scans against PLC receptions across a full shift. A count mismatch is the silent miss made visible.
Route B: free one PLC port and receive in ladder
-
Count what you have: the CPU's built-in serial port or ports, plus any free slot for a serial or communication board. The device worth moving is usually the HMI—it already speaks the PLC's network protocol, so it can sit on a network interface card or an expansion serial board instead of the CPU port. That frees the port for the reader at the cost of some re-addressing.
-
If a rack slot is free, add a serial communication board and leave every existing device where it is. This is the cleanest fix when the CPU supports one.
-
Configure the receive: start and end delimiters, a maximum length, and a done bit per reception. Before you build the panel around it, confirm the CPU family has a serial receive instruction—an RXD-style instruction with delimiter settings on most mid-range families. A few compact and older families leave the framing to an option module instead, which changes the parts list but not the plan.
-
Write the ladder side: drain the buffer every scan, store the payload to a string or byte array—the ASCII barcode strings in PLC memory article covers bytes, words and clears—compare it against the recipe list, and acknowledge the done bit. The plan for a link you can trust, handshake, timeouts and no-read handling included, is in barcode reader PLC communication; the interface options into a PLC are compared in barcode scanner input methods to a PLC.
-
Trigger the reader the way the line runs: free-run on continuously present parts, or sensor-trigger from a photoelectric input wired through the reader's code reader accessories. The fixed barcode reader trigger modes article compares sensor, serial and free-run triggering.
The framing numbers behind either route
Asynchronous serial spends 10 bits on every character—1 start, 8 data, 1 stop—so the wire time is easy to predict:
Worked example: a Code 128 label with a 24-character payload plus a CR terminator is 25 characters. At 9,600 baud: 25 × 10 = 250 bits, and 250 / 9,600 = 26 ms on the wire. At 57,600 baud the same string takes 250 / 57,600 = 4.3 ms. A port reading once per second at 9,600 baud is busy 26 ms out of every 1,000 ms, or 2.6% of the cycle—the wire is never the bottleneck, buffer handling is. Size the receive buffer to the string plus terminator (32 characters covers the linear labels above) and drain it every scan. On the HMI route the same numbers say the serial side is instant; the constraint there is focus, not bandwidth.
Which route wins where
| HMI string-input capture | PLC serial receive | Ethernet-output reader | |
|---|---|---|---|
| PLC changes | None, or one register | Port freed, receive ladder | Network card plus sockets |
| Captures | Only while the field's screen shows and holds focus | Every scan | Every scan |
| Missed scan | Silent | Done-bit timeout, alarmable | Link error, alarmable |
| Enter key | Removed with suffix and auto-commit | Not applicable | Not applicable |
| Best for | Operator-paced entry at a fixed screen | Autonomous per-part decisions | New installs with a spare drop |
The decision per case: an operator confirming parts at a screen that stays on one page takes Route A with the shared sheet. A reject or divert gate with no operator takes Route B. A station you are wiring from scratch with a spare network drop takes the Ethernet reader, with strings read straight over TCP—the raw TCP sockets route shows a PLC receiving them without any serial port.
For that third case, choose a reader that speaks Ethernet out of the box:
- Interface
- Fast Ethernet
- Resolution
- 5 MP
- Interface
- Fast Ethernet
- Resolution
- Up to 3 MP
- Interface
- GigE
- Resolution
- 6-10 MP
The LS-CRD-0028 pairs a 2560 x 2048 sensor with 60 codes/s over Fast Ethernet; the MV-ID3013PM-12M-WBN adds a fixed 12 mm lens in a compact housing; the MV-IDS006M-12C-C steps up to GigE for heavier traffic.
Common mistakes that swallow scans
- Testing capture only on the commissioning screen. The failure appears on the screens nobody tested, so scan on every screen.
- Leaving two string inputs live on one screen. The reader types into whichever grabbed focus last; keep exactly one capture field per displayed screen.
- Free-running the reader at line rate with no handshake. Without per-part triggering and a done bit, the buffer overruns between reads.
- Sizing the string tag to the shortest code you print. A truncated 2D payload arrives as garbage at the PLC; size for the longest label.
- Keeping the Enter key and calling it operator confirmation. It caps throughput at typing speed and gets skipped under pressure.
- Assuming an ASCII module is the only fix for full ports. A moved HMI link, an added serial board or an Ethernet-output reader each solve it without hunting used cards.
Next step
Sort the route first, then the hardware: the HMI route needs only a reader and a configured field, the PLC route one freed port, the new station an Ethernet reader and a drop. Pick from the fixed code readers, filter by interface in the code reader finder, or start the system configurator and we will match the reader, the trigger wiring and the string path to your PLC—every order includes free expert support. More string-handling set-ups live on the code-reading topic page, and for an unusual PLC or HMI family the contact page reaches the applications team.
Questions
Does a hidden HMI string input still capture barcode scans?
Usually yes: the control flag that hides a field stops it being drawn, not the serial port from feeding it. Capture follows focus, not visibility. The exception is an HMI that pulls focus away from a hidden field automatically. If yours does, keep the field on the shared sheet but place it where operators never look, or set focus with a macro after each screen change. Test every screen before you trust it.
Can the HMI make the pass or fail decision instead of the PLC?
It can, but keep the decision in the PLC. An HMI script can compare a string against a list and show pass or fail, yet display-layer logic is invisible to the ladder, hard to monitor over a network, and gone if the screen project changes. Use the HMI to capture and display the string, and let the PLC own gating, rejecting and counting decisions.
Can the HMI write the barcode string straight into a PLC register?
Many HMI string inputs can address a PLC string register directly, which is the cleaner path: no copy step, and the PLC sees each scan exactly once. If your panel only writes HMI-local string memory, copy on the input's completion event, not on a free-running timer—a timer re-sends the same string until the next scan, so the PLC cannot tell new from old. Pair every copy with a new-data bit the ladder acknowledges and clears.
Why does the barcode reach the HMI only when that screen is open?
A keyboard-wedge reader acts like a keyboard: its characters go to whatever input holds focus, and focus belongs to the displayed screen. With the capture screen closed there is no focused field, so the scan goes nowhere and nothing records it—not even an error. The shared sheet with the string field on every screen, plus a focus set after each screen change, closes that hole.
Do I have to press Enter after every scan?
Only if the panel commits its string input on the Enter key. Set the reader's suffix to a terminator such as CR and look for the input's auto-commit-on-suffix option; many HMIs accept the terminator as confirmation. Step 5 of the walk-through covers the macro-based fallback. Leaving Enter in place caps the station at operator typing speed.
Is HMI capture reliable enough to drive an automatic reject?
No. Focus is a screen state: an alarm popup, a screen change or a second input can swallow a scan without any error, and an automatic reject must never depend on a display. Receive the string in the PLC over a freed serial port or an Ethernet link, where each scan lands in a ladder-drained buffer. Keep HMI capture for operator-paced entries such as changeover part-number selection.



