controlling a RG6 gripper with a onrobot URcap

[libishm1]

Hi everyone,

I’m working with an OnRobot RG6 gripper using the official OnRobot URCap.The gripper works perfectly when programmed directly on the PolyScope pendant, no issues there.

However, I’m running into trouble when trying to load custom URScripts generated by the Robots plugin in Grasshopper.

In my custom script, I’ve included the OnRobot initialization blocks and I’m calling the gripper using: on_return = rg_grip(9.1, 36.0, tool_index = 0, blocking = True, depth_comp = False, popupmsg = True)rg_payload_set(mass = 0.0, tool_index = 0, use_guard = True) to open the gripper and close the gripper in the custom commands for the pick locations respectively,

These commands are placed in the appropriate pick/hold sections.

What works

The program3.script file exported from the UR pendant runs correctly.

The RG6 responds reliably inside a URP program.

What does NOT work

The custom URScript from Grasshopper fails to load, even though it includes the same initialization logic.

The robot reports an installation-related error before execution begins.

I have attached the UR robot script generated by the robot pendant as program3.script for reference. Also, the custom script generated by me from grasshopper,

Has anyone successfully integrated GH Robots, while maintai

ning RG6 functionality or similar grippers.

Reference - [(1770) UR Robot Grippers and UR Caps in Grasshopper - YouTube] (https://www.youtube.com/watch?v=9ENygL6V1Ao)

any help is appreciated,
! error_message
files.zip

Thanks in advance,

[LoyWeiWin]

Maybe try this instead (with the "custom mode") function? and the change the weight of the end effector using the "create tool" function rather than hard code it? Hopefully this helps.

[libishm1]

At the moment, the URCap does not allow direct input in the standard URScript format. Because of this limitation, I had to embed a small URScript program directly in the PolyScope pendant and load it from there. To make this workable, I reverse-engineered the URCap’s internal script structure and wrote a small Python utility to reformat my generated code so it matches what the URCap expects.

This workflow is still a work in progress, but the reformatted script does execute correctly on the robot. That said, there are unresolved issues—most notably, the gripper rotates during the pick and place motions themselves rather than during the transition between them.

This reflects the current state of progress from last year. I’ll update this as the workflow evolves. I’m also curious whether there is a simpler or more robust way to make the URCap work seamlessly with the Robots plugin, without needing this intermediate reformatting step.

[visose]

If you leave an em dash behind its even more obvious 😄

[libishm1]

I seemed to have missed that 😄, I used copilot to reformat my original text, and also ChatGPT for code completion.

[visose]

Proposed answer:

Robots generates and uploads plain URScript wrapped in a simple URP Script node. It does not recreate the OnRobot URCap program nodes or their generated installation/program boilerplate. In the current UR upload path, the URP template is just a Script file node and it references the default installation, so URCap-defined functions such as rg_grip(...) are only available if the OnRobot-generated script/header and installation context are also present.

The robust options are:

1. Keep the OnRobot gripper logic inside a PolyScope/URCap program and let Robots handle the robot motion. Trigger the gripper program/state through a stable interface such as digital IO, registers, or another controller-side handshake.

2. If you want everything inside the Robots-generated script, put the full OnRobot-generated initialization/header from a working pendant-exported script into a Custom Command declaration, then call rg_grip(...) from target Custom Commands. This can work, but it is brittle because URCap-generated script can change between OnRobot/PolyScope versions and may depend on the active installation.

3. If the failure is installation-related, check that the generated URP is using the same installation where the OnRobot URCap is configured. Robots currently emits a simple URP Script node using the default installation, so a future improvement could be making the UR installation name/path configurable for UR uploads.

For the gripper rotating during pick/place: check the Tool definitions assigned to the targets. Robots emits set_tcp(...) and set_payload(...) when the active Tool changes. If the empty-gripper and loaded-gripper tools have different TCP orientation or origin, the robot motion will be planned/executed with a different TCP. Keep the TCP frame identical for both states, and only change payload/collision representation where needed, or insert explicit transition targets before changing gripper state.

[libishm1]

OnRobot RG6 (URCap) + Robots plugin: rg_grip scope on upload, and wrist reorientation on tool change UR10e

Setup: UR10e, PolyScope 5.24.0, OnRobot RG6 via URCap. Robots 2.1.0, Rhino 8. Generating motion in GH and uploading to the controller.

1. rg_grip is out of scope on the script socket. URCap functions (rg_grip, rg_payload_set) only exist in the preamble PolyScope injects when it loads a .urp. URScript on port 30002 runs without that preamble, so the calls fail. The only thing I've gotten to work is a two-file deploy - a plain .script plus a pendant-saved .urp with installation="default" whose <Script type="File"> points at the .script.

Is that two-file deploy the intended way to use a URCap gripper with Robots, or is there a native/supported path?
Can the plugin's UR upload target a specific installation or wrap the script in a .urp carrying installation="default"?
If the recommendation is to keep gripper logic in a separate URCap program and let Robots handle only motion, what handshake do you suggest (IO, registers)?

2. The wrist reorients during pick/place. I've traced it to three causes: tool changes emit set_tcp/set_payload (so movel after a switch solves against a different frame), axis-angle branch ambiguity (rx,ry,rz vs its negation travel different paths), and movel IK-branch selection depending on start config.

Is keeping the TCP frame identical between the empty/loaded states (changing only payload) the right way to avoid the tool-change reorientation?
Is there a way to pin the IK configuration / preferred posture, or force reorientation at an explicit transition target before the gripper state changes?