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!
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.
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.
Hello,
We are still experiencing this problem in a depalletising program where we have to be very precise, the UR10e is not going to the position that we have programmed.
To clarify, when I drive the robot to the waypoint in manual mode (local) the position is correct, then on automatic mode (remote) it can be between 2-5mm out in x, y or z.
We updated to the latest version of the Polyscope software and are still experiencing this problem. The only workaround I have is to observe the robot on auto mode and then adjust the programmed waypoint by the inverse of the offset.
Did anyone solve this?
This may be completely unhelpful but I had a similar issue where I discovered that my waypoint was linked to another or shared parameters with another. I would recommend doing a double check that your waypoints are not linked to others, are not J movements but are L movements instead and have no blend radii. These issues will cause a point to be slightly off of where you need it to be in automatic mode but not necessarily in manual mode. This is especially easy to miss if you are setting up relative movements. Beyond that, I have no clue what your issue could be, sorry. Hope you get it figured out though!
Editing to say that my specific issue was a waypoint that was using shared parameters with another waypoint that had a blend radius on it. This caused my waypoint to be slightly off every single time I ran it in auto mode until I removed the blend radius, then it worked perfectly.
Hi chartman,
Thanks for your response! That is interesting, I will check to make sure the waypoints are all linear and have no blend radius.
The sequence of moves is quite complex as access to the pallet is restricted and there are multiple product variants to pick from the tray.
Will edit if this is the solution.
Software version 5.13
I am having this issue. Don’t think it was a bug specific to 5.4.0.
We’re not using blended radii, think it is still a bug with the software.