Release note Software version 5.8.x.x
For e-series only
Date Created: April 9th, 2020
RELEASE NOTES 5.8.2 - 04/06-2020
Released Versions:
- UR Software Update: 5.8.2
- URSim Linux: 5.8.2
- URSim Virtual Machine: 5.8.2
- Robot Image: 5.8.2
?
Bug Fixes
PolyScope GUI
Fixed issue where an unhandled 'ConcurrentModificationException' exception could a occur in a URCap if the URCap was accessing Features in the installation.
Fixed issue where?the first Point/Line Feature from the list in the Features installation screen was always used by Conveyor Tracking regardless of which Feature was original selected in the Installation.
Fixed issue where loading certain older installation files would fail if the installation contained installation variables that were used by the loaded program
Reduced distance for precise automatic move when using pose editor, and "move here" functionalities.
Fixed issue where robot would not stop movement after depressing "automove" button on the TP screen.
Support zip file can now be opened as compressed folder on Windows 10. Support files generated in older releases can still be opened with 3rd party applications (i.e. 7zip).
?
Controller
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.
?
URCap Software Platform
- URCap API:?
Fixed issue where a 'ConcurrentModificationException' exception could be thrown when features where retrieved by calling methods in the 'FeatureModel' interface.
Fixed issue where control of the Tool I/O Interface was not properly granted a URCap when loading an installation which had the control assigned to that URCap
Fixed issue where the active TCP offset (applied to the controller) was not changed after the offset of the Default TCP was updated. This would occur when the TCP selected as Default TCP was contributed by a URCap and that URCap updated the TCP's offset (using the 'updateTCP(String, Pose)' method in the 'TCPContributionModel' interface).
?
?
RELEASE NOTES 5.8.0 - 09/04-2020
Released Versions:
- UR Software: 5.8.0.10253
- URCap Software Platform:
- URCap API: 1.10.0
- URCap SDK: 1.10.0
- URSim: 5.8.0.10253
- URSim Virtual Machine: 5.8.0.10253
- Robot Image: 5.8.0.10253
- Manual: 5.8.0
- Support Log Reader:?3.8.65
KEY FEATURES
- Constrained Freedrive: Improved freedrive experience by allowing movement only in the selected axes.
- URCap API: Improved support for fixed position configuration of Waypoint program nodes
- URCap API: Added payload support for Gripper driver contributions
?
Software update
In this release we introduce an improved functionality for updating the robot software. The software update functionality in PolyScope has not changed from a user perspective. These are the key points to be aware of:
- 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.
?
PolyScope GUI
Export of robot configuration for Technical Support
Introduced functionality where user can easily export data necessary for diagnosing issues with robot application.
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.
File contains:
- 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
?
Program tree
All empty expression fields (which are part of the configuration of a program node) are now displayed with yellow background
The text field in the Popup program node is displayed with yellow background if it is empty
?
Optimized performance for programs and installations
- Shorter loading time for large programs
- Shorter loading time for installations
- Reduced time spent creating or loading an installation when a large program is loaded
- More responsive controls when navigating a program, scrolling and expanding/collapsing nodes in a program tree when a large program is loaded
- Inserting new nodes in the program tree is faster
- Making modifications to the program when a large program is loaded, such as undoing/redoing, copy-pasting, etc. is optimized
?
URCap Software Platform
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.
Changes:
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.).
?
URCap API:
- 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)
- Note:
- 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:
- TCPs
- Features
- Variables (installation variables)
- I/Os
- Devices (such as grippers)
- Performance optimizations:
- 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).
- Improved PolyScope startup time when a URCap with a daemon contribution is installed on the system:
- 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
?
URCap SDK:
- 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
?
Dashboard server
- Added command for triggering flight report
- Added command for generating Technical Support file
Manuals
- Secondary programs description added to URScript manual
- Calibration Manual is updated with a new procedure for resetting robot calibration.
Controller
Embedded
- Kinematic Calibration is saved in the robot arm
- The calibration of the robot parameters (DH parameters) from the dual-robot calibration is now stored in the robot arm.?
- Calibraton data is copied from the arm to the calibration.conf file at every boot, so it is still possible to manually inspect the values.
- Storing calibration data for the robot arm in the arm itself allows user to move the arm from one control box to another without performing re-calibration.
Note that only control boxes rated for the arm size could be used. Be aware that the serial number shown in the GUI will not change when changing the arm. - The PolyScope log should reflect when a calibration file in the control box is overwritten with calibration from arm and vice versa.
- Both new robots produced with SW 5.8 and robots upgraded to SW 5.8 will get the calibration stored in the robot arm.
?
BUG FIXES
PolyScope GUI
- 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
Polyscope Improvements for large programs
- Fixed long pause when selecting Set or Wait nodes on large programs.
- Fixed long pause after protective stop on some systems with large URCaps installed.
- Fixed long pause when accessing move node in programs with large number of waypoints defined.
Controller
- Improved behavior when resuming program. Controller will now evenly ramp up from zero velocity instead of always starting the resume process at maximum acceleration.
- Reduced stopping time and distance when an Emergency Stop interrupts the Protective Stop retraction.
- New and more informative error message when trying to enable IMMI without the required hardware.
- Fixed issue where the setpoint would drift during conveyor tracking/path offsetting if controller executed a blended waypoint without any subsequent movement.
- Fixed issue where stopl/stopj could cause errors during conveyor tracking/path offsetting.
- Reduced occurrence of "Runtime too much behind" Protective Stop which in special cases could occur during program execution, especially in large or complex programs.
URCap Software Platform
- Fixed issue where inserting Waypoint nodes with default names (e.g., "Waypoint_1", "Waypoint_2") resulted in undesired linking of the inserted Waypoints when the language in PolyScope was one of several non-English languages.
- Fixed issue where it was possible to install two versions of the same URCap (same symbolic name) which would be active at the same time in PolyScope:
- Only the URCap with the highest version will be activated
- A dialog is displayed informing the user that the URCap is already installed in a different version and that only the newest will be activated
- When installing a URCap with a different version in the URCaps Settings screen the following will now occur:
- The inactive URCap (with the lowest version) is displayed in the "Inactive URCaps" section and an explanation is shown in the right side of "URCap Information" section (in the bottom of the screen). The version of the URCap is displayed in parentheses next to the URCap name (for both URCap versions) .
- Fixed issue where inserting a configured Waypoint node into the program tree under a MoveL or a MoveP node configured with a feature different from the Base feature would result in an unexpected Waypoint position.
- Fixed issue where a 'ClassCastException' exception would be thrown, if the sub-tree of a URCap program node contained a child node contributed by another URCap not installed on the robot and any of the following interactions occurred with that child node:
- Calling the 'canGetAs(Class)' method on the child node from the missing URCap (as an instance of the 'URCapProgramNode' interface)
- Using the program node visitor (i.e. the 'ProgramNodeVisitor' or 'URCapProgramNodeInterfaceVisitor' abstract class) to traverse the sub-tree containing the child node from the missing URCap
?
Dashboard Server
- Fixed issue where the "No longer controlling the operational mode. Current operational mode: '<current mode>'" return value for the 'clear operational mode' command would report the wrong current operational mode.
?
URSim
- Fixed "ConcurrentModificationException" appearing on some Linux systems (i.e. Ubuntu 18.04) when starting up URSim.
?
Embedded
- More work on stabilizing the brakerelease procedure. Timeout errors should be less frequent.
?
Manuals
- Fixed issue where a wrong screenshot was shown in the "13.2.4: Joint Limits" section.
?