Why the vision server USB stick stays plugged into the controller

The camera connected at installation, and now the cell reports it offline. In almost every case like this one, the camera's vision server was installed from a USB stick and still runs from that stick: someone pulled it, moved it to another port, or the hub lost power, and the server died with it. This guide explains what the stick actually does, why removing it kills the camera connection, the five-minute recovery, the USB power budget that keeps stick and camera alive on one hub, and the points at which the inspection should move off removable media onto a smart camera or a vision controller. Everything here applies to a robot or cobot controller running camera-vendor vision software, and to any controller whose vision runtime lives on a flash drive.

Why did the camera connect at installation but fail now?

Because the stick that carries the vision server is no longer in the port it was installed from: the server runs from that stick, so with it unplugged the controller has no server process and reports the camera offline even though the camera itself is powered.

Work the causes in order of probability. First, the stick was removed after commissioning, often during cable tidying or a cleaning pass. Second, it was moved to a different port than the one the installation used. Third, it sits on a hub that lost its supply or got rewired. Fourth, the server crashed on its own and the stick is fine.

Each cause has a fast test. Look at the port: is the stick physically there? Put it back where the installation ran and watch the camera software's status panel. If the controller lists no storage volume at all, the stick or its hub is dead, not the camera. If the volume mounts but the server will not start, restart the controller before re-installing anything. An offline camera with the stick seated and mounted usually means the server process never came up — the same offline-after-restart family as a smart camera that stays offline on the same class of controller.

What is the vision server doing on the USB stick?

The camera vendor ships the server as a plug-in package you copy to a USB drive and install from the controller's software setup, and on this class of controller the server keeps executing from that drive, which makes the stick permanent cell hardware rather than a one-time installer.

The vendor's procedure is short: copy the plug-in file onto a USB drive, insert the drive into a USB port on the controller or its pendant, run the software installation from the setup menu, then restart so the plug-in comes up. The quick-start guide ends with a standing instruction — the drive stays in. Controller manuals warn against running the robot with an installation loaded from a USB drive for the same reason: the installation depends on whatever volume holds it.

A vision server is a runtime, not a document. The controller reads its files every time a camera session starts, which is the same dependency that makes deploying a vision application without the SDK on the target machine a task of its own: the files must physically exist where the process runs.

What exactly breaks the moment you pull the stick?

The server's executable and its working files live on the removed volume, so the first read after removal fails, the process dies, its socket closes, and every client holding that socket reports the camera offline, the vision system down, or a frozen program step.

Removal is not a graceful unmount. The volume vanishes under a running process, open file handles start failing, and the server exits through the controller's own error handling. Anything it held in memory goes with it: the current frame buffer, half-written logs, calibration files it had open. If your program talks to the server over a socket — the pattern in triggering a USB camera capture from a robot controller over a socket — that socket closes with the server, and the program side has to survive the disconnect.

Two second-order effects matter. A host that still holds the port open when the device disappears can wedge with it — the mechanism behind controllers that hang when a USB device is pulled while its host port is still open. And on the pendant the symptom often surfaces as a generic vision-system-down message; the fix that reworks the USB layout on a robot controller starts at the same root cause.

How do you get the camera back within five minutes?

Re-insert the stick into the same port it was installed from, then restart the controller so the plug-in stack comes up in its proper order; on this class of controller a restart is part of the vendor's own install-and-connect procedure and remains the fastest reliable recovery.

1. Re-insert the stick into the exact port it was installed from; a package that records its install source can ignore it elsewhere.
2. Restart the controller, not just the user program: the plug-in stack starts with the controller software.
3. Open the camera software's status panel and confirm the server shows connected before touching the robot program.
4. Pull a live image from that panel. A connected server with no image is a camera-side problem, not a storage problem.
5. If the server still will not start, re-run the software installation from the stick in the sequence the quick-start guide gives, then restart once more.

How much USB power do the stick and the camera hub need?

Budget the upstream port first: a USB 2.0 port supplies 5 V at up to 500 mA (2.5 W), USB 3.x raises that to 900 mA (4.5 W), and a bus-powered hub passes only its upstream 500 mA to everything plugged into it.

Worked example, with example inputs stated. Take a stick drawing 150 mA active (5 V × 0.15 A = 0.75 W; consumer sticks typically sit in a 100-200 mA active band) and a compact USB camera drawing 400 mA (5 V × 0.4 A = 2.0 W, a common streaming draw). Together they need 550 mA. On a bus-powered hub the downstream budget is still the upstream 500 mA, so the pair is 50 mA over: the hub refuses enumeration or sags the moment the camera ramps up to stream. On a self-powered hub fed by a 2 A, 5 V supply (5 V × 2 A = 10 W), the same pair takes 2.75 W and leaves 7.25 W of margin.

What moves the numbers: the stick's draw is small and steady, the camera's draw dominates and is fixed by its design, and only the hub's own supply — never the upstream port — can raise a self-powered hub's budget. Moving the camera off USB power altogether is often the cleaner fix; the trade-offs sit in camera power over USB versus external 5 V.

When should the vision software leave the stick altogether?

Move it when the stick gets handled between shifts, when more than one cell depends on it, or when each dislodgement costs a stopped robot: a vision controller or a smart camera that stores and runs its own inspection removes the removable-medium failure mode entirely.

Decision per case:

• One cell, commissioned, rarely opened: keep the stick, secure it mechanically, and store a cloned spare in the cabinet.
• The installer offers internal storage as a destination: take it. The failure mode disappears at zero cost; prove it with a cold boot.
• Several cells or frequent maintenance access: put the server on a dedicated vision controller, which holds its software on internal storage and keeps the camera link local.
• The inspection itself can run on the device: a smart camera or vision sensor ends the host dependency completely, because the robot receives results over Ethernet and no server process lives on removable media.

That last route is what the smart cameras category is built around. The MV-SC3050XC-16M-ATN-H is a 5 MP color vision sensor with a global shutter and an M12 mount, talking Fast Ethernet. The LS-SMC-0063 combines a 1.6 MP sensor, a 16 mm lens and white light in one GigE unit:

On-device suits location, measurement and code-reading work; a heavy multi-camera pipeline still belongs on a controller with its own storage. But for the single-camera cells where the stick keeps getting knocked, an on-device camera leaves nothing removable to fail.

What should you check before changing the cell or ordering parts?

Check four things: that the stick mounts and the server starts after a cold boot, that the hub's supply covers the measured draw with 30 percent margin, that the camera holds its target frame rate on that hub, and that a labelled spare stick with its software version exists.

• Cold-boot test: power the controller down and up with the stick in place and confirm the server starts unattended — that is the state the cell will actually live in.
• Measured power: read the hub's upstream draw with a USB power meter at full production speed, not at the bench, and keep 30 percent margin under the supply rating.
• Bandwidth: run the camera at its production frame rate on the final hub; a hub near its limit stalls frames before it fails outright, and the budgeting method is in why a USB hub drops camera frame rate.
• Port count: if cameras share the hub too, size it against how many USB cameras one controller can feed before drops.
• Spare medium: one cloned stick per software version, labelled and bagged, turns a lost stick into minutes of downtime.

If the decision lands on keeping the stick, order the spare, label both, and secure the ports. If it lands on-device, start at the camera finder or step through the system configurator with your field of view and cycle time at hand. More fixes from the field sit on the systems topic page, and if the shopping list grows, contact us — sizing help comes with every order.