What is the meaning of the wrist configuration settings when looking at the user frame settings in SYSFRAME.VA? We have multiple identical cells, each with their own user frame that was supposedly set up the same way, but I am finding that wrist configurations (for instance) for UF[1] on cell one is NUT,0,0,0, for UF[1] on cell two is FUT,0,0,0 and for UF[1] on a third cell is NUT,0,-1,0. I think I understand what these mean when associated with a taught position, but I am not fully understanding what it means as part of the user frame settings and how it could have happened that they were taught differently to result in the configuration differences. And this is not just an academic question for us, the issue we run into is occasionally when copying a program from one cell to the next we get situations where an axis will try to reach a point by trying to rotate almost 360 degrees the opposite way from what worked in the original cell. It seems it would make sense to somehow be related to these settings in the user frame setup, but I don't understand how exactly and what to do about it.
User Frames and Wrist Configuration Settings
-
pzzwhw -
February 10, 2020 at 6:56 PM -
Thread is Unresolved
-
-
You must reteach the user frames that is for sure. My guess is that you taught them by jogging the robot to a fixture and then save the position to a PR and declare the User Frame = PR[x].
If this is the case, then you must check the configuration of the taught position before you store it to the PR.
As a rule of thumb, when I teach a user frame to a fixture I am always using NUT 0,0,0 config before I store the position to a PR and declare the frame.
As a second rule of thumb, I always take into account what my Home position's configuration is. The reason behind this is that all of my programs start and stop at home position, so if for example my user frame is FUT 1,0,0 and my home position NUT 0,0,0, then the robot will start from a NUT 0,0,0 config, proceed to a program on a frame with different configuration which means a lot of unecessary posture changes and rotations then return to home position (meaning bringing back any rotations to 0 and config change again) then proceed to the MAIN program for pick/place/palletize which again has different User frames.
I always "tie" my user frames to my home position config. A lot healthier for the robot and a major reduction in cycle time.
-
The configuration is irrelevant for a user frame definition. It is just there as documentation to record the arm's configuration when the user frame was taught. Now if you move to one of the taught positions of a 3 point method it will use that config, but it won't affect points taught in that user frame.
The only information that matters for a user frame is x, y, z, w, p, and r.