[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.

[d_inokuma]

Thank you for your reply.


Packet Capture

I have attached the Wireshark packet capture collected when the issue occurred.

The relevant packet sequence is as follows:

- Frame No. 282127:
  An 88-byte request was sent.

- Frame Nos. 282128–282236:
  The robot returned 44 TCP segments, each carrying a 4-byte payload, for a total of 176 bytes. This appears to be twice the usual response size.

- Frame No. 282238:
  An 88-byte request was sent.

- Frame Nos. 282239–282291:
  The robot returned 22 TCP segments, each carrying a 4-byte payload, for a total of 88 bytes. This appears to be a complete response.

- Frame No. 282293:
  The next 88-byte request was sent.

- Frame Nos. 282294–282329:
  The robot returned only 10 TCP segments, each carrying a 4-byte payload, for a total of 40 bytes. At this point, 48 bytes of the expected 88-byte response had not yet been received.

- Frame No. 282331:
  RoboDK sent the next 88-byte request before the remaining 48 bytes of the previous response had been received.

- Frame Nos. 282332–282403:
  The robot then returned a total of 136 bytes of TCP payload. This may include the remaining 48 bytes of the previous response followed by the 88-byte response to the next request.

Around this point, the robot model in RoboDK also began behaving abnormally.


RoboDK Logs

I was unable to capture the RoboDK log when the issue occurred. Since the issue is intermittent, I plan to run the system for an extended period again and collect the log if the issue recurs.

Could you please advise me on how to collect the RoboDK logs needed for this investigation? Please also let me know if any debug or logging options should be enabled before reproducing the issue.

If there are any other logs or diagnostic information that I should collect, please let me know.


Best regards,

[Raphael]

Are you able to share your RDK station with us so that we can try and reproduce the issue on our side?

[d_inokuma]

I have prepared a RoboDK project file based on the project where the issue occurred, with all 3D models other than the robot model removed, and I am sharing it here.

• The robot is controlled via the RoboDK API when the issue occurs.
  
• MoveL and MoveJ commands are executed sequentially using blocking calls.
  
• So far, I have not been able to reproduce the issue when operating the robot directly from the RoboDK GUI.
  
• In the project, I use the CRX-25iA robot model renamed to CRX-30iA. The physical robot is a CRX-30iA.
  

I hope this information and the attached project file help with the investigation.

[Raphael]

Thanks for sharing your station. I will try to reproduce your issue soon so that we can fix it. However, because it is intermittent, it might take a while for us to debug. I will let you know as soon as I find something.