Blocking or Non-Blocking nature of or Play_Motion_Index functions

Let’s say that in my TASK program or my MicroPython program, I invoke either image or, and the robot happens to be processing another motion page at that time. Then, would these functions be “blocked” there until Motion.Status becomes FALSE and then they would execute the “new/next” motion page? Or would they return to the main program right away (i.e. non-blocking functions) and essentially that “new/next” motion page would be “lost”?


Hi @roboteer,

Sadly, I have little understanding of your operating environment :frowning:

Do you mean “Processing at that same time” as follows?

  • While the controller are executing one Motion Unit (Motion Page has been renamed “Motion Unit” from R+Motion 2.0), and the controller try to call another Motion Unit at that time the first Motion Unit is running?

In my personal opinion, the second motion will not be executed until the Motion Status returns “False” because, as you know, the first Motion Unit are already being running in the controller at that time . If you would like to execute the second Motion Unit in first Motion Unit, you may want the first Motion Unit to escape the current Motion Unit by adding a Motion Index Number from either 0 to -3. See Motion Index Number

Please point out my thought If I understood your inquiry wrongly.

Hi @Tech_Support,
I am using Windows 10 with TASK and MicroPython code, and let me reword my question:

  1. Motion Unit A is being performed, and it is not finished yet, so Motion.Status == True.
  2. Then my TASK or MicroPython code issue another Play Motion command with Motion Unit B. Please note that I am not talking about, MU_B), just then, and without a wait.while(Motion.Status == True) in between these two commands.
  3. So I would think there are two possibilities:
    a) After Motion Unit A has finished playing, then Motion Unit B is performed next.
    b) After Motion Unit A has finished playing, the robot just stops, as if the command for Motion
    Unit B is lost/discarded.
1 Like

Hi @roboteer

Thank you for your clarification :slight_smile:

If you use wait.while(Motion.Status == True) technique, the Motion B will probably run after the Motion A is complete. But without the technique, I talked with an engineer, we haven’t tested the interfacing with R+Task 3.0 and MicroPython (and vice versa) so that we’re not sure that the given Motion B command is to be ignored or discarded during the Motion A, unfortunately. :cry:

Hi @Tech_Support,
It is OK. I thought that you guys would know already. I’ll test this situation myself then. And I’ll post my results.

1 Like

Hi @Tech_Support,

Ah! I got it figured out. When Motion A is not yet complete and Motion B is invoked (shall we say “early”), then Motion A is terminated where-ever it was, and Motion B just takes over! This is a nice feature to have with the ENGINEER system. As an example, Motion A can be a “regular” motion for the robot to do, but before Motion A can be completed, some kind of emergency happens then Motion B can be launched immediately to save the robot or the operator from harm.
Another interesting note, that only an “old” user like me would know and appreciate, is that the “older” BIOLOID and MINI systems could not do this “trick”. For these older systems, once Motion A is started, and an emergency situation happens, then the only thing that the programmer could do was to set all Moving Velocities to zero to force the robot to stop “dead in its track”, next waited for Motion A to finish (time wise), then reset all Moving Velocities back to “normal”, and then finally Motion B could be played.

1 Like