UR10e / PolyScope 5.26.0 freezes after entering an unreachable Cartesian pose

Technical Questions Report a Bug
1

Hi,

I am experiencing a reproducible issue with a UR10e running PolyScope 5.26.0.

For context, we have two UR10e robots. One robot originally had a defective joint. We replaced its complete robot arm with the arm from our second UR10e, while keeping the original control box.

The replacement arm starts normally and all six joints report OK. The robot can also be moved normally.

However, the control box still shows the serial number of the original robot, while the replacement arm has a different serial number. Both units are UR10e robots from 2021/2022:
Control box / PolyScope S/N: 2022520xxxx
Replacement arm S/N: 2021528xxxx

However, I found the following reproducible problem in the Move screen:

  1. Select the Base coordinate system.
  2. Open the Cartesian tool position editor (X, Y, Z, RX, RY, RZ).
  3. Enter an obviously unreachable position, for example X = 3000 mm.
  4. PolyScope correctly reports that the pose is invalid/unreachable.
  5. Press Cancel.
  6. After this, the robot can no longer be jogged from the Move screen.

There is another strange symptom: when I open the Cartesian position editor again, all values are displayed as:

X = 0, Y = 0, Z = 0, RX = 0, RY = 0, RZ = 0

However, after leaving the editor, the normal tool-position display still shows plausible/current Cartesian coordinates.

The robot remains in this state and I have not found a way to recover it through PolyScope. Even shutting down through the GUI may no longer work correctly. A restart is required, after which the robot works normally again.

What I have already tested

The system originally had OnRobot URCap 6.2.0 installed with OnRobot hardware. Initially I suspected the OnRobot installation.

I therefore:

  • disconnected the OnRobot hardware,
  • uninstalled the OnRobot URCap,
  • restarted the robot,
  • verified that the robot operates normally,
  • reproduced the same X = 3000 mm → invalid pose → Cancel sequence.

The problem still occurs with the OnRobot URCap uninstalled, so it does not appear to be caused by OnRobot.

I also checked the Linux console. At approximately the time the UI became unresponsive, PolyScope generated files named:

/tmp/UIBlockedWatcher-...-event-listeners-....log
/tmp/UIBlockedWatcher-...-threads-....log

The thread dump contains threads waiting around the Java AWT/Swing graphics system, including calls such as:

sun.awt.SunToolkit.awtLock(...)
sun.java2d.xr.XRMaskFill(...)
javax.swing.JComponent.paint(...)

So PolyScope itself appears to detect a blocked UI condition when the problem occurs.

Questions

Has anyone seen this behavior on PolyScope 5.26.0?

In particular:

  • Is this a known PolyScope 5.26.0 bug related to unreachable Cartesian poses / the Move screen?
  • Could it be related to using a different UR10e arm with the original control box?
  • Is there any calibration or arm/control-box pairing procedure required after swapping complete UR10e arms?
  • Is there a known workaround or a newer 5.26.x release that fixes this?
  • Would testing PolyScope 5.25.2 be useful, and if so, what is the supported way to do this given that normal PolyScope downgrades are not supported?

Thanks!

2

The control box is just a control box but the calibration information that you need is on the SD card from the control box of the robot you moved. The SD card should always stay with the arm and can move from/to any compatible controller. Consider the SD card and the robot the mated pair. I would also check to make sure that are no URcaps that are installed but no longer being used and remove them. You have to first remove them from the system settings (and restart the robot) and then remove them from the installation file (don’t forget to save the changes). I specifically have had issues with the Remote TCP & Toolpath URcap causing strange freezes of the robot and the teach pendant itself that went away once I removed it.

3

Our Field Application Engineer of UR, told us, this is not the case anymore?

Is it? Im now also not sure if his response was just related to the new Controller or als Valid for older ones..

To me, the logical point to store the calibration values would be on the arm itself…

5

Hi @yannick4 We have recreated the issue in-house. One of the next patch releases (5.26.1 or 5.26.2) will contain a fix.

Thank you for reporting!

6

Thanks everyone for the replies and for looking into this.

  • Robot Arm 1: faulty arm
  • Robot Arm 2: replacement arm

The faulty behavior described above occurred with the following setup:

I replaced Robot Arm 1 with Robot Arm 2 without swapping the corresponding SD cards.

  • Robot Arm 2
  • Control Box 1
  • SD Card 1

Here is a quick update on what I have found since my original post:

I then swapped SD Card 1 for SD Card 2, as suggested by @justin.tinney, reuniting Robot Arm 2 with its original SD card. SD Card 2 was running PolyScope 5.13, under which the robot had previously operated normally. With this configuration, the freeze no longer occurred :tada:

SD Card 1, however, was running PolyScope 5.26.0, so I also updated the new setup using SD Card 2 to PolyScope 5.26.0 as well.

After this change, I observed the same faulty behavior with the other SD card. In other words, the issue follows the PolyScope version rather than the robot arm. My initial assumption that the arm was the cause was therefore incorrect.

I still had a system backup from the old, working PolyScope 5.13 system. However, restoring it from PolyScope 5.26.0 fails with:

Detecting backup format
Detected legacy squashfs archive
ERROR: Partition-only backup can only be restored to PolyScope versions lower than <5.25

Unfortunately, I only saw UR Development Support’s post confirming the PolyScope 5.26.0 bug after I had already performed these tests. Since UR Development Support has now reproduced the exact issue in-house on PolyScope 5.26.0, it appears that the freeze is indeed caused by a PolyScope 5.26.0 bug. Unfortunately, I cannot simply restore the old PolyScope 5.13 system state while running PolyScope 5.26.0.

I urgently need to get the robot operational again, so I am considering reverting to PolyScope 5.25.2 until a fix is released in PolyScope 5.26.1 or 5.26.2.

Could UR Development Support please confirm:

  • whether PolyScope 5.25.2 is unaffected by this particular Cartesian-pose freeze; and
  • what the recommended and supported procedure is for downgrading an e-Series UR10e from PolyScope 5.26.0 to PolyScope 5.25.2? I have not been able to find clear instructions for this.

If there is already an estimated release window for PolyScope 5.26.1 or 5.26.2, that information would also be very helpful.

Thanks again for reproducing the issue and confirming that a fix is planned.