[petsven]

I am running my code in simulation mode. I want to move the robot arm without blocking so I can get the position of the TCP as the arm is moving. I am moving the robot arm using the moveJ command. To check if the MoveJ command is still blocking, I added print time commands . Here is my code:

Code:

for movement in movements:
print("Start: " +str(time.time()))
robot.MoveJ(movement, blocking=False)
print("Stop: " +str(time.time()))

I can tell the code is still blocking because there is a 1.3 second delay between the start and stop print statements. Why is the code still blocking? Does it always block in simulate mode? Do I need to use a library like "asyncio" to make it non-blocking?

[petsven]

I was able to get it working by using async.io:

Code:

async def non_blocking(loop, executor):
await asyncio.wait(
fs={
loop.run_in_executor(executor, getPosition),
loop.run_in_executor(执行人、钼veRobot),
},
return_when=asyncio.ALL_COMPLETED
)

[Maarten]

I run into the same issue:

I have two robots (R1 and R2) in a station and from the API I want to fire non-blocking move commands to either of them. In its simplest form:

Code:

R1.MoveJ(R1_T1,False) #1 Joint move first robot R1 to target R1_T1
R1.MoveJ(R1_T2,False) #2 Joint move first robot R1 to target R1_T2

R2.MoveJ(R2_T1,False) #3 Joint move second robot R2 to target R2_T1
R2.MoveJ(R2_T2,False) #4 Joint move second robot R2 to target R2_T2

Despite the option blocking=False, the two consecutive move commands #1 and #2 to R1 effectively introduce blocking behavior, since command #2 won't be executed until command # 1 is finished. Execution of command #3 and #4 to R2 are therefore also blocked until command #1 is finished.

The behavior I want is for R1 to consecutively execute its commands #1 and #2, without blocking R2 to start consecutively executing command #3 and #4, independent of each other's busy status.

Any suggestions how to implement async.io in this case, or any other ways?

Best regards,

Maarten

[Albert]

Each movement for the same robot is not executed unless the previous move is complete.

To do what you are planning to accomplish it would be better if you intercalate the movements for each robot:

Code:

R1.MoveJ (R1_T1、虚假)# 1的第一个机器人R1助教rget R1_T1
R2.MoveJ(R2_T1,False) #2 Move second robot R2 to target R2_T1

R1.MoveJ(R1_T2,False) #3 Move first robot R1 to target R1_T2
R2.MoveJ(R2_T2,False) #4 Move second robot R2 to target R2_T2

You can also stop the robot movement by triggering R1.Stop(). You may need to trigger this from a separate thread and you would have to wrap your Movement within a try/catch if you don't want your script to stop.

[Maarten]

Hi Albert, shuffling the commands does not solve the issue. In the order you propose:

• Command #3 to R1 will not execute until R1 has finished command #1, which is as expected.
  
• Command #4 to R2 will not execute until R2 has finished command #2, which is as expected.
  
• Command #4 to R2 will not execute until R1 has finished command #1,which is the remaining issue.
  

I'd like be able to provide commands to R1 and R2, and have them execute the commands consecutively regardless of the other robot's status.

Also, I would need a generic solution, which works for any number of commands and any time duration of a move command. While the order of consecutive commands to an individual robot is inherent when a new command is queued, the combined order of consecutive commands for both robots will be unknown in advance. But since both robots should operate independently, the combined order should be irrelevant: each robot simply executes its own list of consecutive commands independently.

[Albert]

I understand that the last movement command won't execute unless 1 and 2 are complete in the example we discussed. This is a good point. To solve this problem you should run each group of robot movements for the same robot on a separate thread. A separate script would also work (it ends up being a separate thread).

The example MoveRobot script of the "Synchronize 3 Robots with a Screen" example does exactly that (it moves each robot on a separate thread).

[Maarten]

Thanks for your help Albert, but I find the "Synchronize 3 Robots with a Screen" example quite complex to understand for the supposedly simple thing I'm trying to achieve.

I attached a stripped down station with two robots, three joint targets for each, and a python script from which I intend to make the robots perform a series of movements along their targets, both running at the same time (no synchronization is needed). I'm probably not using the threading correctly. Could you have a look at the script to make it work as intended?

[Maarten]

Hi Albert, can you spot the issue in the station I uploaded last week? The behavior when running the program is quite unexpected: sometimes the robots do start their move sequence as a thread, sometimes they don't.