Universal Robots release URCaps API 1.5.0, PolyScope 5.2 and PolyScope 3.8
Universal Robots are pleased to announce the release of a new URCaps API.
The new 1.5.0 API will be supported by two new PolyScope versions 5.2 (e-Series) and 3.8 (CB3).
This is a minor release, which include a number of new features, both to the API, the robot, and generally in PolyScope.
- Ability to contribute TCP’s to the Installation
URCaps can now contribute their own TCP’s to the TCP Configuration installation node.
Other URCaps can list all available TCP’s, including reading their offsets.
- Support for “auto move”
URCaps can now request a user to move the robot arm, using the “auto move” screen (known from “Move here” on Waypoint).
- Increased tool current output on e-Series.
In normal (one pin) mode, the e-Series is able to supply respectively 600 (UR3e) and 1000 (UR5e, UR10e) mA continously.
In dual-pin powered mode (using the 2 outputs for additional sink/source), the e-Series tool is capable of supplying 600 (UR3e), 1500 (UR5e) and 2000 (UR10e) mA continously.
- Tool Output pins can be toggled NPN (default), PNP or push-pull.
- URScript support for string manipulation.
Extending URScript to support string manipulation including concatenation, indexation, split, string to/from numeric conversion, and more.
After upgrading an e-Series robot to 5.2+, it will not be possible to downgrade below 5.2.0.
Get started with the new API
URCap API and SDK release notes
Please find the release notes related to the URCaps API and SDK 1.5.0 below:
- Improved support for TCPs:
All functionality is in the new ‘domain.tcp’ Java package
Support for contribution of TCPs to PolyScope: (See new API interface ‘TCPContributionModel’):
Enabled URCaps to add their own TCPs with a suggested name to the installation in PolyScope
Enabled URCaps to remove their own TCPs from the installation in PolyScope
Enabled URCaps to update the Tool Output Flange offset of their own TCPs
See new API interface ‘TCPContributionModel’
- A TCP added by a URCap cannot be modified in any way by the user or other URCaps (i.e., it cannot be removed, renamed, or have its Tool Output Flange offset changed).
- TCPs 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 PolyScope screens where a TCP can be selected (i.e. in the 'TCP Configuration) on the installation screen, using ‘Set’ and ‘Move’ program nodes. User-defined TCPs are listed in the top of the TCP drop-down menu followed by TCPs added by URCaps.
- Note: Removing a TCP or updating the Tool Output Flange offset of a TCP while loading an installation is not allowed. Such attempts are ignored. This is to ensure the original TCP configuration in the installation is always properly loaded.
- Enabled possibility of TCPs added by a URCap to be removed from an installation when the loaded installation depends on a URCap which is not installed. This occurs when a user taps the ‘Remove from Installation’ button in the “Missing URCap” installation screen (that replaced the UI provided by the URCap installation contribution).
- Access to the list of TCPs:
URCaps can access the list of all TCPs in PolyScope including all user-defined TCPs and all TCPs added by URCaps
See new API interface ‘TCPModel’
- Added support for storing TCPs in the data model.
A URCap program node holding a reference to an unresolved TCP in its data model automatically becomes undefined. A TCP can be unresolved if a different installation (that does not contain the TCP) is loaded or if the TCP is removed.
- Added a new method ‘set_tcp(TCP)’ in the ‘ScriptWriter’ API interface (in the ‘domain.script’ Java package)
- Made support for requesting the user to move the robot to a desired target position through the ‘Automove’ screen
- Added option to specify the target robot position as a pose.
The Automove function moves the robot TCP to the target position linearly in Cartesian space. If this is impossible, the robot moves to the target linearly in joint space.
The current joint positions of the robot are used as a starting point for inverse kinematics to calculate a target joint vector corresponding to a desired pose, which takes the currently active TCP offset into account.
- Added option to specify the target robot position as a joint position vector.
In this case, the Automove function moves to the specified joint position vector linearly in joint space without taking the currently active TCP offset into account.
- Added option to specify the target robot position as a pose.
- See the new API interface ‘RobotMovement’ in the new ‘userinteraction.robot.movement’ Java package. This interface is accessible through the new ‘getRobotMovement()’ method in the ‘UserInteraction’ API interface (in the ‘userinteraction’ Java package).
Ordering of Program Nodes
- Listing of URCap program node types in the ‘Structure’ view in the Program Tab:
Improved the standard built-in sorting of URCap program node types in PolyScope, so all node types contributed by a URCap are grouped together and sorted/ordered.
A URCap can now explicitly specify a custom ordering of its program node contributions:
- This new API feature is supported for program node contributions with Swing- as well as HTML-based user interfaces.
- Using this new feature is optional.
- For Swing-based URCaps, see the new method ‘setDisplayOrderId(double)’ in the ‘ContributionConfiguration’ API interface in the ‘contribution.program’ Java package.
- For HTML-based URCaps, the program node service also implements the new ‘ProgramNodeServiceConfigurable’ API interface in the ‘contribution’ Java package. This interface provides access to the ‘ProgramNodeConfiguration’ API interface (also in the ‘contribution’ Java package), which allows for specifying a custom node ordering.
- Deprecated the method ‘set_payload(double)’ in the ‘ScriptWriter’ API interface due to side effects caused by the script code generated by this method
- Provided access to API providers in the ‘URCapAPI’ API interface for contributions with HTML-based user interfaces:
- Added getters for the context-specific API providers offering access to API functionality relevant to installation and program node contributions. These are the same API providers used by contributions with Swing-based user interfaces.
- See new methods ‘getInstallationAPIProvider()’ and ‘getProgramAPIProvider()’ in the ‘URCapAPI’ API interface (in the ‘domain’ Java package)
- All existing methods in the ‘URCapAPI’ interface are deprecated • Note: In future API versions, no new API functionality will be added and directly accessible in the ‘URCapAPI’ interface. The new providers accessible in this interface must be used instead.
- Made various improvements to Javadoc
- Changed the behavior after a request has been made to start or stop a daemon. Now, when the request execution finishes, it automatically triggers an update (re-rendering and invocation of ‘isDefined()’ methods) of the Program Tree. This ensures the correct “defined/undefined” state is reflected for any program node contribution with an implementation of the ‘isDefined()’ method that depends on the run state of the daemon.
- Created new and updated URCap samples:
New and updated samples are available on Github
- Added new ‘Tool Changer’ URCap sample demonstrating the new API features contributing TCPs to PolyScope and accessing the list of available TCPs
- Added new “Node Ordering” URCap sample demonstrating the new API features regarding program node sorting in the Structure view.
- Updated the ‘Ellipse’ and ‘Ellipse Swing’ URCap samples to demonstrate how to request the user to move the robot to a specified target position through the ‘Automove’ screen.
- See section “10: URCap examples overview” in the URCap tutorial for more details about the samples
- Changed the “default” value for the IP address text field when the data model does not contain a user-defined IP address from an empty string to “0.0.0.0” in the ‘User Input’ URCap SDK sample.
- Added the “12.1: Advanced Compatibility” section to the URCap tutorial for Swing-based URCaps. The content corresponds to the existing section with the same title in the HTML-based tutorial.
- Fixed the issue where an input validation error message in a URCap toolbar contribution would appear behind the toolbar.
- Fixed the issue with Swing combo boxes in URCap toolbar contributions where the item list would not be visible in some situations if the list was short.
- URCap SDK samples:
- Fixed the issue where the text in IP address text fields and number fields was incorrectly left-aligned instead of right-aligned in the ‘Localization Swing’ and ‘User Input’ samples. This was fixed for the “IP Address” and “Positive number” fields in ‘User Input’ sample and the “Enter your height” field in ‘Localization Swing’ sample. The sample User Input are now aligned with the PolyScope User Inputs.
- Fixed the issue in the ‘Localization’ and ‘Localization Swing’ samples where the text in the ‘Units’ drop-down menu was truncated in Japanese
- Fixed the issue in the ‘My Daemon’ (HTML-based) sample, where tapping the ‘Start Daemon’ and ‘Stop Daemon’ buttons froze PolyScope because it blocked the call to start/stop the daemon.
- Aligned the behavior of user input validators created by URCaps using the ‘InputValidationFactory’ API interface as well as custom validators implemented by a URCap with PolyScope. When a text field has a validation error, the text field will still be red, but now no validation error message will be displayed in the following situations:
- The text field is empty (e.g., because the text field was cleared by the user)
- A virtual keyboard accepting IP addresses will not display any error message
- Fixed the issue where calling the ‘get()’ method on a contribution provider (‘ContributionProvider’ API interface) in the constructor for a program node contribution, in rare situations, could return another existing contribution instance. A “This method should not be called directly from ProgramNodeContribution constructor” IllegalStateException exception will now be thrown instead.
- Fixed the issue where the name of a variable would not be “released” in some situations when the variable was stored in the data model and used to configure a program node that failed to be inserted in the Program Tree.
- Fixed the issue where it could take long time to load a program containing program nodes from certain URCaps in some situations.
The Universal Robots+ Team