[stcegepgim]

I'm working on a test project with RoboDK using a UR5e for offline programming. When I transfer the program to the real unit, this is what we found (using the default Universal Robot post processor in RoboDK):

• All the move L with a pose (coordinate position) are precise and in the right place;
  
• All the move J with a pose (coordinate position translated to a joint position by the postprocessor) are offset by at least 40 to 100 mm in X and Y. Example:
  
•    Translated position in X should be  439mm and is 396 mm instead.
  
•    Translated position in Y should be -222mm and is -316 mm instead.
  
•    Z position is good.
  
•    Rotations are good.
  

I tried updating the kinematics with a URP file. The matrix changes but the position in the real world, not really ...

The UR5e robot was manufactured in 2023 with polyscope version 5.12.3.

[Albert]

Do you load the URP file or the script file on the UR robot controller?

If you take one random joint position of the real robot in RoboDK (for example, use the driver and retrieve the current joint position), does the Cartesian position show in RoboDK match the kinematics shown in the robot controller?

[stcegepgim]

Do you load the URP file or the script file on the UR robot controller?

If you take one random joint position of the real robot in RoboDK (for example, use the driver and retrieve the current joint position), does the Cartesian position show in RoboDK match the kinematics shown in the robot controller?

Hey Albert, 

I imported a script file on the robot controller instead of using a URP file.


Regarding the post processing error.... Please look at the attached PDF.
When I look at the scrip, the joint position for a specific target translated in degrees is different as the configuration from the interface ... This creates an offset when transfer on the real robot. 

This is happening only on MoveJ. All MoveL are fine.

Albert, RoboDK and our fleet of UR5e are use for teaching. I would appreciate if one of your team member could give me a more direct line to technical service as our educational license does not allow it.

Simon

[Albert]

You can right click on a program and select "Recalculate Targets" to update the joint position of Cartesian targets that you want to move to using a Joint movement. You can perform this update automatically by changing the corresponding setting in the Tools-Options-Program menu.

Also, if you generate programs using the Universal Robots URP post processor you'll obtain a URP file that you can load on your robot controller and you'll see Joint movements with targets defined using Cartesian information.

Feel free to contact us through the forum or by email if you need more information.

[stcegepgim]

You can right click on a program and select "Recalculate Targets" to update the joint position of Cartesian targets that you want to move to using a Joint movement. You can perform this update automatically by changing the corresponding setting in the Tools-Options-Program menu.

Also, if you generate programs using the Universal Robots URP post processor you'll obtain a URP file that you can load on your robot controller and you'll see Joint movements with targets defined using Cartesian information.

Feel free to contact us through the forum or by email if you need more information.

Hey Albert,

I tried using "Recalculate Targets" and also change the configuration in the Tools-Options-Program but the output script is the same. I'll try using the URP file instead. I'll keep you posted.

Is it  a bug in the script with the post processor or I'm doing something wrong ?

I sent a couple of emails to info@robodk.com but no response so far.

Simon

---

Hey Albert,

I was finally able to make it work.
After configuring the automatic recalculation, I still had to select each indivudual sub-program and generate it in order to get the change in the position.
Seems like it was not recalculating sub-program's target ....

I was still able to use the script and it worked fine after recalculation.

Thank you for your help.

[Albert]

Did you load the URP file generated using the same robot controller you are using to program the robot? Is the coordinate system the same? It looks like the controller kinematics has been properly loaded from the URP file provided.

Can you resend your requests to info@robodk.com? I'm unable to find anything under the domain Cegepgim on our CRM.

[stcegepgim]

Did you load the URP file generated using the same robot controller you are using to program the robot? Is the coordinate system the same? It looks like the controller kinematics has been properly loaded from the URP file provided.

Can you resend your requests to info@robodk.com? I'm unable to find anything under the domain Cegepgim on our CRM.

Yes, I use the same physical robot that gave the URP file to update the kinematic. After regenerating all the subprogram before generating the main program it worked. The robot is now going to the right position and looking at the script, the joint target are now different. 

I resent a resquest to info@robodk.com. Look for the domain cegepgim.ca
On your CRM, the customer should be "Origine Innovation". They provided us with the robots and all the software.

[Albert]

For some reason your email didn't reach our CRM (maybe it was tagged as spam). I just got back to your email.

Regarding the coordinate mismatch, is this issue happening only for the UR5e Home target? If so, you should set this target as a Cartesian target.

Let us know if this does not fix the issue. If the issue persists, are you checking against the robot panel or against the target coordinates?

[stcegepgim]

For some reason your email didn't reach our CRM (maybe it was tagged as spam). I just got back to your email.

Regarding the coordinate mismatch, is this issue happening only for the UR5e Home target? If so, you should set this target as a Cartesian target.

Let us know if this does not fix the issue. If the issue persists, are you checking against the robot panel or against the target coordinates?

The problem is now solved. The issue was happening on every cartesian targets used within a MoveJ. The offset was huge (close to 100 mm in some cases). Attached is my complete analysis on the issue showing that the translation from a cartesian target to a joint configuration for a MoveJ is completely wrong.

SOLUTION:

1. Follow the procedure to update the robot kinematic on RoboDK for the real robot.
   
2. Set the "recalculate targets" option on the configuration menu ( Tools-Option-program).
   
3. Right click on every subprograms and select "recalculate targets".
   
4. Generate the UR Script (generate program) for each subprograms.
   
5. Generate the UR Script (generate program) for the main program that contains all the subprograms.
   

Thanks,