Relative Move wrong distance or inverted

Another member on my team developed a program on a UR5e, then sent the program files to me so I can continue development on location.

After importing the program onto my UR5e, many of the Relative Moves seem to have inverted. When I use the Move Here on the Relative Moves, the waypoints are in the right order. But when I play the program, the TCP Moves in the opposite direction. Additionally, some moves are going a different distance. (Setting the TCP in a consistent position then using Move here to verify it lines up with a specific part, then returning to that start position and playing the program results in a different end point.)

If anybody else has had this kind of issue, what have you done to resolve/work around it?

Sounds like he may have set a different TCP configuration that didn’t come with the program. Did he sent the installation file with it too that would contain that?

If this is the case, here we started defining the setting of the TCP using the script commands inside the program as opposed to doing it in the UI in the installation tab. This allowed us to have the TCP settings travel with the .urp file.

One example in the past was people writing programs and not setting the TCP at all, and then when a more experienced programmer took over, they would set the TCP properly and all the Z axis moves would be backwards.

I think that my have been the cause. I appeared the Move Nodes didn’t have a TCP defined and the first thing I did was assign TCP to each of the Move Nodes.