A panel-mount HMI usually has one spare USB type-A host port, and a workstation at the line wants three things on it: a mouse for the operator tired of touch targets, a keyboard for typing part numbers, and a barcode scanner for capturing the same part numbers faster. All three can share that one port through a hub, and the set-up holds for years when two conditions are met. Every device must enumerate as a HID class device, because an HMI loads no vendor drivers, and the combined current draw must stay inside the port's 500 mA budget at 5 V. This guide gives you the HID rule, the power arithmetic with the numbers filled in, the focus set-up that lands scans in the right field, and the cases where the scanner should skip the hub and go over Ethernet or wireless instead.
The decision up front
Yes: a mouse, a keyboard and a keyboard-emulating scanner can run from one HMI USB port through a hub. Four numbers decide it:
- Device class. Mice and keyboards are HID by definition. The scanner must run its USB keyboard (HID) mode; its vendor serial or camera mode will not enumerate on a panel that only reads HID.
- Hub tiers. The USB 2.0 standard allows up to five hubs in series, seven tiers counting the root port. One hub uses one of the five, and a host controller addresses up to 127 devices while you are connecting three. Addressing never binds here; power does.
- Power. The port supplies 500 mA at 5 V to a high-power device. A bus-powered hub keeps one unit load of that for itself and guarantees only one unit load per downstream port. This is the constraint that kills set-ups weeks later.
- Decision ladder. Total label current at or under 400 mA with no device above one unit load: one bus-powered hub serves all three. Any device labeled above one unit load: that device goes in the HMI port or on a self-powered hub. Total above the port's ceiling: self-powered hub, no exceptions.
Why every device on the hub must be HID class
HID, the USB human interface device class, is the device class defined for input devices such as mice, keyboards and barcode readers. A host that reads HID needs no driver beyond its own stack, and that is exactly the situation on a panel: the HMI's USB host port parses HID reports natively, and there is normally no way to install a vendor driver on the panel at all. A device that enumerates as anything else has no path in.
That makes the scanner's mode setting decisive. A reader that offers several USB modes must be set to keyboard (HID) emulation; in its vendor or serial mode the HMI ignores it. The mode choice is worked through in USB barcode scanner on a PLC HMI: HID keyboard mode or serial port. For the protocol side of carrying HID input into a serial-PLC panel, the configuring USB HID communication for a serial PLC HMI knowledgebase page covers the same integration from the PLC end.
The mouse needs one check rather than a driver: some HMI families draw an on-screen pointer and some older ones read the mouse but show no pointer. Confirm the pointer option in the model's configuration before you mount the mouse on the arm.
How a scan becomes typed text: emulation and focus
A keyboard-emulating scanner sends each decode as keystrokes, with a configurable prefix and suffix, and the suffix is normally an Enter that commits the field. The HMI routes those keystrokes to the entry object holding focus, so the real set-up question is the object, not the scanner.
Three rules cover it:
- The text or numeric entry object that receives scans must sit on the active screen.
- It does not have to sit inside the visible screen area. Place a second entry object outside the viewing area, tied to the same tag as the on-screen field: the scanner types into the tag while the keyboard types into the visible field.
- Where the platform provides a focus tag, input can be steered to a named object without the operator tapping it first, which saves you when a screen change leaves focus on a button.
The single-scanner version of this pattern, and the focus mechanics behind it, are covered in USB barcode scanner as a keyboard wedge into your HMI and keyboard wedge barcode readers and focus in your HMI.
The scanner side of this set-up is a wired USB handheld reader in keyboard-emulation mode. The shop's wired USB models:
| Specification | MV-IDH2000P/13NR/05RN/U | MV-IDH5000P/13SR/04RN/U | LS-HCR-0001 |
|---|---|---|---|
| Symbologies | 1D codes: Code 39, Code 93, Code 128, GS1-Code128, CodaBar, EAN 8, EAN 13, ISBN, ISSN, ITF 25, ITF 14, UPCA, UPCE; 2D codes: QR Code, Data Matrix, MicroQR, Aztec; Stacked code: PDF417 | 1D code: Code 39, Code 93, Code 128 (incl. GS1-128), Coda Bar, EAN8, EAN13, ISBN, ISSN, ITF14, ITF25, UPCA, UPCE; Matrix 2D code: QR Code (incl. GS1-QR), Data Matrix (incl. GS1-DM), Micro QR, Aztec, Han Xin; Stacked 2D code: PDF417, Micro PDF417 | – |
| Min. accuracy | 1D codes: 3 mil; 2D codes: 4 mil | 1D codes: 3 mil; 2D codes: 5 mil | – |
| Sensor type | CMOS | CMOS | – |
| Resolution | 1280 × 1024 | 1280 × 1024 | 1280 x 800 |
| Depth of field | Code 128 (3 mil): 30 mm to 105 mm; Code 128 (10 mil): 20 mm to 200 mm; Data Matrix (5 mil): 40 mm to 80 mm; QR Code (10 mil): 20 mm to 135 mm; QR Code (20 mil): 20 mm to 195 mm | Code 39(3 mil):35 mm ~ 140 mm; Code 39(10 mil):0 mm ~ 440 mm; Code 128(5 mil):30 mm ~ 185 mm; Code 128(20 mil):\ mm ~ 750 mm; Data Matrix (5 mil):60 mm ~ 80 mm; Data Matrix (20 mil):0 mm ~ 485 mm; QR Code (10 mil):0 mm ~ 220 mm; PDF417(7 mil):0 mm ~ 230 mm | – |
| Field of view | Horizontal 39°, vertical 29° | 43° (H) × 35° (V) | – |
| Detection angle | Tilt angle ± 65°, skew angle ± 65°, rotation angle 360° | Tilt angle ±65°, Skew angle ±65°, Rotation angle 360° | – |
| Symbol contrast | 20% | 20 % | 20% |
| Communication protocol | SmartSDK, Serial, USB (HID/CDC) | SmartSDK, Serial, USB(HID/CDC) | USB (HID/CDC) |
| Data interface | USB 2.0 | USB2.0/3.0, DC terminal, RS-232 | – |
| Power supply | 5 VDC | USB:5 VDC; DC terminal: 12 to 24 VDC | – |
| Current consumption | 0.9 A (max.), 0.5 A (typical) | DC terminal: 0.63 A (max. current); 0.28 A (typical current); USB: 0.9 A (max. current); 0.56 A (typical current) | – |
| Price | $179.00 | $719.00 | $539.00 |
Values as printed in each product's data sheet; open a part for its drawing and full specifications.
Sizing the power budget for a mouse, keyboard and scanner on one port
This arithmetic decides whether the hub survives a month. The inputs, with their sources:
- HMI port: USB 2.0 type-A host port, 5 V bus, 500 mA available to a high-power device (2.5 W). These are USB 2.0 specification values.
- Mouse: wired optical mouse, one unit load. A low-power USB 2.0 device may draw up to 100 mA without requesting more.
- Keyboard: compact industrial keyboard, one unit load, same rule.
- Scanner: keyboard-emulation handheld, up to the full port budget worst case. The label on the scanner gives the actual draw.
- Bus-powered hub: keeps one unit load for its own logic and guarantees one unit load per downstream port. The arithmetic 4 × 100 mA + 100 mA = 500 mA is exact: the hub's own load plus four low-power downstream guarantees exhaust the port.
The rule in words: the port budget covers the hub's own unit load plus every device's label current, and separately, any device labeled above one unit load must sit where the full budget is guaranteed — the host port or a self-powered hub port.
Three arrangements, with the arithmetic:
- All three through the bus-powered hub. Three unit loads plus a scanner asking the full budget total 800 mA against the port's ceiling: 300 mA over. And the hub guarantees only one unit load per downstream port, so the scanner fails on the hub even if the total had fit.
- Scanner in the HMI port, mouse and keyboard through the bus-powered hub. 300 mA of the budget is committed, leaving a 200 mA margin, and the scanner draws against the port's full guarantee.
- All three through a self-powered hub. The hub feeds the full budget per downstream port from its own supply and draws one unit load upstream. The port runs at a fifth of its budget and every device sits inside its guarantee.
The result: the set-up works in arrangements two and three and fails in the first.
The decision and its threshold: read the label on every device before ordering the hub. At or under 400 mA total, with no single device above one unit load, a bus-powered hub is fine. The moment any device's label reads above one unit load, that device moves to the HMI port or to a self-powered hub. Above the port's ceiling — a fourth device, or a panel that also wants a card reader — the self-powered hub is the only answer.
Bus-powered versus self-powered hubs
A bus-powered hub is the flat block with no power supply that takes everything from the one port it plugs into. It serves a mouse and a keyboard because both fit inside one unit load, and it is the wrong part the moment a high-power scanner joins. A self-powered hub brings its own mains supply and guarantees the full 500 mA on every downstream port, which restores the budget a PC port gives.
In a panel, the self-powered hub's supply needs a home: a small supply outside the cabinet through a filtered entry, or a 5 V feed from the DIN-rail supply where the hub accepts one. Budget that feed too, since hub plus devices can ask for 2.5 W or more.
| Set-up | Upstream draw | Verdict |
|---|---|---|
| All three through a bus-powered hub | 800 mA asked, 300 mA over | Fails; the scanner also exceeds the hub's per-port unit-load guarantee |
| Scanner in the port, mouse and keyboard on a bus-powered hub | 300 mA of the budget | Works, with 200 mA of margin |
| All three through a self-powered hub | One unit load of the budget | Works; full budget per downstream port |
| Scanner over Fast Ethernet or wireless | No USB draw | Works; the port stays free for mouse and keyboard |
The same one-port arithmetic governs serial adapters: connecting multiple RS-485 devices to LabVIEW via a USB hub works the numbers for RS-485 adapters on one PC port, and the per-port guarantee logic is identical.
When the USB port stops working
The classic failure: everything works for days, then the HMI's USB port is dead and a reboot does not bring it back. Work the causes in this order.
- Chronic over-budget draw. The port ran over budget for weeks, and a decode spike finally sags the 5 V rail far enough to trip the port protection or damage the transceiver. Power the panel down for a minute and back up: many hosts use a self-resetting fuse, so a port that returns means protection rather than damage. Then move the load, scanner to the host port or a self-powered hub.
- ESD at the scanner. A handheld reader in a dry plant carries a static discharge on every scan, down a cable that ends in your port. Swap the cable and watch whether failures cluster by operator or by season.
- Connector wear and strain. A tethered scanner yanks its plug, and a worn power pin browns out under load even with a correct budget. Fit a short cable with strain relief and retest.
If the port stays dead after a cold power cycle, treat it as hardware damage: move scanning to Ethernet or wireless and retire that port from duty. The barcode scanner power and interface checks for USB adapters checklist covers the same faults from the adapter side.
When one shared port is the wrong answer
Two cases argue against the hub entirely. First, if operators change screens freely, focus follows the screen and a scan can land nowhere; when the entry object cannot be guaranteed, take the HMI out of the data path. A Fast Ethernet reader puts its decodes on the plant network and the PLC pulls them as a client, as laid out in barcode reader as TCP server: wire your PLC as the client; the HMI then displays the tag with no focus object in the loop. The interface trade-offs are compared in barcode scanner input methods to a PLC: serial, USB and Ethernet.
Second, if the scanner must travel along the line or the cable run is long, go wireless: the reader pairs with a base station that wires to the controller over serial, as set out in cordless barcode scanner to a PLC: base station and serial link. The readers that bypass the hub:
- Connection
- Wireless
- Interface
- Fast Ethernet
- Connection
- Wired
One hard limit stays: do not share this hub with a machine-vision camera. HID devices move a few kilobits per second, a streaming camera needs hundreds of megabits, and the camera's frame rate collapses first. USB hub drops camera frame rate: budget the bandwidth first works that budget; the camera gets its own port or its own controller.
Checks before you order
Before wiring:
- Every device in the plan is HID class, and the reader's manual lists USB keyboard emulation.
- Label currents are summed, and the total picks bus-powered versus self-powered per the ladder above.
- The plan uses one hub, not a chain: five in series is the USB limit and you need one.
At commissioning:
- The hidden entry object sits on the start screen, tied to the same tag as the visible field, and a test scan commits and clears it in one motion.
- A screen change and return leaves focus where the scanner expects it; if not, set the focus tag.
- Twenty consecutive scans decode without a dropout, the quick test for a high-power device starving on a bus-powered hub.
Cable and mechanics:
- USB 2.0 passive cable segments stay at or under 5 m, and one hub keeps the run inside the tier limit.
- The tethered scanner gets strain relief, so the plug never takes the pull.
If you want a single wired USB reader to hang the set-up on, the shop's general-purpose wired USB handheld is the starting point:
- Interface
- USB
- Connection
- Wired
Where this leaves you
One port, one hub, three HID devices, and a budget that sums under the port's ceiling: that is the whole set-up. Pick the reader from the handheld code readers category or the code reader finder, add mounts and spares from code reader accessories, and keep the camera off the hub. The systems-level guides sit on the systems topic page, and if your panel mix resists the USB path, write to us through the contact page and we will spec the serial or Ethernet route.
Questions
Can a mouse, keyboard and barcode scanner share one HMI USB port?
Yes, through one hub, provided all three enumerate as HID class devices and the current budget holds. A USB 2.0 port supplies 500 mA at 5 V; a mouse and keyboard each take one unit load, so the deciding item is the scanner's label current. Above roughly 400 mA of total draw, fit a self-powered hub or plug the scanner straight into the port.
How much current can I draw from an HMI's USB type-A port?
An HMI's USB type-A host port follows the USB 2.0 rule: 500 mA at 5 V where high power is available, 100 mA where only the low-power class is guaranteed, which is 2.5 W or 0.5 W. A bus-powered hub hands its downstream ports just 100 mA each; a self-powered hub restores the full 500 mA per port from its own supply.
Why does my scanner work on the hub for a few scans, then stop?
That pattern points to a high-power device on a bus-powered hub port. Enumeration and idle operation can succeed, but the current spike during a decode exceeds the one unit load a bus-powered hub guarantees per port, so the scanner browns out. Move the scanner to the HMI port itself or to a self-powered hub, then re-test with a batch of 20 scans.
Does the scanner's text entry object have to be visible on the screen?
Text and numeric entry objects must be on the active screen to receive wedge input, but they can be placed outside the visible screen area. Two objects tied to one tag, one visible and one hidden, keep the keyboard and scanner paths separate. If the platform has no focus tag, make the scanner's object the only entry object on the screens it is used from, so focus defaults to it.
How many USB devices can one HMI port handle in total?
The USB 2.0 standard lets a host controller address up to 127 devices and allows up to five hubs in series, seven tiers counting the root. Three devices behind one hub sit far inside that. Treat a composite device, one physical unit carrying several functions, as a single address, and let power rather than device count set your ceiling: the port budget binds long before address 127.
Can I put a machine-vision camera on the same hub as the scanner?
Keep the camera off this hub. HID reports move a few kilobits per second, while a camera streaming frames claims hundreds of megabits, and frame drops show up as lost images before the mouse ever misbehaves. Put the camera on its own host controller, or on a USB3 bus where one is present, and reserve the HID hub for input devices only.