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.

Which version of the software are you running @Student?  

**Edit** Nevermind, I thought that they had changed it to where you could use subprograms within subprograms but that's not the case.  

Because of this issue, I stopped using subprograms a long time ago, also found they seemed to add time to the program anyways.  Simply moving the call to URScript will not be enough as that is what the program does when it compiles at runtime anyways.  The way that we have gotten around this and use it every day in production is two-fold.

Anything that we call repetitively and can write in URscript we do, such as commands for opening and closing grippers or the Robotiq script commands for the gripper versus using the subprogram commands.  This allows me to write once and then use anywhere plus similar to using subprograms it's quick to make changes to the command and have it applied everywhere.

The other is a bit more "confusing" at first but once you have done it a couple of times it's not bad.  We break the code up into chunks and then wrap each chunk inside of an if statement with a code.  Then at the top of the program is our logic and that logic calls the code that is to run next so something like this:

Before Start Section
codeblock = 0

Program Section

whatStepToDo = "Get User Input as to what step needs to be done"
if codeblock == 0:
  switch whatStepToDo:
    case 1: 
      codeblock = 100
    case 2:
      codeblock = 200
    case 3:
      codeblock = 300
      codeblock = 0

if codeblock == 100:
     Do whatever unique thing you want to do here
     codeblock = 400

if codeblock == 200:

   Do some other unique thing here


if codeblock == 300:

  Do something even more unique here


if codeblock == 400:

  This is somehting that can be called from anywhere so needs to be at the end of the program, this could even call another subroutine so long as it appears below this one in the program


The biggest challenge with this style is that you have your logic at the top of the program and then all of your subroutines below that both physically and numerically.  There is no goto in the UR language so you can't jump back up to the top for instance and go from code block 200 to 100 unless you control how you reset going back to your starting logic blocks.

The part that we really like about this is it provides for a lot of reusability in our code.  We have program templates that we use for our deployments that already have defined a number of code blocks that get used in every deployment.  Also, once we solve a problem it's really easy to copy and paste it into another program for use there such as a block that takes in the current location and then does a spiral or helix move from that location.  Another big advantage is that it makes it easy to do testing of the code, we can make the robot just use one code block for instance so that we can check all of the motion and verify that it is doing exactly what we want it to do.

I have obviously oversimplified the starting logic as there is only one thing that it is doing and it's asking a user for it.  We have a round robin testing scenario where the robot is using up to 3 testers at the end of the line to test product and is keeping track of which tester to service when as well as determining if the part that was just tested needs to be retested on another tester, discarded down the reject chute or placed on the outbound conveyor to go to packaging.  All of this logic is being handled in 3 logic steps at the top of the program and then calling all the required move steps based on what the logic tells it to do.

This is how we have gotten around using subprograms and it has created a scenario where it is much easier to test the code, start from multiple places based on user input during the start-up sequence so that we can resume operation where we left off, reuse code in other programs and create templates that provide core functionality without us needing to do that everytime.