A camera URCap that throws a communication error the moment it calls the camera is one of the most mis-routed faults in a robot cell. The camera maker's support says the code belongs to the robot software, the robot maker's support points back at the camera, and a string like SafetyA : C4A1 appears in neither side's lookup table. In practice the controller is nearly always healthy: the plugin-to-camera exchange — address, TCP port, protocol and timing — has broken somewhere, and every one of those layers can be tested with tools that are not the URCap. This guide gives the test order, the fix for each failing layer, the controller reimage procedure for the rare case where the controller is genuinely at fault, and a socket-based fallback that keeps the cell producing the same day.
What the error actually tells you
A camera URCap is a plugin inside the robot controller's PolyScope software, and for 2D guidance it does one network job: the vision system hosts a TCP server, the plugin connects as a client, sends a trigger and reads back coordinates. A reported communication error means that TCP exchange failed — the plugin could not connect, it connected to the wrong service, or it gave up before the reply arrived. Which of the three happened is testable without the URCap, which is why decoding the error code is a wasted afternoon. Treat the fault as a broken link until a layer test says otherwise, and do not reimage the controller as a first move.
The four failure layers, in order of probability
| Layer | How often | Test | What a failure means |
|---|---|---|---|
| Network path and addressing | Most common | Ping the camera from a PC on the robot's cable | Subnet, cable or address fault |
| Port and protocol | Common | Open the camera's TCP port from a PC and send the trigger | URCap points at the wrong port or protocol |
| Plugin state and versions | Occasional | Compare URCap and PolyScope versions, reinstall the URCap once | Plugin-to-controller mismatch |
| Reply timing | Hardest to see | Measure trigger-to-reply from a PC | Result arrives slower than the plugin waits |
1. Network path and addressing
The camera and the controller must reach each other's addresses, and the simplest arrangement — both on one subnet with static addresses — removes the gateway from the suspect list. Plug a laptop into the robot's cable, set the laptop to the robot's subnet and ping the camera. A ping that fails from a PC will fail from the robot, and no software reinstall changes that: work the cable, the switch port and the addressing. If the cell deliberately spans subnets, the routing options are collected in reaching cameras across a subnet; read that before blaming the plugin.
2. Port and protocol
The camera serves results on a fixed TCP port, and the URCap must carry exactly that address and port. Some plugins poll results as Modbus registers instead of raw TCP — the UR controller speaks Modbus TCP natively — so a plugin expecting registers finds silence on a socket port and reports a failure that looks identical to a broken cable. From the PC, open a TCP session to the camera's address and port and send the one-line trigger the camera's manual defines. A refused connection means the camera is not serving there: the inspection job is not running or the server is switched off. A session that answers with a coordinate line proves the camera side and convicts the URCap's configuration.
3. Plugin state on the controller
A URCap that loaded once can still fail after a PolyScope update or a conflicting plugin installation. Check the pairing first — matching the URCap version to PolyScope — then clear a conflict with a clean reinstall, the path described for a URCap installation error from a conflict. If the failing plugin is one you built yourself, a URCap that installs but cannot open its connection can be missing bundled libraries; embedding OSGi dependencies in a URCap covers that packaging side, which is a different fault from anything on the network.
4. Reply timing
The quietest layer: the exchange works, but the answer lands after the plugin stopped waiting, and the plugin reports that as a communication error. The PC test from layer two gives the number — send the trigger ten times and record the worst case. Anything that slows the camera past the plugin's fixed wait lands here: a heavy inspection job, a burst of network traffic from another device, or a camera still finishing its previous exposure.
The hardware swap that settles the wiring question
Before an afternoon in menus, spend five minutes on copper. Swap the Ethernet cable for a known-good lead, watch the link lights at both ends, and if doubt remains, connect the laptop straight to the camera with a short cable. A camera that serves results over a direct link but fails through the cell wiring has convicted the cable or the switch, not the software. Keep a long fixed run and a short drag-chain lead on the bench for exactly this test:
- Type
- Camera data cables
- Length
- 15 m
The LS-CBL-0117 is a 15 m RJ45 camera data cable with a locking stud; the LS-CBL-0199 is a 3 m high-flex drag-chain GigE cable with screw locks. One swap closes most physical-layer arguments; the rest of the camera data cables range covers other lengths and connector sets.
When the controller really is at fault: install a fresh image
The dead end first: reinstalling the software version that is already on the controller is refused outright — it tells you that version is installed, and nothing is repaired. A same-version overlay is not a repair anyway. What does reset the controller is a full image installation: on the robot maker's support site, under downloads for your controller type, fetch the robot image, put it on a USB stick and follow the published image-install procedure. On a CB3 this restores PolyScope cleanly, and it is the right move once the layer tests pass from the robot's own cable while the URCap still fails. Copy programs, the installation and the URCap file to USB first, then reinstall the URCap afterwards — the steps are in reinstalling a vision URCap package from a USB stick.
The fallback: drop the URCap and exchange results over TCP
The URCap is a convenience wrapper around an exchange you can write yourself, and it is the fastest way to keep a cell producing while the plugin question runs its course. The camera keeps hosting its TCP server; the robot program becomes the client. In URScript that is a socket open to the camera's address and port, a write of the trigger line, and a read of the returned values — socket_read_ascii_integer is the usual call when the camera answers with a plain list of numbers. Give every read an explicit timeout you control; that one setting removes the reply-timing layer the plugin hid from you.
The full pattern, including parsing what comes back, is walked through in smart camera to robot TCP data exchange; the same receive logic on the ABB side is shown in receiving vision data in RAPID over TCP sockets, and the coordinate messaging form in sending camera offsets to a robot over TCP. When the robot sends and nothing comes back, fixing the robot socket send loop is the next read.
For a cell built this way, pick a camera that serves its own results over GigE:
- Interface
- GigE
- Resolution
- 6-10 MP
- Sensor format
- 1/2.4"
- Shutter
- Rolling
The MV-SC5060XM-08M-WBN is a 6 MP mono smart camera with an 8 mm M12 lens and a GigE interface, so the camera side of the exchange needs no PC. Browse the smart cameras range or the camera finder for the sensor format your part needs.
Worked example: UR3 on CB3 at 3.15.8.106339 with a 60 fps camera
Inputs, each from the field case: a UR3 arm on a CB3 controller running PolyScope 3.15.8.106339; a communication error whenever the vision node runs; a same-version reinstall refused as already installed; a GigE smart camera on the same switch, serving results over TCP and acquiring at 60 fps.
The example camera is a compact smart camera that acquires at 60 fps with a 16 mm lens:
- Interface
- GigE
- Resolution
- Up to 3 MP
The LS-SMC-0063 is a 1.6 MP smart camera rated at 60 fps. The rule in words: a camera cannot answer faster than one frame period, and the robot's wait must exceed the measured worst-case reply with margin.
The arithmetic: 1000 ms / 60 fps = 16.7 ms per frame, so no trigger-to-reply on this camera can beat 16.7 ms plus the job's processing and the network round trip. Measure the worst case from the PC test, call it W, and set the robot-side wait to 2 × W. The doubling absorbs one slow cycle without hiding a camera that is genuinely degrading; a wait far beyond 2 × W turns a real outage into a mystery.
Then decide, in this order:
- Ping fails from the robot's cable: fix addressing or copper. Touch nothing in software.
- Ping passes, the port refuses: the inspection job is not serving. Start the job or enable the server on the camera.
- The port answers with a coordinate line and the reply fits inside 2 × W: the link is proven. Reinstall the URCap once, then check version pairing.
- Link proven, URCap reinstalled, error unchanged: install a fresh controller image, restore from USB, reinstall the URCap.
- The cell must run today: leave the URCap out and run the socket exchange with the wait at 2 × W.
When the usual answer is wrong
Start with the network, but know where that answer fails:
- The fault appeared right after a software update. A link that worked last week did not decay on its own; check the version pairing and plugin conflicts before the cable.
- The fault shows only on some cycles. Intermittent points at copper or timing: reseat and swap the cable, then compare the worst-case reply with the wait.
- The camera attaches over USB, not Ethernet. A vision system down error on the controller is then a USB layout problem, not a network one — see fixing the USB layout behind a vision system down error.
- Nobody can decode the error code. That is not a blocker: the exchange either completes or it does not, and the PC test answers that in minutes. The code names where the plugin gave up, not why the link broke.
Checklist before you open a support ticket
- Camera and controller on one subnet with static addresses, or a route you have actually tested.
- Ping the camera from a PC on the robot's own cable.
- Open the camera's TCP port from the PC, send the manual's trigger line, record the worst-case reply over ten runs.
- URCap version confirmed against the PolyScope version; the URCap reinstalled once from its file.
- Ethernet cable swapped for a known-good lead; link lights on at both ends.
- Fresh controller image installed from the maker's support site, programs restored from USB, URCap reinstalled — only after the steps above.
- Fallback running: socket exchange in the robot program, wait set to twice the measured worst case, stale replies discarded.
Once you know which layer failed, the fix is usually an address, a port number, a version pairing or a wait time. If every layer passes and the plugin still errors, talk to the applications team — free expert support comes with every order — and bring the PC test results; they settle most vendor standoffs in one message. More robot and vision integration pieces are on the robotics topic page.
أسئلة
Do the camera and the robot controller have to be on the same subnet?
Not strictly, but they must have a working route to each other. The same subnet is the least fragile arrangement: no gateway in the path and no routing table to drift. If a router sits between them, give both ends static addresses, keep the camera's TCP port open through it, and expect the reply time you measure to include the extra hop. A route that passes ping can still block the port the camera serves, so rerun the port test after any routing change.
How do I test the camera's TCP port without writing code?
Use the socket tools already on a laptop. On Windows, PowerShell's Test-NetConnection with the camera's address and port reports True or False for the connection attempt. On Linux, nc -vz with the address and port does the same in one line. Neither sends the camera's trigger, so a pass proves the server is listening; to see an actual coordinate line, send the manual's trigger through the same tool and read what comes back.
Will reinstalling the controller image delete my programs?
Plan as if it will. Export every program, the installation with its variables, and the URCap installation file to a USB stick before you start, because an image installation puts the controller's software back to a clean state and you do not want your only copy of the vision program on the machine being rebuilt. The URCap file is the piece people forget: without it you cannot restore the plugin once the image is on.
Can something other than the camera host the TCP server?
Yes. Camera-as-server is the standard pattern for 2D guidance, but the server only has to be whichever device holds the result. A PLC or an industrial PC in the cell can host the connection, take the camera's output and serve a normalized coordinate line to the robot. That adds a hop, so measure the reply time through the intermediate device before you set the robot's wait.
Is Modbus TCP an alternative to the URCap?
Sometimes. The UR controller reads Modbus TCP registers natively, so a vision sensor that publishes its results as registers can be polled straight from the robot program and the URCap becomes optional. Check the sensor's documentation for a Modbus map first; where none is offered, the plain socket exchange is your plugin-free path. Register polling is slower than a socket push, but it is simple to commission and easy for a PLC to share.