<![CDATA[RoboDK Forum - RoboDK bugs]]> https://robodk.com/forum/ Wed, 21 Oct 2026 23:09:22 +0000 MyBB <![CDATA[Intermittent pose errors during online control]]> https://robodk.com/forum/Thread-Intermittent-pose-errors-during-online-control Mon, 19 Oct 2026 08:36:21 +0000 d_inokuma]]> https://robodk.com/forum/Thread-Intermittent-pose-errors-during-online-control
We use RoboDK's online driver to control a FANUC CRX-30iA. The issue occurs intermittently: the RoboDK model sometimes jumps to an implausible pose, and a move may stop with an error. The motion paths do not pass near singularities, and the physical robot can execute them without issue. The issue occurs sporadically during prolonged, repeated operation and cannot be reproduced on demand.

Environment
  • RoboDK: v5.9.2.25331 (Professional license); Windows 11 Pro 24H2
  • Physical robot: FANUC CRX-30iA
  • RoboDK model: FANUC CRX-25iA. We use it because the CRX-30iA model's axis movements did not match the physical robot. It is unclear whether this difference is related to the reported issue.
  • Network: isolated Ethernet via a hub/switch; no Internet connection
  • FANUC-side program: RDK_S3 [RoboDK Driver v4][27-May-2025]
  • RoboDK driver (PC): FanucSM.exe (version information is not shown in file properties; SHA-256: 02767CBDB86A8060D41CE07DA3D78BAAE9428D9EC1BE633EBBF78067D327D0D1)
  • Control path: RoboDK API (C#; NuGet package RoboDkApi v5.8.0)
  • Other clients or command sources: none

Symptoms
  • The issue occurs while sending MoveJ and MoveL commands through the RoboDK API.
  • Sometimes the physical robot appears to move normally, but the RoboDK model jumps to an implausible pose or joint configuration and RoboDK stops with an error. The error message varies by incident, but often indicates that the target is unreachable.
  • The displayed pose varies. The model may appear tightly folded, extend almost straight upward, or appear to intersect the floor or itself.
  • During an incident, the teach pendant shows no abnormality in the physical robot's position. Only the simulated arm in RoboDK appears abnormal.

Wireshark observations
  • During normal operation, the PC appears to send a request with an 88-byte TCP payload, followed by 22 robot-to-PC TCP segments carrying 4 bytes each, and then the next request.
  • The 3rd through 8th 4-byte TCP payloads from the robot appear to contain the current joint angles for J1-J6.
  • During an incident, the PC appears to send the next request before all 22 TCP segments believed to belong to the previous reply have been observed. The remaining segments from that reply are then followed by 22 TCP segments believed to be the next reply, after which the RoboDK pose appears incorrect.
  • Before some incidents, the interval between TCP segments appears longer than usual. This change may contribute to a timing issue, but we have not established a causal link.

Questions

  1. What corrective steps do you recommend to resolve this issue and make online control and pose feedback reliable? Are there known issues with RoboDK 5.9.2, the FANUC driver, the CRX-30iA, or its controller software? Which versions or settings do you recommend, and does any component need updating?
  2. Is the CRX-25iA model supported for online control of a physical CRX-30iA? Could this model difference affect the displayed pose or cause RoboDK to stop? Which model or settings do you recommend?
  3. Can the Wireshark capture help identify the cause, such as a request/response mismatch? If additional logs or diagnostic information are needed, what should I provide and how can I collect it?

Available evidence

I can provide a filtered Wireshark capture. Please let me know whether you would prefer it to be shared privately.


Thank you in advance.]]>
We use RoboDK's online driver to control a FANUC CRX-30iA. The issue occurs intermittently: the RoboDK model sometimes jumps to an implausible pose, and a move may stop with an error. The motion paths do not pass near singularities, and the physical robot can execute them without issue. The issue occurs sporadically during prolonged, repeated operation and cannot be reproduced on demand.

Environment
  • RoboDK: v5.9.2.25331 (Professional license); Windows 11 Pro 24H2
  • Physical robot: FANUC CRX-30iA
  • RoboDK model: FANUC CRX-25iA. We use it because the CRX-30iA model's axis movements did not match the physical robot. It is unclear whether this difference is related to the reported issue.
  • Network: isolated Ethernet via a hub/switch; no Internet connection
  • FANUC-side program: RDK_S3 [RoboDK Driver v4][27-May-2025]
  • RoboDK driver (PC): FanucSM.exe (version information is not shown in file properties; SHA-256: 02767CBDB86A8060D41CE07DA3D78BAAE9428D9EC1BE633EBBF78067D327D0D1)
  • Control path: RoboDK API (C#; NuGet package RoboDkApi v5.8.0)
  • Other clients or command sources: none

Symptoms
  • The issue occurs while sending MoveJ and MoveL commands through the RoboDK API.
  • Sometimes the physical robot appears to move normally, but the RoboDK model jumps to an implausible pose or joint configuration and RoboDK stops with an error. The error message varies by incident, but often indicates that the target is unreachable.
  • The displayed pose varies. The model may appear tightly folded, extend almost straight upward, or appear to intersect the floor or itself.
  • During an incident, the teach pendant shows no abnormality in the physical robot's position. Only the simulated arm in RoboDK appears abnormal.

Wireshark observations
  • During normal operation, the PC appears to send a request with an 88-byte TCP payload, followed by 22 robot-to-PC TCP segments carrying 4 bytes each, and then the next request.
  • The 3rd through 8th 4-byte TCP payloads from the robot appear to contain the current joint angles for J1-J6.
  • During an incident, the PC appears to send the next request before all 22 TCP segments believed to belong to the previous reply have been observed. The remaining segments from that reply are then followed by 22 TCP segments believed to be the next reply, after which the RoboDK pose appears incorrect.
  • Before some incidents, the interval between TCP segments appears longer than usual. This change may contribute to a timing issue, but we have not established a causal link.

Questions

  1. What corrective steps do you recommend to resolve this issue and make online control and pose feedback reliable? Are there known issues with RoboDK 5.9.2, the FANUC driver, the CRX-30iA, or its controller software? Which versions or settings do you recommend, and does any component need updating?
  2. Is the CRX-25iA model supported for online control of a physical CRX-30iA? Could this model difference affect the displayed pose or cause RoboDK to stop? Which model or settings do you recommend?
  3. Can the Wireshark capture help identify the cause, such as a request/response mismatch? If additional logs or diagnostic information are needed, what should I provide and how can I collect it?

Available evidence

I can provide a filtered Wireshark capture. Please let me know whether you would prefer it to be shared privately.


Thank you in advance.]]> <![CDATA[FANUC MoveC completes physically but RoboDK remains at Working]]> 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

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

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

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

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

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

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

.png   image(6).png (Size: 11.77 KB / Downloads: 45) ]]>
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

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

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

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

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

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

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

.png   image(6).png (Size: 11.77 KB / Downloads: 45) ]]> <![CDATA[Reference frame not applied correctly when robot is mounted on rail]]> 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

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

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

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

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

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

.png   Screenshot 2026-09-16 140206.png (Size: 14.65 KB / Downloads: 50) ]]>
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

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

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

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

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

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

.png   Screenshot 2026-09-16 140206.png (Size: 14.65 KB / Downloads: 50) ]]> <![CDATA[Siemens Sinumerik driver link is broken]]> 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]]> <![CDATA[KUKA Post Processor modification to include subprograms not working]]> https://robodk.com/forum/Thread-KUKA-Post-Processor-modification-to-include-subprograms-not-working Thu, 18 Jun 2026 15:42:30 +0000 Valentin BONNEAU]]> https://robodk.com/forum/Thread-KUKA-Post-Processor-modification-to-include-subprograms-not-working
Didn't managed to find a topic on this so sorry if this has already been discussed.

I am working on a kuka robot with KRC4 post processor.

I modified it as follows : 
Code:
  # Set to True to include subprograms in the main program. Otherwise, programs can be generated separately.
    INCLUDE_SUB_PROGRAMS = True    # Set to True to include subprograms in the same file

    # Generate subprograms as new files instead of adding them in the same file (INCLUDE_SUB_PROGRAMS must be set to True)
    SUB_PROGRAMS_AS_FILES = False

so that when i generate my main program all the instructions are included instead of having multiple calls (I need this for a specific project).

The issue is that the program thus generated has  DEF ... instructions for every program included, which gives errors. How can I solve this issue (without modifying manually the program)?

Thanks]]>
Didn't managed to find a topic on this so sorry if this has already been discussed.

I am working on a kuka robot with KRC4 post processor.

I modified it as follows : 
Code:
  # Set to True to include subprograms in the main program. Otherwise, programs can be generated separately.
    INCLUDE_SUB_PROGRAMS = True    # Set to True to include subprograms in the same file

    # Generate subprograms as new files instead of adding them in the same file (INCLUDE_SUB_PROGRAMS must be set to True)
    SUB_PROGRAMS_AS_FILES = False

so that when i generate my main program all the instructions are included instead of having multiple calls (I need this for a specific project).

The issue is that the program thus generated has  DEF ... instructions for every program included, which gives errors. How can I solve this issue (without modifying manually the program)?

Thanks]]> <![CDATA[OMRON TM12S MoveL issues]]> https://robodk.com/forum/Thread-OMRON-TM12S-MoveL-issues Thu, 04 Jun 2026 02:34:47 +0000 Jasim]]> https://robodk.com/forum/Thread-OMRON-TM12S-MoveL-issues <![CDATA[Display Panel add-in not rendering on macOS Desktop]]> https://robodk.com/forum/Thread-Display-Panel-add-in-not-rendering-on-macOS-Desktop Sun, 17 May 2026 18:50:39 +0000 aliabdelhamid]]> https://robodk.com/forum/Thread-Display-Panel-add-in-not-rendering-on-macOS-Desktop Hello RoboDK team,


I am having an issue with the Display Panel add-in on macOS.

The Display Panel add-in installs correctly and I can create a display panel from Utilities → Create display panel. The Display Panel settings window opens correctly, and the panel appears to be attached to the selected object.

However, the content is not rendered in the 3D view. I tested simple text such as “TEST”, HTML with a red background, large display sizes, different positions and rotations, and simple objects such as a box. Nothing is visible in the 3D scene.

I also tested the official RoboDK Display Panel example stations, but the display content does not appear there either.

Things I have already tried:
- Reinstalling the Display Panel add-in.
- Installing it in Current user storage.
- Updating RoboDK to the latest macOS version.
- Testing with simple text and HTML.
- Testing with different sizes, positions and rotations.
- Testing with simple objects.
- Testing with official Display Panel example stations.
- Restarting RoboDK completely.
- Resetting the tree/window layout settings.

System:
- OS: macOS Sequoia 15.7.4
- RoboDK version: 6.0.0
- Add-in: Display Panel
- Installation location: Current user storage

Could this be a known issue with the Display Panel add-in on macOS? Is there any workaround, dependency, or setting required for the panel to render correctly?

Thank you.

.png   Captura de pantalla 2026-05-17 a las 20.50.16.png (Size: 882.91 KB / Downloads: 219) ]]> Hello RoboDK team,


I am having an issue with the Display Panel add-in on macOS.

The Display Panel add-in installs correctly and I can create a display panel from Utilities → Create display panel. The Display Panel settings window opens correctly, and the panel appears to be attached to the selected object.

However, the content is not rendered in the 3D view. I tested simple text such as “TEST”, HTML with a red background, large display sizes, different positions and rotations, and simple objects such as a box. Nothing is visible in the 3D scene.

I also tested the official RoboDK Display Panel example stations, but the display content does not appear there either.

Things I have already tried:
- Reinstalling the Display Panel add-in.
- Installing it in Current user storage.
- Updating RoboDK to the latest macOS version.
- Testing with simple text and HTML.
- Testing with different sizes, positions and rotations.
- Testing with simple objects.
- Testing with official Display Panel example stations.
- Restarting RoboDK completely.
- Resetting the tree/window layout settings.

System:
- OS: macOS Sequoia 15.7.4
- RoboDK version: 6.0.0
- Add-in: Display Panel
- Installation location: Current user storage

Could this be a known issue with the Display Panel add-in on macOS? Is there any workaround, dependency, or setting required for the panel to render correctly?

Thank you.

.png   Captura de pantalla 2026-05-17 a las 20.50.16.png (Size: 882.91 KB / Downloads: 219) ]]> <![CDATA[Modifying a code instruction always changes the name]]> https://robodk.com/forum/Thread-Modifying-a-code-instruction-always-changes-the-name Wed, 29 Apr 2026 17:55:28 +0000 HenryInUtah]]> https://robodk.com/forum/Thread-Modifying-a-code-instruction-always-changes-the-name
Here is an image to help explain:


.png   RoboDK Always Renames Instruction.png (Size: 21.5 KB / Downloads: 271) ]]>
Here is an image to help explain:


.png   RoboDK Always Renames Instruction.png (Size: 21.5 KB / Downloads: 271) ]]> <![CDATA[Free license Error]]> https://robodk.com/forum/Thread-Free-license-Error Mon, 06 Apr 2026 00:12:26 +0000 NotaPizza]]> https://robodk.com/forum/Thread-Free-license-Error
.png   Screenshot 2026-04-06 010600.png (Size: 15.67 KB / Downloads: 208) ]]>
.png   Screenshot 2026-04-06 010600.png (Size: 15.67 KB / Downloads: 208) ]]> <![CDATA[Issue with Welding Approach/Retract Angles: Solid Edge vs. SolidWorks]]> https://robodk.com/forum/Thread-Issue-with-Welding-Approach-Retract-Angles-Solid-Edge-vs-SolidWorks Wed, 18 Mar 2026 03:57:09 +0000 rhbissani]]> https://robodk.com/forum/Thread-Issue-with-Welding-Approach-Retract-Angles-Solid-Edge-vs-SolidWorks I hope you are all doing well.
I am experiencing an issue with the approach and retract settings when generating welding paths using the Solid Edge plugin, and I was wondering if anyone has encountered something similar.

The Context:
I currently use SolidWorks with the RoboDK plugin to export models and curves for welding programming. With my current configurations in SolidWorks, the export works perfectly. By selecting the two reference faces and the edge, I get a consistent 45-degree approach and retract angle as expected.

The Problem:
When using Solid Edge, I cannot achieve the same result, even when mirroring the exact same settings used in SolidWorks. While the model and curves export successfully, the approach and retract behavior is incorrect:
The surface normals seem to point in only one direction.
In some cases, the normals flip or vary their position along the path.
I have attached screenshots of my current settings and the resulting behavior in RoboDK for reference.
Has anyone faced this inconsistency between the two plugins? Any advice on how to get the Solid Edge export to respect the 45-degree orientation correctly would be greatly appreciated.
Thank you in advance!

.zip   Robodk_Solidedge_issues_normals.zip (Size: 619.55 KB / Downloads: 160) ]]> I hope you are all doing well.
I am experiencing an issue with the approach and retract settings when generating welding paths using the Solid Edge plugin, and I was wondering if anyone has encountered something similar.

The Context:
I currently use SolidWorks with the RoboDK plugin to export models and curves for welding programming. With my current configurations in SolidWorks, the export works perfectly. By selecting the two reference faces and the edge, I get a consistent 45-degree approach and retract angle as expected.

The Problem:
When using Solid Edge, I cannot achieve the same result, even when mirroring the exact same settings used in SolidWorks. While the model and curves export successfully, the approach and retract behavior is incorrect:
The surface normals seem to point in only one direction.
In some cases, the normals flip or vary their position along the path.
I have attached screenshots of my current settings and the resulting behavior in RoboDK for reference.
Has anyone faced this inconsistency between the two plugins? Any advice on how to get the Solid Edge export to respect the 45-degree orientation correctly would be greatly appreciated.
Thank you in advance!

.zip   Robodk_Solidedge_issues_normals.zip (Size: 619.55 KB / Downloads: 160) ]]> <![CDATA[Installing RoboDK on Windows 7 does not work]]> https://robodk.com/forum/Thread-Installing-RoboDK-on-Windows-7-does-not-work Sun, 08 Mar 2026 08:34:38 +0000 merlinone74]]> https://robodk.com/forum/Thread-Installing-RoboDK-on-Windows-7-does-not-work
.jpg   falloiniciorobodk.jpg (Size: 37.93 KB / Downloads: 227) ]]>
.jpg   falloiniciorobodk.jpg (Size: 37.93 KB / Downloads: 227) ]]> <![CDATA[Import all.prm from robot XRC Yaskawa controller]]> https://robodk.com/forum/Thread-Import-all-prm-from-robot-XRC-Yaskawa-controller Thu, 26 Feb 2026 14:09:40 +0000 cobrasafes]]> https://robodk.com/forum/Thread-Import-all-prm-from-robot-XRC-Yaskawa-controller
.png   2026-02-26 15_07_41-RoboDK - Nueva Estación (1) - Free (Limited).png (Size: 17.59 KB / Downloads: 191) ]]>
.png   2026-02-26 15_07_41-RoboDK - Nueva Estación (1) - Free (Limited).png (Size: 17.59 KB / Downloads: 191) ]]> <![CDATA[Motoman motion problem with nx100 control box]]> https://robodk.com/forum/Thread-Motoman-motion-problem-with-nx100-control-box Sun, 08 Feb 2026 07:18:50 +0000 Béla]]> https://robodk.com/forum/Thread-Motoman-motion-problem-with-nx100-control-box
Hello, I have a problem with RoboDK between Motoman UP350N and nx100 control box. I think the post processor is not working properly. The simulation runs perfectly, but when I send the program to the robot, sometimes it does not follow the path. Can you help me before I buy this software?]]>
Hello, I have a problem with RoboDK between Motoman UP350N and nx100 control box. I think the post processor is not working properly. The simulation runs perfectly, but when I send the program to the robot, sometimes it does not follow the path. Can you help me before I buy this software?]]> <![CDATA[RoboDK crashes when it starts]]> https://robodk.com/forum/Thread-RoboDK-crashes-when-it-starts Mon, 26 Jan 2026 12:37:50 +0000 Chen]]> https://robodk.com/forum/Thread-RoboDK-crashes-when-it-starts I have an issue on RoboDK crashing all the time when it starts. 
I have tried to uninstall it and re install again, but it did not help. It says it loaded 2 plugins and it crashes. 
I am working win11, it works perfect ok until today suddenly it starts crashing. 

What can i do now? any suggestion for me, thanks for help. 

best
Chen
I have tried to open RoboDK-Safe-Start.bat and it can not open it. And i have tried RoboDK-Safe-Start-D3D.bat, it works for me. But my problem is when I use CAD pluginm it will open RoboDK with normal start, it crashed again. So I don't know how to fix it, pls help me with some suggestions, thanks a lot. 

best
Chen
Problem solved, GPU driver updated >D
Chen

.png   Screenshot 2026-01-26 133729.png (Size: 73.5 KB / Downloads: 258) ]]> I have an issue on RoboDK crashing all the time when it starts. 
I have tried to uninstall it and re install again, but it did not help. It says it loaded 2 plugins and it crashes. 
I am working win11, it works perfect ok until today suddenly it starts crashing. 

What can i do now? any suggestion for me, thanks for help. 

best
Chen
I have tried to open RoboDK-Safe-Start.bat and it can not open it. And i have tried RoboDK-Safe-Start-D3D.bat, it works for me. But my problem is when I use CAD pluginm it will open RoboDK with normal start, it crashed again. So I don't know how to fix it, pls help me with some suggestions, thanks a lot. 

best
Chen
Problem solved, GPU driver updated >D
Chen

.png   Screenshot 2026-01-26 133729.png (Size: 73.5 KB / Downloads: 258) ]]> <![CDATA[Windows 11 trial app crashes every time I open]]> https://robodk.com/forum/Thread-Windows-11-trial-app-crashes-every-time-I-open Thu, 15 Jan 2026 20:33:44 +0000 chris.kolar]]> https://robodk.com/forum/Thread-Windows-11-trial-app-crashes-every-time-I-open
Code:
14:13:49.582 (+0 ms): RoboDK v5.9.5 debug file RoboDK.debug.txt, started on 15-01-2026-14:13:49.582
14:13:49.582 (+0 ms): Debug: OS:  WIN64
14:13:49.582 (+0 ms): Debug: Date build:  Jan  3 2026
14:13:49.582 (+0 ms): Debug: Qt Version (compiled):  5.15.10
14:13:49.582 (+0 ms): Debug: Qt Version libs in use (runtime):  5.15.10
14:13:49.582 (+0 ms): Debug: Main process ID:  1468
14:13:49.582 (+0 ms): Debug: Thread ID:  0x235c
14:13:49.629 (+47 ms): Debug: Processing event...
14:13:49.629 (+0 ms): Debug: Starting RobotTools...
14:13:49.629 (+0 ms): Debug: Loading settings...
14:13:49.629 (+0 ms): Debug: Setting up default settings...
14:13:49.629 (+0 ms): Debug: Default settings set
14:13:49.629 (+0 ms): Debug: Reading saved settings...
14:13:49.641 (+12 ms): Debug: Failed to get parameter from ini file
14:13:49.641 (+0 ms): Debug: Failed to get parameter from ini file
14:13:49.641 (+0 ms): Debug: Settings loaded
14:13:49.647 (+6 ms): Warning: link #SVGID_83_ is undefined!
14:13:49.647 (+0 ms): Warning: link #SVGID_83_ is undefined!
14:13:49.647 (+0 ms): Warning: link #SVGID_83_ is undefined!
14:13:49.647 (+0 ms): Warning: link #SVGID_50_ is undefined!
14:13:49.647 (+0 ms): Warning: link #SVGID_83_ is undefined!
14:13:49.647 (+0 ms): Warning: link #SVGID_50_ is undefined!
14:13:49.647 (+0 ms): Warning: link #SVGID_83_ is undefined!
14:13:49.647 (+0 ms): Warning: link #SVGID_50_ is undefined!
14:13:49.661 (+14 ms): Debug: Lang file not found:  "C:/RoboDK/Lang/qt_en.qm"
14:13:49.661 (+0 ms): Debug: Statusbar:  "Language set to English"
14:13:49.661 (+0 ms): Debug: Updating recent files menu...
14:13:49.677 (+16 ms): Debug: Created language menu
14:13:49.695 (+18 ms): Debug: Setting slider style...
14:13:49.695 (+0 ms): Debug: Done
14:13:49.705 (+10 ms): Debug: Image_Mix Warning 2nd image is larger  ":/img/python.svg"  ":/img/tagadd.png"
14:13:49.710 (+5 ms): Debug: Trying to set up SpaceMouse...
14:13:49.710 (+0 ms): Debug: SpaceMouse setup done
14:13:49.725 (+15 ms): Debug: Setting up graphics...
14:13:49.725 (+0 ms): Debug: Setting up main window...
14:13:49.741 (+16 ms): Debug: Starting main window...
14:13:49.761 (+20 ms): Debug: LC start...
14:13:49.761 (+0 ms): Debug: LC message:  LC device not found
14:13:49.761 (+0 ms): Debug: Dongle not found or cannot read
14:13:49.761 (+0 ms): Debug: LC start...
14:13:49.761 (+0 ms): Debug: LC message:  LC device not found
14:13:49.761 (+0 ms): Debug: Dongle not found or cannot read
14:13:49.769 (+8 ms): Debug: Loading plugin:  "CollisionFreePlanner"
14:13:49.769 (+0 ms): Debug: "AddinManager.dll"
14:13:49.771 (+2 ms): Debug: "AppLoader.dll"
14:13:49.772 (+1 ms): Debug: "CollisionFreePlanner.dll"
14:13:49.773 (+1 ms): Debug: Loading plugin file:  "CollisionFreePlanner.dll"
14:13:49.773 (+0 ms): Debug: Loading plugin  "CollisionFreePlanner"
14:13:49.773 (+0 ms): Debug: Using settings:  ""
14:13:49.773 (+0 ms): Debug: Setting up the status bar
14:13:49.777 (+4 ms): Debug: Inserting menu at the end of the utilities menu
14:13:49.777 (+0 ms): Debug: Setting up the menu bar
14:13:49.778 (+1 ms): Debug: "OPC-UA.dll"
14:13:49.779 (+1 ms): Debug: "PluginAttachObject.dll"
14:13:49.779 (+0 ms): Debug: "PluginAttachView.dll"
14:13:49.780 (+1 ms): Debug: "PluginDisplayPanel.dll"
14:13:49.781 (+1 ms): Debug: "PluginIOMonitor.dll"
14:13:49.781 (+0 ms): Debug: "PluginLockTCP.dll"
14:13:49.782 (+1 ms): Debug: "PostProcessorEditor.dll"
14:13:49.783 (+1 ms): Debug: "RobotPilot.dll"
14:13:49.783 (+0 ms): Debug: List of LOADED plugins:
14:13:49.783 (+0 ms): Debug:      "CollisionFreePlanner"
14:13:49.783 (+0 ms): Debug: Done list of plugins
14:13:49.783 (+0 ms): Debug: Loading plugin:  "AddinManager"
14:13:49.783 (+0 ms): Debug: "AddinManager.dll"
14:13:49.784 (+1 ms): Debug: Loading plugin file:  "AddinManager.dll"
14:13:49.810 (+26 ms): Warning: link #SVGID_83_ is undefined!
14:13:49.810 (+0 ms): Warning: link #SVGID_50_ is undefined!
14:13:50.015 (+205 ms): Debug: "AppLoader.dll"
14:13:50.015 (+0 ms): Debug: "CollisionFreePlanner.dll"
14:13:50.015 (+0 ms): Debug: "OPC-UA.dll"
14:13:50.015 (+0 ms): Debug: "PluginAttachObject.dll"
14:13:50.015 (+0 ms): Debug: "PluginAttachView.dll"
14:13:50.015 (+0 ms): Debug: "PluginDisplayPanel.dll"
14:13:50.016 (+1 ms): Debug: "PluginIOMonitor.dll"
14:13:50.016 (+0 ms): Debug: "PluginLockTCP.dll"
14:13:50.016 (+0 ms): Debug: "PostProcessorEditor.dll"
14:13:50.016 (+0 ms): Debug: "RobotPilot.dll"
14:13:50.016 (+0 ms): Debug: List of LOADED plugins:
14:13:50.016 (+0 ms): Debug:      "CollisionFreePlanner"
14:13:50.016 (+0 ms): Debug:      "Addin Manager"
14:13:50.016 (+0 ms): Debug: Done list of plugins
14:13:50.016 (+0 ms): Debug: Statusbar:  "Loaded 2 plugins"
14:13:50.016 (+0 ms): Debug: Reading preferred layout settings...
14:13:50.016 (+0 ms): Debug: Done
14:13:50.016 (+0 ms): Debug: Closing splash window
14:13:50.017 (+1 ms): Debug: Updating window title...
14:13:50.017 (+0 ms): Debug: Entering main loop
14:13:50.042 (+25 ms): Warning: Vertex shader for simpleShaderProg (MainVertexShader & PositionOnlyVertexShader) failed to compile
14:13:50.042 (+0 ms): Warning: Fragment shader for simpleShaderProg (MainFragmentShader & ShockingPinkSrcFragmentShader) failed to compile
14:13:50.044 (+2 ms): Warning: QGLShaderProgram: shader programs are not supported
14:13:50.044 (+0 ms): Critical: Errors linking simple shader:
14:13:50.044 (+0 ms): Warning: Vertex shader for blitShaderProg (MainWithTexCoordsVertexShader & UntransformedPositionVertexShader) failed to compile
14:13:50.044 (+0 ms): Warning: Fragment shader for blitShaderProg (MainFragmentShader & ImageSrcFragmentShader) failed to compile
14:13:50.044 (+0 ms): Warning: QGLShaderProgram: shader programs are not supported
14:13:50.044 (+0 ms): Critical: Errors linking blit shader:
-> Solution: Please install your graphics card drivers. If you are running on a Virtual Machine (VM) or your PC can't process graphics card, please start RoboDK by running this file:
    C:/RoboDK/RoboDK-Safe-Start-VM.bat
    More information here: https://robodk.com/doc/en/Basic-Guide.html#TroubleShootIssues
]]>
Code:
14:13:49.582 (+0 ms): RoboDK v5.9.5 debug file RoboDK.debug.txt, started on 15-01-2026-14:13:49.582
14:13:49.582 (+0 ms): Debug: OS:  WIN64
14:13:49.582 (+0 ms): Debug: Date build:  Jan  3 2026
14:13:49.582 (+0 ms): Debug: Qt Version (compiled):  5.15.10
14:13:49.582 (+0 ms): Debug: Qt Version libs in use (runtime):  5.15.10
14:13:49.582 (+0 ms): Debug: Main process ID:  1468
14:13:49.582 (+0 ms): Debug: Thread ID:  0x235c
14:13:49.629 (+47 ms): Debug: Processing event...
14:13:49.629 (+0 ms): Debug: Starting RobotTools...
14:13:49.629 (+0 ms): Debug: Loading settings...
14:13:49.629 (+0 ms): Debug: Setting up default settings...
14:13:49.629 (+0 ms): Debug: Default settings set
14:13:49.629 (+0 ms): Debug: Reading saved settings...
14:13:49.641 (+12 ms): Debug: Failed to get parameter from ini file
14:13:49.641 (+0 ms): Debug: Failed to get parameter from ini file
14:13:49.641 (+0 ms): Debug: Settings loaded
14:13:49.647 (+6 ms): Warning: link #SVGID_83_ is undefined!
14:13:49.647 (+0 ms): Warning: link #SVGID_83_ is undefined!
14:13:49.647 (+0 ms): Warning: link #SVGID_83_ is undefined!
14:13:49.647 (+0 ms): Warning: link #SVGID_50_ is undefined!
14:13:49.647 (+0 ms): Warning: link #SVGID_83_ is undefined!
14:13:49.647 (+0 ms): Warning: link #SVGID_50_ is undefined!
14:13:49.647 (+0 ms): Warning: link #SVGID_83_ is undefined!
14:13:49.647 (+0 ms): Warning: link #SVGID_50_ is undefined!
14:13:49.661 (+14 ms): Debug: Lang file not found:  "C:/RoboDK/Lang/qt_en.qm"
14:13:49.661 (+0 ms): Debug: Statusbar:  "Language set to English"
14:13:49.661 (+0 ms): Debug: Updating recent files menu...
14:13:49.677 (+16 ms): Debug: Created language menu
14:13:49.695 (+18 ms): Debug: Setting slider style...
14:13:49.695 (+0 ms): Debug: Done
14:13:49.705 (+10 ms): Debug: Image_Mix Warning 2nd image is larger  ":/img/python.svg"  ":/img/tagadd.png"
14:13:49.710 (+5 ms): Debug: Trying to set up SpaceMouse...
14:13:49.710 (+0 ms): Debug: SpaceMouse setup done
14:13:49.725 (+15 ms): Debug: Setting up graphics...
14:13:49.725 (+0 ms): Debug: Setting up main window...
14:13:49.741 (+16 ms): Debug: Starting main window...
14:13:49.761 (+20 ms): Debug: LC start...
14:13:49.761 (+0 ms): Debug: LC message:  LC device not found
14:13:49.761 (+0 ms): Debug: Dongle not found or cannot read
14:13:49.761 (+0 ms): Debug: LC start...
14:13:49.761 (+0 ms): Debug: LC message:  LC device not found
14:13:49.761 (+0 ms): Debug: Dongle not found or cannot read
14:13:49.769 (+8 ms): Debug: Loading plugin:  "CollisionFreePlanner"
14:13:49.769 (+0 ms): Debug: "AddinManager.dll"
14:13:49.771 (+2 ms): Debug: "AppLoader.dll"
14:13:49.772 (+1 ms): Debug: "CollisionFreePlanner.dll"
14:13:49.773 (+1 ms): Debug: Loading plugin file:  "CollisionFreePlanner.dll"
14:13:49.773 (+0 ms): Debug: Loading plugin  "CollisionFreePlanner"
14:13:49.773 (+0 ms): Debug: Using settings:  ""
14:13:49.773 (+0 ms): Debug: Setting up the status bar
14:13:49.777 (+4 ms): Debug: Inserting menu at the end of the utilities menu
14:13:49.777 (+0 ms): Debug: Setting up the menu bar
14:13:49.778 (+1 ms): Debug: "OPC-UA.dll"
14:13:49.779 (+1 ms): Debug: "PluginAttachObject.dll"
14:13:49.779 (+0 ms): Debug: "PluginAttachView.dll"
14:13:49.780 (+1 ms): Debug: "PluginDisplayPanel.dll"
14:13:49.781 (+1 ms): Debug: "PluginIOMonitor.dll"
14:13:49.781 (+0 ms): Debug: "PluginLockTCP.dll"
14:13:49.782 (+1 ms): Debug: "PostProcessorEditor.dll"
14:13:49.783 (+1 ms): Debug: "RobotPilot.dll"
14:13:49.783 (+0 ms): Debug: List of LOADED plugins:
14:13:49.783 (+0 ms): Debug:      "CollisionFreePlanner"
14:13:49.783 (+0 ms): Debug: Done list of plugins
14:13:49.783 (+0 ms): Debug: Loading plugin:  "AddinManager"
14:13:49.783 (+0 ms): Debug: "AddinManager.dll"
14:13:49.784 (+1 ms): Debug: Loading plugin file:  "AddinManager.dll"
14:13:49.810 (+26 ms): Warning: link #SVGID_83_ is undefined!
14:13:49.810 (+0 ms): Warning: link #SVGID_50_ is undefined!
14:13:50.015 (+205 ms): Debug: "AppLoader.dll"
14:13:50.015 (+0 ms): Debug: "CollisionFreePlanner.dll"
14:13:50.015 (+0 ms): Debug: "OPC-UA.dll"
14:13:50.015 (+0 ms): Debug: "PluginAttachObject.dll"
14:13:50.015 (+0 ms): Debug: "PluginAttachView.dll"
14:13:50.015 (+0 ms): Debug: "PluginDisplayPanel.dll"
14:13:50.016 (+1 ms): Debug: "PluginIOMonitor.dll"
14:13:50.016 (+0 ms): Debug: "PluginLockTCP.dll"
14:13:50.016 (+0 ms): Debug: "PostProcessorEditor.dll"
14:13:50.016 (+0 ms): Debug: "RobotPilot.dll"
14:13:50.016 (+0 ms): Debug: List of LOADED plugins:
14:13:50.016 (+0 ms): Debug:      "CollisionFreePlanner"
14:13:50.016 (+0 ms): Debug:      "Addin Manager"
14:13:50.016 (+0 ms): Debug: Done list of plugins
14:13:50.016 (+0 ms): Debug: Statusbar:  "Loaded 2 plugins"
14:13:50.016 (+0 ms): Debug: Reading preferred layout settings...
14:13:50.016 (+0 ms): Debug: Done
14:13:50.016 (+0 ms): Debug: Closing splash window
14:13:50.017 (+1 ms): Debug: Updating window title...
14:13:50.017 (+0 ms): Debug: Entering main loop
14:13:50.042 (+25 ms): Warning: Vertex shader for simpleShaderProg (MainVertexShader & PositionOnlyVertexShader) failed to compile
14:13:50.042 (+0 ms): Warning: Fragment shader for simpleShaderProg (MainFragmentShader & ShockingPinkSrcFragmentShader) failed to compile
14:13:50.044 (+2 ms): Warning: QGLShaderProgram: shader programs are not supported
14:13:50.044 (+0 ms): Critical: Errors linking simple shader:
14:13:50.044 (+0 ms): Warning: Vertex shader for blitShaderProg (MainWithTexCoordsVertexShader & UntransformedPositionVertexShader) failed to compile
14:13:50.044 (+0 ms): Warning: Fragment shader for blitShaderProg (MainFragmentShader & ImageSrcFragmentShader) failed to compile
14:13:50.044 (+0 ms): Warning: QGLShaderProgram: shader programs are not supported
14:13:50.044 (+0 ms): Critical: Errors linking blit shader:
-> Solution: Please install your graphics card drivers. If you are running on a Virtual Machine (VM) or your PC can't process graphics card, please start RoboDK by running this file:
    C:/RoboDK/RoboDK-Safe-Start-VM.bat
    More information here: https://robodk.com/doc/en/Basic-Guide.html#TroubleShootIssues
]]>