UR dashboard server connection fails when port 29999 is in use

You press Start on the pendant and the UR program runs a perfect cycle. Connect from a PLC or PC, load the same program, send play, and either the connection never opens or the pendant drops into a fault state — until you comment out the camera node, and everything works again. That pattern has one cause: the robot's Dashboard Server on TCP port 29999 serves a single client at a time, and a camera URCap in the program is already holding the slot. This guide gives you the symptom profile, a three-line connect test that names the holder, the arithmetic behind the failure, and the fixes in the order that costs least. It is written for integrators wiring remote start commands to UR robots that carry a camera URCap.

What the symptom looks like

Three variants of the same fault show up in the field. The connect to port 29999 fails outright while the camera program runs. Or the connect succeeds, load and play go out, and the pendant's status area misbehaves while your client waits on a reply. Or one start works and the next cycle's commands vanish. In every variant, removing the camera node from the program restores normal behavior, and putting it back breaks it again.

A bounded retry loop turns one missed start into a long silent stall, so operators blame the network. It is not the network. This is also not the usual teach-works, runtime-fails split that vision faults show — that pattern comes from lighting or triggering, as in vision locate works in teach but fails at run time. A fault that moves with the camera node in the program file lives at the connection level, and the send-with-no-reply variant has its own checklist in robot socket communication: no response.

One client at a time on port 29999

The Dashboard Server is the robot's program-level remote interface, documented in UR's official Dashboard Server protocol pages. It runs on port 29999 at the robot's IP address on both CB-Series and e-Series controllers, and it takes commands such as load and play from a TCP client. It serves one client at a time. A second client that arrives while the first holds the socket either fails to connect or disturbs the session already open — the pendant side included.

A camera URCap is a plugin inside PolyScope, and releases that show this fault kept a Dashboard Server connection of their own while the program ran. The slot was taken before your client ever connected. The same one-client-per-port behavior appears far from robots: a camera that answers its vendor tool refuses a second client for the same reason, as in camera works in vendor tool but not in ROS.

One more distinction from UR's documentation: when the socket is healthy and a command is not allowed for safety reasons, the Dashboard Server returns an error message. Text back means the connection path works and your problem is command content or pendant mode. A failed connect or silence means the slot itself is the problem.

Worked example: a UR10 on PolyScope 3.7 with a camera node in the program

Inputs, each with its source:

• Robot UR10 on PolyScope 3.7 — the camera-plus-UR integration this article answers.
• One camera URCap node in the loaded program, running during the cycle — it holds 1 Dashboard Server connection on the versions showing this fault.
• One external dashboard client — your PLC or PC sending load and play.
• Capacity of 1 client at a time — UR's Dashboard Server documentation.
• Connect timeout of 3 s — a value you set in the test snippet below.

The rule in words: while the camera node runs, two clients want a socket built for one, and the server has no room for the second.

Camera node in the program: demand = 1 + 1 = 2 clients against a capacity of 1. Since 2 > 1, the connect fails or the open session breaks — the pendant misbehavior you saw.

Camera node commented out: demand = 0 + 1 = 1 client. Since 1 ≤ 1, load and play pass, which is exactly why commenting the node out cured the cell.

Retry cost: a 10-attempt loop with the 3 s timeout can spend 10 × 3 s = 30 s on one failed start before anything is reported.

Decision and threshold: at most 1 Dashboard Server client at any instant. Two is a failure by definition, so the fix either removes the URCap's connection (update it) or guarantees your client holds the slot only while the camera node holds nothing (sequence it).

Two tests: held socket or refused command

Test 1 names the holder. From a PC on the robot's subnet, run this probe — socket, AF_INET, SOCK_STREAM and settimeout are Python's documented socket API, while the IP, port and timeout are the declared inputs from the example above:

import socket

ROBOT_IP = "192.168.1.10"        # your robot's IP address
DASHBOARD_PORT = 29999           # Dashboard Server port
CONNECT_TIMEOUT_S = 3            # seconds

probe = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
probe.settimeout(CONNECT_TIMEOUT_S)
try:
    probe.connect((ROBOT_IP, DASHBOARD_PORT))
    print("connected: socket reachable")
except OSError as err:
    print("connect failed:", err)
finally:
    probe.close()

Run it twice from the same PC: once with the camera program loaded and mid-cycle, once with the camera node commented out. A connect that fails only in the first run identifies the URCap as the holder. A connect that succeeds in both runs clears the socket path and moves the suspicion to commands or pendant mode.

Test 2 separates a refused command from a held slot. With a connect that succeeds, send a status query from the dashboard command set, then your load and play sequence. A readable error message means the safety system or the pendant's mode refused that specific command — on an e-Series, switch the pendant from local to remote in the top-right corner and repeat. No reply at all, with the camera node running, points back to the held slot and to fix 1 below.

Fixes in order of cost

1. Update the camera URCap. The camera maker solved Dashboard Server access over TCP/IP sockets in a release after the versions showing this fault, and the fix is reported as tested. Look for a Dashboard Server or port 29999 entry in its release notes, and match the URCap to your PolyScope version while you are there: a URCap that does not match PolyScope fails in its own ways, and a plugin missing from the program produces different symptoms again.
2. Lock the URCap, then enforce single-client discipline. One device owns the socket: it connects, sends load and play, then disconnects before the program reaches the camera section. Every other device starts the program through its digital inputs or the URCap's own node logic — never through a second connection on 29999.
3. Move inspection data off the Dashboard Server. Port 29999 carries program state, not part coordinates. Results and offsets belong on their own socket, as in send camera offsets to a robot over TCP socket messaging, which keeps the dashboard connection short or absent.
4. Check Remote Control mode on an e-Series first. Until the pendant is switched from local to remote in the top-right corner, accepted commands do nothing. That toggle explains many connect-works, play-does-not reports on its own.
5. Do not downgrade the robot software. The conflict lives in how the camera URCap used the dashboard socket, not in the PolyScope version. A downgrade leaves the same two-client demand in place and adds a validation job.

Prevention: keep one owner of the dashboard socket

• Name the single dashboard client in the design document, and reject any second connection on 29999 in code review.
• Open camera, PLC and result sockets first; touch the dashboard only for load and start commands.
• Close the dashboard connection before any program section that runs the camera node, and reconnect only after the program has stopped.
• Log every connect attempt with its outcome, so a held slot shows up as failed connects clustered around camera sections.
• Bound the retry loop at a few attempts with a short timeout, then raise an alarm instead of retrying in silence.

More socket-level robot-cell patterns, from send loops to recipe switching, are collected on the systems topic page.

Picking the client hardware that holds the sockets

The machine that sends load and play usually also drives the cameras, the light controller and the PLC link, all as persistent sockets. Give the robot its own NIC and subnet so a camera flood cannot delay a start command, and use a fanless unit that mounts in the cell rather than an office desktop. The vision controllers category is built for this role, and its filters let you narrow models by LAN port count, USB 3 port count, memory and processor.

The MV-VC3301H-128G66 covers the small cell: 5+ LAN ports, 3-4 USB 3 ports, 4 built-in light channels, 8 GB of memory, an Intel Core i3, PCIe expansion supported, with a VM6200Pro license included.

Where the cameras take power over the link, the MV-VC5525-256G70-NN adds PoE camera ports, 8 built-in light channels and 32 GB of memory on a 12th-gen Intel Core i5.

The alternative that shrinks the socket count entirely: run inspection on a smart camera — the camera finder lists them — and trigger it over TCP from the PLC or robot program, so no camera node and no extra dashboard demand live inside the robot program. The trigger pattern is in trigger a smart camera over TCP with ASCII commands.

The decision for each case

• URCap can be updated: update it, rerun the two-pass connect probe, and keep your client as the only dashboard connection during starts.
• URCap version locked by validation: enforce single-client discipline — one owner, connect-command-disconnect, digital-input starts everywhere else.
• Connect works but play does nothing on an e-Series: switch the pendant from local to remote in the top-right corner, then resend.
• No acceptable URCap path: move inspection to a smart camera triggered over TCP, so the robot program carries no camera node and the dashboard socket stays free for your client.

Whatever the case, the threshold never moves: one Dashboard Server client at a time on port 29999. If you want a second pair of eyes on the cell's connection layout, contact us with the socket list.