Release note Software version 3.11.x.x
The latest software version is at the top of this article.
RELEASE NOTES 3.11.0 - 17/09-2019
- UR Software: 188.8.131.52155
- URCap Software Platform:
- URCap API: 1.8.0
- URCap SDK: 1.8.0
- URSim: 184.108.40.206155
- Robot Image: 220.127.116.11155
- Manual: 3.11.0
- Support Log Reader: 3.6.228
- URCap API: Added support for Gripper contributions.
- Program tracking during program execution
- What thread to track is no longer persisted with the program
- What thread to track can be changed during program execution
- The user can no longer choose whether to track or not in to subprogram
- The tracking will go into the subprogram if it is called from the thread that is being tracked
- The Flightreport section 'Latest Program Indicator' now contains information of currently executed node from all threads. Including thread and node name.
- The paper clip icon (used for highlighting log entries with an error report) is now visually separated from the 3 message type filter icons (for info, warning and error messages).
- Content of the Popup message is now included in the Popup node description in the Program Tree.
URCap Software Platform
With this release and going forward, when a URCap needs to depend on the version of the URCap API included in this release (i.e.version 1.8.0) or newer, the approach previously described in the URCap tutorial should not be fully followed:
- It is no longer required to update the version range under the "<Import-Package>" section in the 'pom.xml' for the URCap project
- It is still necessary to update to the desired version in the URCap API dependency under the "<dependencies>" section in the 'pom.xml' file
Note that If the versions range under the "<Import-Package>" section is updated, the result could be that the URCap will fail to start when PolyScope starts up.
- URCaps can implement Gripper driver contributions to add functionality for gripping devices to PolyScope
- Makes it extremely easy and fast to create URCaps supporting grippers in PolyScope by reducing development complexity and time significantly
- Allows URCap developers to focus on implementing the specific functionality related to how their product works instead 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 grippers in PolyScope.
- Benefits of support for Gripper driver contributions:
- A Gripper driver contribution will automatically add the following to PolyScope:
- A program node for the gripper with a corresponding standard screen which allows the user to program grip and release actions. The configuration options available to the user are based on what functionality the gripper supports.
- A toolbar for the gripper providing the user quick access to perform grip and release actions using "default" gripper action parameters.
- Note: The toolbar is not available on CB3 robots.
- An optional installation node for the gripper which allows the user to setup the gripper using a custom UI (only if the URCap chooses to define one)
- A Gripper driver contribution enables the URCap to:
- Supported types of capabilities:
- Width: The gripper can move to a user configurable position, i.e open/close (grip/release) to a specified width
- Supported types of capabilities:
- Specify a name for the Gripper driver contribution. The name is used as title in the program node, installation node and the toolbar.
- Optionally provide a custom logo. The logo is displayed in the program node, installation node and the toolbar.
- Optionally contribute a TCP for the gripper 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.
- Optionally support one or more gripper capabilities:
- Supported types of capabilities:
- Speed: The gripper can perform grip and release actions using a user configurable speed
- Force: The gripper can grip using a user configurable force
- Vacuum/Pressure: The Gripper can grip using a user configurable vacuum/pressure level (by suction cups or pneumatically operated fingers)
- The parameter range supported by the gripper as well as a default value for a grip and/or release operation are specified when a capability is registered.
- Parameter ranges and default values can be updated after registration, if these need to change based on a different setting, e.g. depending on the fingertips mounted on the gripper. If the current configuration of a gripper program node in the program becomes invalid after the parameter range has been updated, the program node is automatically marked as undefined.
- The parameters are displayed in the program node to allow the user to configure the registered capabilities
- See the new 'contribution.driver.gripper.capability' Java package
- Optionally generate script code necessary for initializing the gripper. The script code is added to the preamble section of a robot program.
- Generate script code for performing grip and release actions when:
- A program (with a gripper program node) is executed
- The user tests a configuration of a gripper program node
- The user operates the gripper using the toolbar
- Optionally define a custom UI in the installation node using a general framework for building UIs to allow the user to setup the gripper:
- Supported user input types:
- There are two options for the initial selection in the combo box:
- One of the elements is pre-selected
- The initial selection is a specified string. The string should inform the user what is to be selected or describe what action to do, e.g. "<Mounting>" or "<Select Mounting>".
- Note: Only static content in the combo box is supported, i.e. it is not possible to update/change the content after the user input has been registered.
- Integer, double and IP address user inputs have default error input validators pre-defined
- For integer, double, IP address string user inputs, it is possible to optionally add a custom error input validator
- Description text: A single description text for the installation screen
- Text element: A text with an optional icon, e.g. for displaying status information to the user.
- Filler element: An element not visible on the screen, that can used to control/group the layout.
- Enables the URCap to migrate/adapt an existing value of a user input saved with an older version of the URCap to a new user input definition/format defined in a newer URCap version, so the user's previously stored configuration is not lost.
- This is achieved by marking an old user input as deprecated, converting the old user input value and using the converted value to register a new user input.
- Deprecating user inputs is useful when a previous version of the URCap had a need for the given user input, but the current version no longer needs it. This can for instance be relevant when the "format" of the user input needs to be changed in a new URCap version, e.g. a previously defined checkbox user input needs to be changed to a combo box user input.
- Integer input: Allows the user to enter an integer in a specified range through a number text field (with a specified initial value)
- Double (decimal number) input: Allows the user to enter an integer in a specified range through a number text field (with a specified initial value)
- String input: Allows the user to enter a string through a text field (with a specified initial text)
- IP address input: Allows the user to enter an IP address through a text field (with a specified initial IP address string)
- Boolean input: Allows the user to make a selection using a checkbox (with a specified initial selection)
- Selection input: Allows the user to make a selection using a combo box:
- Validation of user inputs:
- Supported non-user input UI element types:
- Support for handling backwards capability between versions of the URCap:
- See the 'deprecateUserInput(UserInput)' method in the 'CustomUserInputConfiguration' interface in the new 'contribution.driver.general.userinput' Java package.
- General functionality:
- A maximum of 10 user input and non-user input UI elements can be added (not including the description text).
- User input and non-user input UI elements are added in a two-column layout grid (except for the description text)
- When all user inputs and non-user input UI elements have been added, the custom UI is automatically generated and made available in the installation node.
- Any gripper program node in the program is marked as undefined, if the custom setup in the gripper installation node is incomplete, e.g. if the user has not yet made an selection in a combo box input or a user input contains an error.
- See the content in the new 'contribution.driver.general.userinput' Java package.
- See the all content including the 'GripperContribution' main interface in the new 'contribution.driver.gripper' Java package.
- The following functionality is automatically handled for the URCap:
- Retrieving and storing of data
- The defined/undefined state of the gripper program node
- Extended the 'RobotType' enum in the existing 'RobotModel' interface (in the 'domain.robot' Java package) with the new UR16 robot type.
- URCaps can create and insert Screwdriving Nodes into the Program Tree:
- See the new 'ScrewdrivingNode' interface in the 'domain.program.nodes.builtin' Java package
- See the new 'createScrewdrivingNode()' method in the existing 'ProgramNodeFactory' interface (in the 'domain.program.nodes' Java package).
- Note: The Screwdriving Node is only available on e-Series robots. Before attempting to insert a Screwdriving node, remember to check if the node type is available on the system using the ' SCREWDRIVING' value in the new 'ProgramNodeCapability' capability enum (in the 'domain.system.capability.programnodefactory' Java package) with the 'hasCapability(Capability)' method of the 'CapabilityManager' interface.
- URCap SDK:
- 'Simple Gripper': Demonstrates how to create a gripper driver contribution for a basic gripper that only supports the mandatory "default" grip and release actions. The URCap uses I/Os in the script code generation to trigger grip/release actions.
- 'Advanced Gripper': Demonstrates how to create a gripper driver contribution for a more advanced gripper that supports several optional gripper capabilities and configures the output voltage setting of the Tool I/O Interface.
- 'Custom Setup': Demonstrates how to define a custom UI for setting up the gripper in the installation node as well as how to add a TCP for the gripper to PolyScope.
- 'Custom User Inputs': Demonstrates most of the options available when defining a custom UI. This includes how to:
- Use different types of user inputs and non-user input UI elements
- Use the filler UI element for controlling/grouping the layout of the custom UI
- Add a custom input validator for detecting errors for enterable user inputs (in this case an IP address user input)
- The new samples are located under the new 'samples/driver/gripper' and 'samples/driver/general' folders.
- Updated the "11: Creating new thin Projects using a Maven Archetype" and "12: Compatibility" sections in the URCap tutorial to reflect that it is no longer required to update the version range in the "<Import - Package>" section of the 'pom.xml' file for a URCap project.
- Adapted the 'newURCap.sh' script (for creating new empty URCap projects) and all samples in the URCap SDK to this change
- Added new URCap samples:
- Added document "URCap Gripper Driver" which describes the properties of Gripper driver contributions and how they work inside of PolyScope (gripper_driver.pdf file).
- Changes to the 'pom.xml' file for URCap projects:
- It is now possible to subscribe to all RTDE output variables from single client using one recipe.
- Number of allowed RTDE clients increased by three. Up to 6 external clients can connect simultaneously
- Introduced support for aborting an ongoing brake release if a tool induces excessive vibrations to the robot arm during brake release
- Fixed issue where False value was assingle to RTDE input_bit_register_95 to input_bit_register_127
- Fixed issue where killed XML-RPC calls with arguments in thread caused wrong arguments
- Fixed issue with high payloads in combination with low force limit safety settings that could cause position deviation protective stops
- Added a border in the numeric keyboard on position editor to have the same design with numeric keyboard on other tabs.
- Fixed issue where "<no name>" was shown in the save dialog for Russian and Spanish languages.
- Fixed issue where top header was malformed when changes were made to a program with a long name.
- Fixed issue where config_in could not be used in expressions when defined as Safeguard Reset
- Fixed issue where switching between real/simulated mode would mark installation as modified.
- ProgramNodes become defined, while a program is running, even though they are not
- Move tab temporarily changes active TCP when non-default TCP was selected for a move node. TCP is reset after leaving move tab.
- Fixed issue where moving the robot with slow speed using Auto Move could cause the robot to not move to the requested position.
- Fixed issue where a Fixed waypoint would keep changing its position when using Move Here.
- Fixed error when using palletizing template inside multiple subprograms.
- Robot now moves to correct position when move node feature is switched to Base.
- Fixed issue where renaming of a program with a screwdriving node could damaged the program.
- Fixed issue where a tooltip error message was displayed in a Set node configured to "Set Single Pulse" when the pulse time number field was cleared on the keypad
- Corrected the tooltip error message displayed when an invalid value was entered in the pulse time number field for a Set node configured to "Set Single Pulse". The error message text has been changed from "Pulse time must be greater than 0.002s" to "Pulse time must be greater than or equal to 0.002s
- Fixed issue where changing the position of a Point feature would not enable the unsaved changes indicator for the installation.
- Fixed issue where the "There is an error with the URCap that contributes this node" screen displayed instead of a URCap installation screen (when an error occurs while entering that screen) would only be displayed properly the first time.
- Fixed issue where the "Unhandled exception in URCap" dialog could be displayed twice in some situations.
URCap Software Platform
- Fixed issue where calling any of the getter methods in the 'IOModel' interface in the constructor of an Installation node contribution would result in a null pointer Java exception when loading an installation for the first time, or return a list containing the I/Os defined in the old installation when loading a new installation.
- Fixed issue where the "Unhandled exception in URCap" dialog could be displayed twice, if a Java exception occurred in the code of a URCap while it was generating script code.
- Fixed issue where the "There is an error with the URCap that contributes this node" screen displayed instead of the UI for an Installation node contribution (when an error occurs while entering the URCap installation screen) would only be displayed properly the first time.
- Fixed issue where undoing a user action, which added a value (only applied to some object types) to the data model of a program node contribution, would put a 'null' value into the data model instead of completely removing the value.
- The command 'safetystatus' has been added to the Dashboard Server Remote Control Interface. The intention is to have the new command replace the existing command 'safetymode' by allowing a more detailed view of the safety mode without breaking backward compatibility