A PolyScope update that lands on the wrong day can take a vision program down with it. On 5 December 2018, controller software 3.8 for CB-series and 5.2 for e-series stopped wrist camera URCap UCC-1.6.5 from inserting Cam Locate nodes, on controllers where the same program had run the day before. This guide is for the integrator or line engineer who owns that pair: a Universal Robots controller and a camera URCap. You will read the installed versions off the pendant, decide whether the pair is supported, order the upgrade so the vision plugin and the controller software move together, and prove the node is back before the line restarts.
Why did Cam Locate disappear from my program tree after the controller update?
The vision URCap installed on the controller predates the controller software: PolyScope 3.8 for CB-series and 5.2 for e-series, released 5 December 2018, will not insert Cam Locate nodes from wrist camera URCap UCC-1.6.5, which was built for the 3.7 and 5.1 releases.
The mechanism is invisible from the outside. A URCap is a plugin the controller loads at start-up; the plugin declares the program nodes it contributes, and the controller registers those declarations only when the plugin's API level is one the running software supports. When 3.8 and 5.2 moved the URCap API past what 1.6.5 was built against, the controller stopped registering the Cam Locate node and hid it from the tree. Nothing was deleted: the setup screen still lists the URCap as installed, which is the tell that separates a version mismatch from a failed install.
The dates explain why the fault surprised lines that updated promptly. PolyScope 3.8 and 5.2 were released on 5 December 2018, and the wrist camera vendor had shipped UCC-1.6.6 against that release on 19 November 2018, so the fix existed before the break. Every line that installed the controller update without reading the URCap release note met the missing node first.
Which URCap version pairs with which PolyScope release?
One patch digit decides it: UCC-1.6.5 pairs with PolyScope 3.7 on CB-series and 5.1 on e-series, while UCC-1.6.6, released 19 November 2018, targets PolyScope 3.8 and 5.2, so a one-step controller update demands the matching URCap update.
The authoritative pair is always the camera vendor's release note for the specific URCap release, and Universal Robots' URCap compatibility chart for the controller side. The chart records where the plugin system begins: the URCap SDK and API arrived with PolyScope 3.3.0, listed for the CB3.0 and CB3.1 generations. Everything newer pairs the same way, one URCap release against named controller versions.
| Wrist camera URCap release | CB-series target | e-series target | Cam Locate on 3.8 / 5.2 |
|---|---|---|---|
| UCC-1.6.5 | PolyScope 3.7 | PolyScope 5.1 | blocked |
| UCC-1.6.6 | PolyScope 3.8 | PolyScope 5.2 | inserts |
Read the table as a unit, not as two independent products. The third component of the URCap version moved by one digit, 1.6.5 to 1.6.6, and that single digit is the whole compatibility fix. Treat any controller point update, 3.7 to 3.8 or 5.1 to 5.2, as a pair change until the release note says otherwise.
How do you read the versions you are actually running?
Read both numbers off the teach pendant before you plan anything: the controller's about screen prints the software version, and the setup screen lists every installed URCap with its release, so you can put the pair on the asset sheet in one visit.
The controller software version prints on the about screen, including a longer build string where one exists; compare the leading digits against release notes, because vendors pair on 3.7 or 5.1, not on the build suffix. The setup screen lists every installed URCap with its release number. Write both down, with the robot generation beside them:
- Controller software version and build, as printed on the pendant
- Every installed URCap and its release number
- Robot generation: CB3 or e-series
- Which saved programs insert the vision node
What is the safe order to upgrade the controller and the vision URCap?
Plan the pair, not the parts: install the URCap release that targets the new controller software before the maintenance window, update the controller inside it, then prove the node inserts, because a controller updated alone is exactly the combination that blocks node insertion.
Work the window in this order:
- Record the current pair from the pendant: controller software version and every installed URCap release.
- Read the release notes for the installed URCap and for the release that targets the controller version you plan to install. For the 2018 wrist camera pair that is 1.6.5 against 3.7 and 5.1, and 1.6.6 against 3.8 and 5.2.
- Obtain the exact target URCap release from the camera vendor's official support channel.
- In the maintenance window, with the robot in a safe state and no program running, install the target URCap from the pendant's setup screen, and restart the controller if the note calls for it.
- Update the controller software to the target release and let it restart.
- Open a blank program and confirm the vision node inserts and teaches.
- Run one locate cycle at reduced speed with the cell guarded, then release the line.
Can you keep the old pair in production instead?
Yes, within the pairing the vendor supports: UCC-1.6.5 is documented for PolyScope 3.7 and 5.1, so a line that must hold its current controller release freezes controller updates and qualifies the newer URCap offline before anyone touches the pendant.
That is what the vendor recommended for the 2018 episode: production users who wished to stay on UCC-1.6.5 were pointed at PolyScope 3.7 and 5.1. A freeze is a decision, not an accident. Write the held release on the asset sheet, and attach a condition to it: the newer URCap gets qualified on a test cell before the controller update is booked again.
The other exit is architectural. Vision that runs on a smart camera or a vision controller sends coordinates to the robot over Ethernet, so pendant updates stop touching the vision release and the pair you manage shrinks to one.
Does the same pairing rule apply to the newer robot OS and URCapX?
Yes, and the numbers are published the same way: Universal Robots' external-control URCapX for the PolyScope 10 generation states it requires PolyScope 10.8.0 or higher, and on 10.7.0 you either update the robot or step back to an older URCapX release.
URCapX is the plugin format of the PolyScope 10 generation, and its release notes state minimum controller versions instead of exact pairs. On 10.7.0 the published choice is to update the robot, which the note marks as recommended, or to run an older URCapX release. The direction of the comparison changed; the habit has not. Read the number the plugin prints before you book the controller update, and step the pair forward together.
The same reading habit covers the rest of a robot vision build. Before you standardize a cell, run the wider compatibility pass across camera, plugin and controller in 3D camera robot integration: check compatibility; it applies the same pairing discipline beyond program nodes.
When is the missing node not a version mismatch?
Check three other causes before you blame versions: the URCap failed to install outright, a half-removed plugin left stale files, or the saved program references a node from a different plugin release than the controller now has.
Separate the causes with three quick tests. If the setup screen does not list the URCap at all, the installation failed, and if the pendant reported an installation file error on an e-series pendant, work through resolving URCap installation file errors on PolyScope 5.1. If the URCap is listed but the node still will not insert after a confirmed version match, remove the plugin cleanly and reinstall; Uninstall vision system software from a robot controller covers the stale-file case. If a blank program accepts the node but an existing program will not load it, the program carries a plugin reference the controller can no longer resolve, which is the fault in Robot vision plugin missing: match the plugin version to the program.
What should you check on the line after the pair is matched?
Prove the fix in the program tree, not on paper: open a blank program, confirm Cam Locate inserts and teaches, run one locate cycle at reduced speed behind the cell guarding, and only then release the line to production.
Record the new pair on the asset sheet, archive the vendor-downloaded URCap file you installed, and write the previous controller release beside it as the rollback point. If the cell starts its vision program at boot, confirm the auto-start still fires after the controller update; Auto-start your vision system at robot controller boot shows the check. If locate teaches but then fails in production, the cause is usually timing or image source, not versions; Vision locate works in teach but fails at run time: stream vs snapshot walks that split.
Pin every pair in the plant this week: read the pendant screens on each Universal Robots cell with a camera URCap, write the two numbers on the asset sheet, and check them against the release notes before the next controller update is booked. If the vision hardware for a cell is still being chosen, start from the vision locate feasibility checklist, and the robotics topic page collects the set-up guides around this one. For a pairing that does not appear in any release note, send the two version numbers through the contact page and we will help you read the pair.
Questions
Where should the URCap installation file come from?
From the camera vendor's official support site or its authorized distributor, matched to the exact release the compatibility note names. A copy from a shared network folder carries no guarantee of version or integrity: the file name can say 1.6.6 while the contents are not, and a mismatched bundle turns one blocked node into an installation fault.
Which robot generations can run URCaps at all?
URCaps exist from PolyScope 3.3.0 upward, which Universal Robots lists as compatible with the CB3.0 and CB3.1 generations. Controllers older than CB3 predate the URCap system and have no plugin mechanism to match, so a missing vision node on those generations is a hardware capability limit, not a version mismatch.
Can we build our own URCap instead of waiting for the camera vendor?
The URCap SDK exists for integrators who need custom program nodes, but a self-built plugin inherits the same discipline: every controller software release you run must support the API level the plugin was built against, and you maintain that match yourself. For most lines, holding the camera vendor's supported pair costs less than owning a plugin build.
How do we roll back if the upgraded pair misbehaves?
Archive the previous vendor-downloaded URCap file and write the previous controller release next to it on the asset sheet before the window. Rollback is then the reverse of the upgrade: reinstall the archived URCap release, reinstall the previous controller software, and confirm the pair matches the release notes. Without the archived file, rollback waits on a download you may no longer find.