DoF - a Robotiq Community
Warning sign
The Dof Community was shut down in June 2023. This is a read-only archive.
If you have questions about Robotiq products please reach our support team.

@Sebastien in script you would have used a while this which is just the script that was generated from a simple program moving from waypoint 1 to waypoint 2 while monitoring digital output 0

while (True):
    $ 1 "Robot Program"
    $ 2 "MoveJ"
    $ 3 "Waypoint_1"
    movej([-1.6007002035724085, -1.7271001974688929, -2.2029998938189905, -0.8079999128924769, 1.5951000452041626, -0.03099996248354131], a=1.3962634015954636, v=1.0471975511965976)
    $ 4 "If digital_out[0]≟ False "
    global thread_flag_4=0
    thread Thread_if_4():
      $ 5 "Waypoint_2"
      movej([-1.5918919155982847, -2.077602322080553, -1.690556245487243, -0.9697263956928577, 1.5953255450589165, -0.02219193606001557], a=1.3962634015954636, v=1.0471975511965976)
      thread_flag_4 = 1
    if (get_standard_digital_out(0) ==   False  ):
      global thread_handler_4=run Thread_if_4()
      while (thread_flag_4 == 0):
        if not(get_standard_digital_out(0) ==   False  ):
          kill thread_handler_4
          thread_flag_4 = 2
      thread_flag_4 = 2
    $ 6 "stopj(15)"
    $ 7 "sync()"
I have never tried implementing this in script but it makes sense, basically if you get into the if statement you would kick off a thread that would execute the move.  Then a while loop would be monitoring the status of the thread handler, as long as the thread was still executing then the if statement would interrupt the thread if the conditional was voided.

Takes a moment to kind of figure out whats going on but makes sense.  Also, notice that the stopj is not inside of a thread, it just follows the of statement just like it would in a polyscope program.


Sorry for the bump over here, but we've got the same trouble and we have programmed it with Polyscope in this way:

We do not yet have a sensor so we cannot check if the programming is good enough... with False, the whole program works smoothly but we are not sure what will happen when the value is True.

This is kind of a nonintuitive thing, but when you're using an If/Else and the If is checked continuously, you can enter the 'If DO[0]=True' portion of the program, start running the commands within it, and then jump into the Else portion if DO[0] ever goes false while headed to point_6.

Normally this isn't something that happens.  If you have an If/Else that is NOT checked continuously, you have two hunks of code (one under If, one under Else) and only one of those hunks will ever run.

If you wanted to ensure that you jump completely out of the If/Else statement, you could replace the Else with an Elseif.  Maybe it would look like this:
Started_If is just an arbitrary variable functioning as a flag that lets us know if we entered the first part of the If statement.  If we do, it ensures we never enter the Else portion.

Also please note the stopj(5) Script command.  if you're checking things continuously there's a chance you could interrupt robot motion and lead to a protective stop.  Putting in a stopj(a) command ensures that the robot will decelerate before moving on.  That 'a' is the acceleration argument.  Rule of thumb is 0.1=slow deceleration 5+=pretty rapid deceleration.

Lastly, if your robot encounters that Halt it will never reach the 3F Basic Open after it in the Else statement.


You're welcome.  Thats what it always compiles to anyways....find it useful sometimes to understand whats really going on to look at the script file.
I should look at that more often, I always found the continuosly scanning IF statements to be quite bizzare ;)

I wonder if they thought that would make more sense to a non-programmer over a WHILE command?