So im running calibration on my fixture object in my workcell. I run my 3 points touch up in real world and object get offset correction in roboguide. I create a 6 point (3points with fixture table flat and another 3 points on the other side 180*)test program in roboguide to test how close it comes to real world, and its usually pretty close. Issue comes when the table is turned 180* my points seem to shift. Im not sure what I could be doing wrong? Any insights, help, or suggestions?
Roboguide object calibration issues
-
ORDEP81 -
July 12, 2018 at 3:01 PM -
Thread is Resolved
-
-
Hi
What kind of "pretty close" dimensions are we talking ? Is you fixture 2 meters long or 5 mm long ?
My first thought "Do i have a really good TCP" ? That is critical, all you real world dimensions are going to be based on your TCP and problems when you rotate are typical from bad TCP -
Hi
What kind of "pretty close" dimensions are we talking ? Is you fixture 2 meters long or 5 mm long ?
My first thought "Do i have a really good TCP" ? That is critical, all you real world dimensions are going to be based on your TCP and problems when you rotate are typical from bad TCPSo on the 'normal' side after calibration im within 1-2mm out in real world. But once the table flips 180, im up 1/2" off. The fixture is 6' x 5'.
Now the TCP, was set up by our instructor as he was setting up our cells while teaching, and for some reason there was an offset to which i do not recall his reasoning to this.
-
Does the robot use coordinated motion? If so, is the turntable's "coordinated pair" calibrated accurately?
-
The real robot does use coordinated motion but is not set up on in roboguide
-
ummm… I would make sure, that the calibration is ok in real life, then make an AoA and load it to RG.
-
I'm killing myself thinking a difficult answer.
I don't want to blame the tcp, but there is an easy test you can do. Put a pointer on your table, move the tip of the torch there (on the "normal" side) and then rotate it. You'll see a good/bad it isAgain maybe this has nothing to do with the tool but we have to start somewhere
-
So as far as the real world robot everything works great and has been working fine for months. Its just trying to get Roboguide programs transfered onto it is when the issue come into play. The virtual programs do not line up with the real world.
-
Just a thought, does my UFRAME need to redone after calibration? So I set my object back to original position pre-calibration. Ran a 6 point test program using UFRAME (3-point method set up in roboguide and on physical robot), and none of the points lined up. Moved my object back to its calibration coordinates, and checked my UFRAME reference point and its off. Would this make a difference and should i redo my UFRAME(3points )?
-
Programs taught with a falsely defined TCP will work fine in most cases, as long as no complicated reorientations are done.
Have you checked the TCP and Ccorsinated Motion calibration?
-
Yes those are good.
The instructor was just using user frames to match up the virtual and real world robots and it worked great on another robot. We never used the 3 step calibration tool in roboguide. Not sure what going on now. I have been trying different things and multiple recalibrations last few weeks.
-
Ok so figure out my issue, but have not solved it yet. So when my object was calibrated it moved it from my rotation 0 axis. Issue is i do not know how to currently fix this to where it will rotate from my calibrated axis. Attached are the object at 0deg and second at 180deg. The red triad is where my object is currently sitting at and the orange square is my zero point as to where its all rotating from.
-
What model of controller are you running?
It's been a long while since I've done this, but somewhere on the controller there is a COORD setup that is dictating how attached UFRAMES are rotated.
the bad news is it's a pain to get right - the good news is you can definitely do it.Basically, the controller tries to calculate where the center of rotation of your table is, based on how the COORD frame is set up. This makes a frame that references the rotation of the table, which then governs how your UFRAME rotates when the table turns. This is usually done very 'roughly' because someone set it up just to coordinate a tool tip while jogging, and not for offline programs.
You might have to do it in the x-start or whatever it's called system boot.
I won't do a good job explaining all the steps, what you will want to do is get your hands on the Coordinated Motion option manual as it explains it better.Also, you've probably already done this but make absolutely sure your table is actually physically rotating 180 degrees. I've been caught before!
Setting up an accurate COORD frame will help with this.