Release Notes 5.14.X

Release note Software version 5.14.x.x

UR20/e-Series

Date Created: 12th October 2023.

Download HERE

SW 5.14.X RELEASE NOTES - UR20/e-series

Note: On UR20, when installing new joints as replacement parts, an upgrade to SW 5.14.4 or later is mandatory.

SW 5.14.5

Improved handling of low-speed motions for UR20. The robot is now able to move at joint speeds below 0.01 rad/sec.

SW 5.14.3

Fixed issue where operational modes would change on reboot, if no operational mode password was defined

SW 5.14.2

Internal fixes

SW 5.14.1

Internal fixes

SW 5.14.0

key features

Struct datatype in URScript - Engineering Preview
Set of variables can be aggregated into structs, and thus transferred and stored as a single variable
Disable/enable high holding torque
Prevent false positive protective stop when the robot is standing still but the end-effector is doing some work such as screwing. However, if there is an external axis, this prevents collision detection if only the external axis is moving but the robot is in collision.
Set base acceleration
To prevent protective stop when a UR robot is mounted on a moving base and experiences high acceleration, an URScript added to set the base acceleration to the controller.
Payload Transition Time (URScript)
Define a duration for a payload change in URScript.
Improved Modbus Client script functions
Added support for more Function Codes allowing for broader device support and increased communication efficiency. Added error handling script functions - now user can detect, and react to communication errors without stopping the program.
Improved Modbus Server
General Purpose Coils added (bit registers)
Do not restrict tool flange against safety planes
Allow for the tool flange sphere to be ignored when safety planes are used, the same way as the elbow sphere. Works for all the different plane restrictions i.e. Normal, Reduced, Trigger.
Freedrive input added to the safety system
This input will activate freedrive in manual mode. It will activate freedrive even if the robot is equipped with a "3 positional enabling button"-"teach pendant", or an external "3 positional enabling button"
Improved Freedrive
Robots are easier to move in freedrive.
Fixed bugs related to MoveC command

Polyscope GUI

Freedrive input added to the safety system

You can configure the Freedrive input to enable and use Freedrive without pressing the Freedrive button on a standard TP, or without having to press-and-hold any of the buttons on the 3PE TP in the lightpress position.

Do not restrict tool flange against safety planes

Restricting the tool flange prevents the tool flange from crossing a safety plane. When you restrict the tool flange, the unrestricted area is the area inside of the safety plane, where the tool flange can operate normally. The tool flange cannot cross the restricted area, outside of the safety plane. Removing the restriction allows the tool flange to go beyond the safety plane, to the restricted area, while the attached tool remains inside of the safety plane. You can remove the tool flange restriction when working with a large tool off-set. This will allow extra distance for the tool to move. Restricting the tool flange requires the creation of a plane feature.

SAFETY

Comply with EN 61784-3:2021

CONTROLLER

Complex data types (Structs) in URScript

NOTE: This feature is not currently recommended for production use. It will be matured, and fully documented in script manual for release 5.15.0. Robot programmers are encouraged to use complex data types to experiment and iterate during the projects prototyping phase.

Set of variables can be aggregated into structs, and thus transferred and stored as a single variable. This reflects the capability in other languages, but comes with a few restrictions that should be taken into account.

Structs can be obtained through multiple means:

Using the struct() function
RPC call that returns a struct

The struct function takes one or more named arguments, and each argument name becomes a member in the struct. All values must be initialized by value, and the type of the value cannot be changed subsequently.

Example of struct defined in URScript language:

# Create a struct
myStruct = struct(identifier1 = 1, identifier2 = 2, myMember = "Hello structs")
  
# Reassign a member
myStruct.myMember = "Goodbye structs"
  
# use a member
myVar = myStruct.myMember
  
# Use the second member by index (identifier2)
myVar = myStruct[1]
  
# A nested struct, stored by value
myStruct = struct(myStructMember = struct(myMember = "Hi nested struct") )

Complex data types through XML-RPC

Added support for transferring structured data types.
For backwards compatibility 6 element numeric array returned from XMLRPC server is always interpreted as a pose.

Complex data types - URScript reference

struct(...)

Create a struct

A nonempty set of named parameters are tied together in a struct with the name of the arguments being used to name the members of the struct, and the values defining the types and values of those members.

Parameters:

The struct function is unique in that it takes a variable number of named arguments. It is subject to the following constraints:

Each name can only occur once in each struct.
The value assigned to each member determines the type of the member, and that type cannot be change subsequently.
If a members value is assigned to a struct, that struct is copied into the new struct. You cannot create pointers to other structs.

Example command: myVar = struct( member1 = "Hi structs", anotherMember = 1, member2 = anotherVariable)

make_list(n, number)

make a new list of length n with the initial value of each element given by "number"

Parameters:

n: The length of the list

number: The initial value of each of the members of the list

Example command: make_list(10, 5.5)

UR20 baselight

The UR20 robots will have a light ring on the base. By default, the colors on the baselight will depend on the safety and operational modes and comply to the IEC 60204-1 standard.

The following script commands can be used to change the behavior of the baselight:

set_baselight_off() - Turns off the baselight completely
set_baselight_iec() - Make the baselight comply to the IEC 60204-1 standard and indicate whether the robot is in a safety stop, in freedrive as well as the operational mode. Further details of the colors can be seen in the UR20 manual. This is the default behavior.
set_baselight_solid(r, g, b) - Set a color on the entire baselight ring as specified by the given RGB values in the range 0-255.

Disable/enable High Holding Torque

Currently the UR controller automatically enables unlimited torque window (high holding torque) when

the program state is PROGRAM_STATE_RUNNING
actual joint movement <= 0.01 rad/s
target joint velocity == 0

It is useful to prevent a false positive protective stop when the robot is standing still while the end-effector is doing some work such as screw driving. However, if the robot is being transported on an external axis, then high torque hold should be disabled. This will allow collision detection of the stationary robot while being transported.

New URScript functions:

high_holding_torque_disable()
high_holding_torque_enable()

can be called to manually disable/enable high holding torque. When disabled, the robot should report protective stop if it collides with an obstacle when standing still. Note that the setting is reset to enabled after restarting the controller.

Set Base Acceleration

To prevent protected stop when a UR robot is mounted on a moving base and experiences high acceleration, an URScript set_base_acceleration is added to set the base acceleration to the controller. Users can call the function every timestep to report the acceleration of the robot base to the controller.

Payload Transition Time

Added an extra optional argument to the set_target_payload script function, that allows users to define a duration for a payload change. Setting a transition time larger than zero prevents the robot from doing a small "jump" when the payload changes and is easier on the joints. This is useful when picking up or releasing heavy objects or using a vacuum gripper.

Modbus client improvements

Improvements are focused on accessing multiple coils or registers within single modbus transaction. This allows increasing overall communication efficiency when accessing devices like I/O expanders, and enables complex devices like servo drives. Up to 123 coils or registers can be read or written in single modbus transaction.

In addition new Modbus Function Codes are supported enabling broader range of devices compatible with UR robots.

New error handling functions added for more flexible, and error tolerant programs.

NOTE: Current release introduces new features in URScript only. Modbus signals added in Polyscope GUI are still limited to 1 coil/register. Same limitation applies to signal value preview in I/O tab. Error handling/watchdog functions can be applied to signals both added in Polyscope GUI, and URScript.

New function codes support

Previous implementation of Modbus Client was limited to 1 coil, and 1 register per signal in the installation. Moreover only Function Codes (FC) 1-6 were available.

This release adds support for Function Codes 15, 16, and 23

Matrix of Function Codes used for accessing coils or discrete inputs:

Read	Write
Signal type	Single Coil	Multiple Coils	Single Coil	Multiple Coils
0 = "Digital Input"	2	2	-	-
1 = "Digital Output"	1	1	5	15
15	1	1	15	15

Matrix of Function Codes used for accessing Input Registers, or Holding Registers:

Read	Write
Signal type	Single Register	Multiple Registers	Single Register	Multiple Registers
2 = "Register Input"	4	4	-	-
3 = "Register Output"	3	3	6	16
16	3	3	16	16
23	23	23	23	23

Example: signal added with modbus_add_signal("192.168.0.1", 255, 0, 3, "R1", True, 4) will initially read 4 registers starting at address 0 using FC3, but after first write modbus_set_output_register("R1", [101, 102, 103, 104]) it will start writing 4 values with FC16.

Signal types 1 and 3 for backwards compatibility use different function codes depending on number of registers or coils written. Additional types 15, and 16 are provided if that mode is not supported by Modbus slave device.

Types 15 and 16 use the same signal type regardless of number of registers supplied.

Type 23 uses modbus_add_rw_signal(...) function and allows to read and write multiple registers in single Modbus transaction.

Improved error handling

In previous software versions accessing signal that either can't reach remote device, or device is reachable but reports Modbus exception would pause the program with "Protective Stop".

There are introduced few script functions for reading current error, and configuring watchdog time.

Added parameter value range checking to all modbus functions. This change may result in Runtime Exceptions for programs migrated from previous versions.

Script functions reference

Short description of each added, or modified script functions:

- modbus_add_signal(IP, slave_number, signal_address,signal_type, signal_name, sequential_mode=False, register_count=1) - introduced register count. For backwards compatibility, default value is 1.
- modbus_add_rw_signal(IP, slave_number, read_address, read_register_count, write_address, write_register_count, signal_name, sequential_mode=False) - new script function for adding signals for FC23. Read and write address spaces can be in different locations, and have different register count.
- modbus_get_signal_status(signal_name, is_secondary_program=False) - returns array of values when used on signal with multiple registers
- modbus_set_output_register(signal_name, register_value_array, is_secondary_program=False) - accepts array of values when used on signal with multiple registers
- modbus_set_output_signal(signal_name, register_value_array, is_secondary_program=False) - accepts array of values when used on signal with multiple coils
- modbus_get_error(signal_name, error_source=0) - returns error status of signal.
- modbus_set_signal_watchdog(signal_name, timeout_sec) - set tolerance for errors (both communication, and device exceptions) as minimum time between valid device responses.
- modbus_get_time_since_signal_invalid(signal_name) - returns time elapsed since signal entered error state.
- modbus_reset_connection(connection_id, is_blocking=True)- tear down, and reconnect all signals to remote device. Useful in error recovery routines.

Examples

Example programs and script code for efficient data exchange, and diagnostics are available in GitHub repository: https://github.com/UniversalRobots/ModbusExamples.

Modbus server improvements

Added General Purpose bit registers to coils map. Registers are shared with RTDE boolean registers.

From robot program side registers can be accessed with program nodes in Polyscope GUI or URScript functions:

- read_input_boolean_register(address)
- read_output_boolean_register(address)
- write_output_boolean_register(address, value)

COIL ADDRESS
Address	Read	Write	Description
300-428			128 General Purpose Input boolean registers (shared with RTDE boolean registers)
500-628			128 General Purpose Output boolean registers (shared with RTDE boolean registers)

Raw encoder count

There have been a request to also get the raw encoder count for using the high speed input capabilities in the controller to count pulses and get them without extrapolation. This could be used for e.g. counting fast and short pulses from a camera.

The raw integer count is now accessible through both the RTDE protocol with two additional channels: "encoder0_raw" and "encoder1_raw". Both of type INT32. And the URScript by a new "opt" argument to the already existing encoder_get_tick_count(encoder_index, opt="raw").

Embedded

Improved detection of missing of failing devices in the arm, reducing instances of robot getting stuck in booting after arm being turned on.
Control box fan speed will now be increased when the energy eater is under high load. This may result in the control box running louder when executing programs with high decelerations.
SCB 24V outputs will be low (Active) during boot-up

Bug Fixes

PolyScope GUI

Fixed minor issues in the support for the Teach Pendant with 3-Position Enabling Device
Fixed minor issue when switching Operational Mode
Fixed issue where the Play/Resume footer button would become disabled (greyed out) in some situations

Controller

Fixed ending FreeDrive mode when robot was pausing.
Fixed the speedl() builtin function to control the speed in the Cartesian domain. Before it was using one time step too much, which result in poor performance as well as an annoying sound.
Fixed issue where different order of named arguments can cause "ValueStack is Full" error
Fixed issue where race condition occurs while multiple threads are used in XMLRPC client
Fixed "Missing sanity check for set_gravity()" the input for the function shall be within +/- 20 m/s^2 otherwise argumentOutOfRangeException will happen, if NaN or Infinity is passed as an input the invalidArgumentValueException will be activated.
Fixed the modulo operation on integer types in URScript. The modulo operation will have the same behavior as the division. Division/modulo operation with a bool_val will throw an exception.
get_inverse_kin() now returns the numerical IK solution or q_near (whichever achieves the lowest position and orientation error) if the numerical IK solution is not within the specified tolerances but the position error is below 0.002m and the orientation error is below 0.02rad. The previous behavior was that q_near would always be returned if the numerical IK solution was not within the specified tolerances even if the numerical IK solution was more accurate than q_near.
Fix the 24V IOs current is not sent from SCB to the controller and not properly propagated further in the system (Polyscope (Primary interface), RTDE and Modbus)
Fixed the issue where forcemode_set_damping changes the behavior of Lock Axes Freedrive.
Fixed the issue where the "path_offset" builtin functions would incorrectly throw overload exception when run in simulated mode
Fixed Global variables getting blocked after sending a variable that exceeds the maximum allowed size. Long lists are now skipped without disrupting global messages and warnings are logged during these occurrences. While these lists remain hidden and unsavable as installation variables, they are functional in all other contexts.
Fixed a bug that could cause an unexpectedly fast (and presumably dangerous) robot motion when applying a path offset to an underlying trajectory where the underlying trajectory produces a singularity exception
Unified compare operations between boolean and numeric types. This change may result in different behavior for programs migrated from previous versions.
Fix allows the robot to go into backdrive when in automatic mode
Fixed a "Runtime too much behind" error that was particularly sensitive to changing the robot's clock while moving the arm.
Some ProfiNet device module configurations that did not work ("Error in lower level component" shown on PLC when IO, Joints, and TCP modules are not inserted) are working. Confirmed in software 5.12.5 and later.

MoveC bug fixes

Avoided Runtime Exceptions in MoveC
- Fixed cases where MoveC would incorrectly report a RuntimeException "Circular arc path has zero radius".
- Fixed cases where MoveC would incorrectly report a RuntimeException "Circular arc path has infinite radius".
- These changes also improve robustness of movements generated from the Remote TCP and Toolpath URCap, as it would in rare causes throw the mentioned Runtime Exceptions
Corrected orientation motion for MoveC
Fixed bug where when two MoveC commands in ''fixed' mode were used after each other, e.g. in order to move in a complete circle, the second move would not choose the correct orientation path.
- It is unlikely that applications would be reliant on this behavior as a "feature", but it's worth noting that the resulting motion will now differ in this scenario.
- If you use MoveC in fixed mode, it is recommended to check the motions of existing applications after installing this upgrade
Fixed problem where the robot would not do the same orientation every cycle of a MoveC command
Fixed bug where certain MoveC commands using fixed mode (typically 180 degree orientations) would rotate in the opposite direction of the intended motion.
Validates the provided rotation mode, and throws a runtime error when an invalid mode is provided. Valid modes are 0 (Unconstrained) and 1 (Fixed)

URSim

External accelerometer readings can be feed through RTDE interface using the key "external_tool_accel" if it is enabled using the URScript function accel_rtde_input_enable.
Once the external accelerometer RTDE input is enable, move_until can be used to detect the tool contact in URSim.

User Manual

Hardware part of the User Manual is re-organized in to separate sections for robot arm and control box. This is better matching separate packaging of the arm and control box.

Known issues:

DNS name resolution fails in URScript functions (all functions accepting network address are affected: rpc_factory(), modbus_..., socket_...). Workaround: Use numeric IP address in URScript functions or add the IP and hostname to the /etc/hosts file.
Issue affects 5.14.0, and will also be present in future minor revisions.

Release Versions:

UR Software Update: 5.14.0
URCap Software Platform:
- URCap API: 1.13.0 (no change)
- URCap SDK: 1.13.0 (no change)
URSim Linux: 5.14.0
URSim Virtual Machine: 5.14.0
User Manuals: 5.14.0
Support Log Reader: 3.16.57