What might cause one of 4 grid positions to be in a non-reach-able pose?
What about waypoints set to a feature as a Reference point?
I set 4 corners, run the program, stop to make adjustments, try to send TCP to Grid Position 1 using Move Here and the robot literally tries to put the TCP where it’s rectum is, (literally under the robot base) which causes a crash.
Also, when I try to move to one of 2 waypoints based on a Reference point using Move Here it again tries to insert the TCP into it’s rectum, causing a crash.
For the former (grid position), I can move to positions 2, 3 and 4 no problem, but 1 keeps changing without me changing anything. I’ve tried swapping active TCPs and it doesn’t work. If I start the program and stop it, sometimes it goes where it’s supposed to. If I hit E-Stop or otherwise power down the robot it sometimes works when powered back up.
So definitely this type of behavior can result in the position being set with a different TCP (particularly orientation) than what is actively running. Likewise, if you’re now selected a Feature that is different than the one it was Set with, it will do some wonky stuff.
You can see this immediately: Insert a MoveJ and choose a Feature (anything but Base) and teach a waypoint. Now change the Feature to Base, and try to Move To your waypoint. It will be completely jacked (assuming the robot can even reach the position at all). Switch back to whatever Feature it was taught to, and you can Move To the position no problem.
Now as to why it SOMETIMES works, and other times doesn’t I have no idea. You mention you stop the program, make adjustments, then Move To a position. Is it possible that somewhere during program execution the TCP is changed to something different? That could cause this behavior when you try to go back to position 1.
Yes, it does. But when I use your URCap Set TCP to set the correct one it still goes to the wrong position.
I get the general idea behind Base and various features. But I’ve never understood how they interact in my program though.
I have a MoveJ who’s features is “referencePoint”. Where the hell is that feature? It’s not in my Installation / Features tab.
Program:
Features Tab:
Thanks!
Well I’d never claim that stuff I programmed was flawless lol. I have a healthy doubt about all my work, so just be doubly sure it’s ACTUALLY changing the TCP correctly. (and that the one you’re changing it to was the one that was selected when the point was taught)
As for the Features… I have no idea what that referencePoint is lol. There should absolutely be a Feature of that name present in the installation. They are a little strange/hard to describe, but they are like a little virtual “Base” and the robot can do some fancy math to transpose all your points. Very useful when you want to pattern out a part (like your other post example) because it allows you to tell the robot “take everything that was programmed here, and do the same thing 6 inches that way” and all you had to do was adjust the values of the Feature.
In that application, you don’t need to do anything special with the Feature, and it doesn’t even matter where it is. Just teach a new Plane, and when it asks to define the positive X axis, just jog x+ in base. Do the same for y when it asks you. Once it’s done, you’ll have a new Feature whose orientation in the same as Base. Except now you can programmatically offset its position (something you can’t do with the default Base).
Edit: that reference point might be something that’s getting generated by the Palletizing node. Might be why you don’t see it in the installation. Like I said, I don’t really care a whole lot for that node, so I can’t be sure, but I’d wager it’s doing what I’ve described (shifting a feature) so it generates a sort of dummy feature so that all your moves as part of that pallet shift correctly.
I think you’re correct. It’s not anywhere in the Installation. I also noticed I cannot ghost or delete the affected waypoints to fix them. Very frustrating to say the least.
In the “Feature” dropdown there was another “referencePoint_4”. I ticked that and ran my program and it went where it was generally supposed to go. I used Edit Pose to adjust to the correct drop off point and life seems to be somewhat back to normal.
Sadly, my level of understanding how UR works just went from “I think I know enough to get by” to “Crap. I don’t know shit!” 
Gonna be a day or so until I can get to my other issue of staggering my grid positions.
Thanks again for the help Eric. .
We found a bug when modifying points used by the palletizer template that sounds like it could be the same thing you have run up against. Even though you have a new reference and the palletizer will work based on that new reference, if you try to Move To one of the points, it will go to where it was originally taught. In other words, it references the original feature and moves to the point based on that. It can wreck a program in a hurry if you try to make modifications to the points because that modification gets done in the original feature, but is then referenced in the current feature.
Hello, I bumped into something similar. It seems that if you use the “Set Waypoint” option to teach a point with respect to a feature, the waypoint value is not saved correctly.
How to test:
- Choose set waypoint, choose base as feature, then teach a waypoint, record the new value of that waypoint.
- In the same position, choose set waypoint again, choose another feature (a point feature you define), then teach the waypoint, then look at the new value of the waypoint. It will be the same as the value from (1).
I used “Edit pose” instead and manually inserted the values that I want, then it works.