Inconsistent behavior between URSim and real robot on RTDE interface

Technical Questions
1

Hi,

I have a remote control setup with a desktop application setting up RTDE communication to exchange joint targets over input_double_register_0…5 and a local control loop on the UR is sent via the realtime client using these targets in a servoj command. The registers are primed with the actual robot joint positions to initialize the bot in its current pose.

It’s been working flawlessly for a year on a CB3.1 running 3.11 (also on 3.14 but we had to downgrade for unrelated reasons).

Recently we started upgrading our software to support an e-Serie UR10, in URSim 5.10 the same code works perfectly fine, the robot tracks the intended joint targets without issue. When we move to the real robot though, as soon as we send the control loop, the robot will violently zoom all axises to 0, as if the registers did not get set to the initial nor updated values.

I dug further and it seems like the input_double_register_0-23 are reserved, I believe we developed our initial app on 3.8, and it mentions the 24-47 addresses as only there since 3.9.

My questions:

  • I believe that our app now should use the upper range of addresses for the data exchange, so 24-29 should do?
  • importantly: why is it working on the CB3.1 but not e-series?
  • more importantly: why is the URSim for 5.10 working perfectly but the real 5.10 robot has a different behavior? This is very worrying for us if we can not rely on a consistent behavior between simulated and real robot…
2

Check if Ethernet IP, or Profinet is not enabled on the robot.
There is no difference except for control loop frequency when using general purpose registers on CB3, and eSeries.

1 Like
3

Alright, thanks. I’ll dig further, the robot is at a client’s site and I have no history of its configuration and limited access to it. I will see what could cause the behavior.

Could you briefly develop on the reason Ethernet/IP or Profinet would interfere with the RTDE registers? Its important that we find the root cause of this behavior.

4

I could reproduce the issue in URSim on a UR10/5.10 when Profinet or EthernetIP was enabled. I will test again to see which one is causing the issue, or if it’s when both are enabled but seems to be the issue. We’ll verify that the customer disable these options and test again.

Thanks a lot!
Thibault

1 Like