By default, Pally uses as much CPU as possible when calculating the robot trajectory for the next pick and place. This behaviour has been chosen in order to achieve the shortest response times and minimal delays during palletizing.
However, the UR control boxes have limited computational resources, and may not be able to provide enough CPU if multiple URCaps are installed or the robot program contains additional threads.
In general, we can’t control the resource usage of other URCaps and threads, but can control the CPU usage of Pally.
Adjust the Pally CPU optimizer parameters
Set the variable rf_cpuidle_ticks under the initial MoveJ node under the Pally program node.
Changing this parameter can significantly eliminate high peaks in CPU usage caused by the Pally program without losing any functionality. Calculations will take longer time, but in most cases this will remain almost invisible for the user, as the major part of the calculations are performed in the background while the robot is moving back from the pallet position to the next pick position.
On E-series, try one of the following values.
Medium CPU usage:
rf_cpuidle_ticks = 50
Low CPU usage:
rf_cpuidle_ticks = 20
Lowest CPU usage (significant delays may be observed):
rf_cpuidle_ticks = 1
On CB-series, try the following values.
Medium CPU usage:
rf_cpuidle_ticks = 5000
Low CPU usage:
rf_cpuidle_ticks = 2000
Lowest CPU usage (significant delays may be observed):
rf_cpuidle_ticks = 1
Larger values correspond to faster calculations.
Manually optimize Pally to reduce the amount of calculations
Simplify the patterns and the Pally program by doing the following steps:
reduce the Pally log level to Error or Warning
use inverse approach for all layers where possible
use lock direction for all boxes
disable 2-ways and 4-ways gripper optimization, and use enforced gripper rotations only at positions where reach is critical
disable dynamic positioning of the lifting column, and control the lifting column through zones.json file(s)