[Keisuke.Sakai]

Hi RoboDK teams,

I encountered the following error while generating a program for the FAIRINO FR3MT robot in RoboDK:

Joint movement using cartesian targets is not supported. Change the target type to joint or use a cartesian movement.

Environment:

• RoboDK Version 6.0.1
  
• Robot: FAIRINO FR3MT
  

Program structure:

• MoveL(Target 1)
  
• MoveJ(Target 2)
  

The MoveL instruction is generated correctly, but the MoveJ instruction produces the above error.
Target 2 was intentionally created as a Joint Target in RoboDK. However, during program generation it appears to be treated as a Cartesian Target by the FAIRINO post processor.
Could you please clarify the following points?

1. Does the FAIRINO post processor support MoveJ only when the destination target is a Joint Target?
   
2. Is there any known issue where a Joint Target may be interpreted as a Cartesian Target during program generation?
   
3. Are there any RoboDK settings that should be checked (Reference Frame, Tool, Target Type, etc.)?
   
4. Could this be a limitation or bug in the current FAIRINO post processor?
   

A screenshot is attached for reference.

Thank you for your support.

Best regards,
Keisuke Sakai

[Albert]

I understand you are using the Fairino db post processor. The regular Fairino has the same limitation.

A the time we developed the Fairino post processor about 2 years ago it was not possible to have a linear movement given joint targets. Maybe this has changed now. Can you confirm?

If you can provide us with the syntax required to run a joint movement given a Cartesian target we can update the post processor accordingly.

[Miho Amemiya]

Thank you for your reply.
 
We checked with the FAIRINO end user.
 
When creating a PTP motion on the controller, the user selects a point from the point table. Each point stores both Cartesian coordinates and joint values.
 
Therefore, it is not clear whether the PTP motion is executed using the Cartesian coordinates or the joint values.
 
However, when the cursor is placed over a point name, the controller displays the joint values (J1-J6). This suggests that the PTP motion may be using the stored joint values, although we cannot confirm this definitively.
 
At this moment, we do not have documentation or programming examples that clarify this behavior.
 
For reference, we have attached screenshots showing that both Cartesian coordinates and joint values are stored for each point in the FAIRINO controller.
 
Best regards,
Miho Amemiya

[Albert]

Thank you for this information.

Can you confirm if you are using the Fairino db post processor?
Is it possible for you to share a program generated using the robot which includes a PTP movement the way you would like RoboDK to generate it?

[Miho Amemiya]

Thank you for your response.

The customer confirmed that the post processor being used is Fairino db.

I have attached a sample program generated on the robot. The program includes PTP and MoveJ movements.

Please let us know if any additional information is required.

[Sergei]

During the development of the Fairino_db postprocessor, we determined that defining points requires both Cartesian and joint values.

Because of this, it is critical to verify that the real robot's kinematic parameters match the simulated parameters exactly. Otherwise, the program generated by the Fairino_db postprocessor will produce errors.

[Miho Amemiya]

We received feedback from the customer regarding the FAIRINO FR3 issue discussed previously.
As requested, the customer compared the DH parameters of the physical FAIRINO FR3 robot with the DH parameters displayed in RoboDK.
According to the customer, the DH parameters appear to differ between the FR3 manual and the RoboDK robot model.
RoboDK FR3 model:

• J3 a = 280 mm
  
• J4 a = 240 mm
  

FR3 manual:

• J2 a = -280 mm
  
• J3 a = -240 mm
  

The customer also noted that the FR3 manual provides the DH parameters in radians, and it is possible that a different DH convention is being used. Therefore, they were unable to determine whether the alpha and theta values correspond directly to those displayed in RoboDK.
Screenshots of both parameter sets are attached for reference.
Could you please confirm:

1. Does the RoboDK FR3 robot model use the correct kinematic parameters for the FAIRINO FR3?
   
2. Are the differences above simply due to a different DH convention (Standard DH vs. Modified DH, axis assignment differences, sign conventions, etc.)?
   
3. Could a mismatch in DH definitions be related to the original issue observed with the Fairino_db post processor?
   

For reference, the original issue is as follows:

• Two targets have different Cartesian positions in RoboDK.
  
• However, the exported program contains identical joint values for those targets.
  
• When executing MoveJ/PTP on the physical FAIRINO controller, both targets result in the same robot position.
  

We would appreciate your feedback on whether the DH parameters or robot model definition could be contributing to this behavior.

[Albert]

To check if the kinematics of the robot is accurate, we should better take some joint values and check if the XYZ position and orientation of the end effector with respect to the robot base match (values displayed in RoboDK should match what you see in the controller).

There are different robot model conventions, such as DH or DHM. Even within the same convention you could find the exact same robot modelled identically but with a different set of parameters.