https://robodk.com/forum/ Thu, 15 Oct 2026 08:58:27 +0000 MyBB https://robodk.com/forum/Thread-Conveyor-tracking-with-RoboDK-e-g-Curve-Follow-Project Thu, 15 Oct 2026 03:58:42 +0000 Keisuke.Sakai]]> https://robodk.com/forum/Thread-Conveyor-tracking-with-RoboDK-e-g-Curve-Follow-Project
I am planning an application similar to welding where parts are moving on a conveyor.

1. Is it possible to use features like the "Curve Follow Project" for a moving workpiece (conveyor tracking) natively in RoboDK?
   
2. If it is not possible natively and requires combining with the RoboDK API, could you please explain or provide the recommended approach/workflow to achieve real-time synchronization with a conveyor?
   

Thank you for your support!
Keisuke Sakai

  新しいプロジェクト (1).rdk (Size: 3.52 MB / Downloads: 0) ]]>
I am planning an application similar to welding where parts are moving on a conveyor.

1. Is it possible to use features like the "Curve Follow Project" for a moving workpiece (conveyor tracking) natively in RoboDK?
   
2. If it is not possible natively and requires combining with the RoboDK API, could you please explain or provide the recommended approach/workflow to achieve real-time synchronization with a conveyor?
   

Thank you for your support!
Keisuke Sakai

  新しいプロジェクト (1).rdk (Size: 3.52 MB / Downloads: 0) ]]> https://robodk.com/forum/Thread-UR-Post-processor-converts-movec-command-to-moveL-command Wed, 14 Oct 2026 11:21:16 +0000 Marijnd01]]> https://robodk.com/forum/Thread-UR-Post-processor-converts-movec-command-to-moveL-command https://robodk.com/forum/Thread-Real-time-robot-UR5-tracking-in-RoboDK Mon, 12 Oct 2026 14:35:41 +0000 badidou213]]> https://robodk.com/forum/Thread-Real-time-robot-UR5-tracking-in-RoboDK
When I move the robot using the teach pendant, I can see its movements on the tablet but the virtual robot in RoboDK does not update automatically. I know there is an option to retrieve the robot's current position but I have to click it manually and it doesn't keep updating as the robot moves.

Is it possible to configure RoboDK to continuously display the real robot's position and follow its movements? Also when I execute a pick and place program I would like to see the physical robot's movements reflected in RoboDK in real time rather than just seeing the simulation. How can I achieve this?]]>
When I move the robot using the teach pendant, I can see its movements on the tablet but the virtual robot in RoboDK does not update automatically. I know there is an option to retrieve the robot's current position but I have to click it manually and it doesn't keep updating as the robot moves.

Is it possible to configure RoboDK to continuously display the real robot's position and follow its movements? Also when I execute a pick and place program I would like to see the physical robot's movements reflected in RoboDK in real time rather than just seeing the simulation. How can I achieve this?]]> https://robodk.com/forum/Thread-Issue-Editing-Targets-in-Curve-Follow-Project Thu, 08 Oct 2026 15:13:23 +0000 joshb5643]]> https://robodk.com/forum/Thread-Issue-Editing-Targets-in-Curve-Follow-Project I noticed that when creating a curve follow project I have a reference frame set in the curve follow project settings but when I run the program with the robot panel open, the drop down is set to the Fanuc base frame, however I do not recognize the active frame coordinates. If I right click set ref instruction and uncheck ‘force original pose’ then the active frame does change to the expected frame, but none of the positions are reachable. I’ve tried recalculating targets but this fails.
Disabling ‘Impose original tool and reference in programs’ fixes the reference frame issue but now I cannot get the curve follow projects to run at all and the points that the robot will move to are completely incorrect. I get a green check with ‘path solved successfully’ but when I simulate/run it just moves to the first point and stops. The green tool path looks correct but again the points that it does move to are not even close.]]> I noticed that when creating a curve follow project I have a reference frame set in the curve follow project settings but when I run the program with the robot panel open, the drop down is set to the Fanuc base frame, however I do not recognize the active frame coordinates. If I right click set ref instruction and uncheck ‘force original pose’ then the active frame does change to the expected frame, but none of the positions are reachable. I’ve tried recalculating targets but this fails.
Disabling ‘Impose original tool and reference in programs’ fixes the reference frame issue but now I cannot get the curve follow projects to run at all and the points that the robot will move to are completely incorrect. I get a green check with ‘path solved successfully’ but when I simulate/run it just moves to the first point and stops. The green tool path looks correct but again the points that it does move to are not even close.]]> https://robodk.com/forum/Thread-Welding-Add-In-RoboDK Thu, 08 Oct 2026 13:34:53 +0000 YannikB]]> https://robodk.com/forum/Thread-Welding-Add-In-RoboDK
I would like to use the Welding Add-In in RoboDK for a welding project / WAAM application. I have already sent several inquiries regarding this, but unfortunately, I have not received a response yet.

Do you have any experience with the Welding Add-In or know how the process works? I would really appreciate it if you could give me some information or point me in the right direction.

I would like to get started with the Welding Add-In as soon as possible, so any help or information would be greatly appreciated.

Thank you very much in advance for your support.

Best regards,

Yannik]]>
I would like to use the Welding Add-In in RoboDK for a welding project / WAAM application. I have already sent several inquiries regarding this, but unfortunately, I have not received a response yet.

Do you have any experience with the Welding Add-In or know how the process works? I would really appreciate it if you could give me some information or point me in the right direction.

I would like to get started with the Welding Add-In as soon as possible, so any help or information would be greatly appreciated.

Thank you very much in advance for your support.

Best regards,

Yannik]]> https://robodk.com/forum/Thread-Request-to-Add-EFORT-GR6150-2900-Robot-Model-and-Post-Processor Tue, 06 Oct 2026 13:46:51 +0000 sauer]]> https://robodk.com/forum/Thread-Request-to-Add-EFORT-GR6150-2900-Robot-Model-and-Post-Processor EFORT GR6150-2900 industrial robot.

The robot model is essential for my current project, and I would greatly appreciate it if an official GR6150-2900 model could be added to the RoboDK robot library.

If possible, I would also like to request a post processor for the EFORT controller, so that programs generated in RoboDK can be exported for use on the real robot. The post processor is not mandatory at this stage, but it would be very helpful if it could also be provided.

Reference file: https://www.efort.com.cn/index.php/servi...e/200.html

Thank you very much for your help and support.
Best regards]]> EFORT GR6150-2900 industrial robot.

The robot model is essential for my current project, and I would greatly appreciate it if an official GR6150-2900 model could be added to the RoboDK robot library.

If possible, I would also like to request a post processor for the EFORT controller, so that programs generated in RoboDK can be exported for use on the real robot. The post processor is not mandatory at this stage, but it would be very helpful if it could also be provided.

Reference file: https://www.efort.com.cn/index.php/servi...e/200.html

Thank you very much for your help and support.
Best regards]]> https://robodk.com/forum/Thread-FANUC-MoveC-completes-physically-but-RoboDK-remains-at-Working Thu, 01 Oct 2026 18:30:19 +0000 joshuag1041]]> https://robodk.com/forum/Thread-FANUC-MoveC-completes-physically-but-RoboDK-remains-at-Working
I’m encountering an issue with online circular motion using the Python API. The robot executes the MoveC arc and stops at the endpoint, but RoboDK remains at “Working…” and the blocking MoveC call never returns. MoveJ and MoveL complete normally, and the same arc works in simulation.
My setup is:

• RoboDK 6.0.0 on Windows
  
• FANUC Socket Messaging driver 5.3.2
  
• FANUC LR Mate 200iD/7L
  
• Controller software V9.10P/26
  

I replaced the controller programs using the V9 RDK_S3.PC and accompanying TP files from the downloaded driver package, but the issue persists.
During the arc, GO_MC shows MOVING at line 2. Afterward, it shows ABORTED at line 1, while RDK_S3 remains RUNNING with observed line readings around 516–525. There are no active alarms or corresponding alarm-history entries.
I’ve attached the Python script, connection log, and relevant screenshots. Could you check whether this is a driver compatibility or motion-completion reporting issue and advise on the appropriate fix?

Best,

Joshua

  robot_circular.py (Size: 3.83 KB / Downloads: 22)

  IMG_2D4556DB-C5B0-4495-B036-678E34FBA1B4.jpeg (Size: 294.83 KB / Downloads: 27)

  IMG_564E910A-76F6-44C4-B4AD-E90926DBECA8.jpeg (Size: 308.46 KB / Downloads: 25)

  IMG_0995.jpeg (Size: 624.81 KB / Downloads: 27)

  IMG_0997.jpeg (Size: 594.16 KB / Downloads: 29)

  IMG_0998.jpeg (Size: 587.41 KB / Downloads: 30)

  image(6).png (Size: 11.77 KB / Downloads: 37) ]]>
I’m encountering an issue with online circular motion using the Python API. The robot executes the MoveC arc and stops at the endpoint, but RoboDK remains at “Working…” and the blocking MoveC call never returns. MoveJ and MoveL complete normally, and the same arc works in simulation.
My setup is:

• RoboDK 6.0.0 on Windows
  
• FANUC Socket Messaging driver 5.3.2
  
• FANUC LR Mate 200iD/7L
  
• Controller software V9.10P/26
  

I replaced the controller programs using the V9 RDK_S3.PC and accompanying TP files from the downloaded driver package, but the issue persists.
During the arc, GO_MC shows MOVING at line 2. Afterward, it shows ABORTED at line 1, while RDK_S3 remains RUNNING with observed line readings around 516–525. There are no active alarms or corresponding alarm-history entries.
I’ve attached the Python script, connection log, and relevant screenshots. Could you check whether this is a driver compatibility or motion-completion reporting issue and advise on the appropriate fix?

Best,

Joshua

  robot_circular.py (Size: 3.83 KB / Downloads: 22)

  IMG_2D4556DB-C5B0-4495-B036-678E34FBA1B4.jpeg (Size: 294.83 KB / Downloads: 27)

  IMG_564E910A-76F6-44C4-B4AD-E90926DBECA8.jpeg (Size: 308.46 KB / Downloads: 25)

  IMG_0995.jpeg (Size: 624.81 KB / Downloads: 27)

  IMG_0997.jpeg (Size: 594.16 KB / Downloads: 29)

  IMG_0998.jpeg (Size: 587.41 KB / Downloads: 30)

  image(6).png (Size: 11.77 KB / Downloads: 37) ]]> https://robodk.com/forum/Thread-Request-to-add-ROKAE-NB12-12-1-4 Thu, 17 Sep 2026 09:54:17 +0000 WesleySpits]]> https://robodk.com/forum/Thread-Request-to-add-ROKAE-NB12-12-1-4 Hello,

Would it be possible to add ROKAE NB12-12/1.4 to the library?


Thanks

  Schermafbeelding 2026-09-17 112930.jpg (Size: 73.11 KB / Downloads: 69)

  Rokae NB12-12-1.4.STEP.zip (Size: 5.45 MB / Downloads: 38) ]]> Hello,

Would it be possible to add ROKAE NB12-12/1.4 to the library?


Thanks

  Schermafbeelding 2026-09-17 112930.jpg (Size: 73.11 KB / Downloads: 69)

  Rokae NB12-12-1.4.STEP.zip (Size: 5.45 MB / Downloads: 38) ]]> https://robodk.com/forum/Thread-Reference-frame-not-applied-correctly-when-robot-is-mounted-on-rail Wed, 16 Sep 2026 18:48:18 +0000 Elie_Roy]]> https://robodk.com/forum/Thread-Reference-frame-not-applied-correctly-when-robot-is-mounted-on-rail
I'm running into an issue where a manually-taught reference frame is not being used correctly when generating a program, and I've isolated it down to something that only happens when the robot is mounted on a linear rail (external axis / synchronized mechanism).

Setup:

• Robot: Fanuc R-2000iC/210L, mounted on a linear track (RoboDK mechanism "My Mechanism", external axis E1)
  
• Post processor: stock Fanuc_R30i post
  
• Reference frame: Frame Wall 1, taught and set correctly in the station
  

The problem:
In simulation, a target is correctly reached at X=2000mm, Y=-2000mm in Frame Wall 1's local coordinates. But when I generate the program, the output writes this same point as X=6650mm, Y=-3480mm under UF:1
— which is wrong for Frame Wall 1.
I traced this and confirmed the difference (X: +4650, Y: -1480, Z: +120) exactly matches the offset between my Station ORIGIN and Frame Wall 1. In other words, the generated program is outputting the target's coordinates relative to the station origin, not relative to Frame Wall 1 — even though Frame Wall 1 is explicitly set as the active reference frame before the moves in question.

I've tried all the combinaison of option in the program's option setting. As well as changing the post USE ROBOD_UFRAME = True / False in post processor. nothing works

Thanks,

Élie

  Screenshot 2026-09-16 144523.png (Size: 174.37 KB / Downloads: 42)

  Screenshot 2026-09-16 142123.png (Size: 24.3 KB / Downloads: 36)

  Screenshot 2026-09-16 142028.png (Size: 369.11 KB / Downloads: 42)

  Screenshot 2026-09-16 140914.png (Size: 113.1 KB / Downloads: 39)

  Screenshot 2026-09-16 140441.png (Size: 49.39 KB / Downloads: 44)

  Screenshot 2026-09-16 140206.png (Size: 14.65 KB / Downloads: 47) ]]>
I'm running into an issue where a manually-taught reference frame is not being used correctly when generating a program, and I've isolated it down to something that only happens when the robot is mounted on a linear rail (external axis / synchronized mechanism).

Setup:

• Robot: Fanuc R-2000iC/210L, mounted on a linear track (RoboDK mechanism "My Mechanism", external axis E1)
  
• Post processor: stock Fanuc_R30i post
  
• Reference frame: Frame Wall 1, taught and set correctly in the station
  

The problem:
In simulation, a target is correctly reached at X=2000mm, Y=-2000mm in Frame Wall 1's local coordinates. But when I generate the program, the output writes this same point as X=6650mm, Y=-3480mm under UF:1
— which is wrong for Frame Wall 1.
I traced this and confirmed the difference (X: +4650, Y: -1480, Z: +120) exactly matches the offset between my Station ORIGIN and Frame Wall 1. In other words, the generated program is outputting the target's coordinates relative to the station origin, not relative to Frame Wall 1 — even though Frame Wall 1 is explicitly set as the active reference frame before the moves in question.

I've tried all the combinaison of option in the program's option setting. As well as changing the post USE ROBOD_UFRAME = True / False in post processor. nothing works

Thanks,

Élie

  Screenshot 2026-09-16 144523.png (Size: 174.37 KB / Downloads: 42)

  Screenshot 2026-09-16 142123.png (Size: 24.3 KB / Downloads: 36)

  Screenshot 2026-09-16 142028.png (Size: 369.11 KB / Downloads: 42)

  Screenshot 2026-09-16 140914.png (Size: 113.1 KB / Downloads: 39)

  Screenshot 2026-09-16 140441.png (Size: 49.39 KB / Downloads: 44)

  Screenshot 2026-09-16 140206.png (Size: 14.65 KB / Downloads: 47) ]]> https://robodk.com/forum/Thread-Question-Regarding-FANUC-Target-Configuration-in-RoboDK Wed, 16 Sep 2026 12:49:45 +0000 merin]]> https://robodk.com/forum/Thread-Question-Regarding-FANUC-Target-Configuration-in-RoboDK I have a question regarding the FANUC LS program generated by RoboDK.
I am using RoboDK version 5.9.0 with a FANUC LR Mate 200iD/7L robot. I generate the robot program using a RoboDK Python script and the FANUC RJ3 post processor.
I would like to keep the robot configuration as F U T.
In the RoboDK simulation, the robot moves with the desired F U T configuration. However, I found that the joint angles stored in some Targets do not correspond to the F U T configuration. Instead, some Targets appear to have joint angles corresponding to the F D B configuration.
For example, the generated LS file contains:
P[32]{
GP1:
UF : 2, UT : 2, CONFIG : 'F U T, 0, 0, 0',
X = 792.980 mm, Y = 129.270 mm, Z = 160.000 mm,
W = 90.000 deg, P = 0.000 deg, R = -119.518 deg
};
P[33]{
GP1:
UF : 2, UT : 2, CONFIG : 'F D B, 0, 0, 0',
X = 826.627 mm, Y = 164.595 mm, Z = 160.000 mm,
W = 90.000 deg, P = 0.000 deg, R = -149.036 deg
};
I suspect that the problem occurs when the Target positions and joint angles are calculated or generated in RoboDK. Although the robot simulation follows the desired F U T configuration, some Targets are generated with joint angles corresponding to F D B. As a result, the FANUC LS file later outputs those Targets as F D B.
I found that I can correct the configuration by using the "Teach Current Position" function for each Target in RoboDK. After doing this, the Target stores the joint angles corresponding to the desired F U T configuration.
However, my program contains a very large number of Target points, so manually applying this operation to every Target is not practical.
Therefore, I would like to understand:

1. Why are some Targets generated with joint angles corresponding to F D B instead of F U T, even though the robot simulation moves through the path using the F U T configuration?
   
2. Could this be related to the way the Targets are calculated or generated using the RoboDK Python API?
   
3. Is there a way to automatically generate or update all Targets so that their stored joint angles correspond to the F U T configuration, without manually using "Teach Current Position" for each Target?
   

My current setup is:

• RoboDK version: 5.9.0
  
• Robot: FANUC LR Mate 200iD/7L
  
• Post processor: FANUC RJ3
  
• Program generation: RoboDK Python script
  
• Output: FANUC LS file
  

Thank you for your support.

  Problem.rdk (Size: 629.71 KB / Downloads: 36) ]]> I have a question regarding the FANUC LS program generated by RoboDK.
I am using RoboDK version 5.9.0 with a FANUC LR Mate 200iD/7L robot. I generate the robot program using a RoboDK Python script and the FANUC RJ3 post processor.
I would like to keep the robot configuration as F U T.
In the RoboDK simulation, the robot moves with the desired F U T configuration. However, I found that the joint angles stored in some Targets do not correspond to the F U T configuration. Instead, some Targets appear to have joint angles corresponding to the F D B configuration.
For example, the generated LS file contains:
P[32]{
GP1:
UF : 2, UT : 2, CONFIG : 'F U T, 0, 0, 0',
X = 792.980 mm, Y = 129.270 mm, Z = 160.000 mm,
W = 90.000 deg, P = 0.000 deg, R = -119.518 deg
};
P[33]{
GP1:
UF : 2, UT : 2, CONFIG : 'F D B, 0, 0, 0',
X = 826.627 mm, Y = 164.595 mm, Z = 160.000 mm,
W = 90.000 deg, P = 0.000 deg, R = -149.036 deg
};
I suspect that the problem occurs when the Target positions and joint angles are calculated or generated in RoboDK. Although the robot simulation follows the desired F U T configuration, some Targets are generated with joint angles corresponding to F D B. As a result, the FANUC LS file later outputs those Targets as F D B.
I found that I can correct the configuration by using the "Teach Current Position" function for each Target in RoboDK. After doing this, the Target stores the joint angles corresponding to the desired F U T configuration.
However, my program contains a very large number of Target points, so manually applying this operation to every Target is not practical.
Therefore, I would like to understand:

1. Why are some Targets generated with joint angles corresponding to F D B instead of F U T, even though the robot simulation moves through the path using the F U T configuration?
   
2. Could this be related to the way the Targets are calculated or generated using the RoboDK Python API?
   
3. Is there a way to automatically generate or update all Targets so that their stored joint angles correspond to the F U T configuration, without manually using "Teach Current Position" for each Target?
   

My current setup is:

• RoboDK version: 5.9.0
  
• Robot: FANUC LR Mate 200iD/7L
  
• Post processor: FANUC RJ3
  
• Program generation: RoboDK Python script
  
• Output: FANUC LS file
  

Thank you for your support.

  Problem.rdk (Size: 629.71 KB / Downloads: 36) ]]> https://robodk.com/forum/Thread-Import-the-cartesian-points-with-the-external-axes-values Wed, 16 Sep 2026 06:14:09 +0000 Kevin.Zhang]]> https://robodk.com/forum/Thread-Import-the-cartesian-points-with-the-external-axes-values I want to import these points into RoboDK while preserving the external axis value associated with each point. How should I do this by C# API?
Thanks very much!]]> I want to import these points into RoboDK while preserving the external axis value associated with each point. How should I do this by C# API?
Thanks very much!]]> https://robodk.com/forum/Thread-Can-t-align-curves-to-an-actual-part-held-by-robot Tue, 15 Sep 2026 18:18:30 +0000 jheimann]]> https://robodk.com/forum/Thread-Can-t-align-curves-to-an-actual-part-held-by-robot
What I need to do is align the spacer (with the curves) to spacer1 that is picked up in the jaws of the robot, and follow the path.  I can't seem to get the curves to align to the spacer picked up.  As I put the spacer down and regrip it again in a different location to debur the next spot(s) I again will need to realign the spacer with curves to the spacer1 object held in the jaws.

My RDK file is attached.  You can see that spacer contains the curves.  I used Spacer as my remote TCP and the debur position 1 as the reference the the tool will run against.  But the spacer curves I cannot get to align to the spacer1 that is held in the jaws no matter what I do.

I can't seem to figure this out.  Any help would be appreciated.

Thanks,


John Heimann

  DEBUR Fusion Import rev 6.rdk (Size: 1.75 MB / Downloads: 33) ]]>
What I need to do is align the spacer (with the curves) to spacer1 that is picked up in the jaws of the robot, and follow the path.  I can't seem to get the curves to align to the spacer picked up.  As I put the spacer down and regrip it again in a different location to debur the next spot(s) I again will need to realign the spacer with curves to the spacer1 object held in the jaws.

My RDK file is attached.  You can see that spacer contains the curves.  I used Spacer as my remote TCP and the debur position 1 as the reference the the tool will run against.  But the spacer curves I cannot get to align to the spacer1 that is held in the jaws no matter what I do.

I can't seem to figure this out.  Any help would be appreciated.

Thanks,


John Heimann

  DEBUR Fusion Import rev 6.rdk (Size: 1.75 MB / Downloads: 33) ]]> https://robodk.com/forum/Thread-Siemens-Sinumerik-driver-link-is-broken Thu, 10 Sep 2026 20:29:03 +0000 cotega]]> https://robodk.com/forum/Thread-Siemens-Sinumerik-driver-link-is-broken https://robodk.com/doc/en/Robots-Siemens.html

The link 'https://robodk.com/doc/drivers/Connect-Siemens-Sinumerik-robots-with-RoboDK.zip' seems broken.

Thanks]]> https://robodk.com/doc/en/Robots-Siemens.html

The link 'https://robodk.com/doc/drivers/Connect-Siemens-Sinumerik-robots-with-RoboDK.zip' seems broken.

Thanks]]> https://robodk.com/forum/Thread-Program-Patterns-Yaskawa-Post-Processor Thu, 10 Sep 2026 16:04:10 +0000 Arno.Klocke_Estia]]> https://robodk.com/forum/Thread-Program-Patterns-Yaskawa-Post-Processor I have a question regarding patterns in RoboDK. I am going to be as specific as possible in my request. 
I am able to have a simulation for what I want in RoboDK my problem is mainly in the the post process. 
I am using the Motoman.py post processor with output in pulses. 
I will attach the station below with the program. 
To be able to do the simulation I just simply created other coordinate system and in the program I am calling the same target but in another coordinate system moved by the pattern (here Y=+100) 
The robotic cell contains an external axis (2 axis positionner). 
The simulation runs fine but when trying to export the program in Pulses I run into 2 problems. 
The first one is easily fixable and I think is due to the presence of the external axis, but when I import Targets from a rhino grasshopper file (with Python API), targets are created and placed accordingly but all the joints value in the target are the same, an thus I have to manually double click on the target and press teach current position to have the target with the right joint values (only the 6 axis of the robot, the 2 axis positionner values are remembered) 

If I don't do this when I output the program all the pulses values are the same. 

This is ok and can easily be fixed with a python script. 

The second problem I face is when patterning wiht a coordinate system, when exporting the program I have the same Pulse values, I kinda understand that the post process reads all the targets and there joints values and then calculates the pulses accordingly but then when the trajectory in simulation is moved, the outputed program is basically 5 times the same movement. 
Is there an easy way of doing pattern without duplicating all the targets in space and creating the whole program with linked targets ?
Basically I want to be able to have the program ready and if some minor changes have to be made to the path I only have to modify 8 targets instead of all of them and the parametric is kept and then I can output the program. 

How I am currently doing is I am outputing only the first instance of the program and then I do the loop with INFORM language inside the outputted program from post processor "Motoman.py" to pattern and I can visualise that there is no problem with RoboDK simulation making the pattern.

The only Problem I have doing this is in case the tooling is not extermely precise, only the first instance can be changed with the teach and ideally I would like to have all the instances of the program and modify some of them manually with the teach if needed.

I will also use this post for a question regarding targets linked, I want to keep the parametric from Rhino grasshopper and update in real time changes that are made within grasshopper, It works and rewrites the targets, it's also great because it can bedone with meshes, very practical for tooling variations.

Unfortunately the targets are "delinked" so to say in the program while they have the same name. Is there a way to re link all the targets direclty for a program. 

Thank you so much for your time ! 
Arno Klocke

  Pattern_RoboDK.png (Size: 167.12 KB / Downloads: 50)

  Cellule_MILC_THN01.2050_SE PLATINE REAR WHEEL.rdk (Size: 6.2 MB / Downloads: 44) ]]> I have a question regarding patterns in RoboDK. I am going to be as specific as possible in my request. 
I am able to have a simulation for what I want in RoboDK my problem is mainly in the the post process. 
I am using the Motoman.py post processor with output in pulses. 
I will attach the station below with the program. 
To be able to do the simulation I just simply created other coordinate system and in the program I am calling the same target but in another coordinate system moved by the pattern (here Y=+100) 
The robotic cell contains an external axis (2 axis positionner). 
The simulation runs fine but when trying to export the program in Pulses I run into 2 problems. 
The first one is easily fixable and I think is due to the presence of the external axis, but when I import Targets from a rhino grasshopper file (with Python API), targets are created and placed accordingly but all the joints value in the target are the same, an thus I have to manually double click on the target and press teach current position to have the target with the right joint values (only the 6 axis of the robot, the 2 axis positionner values are remembered) 

If I don't do this when I output the program all the pulses values are the same. 

This is ok and can easily be fixed with a python script. 

The second problem I face is when patterning wiht a coordinate system, when exporting the program I have the same Pulse values, I kinda understand that the post process reads all the targets and there joints values and then calculates the pulses accordingly but then when the trajectory in simulation is moved, the outputed program is basically 5 times the same movement. 
Is there an easy way of doing pattern without duplicating all the targets in space and creating the whole program with linked targets ?
Basically I want to be able to have the program ready and if some minor changes have to be made to the path I only have to modify 8 targets instead of all of them and the parametric is kept and then I can output the program. 

How I am currently doing is I am outputing only the first instance of the program and then I do the loop with INFORM language inside the outputted program from post processor "Motoman.py" to pattern and I can visualise that there is no problem with RoboDK simulation making the pattern.

The only Problem I have doing this is in case the tooling is not extermely precise, only the first instance can be changed with the teach and ideally I would like to have all the instances of the program and modify some of them manually with the teach if needed.

I will also use this post for a question regarding targets linked, I want to keep the parametric from Rhino grasshopper and update in real time changes that are made within grasshopper, It works and rewrites the targets, it's also great because it can bedone with meshes, very practical for tooling variations.

Unfortunately the targets are "delinked" so to say in the program while they have the same name. Is there a way to re link all the targets direclty for a program. 

Thank you so much for your time ! 
Arno Klocke

  Pattern_RoboDK.png (Size: 167.12 KB / Downloads: 50)

  Cellule_MILC_THN01.2050_SE PLATINE REAR WHEEL.rdk (Size: 6.2 MB / Downloads: 44) ]]> https://robodk.com/forum/Thread-xArm-6-linear-moves-diverge-from-simulation-when-sent-to-robot Wed, 09 Sep 2026 17:35:16 +0000 JakeInTX]]> https://robodk.com/forum/Thread-xArm-6-linear-moves-diverge-from-simulation-when-sent-to-robot
I'm working with a UFACTORY xArm 6 through RoboDK.

Joint movements work perfectly in both modes, whether the robot is driven live by RoboDK or running a program sent to it independently. The problem only shows up with linear moves:

- Driven live by RoboDK: linear moves are correct, path and end effector orientation match simulation.
- Sent to the robot with "Send Program to Robot" and run independently: linear moves either miss the correct position, or reach it with the wrong orientation, and the path doesn't match what RoboDK shows.

I can't rely on joint moves alone for this project, so I need linear moves to behave the same sent as they do live.

What I've already checked:
- Base frame in RoboDK matches the xArm's reference frame (no unexpected offset).
- Tool frame (TCP) values in RoboDK match the TCP configuration in UFACTORY Studio exactly (same X, Y, Z, and Euler angles).
- Confirmed the Euler angle convention in RoboDK matches how the xArm defines roll, pitch, and yaw (fixed-angle XYZ).
- Tested a single-axis jog to isolate the issue; the discrepancy still shows up on sent linear moves even though live-connected linear moves are fine.

Since joint moves are consistent in both modes and only linear moves diverge, and only when sent rather than live, I suspect this is something in how the post-processor or program generation handles Cartesian/linear motion for the xArm 6 controller specifically. Has anyone else run into this, or know what changes between live-driven and sent-and-run execution for linear moves on the xArm?

Thanks,
Jake]]>
I'm working with a UFACTORY xArm 6 through RoboDK.

Joint movements work perfectly in both modes, whether the robot is driven live by RoboDK or running a program sent to it independently. The problem only shows up with linear moves:

- Driven live by RoboDK: linear moves are correct, path and end effector orientation match simulation.
- Sent to the robot with "Send Program to Robot" and run independently: linear moves either miss the correct position, or reach it with the wrong orientation, and the path doesn't match what RoboDK shows.

I can't rely on joint moves alone for this project, so I need linear moves to behave the same sent as they do live.

What I've already checked:
- Base frame in RoboDK matches the xArm's reference frame (no unexpected offset).
- Tool frame (TCP) values in RoboDK match the TCP configuration in UFACTORY Studio exactly (same X, Y, Z, and Euler angles).
- Confirmed the Euler angle convention in RoboDK matches how the xArm defines roll, pitch, and yaw (fixed-angle XYZ).
- Tested a single-axis jog to isolate the issue; the discrepancy still shows up on sent linear moves even though live-connected linear moves are fine.

Since joint moves are consistent in both modes and only linear moves diverge, and only when sent rather than live, I suspect this is something in how the post-processor or program generation handles Cartesian/linear motion for the xArm 6 controller specifically. Has anyone else run into this, or know what changes between live-driven and sent-and-run execution for linear moves on the xArm?

Thanks,
Jake]]>