Home Programming


Left ArrowBack to discussions page
abeachy_HG24abeachy_HG24 Posts: 79 Handy
Is there a way to have some sort of logic to essentially interrupt the robot's current task and have it go home?

We have two robots that are working on the same part, the first robot performs a couple tasks to it and then moves clear so that the second robot can perform a task, and then once the second robot is done they both go home and that operation is complete. The issue we are seeing is that if something goes wrong with either robot while it is performing its task, like the pressing operation not completing its cycle correctly, that part needs to be rejected. The first robot is the one receiving feedback from the press so if it doesn't complete it knows to reject it, but the second robot doesn't and will continue its program until it finishes the task, which is not desirable because we don't want to continue doing work to the part if it has been rejected.

So we were thinking we might be able to potentially just have something that basically interrupts the robot and tells it to go home and get ready for the next part. Is this possible with the URs?


  • matthewd92matthewd92 Founding Pro, Tactile Sensor Beta Testers Posts: 1,113 Handy
    @abeachy_HG24 the short answer is Yep!  So now for a bit longer answer...

    There are a couple of ways to do this but all revolve around the same premise.  If you were to wrap the entire program on the second robot in an if statement you could then monitor something on the robot and only execute the program if that condition were met.  You would use the "Check expression Continuously" feature on the if statement, little check box.  

    Now how to get them to communicate with each other could be done using digital I/O from one to the other, you would need to use a relay to isolate the 24V sources properly.  Another option is to put them on the same network and then use a general purpose modbus register to communicate with each other.  Modbus registers 128-255 are reserved for general purpose 16 bit use.  The master could set the modbus register to some value, say 100 when everything is good and the second robot can do its operations and then 999 when its time to stop operation and return home.  

    On the master robot you would use a bit of URScript to write a value to the modbus register using something like this:

    write_port_register(128, 100) # this would set the value of the register to 100
    write_port_register(128, 999) # this would set the value of the register to 999

    On the slave robot you would set-up a modbus client that connects to the master robot using the master robot's IP address.

    The code on the slave robot would look something like this:

    if MODBUS_1 != 999. #Make sure the check box is checked for checking expression continuously
      ...do your tasks here
    stopj() #This makes sure that if the robot was moving that it stops
    Your homing routine would go here, you may need to define the path to get home based on what it was doing at the time

    There is information here on using the modbus registers, the nice thing about going this route is there is no physical wiring between the robots.

    @Ryan_Weaver did a great write-up on using the modbus to mirror movement between two robots and there is good information in his white paper on how to connect the two robots together using the modbus.

    Let me know if you need more information.
  • abeachy_HG24abeachy_HG24 Posts: 79 Handy
    @matthewd92 I didn't even think of that, that's a good idea! Thanks! We have a way for the robots to communicate over Ethernet that has been working pretty well for the most part. We are using mainly Boolean bits. One robot will write a specific Boolean output true or false, the PLC sees that and then turns on or off an output to a second robot. The second robot has a variable placed in a thread that is reading that specific Boolean input. The PLC basically just mirrors whatever it receives from one robot and relays it to the next robot.  
  • abeachy_HG24abeachy_HG24 Posts: 79 Handy
    @matthewd92 I implemented that concept into one of my programs and it worked great. I tested it while it was in the middle of performing a move and it transitioned out of that into the reject logic perfectly. Thanks again!
    Awesome, love it when a plan comes together.  

    You're more than welcome, why we have this.
Sign In or Register to comment.
Left ArrowBack to discussions page