Want to invite a potential Pro ? Click here!

matthewd92 Handy

Username matthewd92
Joined
Visits 725
Last Active
Roles Founding Pro, Tactile Sensor Beta Testers
Points 890
Invited bySamuel_Bouchard
Full Name Matthew Bush
Job Title COO/Cofounder
Industry Automation
Country US - United States
Company (optional) Hirebotics, LLC
Posts
400
Badges
14
  • Re: Path between product reference points

    I agree with @David_Gariepy that the plane is an option but probably very tedious and subject to imprecision.  Are the holes that you are cleaning of similar size?  If so, have you thought about using a vision system to locate the hole positions?
  • Re: Path between product reference points

    @Bryan that should be possible. What would the path between the points look like?
  • Re: Picking thin flat sheets with vacuum

    The only motion we ever got was to peal the sheet back and twist at the same time but even that wasn't reliable so we went with separation magnets and voilá, issue resolved 
  • Re: UR interrupt

    Awesome, love it when a plan comes together.  

    You're more than welcome, why we have this.
  • Re: UR interrupt

    @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
    
    or
    
    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
    end
    
    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.