[d_inokuma]

Hello,

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.

[Raphael]

That is a very odd problem. Sharing the wireshark capture and the RoboDK log if you have it would help a lot with solving this issue. The part that I find especially weird is that the driver says a pose is unreachable while I can't find any printout from the driver that would say that.