Universal Robots Forum

Possible bug - 5.4.0 Palletizing

Software version 5.4.0
UR10-e

Greetings from a first-time user of this forum!

I’m chasing down a bug in the Palletizing template, and I wonder if anyone else has any insight on the issue. Here is what I’m observing:

In some cases during program execution, the placement of objects in the Palletizing pattern seems to be shifted as though it is using a different Feature or TCP than was used for programming the Corner Item positions. If I stop the program and manually command the robot to move to each Corner Item position, the robot moves to the correct positions.

Can anyone think of a case in which the reference points used for incrementing the Palletizing locations could be erroneously associated with the wrong TCP or Feature? Any ideas on other possible causes of this issue?

Thanks for the help!

1 Like

There may be a bug here.

Iv’e run into a number of issues with palletizing. Position while programming and runtime are often different.

The only way I’ve found to fix most issues in palletizing is to run through the wizard again from scratch. Manual set the pallet position or TCPs also does not seem to provide the expected operation at runtime.

Our multi tool mount can mount 3 tools. No matter what TCP we set, the pallet node often picks the wrong one whether we set it specifically or “use active TCP”.

Edit: Using Polyscope 5.6.0

The best solution is to upgrade your Polyscope version to 5.8.0.

There are known bugs and performance issues when using multiple palletizing routines within the same program on older versions.

I have had a lot better luck with palletizing since 5.8.0 was released.

Hope this helps.

1 Like

Thank you, I was just updating and read this.

I didn’t see anything in the patch notes about palletizing but I will give it another try.

Edit: Currently program is behaving with version 5.8 but not fully tested. At least it is now picking the correct TCP for the output pallets. I can’t say why it started using the wrong TCP previously so hopefully this continues.

We did indeed have 3 separate pallet sections in the program. Input, and then output pass and fail pallets. 3 separate TCPs used in the program but only 1 TCP used for the pallet load/unload.