USB dongle not found on a robot controller: fix detection

The vision set-up tool stops at "USB dongle not found" and the cell will not start. The message usually appears on robot controllers that run a PC-based vision package or a camera kit that needs a licence dongle or USB interface adapter. In most cases the dongle and the licence are both fine: the controller's USB port never enumerated the device, so the software has nothing to find. This page takes you from the error to the cause in about fifteen minutes — prove enumeration at the operating system layer, check the port's 5 V power budget, then the cable and the port itself, and only then the software.

What "not found" actually reports

The error is an application-layer message: the software looked for its dongle and did not find the device it expects. Before the software can look, the USB bus has to enumerate the device — the host detects it, reads its descriptors and assigns an address. When that bus step fails, the software message is simply the first place the absence becomes visible. So the first question is never "is the licence valid?" but "does the operating system see the dongle at all?" The same layering traps network cameras that show as not detected in software while the real fault sits in the link: the enumeration chain for GigE Vision cameras breaks the same way.

The working rule: if lsusb (Linux-based controllers) or Device Manager (Windows-based controllers) does not list the dongle, no licence re-import, software reinstall or reboot loop will fix it. Work the bus layer first.

Likely causes, in order of probability

Start here and test top to bottom. The first three causes cover most bench cases.

The kernel strings in the table are Linux output; the Windows equivalents appear in Step 1.

Step 1: prove enumeration at the operating system layer

1. Take the chain out. Unplug any hub or extension and plug the dongle directly into a USB port on the controller cabinet itself. Ports on a teach pendant or a front panel often run through an internal hub, which adds its own power budget and its own failure modes.
2. List what the bus sees. Run lsusb and keep the output. It prints one line per USB device, each ending in a vendor:product ID pair — that pair identifies your dongle for every later check.
3. Watch the kernel while replugging. Leave sudo dmesg -w running in a second session, then unplug and replug the dongle. A healthy port prints a new high-speed USB device number N line (the speed text varies with the device) and the dongle then appears in lsusb.
4. Read the failure lines. unable to enumerate USB device or device descriptor read/64, error -71 point at power or signal trouble — the same -71 signature behind USB devices that disconnect mid-stream. over-current condition means the port tripped its current limit, and nothing enumerates on it until the overload is removed and the controller power-cycled.
5. On a Windows-based controller, open Device Manager. Unknown USB Device (Device Descriptor Request Failed) is the same failure seen from Windows. Disable USB selective suspend (Control Panel → Power Options → USB settings → USB selective suspend settings), and remove the entries under Universal Serial Bus controllers so Windows reinstalls them at the next boot — the standard first moves for a port that looks dead.

If lsusb lists the dongle, the bus layer is clean and you can skip to the software-layer section. If it does not, the port's power budget explains most silent non-appearances, and the USB link checks after a cable swap also apply when a port was recently rewired.

Step 2: the 5 V, 0.5 A budget that decides enumeration

A USB 2.0 port lets a device draw 100 mA before it is configured and up to 500 mA after — 5 V × 0.5 A = 2.5 W per port. USB 3.0 raises the ceiling to 900 mA. A dongle configured for that full 500 mA unit load must get all of it from the port it sits on, and every meter of passive cable and every hub in the path spends that budget first.

Hub arithmetic comes before cable arithmetic. An unpowered hub receives a single allocation of that 0.5 A from its upstream port and keeps roughly 100 mA for its own silicon, so it cannot offer any downstream port the full load. A dongle that requests it fails to configure, or drags the shared rail down until descriptors stop parsing. The same budget decides whether a bus-powered depth camera produces an image at all, and it caps how many devices one port can feed.

With the dongle on a cable, the drop is:

Here L is cable length, r is resistance per meter per conductor — about 0.213 Ω/m for 28 AWG and 0.084 Ω/m for 24 AWG, from standard copper wire tables — and the factor 2 counts the power pair out and back.

On a direct port the drop is just the connector pair — a few tens of millivolts — so the budget problem disappears. If bMaxPower exceeds what the chain can supply, the fix is a direct port or a powered hub, not a "better" extension. Where the whole supply question is open, the trade-off between bus power and an external 5 V supply has its own page.

Step 3: shorten the path, then replace the cable

USB 2.0 allows at most 5 m per cable segment and USB 3.0 about 3 m, but a dongle wants far less than that. For it the decision is short: direct port, or one short lead and nothing else in between. If several devices must share one controller port, a powered hub gives each downstream port its own budget instead of splitting the upstream allocation — and it removes the hub from the bandwidth equation too, which is its own failure mode.

While you are in lsusb, run lsusb -t and check the negotiated speed: a device sitting at 480M that should run faster has negotiated down, the classic symptom of a marginal cable. Repeated -71 errors that move with the cable mean replace the cable; errors that stay with the port mean move ports and label the bad one.

If the dongle has to leave the controller cabinet — reaching a test station, for instance — use one short, shielded, drag-chain-rated USB lead rather than a consumer extension. The LS-CBL-0219 below is a 3 m USB 3.0 cable built for exactly that service.

Step 4: stop power management parking the port

The pattern: the dongle worked at commissioning, is gone after a weekend, and comes back after a replug. That is a suspended port, not a broken one. Linux-based controllers expose USB autosuspend per device; setting the dongle's power/control attribute from auto to on holds its interface awake. On Windows-based controllers the switch is USB selective suspend, covered in Step 1. A dongle that only wakes on access can also fail a licence check that runs before the bus has resumed it, so hold the port awake rather than hoping the timing works out.

Enumerated but still "not found": the software layer

lsusb lists the dongle, dmesg is clean, and the software still reports the error. Now work the application layer, again in order:

• Permissions. On Linux, the device node may belong to root while the vision process runs as a service user. Grant your user group access with a udev rule and restart the software.
• Identity. Licence checks usually bind to the dongle's serial number, printed by lsusb -v as iSerial. A replaced dongle enumerates perfectly and still fails the check; the fix is the vendor's documented licence transfer, not a USB change.
• Stale state. After moving ports, the running software may still hold the old device path. Restart the vision software once the bus layer is clean.

This is the same split as a camera that shows in lsusb but gives no video device: enumeration is not the same as usable.

Keep it fixed: mounting and a boot check

• Mount the dongle on a direct controller port, strain-relieved so nothing can lever it out of the socket.
• No unpowered hubs in the chain. If a hub is unavoidable, it is powered.
• Outside the cabinet, one short drag-chain-rated lead and nothing longer.
• A start-up check that fails the cell early instead of mid-cycle:

#!/bin/sh
# Cell start-up check: fail early if the licence dongle is not enumerated.
# Replace vvvv:pppp with the vendor:product ID your lsusb prints for the dongle.
lsusb | grep -qi "vvvv:pppp" || { echo "USB dongle missing" >&2; exit 1; }

On a healthy port the script exits 0 and the cell starts. With the dongle unplugged it exits 1 and prints the message, so the PLC log shows "dongle missing" instead of a vision fault at the worst possible moment. More port, power and cable triage lives on the systems topic page.

When the right fix is to drop the dongle

If the dongle exists only to licence PC vision software running on the controller, the whole USB dependency is optional. A smart camera runs the inspection on the device — no PC, no dongle, no USB chain to break — and hands results to the controller over Ethernet. The category spans vision sensors and smart cameras from under 3 MP to over 25 MP, so the same page serves simple presence checks and pixel-hungry surface work: smart cameras.

For a concrete data point, the LS-SMC-0063 runs 1.6 MP at 60 fps through a fixed 16 mm lens and connects over GigE. The inspection runs on the camera, and the controller's USB port stops being a failure point.

If you keep the dongle instead, pick the direct-port lead from the cables category or size the whole chain in the extras configurator. If you drop it, the camera finder filters smart cameras by resolution, interface and shutter, and we are reachable through the contact page for a set-up review.