Vision system down error on a robot controller: fix the USB layout

You followed the install instructions to the letter: the flash drive shows up, the license dongle shows up, and the pendant still reports Vision System down. The gripper sharing the same USB hub works fine, so power and wiring are not the problem. This combination — hardware detected, vision features not loaded — has one dominant cause on a first install: the package folder is sitting one level too deep on the stick. This guide is for integrators and technicians bringing up a wrist camera on a robot controller for the first time. You will confirm the cause in two minutes with an address bar, fix it with an extract-here, check the four rarer causes if that was not it, and decide when it is time to stop loading vision onto the controller at all.

What the status message does and does not tell you

Vision System down is a load-time status, not a run-time fault. The camera-side software never started, so there is nothing yet to connect to, re-network or reboot into. That distinction drives the whole diagnosis. A cell that ran yesterday and reports down now points at cables, power or a network change. A cell that has never run, failing right after a first install from a USB stick, points at the install itself.

In the case behind this fix, the flash drive was recognized and the license dongle was recognized, and the gripper on the same hub worked. Working devices on the same hub prove two things at once: the hub has power, and the controller enumerates USB hardware correctly. The one thing the controller has not accepted is the content of the stick, which is why file layout outranks every cable on the suspect list.

If nothing on the hub is recognized — no drive, no dongle, no gripper — stop here and work through camera has power but not detected: USB link checks after a cable swap. That is an enumeration or wiring failure, not a file problem.

The root-level rule, and the folder one level too deep

A controller loading vision software from USB does a shallow scan. It reads the top level of the drive, looks for the package folder it expects, and loads from there. It does not crawl the tree below. The compressed package contains one folder — on the wrist camera installation behind this fix it is named vision_system — and that folder, not a wrapper around it, must be the first thing under the drive letter.

Desktop unzip tools fight you here. Most default to extracting into a new folder named after the archive, and a double extraction nests the real folder one level deeper again. The shallow scan then stops at the wrapper: drive found, package invisible, status down.

One folder of depth is the entire difference. The gripper keeps working and the dongle keeps enumerating, and the only symptom is the down status — which is exactly why this failure burns hours before someone finally opens the stick and looks.

Fix it in six steps

1. Format the stick on your PC. Use FAT32: it is the file format controllers in this class read most reliably, and a clean format removes whatever partitions and volumes the stick picked up in earlier duty. For a controller that refuses a stick it should read, the controller USB read/write fix built on FAT32 is the reference procedure.
2. Extract the package onto the stick root. Use your unzip tool's "extract here" option straight on the drive, or extract on the PC and copy the inner folder itself. Copy neither the archive nor a wrapper folder.
3. Check the address bar. Open the stick: the package folder (vision_system in the case behind this fix) must sit at the top level. Open that folder: you should see its files, not a second folder of the same name.
4. Eject cleanly, then plug the stick into the hub the vision system ships with — the same hub the dongle and gripper use — not into an unrelated port on the controller.
5. Reboot the controller. A USB drive is brought into service at boot, so files added or repaired while the controller runs are not re-scanned until the next start-up.
6. Open the camera dashboard. The status should now read running rather than down, and the installed-package view should list the version you loaded. Grab a test image before the camera goes back onto its wrist bracket.

Still down: the remaining causes, in order

If the package folder verifiably sits at the root and the status is still down after a reboot, work this list in order. Each test takes about two minutes.

1. The archive was copied, never extracted. A compressed file at the root gives the controller nothing to load; it wants the folder. Test: is there an archive file at the top level instead of a folder? Extract it in place, confirm the depth, reboot.
2. The stick was pulled after the install. Some stacks re-read parts of the package from the stick at run time, so removing it can bring the down status back even after a correct first load. Test: is the stick physically in the hub? Put it back and reboot.
3. The drive enumerates but will not read. Recognition and readability are different things: a stick can appear in the USB list while its format or its controller chip defeats the read. Test: repeat steps 1 to 3 above on a different plain stick before suspecting the controller itself.
4. Leftover state from a failed first attempt. If the installed-package list shows a half-registered entry, remove it, re-extract at the root and install once more rather than stacking a second attempt on top of the first.

If the folder is verifiably at level 0, the stick is a known-good one and the status still reads down, stop swapping and open a support ticket with the vision vendor. The install sequence is theirs to document, and a ticket with a photo of the stick's top level answers faster than another re-extract.

One boundary worth keeping straight: once the status clears and the software starts, failures move to a different layer. If your client code then fails at start-up, the load-time fix above is finished and the fault lives in the SDK sequence — camera failed to initialize error: fix the start sequence covers that next failure, not this one.

Keep it fixed on the next install

Five habits cost nothing and prevent the repeat:

• Extract at the root, every time, and check the address bar before ejecting. The wrapper folder is the default behavior of most unzip tools, so the depth check is the habit that matters, not the extraction.
• Dedicate the stick. One stick, one package. A stick shared between cameras, laptops and file shuttles collects exactly the volume clutter that causes cause 3 above.
• Leave the stick in its supplied hub once the install is good; the stack may re-read it at every boot.
• Reboot after any stick change, and treat files that "should have been picked up" as not picked up until a boot proves it.
• Record what you loaded. Note the package version and the stick it lives on in the cell file, so the next technician starts from a known state instead of rediscovering it.

Once the system runs, the same habit pays again: if you add more cameras of the same type, copy the smart camera dashboard layout to the next camera instead of rebuilding each screen by hand.

When to move the vision off the robot controller

The stick-install stack earns its keep on a single-camera wrist cell. It stops earning it when installs keep fighting you, when the pendant's processor is the bottleneck, or when the camera count grows past what the controller's vision option was sized for. The alternative is to run the cameras on a dedicated vision controller and hand results to the robot over Ethernet: the vision side boots from its own storage, the stick ritual disappears, and the robot program just receives coordinates.

Size it by port count and bandwidth. The arithmetic is short:

Worked example — three cameras, each 2448 x 2048 Mono8 at 15 fps:

• Frame size = 2448 x 2048 = 5,013,504 bytes ≈ 4.8 MB
• Link load per camera = 4.8 MB x 15 fps ≈ 72 MB/s
• One GigE port carries about 110 MB/s usable (125 MB/s raw, less protocol overhead), so each camera fits its own port with a 1.5x margin: 110 ÷ 72 ≈ 1.5
• Three cameras plus the robot link need four LAN ports, on separate interfaces so no two cameras share one link

Decision: for a cell up to about three GigE cameras, buy by LAN port count. A controller with 5+ LAN ports carries every camera and the robot link with no switch and no shared bandwidth; a two-port board forces a switch and a bandwidth conversation. Mono8 is assumed — an RGB8 pixel format triples the load to roughly 215 MB/s and overruns one GigE port, so color at this frame rate needs more than a single link. If you will add USB cameras to the same machine later, budget those separately: how many USB cameras one controller can feed before drops walks that arithmetic.

The MV-VC3301H-128G66 has 5+ LAN ports, 4 built-in light channels and an included vision license, which makes it the default pick for the worked example above.

The MV-VC2140-128G40-1T covers a single-camera cell from 3-4 LAN ports, 2 USB 3 ports and 4 built-in light channels. The MV-VC5525-256G70-NN steps up to PoE camera ports, 8 built-in light channels and 32 GB memory when the cell wants powered cameras and more light outputs.

Once the controller is on the network with the cameras, the remaining set-up is addresses and image retrieval — the same work as putting a GigE camera on a robot wrist: network setup and image retrieval, with the controller as the host instead of the pendant.

The decision, both cases. If the status is down on a first install, run the address-bar depth check first: level 0 clears it in most cases, in under ten minutes including the reboot. If the robot-side vision keeps costing hours on every change, size a dedicated controller by the port count above — the vision controllers category lists every model with its LAN port count, and the configurator walks you camera to controller step by step; browse the rest of the system-side fixes on the systems topic page. For a failure that does not match this pattern, contact us with a photo of the stick's top level: that one image answers most of the follow-up questions.