Choosing a USB badge reader for an HMI with gloved operators

The short answer

Buy a contactless reader with three properties. First, it enumerates as a USB keyboard with no driver, so the panel treats it like a keypad. Second, it reads the badge technology the plant already issues: 125 kHz proximity fobs, 13.56 MHz smart cards, or a dual-frequency unit if the site runs both. Third, its rated read distance covers a presentation a gloved operator can actually deliver, which in practice means flat placement on the reader face.

Keep the PLC as the authorization point. The badge replaces the typing; the lookup table still decides what that employee may dispense. Bench-test the exact panel and reader pair before the unit goes on the console.

Recommendation: buy one driverless keyboard-emulation USB reader that covers both 125 kHz and 13.56 MHz, mount it flush on a non-metallic console face within reach of the panel, and release it to the floor only after that bench panel delivers a clean credential string into the PLC lookup field and rejects an unknown badge.

What decides the choice

Four checks, in this order.

1. Panel USB support. A USB port names the connector, not the behavior. The panel accepts the device classes its manual lists, so the manual decides before the reader datasheet does. Ask for the keyboard device class, because that is the class barcode scanners and keypad wedges have used on operator panels for years.
2. Credential match. The reader must speak the frequency and card format your badges use. A 13.56 MHz reader will not read a 125 kHz fob, and the reverse.
3. Read distance against mounting. Contactless badges are near-field: the tag draws its power from the reader's field, so the read happens at centimetre range. Desktop units manage about 2 to 10 cm. Mount the reader where a gloved hand can lay the badge flat or come well inside that band.
4. Housing against the chemicals. A sealing figure on a datasheet describes dust and water. It is silent on full-strength acids and caustics, so put the chemical list in front of the reader maker and mount the unit out of the splash path.

Why keyboard emulation is the interface to ask for

A keyboard-emulation reader enumerates as a USB keyboard and sends the badge number as keystrokes. No driver, no vendor library, and no special project work: receiving keystrokes into an input field is the oldest input path an HMI project has.

Two other interfaces exist, and both need the panel maker's documentation before you buy. A reader that requires a driver works only if that driver exists for your panel model and the manual says so. A reader that speaks a vendor protocol over USB works only if the panel manual names that protocol as supported. The word USB on a reader's box describes the plug. Get the interface mode in writing from the supplier, because that line decides compatibility.

125 kHz or 13.56 MHz

Let the badges the plant already issues decide. If the door system runs 125 kHz proximity fobs and you want the same fob at the bench, buy 125 kHz. If the plant issues 13.56 MHz smart cards, buy 13.56 MHz. If the site is mid-migration, a dual-frequency reader covers both from one unit; a common driverless desktop model reads 125 kHz and 13.56 MHz and lists a read distance up to 80 mm.

The split has a hardware reason. A 13.56 MHz tag antenna needs 4 to 5 turns of wire; a 125 kHz tag needs 200 to 300. An antenna application note from a semiconductor maker uses that comparison to explain why high-performance tags are easier to build at 13.56 MHz, which is a large part of why 13.56 MHz cards became the common default while older 125 kHz fleets keep running the fobs that were installed.

Reader options compared

Example: a 15-inch panel at a chemical dispensing bench

Inputs, with where each comes from:

• Panel: the 15-inch operator panel already at the bench, with a USB host port (the station as its process specifies).
• Operators: gloved, with acids and caustics on the gloves (the station's dispensing process).
• Authorization data: employee numbers and passwords held in PLC lookup tables (the station's existing controls design).
• Candidate reader: a driverless dual-frequency USB reader covering 125 kHz and 13.56 MHz, listed read distance up to 80 mm (a typical desktop reader datasheet).
• Expected read band: 2 to 10 cm for desktop contactless readers (typical datasheet range).

Rule in words: a badge reads when its distance from the reader face stays under the rated distance, minus whatever sits between badge and antenna. A keyboard-emulation reader works only if the panel accepts keyboard-class USB devices and the project delivers the typed value into the field the PLC validates.

Arithmetic:

• Flat placement: the badge lies on the reader face, so the gap is 0 mm. Margin = 80 mm - 0 mm = 80 mm.
• Hover check: a gloved hand holds the fob 6 cm clear of the face, the midpoint of the 2 to 10 cm band. 6 cm = 60 mm. Margin = 80 mm - 60 mm = 20 mm, so the read still lands.
• Metal check: a stainless console face between badge and antenna blocks the field outright, and no distance arithmetic helps. The rating carries only through non-metallic material.

Result: the candidate reader fits this bench if it mounts flush on a non-metallic console face within reach of the 15-inch panel.

Decision, with the threshold: keep every badge presentation under 80 mm, and under whatever rating the datasheet you finally buy prints. Accept the reader for rollout only when one scan delivers the complete credential string into the PLC lookup field, an unknown badge number comes back rejected, and the dispensing permissive follows the PLC result. If the panel refuses the keyboard device class, keep keypad entry at the station and take the PLC-side path described below.

Keep the authorization decision in the PLC

The reader delivers a number, nothing more. The lookup tables in the PLC already hold the employee records, so add the badge number as one more value on each record and let the PLC decide, recipe by recipe, whether that employee is authorized. The screen displays what the PLC decided.

Three rules keep the design honest:

• Gate dispensing on the PLC's authorization result. A hidden screen or a disabled button is a screen condition, and screen conditions change with every project edit. The PLC value is what the dispensing sequence actually reads.
• Clear the active identity when the operator changes, the station returns to idle, or the panel link drops. Because the lookup and the dispensing logic live in the PLC, a panel or reader failure leaves the PLC's own permissive state in force, and the PLC keeps its schedules when the panel goes offline.
• Test the rejection path as hard as the acceptance path: unknown badge, valid badge for the wrong area, badge pulled away mid-read, two badges on the reader at once.

Before the station runs live, confirm the panel writes the badge value and the PLC returns a real authorization result, the same discipline as any operator panel link setup where you test writes before motion. For badge authorization wired into PLC logic, a field guide on PLC badge authorization shows the lookup, the reject path and the permissive end to end.

One safety note: identity is access control, not machine safety. The emergency stop chain and the dispensing interlocks stay hard-wired or PLC-resident regardless of how the operator signs in.

Bench-test the pair before it goes on the console

1. Plug the reader in and prove the panel treats it as a keyboard: put the cursor in any text field and scan. Digits on the screen confirm the device class. If nothing appears, work through the checks for a USB device the panel does not recognize, because the enumeration path is the same one.
2. Open the recipe screen, put the input focus in the identity field, and scan once. One scan must deliver one complete string at the full length the badge format carries, with whatever end-of-string terminator you set in the reader, and no repeated characters.
3. Move focus to a different field and scan again to learn where the digits go when the wrong field has focus. Then close that door: set the other fields read-only during a scan and have the project clear the identity field after each read, so no badge number stays on the screen.
4. Scan the unenrolled badge and confirm the PLC rejects it and the recipe stays locked.
5. Break the reader's connection mid-session and confirm nothing authorized survives: the PLC permissive drops and the station returns to its idle state.

When to pick something else

• The panel manual lists no keyboard-class USB support. The panel path is then closed. Check whether the manual documents a serial reader input; if it does not, wire the reader into the PLC and let the PLC hand the authorization to the panel as a value. A knowledgebase page on connecting a badge reader to a PLC walks that wiring.
• The plant issues phone-based credentials. That is a different reader class with its own panel requirements. The bench-test discipline stays the same; the interface questions multiply.
• The washdown chemicals attack the housing. Ask the reader maker which chemicals the housing tolerates and mount the unit out of the splash path. If none is acceptable, the reader belongs at a cleaner post beside the bench, still inside the read-distance rule.

What to ask for before you order

• From the panel side: the panel model and the manual line listing its supported USB device classes.
• From the reader supplier, in writing: interface mode (USB keyboard, no driver), frequency or frequencies covered, card formats supported, rated read distance in millimetres, housing chemical compatibility, and behavior with two badges presented together.
• For the bench: two sample badges enrolled in the PLC table, one badge left unenrolled, and the recipe project loaded on a bench panel of the same model.
• From your own side: the authorization design written down, meaning which PLC value authorizes, which one rejects, and what clears the session.

Questions