Pally Compatibility Notes

Owned by Csaba Mucsi
Last updated: Apr 22, 2024
7 min read

Please read the following compatibility notes carefully before upgrading an existing Pally installation in production. Some changes in the recent versions may require new customer acceptance tests and/or modifications in the main robot program. Always make a full backup before upgrading.

Compatibility notes for version 2.6 and above

Path planning

The path planning algorithm has significantly changed in version 2.6. It is recommended to test existing projects with full pallets of all products after upgrading to version 2.6.

ProductCount

Since version 2.6 the "ProductCount" variable is now properly initialized to 0. In earlier versions it was initialized to -1 incorrectly. It is necessary to update custom code in callbacks that rely on the ProductCount variable.

Compatibility notes for version 2.7.1 and above

Pallet confirmation variables

From version 2.7.1 the pallet confirmation variables "rf_PS1_ok" and "rf_PS2_ok" should be updated with the following script command:

palletmanager_daemon.write_key_value_static(name, value)

The old method palletmanager_daemon.write_key_value(0, name, value) has no longer effect on the pallet confirmation state.

Programs that directly update the pallet confirmation variables should be verified.

Compatibility notes for version 2.8 and above

Execution of beforeZone and afterZone callbacks

From version 2.8.0 the beforeZone callback will be invoked when the lifting column has already reached the specified position but palletizing has not yet started. Similarly, the afterZone callback will be invoked after palletizing the last box has finished but the lifting column is still in the position as specified by the current zone. Programs that use a lifting column and have user code in beforeZone and afterZone callbacks should be verified.

Execution of beforeGrab callback

From version 2.8.0 the pipeline architecture for all path planning calculations has been redesigned such that all calculations are already done when the program enters the beforeGrab callback. Changing some path-planning related internal rf_-variables in beforeGrab for smart exit or collision radius calculations will no longer have any effect on the next movement. Programs that modify internal (rf_) path planning variables directly in beforeGrab should be verified.

Waiting time at pickup and release positions

From version 2.8.0 the waiting time at pickup and release positions has been optimized, in order to minimize the occurrence of protective stops caused by too early or too late change in the payload and center of gravity. The waiting time may become shorter or longer than in previous versions. Projects that are sensitive to the waiting times at pickup and release positions should be verified. For further information, see the new variables rf_joint_deviation_max and rf_joint_deviation_err.

Compatibility notes for version 2.9 and above

URCap API 1.12

From version 2.9.0 the minimum required URCap API version is 1.12. which may require the robot to be upgraded to a significantly newer version of Polyscope. Always make a full backup before upgrading.

Definition of multi-zone grippers (gripper.json)

From version 2.9.0 the structure of gripper.json has been changed. The zone positions are now defined in accordance with the tool coordinate system, which means the X and Y directions are inverted. This applies to all new gripper.json files that have the new format with the "properties" structure included, otherwise the old behavior is kept for compatibility reasons.

Automatic multi-pick

From version 2.9.0 the palletizer program evaluates the maxGripAuto field in the pattern JSON file prior to maxGrip. When maxGripAuto is set to true, the program will ignore the maxGrip value and use the product and gripper dimensions and the number of installed product sensors to determine the maximum number of products to be picked in one turn. Existing projects with multi-pick should take this into account when creating new patterns.

Multi-pick fewer boxes

From version 2.9.0 the optimizer will try to pick fewer boxes when the specified (maximum) amount of boxes cannot be palletized for some reasons, including out of reach issues and too small gripper size. In contrast to older versions that failed immediately with "This position cannot be palletized" the program will now retry with fewer boxes. This may introduce unpredictable behavior when the calibration of an existing system is modified.

Optional posData in zones.json

From version 2.9.0 the "posData" values in zones.json are made optional. This makes it possible to use zones in combination with lifting column dynamic positioning.

New callback onNextTask

From version 2.9.0 a new callback "onNextTask" will be automatically generated into the existing program tree when the Pally program node is opened in the Program Robot menu for the first time. The program has to be saved in order to keep the new structure. 

 

Compatibility notes for version 2.10 and above

Pally Operator Panel (POP)

Functions of the Pally Operator Panel, also known as the Runtime GUI URCap, have been integrated into the Pally URCap. Installing two separate URCaps is no longer required.

Compatibility with the older versions of POP are not maintained. Users are advised to uninstall all older versions of POP as they may not function properly any more.

Maximum allowed payload with multi-pick

From version 2.10.0 the program will check the maximum allowed payload for the specific robot model when selecting more than one box for multi-pick. As a result, the program may reject picking multiple packages, or reduce the number of boxes being picked, in projects where the maximum payload could be previously exceeded.

Maximum allowed payload is derived from the serial number format.

Compatibility notes for version 2.12.0 and above

Ewellix LIFTKIT URCap compatibility

Some compatibility issues with Ewellix LIFTKIT URCap version 1.2.0 have been resolved. Users having Ewellix LIFTKIT URCap version 1.1.0 may receive the following false alarm "Pillar not in position - press Continue to retry" after pausing and resuming the robot while operating the lifting column. Users are advised to upgrade LIFTKIT to 1.2.0 or newer - provided by Ewellix.

Lifting column Dynamic Positioning

The lifting column optimizer behavior has been significantly changed in version 2.12.0. Calculated lifting column positions may be different from in previous versions. Existing projects that use Dynamic Positioning should be verified. Projects that directly modify the rf_lift_alt_boost and rf_lift_safe_down parameters are advised to set rf_lift_alt_boost_auto=False and verify the program.

 

Compatibility notes for version 3.0 and above

Offline waypoint storage

Waypoints for all box positions are stored in a database, and the robot will repeat the same waypoints for each pallet as long as the calibration parameters remain unchanged. Changing path planning parameters will have no effect on the waypoints until the database is deleted. Changing calibration points, TCP, gripper, and lifting column parameters will mark the waypoints useless, which requires testing the pallet again.  

Active plan

The program will lock access to some important settings when the Active plan expires.

URCap version in the active program

The program will store information about the URCap version last used when the program was saved. Upgrading to a newer URCap without a valid Active plan will not work.

Grip Quality

The formula for computing the "Grip Quality" value has been redesigned. It is highly recommended to test all patterns after upgrading from URCap version 2.x to 3.x.

Pallet Manager Daemon variable name and visibility

The global variable palletmanager_daemon has been renamed to Pally_daemon. The legacy variable palletmanager_daemon is still available but only inside the Pally program node (initial MoveJ and callbacks).

Compatibility notes for version 3.2 and above

Lost vacuum signal

The program will no longer repeat the last position without notice when Lost vacuum signal is detected. (see Installation / URCaps / Pally / Gripper / Input Output)

When loss of vacuum is detected, the operator has to confirm how to proceed.

It is recommended that projects with a lost vacuum signal be tested and updated.

Compatibility notes for version 3.3 and above

Using foamHeight parameter in gripper.json

Due to a bug in all previous versions below v3.3 the foamHeightparameter in gripper.json was not used in calculations and path planning. It is recommended to test existing projects that use gripper.json with a custom value in foamHeight parameter.

 

Compatibility with CB 3.0 robots

Due to hardware limitations in the CB 3.0 control boxes, the Pally URCap may not run as smoothly as expected. Consider the following steps before installing Pally URCap on these robots.

Memory usage limitations on CB 3.0

Out of memory exceptions may occur during installation and configuration of the Pally URCap unless the following modification is made in the operating system.

 

  • Find the file run_gui.sh under /root

  • Find the line RUN_GUI="java …

  • Add the following option: -XX:MaxPermSize=128m

 

After the modifications, the line should look like this:

RUN_GUI="java -XX:MaxPermSize=128m -Djava.library.path=/root/GUI/lib -jar bin/*.jar"

 

Note: Make sure all whitespaces are inserted properly as shown above.

 

Note: Make sure all capital letters and small letters are properly written. The operating system is case sensitive and requires the parameter names to be written exactly as shown above.

 

Note: Repeat the above steps every time after upgrading Polyscope.

 

If you are not familiar with operating system parameter tuning, follow the steps below:

  • Connect a keyboard to the Teach Pendant or an USB connector in the control box

  • Press Control+Alt+F1 to enter the console

  • Log in with username root and password easybot

  • Go to the /root folder by entering cd /root

  • Type nano run_gui.sh to edit the file

  • Make the above described modifications, then press Ctrl+X to save the changes

  • Press Ctrl+Alt+F7 to return to the Polyscope screen

  • Disconnect the keyboard

  • Restart the robot 

Computational limitations on CB 3.0

In order to reduce calculation times and avoid lagging, keep the following rules in mind when creating pallet patterns.

 

  • Use "lock direction" for all boxes wherever possible.

  • Disable 2-ways and 4-ways gripper optimization and only add the enforced gripper orientation at positions where it is needed.

  • Use the "inverse approach" option for all layers except the highest layers.

  • Disable dynamic positioning of the lifting column, and control the lifting column through zones.json file(s)

  • Reduce the Pally log level to Error or Warning

Compatibility with other URCaps

The Pally URCap supports a wide range of hardware components, however, unexpected compatibility issues can occur with specific setups.

 

We have received feedback from customers using hardware controlled by additional URCap(s) that the robot program becomes unstable and stops randomly with the error message “Runtime too much behind” on E-series and “Communication with controller lost” on CB-series robots. These error messages are related to insufficient CPU resources or high peaks in CPU usage: while both Pally and the third party URCap can work as standalone, they can’t be used together without further adjustments.

 

There are several options to control CPU usage of the Pally URCap. By default, the program utilizes as much CPU as possible, and provides fast calculations and low response times. In combination with another URCap with high CPU demand however, this can cause the program to stop. In this case we recommend the following actions:

 

  • Reduce the CPU usage of the other URCap(s) if possible

  • Change the Pally CPU optimizer parameter rf_cpuidle_ticks

    • On E-series, try one of the following values: rf_cpuidle_ticks=50, 20, or 1

    • On CB-series, try rf_cpuidle_ticks=5000, 2000, or 1

    • larger values correspond to faster calculations, 

    • smaller values correspond to less peaks in CPU usage

Reduce complexity of the pattern and path planning as described in the previous section.