Release of URCap SDK 1.11.0, Polyscope 5.9 and 3.14

UR News & Announcements
1

Dear valued developers,

Universal Robots is delighted to announce, that we are now releasing a new software, to continuously deliver more value to you and our customers.The new release consist of:

  • PolyScope 5.9.1 for e-Series
  • PolyScope 3.14.1 for CB3
  • URCap SDK 1.11.0 including URCap API 1.11.0 for both platforms

Release notes for the e-Series:

KEY FEATURES

  • Unscheduled Stop Output: The two new output actions indicates if a program terminated unscheduled.
  • Output Actions extended to registers: General purpose registers (integer and float) and MODBUS registers now supports Output Actions.
  • Features out of reach: Create and Edit Features outside reach of the robot.
  • URCap API:
    • Support for the Multi-Gripper capability (support for multiple grippers) for Gripper driver contributions and conformant grippers
    • Support for registering the capabilities supported by a conformant gripper
    • Support for querying whether a specific capability is supported by a gripper device
    • Support for creating configurations for Gripper Nodes which use a multi-gripper device
    • Improved support for fixed position configuration of Waypoint program nodes

POLYSCOPE GUI

UNSCHEDULED STOP OUTPUT:

Two new output actions which indicates if a program terminated unscheduled by a Protective stop, Fault, Violation or Runtime exception have been added. The output actions can be applied to all outputs of type:

  • Digital standard general purpose, configurable and tool
  • Analog standard general purpose and tool
  • MODBUS (digital and registers)
  • General purpose registers (boolean, integer and float)

OUTPUT ACTIONS EXTENDED TO REGISTERS:

General purpose registers (integer and float) and MODBUS registers now support Output Actions, that are triggered by events like stop, pause, play or unscheduled stops.

Note: In the previous versions it have been possible to set actions on MODBUS registers, even though they had no effect on the register. This change could affect programs, where the registers where previously set and it is advised to verify the actions assigned to MODBUS signal.

FEATURES OUT OF REACH

A new way of adding and editing features

  • New “Edit” button on the feature screen takes you to a Feature editor
  • Define and/or edit features directly, with position and rotation coordinates
  • Define and/or edit features without using the robot arm
  • This means the features don’t have to be in reach of the robot arm

PAYLOAD NOTIFICATION

When the installation payload has not been set, or is set to zero, the user is reminded that the payload should be configured correctly, before operating the robot. This is visible as a warning on the TCP Configuration and AutoMove screens.
Note : Always specify the correct payload, according to the tooling and workpiece mounted on the robot, before moving or operating the arm.

URCAP SOFTWARE PLATFORM

COMPATIBILITY NOTICE: BEHAVIOR CHANGE FOR REGISTRATION AS A CONFORMANT GRIPPER DEVICE

This release will introduce a minor behavior change in the URCap API that might affect existing URCaps. The change will not break backwards compatibility of the API itself, but the behavior of one specific method will be affected, which can cause exceptions to be thrown in some cases. The behavior change will only affect “regular” (non-driver contribution) URCaps which register as being conformant with a PolyScope gripper device.

Changes:

  • It will only be allowed to register a URCap as conformant with a PolyScope gripper device once. If a URCap attempts to register as a conformant gripper device multiple times, the ‘registerAsGripper(Class)’ method in the ‘GripperRegistrationManager’ interface will now throw a ‘DeviceAlreadyRegistered’ exception.
  • It will not be allowed to register a URCap as conformant with a PolyScope gripper device at the wrong time. If a URCap registers as a conformant gripper device outside the scope of the call to either the implementation of (the overridden) ‘SwingProgramNodeService.configureContribution(ContributionConfiguration)’ (for Swing-based URCaps) or ‘ProgramNodeServiceConfigurable.configureContribution(ProgramNodeConfiguration)’ (for HTML-based URCaps), the ‘registerAsGripper(Class)’ method will now throw a ‘CalledOutsideMethodScope’ exception.

URCAP API:

Multi-gripper support for gripper URCaps

Added support for the Multi-Gripper capability for Gripper driver contributions and “regular” URCaps which is conformant with a PolyScope gripper device:

  • This new capability can be registered, if the gripper (URCap) supports a set of multiple individual grippers/zones from which the end user can select an individual gripper/zone to operate

  • When this capability is registered, it is possible to support two new use cases:

    • A gripping device physically constructed in a way where it is logically partitioned in multiple zones/grippers (“built into” the device)
    • A gripper URCap with the option of supporting a number of separate, identical grippers which can be mounted on the robot at the same time (for instance using a special mounting bracket). Typically the end user has the choice of using either a setup with a single gripper or one with multiple grippers

  • Note: It is a requirement for registering this capability that all of the individual grippers are identical in terms of the supported set of capabilities, i.e. they will all have to support any other capability, e.g. the Width capability, that has registered (using the ‘GripperCapabilities’ interface)

  • For each individual gripper, it is possible to independently:

    • Add a TCP for the gripper
    • Dynamically enable and disable the gripper:

      • Disabling a gripper will have the following effects:

        • The disabled gripper and its associated TCP will not be available (nor visible) in Polyscope
        • The disabled gripper will not be accessible to other contributions (e.g. contributed by other 3rd party URCaps) when creating Gripper Node configurations with a predefined individual gripper selection
        • Any existing selection of the disabled gripper will become unresolved and will be displayed accordingly in drop-down boxes in PolyScope, e.g. in the Gripper toolbar and program node as well as in other 3rd party contributions
        • These effects will be reverted when the gripper is enabled again

      • The enable/disable functionality can be used, if the gripper URCap is meant to support both a use case with only a single gripper as well as supporting the option of mounting several separate, identical grippers on the robot. In this case, the secondary gripper(s) can be created in an initial disabled state, and then enabled when the end user is using a multi-gripper setup.

    • Dynamically adjust the capability parameters, including the value range and default values, of any (other) registered capability (i.e. the Width capability, Force capability, etc.) exclusively for the gripper
    • See the new ‘MultiGripperCapability’ interface in the ‘contribution.driver.gripper.capability’ Java package

  • See the new ‘registerMultiGripperCapability(GripperListProvider)’ method in the existing ‘GripperCapabilities’ interface (in the ‘contribution.driver.gripper.capability’ Java package)

  • See the new ‘contribution.driver.gripper.capability.multigripper’ Java package

  • Gripper toolbar and program node (only relevant for URCaps implementing the ‘GripperContribution’ interface):

    • When this capability is registered, the user will be able to select which individual gripper to operate in the Gripper toolbar and program node
    • UI elements in the Gripper toolbar are now laid out in a single column

  • When an individual gripper has been selected in the Gripper Node, the name of that gripper will be included in the title of the Griper Node in the Program Tree. The only exception is when only one gripper is enabled, in which case the name of the gripper driver contribution (returned by the ‘getTitle()’ method in the ‘GripperContribution’ interface) is used.

  • When only one individual gripper is enabled, this gripper will automatically be selected when a new Gripper Node is inserted into the Program Tree

Improved support for conformant grippers

“Regular” URCaps, which are conformant with a PolyScope gripper device, can register the capabilities supported by the gripper (the same way as gripper driver contributions), such as force gripping and support for multiple grippers

  • Note: Currently, the API only supports that a template designer can build Gripper Node configurations containing information about the gripper action (grip or release) as well as a selected individual gripper if the gripper supports the multi-gripper capability. There is no harm in registering all supported capabilities as this will carry over to when the functionality is supported for building the configurations.
  • See the new ‘getGripperCapabilities()’ method in the existing ‘GripperRegistrationConfiguration’ interface (in the ‘contribution.driver.gripper.conformant’ Java package)

Introduced two new exceptions for inappropriate registrations:

  • Introduced the ‘DeviceAlreadyRegistered’ exception which will now be thrown by the ‘registerAsGripper(Class)’ method (in the ‘GripperRegistrationManager’ interface) if an attempt is made to register as a conformant gripper device multiple times
    • See the new ‘DeviceAlreadyRegistered’ exception in the existing ‘domain.device’ Java package
  • Introduced the ‘CalledOutsideMethodScope’ exception:
    • Will now be thrown by the ‘registerAsGripper(Class)’ method (in the ‘GripperRegistrationManager’ interface), if an attempt is made to register as a conformant gripper device outside the scope of the call to either the implementation of (the overridden) ‘SwingProgramNodeService.configureContribution(ContributionConfiguration)’ (for Swing-based URCaps) or ‘ProgramNodeServiceConfigurable.configureContribution(ProgramNodeConfiguration)’ (for HTML-based URCaps)
    • Is thrown by the register-methods in the ‘GripperCapabilities’ interface, if an attempt is made to register a capability outside the scope of the call to either the implementation of (the overridden) ‘SwingProgramNodeService.configureContribution(ContributionConfiguration)’ or ‘ProgramNodeServiceConfigurable.configureContribution(ProgramNodeConfiguration)’.
    • See the new ‘CalledOutsideMethodScope’ exception in the new ‘util’ Java package

Improved support for configuration of Gripper Nodes

Added support for querying whether a specific capability is supported by a gripper device:

  • When a capability is supported by the gripper device, it is possible to access information which can be used to configure the supported capability when creating a configuration for a Gripper Node
  • Currently, only the multi-gripper capability is supported for this functionality
  • See the new ‘getCapabilitySupport(Class)’ method in the existing ‘GripperDevice’ interface (in the ‘domain.device.gripper’ Java package)
  • See the new ‘device.gripper.capability’ Java package

URCaps can read and configure the individual gripper selection of the configuration for a Gripper Node (if the gripper device used by the node supports the multi-gripper capability):

  • See the new ‘MultiGripperSupport’ interface in the new ‘device.gripper.capability’ Java package

  • In the existing ‘domain.program.nodes.contributable.device.gripper.configuration’ Java package see:

    • New interface ‘SelectableGripper’
    • New method ‘getGripperSelection()’ in the existing ‘GripActionConfig’ and ‘ReleaseActionConfig’ interfaces
    • New methods ‘setEmptyGripperSelection()’, setGripperSelection(Optional)’ and ‘setGripperSelection(SelectableGripper)’ in the existing ‘GripActionConfigBuilder’ and ‘ReleaseActionConfigBuilder’ interfaces

Added the new ‘UndefinedActionConfig’ interface representing a configuration where the gripper action (i.e. grip or release) has not been selected:

  • A configuration retrieved from a Gripper Node can be cast to this interface, if the gripper action is undefined (the existing ‘UNDEFINED’ value of 'ConfigType defined in the ‘GripperNodeConfig’ interface)
  • Note: It is only relevant to use this interface, if the gripper device used by the Gripper Node supports the multi-gripper device and there is a desire to access the individual gripper selection
  • See the new ‘UndefinedActionConfig’ interface in the ‘domain.program.nodes.contributable.device.gripper.configuration’ Java package.

Added support for determining if an existing (or a newly created) configuration is for multi-gripper device:

  • This functionality can used to determine if a Gripper Node configuration contains an individual gripper selection (which could be empty)
  • See the new ‘isForMultiGripper()’ method in the ‘GripActionConfig’, ‘ReleaseActionConfig’ and ‘UndefinedActionConfig’ interfaces (in the ‘domain.program.nodes.contributable.device.gripper.configuration’ Java package)

Introduced new exception for incompatible Gripper Node configurations:

  • The ‘setConfig(GripperNodeConfig)’ method (in the ‘GripperNode’ interface) will now throw the new ‘UnsupportedConfig’ exception if an attempt is made to apply a configuration to a Gripper Node when:

    • The configuration uses a capability which is not supported by the gripper device used by the Gripper Node. This can occur when applying a newly created configuration with a preselected individual gripper to a Gripper Node which uses a single gripper device (i.e. a gripper device that does not support the multi-gripper capability).
    • An existing configuration is taken from one Gripper Node and reapplied to another Gripper Node, which uses a gripper device different from the gripper device used by the original node (i.e. when reapplying an existing configuration the two gripper devices must be identical).
    • See the new ‘UnsupportedConfig’ exception in the ‘domain.program.nodes.contributable.device’ Java package

Improved support for configuration of Waypoints:

  • Added support for creating a fully defined fixed position configuration for a Waypoint Node by additionally specifying the TCP offset

    • See the new ‘createFixedPositionConfig(Pose, JointPositions, Pose …)’ method in the existing ‘WaypointNodeConfigFactory’ interface (in the ‘domain.program.nodes.builtin.configurations.waypointnode’ Java package).
    • Deprecated the ‘createFixedPositionConfig(Pose, JointPositions, BlendParameters, WaypointMotionParameters)’ method in the ‘WaypointNodeConfigFactory’ interface

  • Introduced new exception for unreachable target positions:

    • The ‘setConfig(WaypointNodeConfig)’ method in the ‘WaypointNode’ interface will throw the new ‘UnreachablePositionException’ exception (throwing an exception is existing behavior) when it is not possible to compute joint positions corresponding to the specified target pose
    • See the new ‘UnreachablePositionException’ exception in the ‘domain.program.nodes.builtin’ Java package

URCAP SDK:

New/Updated URCap Samples

Added new ‘Dual Zone Gripper’ sample which demonstrates how to create a gripper driver contribution for a multi-gripper that:

  • Supports multiple permanently enabled, individual grippers
  • Adds a dedicated TCP for each individual gripper
  • Dynamically adjusts the parameters of a capability (after it has been registered) for all individual grippers

Added new ‘Dynamic Multi-Gripper’ sample which demonstrates how to create a gripper driver contribution for a multi-gripper that:

  • Supports both a single gripper setup and multi-gripper setup
  • Adds a dedicated TCP for each individual gripper
  • Dynamically adjusts the parameters of a capability (after it has been registered) exclusively for each individual gripper

Updated the following samples to use the new way of obtaining a user-defined robot position with the ‘getUserDefinedRobotPosition(RobotPositionCallback2)’ method in the ‘UserInteraction’ interface instead of the using the deprecated ‘getUserDefinedRobotPosition(RobotPositionCallback)’ method:

  • ‘Ellipse’ and ‘Ellipse Swing’
  • ‘Tool Changer Swing’
  • ‘Create Feature Swing’

Updated the following samples to use the new ‘createFixedPositionConfig(Pose, JointPositions, Pose, …)’ method in the ‘WaypointNodeConfigFactory’ interface, where the TCP offset for the Waypoint configuration can be specified, instead of using the deprecated ‘createFixedPositionConfig(Pose, JointPositions, BlendParameters, …)’ method:

  • ‘Ellipse’ and ‘Ellipse Swing’
  • ‘Create Feature Swing’

Updated the XML-RPC server (files hello-world.py and AbyssServer.cpp) in the ‘My Daemon’/‘My Daemon Swing’ samples to minimize port close/open cycles

Documentation

Updated the “URCap Gripper Driver” document (gripper_driver.pdf file):

  • Added two new subsections in the “2.3: Capabilities (Optional)” section:

    • The “2.3.1: Parameter-based Capabilities” subsection contains the description of the existing capabilities from the previous version of the document
    • The “2.3.2: Multi-gripper Capability” subsection describes the new multi-gripper capability

  • Updated the “2.6.1: TCP Contribution” section with information about:

    • Multi-gripper TCPs

    • Migrating from a single gripper URCap to a URCap supporting multiple grippers

    • How any attempts to modify existing TCPs during load of installations are ignored

    • How TCPs will be become inaccessible if the class of a gripper driver contribution is renamed

  • Updated sections “3.3.2: Grip Action”, “3.3.3: Release Action” and “2.4: Feedback Capabilities (Optional)” with information about generating script code for the individual gripper selected by the end user

  • Updated section “5.2: Supporting Translations” with information about supporting translations in multi-gripper URCaps

Updated the “Registering a Regular Contribution as a Conformant Device” document (registering_conformant_device.pdf file):

  • Added new section “5: Registering Capabilities” which describes how to register the capabilities supported by a conformant gripper

CONTROLLER

RTDE - SCRIPT CONTROL LINE NUMBER

Script control line number is added to RTDE and can be subscribed by the clients using field name “script_control_line”. This field will provide script line number that is actually in control of the robot given the the robot is locked by the one of the threads in the script. If the no thread is locking the robot this filed is set to ‘0’.

NOTIFICATION IN CASE OF RISK OF EXCESSIVE WEAR ON ROBOT

A warning is shown in the log if the executing program introduces torque levels or torque jumps that could damage the robot hardware. The error code in the log has the format C173Ax for high torque levels and C174Ax for high torque jumps. The value of x will depend on which joint it concerns. In such cases the new ’ pause_on_error_code() ’ script command can be applied to pause the program when the torque warning occurs. The new script command supports pause on any specific error code. See the script manual for further information.

MATRIX AND SCALAR OPERATION SUPPORT IN SCRIPT

It is now possible to assign a matrix to a variable as well as do matrix math like multiplication, transpose and inverse. In addition scalar operation are also added with support for both Matrix and List.

Matrix and Scalar support example:

#  Matrix Assignment
m = [[1,2,3],[4,5,6]] # Assign a any dimension matrix
two = m[0,1]          # Get an specific index
m[0,0] = 100          # Assign an specific index
strM = to_str(m)      # Convert to string
msize = size(m)       # Get a [rows, columns] list with the dimensions of the matrix

#  Matrix operations
A = [[1, 2, 3, 4], [5, 6, 7, 8], [9, 10, 11, 12]]
B = [[1, 2, 3], [4, 5, 6], [7, 8, 9], [10, 11, 12]]
C = A * B             # 3x3 = 3x4 * 4x3
Ct = transpose(C)     # Transpose
Cinv = inv(C)         # Inverse

# Scalar operations works for both Matrix and List
a = 0.5 * [1,4,6]
b = [1,4,6] * 0.5
c = [1,4,6] / 2
d = 2 / [1,4,6]
e = [1,4,6] + 3
f = 3 + [1,4,6]
g = [1,4,6] - 3
h = 3 - [1,4,6]
g = [1,4,6] % 3
h = 3 % [1,4,6]

# List List operation is also supported for *, /, +, - and %. The list shall have the same dimensions
# Example: List * List multiplication
Al = [1,2,3,4,5]
Bl = [6,7,8,9,10]
Cl = Al * Bl # Results in [6,14,24,36,50]

For more information see the updated script manual.

EMBEDDED

DASHBOARD SERVER

This release introduces an internal queue to the dashboard server where dashboard actions, send from a dashboard client, are offloaded into.

Actions will be executed in order received from the dashboard client, as before, and each client will have it’s own queue.

In the event the network connection between the dashboard server and a client is interrupted, either by technical problems or by terminating the client, the dashboard server will discard all actions in queue that are not yet executed and will try to discard any action that is currently being executed.

In case of actions being discarded when connection is interrupted, a warning log entry will be added to the Polyscope log.

BUG FIXES

POLYSCOPE GUI

  • Fixed issue where the speedslider was greyed out, and not at 100%, in Automatic mode. Now when going to Automatic mode, the speed is set to 100%, and the speedslider is not visible.

  • Fixed “Move here” button on waypoints, so the automove will now use the same move-type as the move node the waypoint is under (if possible).

  • Fixed issue on the Freedrive panel, where there was not enough space for a label in certain languages.

  • Fixed issue where large programs with many waypoint nodes, would make Polyscope sluggish and unresponsive

  • Fixed issue where visiting the Move tab would stop a running program and enable the unsaved changes indicator for the installation, if the orientation of a TCP had been modified in the installation prior to running the program

  • Fixed issue where the name of a variable would not be “released” (i.e. it was not possible to, for instance, assign a new variable that name) after all references to that variable had been removed from the program. This would occur, if the variable previously was used by a variable Waypoint.

  • Fixed issue where a running program would not be stopped when a different program was loaded in the SubProgram Node

  • Fixed issue where the unsaved changes indicator for the installation would become enabled if the Tool I/O installation screen was selected

  • Fixed issue where a non-standard warning state was displayed in the “Object Height” field in the Palletizing Node when the field was empty (a yellow border was shown instead of a yellow background)

  • Fixed issue where files and directories were not correctly sorted alphabetically in the File Manager if some of the files/directories started with a capital letter

  • Fixed issue where undo/redo did not work for changes to the “Keep SubProgram Updated with this Program” checkbox in the SubProgram Node

  • Fixed issue where the feature variable would not be inserted into an expression when the feature was selected in the “Variable” drop-down box in the Expression Editor. During program execution the (fixed) pose of the feature (defined in the installation) would be used instead of the feature variable.

  • Fixed issue where the cursor was not positioned at end of the feature name (e.g. “Point_1_const”) when a feature was inserted in an expression using the “Pose” drop-down box in the Expression Editor

  • Fixed issue where the value of an user-defined variable could be overwritten during execution of a program, if the program contained a Switch Node and the name of the user-defined variable was identical to the variable name used by the Switch Node (e.g.“switch_1”)

  • Fixed issue where a program variable would be initialized to a value from a previously loaded program, if the previous program used a variable with the same name and the variable was assigned an initial value in the Init Variables Node

  • Fixed issue where it was not possible to create new installations after an unhandled exception had occurred in an installed URCap while creating a new installation

  • Fixed issue where the unsaved changed indicator for the installation was not enabled when an installation was loaded after a new URCap had been installed or an existing URCap had been updated. The indicator will now the enabled in the following situations:

    • The existing installation (being loaded) was saved before the new URCap was installed and the new URCap makes a contribution to the installation
    • The existing installation (being loaded) was saved when the old version of the updated URCap was installed and the new version of the URCap now makes a new contribution to the installation, for instance, contributes a new installation entity, such as a TCP, feature, etc.

  • Fixed issue where the value of an installation variable was not saved to file, if the variable’s value was updated in a running program as the very last thing before the program stopped

  • Fixed issue where it was not possible to load some older programs if the program contained Force nodes

CONTROLLER

  • Fixed issue where robot would enter a Protective Stop when requested to execute a motion or program instantly after releasing the brakes

  • Fixed blend algorithm for MoveL movements with large orientation change and very small translation.

    • Fixed issue where blending during MoveL could result in aborted program execution or the robot drifting away from the expected trajectory. The issue was related to the combination of orientation blend paths and positional blend paths. In scenarios where the required joint movements of the MoveL blend are dominated by a tool orientation change, i.e. especially relevant for zero or small tool position changes (lower than the blend radius), this issue would occur.

  • Fixed an issue where smooth transition results in violation if reduced mode plan is entered during accelleration phase of movement.

  • Fixed issue where torques computed with the script function enable_external_ft_sensor was with the wrong sign. This has been fixed by introducing the new script function: ft_rtde_input_enable, and deprecating the old. Please refer to the script manual for more details.

  • Fixed issue where the Payload and Payload COG was not incorporated in computing the the wrench from the RTDE input. To not break backwards compatibility this is only fixed when using the new ft_rtde_input_enable.

  • Fixed issue where implicit sync after move-until mode with blend radius on the final waypoint would cause unintended hard brake.

  • Fixed issue where blend path visualization (the green lines in PolyScope graphics) would be either missing or garbage.

  • Improved controller performance, reducing the risk of experiencing the “Runtime too much behind” protective stop.

DASHBOARD SERVER

  • Fixed issue where the program execution would get “stuck” on executing an Assignment Node after the ‘close popup’ Dashboard Server command had been sent. This would occur, if the Assignment Node was configured to request the operator to input a whole number, a decimal number or a text string. For these Assignment Node configurations, the behavior is now the same as when the Assignment Node is configured to request a “Yes or No” input from the operator.

URCAP SOFTWARE PLATFORM

  • Fixed issue where the unsaved changes indicator for the installation would be enabled when a configuration containing a TCP selection (with a real TCP) was applied to a Move Node
  • Fixed issue where features with an undefined pose where included in the list returned by the ‘getGeomFeatures(…)’ methods in the ‘FeatureModel’ interface
  • Fixed issue where it was not possible to create new installations after an unhandled exception had occurred when a URCap’s implementation of the ‘configureInstallation(…)’ method in the ‘GripperContribution’ interface was called while creating a new installation
  • Fixed issue where the “Unhandled exception in URCap” error dialog would display the string “polyscope-screwdriving-impl” instead of the name of the faulty URCap as well as showing an incorrect version. This issue would happen, if an unhandled Java exception occurred when a URCap’s implementation of the ‘generatePreambleScript(…)’ method in the ‘ScrewdriverContribution’ interface was called while preparing to execute a program.
  • Fixed issue where the “Unhandled exception in URCap” error dialog would not be shown, if an unhandled Java exception occurred when a URCap’s implementation of the ‘configureContribution(…)’ method in the ‘GripperContribution’ interface was called while loading an installation. Furthermore, if the gripper contribution did not define a custom installation UI, the “There is an error with the URCap that contributes this node” screen, which is displayed instead of the UI for an Installation node when an error occurs, would not appear in the installation.

SOFTWARE PLATFORM

  • Fixed issue where Robot Age is reset to 0 after a software update
  • Fixed issue where log_history.txt is not preserved over a software update
  • Fixed issue where a software update would occasionally (running the same update twice) result is a failure to startup Polyscope (a black screen after rebooting)

EMBEDDED

  • Fixed issue where the SCB would fault in case of loading a new installation while E-stop is asserted.

You can find the release notes for the CB3 here:
Release Notes 3.14

Happy development,
The Universal Robots+ Team