Reinstall a vision URCap package on a USB stick after formatting

A formatted USB stick takes a camera cell built around a Universal Robots pendant from running to blind in one click: the vision server that the camera URCap loads from that stick is gone, and the camera feature drops out of the program tree. Nothing else is lost — the installed .urcap, its settings and your saved .urp programs still sit on the controller — but the cell stays down until the stick carries the server files again. This guide is for the integrator or technician on shift, and it follows the recovery in the order you will actually do it: back up first, download the package again from the camera vendor, rebuild the stick with the vision_system folder at its root, match the package release to the PolyScope family, and step a pendant that is behind up through each minor version without skipping. Every file comes from the manufacturer or its distributor.

What disappears when you format the vision USB stick?

Only the stick's own contents: the vision server folder, named vision_system, that the URCap reads from the stick whenever it starts the camera. The pendant keeps its own half of the pairing, so the fix is to rebuild the stick, not to reconfigure the cell.

The split matters for the repair. The URCap is installed on the pendant and survives; the server folder has to sit at the root of an inserted stick or the feature has nothing to launch. That is also why the stick stays in the controller after commissioning — it is runtime equipment, not a transfer device, and the same reasoning explains why the vision server USB stick stays plugged into the controller.

What do you save before you reinstall anything?

Copy the .urp program files off the controller before you touch any version: the backup is not for the update that works, it is for the one that fails halfway and turns into a re-image.

Use the controller's backup function, or copy the program files off directly, and keep the copy on a PC — not on the stick you are about to reformat. A normal upgrade leaves programs and settings in place, so most of the time this is insurance you never cash. If the pendant's storage is already crowded, split the vision program files first; the pendant storage limit fix shows how to keep the archive small. And if the cell has PC-side tooling worth protecting too, choosing a Windows backup tool for a recovery USB stick is a decision to make before the failure, not during it.

Where do you get the vision package back from?

From the camera vendor's support page, for your camera model: the package archive holds both the .urcap that installs on the pendant and the vision server folder that goes back on the stick, so one download rebuilds the whole chain.

The archive is compressed; unpack it on a PC and you end up with the .urcap file and the vision_system folder, released as a matched pair. The download page usually offers two package releases — one for the older PolyScope families and one for the newer — so read the pairing note before clicking instead of grabbing the newest file. Download only from the manufacturer's own support page or its distributor, and follow that page's install sheet for the pendant-side .urcap installation.

Which package version matches your PolyScope release?

The release built for the PolyScope family the pendant is actually running: a package meant for 3.6 will not install on a 3.3 pendant — the pairing, not the newest number, decides.

Read the version off the pendant's system screen first; it decides the download. In the package line for these camera URCaps, one release covers the 3.5 and 3.6 families and an earlier release covers 3.4 and below, and the download page states which is which. Staying put is a valid answer: a pendant on 3.4 that must not move takes the older release and the cell runs. The same matching discipline decides program-side failures — a program saved under one plugin version may not open cleanly under another — as matching a URCap version to PolyScope and matching the plugin version to the program both show.

How do you load the vision_system folder onto the stick?

Format the stick in Windows, then copy the vision_system folder so it sits at the root of the drive — the URCap looks for it exactly there, and a folder nested one level down reads as missing.

1. Put the stick in a Windows PC, right-click the drive in File Explorer, choose Format and select Restore device defaults — the same preparation the robot maker's USB update procedure prescribes.
2. Unpack the package archive on the PC; the .urcap file and the vision_system folder should end up side by side.
3. Copy the vision_system folder onto the stick at the root, not inside any parent folder.
4. Move the stick to a USB port on the controller and install the .urcap from the pendant's URCap setup screen.
5. Restart the controller and run a test program that calls the camera node.

One detail catches people on the second pass: a stick that has just served a robot update or re-image comes back partitioned as ext3 and ext4, which Windows cannot read, so File Explorer offers to format a drive that is behaving normally. Reformat with Restore device defaults and it carries files again — the same pattern as a USB drive not recognized until a FAT32 reformat. Plug the stick directly into the controller rather than through an unpowered hub, because shared-port layout causes its own vision system down errors that look exactly like a missing server.

What order do you follow when PolyScope is behind?

One minor family at a time: from 3.3 you step to one 3.4.x release, then one 3.5.x, then 3.6.x, and the robot maker's update notes are explicit that minor releases are steps, not options.

Skipping a family is the one move the procedure refuses — 3.4 straight to 3.6 fails — so plan the landing before the first download. Worked example, pendant reporting 3.3.3 and a package line built for 3.6:

• Path: 3.3.3 → one 3.4.x → one 3.5.x → 3.6.1
• Update loads = target minor − current minor = 6 − 3 = 3
• Stick cycles = 3 update loads + 1 package install = 4
• Downloads = 3 update archives + 1 package archive = 4 files

Each load repeats one cycle: format the stick with Restore device defaults, copy that stage's update archive, run the update from the pendant's update screen, confirm the landed version on the system screen, then format again for the next family. Install the camera package once, at the final version, and rebuild the stick for it then — the intermediate families never see the package.

How do you verify the camera is back?

Three checks, in order: the camera feature appears and installs in the program tree, the pendant reports the vision server running from the stick, and a test capture returns a live image instead of an error.

Most recoveries end at the first boot after the install step. If the feature refuses to install, the pairing is wrong — go back to the version section and take the release built for the family the pendant now reports. If the feature installs but never streams, re-check the root rule for vision_system and confirm both files came out of the same archive. Once the picture is back, log a short series of test images; when a pick fault appears weeks later, that history is what makes image logging over FTP useful instead of decorative.

When is a vision controller the better home for vision?

When more than a camera or two shares the pendant's attention: a vision controller on the cell network runs the application independently of PolyScope, so stick formats and robot software updates stop taking vision down with them.

Moving the runtime off the pendant changes the failure mode entirely. Cameras terminate on the controller's LAN ports, results reach the robot over Ethernet, and neither a formatted stick nor a PolyScope upgrade touches the vision application. Multi-camera cells, heavy matching or 3D workloads, and any line where vision downtime stops the robot belong on this architecture.

The MV-VC2140-128G40-1T and the MV-VC3301H-128G66 carry 8 GB of memory and 4 built-in light channels each; the MV-VC4712-256G10-2TH adds PoE camera ports and 6 built-in channels, so a GigE camera shares one cable for image and power. The MV-VC5525-256G70-NN steps up to 32 GB of memory, 5+ LAN ports and 8 built-in channels:

Size it from the camera list and the cycle time rather than the box count: port count, PoE and memory decide how many cameras a controller carries well. Start from the vision controllers category, or send us the camera list and we will do the pairing with you.

That is the whole recovery: files back at the root of the stick, package release matched to the family the pendant runs, versions stepped one minor family at a time. More UR-side fixes — plugin pairing, USB layout, image history — sit on the robotics topic page, and contact us with the pendant's version screen if a pairing still will not close.