hey,
I’m trying to make the Robot do a circular path relative to a point (a gripped Object) which is different from the TCP of the robot. I was wondering if it is somehow possible to change the Robots Tcp online so that the MoveP command would move the way i want or if i have to handle the transformation on my side.
thanks
You can use set_tcp() function. Just give your new TCP data as parameter. You can look it up in script manual.
would this have an impact on the performance of the robot since the new tcp is only a virtual one and won’t be in the centre of mass of the actual tool?
Depends if you use this function:
set_payload(m, CoG)
Set payload mass and center of gravity
Alternatively one could useset_payload_massand
set_payload_cog.Sets the mass and center of gravity (abbr. CoG) of the payload.
This function must be called, when the payload weight or weight
distribution changes - i.e when the robot picks up or puts down a
heavy workpiece.The CoG argument is optional - if not provided, the Tool Center Point
(TCP) will be used as the Center of Gravity (CoG). If the CoG argument
is omitted, later calls to set_tcp(pose) will change CoG to the new TCP.
The CoG is specified as a vector, [CoGx, CoGy, CoGz], displacement,
from the toolmount.Parameters
m: mass in kilograms
CoG: Center of Gravity: [CoGx, CoGy, CoGz] in meters.
Optional.
Example command: set_payload(3., [0,0,.3])
• Example Parameters:
– m = 3 → mass is set to 3 kg payload
– CoG = [0,0,.3] → Center of Gravity is set to x=0 mm, y=0 mm,
z=300mm from the center of the tool mount in tool
coordinates
To be honest it is a bit complicated, so best if you search the forum and script manual yourself to understand how it works. I wouldn’t want to mix it up.
The TCP is set independently of the CoG and payload, so you shouldn’t have any issues changing the tcp with set_tcp().
If I understand it correctly, if you call set_payload at least once it changes the way set_tcp behaves. Is that right?
If I call set_payload(4), then set_tcp(0,0,0.050) will put CoG at new TCP.
Yes that appears to be what the manual says but I haven’t tested this behavior. I’d recommend always calling set_payload() with a CoG argument to avoid this.
Also note, that there are two new sub-functions to set_payload(m, CoG) which respectively are set_payload_mass(m) and set_payload_cog(cog) that you could use, to avoid the confusion.
1 Like
So, If i set the Mass and CoG int the Script (by set_payload(m, CoG)), and just
use Join Angle Poses (like "movej([0,-0.98,-2.6,-2.1,-1.6,1.5],3,3,0,0) " …
Do I have to set the TCP?
You can run the robot without setting TCP, however the safety system uses TCP position in calculating force and position limits, so it’s recommended to do so.
Do you have any example of program that changes the TCP for each point of a path?
Like glue dispensing aplication. I want to know how to do that in the corect way.
Can you explain the use case in a bit more detail? Not sure I understand why you’d need to change the TCP like this?
Dass-PUR.script (9.2 KB)
Have a look in this program. Do you think is ok work like this?
I does a glue dispensing path over a outsole shoes
I don’t see anything obviously wrong with the program. Is the robot holding the dispenser or the shoe? If it’s the shoe and the dispenser is static you should look into remote TCP functionality to ensure that you maintain a constant speed relative to the dispensing head.
It holds the shoes and the dispenser is static.
I´m trying to make this program better, becouse I had some complaim about the way that I made it.
I made this program at 2017, and that time we just have the CB series (RTPC for now is not available to CB series).
Now we are changing the production to E-Series, and i will change the programs to remote TCP. As I Know, remote tcp was just releases about 6 month ago. So just now I started to change to It. Corona broke my legs here 
What were the complaints? My first question would be why it was written in script and not in polyscope? That makes it much harder to adjust any of the waypoints in the program.
Actualy I just made it in script to be easy to change it!
I draw the glue spray in Rhino3D (the shoes all came in Rhino3D files), and take the geometry and convert the coordinates.
Then i made a Java Desktop program that convert it to Script (doing almost the same way that the new “toolpath” function in e-series). In This program I can changes the angle, height, size, etc of the glue dispensing. And as shoes I have a lot of diferent sizes and models ( each model have more then 10 sizes, and left/right, and we work with about 3 models…so around 70/80 programs!). So I have and qrcode reader that read the programs and send it to the UR3 via script.
Seems like a good approach. Would potentially be convenient for the path to be relative to a feature (user coordinate frame) so that operators can make small adjustments in case something moves in the production environment.
Actually I have a reference point that we can change It.
Today the robot that run this program shows the C264A0 error… any ideais that what can cause it?
Hi @lucas.schneider, for help in dealing with error codes, please contact your distributor, we have a separate system for handling post sales service issues.