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

MoveJ commands with blocking set to False still block when queueing moves

#1
I'm trying to simulate a KUKA KR 10 R1100-2 in RoboDK but I'm running into an issue where the MoveJ command blocks all threads trying to access RoboDK, even though blocking is set to false. The simple code shown below demonstrates the issue:

Code:
from robodk.robolink import *
import time

link = Robolink()
link.AddFile("FILEPATH")
robot = link.Item('', ITEM_TYPE_ROBOT)
target = link.AddTarget("Target1", robot.Parent())

for i in range(10):
    start = time.time()
    target.setPose(target.Pose().Offset(10, 0, 0, 0, 0, 0))
    robot.MoveJ(target = target, blocking = False)
    end = time.time()
    print("Tick" + str(i) + ": "  + str(end-start) + "s")
   

link.CloseRoboDK()

It produces the following output which shows that the first move is queued instantly but when the second move is queued RoboDK blocks until the first queued move finishes. This means that until then I cannot read any data from RoboDK during movement and only 2 moves are queueable at once. 

RoboDK is Running...
Tick0: 0.01750922203063965s
Tick1: 0.4813239574432373s
Tick2: 0.46680164337158203s
Tick3: 0.4840884208679199s
Tick4: 0.47762632369995117s
Tick5: 0.4962923526763916s
Tick6: 0.5008013248443604s
Tick7: 0.5033588409423828s
Tick8: 0.5121309757232666s
Tick9: 0.5225851535797119s
RoboDK will close now.

The issue is that I need to queue multiple moves and then constantly read the robot pose as it performs them. I have tried to read the pose from another thread as shown in the code below but it is blocked from accessing RoboDK until only 1 move is queued so I only get the pose whenever the robot finishes a move, right before the next is queued and while the last move is performed.

Code:
class Monitor(threading.Thread):
    def __init__(self):
        super().__init__()
        self.stopflag = threading.Event()
   
    def set_args(self, robot):
        self.robot = robot
   
    def run(self):
        while not self.stopflag.is_set():
            print(robomath.Pose_2_KUKA(robot.Pose()))

# Called before for loop:
monitor = Monitor()
monitor.set_args(robot=robot)
monitor.start()

How can I go about queuing up 2 moves and simultaneously reading the pose of the robot, and how do I queue more than 2 moves? I have also tried sending the MoveJ command from a separate thread, resulting in the same issue.

The robot item in the RDK file uses the KRC2 post processor.
#2
The first joint movement is not blocked, but the second joint movement will be blocked until the first one is finished. Basically, the movements are not buffered in this scenario.

One alternative option is to create a program instead, and run the program when you have created it in RoboDK. This can be easily done by swapping the robot item by a program item.
#3
(06-27-2025, 09:25 AM)Albert Wrote: The first joint movement is not blocked, but the second joint movement will be blocked until the first one is finished. Basically, the movements are not buffered in this scenario.

One alternative option is to create a program instead, and run the program when you have created it in RoboDK. This can be easily done by swapping the robot item by a program item.

Thanks for the reply. I'm trying to control the simulation in real time and the simulated KUKA uses rounding to interpolate between queued moves, so I don't think using a program will work unless there is some way to add moves to it while it is running. Is there any other way to buffer moves?
#4
If you are using the KUKA driver and you are connected to the controller the buffering will happen properly if you enabled it (use setRounding and pass a value greater than zero). The robot controller will take all the movements it can (5 maximum I believe, which you can configure with the ADVANCE variable) and they will be buffered on the robot controller and also in the RoboDK API.
#5
(06-27-2025, 09:38 AM)Albert Wrote: If you are using the KUKA driver and you are connected to the controller the buffering will happen properly if you enabled it (use setRounding and pass a value greater than zero). The robot controller will take all the movements it can (5 maximum I believe, which you can configure with the ADVANCE variable) and they will be buffered on the robot controller and also in the RoboDK API.

I'm not sure If I'm understanding correctly, but I'm assuming that being connected to the robot controller means being connected to the actual robot? What I'm trying to achieve is a simulation that allows real time control of the simulated robot in real time, with it behaving just like the real robot would (if it were sent the same commands), for purposes such as training without access to the real robot.
#6
In this case, you should split all movements as small movements and feed what the robot can process within the next few milliseconds so you can update the targets along your path.
#7
(06-27-2025, 09:45 AM)Albert Wrote: In this case, you should split all movements as small movements and feed what the robot can process within the next few milliseconds so you can update the targets along your path.

That would make sense, but how do I ensure that the simulation follows the correct acceleration and position profile that the real robot would based on the rounding and speeds set? Since if I am understanding correctly this will only be applied to buffered moves.
  




Users browsing this thread:
1 Guest(s)