Connect a gripper and wrist camera to offline programming software

You have the robot moving: post processors sorted, targets reachable, the arm repeating. Then two walls appear at once — the teach pendant answers a gripper call with "set_tool_comunication is not supported by this robot", and the programming side answers a script call with error_name_not_found and the script's name. Both errors have boring, fixable causes: the first is a command sent through a channel that does not carry it, the second a name looked up in a station that does not contain it. This guide is for the engineer wiring a Robotiq 2F-85 gripper and a Robotiq wrist camera into a RoboDK cell on a UR5. By the end you will route gripper and camera actions through robot-side I/O behind a small socket server, clear both errors, and know which cables and checks keep the cell running.

Why does the teach pendant say set_tool_comunication is not supported by this robot?

Your UR5 rejects the call because the RoboDK driver that streams motion to the controller has no command for the tool communication port: the gripper's native channel belongs to software running on the pendant, not to the PC-side driver.

RoboDK drives a UR controller along two paths, and neither one carries tool-port messaging:

UR controllers accept program uploads over SFTP only, which is why the transfer port is 22. The tool-port functions your gripper uses live in software on the pendant itself, so a tool-communication call sent from the PC has nothing to land on: the refusal is the controller marking the boundary, not a fault in your cell. If the wider question — which processor owns which device — is still open, settle it with the vision system and robot gripper control architecture guide before wiring anything.

How do you control the gripper without tool communication?

Route the gripper through robot outputs: a short program on the controller turns one integer command into one action, and your offline program sends that integer as a string over a TCP socket, so nothing ever needs the tool communication call.

Two patterns fit, and the choice is a decision, not a preference. Static: when the pick sequence never changes, write the gripper actions into the generated program — open at the approach target, close at the pick target — and production runs with no PC link at all. Dynamic: when the cell must react, with grip chosen per part, a snapshot between picks, or a retry after a missed image, run a small server program on the controller and let the offline program send short commands down one TCP connection.

Three integers cover most cells:

• 1 — gripper open
• 2 — gripper close
• 3 — camera snapshot

The server program drives the gripper from robot outputs; the refused call is never used, so the pendant error cannot come back. Give each device one master: if a pendant-side gripper app also commands the same jaws, disable one path before production.

What is error_name_not_found telling you?

RoboDK looked for an item with that exact name in the currently open station and did not find it; the text after the colon is the name it searched for, which in your case is the Python script.

Check the causes in this order, most likely first:

1. Spelling and case. The match is exact: "Gripper_Close" and "gripper close" are different names. Compare the name in the error text with the station tree, character by character.
2. Right name, wrong station. The script lives in another station file, or on disk, but not in the station that is open; lookups only see the open station.
3. Order of operations. The lookup runs before the item exists — common when a script builds programs on the fly and calls one by name in the same run.

The test is the same for all three: print the names the station holds, then rerun the failing step. The durable fix: fetch each item once at start-up, keep the reference, and pass the reference in the run loop instead of resolving the name on every cycle.

How do you write the robot-side socket program?

Write a loop on the controller that opens a server socket, waits for one connection, reads one command per line, and dispatches it: about thirty lines of script covers open, close and snapshot.

1. Pick a port above 10000 that nothing else on the controller claims, and write that one number into the robot program and the PC sender.
2. On the pendant, start a program that binds the port, listens, and accepts one connection, using the socket functions spelled out in the controller's script reference.
3. Read one line per command, convert it to an integer, and dispatch: 1 opens the gripper, 2 closes it, 3 fires the camera.
4. When the client disconnects, close and accept again; a dropped link must look like a pause, not a crash.
5. Put the listener in a parallel thread of the robot program so motion keeps running while it waits.
6. Answer unknown commands with an error reply and do nothing — a server that guesses turns a typo into a crushed part.

On the PC side, send with a loop that waits for the reply and reconnects after a drop; the robot socket communication send-loop fix shows the pattern that survives a lost link.

How does the wrist camera join the same command set?

Give the snapshot command number 3 and let the robot program pull the trigger: it either toggles the output wired to the camera's trigger input or sends the camera's own network command, so the snapshot happens on the controller's schedule.

Pick one trigger route and give it a single owner. Fire at a stopped waypoint, not on the fly — the arithmetic decides for you. With example numbers, a wrist moving at 250 mm/s during a 4 ms exposure smears the image by:

250 mm/s × 0.004 s = 1.0 mm of smear. One millimetre of smear erases a 0.5 mm feature, so on-the-fly capture fails that inspection outright. Stopped at the waypoint, wait for the arm to settle — 150 ms is a sound first value for a mid-size cobot; measure yours once and replace it — then expose 4 ms. Motion blur is then zero, and the cycle pays about 0.16 s per snapshot: 0.150 s settle + 0.004 s exposure + about 1 ms each for the socket command and the trigger line, with the socket round trip under 1 ms on a switched local link.

Commit to stop-and-snapshot whenever the feature you inspect is under about 1 mm at these speeds. For the PC side of the same trigger when no pendant is in reach, see wrist camera remote snapshot trigger over TCP; if locating works when taught but fails at run time, read stream versus snapshot at run time before touching the socket.

Which cables survive life on a moving wrist?

Use drag-chain rated cable for everything that moves with the arm and standard cable for the fixed run: plan for a bend radius of ten times the cable's outside diameter and a service loop at the wrist.

Size the moving section by arithmetic, not by eye. Measure the dress path from the wrist to the base entry — 1.4 m on a mid-size arm is typical — add 15% for slack and the service loop, and you get about 1.6 m; a 3 m high-flex GigE cable covers that with margin. The 100 m per-segment limit for GigE under IEEE 802.3 means the fixed run into the cabinet is never the constraint. Run gripper power and I/O on their own drag-chain cable, separate from the camera's data line: separate paths separate faults.

Three cables cover a typical wrist build:

The LS-CBL-0199 is a 3 m high-flex GigE camera cable for drag-chain use, with screw locks. The LS-CBL-0300 is an M8 8-pin male-to-open 8-core power and I/O cable, 7 m, built for drag-chain use. The LS-CBL-0211 is a 5 m 12-pin I/O and power cable, for cameras that break their I/O out on 12 pins — wiring a 12-pin camera cable to a robot vision port maps the pins. If the camera shows a red power LED at full wrist extension, read wrist camera and gripper wiring: fix red LED power faults before replacing anything. Match connectors before ordering: cables and the accessories finder list the exact fittings.

What should you check before the first production run?

Walk the chain from ping to picture in one sitting: ten minutes of checks catches the faults that otherwise surface as random mid-shift stops, and each check below names the fault it catches.

Give the sender and the image pipeline a fixed home: a vision controller can carry the programming software, the socket sender and the camera. The MV-VC3301H-128G66 brings an Intel Core i3 processor, 8 GB of memory, 5+ LAN ports and 4 built-in light channels, so the camera, the robot link and a light each hold their own port.

Then work the list:

• Ping the controller and the camera from the sender; a subnet mismatch is the first cause of a link that works on the bench and dies in the cell.
• Connect the socket, send 1, watch the jaws open; send 2 and confirm a full close at reduced speed.
• Send 3 while the camera streams, and confirm one image per command, not one image late.
• Measure the settle time at the snapshot waypoint once, and replace the first-pass value from the worked example with your measured number.
• Pull the wrist cable mid-run: the server must re-accept and the sender must reconnect and continue.
• Rerun your script with the station tree visible; every name it resolves must appear, character for character.
• Generate the URP program and confirm the cell cycles with the programming software closed; only the driver path needs it open.

Bench-test the camera before it goes on the flange: hold it over the parts on a stand — the LS-MNT-0040 is a professional slide-table stand with a 700 mm height and a 400 × 450 mm base — and drive commands 1 through 3 from the sender you will ship. Browse camera stands for the right bench geometry, or start the system configurator at the stand step.

When is the socket workaround the wrong answer?

Skip the socket when your sequence never changes — write the gripper calls straight into the generated program and let the controller run it standalone, with no live PC link during production.

Decide by what changes during the cycle:

• Nothing changes: bake the gripper calls into the URP program, upload it over SFTP, and run production with the PC link off.
• The cell reacts to parts or images: the socket server is the right answer; keep the protocol to integers until you need more.
• The controller is an older CB-series unit: connect through the legacy apiur driver, with the one setting from the table above; the gripper still lives robot-side, exactly as described.
• Several robot brands share one protocol: integers over a socket port to any controller with a scripting language; per-brand tool communication calls do not.
• The camera locates parts on the controller itself: let it, and send only the pick offsets back over the socket — smaller messages, fewer failure points.

The pattern to carry away: motion belongs to whichever path you chose, and gripper plus camera actions belong to a program running on the robot. Keep that split and both errors stay cleared. For more on this layer, see the systems topic page; to have the command set and cable list reviewed for your arm, use the contact page or lay the cell out in the system configurator.