URCap installation error from a URCap conflict: the fix

A vision URCap that refuses to install can idle a UR cell before the first image is taken. The camera is rarely the culprit. The failure is almost always a conflict between the URCap you are adding and one already on the controller. Typical causes: an API newer than the PolyScope underneath it, a dependency package the controller does not carry, or a build bug that fires only when one specific other URCap is present. Work the versions, not the wiring: read the tested PolyScope list, compare the numbers correctly, settle the URCap already installed, then reinstall in an order that proves the fix. This is pendant work, not rewiring work — twenty minutes beats a day of swapping cameras that were never the problem.

Why does a URCap installation fail when another URCap is already installed?

Install-time failures come in three forms. The new URCap may call an API newer than your PolyScope can resolve, it may need a dependency package your controller does not carry, or it may carry an install-order bug that fires only when one particular other URCap is present.

The pattern behind most warning signs in the setup screens is a URCap built against an API too new for the PolyScope underneath it. The dependency case announces itself in the error text, which names a required package; that form shows up most on CB3 series controllers. The third form is real, and vendors fix it in the open: one camera URCap release from May 2021, build 1.11.2, exists whose only listed change is an installation-error fix. That error appeared when a specific companion URCap was already on the robot. Before you touch the camera, treat the installed URCap list as the suspect pool.

If the new tile never appears at all after a restart, you are in the missing-plugin case rather than a conflict. Robot vision plugin missing: match the plugin version to the program walks that failure step by step.

Which PolyScope version is your controller actually running?

Read it off the controller itself — the home screen shows it as three numbers, for example PolyScope 5.9.0. Write all three down, because every decision that follows compares those numbers one place at a time.

The first number is also the generation: PolyScope 3.x runs on CB3 controllers, PolyScope 5.x on e-Series. A URCap is built for a generation, and the robot maker's URCap compatibility chart maps which URCap lines load on CB3.0, CB3.1 and e-Series — find it on Universal Robots' own support pages for your pairing. The rule that saves most upgrades: newer PolyScope versions are backwards compatible with URCaps built on older API versions. That is why an older URCap usually survives a PolyScope update, and why the dangerous direction is one-way. A URCap written for a newer PolyScope than yours has no such safety net.

How do you read a URCap's tested PolyScope list?

Treat the 'tested on' lines in the release note as the contract: a build listing PolyScope 3.15 and PolyScope 5.10 has been demonstrated on exactly those two. Your safe target is your version or a newer one inside the same major line.

Those two numbers are a real example: a camera URCap release tested on precisely 3.15 and 5.10 ships one build across both generations, CB3 and e-Series. Installing it on PolyScope 5.9 means running below the tested floor. Installing on 5.13 means running above the demonstrated pair with only backwards compatibility underneath. Both can work, and neither is what the developer promised. When the version question follows you past installation into runtime misbehavior, the matching logic is the same — URCap version mismatch: match vision plugin to PolyScope covers the runtime side.

How do you compare PolyScope versions without the 5.10 trap?

Compare major, then minor, then patch as integers: 5.9.0 is older than 5.10.0 because 9 is less than 10. Reading '5.10' as '5.1' is the classic mistake that leaves engineers convinced they are current when they are two releases short.

Worked example: three controllers against one build tested on PolyScope 3.15 and 5.10. Controller A reads 5.9.0 — major 5 equals 5, minor 9 sits below 10, so it is under the tested floor; upgrade PolyScope to 5.10 first. Controller B, a CB3, reads 3.14.0 — 3 equals 3 and 14 sits below 15, so upgrade inside the 3.x line to 3.15.

Controller C reads 5.13.0 — 13 sits above 10, so it runs above tested. Backwards compatibility means the build is expected to load; if the error still fires, the suspect is the other URCap, not the version. Decision per case: below tested, upgrade the controller first; on tested, install; above tested, install and then work the conflict list.

How do you remove or update the URCap that is blocking the install?

The URCaps page on the robot's setup screens lists every installed URCap with its version. The pool your conflict came from sits in one place before you change anything.

1. Screenshot the install error text and the URCap list before changing anything.
2. Identify the entry that overlaps the new URCap — the same vendor family, a shared function, or whichever entry the error names.
3. Open that URCap's release notes and look for a build that fixes installation against your new URCap or adds your PolyScope version to the tested list.
4. Update it to that build on the URCaps page, or remove it there if no such build exists and the cell runs without it.
5. Restart and confirm the list shows exactly what you expect.

If no fix build exists, the developer's support channel is the path: they can confirm the conflict, supply a build, or give you a date. Order matters from here, which is the next question.

What order do you reinstall in so the conflict does not come back?

Change one thing per restart: settle the URCap already installed, restart, and only then add the new one. A repeat of the error then points at exactly one candidate.

1. Note the failing URCap's name, build number and the exact error text.
2. Check your PolyScope against the tested list and, if you sit below the floor, upgrade the controller first.
3. Update or remove the conflicting URCap, then restart.
4. Download the target URCap build from the developer's official download portal only.
5. Install it on the URCaps page and let the robot restart.
6. Read the whole URCap list after the restart before opening the Installation tree.
7. Run one dry cycle that calls the vision node once, and log the result against the build numbers from step 1.

What if the URCap needs a dependency your controller does not have?

When the installer names a missing package, the URCap requires a third-party dependency your controller generation does not provide — a form seen most on CB3. The fix is a build from the URCap's developer for your generation, not a package loaded by hand.

The dependency is not optional and not something to source separately: URCap packages are matched to a controller generation, and on CB3 some dependencies simply are not available. Take the error text to the developer or the distributor that sold the URCap. The outcome is either a build that carries what it needs or a clear statement that the generation is not supported.

How do you prove the install took and the conflict is gone?

After the restart, three checks pass together. Every tile on the URCaps page loads without a warning sign, the vision node appears in the Installation tree, and one dry cycle completes with the camera producing frames.

The warning sign is the tell to read: its usual pattern is a URCap whose API is newer than the PolyScope underneath — a build written for a PolyScope you do not have. The cure is one step back or one step up. Install the newest build whose tested list contains your version, or move PolyScope up to the tested one, and the sign clears. A warning sign with everything still working has been reported in the field, so run the dry cycle before you roll anything back. If the node installs clean but dies after days of running, that is a different failure class: Smart camera fatal error after days running: network failure recovery handles that symptom.

Which vision hardware sits on the other end of the URCap?

A vision URCap is only the bridge; the pixels come from smart cameras or vision controllers that share the robot's subnet. Every device on that subnet needs its own unique address before any URCap behaves.

For inline checks where the camera judges on its own, keep the wiring short: the MV-SC5060XM-08M-WBN is a 6 MP mono GigE smart camera with an 8 mm M12-mount lens, a 1/2.4-inch sensor and a rolling shutter.

When the judgment runs on a PC-class node with room for more cameras and light control, a vision controller takes the role: the MV-VC2140-128G40-1T pairs an Intel N-series N97 processor and 8 GB of memory with a 128 GB SSD plus a 1 TB HDD, 3-4 LAN ports and 4 built-in light channels.

Network hygiene belongs on the same checklist as the versions. Give the camera or controller a static address outside the robot's range and a name that says what it is; Rename a smart camera network name without conflicts is the short procedure. If the pendant error talks about USB devices on the controller rather than URCap files, that is a port-budget problem, not a software conflict, and Vision system down error on a robot controller: fix the USB layout is the fix path.

Next step: shortlist the camera side in the smart cameras finder or start the camera configurator, and keep the robotics topic page at hand for the rest of the UR-plus-vision failure set. Version questions on a cell you are quoting come with free expert support on every order.