Release note Software version 5.6.x.x

For e-series only

The latest software version is at the top of this article.

RELEASE NOTES 5.6.0 - 05/12-2019

Released Versions:

UR Software: 5.6.0.90886
URCap Software Platform:

URCap API: 1.9.0
URCap SDK: 1.9.0

URSim: 5.6.0.90886
URSim Virtual Machine: 5.6.0.90886 (internal version: 2.0.41)
Robot Image: 5.6.0.90869 (internal version: 5.1.33)
UR Firmware

Joint selftest firmware: 5.1.28
Joint selftest application: 17.3.4

Manual: 5.6.0 (internal version: 3.7.27)
Support Log Reader: 3.7.36
RTDE: 2.3.6 (no change)
F/T Software: 8.8.20

Key Features

Align to feature: Ability to align the Z-Axes of the TCP to selected feature.
Breakpoints: It is possible to set breakpoints on program nodes by tapping the line number. Program execution will pause when it reaches a breakpoint.
Single step: behavior of the single step button changed to be more aligned with customer expectations.
Remote TCP & Toolpath URCap: G-code toolpaths could be imported into PolyScope through Remote TCP/Toolpath URcap.
Online Path Offset: Ability to dynamically offset motions in URScript.
OSSD outputs: Configurable Outputs now support output signal switching devices.
URCap API: Added support for Screwdriver driver contributions
URCap API: Added support for Grip Detected and Release Detected feedback capabilities for Gripper driver contributions
URCap API: Added support for using gripper devices in template program Nodes
URCap API: Added support for registering a "regular" URCap as a conformant PolyScope gripper device
URCap API: Improved support for Features
New dashboard server commands
New URScript utility functions

PolyScope GUI

Align to feature

User can automatically align robot's TCP to selected feature, for example, align screwdriver perpendicular to desk surface.

In the Move screen, pressing the Align button will take you to an Automove screen where you can move the active TCP to be aligned with the feature selected on the Move Tab.
The TCP will be moved so that the Z-Axes of the TCP and the feature are parallel, either pointing in the same direction or opposite directions.
The direction of the alignment is determined by the current orientation of the TCP (the closest direction will be chosen).
To make room for the Align button, the Zero position button has been moved to Installation→General→Home. The Home position now defaults to the Zero position.

Breakpoints

Single tap on the line number in the Program Tab will set or clear a breakpoint.

This Feature is available only in Manual local control mode.
Breakpoints can be set and cleared both when program is running and when it's stopped.
When a breakpoint is set, a red line above or below node text shows if program will pause before executing node (most nodes), or if it will pause after node is executed (i.e. waypoint nodes).
A blend on a waypoint is ignored if a breakpoint is set on that waypoint.
Breakpoints can be set on any program thread, and it will pause all threads when hit. However, user must select which thread execution is followed by execution indicator (blue arrow in program tree)

Single step

Single step button behavior has changed

In previous software versions single step button was only active when program was stopped. Pressing a button was executing just one selected node.

Starting from this version, single step button is active when program is paused and in Manual local mode only. When button is pressed, then controller will execute single node, and pause again.

Single step button is enabled only when program execution is paused, and robot is in Manual local control mode.

It is possible to use single step after pausing a program, or when program is paused after hitting a breakpoint.
Pressing the button will execute program until next node is reached.
If next node is a waypoint, then move will be executed (ignoring blend), and program will pause again, otherwise program will pause before executing next node.
Program is stepping to the next node on active thread. Active thread is a thread that was last executed when program was paused (either manually or hitting a breakpoint)

Remote TCP and Toolpath

Remote TCP & Toolpath URCap enables the robot to follow a complex toolpath either with a part or with a tool at a constant speed.

Generate G-code toolpath files using standard CAD/CAM packages
Easily load G-code toolpath files onto UR teach pendant
Optimize robot motion with free-spin-in-Z
This URCap automatically generates robot motions based on the imported toolpath files, eliminating the need for the user to program a long list of waypoints to trace complex trajectories.
Multiple toolpath files could be loaded in to robot and used with Toolpath Move and Remote TCP Move - Toolpath.

This URCap is compatible with the following G-codes:

G00-03: All the rapid, linear, circular and helical moves
G90-91: Absolute vs incremental programming
G20-21: G-code for units (mm/inch)
G17-19: Plane of motion
G54-59: defining multiple coordinate systems and allowing multiple programs at different locations

This URCap was specifically developed for process applications, such as dispensing, gluing, deburring, and sewing. Other applications, such as polishing, welding, painting, and even machining and 3D printing may also benefit from this URCap.

Currently the RTCP & Toolpath feature is only available on UR3e, UR5e, and UR10e models.

New dashboard server commands

get operational mode - allows to determine if robot is in automatic or manual mode
is in remote control - allows to determine if robot can be controlled remotely
get serial number - reads robot serial number
get robot model - reads robot model

Changed dashboard server commands

unlock protective stop - unlocking a protective stop is not possible until 5 seconds after occurrence.

Other improvements

It is now possible to specify a custom name for an I/O that has an action assigned.
Magic scripts are executed only from USB root folder.
Reduced the amount of disk space taken up by an installed URCap

URCap Software Platform

URCap API:

URCaps can implement Screwdriver driver contributions to add functionality for screwdriver devices to PolyScope:

Support for Screwdriver driver contributions provides the following benefits:
- It makes extremely easy and fast to create URCaps supporting screwdrivers in PolyScope by reducing development complexity and time significantly
- Allows URCap developers to focus on the specific functionality related to their product, instead of spending time on implementing, e.g. UIs, handling of defined/undefined program node state and handling storing/retrieving data.
- Provides users a simplified and uniform user experience when working with screwdrivers in PolyScope
A Screwdriver driver contribution will integrate into the following parts of PolyScope:
- The built-in Screwdriving installation screen, where the screwdriver driver will be selectable together with the built-in user-defined screwdriver. When the screwdriver driver is selected, the screwdriver will be used by the built-in Screwdriving program node and an optional custom UI (only if the URCap chooses to define one) will be displayed which allows the user to setup the screwdrive

The built-in Screwdriving program node can use the screwdriver driver for programming screwing operations (when the screwdriver driver is selected in the installation). The configuration options available to the user are based on what functionality the screwdriver driver supports.

A Screwdriver driver contribution enables the URCap to:

Specify a name for the Screwdriver driver contribution. The name is displayed in the Screwdriving program node and Screwdriving installation screen (when the screwdriver driver is selected)
Optionally provide a custom logo. The logo is displayed in the Screwdriving program node and Screwdriving installation screen (when the screwdriver driver is selected)
Optionally contribute a TCP for the screwdriver to PolyScope
Optionally read the settings of the Tool I/O Interface as well as request exclusive control of the configuration of the Tool I/O Interface resource and exclusively configure the settings of this interface if the control request is granted to the URCap.
Support "default" start and stop screwdriver operations. This is mandatory for all Screwdriver driver contributions.
Optionally support one or more screwdriver capabilities:
- Supported types of regular capabilities:
  - Program selection: The screwdriver supports selecting between a set of screwdriver programs (typically defined on an external control box for the screwdriver)
  - Prepare To Drive Screw: The screwdriver needs to generate script code for preparing the screwdriver for a screwdriving operation
  - Feed Screw: The screwdriver supports automatic screw feeding
  - Operation Type: The screwdriver supports the two types of screwdriving operations, i.e. tighten and loosen
- Supported types of feedback capabilities:
  - Drive Screw OK: The screwdriver can inform whether an ongoing screwdriving operation ended successfully, i.e. ended in OK-state
  - Drive Screw Not OK: The screwdriver can inform whether an ongoing screwdriving operation failed, i.e. ended in Not OK (NOK) state
  - Screwdriver Ready: The screwdriver can inform whether the screwdriver device is ready to operate
- All capabilities are based on execution of script code (generated by the URCap)
- See the new 'contribution.driver.screwdriver.capability' Java package
Optionally generate script code necessary for initializing the screwdriver. The script code is added to the preamble section of a robot program.
Generate script code for the registered screwdriver capabilities and for performing the mandatory start and stop screwdriver operations executed when a program (with a Screwdriving program node) is run
Optionally define a custom UI in the Screwdriving installation screen using a general framework for building UIs to allow the user to setup the screwdriver (identical to the UI framework for Gripper driver contributions):
- See the content in the existing 'contribution.driver.general.userinput' Java package

See all the content including the 'ScrewdriverContribution' main interface in the new 'contribution.driver.screwdriver' Java package

The following functionality is automatically handled for the URCap:
- Retrieving and storing of data
- The defined/undefined state of the Screwdriving program node

Improved support for grippers:
- Added support for the Grip Detected and Release Detected feedback capabilities for Gripper driver contributions:
  - These two capabilities can optionally be registered, if the gripper can inform whether it has detected that an object has been gripped/released after a grip/release action has been triggered
  - See new the 'GripperFeedbackCapabilities' interface in the 'contribution.driver.gripper.capability' Java package
  - When one or both of these capabilities are registered, the user will be able to enable handling of grip/release detection in the Gripper program node. This provides the possibility of:
    - Specifying a timeout value for the grip/release action (in the Grip/Release Timeout Node)
    - Defining the processing steps to perform when the grip/release action timed out (under the Grip/Release Timeout Node)
    - Defining the processing steps to perform when the a grip/release was detected (under the Grip/Release Detected Node)

Introduced the concept of PolyScope devices:

The new 'Device' base interface represents a physical device supported by PolyScope
Currently, gripper devices are the only supported type of device
See new 'domain.device' Java package

Added support for getting the list of installed gripper devices available in PolyScope:

See the 'getGrippers()' method in the new 'GripperManager' interface in the 'domain.device.gripper' Java package

Added support for Gripper Nodes:

URCaps can create and insert a Gripper Node for a selected gripper device into the Program Tree
URCaps can read and configure the gripper action selection (i.e. grip or release) of the configuration for a Gripper Node
See the 'getGripperProgramNodeFactory()' method in the new 'GripperManager' interface in the 'domain.device.gripper' Java package
See the new 'domain.program.nodes.contributable.device.gripper' Java package

Added support for storing gripper devices in the data model:

URCaps can store and retrieve 'GripperDevice' objects and other device types ('Device' objects) in the data model
A URCap program node holding a reference to an unresolved gripper device in its data model automatically becomes undefined. A gripper device can be unresolved if the URCap that added the device is not installed.
See new methods 'set(String, Device)' and 'get(String, T, Class<T>)' in the 'DataModel' interface in the 'domain.data' Java package

Added support for registering a "regular" URCap as conformant with a PolyScope gripper device:

A URCap can register its program node contribution/service as conformant with a PolyScope gripper device
This allows the URCap to act as well as be treated and seen the same way as a URCap implementing the 'GripperContribution' interface
Registering as a PolyScope gripper device will enable other program node contributions (could be contributed by a different 3rd party URCap) to use the conformant program node contribution for e.g. creating a template node
The registered conformant program node contribution will get the following abilities:
- It will be included as a device in the list of installed PolyScope grippers
- It can be inserted as a Gripper Node into the Program Tree by another program node contribution
- It can have the gripper action configured by another program node contribution
See new 'contribution.gripper.conformant' Java package
For URCaps with a Swing-based UI, see the new 'getDeviceRegistrationManager(Class<T>)' method in the 'ContributionConfiguration' interface in the 'contribution.program' Java package
For URCaps with a HTML-based UI, see the new 'getDeviceRegistrationManager(Class<T>)' method in the 'ProgramNodeConfiguration' interface in the 'contribution' Java package. Note that the program node service must additionally implement the 'ProgramNodeServiceConfigurable' interface.

Improved user feedback for Gripper driver contributions:
- Introduced new dialog displayed when loading an old installation on a robot with a newer version of a Gripper URCap where some of the registered custom user inputs are deprecated (using the 'deprecateUserInput(UserInput)' method in the 'CustomUserInputConfiguration' interface). The intention of the dialog is to inform the user that the configuration "format" for the setup of the gripper has changed and that the old setup potentially has been adapted.

- - Added warning message in the Gripper Node to inform the user when the custom setup of the gripper in the Installation is incomplete or contains error, e.g. because no selection has been made in a combo box input

The "Robot needs to be powered ON to Proceed" tooltip is now displayed (in the footer) if the robot is powered off when:

The Test, Grip Now or Release Now button is pressed in Gripper Node
The Grip or Release button is pressed when operating the gripper from the toolbar

Improved support for Features:
- Added support for contribution of Features to PolyScope:
  - URCaps can add their own Features with a suggested name to the installation in PolyScope
  - URCaps can remove their own Features from the installation in PolyScope
  - URCaps can update the pose for the position of their own Features
  - See new 'FeatureContributionModel' interface in the 'domain.feature' Java package
  - PolyScope integration:
    - Features added by URCaps are displayed in the new URCap section in the Features installation screen
    - A selected URCap Feature cannot be modified in any way by the user or other URCaps (i.e., it cannot be removed, renamed, or have its position changed)
    - Features contributed by URCaps are grouped by the URCap "owner" in terms of the name of the URCap and its developer in all drop-down lists in programs Nodes where a Feature can be selected, e.g. 'Move' Nodes. User-defined Features are listed in the top of the feature drop-down lists followed by features added by URCaps.
    - Note: Removing a Feature or updating the pose of a Feature while loading an installation is not allowed. Such attempts are ignored. This is to ensure the original Feature configuration in the installation is always properly loaded

Added support for storing Features in the data model:

A URCap program node holding a reference to an unresolved Feature in its data model automatically becomes undefined. A Feature can be unresolved if a different installation (that does not contain the feature) is loaded or if the Feature is removed.
See new methods 'set(String, Feature)' and 'get(String, Feature)' in the 'DataModel' interface in the 'domain.data' Java package

Added support for getting a corresponding 'TreeNode' instance for child program node ('ProgramNode' instance) in the sub-tree under a 'TreeNode' instance:
- This can for instance be used to gain access to the sub-tree under a child program node encountered while traversing the sub-tree of the parent node using the program node visitor

See new method 'locateDescendantTreeNode(ProgramNode)' method in the 'TreeNode' interface in the 'domain.program.structure' Java package

Added support for configuring a program node contribution's ability to be used in the built-in PolyScope program debugging/execution control functionality:
- URCaps can configure whether or not the user is allowed to single step or set a breakpoint (pause) on its own URCap program node as well as any of the child nodes in the sub-tree under it
- URCaps can configure whether or not the user is allowed to start the program directly from its own URCap program node as well as any selected child node in the sub-tree under it
- See the new 'ProgramDebuggingSupport' interface in the new 'contribution.program.configuration.debugging' Java package
- For URCaps with a Swing-based UI, see the new 'getProgramDebuggingSupport()' method in the 'ContributionConfiguration' interface in the 'contribution.program' Java package
- For URCaps with a HTML-based UI, see the new 'getProgramDebuggingSupport()' method in the 'ProgramNodeConfiguration' interface in the 'contribution' Java package. Note that the program node service must additionally implement the 'ProgramNodeServiceConfigurable' interface.
Extended the 'URCapInfo' interface with new methods for getting information about the name of the URCap and the name of the vendor of the URCap
Made various updates and improvements to Javadoc
Reduced the amount of disk space taken up by an installed URCap

URCap SDK:

URCap samples:

Added new URCap samples:
- 'Grip and Release Swing': Demonstrates how to use gripper devices in a template program node. The sample shows how to use the following new API features:
- 'Simple Screwdriver': Demonstrates how to create a screwdriver driver contribution for a basic screwdriver that only supports the mandatory start and stop screwdriver operations
- 'Advanced Screwdriver': Demonstrates how to create a screwdriver driver contribution for a more advanced screwdriver that supports several optional screwdriver capabilities
- 'Custom Screwdriver': Demonstrates how to define a custom UI for setting up the screwdriver in the Screwdriving installation screen as well as how to add a TCP for the screwdriver to PolyScope
- 'Create Feature Swing': Demonstrates how to contribute a Feature to PolyScope as well as how to store a Feature in the data model
Updated URCap sample:
- Updated the 'Advance Gripper' URCap sample:
- Updated the sample to demonstrate how to support the new Grip Detected and Release Detected feedback capabilities
- Changed the implementation of the methods that generates script code for performing grip and release actions to print out the gripper action parameters to the console instead of showing them in a popup (through script code)
- Updated the following URCap samples to demonstrate how to allow the user to use the built-in PolyScope program debugging/execution control support for starting from and pausing/breaking on a selected program node in the program tree:
- Extracted strings used as ids for registering custom user inputs into constant fields in the 'Custom Gripper Setup' sample
- Simplified the code for clearing the program sub-tree in the 'Ellipse', 'Ellipse Swing', 'Pick or Place' and 'Pick or Place Swing' samples
- Simplified the code that provides the node title for the Program Tree in the 'Tool Changer Swing' sample

Added document "URCap Screwdriver Driver" which describes the properties of Screwdriver driver contributions and how they work inside of PolyScope (screwdriver_driver.pdf file)
Added document "Registering a Regular Contribution as a Conformant Device" which describes how to register a regular URCap contribution as conformant with a PolyScope device (registering_conformant_device.pdf file)
Added document "Using a Device in a Template" which describes how to use a PolyScope device in a template program node (using_device_in_template.pdf file)

Controller

Online Path Offset

Using the URScript programming language user can superimpose a movement on top of a programmed motion as well as add and dynamically adjust a translational and rotational offset to a motion. The new family of functions for configuring the Online Path Offset share the prefix 'path_offset'.

There are four options for specifying the offset using the URScript function 'path_offset_set'

In relation to the robot base coordinate system
In relation to the TCP coordinate system
In relation to the direction of movement of the TCP (see URScript manual for details)
Relative to the movements of the robot base, compensating for external movement of the entire robot

Rough, jagged superimposed motions can be made smoother by applying an approximation filter using the function "path_offset_set_alpha_filter"

New URScript utility functions

In order to support usage of conveyor tracking and online path offset, two URScript functions have been added:

get_target_tcp_pose_along_path: Returns the TCP pose excluding the contribution from conveyor tracking and online path offset (similar to get_target_tcp_pose)
get_target_tcp_speed_along_path: Returns the TCP velocity excluding the contribution from conveyor tracking and online path offset (similar to get_target_tcp_speed)

The Remote TCP & Toolpath URCap enables a new URScript module for UR+ developers or advanced users. Examples include:

mc_load_path(nc_file, useFeedRate): Load a G-code .nc toolpath file.
mc_add_path(path_id, a, v, r): Add a motion to move according to the G-codes specified in the .nc file.
mc_set_pcs(pcs): Set part coordinate system (PCS).
mc_add_linear(pose, a, v, r): Add a motion to move to pose, linear in tool space.
mc_add_circular(pose_via, pose_to, a, v, r, mode=0): Add a motion to move to pose, circular in tool space.
mc_get_target_rtcp_speed(): Returns the target lineaer speed of a Remote TCP.
mc_set_speed_factor(s): Set speed factor in range [0, 1].

Please refer to the latest version of the URScript User Manual for the detailed explanations of these new URScript functions and example codes. Make sure you activate the Remote TCP & Toolpath URCap on your robot before using these URScript functions.

Embedded

OSSD support for safety outputs: It is now possible to configure a safety output to enable OSSD signals.

Bug Fixes

PolyScope GUI

Fixed issue where "Auto Initialize" function occasionally fails to release brakes.
Fixed an issue, where the input/output fields of a Modbus Register signal was wrongly showing a formatting error.
The blue program indication arrow is now showing when executing waypoints.
Fixed an issue where it was not possible to create two waypoints less than 0.05 mm apart
Fixed an issue with some USB drives causing "out of memory" exceptions when attached for extended period of time.
Fixed an issue where arrows in Move Tool did not get correct colors and labels when "Base" or "Tool" features are selected
Fixed inconsistency with program highlighting when tracking execution.
Fixed bug where rotating wrist 3 on UR3 with infinite rotation, did not correctly show Automove screen
Fixed misleading descriptions and illustrations for the Stacking and Destacking function in the Seek Node
Fix issue where the "<empty>" text in the program tree for an empty program could be truncated in some situation
Fixed an issue in the Initialize screen where the "Active Payload" number field would not maintain its warning state (yellow background) when the field was pressed
Fixed issue in the file manager where copying a program from a USB which did not contain the program's associated installation would result in a null pointer Java exception
Changed the name of "Tool IO" installation screen to "Tool I/O"
Fixed issue where it was possible to delete/cut the Pattern Node (as well as all nodes under it) and the Generated Movements Node under a copy/pasted Pallet (Palletizing) Node
Fixed an issue in the Program Tree where the subtree containing the last executed node could not be minimized.

Controller

Fixed an issue where first Modbus message on each signal was delayed by up to 1s.
Fixed "No Controller" issue when application is using a lot of secondary programs (either directly, or through one of URCaps)
Error with code C271A1 can be caused by missing sync() on a thread. Proper explanation, and suggestion added to protective stop popup.
UR3e: When encountering a fault, the last Wrist no longer appears to be rotated 20+ rotations.
Fixed an issue with Force Mode, which prevented robot from reaching target waypoint when the safety system is in Reduced mode.
Fixed an issue where XML-RPC call could result in controller crash
Fixed an issue where externally clearing a Protective Stop quickly after an impact could cause a wrong retraction motion
Fixed issue where breaking out of a "continuous if" and executing a subsequent "wait" would cause an instant stop and often a protective stop. Robot will now instead per default brake at a fixed rate. To override this behaviour and explicitly control braking, use stopj() or stopl() script commands
Fixed issue where requesting a higher acceleration from stopj() or stopl() than the robot can deliver would sometimes result in a protective stop. If such parameters are given, the stopj() and stopl() will at runtime be limited to decelerate at a rate within the limits of the robot.

URCap Software Platform

Fixed issue where a Gripper contribution could define a custom UI in the Installation that did not fit on the screen. This could occur, because any added non user input UI element, such as a text component or a filler, was not taken into account in the maximum limit of 10 UI elements allowed and hence the 'TooManyUserInputsRegistered' exception was not always thrown. Now, the 'TooManyUserInputsRegistered' exception will be thrown when appropriate.
Fixed issue where the "Unhandled exception in URCap" dialog was not displayed, when a Java exception occurred within the scope of a call to the implementation of the overridden 'configureContribution(ProgramNodeConfiguration)' method in a HTML-based URCap with a program node service, that implemented the 'ProgramNodeServiceConfigurable' interface.
Fixed issue where pressing the Test or Grip Now/Release Now buttons in the Gripper program node, or the Grip or Release buttons in the toolbar could result in a runtime exception. This would occur, if the corresponding script code for the preamble, grip or release actions (the result of calls to the 'generatePreambleScript(ScriptWriter)', generateGripActionScript(ScriptWriter)'' and 'generateReleaseActionScript(ScriptWriter)' methods) generated by a gripper contribution made use of conditional statements, such if- and while-statements.
Fixed issue where the URCap title displayed in the left-hand side of the Installation and Program tab was truncated in PolyScope for the some of URCap SDK samples with Swing-based UIs. Now, the word "Swing" is not included in the URCap titles.
Fixed issue where the "There is an error with the URCap that contributes this node" screen, which is displayed instead of the UI for an Installation node contribution when an error occurs while entering the URCap installation screen, would incorrectly be shown, if a Java exception had occurred while the Installation contribution generated script code for the program preamble. Now, the URCap UI will be shown instead.
Fixed issue where the "Unhandled exception in URCap" dialog displayed during startup of PolyScope, if the code of an Installation contribution or Gripper contribution generated an unhandled Java exception, would not remain on the screen (because it was quickly closed).

URSim

Generation ID in serial number updated to match generation 5

Embedded

Fix safety state disagreements when input signals are bouncing.

Improved brake release stability.

Manuals

Corrected get_flag, and set_flag parameter descriptions.