Release Notes 5.9

Release note Software version 5.9.x.x

For e-Series only

Date Created: January 30th, 2021.

SW 5.9.5 Release Notes

Release Versions:

UR Software Update: 5.9.5

Bug Fixes

PolyScope GUI

3PE Teach Pendant: Fixes an issue when an external mode selection switch is used with 3PE Teach Pendant on SW 5.9.3 and 5.9.4. Customers with 3PE Teach Pendant should update to 5.10 or higher.

Date Created: November 2nd, 2020.

SW 5.9.4 Release Notes

Release Versions:

UR Software Update: 5.9.4
URCap Software Platform: (no change)
URSim Linux: 5.9.4
URSim Virtual Machine: 5.9.4
User Manuals: (no change)
Support Log Reader: (no change)

Key Features

New builtin script function get_inverse_kin_has_solution()
The new function can be used to check if get_inverse_kin can compute a valid solution and thereby avoid runtime exceptions if no solution is found.
The new function should be used instead of is_within_safety_limits, which is now deprecated.

Bug Fixes

Controller:

Fixed an issue where multiple calls to get_inverse_kin() with the same pose but varying the q_near parameter would always return the same first solution. The solution will now reflect the q_near reference joint positions at each function call.
Improved smooth transition when safeguard stopping for linear motions.

Date Created: October 5th, 2020.

SW 5.9.3 Release Notes

Release Versions:

UR Software Update: 5.9.3
URCap Software Platform: (no change)
URSim Linux: 5.9.3
URSim Virtual Machine: 5.9.3
User Manuals: (no change)
Support Log Reader: (no change)

Key Features

Support for 3PE Teach Pendant:
- Universal Robots Teach Pendant with built-in 3-Position Enabling Device is sold separately
Motor control optimizations at low speeds:
- For increased stability in path tracking at low speed movements. To understand more about the Motor Control Optimizations at low speeds, check the service note regarding this HERE.

PolyScope GUI

Motor Control Optimization at Low Speeds:
- This improvement applies to robots built with PolyScope version 5.4.0 and higher.
- The "Calibration revision" of each joint must be higher than v12.0. Users can check this in the file robot_calibration_summary.txt. To check the robot joint's "calibration revision" please follow the guideline HERE

Support for Universal Robots 3PE Teach Pendant:
- Requires connection of the Universal Robots Teach Pendant with 3-Position Enabling Device (sold separately).

Bug Fixes

PolyScope GUI

Fixed an issue where Constrained Freedrive would follow wrong rotations of the selected feature.
Performance improvements on the Log screen.
Fixed issue where it was not possible to run a program, if two or more digital outputs were configured (in the "I/O Setup" installation screen) to generate a continuous pulse when a program is running. Attempting to start a program would result in a "Contextual error: The thread ContinuousPulseInstallationComponent is double defined" runtime exception.

Controller:

Fixed an issue where resuming a paused program could result in "No Controller".
Increased the workspace around the base in which the user can use Constrained Freedrive. Reduced the singularity zone by up to 30 %.
Improved responsiveness of constrained freedrive, when only moving in wrist 3.
When a cascade of faults or violations occur in the joints/embedded code, the initial fault (or if no fault, violation) will be shown in the Polyscope popup. The log still retain information on all faults and violations.

Software Platform

Improved robustness of the software update procedure; DNS and remote control settings now persist across updates

Date created: August 10th, 2020

RELEASE NOTES 5.9.1 - 08/2020

Released Versions:

UR Software Update: 5.9.1
URCap Software Platform:
- URCap API: 1.11.0
- URCap SDK: 1.11.0
URSim Linux: 5.9.1
URSim Virtual Machine: 5.9.1
User Manuals: 5.9.0
Support Log Reader: 3.9.44

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.
Payload notification
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<T>)' 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<SelectableGripper>)' 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.

NEWEst RELEASE NOTES:

Release Notes Software Version 5.10

previous RELEASE NOTES: