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.8.0 for e-Series
- PolyScope 3.13.0 for CB3
- URCap SDK 1.10.0 including URCap API 1.10.0 for both platforms
Please pay attention to the following notices
COMPATIBILITY NOTICE: DATA PERSISTENCY WHEN UPDATING ROBOT SOFTWARE
When updating robot software all data in the /root/GUI folder is reset. Please note that this involves any data URCaps might choose to persist in its own bundle folder. URCaps themselves are stored in /root/.urcaps and that this folder is not reset.
Few URCaps have been seen to change the system configuration in unsupported ways. Such changes will be reset and these URCaps will need to be re-installed to restore full functionality.
COMPATIBILITY NOTICE: BEHAVIOR CHANGE FOR VALID TCP NAMES IN SCREWDRIVER AND GRIPPER DRIVER CONTRIBUTIONS
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 Screwdriver and Gripper driver contributions.
When TCPs are added through a Screwdriver or Gripper driver contribution (using the ‘setTCP(String, Pose)’ in the ‘TCPConfiguration’ interface) certain names will no longer be accepted. The following will be disallowed when specifying the name for a TCP and will throw an ‘IllegalTCPNameException’ exception:
- Any occurrences of hyphens (-)
- A name starting with a number or an underscore (_)
- Any occurrence of special characters, such as #, [, (, etc.
Previously, these cases were accepted, and the specified name was automatically corrected. This change is implemented to align the behavior with all other API functionality that allows for adding/contributing named entities to PolyScope (such as variables, features, etc.).
The key features in this release is:
- URCap Gripper Drivers
- Added payload support for Gripper driver contributions.
- Improved support for fixed position configuration of Waypoint program nodes
Other relevant features
- Constrained Freedrive: Improved freedrive experience by allowing movement only in the selected axes.
- Export of robot configuration for technical support
- Export button is available on the log tab and is enabled in manual mode only.
Single zip-compressed file will be created. File can be saved directly to USB flash drive. Containing:
- all previous flight reports
- all programs, scripts, and installations
- entire robot log
- individual log files for all software components
- operating system log files, memory consumption, and available disk space
- configuration files
- calibration file
- robot arm statistics
- software metrics
- Updating to this release and future releases can now be done in one step rather than the current practice of updating incrementally. There are some restrictions to this, so please consult the Service Manual for further instructions.
- After this update we do not recommend reverting to previous versions of robot software using older update packages. If you need to downgrade below PolyScope 5.8, you can do so by restoring your old system backups.
- We strongly recommend performing a backup before this update.
- The size of the update files has increased. Expect a file size of around 1Gb.
- Further instructions on correct usage of the software update feature is included in the Service Manual. Please read these instructions carefully.
Get started with the new API
URCap SDK and API release notes
Please find the release notes related to the URCap API and SDK 1.10.0 below:
- Improved support for gripper driver contributions:
Added integrated payload support:
- Gripper program node and toolbar:
- The user can specify what the total payload should be set to after the execution of a grip or release action
- For a gripper supporting the Grip Detected or Release Detected feedback capability, the payload will be applied after successful grip/release detection in the Gripper program node
- The user-defined total payload value will be applied by PolyScope immediately after the script code for the gripper action has finished executing (or successful grip/release detection)
- Gripper program node and toolbar:
- Applying the new payload is not the responsibility of the gripper driver, since this is automatically handled by PolyScope
- To ensure that the new payload is properly applied by PolyScope, the generated script code for the gripper action must not finish earlier than when it is appropriate to apply the new payload value (i.e. when the object has been gripped or released). For more details, see the new section “3.2: Integrated Payload Support” and the updated section “3.3: Script Code Generation” in the “URCap Gripper Driver” SDK document.
- Added API support for querying the enablement state of the grip/release detection option in the Gripper program node when generating script code for grip and release actions (in calls to the ‘generateGripActionScript(ScriptWriter, GripActionParameters)’ and ‘generateReleaseActionScript(ScriptWriter, ReleaseActionParameters)’ methods in the ‘GripperContribution’ interface):
- If the grip detected feedback capability has been registered, URCaps can determine if the end user has enabled or disabled this functionality
- This functionality enables URCaps to generate different script code for grip/release actions depending on the enablement state of grip/release detection. For more details, see the u pdated section “3.3: Script Code Generation” in the “URCap Gripper Driver” SDK document.
- See new method ‘isGripDetectionEnabled()’ in the ‘GripActionParameters’ interface
- See new method ‘isReleaseDetectionEnabled()’ in the ‘ReleaseActionParameters’ interface
- Improved Gripper node UI:
- Allowed the user to define two independent values for the parameter for each registered capability (e.g. width capability), one value used for the grip action and one value used for the release action
- Removed the “Grip Now” and “Release Now” buttons
- For gripper contributions supporting the Grip Detected and/or Release Detected feedback capability, the Grip Detection (or Release Detection) option is now enabled by default when the user selects the Action in a new Gripper program node
- Increased the length of the sliders for adjusting capability parameters (e.g. width capability) in the Gripper program node
- If a gripper contribution does not define a custom installation screen UI (for setting up the gripper), the installation node for the gripper will not be shown in the Installation
- Added access to the TCP contributed by Screwdriver and Gripper driver contributions:
- A Gripper or Screwdriver contribution can access the actual TCP it has contributed to PolyScope
- See new ‘getTCP()’ method in the existing ‘TCPConfiguration’ interface (in the ‘contribution.driver.general.tcp’ Java package).
- Improved support for requesting the end user to define a position of the robot (using the Move tab):
- Introduced a new robot position callback which returns the TCP offset used when the user defined the robot position (together with the resulting pose and corresponding joint positions)
- See the new ‘RobotPositionCallback2’ interface and the new ‘getUserDefinedRobotPosition(RobotPositionCallback2)’ method in the existing ‘UserInteraction’ interface (in the ‘domain.userinteraction’ Java package).
- Deprecated the ‘RobotPositionCallback’ interface and the ‘getUserDefinedRobotPosition(RobotPositionCallback)’ method in the ‘UserInteraction’ interface.
- See the new ‘PositionParameters’ interface (in the new ‘domain.value.robotposition’ Java package)
- Improved support for configuration of waypoints:
- Added support for creating a fully defined fixed position configuration for a Waypoint Node by specifying a pose and corresponding joint positions and TCP offset (obtained using the new robot position callback)
- See the new ‘createFixedPositionConfig(PositionParameters, …)’ method in the existing ‘WaypointNodeConfigFactory’ interface (in the ‘domain.program.nodes.builtin.configurations.waypointnode’ Java package).
- Added default rendering support for unresolved PolyScope entities in Swing combo box widgets:
- A Swing combo box (‘JComboBox’ class) where the selected PolyScope entity is unresolved (e.g. because it was deleted/not present in the Installation) is automatically displayed as in built-in PolyScope program nodes (i.e. the entity name is italicized and the combo box is displayed with yellow background and border).
- Supported PolyScope entity types:
- Variables (installation variables)
- Devices (such as grippers)
- Performance optimizations:
- Improved PolyScope startup time when a URCap with a daemon contribution is installed on the system:
- The unpacking of resources when the ‘installResource(URL)’ method is called on the implementation of the ‘DaemonContribution’ interface during startup will only occur the very first time (after the URCap has been installed or updated)
- In previous versions, the daemon resources would be unpacked every time PolyScope started (which could be time consuming with large resources).
- Reduced the number of calls to the ‘isDefined()’ method in implementations of the ‘ProgramContribution’ interface during rendering of the program tree and when the data model is updated.
- Reduced the time it takes to insert child nodes in sub-tree of a parent node, especially for Waypoints nodes
- When a Java exception has occurred- in the code of a URCap , a detailed explanation including URCap information and stack trace is now provided in the Log tab
- Improved PolyScope startup time when a URCap with a daemon contribution is installed on the system:
- Updated the following Swing-based samples to use the new default rendering support for unresolved PolyScope entities in Swing combo boxes:
- Cycle Counter Swing
- Idle Time Swing
- Tool Changer Swing
- Updated the ‘install.sh’ script so that when executed, it will ask the user if the ‘ant’ Linux package should be installed, if that package is not installed on the system. The ‘ant’ tool is a prerequisite for the optional UR C/C++ cross-compiler toolchain.
- Updated the “URCap Gripper Driver” document (gripper_driver.pdf file) with description of the new integrated payload support:
- Added new section “3.2: Integrated Payload Support”
- Updated section “3.3: Script Code Generation” with information about how the generated script code for gripper actions should behave after the introduction of integrated payload support to ensure an optimal user experience
- Added command for triggering flight report
- Added command for generating Technical Support file
Fixed memory and resource leak that caused “out of memory” errors or slow GUI when a program was started and stopped few thousand times with short intervals.
Fixed issue on Move Tab where no arrows were displayed when feature selection was changed from View to anything else.
Fixed an issue where opening a program copied to a USB displayed “Installation file not found” error.
Fixed an issue where adding a second Seek-template in the Program Tree resulted in linking of waypoints for Start and End Direction to the waypoints of the first template.
- Fixed an issue where IMMI signal for mold closed and mold open was not translated correct.
- Improved readability on I/O screen for IMMI signals with very long names.
- IMMI added to filter on I/O screen for better filtering of signals.
- Fixed issue where no help was available for Three Position Enabling.
- Fixed issue in the “I/O Setup” installation screen where a value smaller than 0.1 (and larger than 0.02) could not be specified in the “High” and “Low” number fields when configuring a digital output to generate a continuous pulse.
- Fixed issue where undoing (or manually reverting) a change from a fixed Waypoint to a variable Waypoint would restore the original default name (assigned when the Waypoint node was inserted) instead of its user-defined name.
- Fixed issue where loading an installation in some situations could change the name of fixed Waypoints in a loaded program containing variable Waypoints, if the Waypoint name was a default name (e.g., “Waypoint_1”, “Waypoint_2”).
- Fixed issue where the program play controls (the Play/Pause button in the PolyScope footer) would falsely indicate the (user’s) program was running while the “Move Robot into Position” screen was visible or when the robot was moved using the Move tab.
- Fixed issue in the Features installation screen where the onscreen keyboard would not invalidate the entered input if the name of an existing Point feature was specified when renaming a Line or Plane feature.
- Fixed issue where loading a large program could take very long time if that program was already loaded
- Fixed issue where all dialogs would stop working, if the Operational Mode was changed to Automatic (using a hardware switch or the Dashboard Server) while the “Apply and Restart” / “Revert Changes” Safety Configuration dialog (appearing after the “Apply” button is pressed in the Safety installation screen) was showing.
- Fixed issue with unresponsive screen when program is loaded and started over 10000 times using dashboard server
- Fixed unexpected exception when pressing Move Here button in programs with large number of waypoints defined.
- Fixed “OutOfMemoryError” exception when running program with over 33 threads with long names.
- Fixed issue where line numbers are not shown on last program tree branch of first program loaded after robot restart.
- Fixed the following issues with loading and saving programs in the Sub Program node:
- After the sub program was saved, it was not listed in the file chooser dialog (unless the “All Files” filter was selected) because the sub program was not saved as a .urp file
- The previous name of the Sub Program node was not “released” after loading a sub program (i.e. it was not possible to assign other PolyScope entities or programs nodes that name)
- It was possible to save the sub program under a name already assigned to another PolyScope entity or program node
The Universal Robots+ Team