A USB barcode scanner sends an HMI a barcode as keystrokes, and the entry field must be selected on screen before every scan. Plan the workflow around that touch step, size the destination for the longest label plus 1 or 2 suffix characters, and use a simple rate test to decide between the standard entry field, a dedicated scan screen and a serial input.
Yes, a USB barcode scanner feeds a barcode straight into an HMI, with one condition: the text entry field has to be the active object on screen before the trigger is pulled. The scanner types. Its characters arrive as keystrokes, they land in whichever field the panel considers active, and a terminator character the scanner appends closes the entry. That behavior decides two parts of the job: the operator's cycle (select, scan, confirm) and the project (a destination long enough for the longest label plus its suffix). The editor steps for the text entry object itself are in the USB barcode scanner setup for an HMI text entry object. This page sizes the string, times the touch step, and gives the rate bands that decide whether the standard build fits your station.
What the scanner sends over USB
In keyboard wedge mode the scanner presents itself to the panel as a keyboard: each decoded character goes out as a keystroke. Scanner manuals cover the output mode first: it is a setting in the reader's own configuration, set by scanning a programming barcode or through the vendor's configuration tool. The output mode is a scanner setting, not a panel setting.
The second scanner-side setting is the suffix. Most wedge scanners can append a terminator after every scan, and the usual choice is a carriage return, which acts as the Enter key; scanner manuals document the suffix setting under the keyboard wedge or USB HID output section. Count the suffix in the string size: a carriage return is 1 character, carriage return plus line feed is 2. Some quick-start cards bundle the suffix with a defaults reset in one programming barcode, so scan that card before the rest of your settings, or use the suffix-only code if the manual offers one.
The select step that decides the workflow
A wedge scanner has no idea what is on the screen. It types, and characters land in the focused field exactly as they would from a keyboard, so a screen with nothing selected swallows the scan. The working cycle at the bench is: touch the entry field, pull the trigger, read back the value. Until your project tests otherwise, assume the field must be selected again for every scan.
Lay the screen out for that cycle. Put the entry field where the operator's hand already rests, size the target for a gloved tap, and show the last accepted scan as read-back text so the operator confirms without leaning in. This level of station planning sits inside planning a touchscreen operator interface for factory controls. If taps register late or redraws crawl, the cycle stretches and mis-scans climb; fixing a slow HMI panel's touch and screen updates sorts a sluggish panel from a workflow problem.
What you need
- A scanner that outputs keystrokes over USB, with its manual or programming card for the output mode and suffix settings.
- A panel with a USB host port and a text entry object configured to accept the scanned ASCII string.
- Test labels, including the longest code in use and one with leading zeros or mixed case.
- A timer, for ten timed cycles.
Prove the workflow before the station goes live
- Set the scanner to keyboard output and add the suffix (carriage return, or carriage return plus line feed) by scanning the programming barcodes in its manual.
- Size the destination: longest label in use plus the suffix characters. A 12-character label with a 1-character suffix needs 13 characters at minimum; write the number into the entry object's length setting.
- Decide where the string lives afterwards. Panel-local memory is fine for display and checks; when the logic consumes it word by word, packing an ASCII string into V-memory words for an HMI tag shows one destination layout.
- Open the screen, touch the entry field, scan one test label and compare the displayed value with the label character for character, leading zeros included.
- Scan the longest label and confirm the entry closes on the suffix with nothing truncated.
- Scan a second label without touching the field again. If the value lands, the entry re-arms itself in this project; if nothing appears, the operator selects the field before every scan. Time ten select-and-scan cycles and keep the average seconds per scan.
Whatever consumes the string, add validation for length, format and allowed values in the logic before anything downstream acts on a scan.
How to check it worked
The displayed string matches the label exactly on every test scan, the entry closes on the suffix with the longest label, and the ten timed cycles give you a seconds-per-scan number for the rate decision below. Time the cycles with the operator who will run the station, since their number is the one that matters.
Example: size the string and time the station
Scenario: a kitting bench scans one part-number label per kit, 40 kits per hour. Labels are 12-character Code 39 codes, and the symbology tops out at 43 data characters, so 12 sits well inside. The scanner appends a carriage return: 12 + 1 = 13 characters, so the destination is set to 16 for headroom.
The two-scan test shows the field must be selected again for every scan. Each cycle takes about 2 seconds: reach the screen, tap the field, aim, scan. At 40 scans per hour that is 40 × 2 = 80 seconds per hour, and 80 / 3600 ≈ 2% of the bench hour. The standard entry build stays.
Contrast a receiving bench at 360 scans per hour, one every 10 seconds. The same 2-second cycle means 360 × 2 = 720 seconds, which is 12 minutes in every hour, or 20% of the bench time spent tapping a field. Put a 5% budget on the touch step: 0.05 × 3600 = 180 seconds, and 180 / 2 = 90 scans per hour is where the standard field stops fitting.
Which build fits your station
The re-arm test result and the scans-per-hour number choose the build. The 2-second cycle assumes a field in easy reach on a used screen; a dedicated scan screen with the entry field as the only object cuts the tap to about 1 second, and 180 × 1 = 180 seconds again lands on the 5% line.
| Test result | Station rate | Build |
|---|---|---|
| Field re-arms after the suffix | any rate the station produces | Standard entry field; the operator touches once per screen visit and scans one label after another |
| Field needs selecting every scan | up to 90 scans/hour | Standard entry field, touch then scan, about 2 seconds per scan |
| Field needs selecting every scan | 90 to 180 scans/hour | Dedicated scan screen: entry field as the only object, target sized for a 1-second tap |
| Field needs selecting every scan | above 180 scans/hour | Scanner into a serial input on the panel or controller, so the touch step leaves the cycle |
A serial input moves the value into a communication port your logic reads, which changes the project on both sides; it is the answer above 180 scans per hour or at any station where the operator's hands are full.
Recommendation: run the two-scan re-arm test before the station goes live. If the field re-arms, keep the text entry build at any rate the station produces. If every scan needs a fresh selection, follow the bands in the table: standard entry field, then dedicated scan screen, then serial input, and size the destination for the longest label plus suffix characters in every build.
Questions
Can one screen hold two entry fields for two different barcodes?
It can, but the scan lands in whichever field is selected, so the operator picks the right one before every trigger pull, and a mis-tap puts a part number where a lot code belongs. Keep one entry field per screen for scan work, or split the task across two screens: select, scan, advance, select, scan. One field can accept both codes when the logic tells them apart by length or content.
The scanner beeps but nothing appears on the panel. What do I check first?
Confirm the entry field is selected first: a wedge scanner types into the focused field, and an unselected screen is the most common cause of a silent scan. Then confirm the output mode is keyboard. Check the suffix last, because a missing terminator shows up differently: the text sits in an open entry with the cursor waiting, instead of the field staying empty.
Does a scanner with its own display remove the select step?
No. The gun's own display confirms the decode at the scanner, but the panel field still has to be the active object before the scan for the value to land there. A display scanner earns its keep away from the panel, where the operator verifies a doubtful label without walking back, and it pairs well with the read-back line on the screen.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.