Release note Software version 10.11.x.

Applicable for e-Series and UR-Series

For latest release notes of PolyScope 5, please refer to Release note Software version 5.24.x.x

Date of release: October 16th 2025.

Download HERE

SW 10.11.0 Release Notes

Release Versions:

PolyScope X robot image: 10.11.0
URCap X SDK:
User Manuals: 10.11.0

Key Features

Application Variables feature allows values to persist across application sessions and robot restarts.
License Manager allowing you to manage your licensed UR Software
Additional Safety Functions and Configurations
Toolbox categories, filtering your toolbox into categories allowing for easier navigation and overview
Frame node, create and modify Frames during program execution
Script file import and Script node, import script files into your program
Expression Editor enhancements
Smart skills creation flow enhancements
ProgramTree performance enhancements - Improved UI Performance During Program Editing
Robot API - new RESTful interface replacing the legacy PolyScope 5 Dashboard server
API enhancements (OperatorScreenAPI, ProgramTree API, URCap API)
URScript - new variable category to the script language - shared variable

Compatibility notice

Please note that PolyScope X (all versions) is only supported on Control box version 5.6 (CB5.6).

To verify your Control box version please check the serial number label. It will clearly state "CB5.6" in the model name. If the version listed is not CB5.6 or not listed at all, your Control box does not support PolyScope X. If your robot is purchased as being a PolyScope X Robot, but you do not believe you have the right Control box, please contact Universal Robots with this information so we can ensure you have the right hardware.

PolyScope X Upgrade Kits are available supporting all current Universal Robot models. Please contact Universal Robots or your local Universal Robots Partner to learn more.

PolyScope X User Interface

Application Variables

PolyScope X UI allows users to define Application Variables that persist across program runs and robot restarts. These variables behave like any other program variable and are exported together with the program.

Accessing Application Variables

To view or manage Application Variables:

Navigate to Application→Application Variables

The configuration page displays all variables created for the currently loaded program. Value is updated live when program is running.

Creating a New Variable

Click Create Variable to open a dialog where you can specify:

Name
Type
Initial value

New variable can be added by clicking on the "Create Variable" button. This will show popup window where name, type and initial value can be configured.

NOTE: Once created, the variable's name and type cannot be changed. To modify these, delete the variable and create a new one.

Removing a Variable

To delete a variable:

Click the trashcan icon next to the variable.
The program must be stopped to remove a variable. If the program is running, it will be stopped automatically.

Using variables in programs

Application variables can be used in the same way as any other variable in the program. They are added to a list of variables available in dropdown lists.
Example of assignment node:

Types supported

Following variable types are supported:

Number (integer and floating point): 1, 3.14159
Boolean: True, False
String: "Next part"
Pose: p[0.1, 0, 0.3, 3.14, 0, 0]
Matrix: [[1, 0, 0], [0, 1, 0], [0, 0, 1]]
Array of numbers, strings, poses: [3, 44, 55, 66, 77], ["Start position","Pozycja startowa"], [p[0, 0, 0, 3.14, 0, 0], p[0.3, -0.1, 0.5, 0,1.57, -0.33]]

NOTE:

structs (complex data types) are not supported in Application Variables.
Handle objects (e.g. xmlrpc, ros_subscriber, etc) are not supported in Application Variables.

Showing variable values

Most recent variable values are shown both on the sidebar in variables section and on the Application Variables screen in Application section.

Saving variables

Each program has its own set of Application Variables.

Every time a new program is loaded all variables are cleared and replaced with variables defined in the newly loaded program.

When a program is loaded again, values of Application Variables are automatically restored to the last state.

Variables are saved to internal program database automatically every 10 minutes and when program is stopped.

Application variables support in URScript

In URScript, application variables are implemented with the "shared" keyword. Details of the keyword are discussed in a Controller section. To use an application variable in the script, which was created on the UI, the script should bring the variable into the "program scope" by using the "shared" keyword.

Typically, this is done automatically by PolyScope X and is relevant only when a script is sent directly to the controller either from URCap backend or a remote system.

# Example for bringing shared variable to program scope - value was defined on the UI
shared y
y = y + 1

NOTE:

A shared variable that is created in the URScript does not implicitly become an application variable (on the UI). Creating persistent Application Variables from URScript is not yet supported. Best practice using application variables in URScript would be to create a temporary copy of the variable and work on it in the script. When persistency is needed, copy the temporary variable back into the Application Variable.

shared X
global gX = X
while gX < 100:
if (check_exit_condition()):
X = gX
break
end
do_task()
gX = gX + 1
end

Known limitations

This release has a few limitations that programmers should be aware of. Future releases will be addressing those limitations.

Lists that are already defined as application variables cannot be extended.

When list is defined with specific length in Application Variables then it can be shortened but cannot be extended.
Same limitation applies when list length is shortened in program. When elements are removed from the list then reloading application or restarting robot will permanently reduce list capacity.

Workaround: delete list manually and add again.

Values are not saved when robot is shut down

Very last values of Application Variables might not be saved if robot shutdown is requested while program is running.

Workaround: stop program before shutting down. Variable values are saved to internal persistent database when program is stopped.

Last update might be lost when switching programs

When new program is loaded while current program is still running there is half second time window when application variables are not saved.

Workaround: stop current program before loading new one. Avoid updating application variables
when program could be switched over by operator (i.e. when robot is standing idle, but program is still
running).

License Manager Added to System Manager

A new License Manager has been introduced in the System Manager.

This feature allows users to easily add licenses from Universal Robots to activate new software capabilities and robot features.

Licenses can also be removed when they are no longer required, providing greater flexibility in managing robot functionality.

Safety Tool Position – Safety Configuration

A new feature has been added to the Safety Configuration section, allowing users to define and manage up to two custom Tool Positions, in addition to the default Tool Flange.

Key Capabilities:

Configure up to two custom Tool Positions with precise X, Y, Z coordinates and radius values.
Tool Positions are visualized in the 3D model, with live updates to assist accurate placement.
Enables interaction with safety planes through:
- Collision detection between Tool Position spheres and safety planes.
- Reduced mode activation when a Tool Position enters a safety plane.

How to Use:

Navigate to Safety > Tool Positions.
Add a new tool.
Set the desired radius and position coordinates (X, Y, Z).
Use the live 3D model visualization to fine-tune placement.
Save and apply the configuration.

Once configured, the robot will trigger safety planes based on the defined Tool Position spheres, enhancing operational safety and control.

Restrict Tool Flange Toggle – Safety Configuration

This software release introduces an option to disable collision detection between the Tool Flange and Safety Planes within the robot's Safety configuration.

Purpose: This feature enables definition of tool positions with a radius that will interact with the safety planes by either collision detection with Tool Position and plane or enter reduced mode when tool enters plane.

Key Benefits:

Allow tool flange to pass through safety plane

How to Use:

Navigate to Safety >Planes
Select option to not restrict tool flange (OFF)
Save and apply the configuration.
The robot will now not interact with safety plane if tool flange comes into contact with it.

Three-position Enabling Stop output Safety Functions

Two new Safety Functions can be assigned to output signals in the Safety I/O > Outputs section on the Safety application screen:

3-Position Enabling Stopped: Output signals are LOW when a "3-Position Enabling Stop" is active, HIGH otherwise
Not 3-Position Enabling Stopped: Output signals are LOW when a "3-Position Enabling Stop" is NOT active, HIGH otherwise

These new output Safety Functions allows for configuring safety outputs to send a HIGH or LOW signal depending on whether a "3-Position Enabling Stop" has been triggered by an attached 3-Position Enabling (3PE) Device.

To use the new output Safety Functions, the Safety Configuration must also contain configuration of a 3PE, either the Teach Pendant with 3PE or/and an external 3PE Device. If this is not the case, a warning is displayed, and the Safety Configuration cannot be applied.

Toolbox Categories

The toolbox for program nodes has now been sorted into categories

The categories are Move, Logic, Structure, Tool, and URCaps. There is also an All category, for all program nodes. Nodes can be given a particular category with the "categoryName" field in their corresponding contribution.json file.

Frame Node

A new Frame node has been added, to allow for the easy creation and modification of frames during the program execution. Frames created with this node are referred to as Live Frames, to distinguish them from the frames created from the application section.

There are four actions that can be used in the node: Create Live Frame, Move Frame, Delete Frame, and Change Parent

Create Live Frame

This creates a new frame with the given name. The position of the frame can be specified from the position dialog, as well as the parent of the frame. The position can be given by either an x,y,z,rx,ry,rz, or by an expression

Move Frame

This moves an existing frame to a new position. The frame can be either a frame created in the application, or a live frame. As with the create, the position an be specified in either coordinates or an expression

Delete Frame

This deletes an existing frame. The frame can be one created in the application, or a live frame. Pre-defined frames such as base and world cannot be deleted.

Change Parent

Script Files

Script files can now be imported from disk into PolyScope X. These scripts can then be used in the program through the Script Node.

The script files are managed via the System Manager

They are imported by the +Script File. The file on disk should have the '.script' extension. Script files are kept according to their filename. So re-importing the script file again from disk will overwrite the old one. Once imported, the script file can be deleted or viewed.

The Script Node itself no longer has the script name field.

When the script is edited, there is now the option to import a script from the Script Manager, as well as clear the contents. Note: the script file is copied from the script manager into the script node when inserted. Any future imports of the file into the script manager will not change the existing programs. The programs will need to be manually updated, if necessary.

Expression Editor

There are now shortcuts for inserting functions, IOs, and logic operators into expressions.

The expression tab of the input dialog has been updated. There is now a Quick Access section that allows the user to easily insert an Input, Output, Variable, or Function at the current cursor position.

There is also button to insert common logic operators and values, such as AND, OR, NOT, TRUE, FALSE.

This functionality has been added to every tabbed into dialog, as well as a few node fields that only accepted a string previously, such as the If node.

Smart Skills Creation Flow Update

Dedicated Call-to-Action for Custom Smart Skills

The Smart Skills configuration interface has been enhanced with a streamlined creation flow. Users can now initiate the development of custom Smart Skills directly using a dedicated Create Smart Skill button, eliminating the need to duplicate existing skills.

What’s New:

A clearly visible and accessible Create Smart Skill button.
Removes the previous requirement to duplicate existing skills as a starting point.
Simplifies and accelerates the creation process.
Enhances clarity and usability within the Smart Skills interface.

Impact:

This update improves the user experience by making it easier and more intuitive to build tailored Smart Skills. It reduces setup time and supports faster deployment of customized solutions.

ProgramTree Performance Enhancements

Improved UI Performance During Program Editing

We’ve introduced a set of enhancements to improve responsiveness and user experience when editing programs in the ProgramTree.

What’s New:

Non-blocking UI actions: Users can now continue interacting with insertion points and toolbar actions immediately after making changes to the program. No need to wait for validation and code generation to finish before making the next update.
Continuous program validation: Program changes are validated in the background, allowing for a smoother and faster editing flow.
Smart validation handling: If a validation is already in progress and a new change is made, the current validation is automatically canceled and restarted with the latest program state.
New Validation Bar: A subtle validation status bar has been added at the top of the ProgramTree to indicate when validation is in progress.
Execution safeguard: Programs cannot be started while validation is still running, ensuring correctness and stability. Impact: These upgrades significantly improve perceived performance and responsiveness, enabling users to iterate quickly and intuitively without being blocked by background processes.

Impact:

These upgrades significantly improve perceived performance and responsiveness, enabling users to iterate quickly and intuitively without being blocked by background processes.

Robot API

Introduction

The Robot API is a new RESTful interface introduced as part of PolyScope X, replacing the legacy PolyScope 5 Dashboard server. This API enables external systems to control and monitor robot behavior programmatically and is only available when the robot software is operating in Remote Mode.

By adopting REST (Representational State Transfer), the Robot API offers a modern, standardized, and scalable approach to robot control. This transition facilitates easier integration with external automation systems and cloud-based orchestration tools.

Key Features

RESTful Architecture

Uses standard HTTP methods (PUT) and JSON payloads.
Designed for compatibility with modern software development practices.

Remote Mode Requirement

The API is accessible only when the robot is in Remote Mode, ensuring safe and deliberate external control.

Endpoints Summary

Robot State Domain

Provides control over the robot's operational state.

PUT /robotstate/v1/state
- Function: Change the robot's state.
- Request Format: { "action": "UNLOCK_PROTECTIVE_STOP" }
- Supported Actions:
  - UNLOCK_PROTECTIVE_STOP
  - RESTART_SAFETY (will not close potential error-dialogs for safety reasons)
  - POWER_OFF
  - POWER_ON
  - BRAKE_RELEASE
- Response Codes:
  - 200 OK: State changed successfully.
  - 409 Conflict: Invalid state transition (e.g., robot not in PROTECTIVE_STOP).
  - 500 Internal Server Error
  - 504 Gateway Timeout
  - 422 Validation Error

Program Domain

Provides control over robot programs.

PUT /program/v1/load
- Function: Load a program by name.
- Request Format: { "programName": "example" }
- Response Codes:
- 200 OK: Operation successful.
- 500 Internal Server Error
- 422 Validation Error
PUT /program/v1/state
- Function: Change the program state.
- Request Format: { "action": "play" }
- Supported Actions:
  - play
  - pause
  - stop
  - resume
- Response Codes:
  - 200 OK: Operation successful.
  - 500 Internal Server Error
  - 422 Validation Error
GET /program/v1/state
- Function: Fetch the current Program state
- Response Codes:
  - 200 OK: Operation successful.
  - 500 Internal Server Error

Developer Notes

All endpoints are served under the base URL:
http://{host}/universal-robots/robot-api
Documentation and examples/try-it-out is available on the following URL:
http://{host}/universal-robots/robot-api/docs
Error handling is standardized using the following schemas:
- APIError
- APIResponse
- HTTPValidationError
Use RobotStateResponse and LoadProgramRequest schemas for structured communication.

API

OperatorScreenAPI Update

New Services Available in OperatorScreenAPI

The OperatorScreenAPI has been extended to include the following services:

ToolService
MountingService
FramesService
MotionProfilesService
ScriptFileService
TreeBuilder

These services were previously available elsewhere in the system and are now integrated into `OperatorScreenAPI` to improve accessibility and consistency across operator screen configurations.

Compatibility & Impact

These additions are non-breaking and fully backward compatible.

Existing consumers of OperatorScreenAPI do not require changes unless they wish to leverage the new services.

ProgramTree API Update

New Function: addBlockChildNode

A new method has been added to the ProgramTree service to support dynamic program structure manipulation:

/**

* Add a node to the root of a program block, for example the main program or

* the before start

* @param node and other add parameters

addBlockChildNode(node: AddBlockChildNode): Promise<void>

/**

* Describes information required to add a node to the root of a program block

* @property insertionRelativeToBlock Which position to insert. Either first or last

* @property block Where to insert. Either the main program or the before start

* @property node The node to insert

* @property changeSelection Whether to change the selected node after the add. If true or undefined, the

* selection will be changed to the newly added node, if false the selection will remain unchanged

export interface AddBlockChildNode {

readonly insertionRelativeToBlock: InsertionEnum.INTO_FIRST |

InsertionEnum.INTO_LAST;

readonly block: BlockEnum;

readonly node: Readonly<ProgramNode | BranchNode>;

readonly changeSelection?: boolean;

}

export enum BlockEnum {

MAIN_PROGRAM = 'mainProgram',

BEFORE_START = 'beforeStart',

}

Description:

Allows adding a node to the root of a program block, such as the main program or the "before start" section. This enables more flexible and programmatic construction or modification of program trees.

Parameters:

node: An object of type AddBlockChildNode containing the node details and additional parameters required for insertion.

Controller

Shared variables

This release introduces new variable category to the script language - shared variable.

Shared variables are created by prefixing variable name with "shared" keyword. Shared variables are created in memory space independent from global and local program variables. This allows them to keep values between program restarts (including safety stops).

NOTE: Application Variables in PolyScope X are implemented on top of shared variables functionality. Namespace of variables (global and local) is overlapping with shared variables namespace. Compile error will be generated if variable with the same name is both declared global and shared.

Examples for declaration of shared variables in URScript:

# Example for new shared variable with value assignment.

# This assignment will also overwrite shared variable value if it is already defined.

shared x = 100

# Example for bringing shared variable to program scope - value was defined in another program or Polyscope UI and will be used in later in script

shared y

After declaration variables can be used in the same way as any other variable in script.

Differences between global and shared variables

Following table is summarizing differences and similarities between variables declared as shared or global.

	global	shared
Declaration in URScript	"global" keyword before variable name
Scope within program	Visible in entire program scope and in all functions	Visible in entire program scope and in all functions
Scope relative to other programs	Only visible within execution unit of single program	Visible across all running programs
Lifetime	Created when program is compiled, Destroyed when program stops	Created when program is compiled (including secondary programs) or using ROS2 API, Destroyed only explicitly by ROS2 API call, or when controller is shut down.
Type assignment	Type is set on first assignment Type cannot be changed later	Type is set on first assignment Type cannot be changed later
Type compatibility	All supported types	All supported types except "struct", and handles (XmlRPC, ROS2, Ethernet/IP)

URCap API (Engineering Preview)

ROS2 interface allows to interact with shared variables.

This release does not document any API, as breaking changes are expected.

API functions:

Service for creating variables and setting values
Service for deleting individual variables
Service for clearing all variables
Publisher showing current variable values periodically

Improved usability of Constrained Freedrive

Constrained freedrive has been significantly improved. In particular for tools with long TCP offsets, such as welding tools.

Freedrive is constrained, when one or more axes are locked.

It is now easier to position the tool accurately.

The improvements are effective both when a guiding force is applied directly on the tool or one the robot arm.

You can adjust the sensitivity of freedrive by adjusting the speed slider. Low speed slider is good for fine positioning.

Other Controller features

Introduced jerk_gain_scaling_set() and jerk_gain_scaling_get() builtins; Allow users to reduce system vibrations and achieve smoother motions in optimoveX and moveX (in combination with motion version 2).

Bug fixes:

Embedded

Resolved issues where an E-Stop activation would fail to remove power from motors if they were vibrating at a specific frequency, if the vibration was triggered by a instability in the control, vibrations from programs would not cause the issue.
Fix IMMI faulting on timeout during first start-up after applying a safety configuration.
Improved motion tracking on UR-Series when target is oscillating at slow speeds (e.g. during weld weaving)
Fixed bug where joints having been originally delivered with software between SW5.6 and SW5.9.2 could not be updated directly to SW5.20 or newer
Improved motion performance at joint speeds below 800µrad/s in the base and shoulder of UR8 Long and UR15 robots.

Controller

Fix for robot moving slower than expected under certain conditions when using movej and motion version 2

PolyScope

Fixed issue where, in some situations, tapping the Lock button on the Safety application screen would inform the user that the Safety Configuration contained unapplied changes even though no changes had been made.
Fixed issue where, in some situations, a Safety Function assigned to an output signal pair would be falsely removed on the Safety I/O > Outputs on the Safety application screen.
Fixed issue where the Matrix type was not supported for variables.
Fixed issue in the Call program node where, in some situations, the Function drop-down list was not cleared when making a new selection in the Module drop-down list.
Fixed display issue of log message when using a textMsg() script node.
Fixed wait node not allowing 0 as parameter.
Fixed display issue in joint move panel.
Fixed backups for Log History to append up to 30M

Support Files:

Some column names in real-time data had either wrong names, or missed indexes (joint id or axis)

previous RELEASE NOTES: