Hi, I have used the three point method and also direct entry method for teaching a tool frame and when I check the axis' they do not stay on they datum point. Rotating about the Z axis seems to be the worst as it seems to corkscrew up as you rotate about it. All of my robots are doing this in this cell all on different controllers. When I use direct entry method and w,p,r are all at 0 I would think all the axis would be in line with and perpendicular with the face plate, but I still have this issue. I believe it is giving me issues with my VGR Camera using to pick parts. Any suggestions?
Rotation around Z Axis of tool is corkscrewing
-
Copenhagen -
September 13, 2024 at 3:57 PM -
Thread is Unresolved
-
-
95devils
September 13, 2024 at 4:01 PM Approved the thread. -
verify your robots are mastered correctly. I had a similar issue and found one of our techs did not line up the axes on the lines correctly when remastering the robot after a battery failure. It would rotate perfectly around Z after that.
-
What DaveP said.
Either bad mastering, or mechanical damage to either the robot arm or the EOAT.
-
Thanks I will try remastering. When looking at the axis lines they all line up correctly. What steered us away from remastering is that it was the same issue on all 6 robots in our cell.
-
Key questions are: How much corkscrewing? On which axes? Some degree of it is inevitable, no matter how perfectly the robot is mastered or the TCP is taught. It's just the nature of robots.
In the past, I had cause to try creating some very precise TCPs, using a laser tracker and iteratively tuning the TCP values in 0.1mm increments, and quickly found a point where reducing the error on one axis increased error on the other.
-
Key questions are: How much corkscrewing? On which axes? Some degree of it is inevitable, no matter how perfectly the robot is mastered or the TCP is taught. It's just the nature of robots.
In the past, I had cause to try creating some very precise TCPs, using a laser tracker and iteratively tuning the TCP values in 0.1mm increments, and quickly found a point where reducing the error on one axis increased error on the other.
Similar to me, you usually can't perfectly calibrate the TCP, on my case I used mechanical comparators and even lasers to measure the center of a cilynder, and no matter how much I tried, I always got deviation even while the measurements with the lasers were of less than 0.01mm difference when rotating the part.
I mean... I've done it using 4 points of the cylinder, rotating the part 90, 180, and 270 degrees while correctling the tcp after each iteration to recenter the tcp, but no matter how fine tuned the tcp was, when reorienting it always deviated a little. Also the same happened on my case, it reached a point where correcting on one direction would deviate into the other, even when correcting less than 0.1mm.
I ended just assuming there would be always a reorientation error, it was not much, but if the deviation was greater than 0.1mm while rotating the results were noticeable.
-
I ended just assuming there would be always a reorientation error, it was not much, but if the deviation was greater than 0.1mm while rotating the results were noticeable.
I've sometimes had to use different TCPs (or corrective offsets) for when the robot was working in different poses. Although that was when I was trying to align two robots to within .25mm over a very large 6DOF volume.