Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5

Correct use of RoboDK with Windows and a UR5 robot

#1
Hi All.

I am attempting to use RoboDK to control a UR5 robot in online mode from a Windows 10 PC and continue to run into problems that do not appear when running in offline mode.

I have a main.py script that imports several modules, initalises the connection to RoboDK, sets the run mode etc. When I attempt to run main when online I get the following error:

Code:
C:\RoboDK\Python-Embedded>python C:\Users\Admin\Documents\robot_barista\src\robot_barista\main.py 3 -r online
Retain frames and targets?
============ meta-task: prep ============
------------   rounding off  ------------
[TASK 1000]: Reset simulation
Traceback (most recent call last):
  File "C:\Users\Admin\Documents\robot_barista\src\robot_barista\main.py", line 447, in <module>
    tks.run_tasks([
  File "C:\Users\Admin\Documents\robot_barista\src\robot_barista\tasks.py", line 190, in run_tasks
    getattr(Tasks, method)(self)
  File "C:\Users\Admin\Documents\robot_barista\src\robot_barista\tasks.py", line 290, in tks_1
    robot_program.RunCode()
  File "C:\RoboDK\Python-Embedded\lib\site-packages\robodk\robolink.py", line 6526, in RunCode
    self.link._check_status()
  File "C:\RoboDK\Python-Embedded\lib\site-packages\robodk\robolink.py", line 813, in _check_status
    raise Exception(self.LAST_STATUS_MESSAGE)
Exception: Robot is not ready

Note that across all of my modules there are several thousand lines of code, and it has been structured per best Python programming practice. This is somewhat different to the note in the Generate Program online documentation which states:

Quote:It is best practice for some robot controllers to integrate the generated program and required subprograms with same program file.

Further, I prefer not to add my Python modules to the station tree due to previous issues with RoboDK making temporary copies of files etc etc.

Can someone (Albert?) please provide guidance on how to resolve the current issue. As discussed in previous threads, if I run my code from a Linux PC (using the Linux version of RoboDK etc etc) then everything works exactly the same online as offline. Finally, note that when running code on the robot, the log is full of messages of the type:

Code:
socket_read_binary_integer: timeout
#2
The socket_read_binary_integer timeout warning you see in the log of the real UR robot is normal. It means it is waiting for commands from the computer to be executed by the real robot.

If you see the error message "The robot is not ready" it means the connection was not properly stablished between RoboDK and the real robot. I recommend you to use the function ConnectSafe instead of Connect. And check the connection using ConnectedState:
https://robodk.com/doc/en/PythonAPI/robo...ectedState

Can you share your project file and the connection log of RoboDK? We can take a better look.
#3
Hi Albert.

In order to connect to the UR5, I use the "Connect Robot" dialog within RoboDK - that is, my Python code does not establish a connection to the robot using Connect or ConnectSafe.

I have attached my RoboDK station file, the output of my Windows command line, the output of the RoboDK log window, as well as the UR5 support file. Several things worth nothing in my latest attempt to get things working:

1. I generated .URP files for every program contained in the "Tool_Programs" and "Visual_Programs" folders of my RDK file and transferred them to the UR5 robot via FTP.
2. I connected to the robot using the RoboDK dialog, then ran my main.py program from the Windows command line.
3. I then manually disconnected from the robot when it became clear that it had skipped the tool attach routine described below.

Looking at the UR5 log, it seems to have run the first .URP program specified in main.py (which is "Reset_Simulation_L"), but it then fails to run the next one that should be called ("Rancilio_Tool_Attach_L_(ATI)").

I am happy to provide you with all of my Python modules, but I am unwilling to attach them to this message as it would provide students who have to perform the task for which my code is an exemplar with an unfair advantage. Please DM or email me if you want these files.


Attached Files
.txt   robodk_log.txt (Size: 1.32 KB / Downloads: 34)
.txt   windows_cmd.txt (Size: 1.22 KB / Downloads: 29)
.zip   ur_2023350546_2025-08-12_13-12-59.zip (Size: 4.02 MB / Downloads: 45)
.rdk   Robot_3_2025.rdk (Size: 42.3 MB / Downloads: 41)
.py   main.py (Size: 15.36 KB / Downloads: 28)
#4
Updates

1. There was a naming inconsistency between the "Tool_Programs" in my RDK file and the names of the URP files that were generated and transferred to the robot (the generated URP file had brackets stripped from the filename). I corrected this in the RDK file and all methods that call the program, but "Rancilio_Tool_Attach_L_ATI" still fails to run when called. Note that the tool program in the station tree had it's "Run on Robot" flag set.

2. If I unset the "Run on Robot" flag, I can see from the RoboDK log that an attempt is made to call an external program named Rancilio_Tool_Attach_L_ATI, but the robot then crashes, with the following entries in the UR5 log:

Code:
3.5 :: 0008d07h32m58.656s :: 2025-08-12 16:50:59.064 :: -3 :: C0A0:7 :: null :: 1 :: DriverRoboDK :: Program DriverRoboDK stopped :: null
3.5 :: 0008d07h32m59.232s :: 2025-08-12 16:50:59.661 :: -2 :: C100A4:6 :: null :: 1 ::  ::  :: 0
3.5 :: 0008d07h42m45.128s :: 2025-08-12 16:51:01.667 :: -2 :: C0A0:12 :: null :: 1 :: URSafetyA 3.5.2: URSafetyB 3.5.4 ::  :: null
3.5 :: 0008d00h40m10.919s :: 2025-08-12 16:51:01.720 :: -5 :: C0A0:7 :: null :: 1 ::  :: Safety checksum changed to: CCCC :: null
3.5 :: 0008d07h42m45.272s :: 2025-08-12 16:51:01.776 :: -2 :: C100A3:6 :: null :: 1 ::  ::  :: 0
#5
Updates

1. The issue seems to be something to do with the .urp files that are generated by RoboDK using the "Universal Robot URP" post processor. If I transfer the Rancilio_Tool_Attach_L_ATI.urp file to the robot and attempt to load it from PolyScope, the robot states the program cannot be loaded. This would explain the crash in the previous update. However, if I select "Send program to robot", it works as expected.

Is it possible to access a previous version of RoboDK - preferably one from 2023 or so?
#6
Apologies for multiple posts, but I have attached the minimum reproducible code that demonstrates the error. With reference to the attached test.py, when connected to the real robot, the robot program "Rancilio_Tool_Attach_L_(ATI)" is never called. There are no errors in the RoboDK log, nor are errors thrown on the Windows command line, but the program is never called. If I double click on the program in the station tree however, it works exactly as expected.


Attached Files
.py   test.py (Size: 499 bytes / Downloads: 29)
.rdk   Test_Station.rdk (Size: 42.3 MB / Downloads: 36)
#7
I recommend you to use a custom version of the driver based on this example we used to control the RobotiQ gripper:
https://robodk.com/doc/en/Robots-Univers...er-RobotiQ

In short, you should use program indexes instead of program names to trigger programs on the robot controller. You should customize the script call to use indexes or program names to trigger your accepted programs. See this sample code in the RobotiQ sample script file, around line 1986:
Code:
          if True:
            rq_move_and_wait(prog_num)
          end
         
         
          # List possible program names
          #if str_find(prog_name, "rq_move_and_wait") >= 0:
          #  rq_move_and_wait(prog_num)
          #
          #elif str_find(prog_name, "rq_open") >= 0:
          #  rq_open()
          # 
          #elif str_find(prog_name, "rq_close") >= 0:
          #  rq_close()
          # 
          #end
#8
Thanks Albert.

I investigated your proposed solution, only to realise that the simplest way to fix the issue was to reproduce the programs in Python and not bother attempting to call the ones in the station tree at all. Not quite sure why it did not occur to me earlier, but it works and therefore I am happy. Thanks again for the suggestion though.
#9
Excellent then! Thank you for letting us know.
  




Users browsing this thread:
1 Guest(s)